Переход на server-side tracking: архитектура, миграция и контроль расхождений

Редакция mevrica

Трекинг7 мин чтения

Обновлено 3 августа 2026 г.

Server-side tracking переносит часть сбора, нормализации и маршрутизации событий на серверную инфраструктуру команды. Это может дать единый контракт, контроль retry и меньше зависеть от множества клиентских интеграций, но не создаёт право собирать больше данных и не делает событие истинным. Главный риск миграции — двойная отправка: браузер продолжает посылать старый event, сервер отправляет новый, а платформа считает оба. Поэтому переход выполняют через карту потоков, общие идентификаторы, shadow и ограниченный dual run.

Прямой ответ

Сначала инвентаризируйте текущие клиентские и серверные события. Создайте канонический event с ID и временами, реализуйте first-party endpoint, применяйте consent до маршрутизации и только затем включайте получателей через canary с reconciliation.

1. Определите цель миграции

Цель может быть единым контрактом, безопасным хранением ключей, контролем качества или надёжной доставкой. Формулировка «собрать все потерянные конверсии» нереалистична и провоцирует подмену неизвестного.

Для каждой цели задайте измеримый SLI.

Baseline перед миграцией включает matched events, duplicate rate, latency, acceptance и долю unknown. Без него улучшение нельзя измерить: новый поток может выглядеть полнее только потому, что начал считать другие события. Для каждого KPI задаётся определение и одинаковое окно зрелости до и после.

2. Нарисуйте текущие потоки

Перечислите tags, SDK, пиксели, postback, GTM, backend events и импорты. Для каждого укажите trigger, ID, получателя, consent, время и retry.

Скрытые дубли часто существуют до миграции.

Инвентаризацию удобно вести в таблице event × destination. В ячейке указаны current sender, trigger, event ID, consent rule и counting role. Так обнаруживается, что один purchase отправляется браузером, GTM и backend, а две системы считают его primary. До миграции назначьте одного владельца истины и ожидаемое поведение остальных копий.

Нарисуйте последовательность от действия пользователя до каждого получателя: браузер, first-party endpoint, очередь, обработчик, внутреннее хранилище и внешняя платформа. На каждой стрелке укажите идентификатор, формат, retry и владельца. Такая схема обнаруживает скрытые прямые отправки, которые иначе останутся после миграции.

Рядом зафиксируйте источник истины для времени, суммы, валюты и статуса. Если сервер и браузер вычисляют поле независимо, расхождения неизбежны. В целевой архитектуре одно значение создаётся один раз, а остальные компоненты либо передают его, либо явно преобразуют.

3. Создайте каноническое событие

Минимум: event_id, event_name, occurred_at, received_at, schema_version, source, consent state и необходимые бизнес-свойства.

Payload получателя строится как адаптер; его специфические поля не должны определять внутреннюю модель.

Schema registry должен поддерживать backward compatibility. Добавление optional поля обычно безопаснее переименования; изменение смысла требует новой event/schema version. Producer validation не заменяет consumer contract tests: адаптер каждого получателя проверяется на эталонных payload и отсутствующих полях.

4. Спроектируйте first-party endpoint

Endpoint проверяет размер, типы, origin/authorization по модели, rate limit и допустимые event names. Он возвращает понятный статус и request ID.

Принятие HTTP не означает бизнес-успех; очередь и доставка наблюдаются отдельно.

Не доверяйте client-provided campaign, value или identity без валидации. Часть контекста восстанавливается по server session или allowlist, а конфликт получает reason code. Endpoint ограничивает CORS/CSRF по архитектуре, проверяет content type и не возвращает секретные детали ошибки. Observability хранит request ID, но не полный чувствительный payload в обычном логе.

5. Сохраните event time

Сервер не заменяет время события временем получения. Backfill и offline event должны сохранять occurred_at, иначе отчёт попадёт в неверную когорту.

Clock skew получает quality flag.

6. Обеспечьте идемпотентность

Event ID уникален в namespace. Повтор одного события не создаёт новую запись, но delivery attempt журналируется.

Особенно тестируйте timeout после возможного принятия — запрос может быть обработан, хотя клиент не получил ответ.

Дедупликация имеет окно и область. Если один event ID повторится после истечения TTL, система не должна внезапно создать вторую конверсию без бизнес-правила. Для финансово значимых событий ключ хранится достаточно долго для полного replay и сверки. Collision и malformed ID получают отдельные коды, а не перезаписывают исходную запись.

