• Meta Ads · Meta Pixel
  • Вимір 31.07.2026

Meta Pixel і Conversions API: щоб події доходили повністю

Налаштування Meta Pixel і Conversions API — це дві половини одного вимірювання: браузер шле подію з телефона покупця, сервер — з вашого боку, і обидві мають нести спільний ідентифікатор події. Без нього купівля рахується двічі, і кабінет показує більше замовлень, ніж бачить ваша бухгалтерія. Деталь, через яку серверний канал часто працює гірше за очікуване: подія з сервера без cookie _fbp і _fbc, знятих у браузері, приходить майже без даних для зіставлення — склеїти її з людиною системі нема за чим.

Подивитись, як це працює
Вартість
після безкоштовного аудиту
Гарантія
30 днів після підписання акта
Два канали однієї події
браузерний піксел і серверний Conversions API; зводить їх спільний ідентифікатор події
Вартість
після безкоштовного аудиту
Гарантія
30
днів після підписання акта
Два канали однієї події
браузерний піксел і серверний Conversions API; зводить їх спільний ідентифікатор події
Строк робіт
3–12
робочих днів — залежить від способу передачі серверних подій
Перед кошторисом
безкоштовна перевірка того, що передається зараз: 2–3 робочих дні
Типова знахідка
у магазині засобів самооборони піксел Meta був єдиним лічильником на сайті — вимір 31.07.2026
Що міряємо після впровадження
частку подій із серверного каналу, оцінку якості зіставлення, розбіжність із обліковою системою
Чого не обіцяємо
зростання цифр у кабінеті: після дедуплікації вони частіше падають, бо перестають рахувати купівлю двічі
Етапи роботи

Прозорі етапи з погодженням на кожному кроці

Загальний строк:3–12 днів

  1. Безкоштовна перевірка передачі подій

    2–3 робочих дні, до кошторису

    Дивимось, скільки пікселів на сторінці, які події доходять, чи є серверний канал і чи не рахується купівля двічі. На виході — карта подій і рекомендований спосіб передачі для вашої платформи.

  2. Браузерні події: ревізія й повний ланцюжок

    1–3 робочих дні

    Прибираємо дублі й зайві джерела, добираємо події, яких бракує, дописуємо параметри товару, суму й валюту. Тут же фіксуємо, як генерується ідентифікатор події.

  3. Серверний канал і дедуплікація

    1–5 робочих днів

    Піднімаємо передачу через Conversions API обраним способом, переносимо _fbp і _fbc з браузера, зводимо обидва канали за спільним ідентифікатором. Спершу вмикаємо одну подію — купівлю.

  4. Тестові події, звірка й документ

    1–4 робочих дні

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

  5. Тиждень спостереження за якістю зіставлення

    7 календарних днів, робочих днів не забирає

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

Технології та інтеграції

На чому будуємо і з чим це з'єднується

Стек

  • Meta Pixel — браузерний канал. Ставиться швидко, але частину подій не побачить ніколи: блокувальники й обмеження браузерів на cookie
  • Conversions API — серверний канал. Закриває прогалини браузера, проте без _fbp і _fbc, знятих у браузері, якість зіставлення падає
  • Диспетчер подій і тестові події — єдине місце, де видно, що дійсно прийшло. Оцінка якості зіставлення там приблизна, це не метрика точності
  • Google Tag Manager — збирає браузерні події без релізу сайту. Купівлю з нього шлемо неохоче: сторінка подяки не є доказом оплати
  • Серверний контейнер тегів — один канал одразу на кілька систем. Це окремий хостинг, який хтось має оплачувати й оновлювати
  • Обробник на бекенді — найточніше джерело: подія йде тоді, коли замовлення справді створене. Потрібен доступ до коду й черга розробника

Інтеграції

  • Meta Ads Manager
  • диспетчер подій Meta
  • Google Tag Manager
  • серверний контейнер тегів
  • CRM або облікова система
  • банер згоди
Що входить

