Зворотний зв'язок від CRM у рекламу: як замкнути цикл

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

Коротко

• Подія з CRM передається на бік площадки серверно, з ідентифікатором клієнта (email, телефон або ID).
• У Google Ads це завантаження офлайн-конверсій або Google Ads API, у Meta - Conversions API.
• Той самий transaction/order ID потрібен і в браузерній, і в серверній передачі, інакше одна покупка може зарахуватися двічі.
• Конверсійна акція в Google Ads має бути позначена як основна, інакше вона не впливає на ставки.
• Вікно конверсій у CRM-звіті й у кабінеті має збігатися, інакше цифри не зійдуться.

Що саме передають із CRM у рекламу

Із CRM у рекламний кабінет передають подію, яка означає бізнес-результат: оплату, підписання договору, кваліфікований лід. Кожна така подія супроводжується ідентифікатором, за яким площадка може зіставити її з конкретною людиною або кліком.

Найчастіше використовують email, телефон або внутрішній ID клієнта. Вибір залежить від того, що у вас стабільно зберігається в CRM і що приймає площадка. Якщо клієнт залишив лише телефон, а email порожній, передавайте телефон; головне, щоб формат був однаковий у всіх відправках.

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

Як передати конверсії з CRM у Google Ads і Meta

Передача йде двома шляхами: через серверну інтеграцію з площею або через проміжний сервіс, який приймає події з CRM і пересилає їх у кабінети. У Google Ads це завантаження офлайн-конверсій або передача через Google Ads API, у Meta - Conversions API.

Порядок дій виглядає так:

1. Визначте в CRM подію-результат і переконайтеся, що вона фіксується один раз і має унікальний ID.
2. Перевірте, що назви подій збігаються з тими, які приймає площадка.
3. Налаштуйте серверну відправку з реальним ID замовлення на тестовому записі.
4. Переконайтеся, що подія з'явилася в кабінеті, а не лише в CRM.
5. Зіставте період звіту в CRM із вікном конверсій у налаштуваннях кабінету.

Для Google Ads важливо, щоб той самий transaction/order ID використовувався і в браузерній, і в серверній передачі. Інакше повторна акція може зарахуватися двічі. Повтор однієї конверсійної акції з тим самим ID дедуплікується, але різні акції для однієї покупки можуть спотворити підсумок.

У Meta дедуплікація пікселя і Conversions API працює за збігом назви події та event_id. Окремого перемикача немає, тому узгодженість назв і ідентифікаторів лягає на вашу інтеграцію.

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

Чому не можна передавати всі конверсії без перевірки подій

Передавати все підряд ризиковано: спочатку треба переконатися, що подія в CRM фіксується один раз, має унікальний ID і що її назва збігається з прийнятою на площі. Без цього алгоритм отримає дублі або події, які неможливо зіставити.

Типові проблеми, які видно ще до запуску:

• подія спрацьовує при кожному редагуванні картки клієнта, а не при зміні статусу;
• ID замовлення генерується заново при повторній синхронізації;
• назва події в CRM і в кабінеті відрізняється регістром або мовою;
• частина угод закривається вручну, і подія не відправляється взагалі.

Зміна кількості конверсій сама по собі не доводить, що дедуплікація працює. Це лише привід перевірити події, ідентифікатори, джерела й атрибуцію. Спершу дивіться на самі записи, потім на цифри.

Як узгодити вікно конверсій між CRM і кабінетом

За замовчуванням у Google Ads вікно конверсій за кліком становить 30 днів, його можна налаштувати від 1 до 90 днів. Вибір залежить від довжини циклу угоди у вашому бізнесі.

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

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

Як перевірити, що серверні конверсії доходять до кабінету

Перевіряйте статус конверсійної акції та останні дати отримання подій у самому кабінеті, а не лише в CRM. CRM підтверджує, що подію відправлено, але не що її прийняла площадка.

У Google Ads подивіться, чи є нові конверсії у звіті після тестової відправки з реальним ID замовлення. У Meta перевірте, чи відображаються події Conversions API в Events Manager. Якщо події не з'являються, шукайте причину в ідентифікаторах, форматі запиту й узгодженості назв подій.

Окремо зверніть увагу на шлях передачі. Measurement Protocol відправляє серверні події в GA4, а не напряму в Google Ads. Імпорт із GA4 і передача через Google Ads API або Data Manager - різні шляхи, і плутати їх не варто: інакше ви налаштуєте не те, що перевіряєте.

Для регулярного контролю зручно тримати перед очима звіти з CPA, CTR, CPC і CPM по кожному каналу: різке розходження між кабінетом і CRM видно саме там.

Що робити, якщо кампанії не оптимізуються на конверсії з CRM

Спершу перевірте, чи конверсійна акція позначена як основна (primary) у Google Ads. Саме primary входить у «Conversions» і впливає на ставки, а secondary видно лише в «All conversions». Якщо ваша подія з CRM стоїть як додаткова, алгоритм її не враховує.

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

Що ще варто перевірити:

• чи не дублюються акції для однієї покупки (окрема акція на «лід» і окрема на «оплату» можуть давати різні підсумки);
• чи не затримується вивантаження з CRM настільки, що алгоритм бачить продаж із запізненням;
• чи достатньо подій для навчання, чи варто тимчасово оптимізуватися на проміжний крок.

Якщо лідів багато, а продажів мало, проблема може бути не в передачі, а в якості заявок. Тоді доречно подивитися на скоринг заявок і розстановку пріоритетів: передавати в рекламу варто не будь-який лід, а кваліфікований.

Як не зламати атрибуцію, коли джерел кілька

Коли в одному кабінеті збираються і браузерні, і серверні події, і кілька каналів, легко отримати подвійний облік. Правило просте: одна покупка - один узгоджений ID, одна конверсійна акція на кожен значущий результат.

Google Ads підтримує узгоджені джерела, тому наявність двох джерел сама по собі не означає подвійний облік. Проблема виникає, коли для однієї покупки заводиться кілька різних акцій: підсумок спотворюється, навіть якщо кожна акція окремо рахується правильно.

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

Наступний крок

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