Identity Resolution: От 6 Сигналов к Единой Идентичности Клиента

Cookie'ли исчезли, уровень входа ~8%, на каждом устройстве свой ID, на каждом канале — другой сигнал. Средний покупатель электронной коммерции оставляет 6 различных touchpoint'ов на пути к покупке, но платформы записывают их как 6 разных людей. Главная проблема маркетинговых данных: цифровая идентичность одного человека расколота на 6 фрагментов. Identity resolution — это дисциплина инженерного объединения этих фрагментов через hash matching, probabilistic linking и household clustering. Построить production identity graph значит балансировать не только технику, но и privacy, производительность и точность.

Что такое Identity Resolution и почему это критично сейчас

Identity resolution — это процесс объединения фрагментов сигналов из разных источников (email hash, device ID, browser fingerprint, IP, session cookie) в один профиль клиента. К 2026 году полный отказ Google от third-party cookie'ов в Chrome, ограничение хранилища Safari до 7 дней в ITP 2.3, low opt-in на IDFA (≈15%) после iOS 14.5 сделали кроссдевайсный tracking невозможным на основе платформенных технологий.

Анализ Roibase за Q4 2025 на клиентах Shopify Plus показал: один и тот же пользователь генерирует в среднем 3,2 разных anonymous ID в треугольнике мобильный веб → десктоп → приложение. Когда клиент доходит до checkout'а и вводит email, только тогда происходит «склеивание». Но если вы не свяжете 4-5 touchpoint'ов до checkout'а с этим же человеком, ваша attribution модель развалится — побеждает последний клик, реальное путешествие невидимо. Identity resolution поэтому — это фундаментальный слой современного маркетингового измерения. Комбинация deterministic (точное совпадение: email, телефон) + probabilistic (вероятностное: комбинация IP+user-agent+timezone) методов достигает ~85% match accuracy.

Перенесение этой дисциплины в production требует трёхслойной архитектуры: сбор сигналов (raw event stream), stitching идентичностей (graph engine), унификация профилей (CDP layer). На каждом слое балансируется compliance (TCF 2.2, GDPR, KVKK) и производительность (real-time vs batch).

Hash Matching: Ядро Детерминистической Идентичности

Hash matching — самый надёжный метод identity resolution: вы берёте email или номер телефона пользователя, хешируете его через SHA256 и сопоставляете с hash'ами в разных системах. Точность близка к 100%, потому что вероятность коллизии ничтожна — один и тот же hash = один и тот же email. Но есть 3 критических условия: (1) вы должны собрать PII у пользователя (заполнение формы, вход), (2) получить согласие (GDPR 6(1)(a) или legitimate interest), (3) стандартизировать hash'ирование между системами (lowercase + trim + UTF-8).

В CDP & retention engineering проектах Roibase используется такой pipeline:

-- Стандартизация email hash в BigQuery
CREATE OR REPLACE FUNCTION `project.dataset.hash_email`(email STRING)
RETURNS STRING AS (
  TO_HEX(SHA256(LOWER(TRIM(email))))
);

-- Обогащение event таблицы email hash'ом
SELECT
  event_timestamp,
  user_pseudo_id,
  `project.dataset.hash_email`(user_properties.email) AS email_hash,
  device.category,
  traffic_source.medium
FROM `analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
  AND user_properties.email IS NOT NULL;

Если вы запишете этот hash'в Segment или mParticle, CDP объединит события с разных устройств под одним email_hash. Сценарий: пользователь в понедельник на десктопе подписывается на рассылку (собран email), в среду анонимно гуляет по мобилю, в четверг на десктопе снова входит и покупает. Без email hash'а — 3 разных user_id; с hash'ом — 1 профиль, 3 session'а, видно весь journey.

Компромисс: Hash matching работает только для authenticated user'ов. На сайтах электронной коммерции уровень входа 8-12%, то есть 88-92% трафика остаются анонимными. На этом сегменте включаются probabilistic методы.

Probabilistic Linking: Сопоставление Сигналов Статистически

Probabilistic identity resolution использует комбинацию различных сигналов для вычисления score: «вероятно, это один и тот же человек». IP адрес + user-agent + timezone + паттерны поведения в session'е объединяются, и при confidence threshold'е >80% два session'а связываются в одну identity. Точность не такая высокая как deterministic (false positive 5-10%), но охватывает анонимный трафик.

Логика алгоритма: каждый сигнал имеет вес. Стабильный IP (дом/офис) → +0.3, редкая комбинация user-agent+timezone → +0.25, паттерн поведения в session'е совпадает с предыдущим на 90% → +0.4. Итого score >0.8 → два session'а связаны в одной identity node'е. Это не реал-тайм — расчёт происходит batch job'ом 1-2 раза в день.

В gaming vertical'е Roibase применяет такой probabilistic pipeline:

-- Создание fingerprint'а (упрощенно)
WITH fingerprints AS (
  SELECT
    user_pseudo_id,
    event_date,
    NET.IP_TO_STRING(NET.SAFE_IP_FROM_STRING(user_first_touch_timestamp)) AS ip_prefix,
    device.operating_system,
    device.browser,
    geo.country,
    ARRAY_AGG(page_location ORDER BY event_timestamp LIMIT 5) AS page_sequence
  FROM `analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  GROUP BY 1,2,3,4,5,6
)
SELECT
  a.user_pseudo_id AS user_a,
  b.user_pseudo_id AS user_b,
  -- Jaccard similarity для последовательности страниц
  (SELECT COUNT(*) FROM UNNEST(a.page_sequence) AS p WHERE p IN UNNEST(b.page_sequence)) 
    / (ARRAY_LENGTH(a.page_sequence) + ARRAY_LENGTH(b.page_sequence)) AS similarity_score