Повний перелік робіт і того, що ви отримуєте на виході

  • Ревізія піксела: один ідентифікатор на сайт замість двох-трьох, що лишились від різних підрядників — інакше події діляться між кабінетами
  • Повний ланцюжок стандартних подій — перегляд товару, кошик, початок оформлення, купівля: видно, на якому кроці губиться покупець
  • Параметри товару, сума й валюта в події купівлі — без них у звіті лишається кількість, але не віддача з реклами
  • Серверна передача через Conversions API з вашого боку: подія доходить і тоді, коли браузер її не відправив
  • Спільний ідентифікатор події для обох каналів і перенесення _fbp та _fbc на сервер — купівля рахується один раз і має за чим зіставитись
  • Узгодження подій із банером згоди: відмова людини зупиняє передачу, а не лише запис cookie
  • Тестові події й прогін реального замовлення від кошика до підтвердження — перевіряємо, що приходить, а не що мало б приходити
  • Звірка купівель у кабінеті з замовленнями у вашій обліковій системі за той самий період
  • Перевірка оцінки якості зіставлення в диспетчері подій через тиждень роботи, коли набереться статистика
  • Схема подій одним документом: назви, параметри, звідки береться кожне значення — щоб її підтримували без нас
  • Гарантія 30 календарних днів на виконані роботи
Коли ця послуга не підходить

Що не входить у роботу — щоб не було сюрпризів на здачі

  • Ведення рекламних кампаній
  • Передача персональних даних без вашої письмової згоди й правової підстави
  • Обхід відмови користувача від відстеження
  • Налаштування аналітики Google — це суміжна послуга
  • Юридичне оформлення політики приватності
Кому підходить

Ситуації, у яких ця послуга дає результат

Сценарій 1 із 5

Ведете рекламу в Meta й ніколи не звіряли кабінет з обліковою системою

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

Розберемо вашу ситуацію на безкоштовному аудиті
Тільки браузерний піксел проти піксела разом із серверним каналом

Чим цей варіант відрізняється від альтернативи

Тільки браузерний пікселНаш підхід
Що з подією при блокувальникуподії немає взагалі, замовлення для кабінету не існуєбраузерна не пішла, серверна пішла — купівля порахована один раз
Звідки відомо, що замовлення справжнєподію шле сторінка подяки, а її можна перезавантажити п'ять разівподію шле бекенд у момент створення замовлення
Ризик подвійного облікунемає: канал один, натомість тут недолік данихє — саме тому спільний ідентифікатор події обов'язковий, а не бажаний
Що потрібно від васдоступ до сайту або до диспетчера тегівдоступ до бекенда або серверного контейнера й рішення щодо параметрів
Скільки коштує підтримуватинічого понад сам сайтсерверний контейнер — окремий хостинг; обробник — час розробника при змінах у чекауті
Безкоштовний аудит

Безкоштовна перевірка передачі подій у Meta

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

Що ми міряємо

  1. Чи стоїть піксел і чи він одинДва піксели на сторінці — не рідкість після зміни підрядника. У виміряній нами вибірці траплялись сайти, де Meta Pixel був єдиним лічильником узагалі, без будь-якої іншої аналітики.
  2. Повнота ланцюжка подійПерегляд товару, додавання в кошик, початок оформлення, купівля. Найчастіше бракує саме середини, і воронка стає непридатною до аналізу.
  3. Передача вартості замовленняБез суми й валюти в події купівлі неможливо порахувати віддачу з реклами — лишається тільки кількість.
  4. Наявність серверного каналуЧи передаються події з вашого боку, а не лише з браузера. Браузерні події частково не доходять через блокувальники й налаштування приватності.
  5. ДедуплікаціяЯкщо ту саму купівлю шле і браузер, і сервер без спільного ідентифікатора події, вона порахується двічі. Це найтихіший з усіх дефектів: цифри стають кращими.
  6. Стан згоди на збір данихЯкщо на сайті є банер згоди, події мають підкорятись вибору користувача. Перевіряємо, чи так це зараз.

