Cross-device-трекинг: связывание сессий без авторизации

Когда пользователь заходит на ваш сайт утром с ноутбука, а днём — с телефона, большинство аналитических платформ видят двух совершенно разных посетителей. Наш алгоритм идентификации устройств умеет связывать эти сессии вероятностно — без требования авторизации — анализируя пересечение сигналов и строя графы устройств.

Проблема cross-device

Классический fingerprinting генерирует уникальный ID для каждого экземпляра браузера. Chrome на ноутбуке даёт один ID, Safari на iPhone — другой. Даже на одном устройстве разные браузеры дают разные отпечатки, потому что у них разные user agent, разная поддержка возможностей и разные характеристики рендеринга.

Но пользователи мыслят не браузерами. Они мыслят сессиями. Они начинают покупку с телефона в обеденный перерыв и завершают её с ноутбука дома. Они изучают товар на планшете и покупают его с десктопа. Для fraud detection и персонализации критически важно понимать, что все эти сессии принадлежат одному человеку.

Вероятностное сопоставление сигналов

Наше cross-device-связывание построено вокруг графа людей с узлами трёх видов: посетитель (один профиль браузера), устройство (машина, на которой работают несколько профилей браузера) и хешированный идентификатор, полученный из подписанного адреса электронной почты или номера телефона, которые передаёт нам ваше собственное приложение. Именно рёбра между этими узлами объединяют две сессии в одного человека.

В этом списке намеренно отсутствуют IP-адрес и ASN. Общая сеть — сигнал соблазнительный и неверный: за одним адресом офиса, кампуса или carrier-grade NAT оказываются тысячи никак не связанных между собой людей, поэтому ребро на основе IP порождает ровно тот тип ложной связи, отменять который дороже всего. Детерминированные рёбра, которые мы действительно используем, — то же самое устройство, тот же хешированный идентификатор, тот же канонический корневой посетитель — общая сеть создать не может.

Поверх этого есть ограниченная вероятностная составляющая: подтверждённые поведенческие пары посетителя могут рассматриваться как кандидаты на присоединение — не больше нескольких на посетителя и только выше порога уверенности. Она расширяет кластер, который уже закреплён детерминированными рёбрами, но сама по себе кластер не создаёт.

Построение графа устройств

Каждая подтверждённая или высоковероятная связь между сессиями создаёт ребро в графе устройств. Граф соединяет экземпляры браузеров с узлами устройств, а узлы устройств — с узлами людей. Со временем, по мере накопления сессий, граф становится всё точнее.

Построение графа использует консервативный подход. Детерминированное ребро — то же самое устройство, распознанное под двумя профилями браузера, или тот же хешированный идентификатор, переданный для двух аккаунтов, — создаёт связь напрямую. Всё, что слабее, считается кандидатом, а не связью: оно должно преодолеть порог уверенности и ограничено лимитом, чтобы один посетитель не утянул за собой неограниченный кластер. Посетитель или мост в карантине пропускается целиком, а не сливается по подозрению.

Применение в fraud detection

Cross-device-связывание особенно эффективно для fraud detection. Мошенника, ведущего аккаунты через несколько профилей браузера, вычисляют тогда, когда эти профили сводятся к одному и тому же устройству под ними или когда за двумя аккаунтами обнаруживается один и тот же подписанный идентификатор. Украденная кредитная карта, использованная на устройстве, которое никогда не было связано с графом устройств держателя карты, немедленно вызывает тревогу.

Мы видели fraud-кольца, где один оператор держит десятки виртуальных машин для создания фейковых аккаунтов. Каждая VM выдаёт свой отдельный отпечаток браузера, но все они работают на одном и том же физическом оборудовании, и именно распознавание устройства сводит их обратно к одной машине. Этот общий узел устройства и есть то ребро, на котором строится граф: оно вскрывает кольцо по одному обнаруженному аккаунту — без всякой опоры на общий адрес.

Дизайн с сохранением приватности

Cross-device-связывание вызывает обоснованные опасения по поводу приватности. Наш подход снижает их за счёт ряда проектных решений. Во-первых, слой по умолчанию выключен — он не появляется сам вместе с развёртыванием, а осознанно включается для конкретного рабочего пространства, и до этого момента граф людей вообще не строится. Во-вторых, связывание происходит server-side и никогда не попадает в браузер, поэтому граф связей нельзя прочитать со стороны клиента, а сам режим задаётся на нашей стороне, а не чем-либо, что может прислать страница. В-третьих, ребро по идентификатору существует, только если ваше собственное приложение решит передать подписанный адрес электронной почты или телефон, — сами мы его из посетителя не выводим. В-четвёртых, пользователям можно предоставить прозрачность по связанным устройствам через ваш интерфейс приватности.

Метрики точности

Компромисс намеренный, и он в пользу precision в ущерб recall: мы предпочтём пропустить связь, чем создать ложную. Это предпочтение видно в самом устройстве системы, а не в громкой цифре: связи создают детерминированные рёбра, слабые сигналы лишь расширяют уже закреплённые кластеры, мосты в карантине пропускаются, а каждый кластер ограничен лимитом. Пропущенная связь стоит вам fraud-паттерна, который вы всё равно поймали бы позже другими средствами. Ложная связь сливает двух реальных клиентов в одного человека, и эта ошибка распространяется дальше на все принимаемые после неё решения.

Измерьте это на собственном трафике, прежде чем на это полагаться. Cross-device recall зависит от того, сколько ваших пользователей вообще проходят аутентификацию: ребро по идентификатору — самое сильное из доступных, и оно существует только там, где его передаёт ваше приложение.