Files
clickstream-data-platform/docs/architecture/orders/identity.md
T
ddadminandClaude Fable 5 cf1c6c4636 docs(orders): спека превращена в принятый живой набор architecture/orders
Зачем: датированная спека — событие истории, а устройство компонента — живой
документ; большое полотно плохо грузится и агентом, и человеком (ADR 0011).

Что: вычитание #84 слито с переустройством формы: набор
docs/architecture/orders/ — индекс README и семь файлов по частям устройства
(нарезка по правилу «семь плюс-минус два»); датированные файлы удалены,
ссылки перенацелены, AGENTS.md дополнен правилом подпапки. Приёмка
владельцем #88 пройдена, черновой статус снят из README.

Проверка: холодная сверка миграции свежим тредом — потерь решений нет;
обход относительных ссылок набора — битых нет.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-17 22:05:52 +03:00

3.8 KiB

Мост к склейке: человек, person_id, user_id

Резолюция развилки «Мост к склейке: user_id и двухкуковые пары».

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

План владеет устойчивой личностью и отношением «кука принадлежит человеку». Минимальная форма — непрозрачный внутренний person_id, выровненный по кукам: у двух кук пары он одинаков. Заказ выводит то же значение под родным именем user_id (UInt64); в кликстрим ни person_id, ни user_id не попадает — анонимность формата держится формой, а не забывчивостью сериализатора.

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

Наблюдаемое обещание — четыре свойства: назначенные заказы пары с разных ClientID несут один user_id; событие Метрики не раскрывает user_id; отдельные прогоны одного мира дают то же соответствие; принятый мир воспроизводит эффект склейки без случайных ложных объединений — конкретные числа пар контрактом описи не являются. Межкогортные столкновения принимаются по той же дисциплине, что у случайных ClientID: принимается конкретный канонический мир по внешнему результату.

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