Що ви отримуєте

  • Карту подій: що передається зараз, звідки і з якими параметрами.
  • Перелік втрачених і задвоєних подій.
  • Рекомендований спосіб передачі серверних подій саме для вашої платформи.
  • Розмову на 30 хвилин по документу.

Строк: 2–3 робочих дні

Чому це безкоштовно

Бо подвійний облік робить звіти красивішими, і його майже ніколи не шукають самі. Дешевше показати це безкоштовно, ніж потім пояснювати, чому цифри в кабінеті вдвічі більші за реальні замовлення.

Що далі

Даємо кошторис на впровадження обраного способу передачі, дедуплікацію й перевірку якості даних.

Коротка форма: контакт і адреса сайту

Не знайшли свій випадок?

Опишіть, як це влаштовано у вас, — відповімо, чи підходить «Meta Pixel і Conversions API» і що це означає у вашій ситуації. Без брифу й без дзвінка: одне питання, одна відповідь.

Договір і документи

Працюємо офіційно

Договір, акт і рахунок — на кожен проєкт, а не тільки на великий. Без документів у вас немає ні прав на роботу, ні підстави провести витрати.

Нам довіряють6 брендів

Нам довіряють: Kvant Energy, GYPSUN, Naturel Cosmetics, Pancer Protection, LUGI, BeeTech

Умови, зафіксовані письмово8 пунктів

  • Договір, акт і гарантія 30 днів

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

  • ФОП і безготівковий розрахунок

    Виконавець — зареєстрований ФОП. Оплата на рахунок із закривними документами.

  • Права й доступи — ваші

    Код, дизайн і матеріали переходять до вас після повної оплати. Домен, хостинг, репозиторій, аналітику оформлюємо на вас.

  • Портал клієнта замість переписки

    На час роботи ви отримуєте доступ до порталу: договори, рахунки, акти й стан проєкту в одному місці.

  • Сайти в дев'яти країнах

    Наші сайти працюють у дев'яти країнах: крім України — Польща, Німеччина, Австрія, Англія, Норвегія, Болгарія, Молдова, Іспанія.

  • Цифри, які можна перевірити

    Кожен кейс у портфоліо — з посиланням на живий сайт і технічним виміром.

  • Спершу аудит, потім сума

    Прайсу на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази.

  • Кажемо «ні», коли не впевнені

    Якщо задача не наша або строк нереальний — скажемо одразу.

  • Договір, акт і гарантія 30 днів

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

  • ФОП і безготівковий розрахунок

    Виконавець — зареєстрований ФОП. Оплата на рахунок із закривними документами.

  • Права й доступи — ваші

    Код, дизайн і матеріали переходять до вас після повної оплати. Домен, хостинг, репозиторій, аналітику оформлюємо на вас.

  • Портал клієнта замість переписки

    На час роботи ви отримуєте доступ до порталу: договори, рахунки, акти й стан проєкту в одному місці.

  • Сайти в дев'яти країнах

    Наші сайти працюють у дев'яти країнах: крім України — Польща, Німеччина, Австрія, Англія, Норвегія, Болгарія, Молдова, Іспанія.

  • Цифри, які можна перевірити

    Кожен кейс у портфоліо — з посиланням на живий сайт і технічним виміром.

  • Спершу аудит, потім сума

    Прайсу на сайті немає навмисно: обсяг тієї самої роботи у двох клієнтів відрізняється в рази.

  • Кажемо «ні», коли не впевнені

    Якщо задача не наша або строк нереальний — скажемо одразу.

NDA підписуємо на запит. Після завершення співпраці наші доступи до ваших сервісів видаляємо самі.

Що впливає на вартість

