<b>Conversion API в native: где ломается интеграция и как не потерять postback</b>

<b>Conversion API в native: где ломается интеграция и как не потерять postback</b>


В native-трафике CAPI нужен не «для галочки», а чтобы связать клик, лид и апрув без плясок с пикселем. Проблема в том, что у native-источников цепочка длиннее: редирект, преленд, оффер, иногда свой трекер. На каждом шаге можно потерять параметры.

Проверяйте базу:
— сохраняется ли `click_id` с первого захода до отправки формы;
— уходит ли `event_id` в CAPI и совпадает ли он с серверным событием;
— не режет ли преленд UTM, subid и referer;
— есть ли дедупликация между пикселем и сервером.

Для native особенно важно не полагаться только на браузерный пиксель. Mobile-трафик, in-app и агрессивные браузерные ограничения часто дают дырки в атрибуции. Если видите, что лиды есть, а postback пустой, первым делом смотрите не креатив, а маршрут данных.

Нормальная схема выглядит так: source → tracker → lander → form → server postback. Если хотя бы один параметр не переживает редирект, CAPI превращается в красивую витрину без учета.

Мой чек: один клик — один идентификатор — одно серверное событие. Всё остальное уже украшения.