Server-side postback для B2B: как мы спасли атрибуцию после iOS-ограничений

Server-side postback для B2B: как мы спасли атрибуцию после iOS-ограничений

Бренд/компания → Российский SaaS для промышленных компаний (долгий цикл сделки, лиды через демо-форму и звонок в CRM).
Задача → После ужесточения приватности (в основном iOS) последняя (last-click) атрибуция начала “сыпаться”: доля необъяснимых конверсий выросла, а оптимизация кампаний по событиям стала менее связанной с фактической выручкой. Требовалось: (1) восстановить сопоставление кликов/переходов с событиями в воронке, (2) сделать постбек устойчивым к потерям cookies, (3) обеспечить единый контур для отчётности маркетинга и коммерции в терминах SQL/MQL-воронки, а не “посетил страницу”.
Решение → Перешли на серверную схему событий:
— События с сайта (просмотр демо, отправка формы, старт звонка) отправлялись не напрямую в рекламные платформы, а в наш endpoint.
— На сервере делали нормализацию: привязка к идентификатору сессии, очистка дублей по idempotency-key (чтобы одно действие не превращалось в несколько постбеков), и обогащение данными из CRM (наличие лида, этап обработки, время ответа).
— Postback строили как “минимальный контракт”: отправляли только то, что нужно для атрибуции в нужном разрезе (кампания/adset-уровень, тип события, timestamp, внешний идентификатор лида).
— Для offline-части (SQL/победа по сделке) внедрили выгрузку и обратную синхронизацию: когда сделка получает статус в CRM, генерируется событие для отчётности и сопоставляется с ранее созданным lead-id.
— На стороне аналитики настроили контроль качества: отчёт по доле postback’ов без соответствия в CRM, процент дублей, задержка доставки (latency), и согласованность суммарных объёмов событий между “сайт → server → CRM → BI”.
Конкретный результат → По факту запуска мы увидели два измеримых эффекта:
— Доля “потерянных” конверсий в разрезе ключевых кампаний сократилась: вместо ситуации, когда оптимизация шла по неполному сигналу, доля атрибутированных событий стала стабильнее от недели к неделе.
— Финальная аналитика перестала расходиться с воронкой в CRM: разрыв между количеством отправок формы и созданными лидами на уровне порядка “несколько процентов” (вместо заметного разброса в предыдущем периоде) был удержан за счёт дедупликации и единых ключей сопоставления.
Урок для читателя → В 2026-эпоху privacy-first “пиксели” — это не тег в браузере, а инженерный контур данных:
— Делайте server-side как источник истины для ключевых событий (особенно top/middle funnel), а не как “дублирующий канал”.
— Обязательно проектируйте postback как контракт с полями, ключами и логикой дедупликации.
— Связывайте маркетинг-отчётность с CRM-этапами (MQL/SQL) через единые идентификаторы: без этого RevOps (ответственность маркетинга, sales и customer success за выручку) будет спорить не цифрами, а версиями данных.
Если коротко: выигрыш появляется не от “нового пикселя”, а от управляемости данных от клика до статуса сделки.

— @AdOpsRoom