Як звірити конверсії вебаналітики з CRM

Як узгодити конверсії вебаналітики із записами в CRM

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

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

1. Визначте конверсію та лід, які будете звіряти

Виберіть одну конверсію в аналітиці та відповідний їй результат у CRM. Наприклад, порівняйте подію на сайті demo_request_submit із записами в CRM, створеними як нові ліди із запитом на демонстрацію. Не об’єднуйте цю подію з підписками на розсилку чи телефонними зверненнями: це різні дії клієнтів, які можуть оброблятися по-різному.

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

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

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

2. Визначте правила порівняння до отримання даних

Спочатку домовтеся про часовий пояс. Аналітика та CRM можуть зберігати часові мітки в різних часових поясах або відображати їх відповідно до різних налаштувань облікових записів. Перш ніж порівнювати підсумки за днями, приведіть обидва набори даних до одного узгодженого часового поясу, наприклад UTC. Інакше надсилання форми близько до опівночі може потрапити до різних дат.

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

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

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

3. Порівняйте конверсії в аналітиці з лідами в CRM

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

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

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

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

4. З’ясуйте причину розбіжності між вебаналітикою та даними CRM

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

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

• Спрацювання тегу: Тег аналітики може не запускатися після надсилання форми або спрацьовувати до того, як надсилання завершиться успішно. Перевірте форму в контрольованому сеансі та переконайтеся, що подія з’являється лише на потрібному етапі процесу.

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

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

• Усунення дублікатів: CRM може оновити наявний контакт замість створення нового ліда. Знайдіть ідентифікатор у наявних записах і перевірте, чи система зафіксувала оновлення або об’єднання.

• Затримка створення: Черга, заплановане завдання або ручна перевірка можуть відкласти створення запису в CRM. Перш ніж вважати його відсутнім, порівняйте час події з часом створення запису.

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

5. Врахуйте дублікати, затримки та зміни статусів

Не кожна конверсія в аналітиці має створювати новий лід у CRM. Хтось може надіслати форму двічі або CRM може об’єднати повторне надсилання з наявним контактом. Рахуйте події-конверсії за визначенням аналітики, а унікальні записи CRM — за визначенням CRM. Підсумки можуть правомірно відрізнятися, але правило обробки дублікатів має бути чітким.

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

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

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

6. Виправляйте розбіжності, не переписуючи історію

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

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

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

7. Регулярно перевіряйте узгодженість даних

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

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

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