Средний пользователь электронной коммерции просматривает ваш сайт с 6 разных устройств через 11 точек контакта, прежде чем принять решение о покупке. GA4 записывает их как 4 разных пользователя, CRM видит 2 лида, платформа email — 1 подписчика. В мире без cookies объединение этих фрагментов — не просто удобство, а необходимость. Без этого атрибуция невозможна, сегментация бессмысленна, расчет пожизненной ценности клиента становится неточным. Identity resolution — это дисциплина data engineering, которая соединяет эти фрагменты в единую идентичность. Для этого требуется трёхслойная архитектура: от детерминированного хеш-сопоставления до вероятностной связи.

Хеш-сопоставление: детерминированный остов идентичности

Детерминированное совпадение работает через хеш SHA-256. Адрес электронной почты "[email protected]" преобразуется в хеш "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8" — если один и тот же хеш появляется в каждой системе, это один и тот же человек. Когда пользователь входит в систему, Вы добавляете параметр user_data.email_sha256 в payload события GTM на сервере, и в BigQuery этот хеш объединяет веб-сессию, лид в CRM и подписчика Klaviyo в одну строку.

Два критических момента: стратегия соли для хеша и риск коллизии. Если взять хеш без соли, возникает риск атаки радужной таблицы, но в маркетинговом pipeline данных соль должна быть согласованной во всех системах — иначе один и тот же адрес электронной почты будет производить разные хеши. Риск коллизии в SHA-256 теоретический — на практике столкновений в пространстве 2^256 не бывает, но с низкоэнтропийными полями, такими как номер телефона, детерминизм ослабляется. По этой причине комбинация email + телефон создаёт более надёжный остов.

Когда вы извлекаете данные из Klaviyo в BigQuery, добавляйте столбец user_properties.email_sha256 и используйте LEFT JOIN web_events USING (email_sha256) в dbt-модели. Таким образом анонимная веб-сессия связывается с профилем подписчика в одной строке. Стратегия таблицы снимков критична — сопоставления хешей должны сохраняться в ежедневных снимках, чтобы при изменении пользователем адреса электронной почты исторические сопоставления не были утеряны.

Вероятностная связь: объединение сигналов с помощью нечёткой логики

Детерминированное сопоставление недостаточно для мобильного веба без cookies. Пользователь закрывает браузер, не войдя в систему и не оставляя адреса электронной почты, но комбинация IP + user agent + timezone + язык с вероятностью 87% указывает на одного и того же человека. Здесь в дело вступает вероятностный граф идентичности — Вы взвешиваете сигналы с использованием байесовской вероятности.

Существует шесть основных слоёв сигналов: отпечаток устройства (canvas hash, WebGL renderer), сетевой уровень (IP-подсеть, ASN), поведенческой паттерн (длительность сессии, последовательность путей), геолокация (кластеризация GPS lat/long), временной сигнал (паттерн активных часов) и контекстные метаданные (домен источника, согласованность UTM). Каждому сигналу присваивается оценка достоверности от 0 до 100, и если взвешенная сумма превышает 70, назначается временный probabilistic_id.

В BigQuery вы моделируете это следующим образом:

WITH signal_scores AS (
  SELECT
    session_id,
    device_fingerprint,
    ip_subnet,
    SUM(
      CASE WHEN device_fingerprint_match THEN 40 ELSE 0 END +
      CASE WHEN ip_subnet_match AND hour_diff < 4 THEN 25 ELSE 0 END +
      CASE WHEN behavior_vector_similarity > 0.8 THEN 20 ELSE 0 END
    ) AS total_confidence
  FROM event_stream
  WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
)
SELECT session_id, device_fingerprint, total_confidence,
  CASE WHEN total_confidence >= 70 
    THEN GENERATE_UUID() 
    ELSE NULL 
  END AS probabilistic_id
FROM signal_scores

Компромисс этого подхода — риск ложных срабатываний. Общее устройство (офисный компьютер) или использование VPN могут объединить разных людей. По этой причине вероятностные ID всегда должны проверяться детерминированным хешем — когда пользователь входит в систему, происходит операция "слияния" на основе хеша, исправляются все предыдущие вероятностные сессии.

Идентификация домохозяйства: от набора устройств к единице дома

Единица принятия решения обычно — не индивид, а домохозяйство. С одного IP-адреса работают три устройства: MacBook (утром женщина), iPhone (весь день), iPad (вечером ребёнок). Объединение их в одного "индивидуума" неправильно, но группировка как "домохозяйство" критична для сегментации — особенно для товаров длительного пользования (бытовая техника, мебель), где решение о покупке принимается на уровне семьи.

График домохозяйства строится на основе MAC-адреса маршрутизатора/модема + подсети IP + GPS-координат. В качестве основы берётся отпечаток сети, а не устройства, потому что WiFi-маршрутизатор даёт один и тот же MAC-адрес шлюза на всех устройствах. Здесь критично фильтровать публичные WiFi — если вы группируете 200 устройств с IP Starbucks как "домохозяйство", модель развалится. Это фильтруется порогом количества сессий (на одном IP более 50 уникальных устройств → чёрный список) и паттерном времени нахождения (на одном IP нет сессий длительностью 2+ часа → розничный магазин/кафе).

