Cross-Device трекінг: зв’язування сесій без логіну

Коли користувач заходить на ваш сайт з ноутбука зранку та з телефона по обіді, більшість аналітичних платформ бачать двох цілком різних відвідувачів. Наш алгоритм ідентифікації пристроїв здатен імовірнісно поєднати ці сесії — без вимоги логіну — аналізуючи перетин сигналів і будуючи графи пристроїв.

Проблема cross-device

Традиційний fingerprinting генерує унікальний ID для кожного екземпляра браузера. Chrome на ноутбуці дає один ID; Safari на iPhone — інший. Навіть на одному пристрої різні браузери генерують різні fingerprint’и, бо мають різні user agent, різну підтримку можливостей і різні характеристики рендерингу.

Але користувачі не мислять категоріями браузерів. Вони мислять категоріями сесій. Вони починають покупку на телефоні під час обіду та завершують її на ноутбуці вдома. Вони досліджують товар на планшеті й купують його на десктопі. Для виявлення шахрайства та персоналізації критично розуміти, що ці сесії належать одній і тій самій людині.

Імовірнісне зіставлення сигналів

Наше cross-device зв’язування побудоване навколо графа людей із вузлами трьох типів: відвідувач (один профіль браузера), пристрій (машина, що стоїть під кількома профілями браузера) і хешований ідентифікатор, отриманий із підписаної адреси електронної пошти чи номера телефону, які передає нам ваш власний застосунок. Саме ребра між цими вузлами поєднують дві сесії в одну людину.

Свідомо відсутні в цьому переліку IP-адреса та ASN. Спільна мережа — сигнал спокусливий і хибний: офіс, кампус чи carrier-grade NAT ставлять за однією адресою тисячі непов’язаних людей, тож ребро на основі IP дає саме той різновид хибного зв’язку, який найдорожче скасовувати. Детерміновані ребра, які ми справді використовуємо, — той самий пристрій, той самий хешований ідентифікатор, той самий канонічний корінь відвідувача — спільна мережа не здатна вигадати з нічого.

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

Побудова графа пристроїв

Кожен підтверджений або високоймовірний зв’язок між сесіями створює ребро у графі пристроїв. Граф поєднує екземпляри браузерів із вузлами пристроїв, а вузли пристроїв — із вузлами людей. З часом, у міру накопичення сесій, граф стає дедалі точнішим.

Побудова графа використовує консервативний підхід. Детерміноване ребро — той самий пристрій, розпізнаний під двома профілями браузера, або той самий хешований ідентифікатор, переданий для двох акаунтів, — створює зв’язок одразу. Усе слабше вважається кандидатом, а не зв’язком, має подолати поріг упевненості й обмежене лімітом, щоб один відвідувач не тягнув за собою необмежений кластер. Відвідувача чи місток на карантині система просто пропускає, а не зливає за підозрою.

Застосування для виявлення шахрайства

Cross-device зв’язування особливо потужне для виявлення шахрайства. Шахрая, який веде акаунти через кілька профілів браузера, ідентифікують тоді, коли ці профілі розпізнаються як той самий пристрій під ними або коли за двома акаунтами виявляється той самий підписаний ідентифікатор. Викрадена кредитна картка, використана на пристрої, що ніколи не був пов’язаний із графом пристроїв власника картки, спричиняє негайне сповіщення.

Ми бачили fraud-ринги, де один оператор запускає десятки віртуальних машин для створення фейкових акаунтів. Кожна VM показує окремий fingerprint браузера, але всі вони розміщені на одному фізичному залізі, і саме розпізнавання пристрою згортає їх назад до однієї машини. Цей спільний вузол пристрою і є тим ребром, на якому будується граф: він викриває ринг з єдиного виявленого акаунта, без жодних посилань на спільну адресу.

Дизайн зі збереженням приватності

Cross-device зв’язування породжує обґрунтовані занепокоєння щодо приватності. Наш підхід пом’якшує їх завдяки кільком проєктним рішенням. По-перше, цей шар типово вимкнений — він не з’являється разом із деплоєм, його свідомо вмикають для конкретного workspace, і до того моменту жоден граф людей не будується взагалі. По-друге, зв’язування відбувається на боці сервера й ніколи не потрапляє в браузер, тож граф зв’язків неможливо прочитати з боку клієнта, а режим встановлюється на нашому боці, а не чимось, що може надіслати сторінка. По-третє, ребро ідентифікатора існує лише тоді, коли ваш власний застосунок вирішує передати підписану пошту чи телефон, — ми не виводимо його з відвідувача. По-четверте, користувачам можна надати прозорість щодо пов’язаних пристроїв через ваш інтерфейс приватності.

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

Компроміс свідомий, і він на користь precision над recall: ми радше пропустимо зв’язок, ніж створимо хибний. Ця перевага помітна в самій конструкції, а не в гучній цифрі — зв’язки створюють детерміновані ребра, слабкі сигнали лише розширюють кластери, які вже мають якір, містки на карантині пропускаються, а кожен кластер обмежений лімітом. Пропущений зв’язок коштує вам шахрайського патерну, який ви все одно виявили б пізніше в інший спосіб. Хибний зв’язок зливає двох реальних клієнтів в одну людину, і ця помилка поширюється на кожне подальше рішення.

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