После включения серверного трекинга (CAPI) в дополнение к существующему пикселю число конверсий Purchase в рекламном кабинете внезапно выросло на 90% за один день. Что здесь стоит проверить первым делом?

Короткий ответ

Первым делом стоит проверить настройку дедупликации (event_id/deduplication key) между клиентским и серверным событием — скачок почти вдвое почти всегда означает, что одни и те же покупки теперь считаются два раза: один раз через пиксель, второй раз через CAPI.

Как это работает подробнее

Если оба канала отправляют событие Purchase с разными (или вовсе без) идентификаторами дедупликации, платформа не может сопоставить их как одно и то же событие и засчитывает оба — отсюда рост числа конверсий и выручки, который не отражает реальный рост продаж, а является техническим артефактом задвоения данных. Технически без правильной дедупликации платформа получает два отдельных HTTP-запроса о покупке с разным (или вовсе без) уникальным идентификатором события и у неё просто нет основания считать их одним и тем же событием, поэтому оба засчитываются как отдельные конверсии.

Что использовать на практике

• Практика. Чтобы проверить гипотезу, нужно сравнить число Purchase-событий с реальным числом заказов в CRM за тот же день: если число конверсий в кабинете выросло почти вдвое, а число реальных заказов не изменилось — это подтверждает проблему дедупликации, а не рост эффективности.

Подводные камни

• Риск ошибки. Частая ошибка — обрадоваться резкому росту конверсий и ROAS сразу после технического изменения и не сверить его с независимым источником (CRM/платёжная система), что может привести к неверным решениям по увеличению бюджета на основе задвоенных данных.Отдельный случай, который стоит исключить перед выводом о проблеме, — одноразовая историческая догрузка (backfill) прошлых конверсий через CAPI при первом включении интеграции: такой разовый скачок в день запуска является ожидаемым и не повторяется в последующие дни.