В BigQuery вы присваиваете ID домохозяйства следующим образом:

CREATE OR REPLACE TABLE households AS
WITH network_clusters AS (
  SELECT ip_subnet, router_mac, GPS_lat, GPS_long,
    APPROX_COUNT_DISTINCT(device_id) AS device_count,
    AVG(session_duration_sec) AS avg_session
  FROM sessions
  WHERE DATE(timestamp) > DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  GROUP BY 1,2,3,4
  HAVING device_count BETWEEN 1 AND 8 AND avg_session > 120
)
SELECT *, GENERATE_UUID() AS household_id
FROM network_clusters

Расчёт пожизненной ценности на уровне домохозяйства более осмыслен, потому что покупка бытовой техники — не выбор одного человека, а необходимость для всего дома. В архитектуре CDP и Retention Engineering сегменты домохозяйства показывают на 23% выше ROAS по сравнению с индивидуальными сегментами — потому что вместо отправки сообщений на один номер телефона с разных устройств домохозяйство становится стратегической целью.

Связывание графа: идентичность, растянутая во времени

График идентичности статичен — пользователь сегодня анонимен, завтра предоставляет адрес электронной почты, через 5 дней входит в систему, через 2 месяца обновляет номер телефона. Каждый новый сигнал "связывает" старые фрагменты — то есть старые вероятностные ID'ы объединяются с новым детерминированным хешем.

Вы решаете это в event-driven архитектуре: каждое событие user_identified падает в Pub/Sub, вызывается Cloud Function, в BigQuery запускается оператор MERGE. Например, пользователь входит в систему → поступает хеш email → все вероятностные ID'ы, созданные с этого же отпечатка устройства за последние 90 дней, связываются с этим хешем. Эта операция backfill должна идти так далеко в прошлое, как окно атрибуции — если у Вас 30-дневное окно конверсии, связывайте на 30 дней в прошлое.

MERGE INTO unified_identity AS target
USING (
  SELECT probabilistic_id, email_sha256, MAX(timestamp) AS last_seen
  FROM identification_events
  WHERE event_name = 'user_login'
  GROUP BY 1,2
) AS source
ON target.probabilistic_id = source.probabilistic_id
WHEN MATCHED THEN UPDATE SET 
  target.email_sha256 = source.email_sha256,
  target.is_deterministic = TRUE,
  target.stitched_at = CURRENT_TIMESTAMP()

Связывание несёт риск race condition — если пользователь одновременно входит с двух устройств, две попытки слияния разных хешей могут конфликтовать. Это решается блокировкой транзакции или ключом идемпотентности. Ключ идемпотентности обычно — это device_id + timestamp_truncated_to_second — два события user_login с одного устройства в течение одной секунды считаются дубликатом и запускают только одно слияние.

Приватность и соответствие нормам: хешированные PII и минимизация данных

Разрешение идентичности в контексте KVKK и GDPR попадает в категорию "автоматизированное принятие решений" и "профилирование" — это означает, что без явного согласия это делать нельзя. Если от платформы управления согласием (OneTrust, Cookiebot) не приходит сигнал analytics_storage=granted, Вы не можете даже взять хеш. В Consent Mode v2 при базовом согласии параметр user_data остаётся пустым, хеш добавляется только при расширенном согласии.

Хеш не считается PII, а считается псевдонимизацией — это означает, что по GDPR "право на забывчивость" распространяется и на хеши. Когда поступает запрос на удаление, Вы должны запустить оператор DELETE на основе email_sha256 в BigQuery, и это удаление должно распространиться на downstream системы (CDP, CRM). По этой причине таблица отображения хешей должна быть централизована — в распределённых системах хеши не должны быть разбросаны; они должны быть производными из единого источника истины.

Принцип минимизации данных должен ограничить граф идентичности периодом в 90 дней. Вероятностные ID'ы старше 90 дней должны быть перенесены в архив, долгосрочно должны храниться только детерминированные хеши. Это критично как для соответствия нормам, так и для снижения затрат на хранилище — если применить partition pruning с 90-дневным скользящим окном в BigQuery, стоимость запроса снижается на 60%.

Архитектура production pipeline: гибрид batch + streaming

Pipeline разрешения идентичности работает на двух уровнях: streaming layer (сбор сигналов в реальном времени) и batch layer (связывание по ночам). Streaming layer работает через Pub/Sub → Dataflow → BigQuery с latency <10 секунд. Batch layer запускается в 04:00 UTC с помощью dbt, на этом уровне выполняются все операции связывания графа и кластеризации домохозяйства.

На streaming layer'е собираются только сигналы — хеш-сопоставление и вероятностное подсчёт не выполняются, потому что сложные JOIN'ы в streaming'е дорогие. События записываются в Firestore с уникальным ограничением на event_id, что предотвращает дублирование записей. Batch layer читает эти события и преобразует их в размерную модель в BigQuery. Макросы dbt связывают генерацию хешей, расчёт оценок и слияние графа в один pipeline.

Для мониторинга критична метрика coverage графа: identified_users / total_active_users. Если она ниже 40%, это означает недостаток детерминированных сигналов — нужно оптимизировать flow входа, сосредоточиться на захвате email в формах лидов. Если выше 75%, это считается здоровым. Эта метрика определяется как dbt тест