Если Meta Ads показывает 127 покупок, а трекер — 103, это ещё не доказывает поломку. Системы могут считать разные события, использовать разные окна атрибуции, timezone и дату отчёта. Но фраза «Facebook всегда моделирует» тоже не объяснение: расхождение нужно разложить на измеряемые причины.
Цель reconciliation — не заставить два интерфейса показать одинаковое число любой ценой. Цель — построить мост между платформенным attributed event, полученным callback и подтверждённой бизнес-транзакцией.
Сначала определите, что именно сравниваете
Зафиксируйте для обеих сторон:
- название и семантику события;
- временной диапазон и timezone;
- дату отчёта: click time или conversion time;
- attribution window;
- click-through и view-through правила;
- включены ли modeled/estimated conversions;
- статус: raw, pending, approved или paid;
- gross revenue, payout или order value;
- фильтры account, campaign, GEO и device.
Без этого сравнение «Purchases против Sales» может соединить несопоставимые множества.
Карта причин расхождения
| Причина | Обычно больше в Meta | Обычно больше в трекере | Как доказать |
|---|---|---|---|
| View-through/modeling | ✓ | Разбивка attribution setting | |
| Разные окна | ✓/— | ✓/— | Одинаковый cohort и window |
| Разные timezone | ✓/— | ✓/— | Пересчитать timestamps в UTC |
| Pixel + CAPI без dedup | ✓ | Сверить event_id | |
Потерян fbclid/fbc | ✓ | Проверить click record и CAPI payload | |
| Не пришёл postback | ✓ | CRM/order есть, tracker callback нет | |
| Не тот статус | ✓/— | ✓/— | Raw status → canonical mapping |
| Organic/direct события | ✓ | Наличие paid click ID | |
| Rejected/refund позже | ✓ | История статусов и correction | |
| Повтор callback | ✓ | Transaction ID и duplicate log |
1. Выровняйте время
Один и тот же депозит в 23:30 UTC может попасть в разные календарные дни в рекламном кабинете и трекере. Экспортируйте timestamps, приведите их к UTC и отдельно храните исходную timezone.
Также решите, по какой дате группировать. Meta может приписывать конверсию дню рекламного взаимодействия, тогда как CRM показывает день фактического депозита. Для дневной сверки это создаёт расхождение даже при полном совпадении событий за длинный период.
2. Сравните одинаковую атрибуцию
Трекер обычно использует детерминированный путь через click ID. Рекламная платформа может учитывать собственные окна, view-through сигналы и моделирование. Поэтому начните с наиболее строгого общего слоя:
- paid click был зафиксирован обеими системами;
- событие произошло внутри согласованного окна;
- тип и статус события одинаковы;
- user/order не включён в тестовый или organic traffic.
Сделайте отдельные колонки tracker_attributed, meta_attributed и business_confirmed. Не превращайте отсутствие совпадения в автоматическое доказательство ошибки одной стороны.
3. Проверьте маршрут fbclid → fbc → CAPI
После клика Meta может передать fbclid. Его нужно сохранить через landing, PWA и offer route и использовать для корректного click context серверного события. Параллельно сохраните внутренний click ID трекера — он нужен для вашего postback.
Если fbclid теряется на редиректе, трекер всё ещё может принять депозит по своему ID, но Meta получит слабее сопоставленное событие. Карта ролей приведена в статье Click ID, Sub ID, fbclid, fbc и ttclid.
4. Проверьте Pixel + CAPI dedup
Одна покупка часто отправляется двумя каналами:
- браузерный Pixel;
- серверный Conversions API.
Для дедупликации обе копии должны представлять одно событие и использовать согласованный event_id. Типовые ошибки:
- браузер и сервер генерируют разные IDs;
- один постоянный ID используется для всех покупок;
- retry CAPI получает новый ID;
- названия события не совпадают;
- CAPI отправляется после уже изменённого статуса как новая покупка.
Проверьте Events Manager и собственный delivery log. Считайте queued промежуточным состоянием; нужен ответ API и связь с исходной транзакцией. Общую роль каналов объясняет Pixel vs CAPI vs Postback, а Meta публикует назначение Conversions API в официальной справке.
5. Сверьте семантику статусов
Оффер может прислать registration, deposit, approved, rejected. В Meta команда могла оптимизироваться на Purchase, отправляя туда уже первый депозит. Если трекерский отчёт фильтрует только approved, Meta закономерно будет выше до завершения hold.
Сделайте таблицу:
| Источник | Сырое событие | Внутренний статус | Meta event | Revenue |
|---|---|---|---|---|
| CRM/network | reg | Registration | Lead | 0 |
| CRM/network | ftd | First deposit | Purchase | payout/value |
| CRM/network | approved | Approved | Не отправлять повторно либо correction | confirmed |
| CRM/network | rejected | Rejected | Policy-dependent correction | 0 |
Не существует универсально правильного маппинга для всех бизнесов. Но он должен быть явным, versioned и одинаковым в отчётах.
6. Отделите потерю callback от потери platform feedback
Это два разных сбоя:
Network/CRM → postback → tracker → CAPI → Meta- Если order есть в CRM, но нет в трекере — проверяйте postback, click ID и статус.
- Если событие есть в трекере, но нет в Meta — проверяйте policy, payload, token,
fbc/fbp, event ID и API response. - Если Meta видит событие, а CRM его позже отклонила — нужна история статуса, а не удаление исходного факта.
Используйте чек-лист диагностики постбека для первого участка.
7. Найдите дубли и реальные повторные покупки
Один пользователь может сделать две покупки — это не дубль. Один и тот же callback может быть доставлен дважды — это дубль. Различайте их по transaction ID:
| click_id | transaction_id | event | Результат |
|---|---|---|---|
c101 | tx900 | purchase | accepted |
c101 | tx900 | purchase | duplicate |
c101 | tx901 | purchase | accepted |
Dedup только по click ID ошибочно удалит tx901. Отсутствие dedup вообще удвоит tx900.
Практическая reconciliation-таблица
Выгрузите один matured cohort и соберите строки по transaction ID:
| transaction_id | click_id | event_at UTC | tracker status | Meta sent | Meta accepted | business status | value |
|---|---|---|---|---|---|---|---|
tx900 | c101 | 12:04 | FTD | yes | yes | approved | 45 |
tx901 | c102 | 12:11 | FTD | yes | no | approved | 30 |
tx902 | — | 12:19 | — | — | modeled/unknown | approved | 55 |
Каждой несовпавшей строке присвойте reason code, а не свободный комментарий:
TIMEZONE_SHIFTWINDOW_MISMATCHCLICK_ID_LOSTPOSTBACK_MISSINGSTATUS_FILTEREDCAPI_REJECTEDPIXEL_CAPI_DUPLICATEORGANIC_OR_UNATTRIBUTEDMODELED_PLATFORM_EVENTBUSINESS_REJECTED
После этого расхождение превращается в распределение причин, которое можно уменьшать по приоритету.
Как проводить сверку без самообмана
- Возьмите период, где конверсии уже дозрели и hold в основном завершён.
- Зафиксируйте настройки отчётов и не меняйте их в процессе.
- Сравнивайте один account/GEO/campaign cohort.
- Используйте transaction-level export, а не только totals.
- Отдельно считайте события без детерминированного match.
- Не «добавляйте» modeled events в CRM revenue.
- После исправления повторите тест на новом cohort, не переписывая историю.
FAQ
Какой процент расхождения нормальный?
Универсального безопасного процента нет. Даже небольшое расхождение может скрывать систематическую потерю дорогого GEO, а большое — объясняться разными окнами. Норма определяется reason codes и бизнес-влиянием, а не одной границей.
Кому верить: Meta, трекеру или CRM?
Для разных вопросов — разным системам. Meta отвечает за свою атрибуцию и delivery optimization. Трекер — за детерминированный маршрут клика. CRM/платёжная система — за факт и финальный статус транзакции. Хорошая сверка не выбирает одного победителя, а связывает три слоя.
Почему после подключения CAPI конверсий стало больше?
Возможны как лучшее сопоставление, так и дубли Browser Pixel + CAPI. Проверьте общий event_id, event name, transaction mapping и ответы Events Manager до вывода об uplift.
Можно ли добиться полного совпадения?
Для строго определённого детерминированного подмножества — приблизиться можно. Общие цифры интерфейсов могут оставаться разными из-за окон, view-through, modeling и даты атрибуции. Важно, чтобы разница была объяснена и не искажала решения о бюджете.
Итог
Начните не с totals, а с контракта данных: один click record, один transaction ID, явный status mapping и лог доставки в Meta. DarkCore Analytics и Finance нужны именно для такого соединения — от источника клика до подтверждённой выручки, с возможностью экспортировать и перепроверить результат.