FROM fingerprints a
JOIN fingerprints b
  ON a.ip_prefix = b.ip_prefix
  AND a.operating_system = b.operating_system
  AND a.user_pseudo_id != b.user_pseudo_id
WHERE similarity_score > 0.75;

Этот запрос находит пользователей с одинаковой IP + OS, у которых последовательность страниц совпадает на 75%+. В production эти score'ы записываются в graph database (Neo4j или BigQuery graph table) как edge weight.

Риск: Shared IP (кафе, офис) или массовые user-agent'ы (iPhone 15 + Safari) генерируют высокий false positive. Поэтому household-level resolution обрабатывается отдельным слоем.

Household Identity: Отделение Разных Людей на Одной Сети

Household clustering решает проблему: несколько человек (мама, папа, ребёнок) делят одно соединение Wi-Fi. Probabilistic matching может объединить их в один профиль, что неправильно. Чтобы этого избежать, смотрят на behavioral divergence: предпочтение категорий товаров, время session'а (утро 10:00 vs ночь 23:00), скорость скролла, паттерны ввода (биометрия, но GDPR-чувствительно).

В telecom vertical'е Roibase разработала модель:

IP-level clustering: Все session'ы с одного IP объединяются в один «household node».
Behavioral segmentation: Каждый session превращается в feature vector (product_category, avg_session_duration, bounce_rate, hour_of_day).
K-means clustering: Внутри household'а образуются 2-3 кластера — каждый соответствует «sub-identity».
Validation: Когда приходит email hash, sub-identity подтверждается или пересчитывается.

Пример структуры:

household_id	sub_identity	feature_vector	last_seen	email_hash
hh_abc123	sub_1	fashion, 18min, 0900-1200	2026-07-02	hash_x
hh_abc123	sub_2	gaming, 45min, 2100-2400	2026-07-02	NULL

Таким образом, два человека из одного дома хранятся как отдельные профили. Когда приходит email hash (например, ребёнок вошёл), sub_2 становится certain, но sub_1 остаётся probabilistic.

Компромисс: Clustering — вычислительно тяжелый. Пересчёт всех household'ов каждый день стоит дорого. Batch job запускается 4-6 часов — обновление профилей не real-time, а T+1 день.

Production Identity Graph Архитектура

Объединение трёх методов в production архитектуру:

1. Event ingestion layer (sGTM): Server-side Google Tag Manager собирает raw event stream — GA4, Segment, Klaviyo, server-side Conversion API. Каждый event содержит user_pseudo_id + session_id + client_id. Если есть email/телефон, добавляется hash.

2. Identity stitching engine (BigQuery + dbt): Ежедневный batch job выполняет:

Deterministic matching (email_hash совпадения)
Probabilistic scoring (IP+UA+behavior similarity)
Household clustering (K-means или DBSCAN)

Результат: таблица identity_graph (node = уникальная identity, edge = confidence score).

3. Profile unification (CDP): Для каждого node'а создаётся unified profile — все touchpoint'ы, атрибуты, segments объединены. Профиль синхронизируется с Klaviyo, Braze и другими платформами активации.

4. Real-time lookup: Новое событие поступает, граф ищется — если совпадение найдено, добавляется в профиль; если нет, создаётся новый node (завтра batch job объединит).

На Shopify Plus stack'е Roibase эта архитектура обходится в ~$800/месяц на GCP (BigQuery + Cloud Functions + sGTM container). При 50M event/месяц batch runtime 4-5 часов. ROI: attribution accuracy +18%, CAC стабильнее на 22% (потому что вы правильно отделяете 3 session'а одного пользователя).

Identity resolution основана на GDPR 6(1)(f) «legitimate interest» или 6(1)(a) «explicit consent». В Европе требуется явное согласие — пользователь должен согласиться: «мы объединим ваши действия на разных устройствах». Это управляется через CMP (Consent Management Platform): TCF 2.2 с purpose 2 (device identification) и purpose 7 (cross-device linking).

Hash'ирование — это GDPR pseudonymization (4(5)), не полная анонимизация, поэтому остаётся personal data категорией. Hash таблицы требуют encryption at rest + access controls. В проектах Roibase BigQuery dataset'ы шифруются customer-managed keys (CMEK), доступ ограничен IAM policies + VPC Service Controls.

Retention policy: Identity graph должен быть удалён согласно KVKK 7-й статье, когда обработка завершена. В электронной коммерции типичный retention 2 года — через 24 месяца после последней покупки профиль получает inactive флаг, через 30 дней удаляется (right to erasure).

Что Делать Сейчас

Построение identity resolution с нуля — проект на 8-12 недель. Если CDP нет, сначала создайте first-party data архитектуру — server-side event collection, BigQuery warehouse, dbt pipeline. На этот фундамент накладывается identity stitching engine. Если stack уже есть, пилотируйте probabilistic matching на 1-2 сегментах (высокоценные клиенты), измеряйте accuracy и false positive rate, калибруйте confidence threshold. Перед production запуском согласуйте consent flow и retention policy с legal team. Identity resolution — базис остальных маркетинговых слоёв (attribution, segmentation, LTV). Если здесь слабо, все верхние метрики стоят на зыбком основании.