Піксель і CAPI в Telegram-воронках: як передати події з бота в рекламний кабінет

Щоб реклама на Telegram-бота окупалась, рекламний кабінет Meta має бачити не кліки, а результати: хто з реклами дійшов до заявки, бронювання, оплати. Проблема в тому, що всередині Telegram браузера немає, тому звичайний піксель там не працює — події з бота можна передати тільки сервером, через Conversions API (CAPI). У цій статті розберемо простими словами, що таке піксель і CAPI, чому браузерного трекінгу недостатньо навіть на лендингу, скільки конверсій губиться без серверного каналу і як налаштувати зв’язку «оголошення → бот → покупка», щоб рекламний бюджет працював на покупців, а не на клікерів.

Піксель Meta — це маленький шматок коду, який ставиться на сайт чи лендинг. Він робить дві речі: запам’ятовує, що конкретна людина прийшла з конкретного оголошення, і повідомляє рекламному кабінету, що ця людина зробила на сторінці — подивилась, натиснула кнопку, залишила заявку.

Навіщо це кабінету? Алгоритм Meta оптимізує рекламу на ту подію, яку ви йому віддаєте. Якщо він бачить лише кліки — він приводить «клікерів»: людей, які охоче натискають на оголошення, але нічого не купують. Якщо він бачить покупки — він шукає людей, схожих на ваших покупців. Той самий бюджет, ті самі креативи, але зовсім інша якість трафіку і зовсім інша ціна клієнта.

Тому золоте правило платного трафіку: кабінет має отримувати ту подію, за яку ви насправді платите. Для школи це оплата курсу, для експерта — бронювання консультації, для магазину — покупка.

У класичній схемі «реклама → сайт → покупка на сайті» піксель бачить весь шлях. У воронці на Telegram шлях інший:

оголошення → лендинг → кнопка «Перейти в Telegram» → бот → заявка чи анкета в чаті → оплата → (часто ще) вебінар.

Все цінне тут відбувається після переходу в Telegram. А щойно людина натиснула кнопку — піксель осліп: у месенджері немає браузера, немає cookie, немає JavaScript. Заявка в чаті, оплата через бота, прихід на вебінар — для рекламного кабінета все це тиша. Він чесно звітує: «100 кліків, 0 конверсій» — і оптимізує далі на кліки.

Завдання трекінгу в Telegram-воронці — повернути ці події в кабінет і «зшити» кожну з конкретним кліком по конкретному оголошенню.

Браузерний піксель втрачає події не лише в месенджері. Три «діри», через які витікають конверсії ще на рівні сторінок:

Блокувальники реклами. За галузевими даними, близько 30% користувачів інтернету користуються блокувальниками принаймні на одному пристрої, і більша частина цього — саме мобільні. Блокувальник вирізає код пікселя ще до завантаження: для Meta цих людей не існує, хоча вони бачили рекламу, кликали і купували.

iOS і App Tracking Transparency. Із 2021 року Apple питає власника iPhone, чи дозволяє він застосункам відстежувати себе. Більшість відповідає «ні»: за різними оцінками, дозвіл дають лише 25–35% користувачів iOS. Для решти браузерний трекінг різко деградує — за оцінками сервісів аналітики, піксель самотужки не бачить від третини до половини iOS-конверсій.

In-app браузер Instagram. Якщо ви крутите рекламу в Instagram — а для Telegram-воронок це поширений канал — ваша аудиторія сидить з телефона. Клік по оголошенню відкривається не в Safari чи Chrome, а у вбудованому браузері самого застосунку. Там своє, урізане середовище: cookie живуть коротко, частина скриптів обмежена. Це і є та «похибка браузерного пікселя», через яку кабінет бачить менше конверсій, ніж є насправді, — і через яку оптимізація працює наосліп.

Висновок з цих трьох пунктів один: браузерний піксель сам по собі — це неповна картина. Навіть без Telegram. А з Telegram — тим більше.

Conversions API (CAPI) — це серверний канал передачі подій: конверсію в Meta надсилає не браузер відвідувача, а сервер вашого сервісу, напряму. Серверу байдуже, який у людини телефон, чи стоїть блокувальник і чи є взагалі браузер. Бот отримав оплату на 100 € — подія «Purchase, 100 €» тієї ж миті йде в рекламний кабінет.

Правильна схема — не «або піксель, або CAPI», а обидва одночасно:

Канали доповнюють один одного: піксель дає Meta сигнали зі сторінок (перегляди, поведінка), CAPI — надійну доставку ключових конверсій.

А не порахується двічі? Ні. Коли та сама подія йде обома каналами (сторінка «дякую» міні-лендингу, вебінарна кімната, оплата на їхньому чекауті), обидві копії несуть однаковий event_id. Meta бачить збіг і рахує одну конверсію — це стандартний механізм дедуплікації. Важлива лише одна умова: браузер і сервер мають слати в один і той самий піксель, інакше кабінет побачить дві різні покупки у двох різних наборах даних. Події з бота йдуть лише сервером, тож дубліката для них немає.

