Postback как контракт: почему я перестал “просто пробрасывать” события

Postback как контракт: почему я перестал “просто пробрасывать” события

В 2026 я всё чаще вижу одну и ту же инженерную ошибку: postback воспринимают как техническую кнопку “отправь конверсию”, а не как договор между трекером, платформой и бизнес-метрикой. В результате мы получаем атрибуцию, которая “сходится по количеству”, но расходится по смыслу.

Моя позиция жёсткая: **postback должен быть инвариантным** относительно источника трафика и формата события на стороне рекламной системы. То есть одно и то же бизнес-событие (например, “SQL-сделка создана”, “пакет документов подписан”, “оплата прошла”) должно приходить в разные каналы одинаково: с одинаковыми ключами идентификации, одинаковыми правилами дедупликации и с одинаковой логикой “что считается успешным”.

Что я делаю на практике:
— Строю словарь событий “уровень бизнеса → уровень транспорта”. На уровне бизнеса: conversion_type, revenue_bucket, lead_stage. На уровне транспорта: client_id/server_id, time, event_hash, параметр качества (например, dedupe_key).
— Вводю “контроль версий” события: event_schema_version и обязательный набор полей. Если поменяли поле — считаем, что это новое событие до сверки.
— Дедупликацию переношу в серверную аналитику: postback может прийти дважды (ретраи, лаги, повторный апдейт лида), а атрибуция должна переживать это.

Одно наблюдение из реальной отладки (B2B, серверная связка CRM + ad platform):
когда мы оставили дедупликацию “на стороне приёмника”, расхождение по SQL составило около 6–9% по медиане недельного окна. После переноса дедупа на common-key (lead_id + stage + date_bucket) расхождение упало до 1–2%. Это не “маркетинговая магия”, это банальная математика: вероятность повторов не нулевая, а качество ключей важнее идеальной передачи “последнего клика”.

Почему это критично именно сейчас:
last-click всё сильнее выдавливают privacy-first подходы (server-side, MMM, incrementality). В такой архитектуре постбэк становится опорным узлом, и любое нестрогое трактование “события успеха” превращает модель в гадание по шуму.

Если хотите быстрый тест на зрелость вашей postback-схемы:
попробуйте зафиксировать один бизнес-кейс (один заказ/одна сделка) и проследить, сколько раз и в каких параметрах он уходит в платформу. Если вы не можете ответить “один кейс → одно событие → один dedupe_key” без ручной лог-охоты, значит контракт ещё не подписан — и атрибуция будет продолжать врать, даже когда цифры “похожи”.

Ядро мысли простое: **postback — это не канал связи, а часть измерительной системы**. Относитесь к нему как к интерфейсу: версия, инварианты, дедуп, контроль качества. Тогда серверная аналитика начинает работать как инженерная дисциплина, а не как набор надежд.

— @AdOpsRoom