Доставка конверсій: перевіряємо, що кожна конверсія дійшла до Meta, Google і трекера

За клік ви вже заплатили. Якщо депозит, який він приніс, так і не долетів до Meta чи Google, оптимізатор платформи так і продовжує закуповувати схожих на тих, хто не конвертиться. А якщо впаде S2S-постбек у ваш партнерський трекер, конверсії не буде і у вашій власній статистиці. Сторінка «Доставка конверсій» - єдиний екран, що відповідає на питання «чи дійшла кожна конверсія насправді»: картки CAPI по кожній платформі, картки постбеків по кожному правилу, таблиця всього застряглого і кнопка «Повторно надіслати» для ручного відновлення.

Як читати картки

Угорі сторінки - по картці на кожну CAPI-платформу: Meta, Google і TikTok, усі три надсилають серверно. Нижче - по картці на кожне правило постбеку, за яким була хоча б одна доставка за останні 7 днів. CAPI-платформа може показати картку і з нульовими доставками: картку заводить будь-який із трьох слідів за вікно - доставка, пропуск або сам клік, віднесений до цієї платформи. Слідом вважається клік по активній кампанії: по кампанії на паузі, у чернетці чи в архіві клік теж пишеться, але картки не заводить, навіть якщо ви за нього заплатили. Платформу кліку проставляє його ідентифікатор - fbclid дає Meta, gclid, gbraid чи wbraid дають Google, ttclid дає TikTok, - а коли ідентифікатора немає зовсім, платформа береться з інтеграцій кампанії в тому ж порядку: Meta, потім Google, потім TikTok. Кампанії, у якої немає жодної інтеграції, клік записується як Meta, тому картка Meta може з'явитися і там, де Meta не запускали. Пропуски пояснює блок «Пропущено», про нього нижче.

Кожна картка рахує доставки у двох вікнах, «24 год» і «7 дн», за п'ятьма статусами:

• Відправлено - платформа або трекер прийняли конверсію. Готово.
• У черзі - доставка чекає, воркер підхопить її за секунди.
• Збої - рядки, у яких спроба завершилася помилкою. У CAPI до 5 спроб з експоненційною затримкою (паузи 5с, 10с, 20с і 40с - 75 секунд на весь ланцюжок); у постбеку до 3 спроб, і він укладається в секунди. Збійний рядок часто сам доїжджає до «Відправлено» ще в цьому вікні. Коли падає остання спроба, рядок автоматично стає «Мертва» - без cron-джоби і без ручних дій.
• Мертві - усі автоматичні спроби вичерпано. Далі без вас нічого не станеться.
• Придушено - доставку затримала дедуплікація за користувачем: у кампанії (для CAPI) або в правила постбеку увімкнено режим, за якого на одну людину йде одна конверсія. Це чесний термінальний статус, а не збій: такі рядки не ретраяться і не стають мертвими. У таблиці нижче вони лежать під окремим фільтром «Придушені», і кнопки «Повторно надіслати» в них немає - ручний повтор обійшов би сам дедуп.

Бейдж працює як світлофор: «Без проблем», коли проблем немає, «Є збої» (жовтий), якщо щось впало, «Є мертві» (червоний), якщо хоча б одна доставка загинула. На кожній картці також видно текст останньої помилки з таймстампом - зазвичай цього достатньо, щоб впізнати протухлий токен, не відкриваючи логи.