Сама по собі серверна подія «хтось купив» кабінету мало що дає — треба знати, хто купив і з якої кампанії прийшов. Це вирішується у два кроки.

Крок перший — упіймати клік. У момент, коли людина на лендингу натискає кнопку «Перейти в Telegram», зберігаються мітки: fbclid (ідентифікатор кліку, який Meta додає до адреси), _fbp/_fbc (cookie пікселя), utm-мітки кампанії. Вони лягають під короткий код, і саме цей код їде в Telegram у посиланні старту. Код діє 14 днів і спрацьовує один раз: перешлеш посилання подрузі — чужі мітки їй не запишуться. У момент старту воронки мітки записуються в поля контакта — і далі їдуть разом з кожною подією цієї людини.

Крок другий — матчинг. Разом з подією сервер передає Meta хешовані email, телефон, ім’я та прізвище, якщо воронка їх зібрала (хешовані — означає перетворені на відбиток, з якого не можна відновити оригінал; Meta лише звіряє відбитки зі своїми), а також мітки кліку й внутрішній ідентифікатор контакта. Email і телефон беруться з полів контакта, назва яких містить «email»/«пошта»/«мейл» та «phone»/«телефон» — назвіть так свої поля. Що більше збігів — то впевненіше Meta прив’язує конверсію до користувача й оголошення. В Events Manager це видно як «якість зіставлення» (event match quality): що більше даних збирає воронка, то вищий бал.

Результат подвійний. У рекламному кабінеті — справжня вартість покупця по кожній кампанії, і алгоритм, який вчиться на покупцях. У Sviteya — джерело трафіку в картці кожного контакта: видно, що Марія прийшла з кампанії «вебінар-серпень», а Олег — з посту в каналі.

Подивимось на весь ланцюжок очима однієї людини.

1. Ірина гортає Instagram з iPhone і бачить рекламу безплатного вебінару. У неї стоїть iOS зі забороною трекінгу — для браузерного пікселя вона майже невидима.
2. Клік по оголошенню відкриває лендинг школи в in-app браузері. Сніпет трекінгу на лендингу ловить fbclid і utm-мітки.
3. Ірина натискає «Зареєструватися в Telegram». Разом з нею у бот «заходять» усі мітки кліку — вони записуються в поля її контакта.
4. Бот реєструє її на вебінар (дія «Зареєструвати на вебінар»). Одразу після неї у воронці стоїть дія «подія в Meta CAPI» → CompleteRegistration. Подія летить у кабінет сервером — блокування трекінгу на її телефоні вже нічого не вирішує.
5. Після вебінару Ірина оплачує курс через бота. Оплата запускає воронку з тригером «Оплата товару», у якій стоїть дія «подія в Meta CAPI» → Purchase із сумою.
6. У рекламному кабінеті школи кампанія «вебінар-серпень» показує: стільки реєстрацій, стільки покупок, ось вартість покупця. Алгоритм отримує сигнал «шукай схожих на Ірину». У Sviteya в картці Ірини — джерело, кампанія, вся історія подій.

Без CAPI цей ланцюжок обірвався б на кроці 3, і кабінет вважав би кампанію збитковою — хоча вона привела покупця.

Повна покрокова інструкція з усіма кнопками — на сторінці документації «Піксель Meta і Conversions API». Тут — логіка процесу, щоб було зрозуміло, з чого він складається. Підключення пікселя й CAPI доступне на платних тарифах і на пробному; на тарифі Free воно недоступне.

1. Підключення. В Meta Events Manager берете два рядки: Pixel ID (номер пікселя) і токен Conversions API (Налаштування → Conversions API → Generate access token). Вставляєте обидва у Sviteya: Інтеграції → Трекінг реклами (Meta), де ще треба дати підключенню назву (наприклад, «Школа»). Обидва поля обов’язкові: без токена сервер не має права надсилати події у ваш піксель, а з Telegram події йдуть лише сервером. Sviteya одразу перевіряє, що токен має доступ до пікселя, і якщо ні — покаже помилку.

2. Сторінка входу. Два варіанти, залежно від того, де живе лендинг:

• Лендинг на конструкторі (WordPress, Webflow тощо) — додаєте на сторінку один рядок коду (сніпет трекінгу) і ставите на кнопку «Перейти в Telegram» «Посилання зі змінними» з тригера «Реф-посилання». Сніпет ловить мітки кліку і передає їх у бот разом з людиною.
• Міні-лендинг чи сторінка реєстрації на вебінар у Sviteya — коду не треба взагалі: у налаштуваннях сторінки обираєте піксель зі списку, браузерний код і серверні події сервіс додає сам (блок «Піксель цього лендинга»: PageView, Lead, Purchase).

3. Події у воронці. На кроках, де стається результат, ставите в блоці «Дії» дію «подія в Meta CAPI»: Lead після анкети, Schedule після бронювання, Purchase із сумою після оплати (суму можна підставити змінною — скільки людина реально заплатила, стільки й піде в кабінет), CompleteRegistration після реєстрації на вебінар — або свою назву події.

