Відстеження дзвінків: як зв'язати дзвінок із кампанією
Як налаштувати відстеження дзвінків і прив'язати кожне звернення до кампанії, групи оголошень і ключового слова. Покрокова інструкція та розбір помилок.
Редакція ADS BeastОпубліковано 7 хв читання
Відстеження дзвінків - це спосіб прив'язати кожне телефонне звернення до джерела, з якого прийшла людина. Зв'язок будується на динамічному номері або динамічному параметрі в оголошенні чи на сайті, який система підставляє автоматично. Далі ця мітка проходить через CRM і потрапляє у звіт разом із заявками з форм.
Коротко
- Дзвінок стає конверсією лише тоді, коли несе ідентифікатор кампанії, а не просто фіксується як факт звернення.
- Динамічний номер або параметр у кінцевому URL - основа зв'язку між дзвінком і джерелом.
- Без єдиного поля для ідентифікатора клієнта в CRM дзвінки та заявки з форм доведеться зіставляти вручну.
- Вікно конверсії за кліком у Google Ads за замовчуванням 30 днів, налаштовується від 1 до 90.
- Помилку найчастіше видно не в цифрах, а в тому, що частина звернень не має жодної мітки джерела.
Що таке відстеження дзвінків і навіщо воно потрібне
Відстеження дзвінків - це набір налаштувань, які зберігають інформацію про джерело звернення разом із самим фактом дзвінка. Без нього ви бачите, що хтось подзвонив, але не знаєте, з якої кампанії, групи оголошень чи ключового слова прийшла ця людина.
На практиці це означає, що бюджет розподіляється наосліп. Ви бачите витрати по кампаніях, бачите загальну кількість дзвінків, але не можете сказати, яка кампанія їх принесла. Різниця між «дзвінки є» і «дзвінки атрибутовані» - це різниця між звітом для звіту та робочим інструментом для рішень.
Тому відстеження дзвінків майже завжди йде в парі з наскрізною аналітикою: мінімальний набір для наскрізної аналітики без підрядника описує, які поля обов'язково мають дожити від першого кліку до угоди. Якщо цей ланцюг розірваний на будь-якому етапі, дзвінок не долетить до звіту.
Як пов'язати дзвінок із конкретною кампанією
Найнадійніший спосіб - підставляти в номер, який бачить людина, або в посилання на дзвінок динамічний параметр із назвою кампанії чи групи оголошень. Тоді система під час звернення фіксує, з якого джерела прийшов цей номер.
У Google Ads і Meta такий параметр додається до кінцевого URL або до самого оголошення, тому зв'язок зберігається навіть після переходу на сайт. Людина бачить один номер, а система за ним зберігає повну мітку джерела.
Важливо розуміти різницю між двома сценаріями. Коли людина дзвонить прямо з оголошення, мітка прив'язана до оголошення і передається разом із викликом. Коли людина спершу переходить на сайт, а потім дзвонить із номера на сторінці, зв'язок залежить від того, чи правильно налаштований динамічний номер і чи зберігся параметр у сесії.
Другий сценарій складніший, бо між кліком і дзвінком може минути час, людина може повернутися на сайт з іншого пристрою. Саме тому параметр у кінцевому URL варто дублювати в CRM, а не покладатися лише на сесію браузера. Про те, як мітка доживає до картки клієнта, детально розказано в матеріалі про UTM-розмітку, яка доживає до картки в CRM.
Динамічний номер проти динамічного параметра: що вибрати
Обидва способи працюють, але вирішують різні задачі. Динамічний номер підмінює телефон, який бачить людина, залежно від джерела. Динамічний параметр додає мітку до посилання або оголошення і не змінює номер.
| Критерій | Динамічний номер | Динамічний параметр |
|---|---|---|
| Що змінюється | Телефон, який бачить людина | Мітка в посиланні або оголошенні |
| Точність прив'язки | Висока, номер сам вказує на джерело | Залежить від збереження параметра |
| Складність налаштування | Потрібен пул номерів і підміна | Достатньо коректного URL |
| Робота з офлайн-дзвінками | Підходить | Не покриває |
| Ризик втрати мітки | Низький | Зростає, якщо сесія перервалася |
Динамічний номер краще працює там, де дзвінків багато і потрібна точність до ключового слова. Динамічний параметр дешевший у впровадженні й часто достатній, якщо бізнес хоче бачити хоча б розподіл за кампаніями.
На практиці багато хто починає з параметра, а номер додає пізніше, коли з'являється потреба в точніших даних. Це нормальний шлях, головне не залишати зв'язок на рівні «приблизно».
Що потрібно налаштувати, щоб дзвінки потрапляли в аналітику разом із заявками з форм
Дзвінок має стати окремою подією або конверсією з тим самим ідентифікатором клієнта, що й заявка з форми. Якщо телефон і форма ведуть у різні системи, зв'язати їх можна через CRM: вона приймає обидва типи звернень і передає мітку кампанії далі.
Без єдиного поля для ідентифікатора звіти доведеться зіставляти вручну. Це не означає, що потрібна складна інтеграція - часто достатньо домовитися про одне поле, яке заповнюється в обох випадках.
Порядок дій виглядає так:
- Визначте, яке поле буде ідентифікатором клієнта, і використовуйте його і для дзвінка, і для форми.
- Налаштуйте передачу мітки кампанії з рекламного кабінету в CRM, а не тільки в аналітику.
- Створіть окрему подію для дзвінка з тією ж назвою, що й у звітах по формі.
- Перевірте, що обидва типи звернень видно в одному звіті з однаковими назвами кампаній.
- Звірте кілька реальних звернень вручну, перш ніж довіряти агрегованим цифрам.
Коли ці кроки зроблено, звітність рекламного кабінету і CRM починають сходитися. Якщо цифри все одно розходяться, варто розібрати причини за матеріалом про те, чому цифри рекламного кабінету не збігаються з CRM.
Вікно конверсії та атрибуція дзвінка
За замовчуванням вікно конверсії за кліком у Google Ads становить 30 днів, і його можна налаштувати в межах від 1 до 90 днів. Це стосується і тих дій, які зараховуються після звернення, якщо вони прив'язані до кліку.
Якщо дзвінок надходить через кілька тижнів після переходу, перевірте, чи не випадає він за межі вибраного вікна. Це часта причина, чому звернення є, а конверсії в звіті немає. Людина подзвонила, CRM зафіксувала дзвінок, а система вважає, що клік був занадто давно.
Вибір вікна залежить від циклу угоди. Для швидких послуг достатньо короткого проміжку, для довгих продажів його варто розширити. Головне - розуміти, що будь-яке вікно щось відсікає, і зіставляти його з реальним циклом, а не зі зручністю звіту.
Браузерна чи серверна передача даних про дзвінки
Серверна передача стійкіша до блокувальників і втрат на стороні браузера, але вона вимагає, щоб ідентифікатор клієнта збігався з тим, що використовується в браузерній частині.
Для Google Ads повторна конверсія з тим самим transaction або order ID дедуплікується, а от однаковий ID у різних конверсійних акціях їх не об'єднує. Тому для однієї покупки краще вести один наскрізний ідентифікатор і в браузері, і на сервері.
Окремо варто пам'ятати, що Measurement Protocol відправляє серверні події в GA4, а не напряму в Google Ads. Імпорт із GA4 і передача через Google Ads API - це різні шляхи, і їх не варто плутати при налаштуванні конверсій.
На практиці найчастіше помиляються саме на стику цих двох шляхів: налаштовують серверну передачу, але не узгоджують ідентифікатори, і потім не можуть зрозуміти, чому частина звернень не дедуплікується. Про схожі проблеми з передачею подій із боку Meta варто почитати в розборі чому Meta Pixel не передає події та як це перевірити - логіка перевірки там та сама.
Типові помилки, через які дзвінки не видно у звіті
Найчастіше причина в тому, що номер на сайті або в оголошенні не має динамічного параметра, тому система не знає, з якої кампанії прийшов абонент. Друга причина - розбіжність у назвах подій або ідентифікаторах між джерелами, через що частина конверсій не дедуплікується.
Перевірте, чи передається мітка кампанії в CRM і чи збігається назва події в усіх джерелах. Якщо хоча б одне з цих двох не виконується, звіт буде неповним незалежно від того, скільки дзвінків насправді надійшло.
Ще одна помилка - відсутність єдиного конструктора посилань. Коли кожен менеджер розмічує кампанії по-своєму, назви джерел розходяться, і зв'язати їх потім майже неможливо. Конструктор UTM-міток допомагає тримати однаковий формат для всіх каналів.
Окремо варто згадати передчасні висновки. Зміна числа конверсій сама по собі не доводить, що дедуплікація працює. Це лише гіпотеза, яку треба перевірити на рівні подій, ідентифікаторів, джерел і атрибуції.
Як перевірити, що зв'язок працює
Перевірка будується на кількох реальних зверненнях, а не на загальних цифрах. Візьміть кілька дзвінків і заявок з форм і пройдіть кожен шлях вручну від кліку до картки в CRM.
Що варто перевірити:
- Чи має кожне звернення мітку джерела, а не порожнє поле.
- Чи збігається назва події для дзвінка і для форми.
- Чи не випадає звернення за межі вікна конверсії.
- Чи однаковий ідентифікатор клієнта використовується в браузерній і серверній частині.
- Чи видно обидва типи звернень в одному звіті.
Якщо всі п'ять пунктів виконуються на тестових зверненнях, налаштування можна вважати робочим. Якщо ні - проблема локалізована, і її видно без здогадок.
Для тих, хто хоче бачити цей ланцюг в одному місці, є сторінка про наскрізне відстеження звернень у кабінеті: там описано, як дзвінки та заявки зводяться в спільний звіт разом із передачею серверних конверсій.
Наступний крок
Почніть з одного тесту: візьміть реальний дзвінок, який надійшов із реклами, і простежте його шлях від кліку до картки в CRM. Якщо на якомусь етапі мітка джерела зникає, саме там і потрібно правити налаштування. Після цього перевірте, чи видно це звернення у звіті поруч із заявками з форм.