ddadminandClaude Fable 5
0d9a83d6af
Зачем: собранная спека заказов стала базовой документацией сервиса, а жанр спеки-события ей мал: дата в имени врёт, целиком в контекст агента она не влезает, а трекер с резолюциями долговечным хранилищем не считается. Решение владельца — держать детальное устройство компонента связным набором живых документов (ADR 0011) и совместить переезд с проходом на вычитание (#84). Что: docs/architecture/orders/ — индекс README и файлы по частям устройства: проекция, слепок и доставка, судьба, классы расхождений, опись, мост к склейке, стартовый мир, правила кода; спека приёма переехала в ingestion.md без содержательных правок. Резы вычитания по итогам двух слепых линий: тела разделов о проводе и приёме сведены к указателям на мастер-спеку, исследование формата и ADR (порядок строк слепка — единственное правило, оставшееся на месте); замеры канонического зерна и повторы-пояснения срезаны; списки отклонённых вариантов сохранены как долговечная запись. Датированные файлы удалены, ссылки из мастер-спеки, спеки генератора, ADR 0008/0010, исследования формата и storage.md перенацелены; раздел «Структура» AGENTS.md дополнен правилом подпапки. Проверка: grep по репозиторию не находит ссылок на удалённые файлы; все относительные ссылки внутри набора разрешаются в существующие файлы; впереди холодная сверка «ни одно решение не потеряно» и приёмка #88. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
38 lines
3.8 KiB
Markdown
38 lines
3.8 KiB
Markdown
# Мост к склейке: человек, `person_id`, `user_id`
|
|
|
|
Резолюция развилки [«Мост к склейке: user_id и двухкуковые
|
|
пары»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/73).
|
|
|
|
Причинная модель: план состава порождает **человека**; ему принадлежат одна
|
|
или две куки, каждая наблюдается в кликстриме как отдельный посетитель. Визит
|
|
может оформить заказ — тогда заказная сторона представляет того же человека
|
|
как **пользователя магазина**. Это не модель аккаунта: регистрации нет, люди
|
|
без визитов не порождаются, внутреннее знание наружу не выдаётся.
|
|
|
|
План владеет устойчивой личностью и отношением «кука принадлежит человеку».
|
|
Минимальная форма — непрозрачный внутренний `person_id`, выровненный по кукам:
|
|
у двух кук пары он одинаков. Заказ выводит то же значение под родным именем
|
|
`user_id` (`UInt64`); в кликстрим ни `person_id`, ни `user_id` не попадает —
|
|
анонимность формата держится формой, а не забывчивостью сериализатора.
|
|
|
|
`person_id` — последний обычный бросок потока случайности когорты, после уже
|
|
принятых свойств: добавление личности не сдвигает куки, пары, возвраты и
|
|
паспорта. Для второй куки повторяется ID её человека. Раздельные прогоны
|
|
ничего не хранят и не согласуют: генератор событий и команда слепка заново
|
|
спрашивают один план и получают тот же `person_id`.
|
|
|
|
Наблюдаемое обещание — четыре свойства: назначенные заказы пары с разных
|
|
`ClientID` несут один `user_id`; событие Метрики не раскрывает `user_id`;
|
|
отдельные прогоны одного мира дают то же соответствие; принятый мир
|
|
воспроизводит эффект склейки без случайных ложных объединений — конкретные
|
|
числа пар контрактом описи не являются. Межкогортные столкновения принимаются
|
|
по той же дисциплине, что у случайных `ClientID`: принимается конкретный
|
|
канонический мир по внешнему результату.
|
|
|
|
Отклонено: *заказная сторона сама назначает личность* — родство кук всё равно
|
|
пришлось бы спрашивать у плана; *материализованный реестр кука↔пользователь* —
|
|
состояние между прогонами без нового внешнего эффекта; *первая кука как ID
|
|
человека* — магазин оказался бы замаскированным продолжением трекера;
|
|
*структурная координата, хеш или глобальная последовательность* — больше
|
|
механики при тех же данных; *полная модель аккаунтов* — менти её не наблюдает.
|