Чому дві однакові на вигляд задачі рахуються по-різному

  • Спосіб передачі серверних подійГотова інтеграція платформи — кілька днів. Серверний контейнер тегів — це ще й окремий хостинг, який комусь треба оплачувати й оновлювати. Власний обробник на бекенді дає найточніші дані й забирає найбільше часу. Тут і сидить різниця між нижньою та верхньою межею.
  • Скільки подій зводимоОдна купівля — це один ідентифікатор і одна звірка. Повний ланцюжок від перегляду до оформлення — чотири події, у кожної свої параметри товару, і кожну треба перевірити окремо в обох каналах.
  • Що вже стоїть на сайтіЧистий сайт налаштувати швидше, ніж розібрати спадок. Два піксели, події з теми й з диспетчера тегів одночасно, модуль, який шле своє — розбір чужого налаштування йде окремим рядком кошторису.
  • Є банер згоди чи немаєЯкщо немає — події просто йдуть. Якщо є — обидва канали треба підкорити вибору людини й перевірити два стани, згоду й відмову. Тестування на цьому подвоюється.
  • Чия черга на бекендіПравки в диспетчері тегів робимо самі. Обробник на боці сайту вносить той, у кого є доступ до коду: якщо це ваш розробник, строк починає залежати від його черги, а не від нашої.
Кейси

Задачі та результат у цифрах — усі показники зняті нашим виміром

роздрібний інтернет-магазин нижньої білизни, понад 110 тис. товарних позицій

Задача
Перевірити, чи можна довіряти подіям, за якими працює ремаркетинг у Meta.
Рішення
Розбір лічильників у розмітці й вибірка зі 150 випадкових товарних адрес карти сайту.
Результат
Лічильники стоять усі: диспетчер тегів, GA4, Google Ads, а модуль ремаркетингу віддає ідентифікатор товару одразу для кількох систем, включно з Facebook. Дефект знайшовся не в лічильниках: із 150 випадкових товарних адрес 50 (33%) віддають 301, і всі ведуть на іншу позицію — інший розмір або колір. На каталозі в 115 456 позицій це близько 37 тис. адрес, де подія перегляду вказує не на той товар, який людина відкривала. Вимір 01.08.2026.

Elektroshokery

спеціалізований інтернет-магазин засобів самооборони

Задача
Зрозуміти, чим міряти рекламу, якщо цифри в кабінеті є, а звіряти їх нема з чим.
Рішення
Розбір усіх лічильників на сторінках і перевірка карти сайту.
Результат
Meta Pixel на місці й вантажиться, а більше на сайті немає нічого: жодної згадки диспетчера тегів чи аналітики Google. Каталог невеликий — 68 адрес у карті сайту, 48 з них товарні, тож перевірити вдалося кожну. Єдиним незалежним джерелом для звірки лишається облікова система. Вимір 31.07.2026.

інтернет-магазин натуральної косметики на продуктах бджільництва

Задача
Перевірити, чи справні лічильники, за якими рахують рекламу.
Рішення
Розбір ідентифікаторів лічильників у HTML і звірка їх типів.
Результат
Meta Pixel, Google Ads і диспетчер тегів стоять і працюють. Аналітика — ні: на сайті живе лічильник Universal Analytics, який Google вимкнув 1 липня 2023 року, а ідентифікатора GA4 у розмітці немає взагалі. Три роки дані не збиралися, і ззовні це виглядало як налаштована аналітика. Перша відповідь 126,3 мс. Вимір 31.07.2026.

клініка пластичної хірургії, сайт на JS-фреймворку

Задача
З'ясувати, чому налаштовані події не з'являються у звітах.
Рішення
Читання розмітки окремо для браузера й для бота, розбір інлайнового сніпета тегів і режиму згоди.
Результат
Контейнер тегів не вантажився взагалі: в інлайновому сніпеті умова виходу порівнювала ідентифікатор сам із собою, тому return спрацьовував завжди — і в полі ідентифікатора стояв код GA4, а не контейнера. Режим згоди за замовчуванням у стані «заборонено». Браузеру сайт віддає оболонку на 3,0 КБ, пошуковому боту — 126 КБ пререндереного HTML. Ззовні все виглядало налаштованим. Вимір 31.07.2026.
Що потрібно від вас