Event ID создаётся в момент логического действия и остаётся одинаковым во всех повторных доставках этого действия. Новый ID на каждый retry делает дедупликацию невозможной, а повторное использование одного ID для разных действий скрывает реальные события. Формат и область уникальности входят в контракт.

7. Примените consent до отправки

Состояние и область разрешения участвуют в маршрутизации. Сервер не должен отправлять событие получателю, если клиентский прямой путь не имел бы допустимого основания.

Изменение consent создаёт событие состояния, а не переписывает прошлое без правила.

Consent snapshot хранит source, version, occurred_at и scopes. Adapter проверяет нужный scope перед каждым destination, а не использует общий bool. Если политика или выбор пользователя изменились, новые отправки следуют новой версии; удаление или отзыв обрабатываются отдельным регламентом, а не автоматической подменой исторического факта.

8. Минимизируйте данные

Удаляйте поля, не нужные конкретному получателю. Секреты остаются в защищённой конфигурации и не попадают в браузер или журнал.

Хеширование не отменяет чувствительность идентификаторов.

Создайте destination-specific allowlist. Например, внутренний event может содержать технический route version, но внешней платформе он не нужен; другой получатель требует currency, но не user agent. Автоматический schema diff показывает появление нового поля и блокирует отправку до review. Такой процесс предотвращает постепенное расползание payload после миграции.

9. Постройте очередь доставки

Каждый receiver имеет status, attempts, last_error, sent_at и response reference. Retry учитывает 429/5xx и не блокирует остальных.

Dead-letter queue получает owner и процедуру безопасного replay.

Outbox pattern помогает связать бизнес-транзакцию и постановку события: запись создаётся атомарно, worker доставляет позже. Exactly-once через сеть обычно недостижимо, поэтому система строится на at-least-once delivery и идемпотентном receiver/ключе. Метрики включают queue age, attempts, 429, permanent failure и dead-letter size.

Retry применяют только к временным ошибкам и ограничивают по числу либо возрасту события. Постоянный отказ валидации отправляют в quarantine с reason code, а не бесконечно возвращают в очередь. Dead-letter поток должен иметь владельца, срок разбора и безопасный способ повторной обработки.

10. Shadow mode

Сервер принимает и валидирует события, но не отправляет их внешнему получателю. Сравните объём, schema errors, latency и соответствие старому потоку.

Shadow обнаруживает контрактные ошибки без двойного учёта.

Сравнение shadow выполняют по дням события и version, а не по времени обработки. Строят matched, client-only, server-only и payload mismatch. Часть server-only может быть ожидаемой, но каждое правило классификации документируют. Unknown остаток не распределяют, пока не найден механизм.

11. Dual run

На ограниченной доле старый и новый пути используют один event ID, если получатель поддерживает дедупликацию. Иначе сравнение проводят без одновременного production counting.

Цель — matched/old-only/new-only и reason codes, а не идеальное равенство totals.

Во время параллельной работы назначьте одному контуру право влиять на внешнюю оптимизацию, а второй используйте для сравнения. Иначе двойная доставка может обучить рекламную систему на дубликатах. Отчёт reconciliation показывает совпадение по event ID, задержку и расхождения обязательных полей.

12. Переключение и откат

Canary расширяется ступенями. Откат возвращает предыдущий маршрут без повторной отправки уже принятых событий.

Версия маршрутизации хранится с каждым event и delivery.

Перед rollout замораживают изменения схемы и создают коммуникационный план. На каждой ступени проверяют counts, latency, duplicate rate и platform acceptance. Откат останавливает новые server deliveries, но не удаляет принятые события и не запускает повтор старого client потока без reconciliation. Именно эта граница предотвращает массовые дубли.

Переключение выполняют по небольшому измеримому сегменту с автоматическим порогом отката. Перед увеличением доли ждут дозревания событий и проверяют не только количество, но и стоимость, статусы и downstream-приём. Финальное отключение старого контура происходит после окончания его retry-очереди.

13. Вывод

Server-side tracking полезен как контролируемая граница данных, но требует больше инженерной ответственности. Канонический event, consent routing, идемпотентность, очередь и reconciliation важнее самого факта переноса кода на сервер.

Миграция завершена, когда старый путь отключён, расхождения объяснены, а replay и deletion проверены.

Server-side не означает скрытый

Перенос обработки на сервер не отменяет прозрачность, выбор пользователя и ограничения платформы. Используйте его для качества и управления, а не для обхода технических или правовых ограничений.