Реклама привела звернення. Менеджер поговорив із покупцем, змінив склад замовлення й погодив доставку. Оплата з’явилася в обліковій системі. У звіті маркетолога досі видно лише заповнену форму.
Саме цей розрив має закрити наскрізна аналітика. Для Flipper ми налаштували зв’язок сайту, CRM, BAS / 1С і GA4. Головна задача тут полягає в тому, щоб простежити шлях звернення до продажу. Нижче розбираємо підхід до такої інтеграції; приклади статусів і перевірок не є виміряними результатами Flipper.
Спочатку домовтеся, що називаєте продажем
Відправлена форма, створене замовлення й отримана оплата відбуваються в різний час. Якщо кожна система називає їх «конверсією», порівняти звіти буде важко навіть за справного обміну даними.
Випишіть події вашого процесу: звернення, погодження, оплата, відвантаження, скасування, повернення. Для кожної визначте джерело та відповідального. Наприклад, CRM керує статусом роботи менеджера, а облікова система підтверджує оплату. Це приклад розподілу, його потрібно звірити з реальною роботою команди.
Збережіть зв’язок із першим зверненням
Посилання з реклами може містити UTM-мітки. Їх потрібно зберегти разом із зверненням і передати далі, поки менеджер створює замовлення. Самої адреси сторінки недостатньо, щоб відрізнити кілька кампаній.
Замовлення повинно мати сталий ідентифікатор. Не зв’язуйте записи лише за сумою або датою: у той самий день можуть бути однакові покупки. Якщо клієнт звернувся повторно, визначте, це продовження попереднього замовлення чи нова покупка.
Заздалегідь погодьте, які дані потрібні аналітиці. Імена, телефони, email і зміст приватної переписки залишаються в системах роботи з клієнтом, а не в довільних параметрах аналітичних подій.
Передавайте зміни, а не копії всього замовлення
У Google Analytics для покупки передбачена подія purchase, для повернення — refund. Ідентифікатор transaction_id пов’язує подію з конкретною транзакцією. Перелік параметрів і приклади є в документації GA4 для електронної торгівлі.
В інтеграції потрібен журнал відправлених подій. Якщо мережа обірвалася після запису, повторна спроба не повинна створити новий продаж у звітності. Зміна адреси доставки також не означає, що покупку слід порахувати ще раз. Детальніше про це — у матеріалі про помилки синхронізації CRM та обліку.
Для серверних подій Google пропонує Measurement Protocol. Він доповнює збір даних через теги, а не замінює його повністю. Параметри зв’язування та обмеження потрібно врахувати ще під час проєктування обміну. Джерело: огляд Measurement Protocol.
Перевірте одне замовлення від початку до кінця
До оцінки рекламних каналів пройдіть короткий контрольний сценарій:
- Звернення прийшло з відомого джерела. Мітки збережені в CRM.
- Менеджер створив замовлення. Зв’язок із зверненням залишився.
- Оплата підтвердилася в обліку. Подія потрапила в аналітику.
- Повторна доставка тієї самої події не збільшила кількість продажів.
- Повернення або скасування відобразилося за погодженими правилами.
Після цього звірте вибраний період: кількість замовлень, суми, валюти, повернення й дати. Якщо цифри не сходяться, відкривайте конкретні записи, з яких складається підсумок. Один правильний графік не доводить, що весь обмін працює.
Що власник отримує від такого зв’язку
Можна ставити точніші питання: які джерела приводять звернення, що доходять до оплати; де замовлення зупиняються; які дані ще очікують оновлення. При цьому GA4 не слід використовувати як єдиний реєстр фінансових операцій. Частина відвідувань може бути недоступною для вимірювання, а правила атрибуції й дати подій відрізнятися від обліку.
Налаштована аналітика сама не збільшує продажі. Вона дає основу для рішень і дозволяє перевіряти їхній результат. Для оцінки інтеграції підготуйте перелік систем, статуси замовлення та кілька знеособлених прикладів розбіжностей. На аудиті вашого процесу визначимо, на якому переході втрачається зв’язок.