У картки будь-якої CAPI-платформи є ще один блок - «Пропущено (не надіслано)». Він з'являється, щойно за вікно набрався хоча б один пропуск, і показує лічильники «Сьогодні» і «7 дн» з розбивкою за причиною: «Майданчик не підключено», «Немає CAPI-акаунта для пікселя», рядок про click ID, «Клік застарів» і «Подію не зіставлено». Рядок про click ID підписує майданчик тієї картки, на якій він стоїть, бо ідентифікатор у кожного майданчика свій: «Немає Google click ID (gclid)» у Google, «Немає TikTok click ID (ttclid)» у TikTok і нейтральне «Немає click ID» на картці майданчика, який цієї причини не пише взагалі. Повідомляють її рівно два адаптери - Google пропускає клік без gclid/gbraid/wbraid, TikTok - клік без ttclid, - а «Клік застарів» належить одному Google (клік, старший за 89 днів, доба запасу під 90-денним вікном завантаження), тому на картці Meta обидва рядки завжди нулі. Третя, «Подію не зіставлено», спільна для платформ: її пише диспетчер, коли типу події немає в мапінгу платформи і назву події не задано вручну, тож на картці Meta цей рядок цілком може бути ненульовим. Найперший рядок, «Майданчик не підключено», відповідає на питання раніше за всі інші: у кампанії немає ключа цього майданчика в інтеграціях узагалі, тобто налаштування не починали. Так виглядає запуск трафіку до прив'язки пікселя - кліки йдуть, подій у майданчик не надходить жодної, а до появи цього лічильника такі події не лишали взагалі жодного сліду: ні рядка доставки, ні помилки, ні запису в журналі. Відрізняйте його від наступного рядка: там налаштування почали і не закінчили, і лагодиться воно звіркою ідентифікаторів, а не прив'язкою пікселя. Рядок «Немає CAPI-акаунта для пікселя» стоїть другим не випадково: інші причини відтинають частину трафіку, а ця означає, що в організації немає CAPI-акаунта з тим pixel ID, який записано в інтеграції кампанії, - до майданчика не доходить жодна конверсія цієї кампанії. Найчастіше піксель змінили в одному місці й не змінили в іншому. Ненульове значення тут - привід звірити pixel ID кампанії з тим, що стоїть у CAPI-акаунті, перш ніж розбиратися з чимось іншим. Пропуск - це свідома відмова від відправлення, а не збій: він взагалі не створює рядок доставки і ніколи не потрапляє ні в лічильники збійних чи мертвих, ні в таблицю нижче. Це і є пряма відповідь на питання, чому на змішаній кампанії Meta+Google конверсій по Google помітно менше, ніж по Meta - спершу загляньте в цей блок, перш ніж вважати щось зламаним.

Таблиця проблемних доставок

Під картками - таблиця з пагінацією і двома рядами перемикачів. Верхній обирає, що показувати: «Збійні / мертві» (відкритий за замовчуванням) або «Придушені». Нижній - канал: CAPI і Постбеки. На вкладці CAPI - платформа, Event ID, статус, кількість спроб, помилка і час створення. На вкладці «Постбеки» додаються HTTP-метод і код статусу, який повернув endpoint вашого трекера. 500 від трекера і мережевий таймаут дебажаться зовсім по-різному.

Повторне відправлення: що воно справді робить

1. Спершу усуньте причину: оновіть access token Meta, поверніть доступ сервісному акаунту Google, знову увімкніть правило постбеку.
2. Натисніть «Повторно надіслати» на рядку. Кнопка зміниться на «У черзі»: нова спроба доставки йде через звичайну чергу з повним ланцюжком ретраїв. У CAPI йде той самий payload, а постбек вирушає на поточну ціль правила - адресу і метод беруть із самого правила, а не зі знімка старої доставки, тож виправлена адреса підхоплюється одразу. Якщо ціль відтоді змінилася, екран скаже про це просто на рядку.
3. Доставка асинхронна, але тиснути F5 не потрібно: екран перечитує себе сам - таблиця проблемних доставок раз на пів хвилини, картки раз на хвилину. Якщо повторне відправлення спрацювало, рядок сам стане «Відправлено» і зникне зі списку. На фоновій вкладці опитування зупиняється і робить позачерговий запит саме тоді, коли ви на неї повернулися, а невдалий запит не стирає вже показані цифри - на екрані лишається остання вдала відповідь.
4. Якщо рядок не зрушив хвилини за дві, кнопка знову стає натискною. Це не забутий екраном клік: черга заявку прийняла, а обробити її ніхто так і не обробив, тож натиснути ще раз - правильна дія. Якщо рядок повертається до вас так раз за разом, дивитися треба на воркер, а не на рядок.

Повторне відправлення чесно відмовляє, а не вдає, що спрацювало. Повторити можна лише збійні та мертві рядки. Якщо ви прибрали піксель з кампанії, отримаєте «Платформу більше не налаштовано на кампанії»: постановка в чергу все одно закінчилася б ще одним мертвим рядком. Відмова дивиться лише на кампанію: якщо піксель у ній лишився, а сам CAPI-акаунт видалено, повторне відправлення приймається, площадка мовчки пропускається, і рядок лишається мертвим. «Подія не тарифікована» - захисна відмова: у події статус білінгу не «списано» і не «безкоштовно», тож повтор усе одно нічого б не надіслав. Постбек відмовляє так само, якщо правило видалене чи вимкнене: ручний повтор не може непомітно обійти правило, яке ви самі вимкнули.

