Facebook Conversion API (Server-Side)

iOS 14.5+ зламав піксель. Ви губите 30-60% даних про конверсії — алгоритм Meta оптимізується на шумі, ваш CPL росте, а звіти брешуть про ROAS.

• ▸ 60% конверсій губиться без серверної передачі після iOS 14.5+
• ▸ +10-15% ефективність реклами в середньому після CAPI
• ▸ CPL падає 15-30% за 2 тижні після того, як Meta переучується на чистих даних

Серверна передача подій через Make.com → Facebook Conversion API. Lead, Schedule, Purchase і кастомні події летять з вашої CRM з хешованим email, телефоном (E.164), імʼям, містом і IP — Meta бачить повну конверсію за 15-30 хвилин незалежно від браузерного трекінгу.

1. 01
   Мапінг подій

   Визначаємо ключові події: Lead (submit форми), Schedule (бронь дзвінка), Purchase (Shopify/Stripe оплата) і кастомні кроки воронки.
2. 02
   Make.com router

   Кожне джерело події (стадія Pipedrive, Cal.com booking, Shopify order) йде через один Make-сценарій.
3. 03
   Хешування даних

   Email lower-case + SHA-256, телефон у E.164 + SHA-256, name + city + IP пакуються по специфікації Meta CAPI.
4. 04
   Відправка в Conversion API

   POST на graph.facebook.com Conversion API з правильним event_id для дедуплікації проти подій пікселя.
5. 05
   Дедуп з пікселем

   Один event_id використовують клієнтський піксель і серверний CAPI — Meta мерджить, без подвійного підрахунку.
6. 06
   Верифікація в Events Manager

   Тестуємо через Test Event Code, моніторимо Event Match Quality (ціль 7+), валідуємо за 48 годин.

• ✓+10-15% ефективність реклами завдяки чистій атрибуції
• ✓Event Match Quality 7-9 (vs ~4 на самому пікселі)
• ✓CPL падає 15-30% за 14 днів після впровадження
• ✓Повертаються Lead і Purchase події, втрачені через iOS 14.5+

• Прийом ліда → CRM
  Лід з форми одразу в CRM з тегами і UTM. 0 пропущених лідів.
• Вітальна серія листів
  5-листова прогрівна послідовність. Контакт прогрітий до покупки.
• Сортування лідів (якісні / неякісні)

  Опитування через Typeform відсіює неякісних. Менеджери працюють лише з тими, хто реально купить.