4. Перевірка. Проходите шлях як клієнт: лендинг з тестовими мітками → кнопка → бот → крок з CAPI-дією. Дивитесь у два місця: в журналі подій контакта у Sviteya мають з’явитися записи «клік з реклами» і «подію надіслано в Meta», а в Events Manager — сама подія (вкладка Test events показує їх у реальному часі, в Overview вони з’являються за кілька хвилин).

Якщо пікселів кілька — різні проєкти, різні рекламні кабінети — підключень теж може бути кілька, а потрібний обирається там, де подія народжується: у ноді воронки, в налаштуваннях вебінару чи лендинга. Якщо пікселів кілька, а вибір не зроблено, подія не надсилається — краще нічого, ніж у чужий піксель.

Підключити тільки Pixel ID, без токена. Найчастіша. Виглядає, ніби все налаштовано, але події з бота не йдуть — серверу нічим підтвердити право писати у ваш піксель.

Забути сніпет на лендингу. CAPI-події доходитимуть, але «сирітками»: без fbclid їх нема з чим зшити, атрибуція до кампанії губиться, і кабінет не розуміє, яке оголошення привело покупця.

Звичайне посилання на бота замість трекінгового. Кнопка веде на t.me/… напряму — людина в боті, а мітки лишились на лендингу. Посилання для кнопки треба брати з тригера воронки.

Браузер і сервер шлють у різні пікселі. Дедуплікація працює лише в межах одного пікселя. Якщо на сторінці вибраний один, а у воронці інший — Meta бачить дві різні події, і статистика задвоюється.

Оптимізація кампанії на клік, коли вже є події. Налаштували передачу Purchase, а кампанія досі оптимізується на трафік. Події в кабінеті — це пів справи; ціль кампанії треба перемкнути на конверсію.

Токен, що перестав діяти. Meta інколи відкликає токени (зміна прав у Business Manager, зміна власника пікселя). Симптом: усе працювало — і перестало. Ліки: згенерувати новий токен і підключити піксель ще раз із тим самим Pixel ID — токен наявного підключення оновиться.

Що таке CAPI простими словами?

Це спосіб передати конверсію в Meta напряму з сервера, минаючи браузер. Браузерний піксель каже «я бачив, що людина щось зробила на сторінці», CAPI каже «сервіс підтверджує: ця людина купила». Другий канал надійніший, бо на нього не впливають блокувальники, налаштування телефона і відсутність браузера в Telegram.

Чи можна обійтися без CAPI, якщо на лендингу вже стоїть піксель?

Ні. Піксель на лендингу бачить лише візит і клік по кнопці. Заявка й оплата стаються в боті, де браузера немає, — без CAPI ці події в кабінет не потраплять, і Meta оптимізуватиме рекламу на кліки, а не на гроші.

Події з пікселя і CAPI не задвояться?

Ні, якщо обидва канали надсилають подію з однаковим event_id — Meta автоматично склеює дублікати. На сторінках Sviteya (міні-лендинги, вебінарна кімната, їхній чекаут) це працює з коробки; важливо лише, щоб браузер і сервер слали в один і той самий піксель.

Реклама йде в Instagram. Це щось міняє?

Так, це якраз головний аргумент за CAPI: in-app браузер Instagram + iOS з забороною трекінгу + блокувальники з’їдають помітну частину браузерних подій. Серверний канал цих втрат не має.

Які події передавати?

Мінімум — та подія, за яку ви платите: Purchase із сумою. Добра практика — ще одна-дві проміжні (Lead, Schedule чи CompleteRegistration), щоб кампанії на верхніх етапах воронки теж мали на що оптимізуватись.

Що таке «якість зіставлення» і яка вона має бути?

Це оцінка Meta, наскільки впевнено вона прив’язує ваші серверні події до своїх користувачів (залежить від кількості переданих даних: fbclid, email, телефон). Видно в Events Manager біля кожної події. Що більше даних збирає воронка, то вищий бал.

Скільки пікселів можна підключити?

Скільки завгодно — під різні проєкти чи рекламні кабінети. Потрібний обирається в налаштуваннях воронки, вебінару чи лендинга. Якщо піксель один, обирати нічого не треба.

Що з UTM-мітками?

Вони зберігаються паралельно з fbclid у полях контакта і працюють для всіх джерел трафіку, не лише Meta — Telegram Ads, посіви в каналах, YouTube. Як побудувати на них звіт «звідки приходять покупці, а не підписники» — у гіді «Наскрізна аналітика в Telegram».

Джерела цифр: частка користувачів блокувальників ~30% — Backlinko, Ad Blocker Usage 2026; опт-ін ATT 25–35% і втрати iOS-конверсій піксельним трекінгом 30–60% — огляди Cometly і TrueROAS. Це галузеві оцінки, вони змінюються.