Захист від задвоєння: повторне відправлення постбеку використовує той самий fire ID, що й оригінал - якщо перша спроба реально дійшла до трекера, повтор гаситься ще до HTTP-запиту. Гасять його два сторожі: відмітка в Redis про здійснене надсилання (живе 24 години) і довговічний рядок «Відправлено» в журналі доставок. Обидва читаються на пропуск - коли сховище цієї миті не відповіло, доставка не скасовується, а йде повторно, тому обіцянка чесно звучить як «щонайменше один раз», і приймач на вашому боці зобов'язаний дедуплікувати сам. У CAPI своя дедуплікація, за event ID на стороні платформи: у Meta вікно приблизно 48 годин, тож повторне відправлення значно старіших рядків може задвоїти конверсії в Ads Manager.

Коли хвилюватися, а коли ні

• Хвилюватися варто, коли «Мертві» більше нуля або повторюється та сама остання помилка: протухлий access token, відкликаний доступ сервісного акаунта, неправильний dataset або ID conversion action.
• Не хвилюватися варто, якщо на змішаному трафіку Google показує менше конверсій, ніж Meta. У конверсії, що прийшла з оголошення Meta, немає gclid, тому Google свідомо її пропускає, а не падає з помилкою - точну причину і лічильник дивіться в блоці «Пропущено» на картці Google. Ще Google пропускає кліки, старші за 89 днів - доба запасу під його 90-денним вікном завантаження.

Лист, коли доставка починає сипатися

До попереднього розділу є заперечення: він працює, лише поки екран у вас відкритий. Тому в збою з'явився другий канал. Якщо за годину в організації набралося десять і більше доставок у статусах «Збої» та «Мертві» - CAPI і постбеки рахуються разом, однією сумою, - власникам організації йде лист. У ньому та сама цифра, вікно, за яке її пораховано, розбивка за каналами і посилання просто на цей екран.

Рахуються доставки, створені за останню годину і такі, що лишилися збійними або мертвими на момент перевірки; перевірка йде раз на п'ятнадцять хвилин. Поріг у десять дібрано так, щоб поодинокий 5xx платформи або ретрай, який пройшов із другої спроби, листа не породжували: до десятки за годину дотягує зламана конфігурація, а не разове моргання мережі.

Один лист на організацію за шість годин - не частіше. Збій доставки це стан, а не подія: доки протухлий токен не замінили, кожна наступна перевірка бачить ті самі збійні рядки, і без цього обмеження одна поломка перетворилася б на розсилку.

Вимикається у двох місцях, і це різні рівні. Налаштування → Сповіщення - перемикач на всю організацію; змінювати його може лише власник, бо діє він на всіх власників одразу. Там же нижче, у налаштуваннях сповіщень, - особиста галочка «Сповіщення про збої доставки (CAPI і постбеки)»: вона знімає листи лише з вас і решти власників не чіпає.

Типові граблі

• Повторне відправлення без усунення причини просто плодить нові мертві рядки: кнопка повторює відправлення, а не лагодить конфігурацію.
• Рядки Meta, старші за приблизно 48 годин, ризиковано повторювати - дедуплікація вендора їх уже не прикриває.
• Конверсію, заблоковану білінгом (організація на паузі, вичерпаний овердрафт), у цій таблиці шукати марно: рядка доставки для неї не створюється взагалі - вона потрапляє в картку «Втрачено через білінг» на цьому ж екрані. Досилати руками нічого не треба: після поповнення балансу такі події йдуть самі - одразу при зарахуванні, а хвіст підбирає щогодинний прохід, - але лише поки конверсії не старші за шість діб.
• Картка Google з нулем доставок на трафіку, де переважає Meta, - це норма, а не поломка. Причину пояснює блок «Пропущено» на цій картці.
• Порожнє місце замість картки TikTok - це не «доставку ще не запустили»: серверна доставка в TikTok жива так само, як у Meta і Google. Картку заводить будь-який слід платформи за вікно - доставка, пропуск або клік, віднесений до TikTok, - тож її відсутність означає рівно одне: до TikTok за вікно не віднесли жодного кліка. Це не те саме, що «трафіку з TikTok не було»: клік із TikTok, що прийшов без ttclid на кампанію, де в інтеграціях є Meta чи Google, записується на ту платформу і потрапляє в її картку. Картка з нулем доставок - інший випадок, і його пояснює блок «Пропущено» на ній же: «Майданчик не підключено», якщо кампанія про TikTok не знає, або «Немає TikTok click ID (ttclid)», якщо підключення є, а мітки в кліках немає.