Без цього не почнемо — краще підготувати заздалегідь

  1. Доступ до бізнес-акаунта й диспетчера подій — без нього не видно, що приходить зараз.
  2. Доступ до сайту або до диспетчера тегів для впровадження браузерної частини.
  3. Рішення, які параметри ви готові передавати, і правова підстава для цього — це ваше рішення, не наше.
  4. Доступ до серверної частини, якщо обираємо пряму передачу з бекенда.
  5. Опис того, що у вашій системі вважається успішним замовленням: оплата, підтвердження менеджером чи відвантаження.
  6. Наявний банер згоди й правила його роботи, якщо він уже стоїть.
Якщо чогось із цього немає — скажіть, підкажемо, як зібрати або зробимо самі окремою задачею.
Часті питання

Те, що питають найчастіше — з конкретними відповідями

Навіщо серверні події, якщо піксел і так стоїть?

Браузерна подія їде з телефона покупця й не доїжджає щонайменше в трьох випадках: блокувальник реклами, обмеження браузера на сторонні cookie, обірвана вкладка на слабкому зв'язку. Серверна їде з вашого боку й від цього не залежить. Це не заміна пікселу: обидва канали шлють ту саму подію, тому спільний ідентифікатор обов'язковий. Є й друга причина, про яку згадують рідше: сервер знає, що замовлення справді створене, а сторінка подяки знає лише те, що браузер її відкрив — а відкрити її можна п'ять разів поспіль.

Що таке дедуплікація і чому саме вона головна?

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

Як швидко зрозуміти, що зараз цифри неправильні?

Візьміть купівлі в кабінеті Meta за тиждень і замовлення в обліковій системі за той самий тиждень. Різниця в рази в бік кабінету — майже завжди подвійний облік. Різниця в бік облікової системи — недоставлені події. Точного збігу не буде ніколи: вікна атрибуції зсунуті, частина замовлень приходить не з реклами. Але порядок величин має сходитись, і якщо не сходиться — питання не до кампаній.

Чому подія має нести правильний ідентифікатор товару?

На ньому тримається динамічний ремаркетинг: подія перегляду має вказувати на ту саму позицію, що лежить у товарному фіді. У магазині нижньої білизни ми взяли 150 випадкових товарних адрес із карти сайту — 50 із них (33%) віддали 301 на іншу позицію, інший розмір або колір. На каталозі в 115 456 позицій це близько 37 тис. адрес. Формально події там шлються, фактично частина з них розповідає Meta про товар, якого людина не дивилась. Тому перед налаштуванням подій ми дивимось на редиректи, а не лише на код.

Банер згоди зменшить обсяг даних?

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

У нас магазин на JS-фреймворку, події не спрацьовують на переходах

Впізнавана історія: сторінка не перезавантажується, тому стандартна вставка піксела реєструє тільки перший екран. Події треба вішати на зміну маршруту, а купівлю краще взагалі винести на сервер — вона там і так відома. Наочний приклад із наших замірів: у клініки браузер отримує оболонку на 3,0 КБ, а весь контент домальовується скриптом. Усе, що покладається на завантаження документа, у такій збірці спрацьовує один раз за візит.

Які параметри можна передавати, а які ні?

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

Скільки це триває і що буде видно наприкінці?

3–12 робочих днів після безкоштовної перевірки. Готова інтеграція платформи вкладається в три-чотири дні. Серверний контейнер тегів або власний обробник на бекенді — до двох тижнів: там потрібні тестові події, звірка з обліковою системою й тиждень спостереження за якістю зіставлення. Наприкінці у вас три речі: схема подій документом, звірка кабінету з обліковою системою за той самий період і зрозуміла причина розбіжності, якщо вона лишилась.

Надішліть адресу сайту й доступ до диспетчера подій.

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

Дивитись кейси
  • Відповідь протягом 2 годин
  • Без зобов’язань
  • Працюємо за договором

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