Офлайн-конверсії не долітають до аналітики: де ламається зв'язка
Найчастіше зв'язка ламається не на етапі налаштування, а на етапі зіставлення: у CRM є угода, в аналітиці — візит, а між ними немає спільного ідентифікатора. Клієнт прийшов за оголошенням, залишив заявку, менеджер завів угоду вручну через день — і все, ланцюжок обірвався.
Google Analytics бачить лише сесію без результату, а Битрикс24 — результат без джерела. У звітах за каналами такі угоди осідають у «прямих заходах» або не враховуються взагалі.
Другий розрив — часовий. Офлайн-конверсія за своєю природою відстає від візиту: дзвінок обробляють через годину, угоду закривають через тиждень, оплату — через місяць.
Поки подія дійде до аналітики, вікно атрибуції вже закрите, і система записує конверсію не тому каналу, який її приніс. Особливо помітно на довгих угодах у B2B, де між першим торканням і оплатою минають місяці й кілька торкань.
Третє джерело викривлень — ручні статуси. Якщо воронка в Битрикс24 не прив'язана жорстко до етапів «кваліфіковано, узгоджено, оплачено», а менеджери рухають картки на власний розсуд, то в аналітику йде не факт продажу, а суб'єктивна оцінка.
Наскрізна аналітика починає вважати конверсією те, що нею не є, і канали отримують хибну атрибуцію — бюджет іде туди, де заявок багато, а грошей немає.
Четвертий шар — технічний: ідентифікатор кліку (gclid, client_id) не зберігається в угоді, а без нього Google Analytics не може зшити офлайн-подію з конкретним візитом.
Інтеграція Битрикс24 Google Analytics у цьому місці вимагає не плагіна, а дисципліни передачі ідентифікаторів із форми в CRM і зворотного надсилання статусів через Measurement Protocol. Розбираємо, як це закривається.
Що дає зв'язка: вимірювані ефекти для відділу продажів
Коли угода з CRM потрапляє в аналітику як офлайн-конверсія, відділ продажів перестає працювати наосліп. Раніше шлях клієнта обривався на заявці: форму надіслано, а що з нею сталося далі — чи закрилася угода, чи ні — аналітика не знала.
Тепер кожна закрита угода повертається у звітність із прив'язкою до джерела, кампанії та ключового запиту, і рішення ухвалюються за фактичними грошима, а не за кількістю кліків.
Атрибуція угод змінює картину каналів. Канал, який давав багато дешевих заявок, але майже не приносив оплат, нарешті видно у звіті поруч із каналом, який приводив менше лідів, зате з високою часткою закриттів.
Це дозволяє перерозподіляти зусилля й бюджет туди, де заявки перетворюються на виручку, а не просто на рядок у CRM.
Якість лідів стає вимірюваною, а не оцінною. Видно, з якої кампанії приходять клієнти, що доходять до оплати, а з якої — звернення, які відділ продажів закриває відмовою на першому дзвінку.
Вартість залучення рахується за угодами, а не за заявками, тому вона відображає реальну економіку продажів, а не проміжну метрику.
Звітність за каналами перестає розходитися між маркетингом і продажами: обидві сторони дивляться на ті самі дані, де офлайн-угоди зведені з онлайн-джерелами.
Суперечка «маркетинг приводить сміття» чи «продажі не вміють закривати» замінюється розбором конкретних каналів і етапів воронки.
Способи передачі даних: порівняння варіантів
Передача офлайн-конверсій з Битрикс24 в Google Analytics будується на одному принципі: подія в CRM зіставляється з сесією на сайті через ідентифікатор клієнта, і вже це зіставлення надходить в аналітику.
Відрізняються способи доставки — від майже миттєвої передачі через вебхуки до регулярного вивантаження даних пакетами. Вибір визначає, наскільки швидко конверсія з'явиться у звітах і скільки ручної роботи залишиться на боці команди.
| Спосіб | Коли підходить | Обмеження |
|---|---|---|
| Вебхуки за подією | Потрібна передача офлайн-конверсій майже одразу після зміни стадії угоди; потік подій помірний | Потребує стабільного приймання на боці аналітики: при недоступності події губляться, потрібна черга повторів і журнал доставки |
| Планове вивантаження даних | Великі обсяги, звітність раз на добу влаштовує; важливо не навантажувати CRM у години пік | Затримка між угодою та появою у звіті; при збої вікна вивантаження дані наздоганяються наступним запуском |
| Ручний експорт з CRM | Разовий аудит, звірка історичних угод, перевірка гіпотез | Не масштабується, високий ризик дублів і розбіжностей з автоматичним потоком |
| Передача через проміжне сховище | Кілька джерел і систем аналітики, потрібна єдина точка нормалізації ідентифікаторів | Дорожче в підтримці: з'являється ще один сервіс, який треба моніторити й оновлювати |
На що дивитися при виборі
Ключовий ризик — розсинхрон ідентифікатора клієнта: якщо в CRM він зберігається в одному вигляді, а на сайті збирається в іншому, зіставлення дає хибні спрацювання або пропуски.
Тому в будь-якому варіанті спочатку фіксуємо правило нормалізації і лише потім обираємо спосіб доставки.
Другий фактор — ідемпотентність. Повторне надсилання однієї й тієї ж події не повинно задвоювати конверсію, інакше звітність втрачає сенс. Вебхуки та вивантаження налаштовуються так, щоб кожна подія мала унікальну ознаку і повторна доставка не створювала дубль.
Що це дає на практиці
При передачі офлайн-конверсій через вебхуки дані у звітах відстають на хвилини, при плановому вивантаженні — на години.
Різниця критична, якщо на аналітику спирається управління рекламою: свіжі дані дозволяють швидше перерозподіляти канали, а добова затримка залишає рішення на застарілій картині.
Ми зазвичай комбінуємо способи: вебхуки для поточних угод і планове вивантаження як страховку, яка наздоганяє пропущене. Опишіть вашу воронку та обсяг угод — повернемося з оцінкою та планом по кожному способу.
Як ми впроваджуємо зв'язку: етапи робіт
Роботу починаємо з аудиту: дивимося, які цілі вже заведені в Google Analytics, як розмічені форми та кнопки на сайті, які угоди в Бітрікс24 закриваються вручну і тому не потрапляють в аналітику.
На цьому етапі фіксуємо розрив між маркетинговими даними та реальними продажами — саме він спотворює оцінку каналів.
Етапи впровадження
- Аудит поточної інтеграції. Звіряємо список цілей з воронкою угод, перевіряємо коректність ідентифікаторів (Client ID, User ID) у вебформах і заявках з месенджерів, знаходимо джерела, де зв'язок губиться.
- Проєктування схеми передачі. Визначаємо, які стадії угоди вважати офлайн-конверсією, як матчити подію з сесією, які поля CRM йдуть у звіт. Узгоджуємо правила з вашою командою продажів, щоб «кваліфікований лід» означав одне й те саме для всіх.
- Налаштування передачі даних. Налаштовуємо вивантаження з Бітрікс24 в аналітику: пов'язуємо закриті угоди з вихідним візитом, налаштовуємо розклад і повторні відправлення при збоях, щоб жодна конверсія не загубилася.
- Тестування. Проганяємо контрольні угоди по всій воронці — від заявки до оплати — і перевіряємо, що подія дійшла з правильним джерелом і сумою. Окремо перевіряємо відкат: якщо передача впала, дані мають довантажитися, а не задвоїтися.
- Звірка з CRM. Порівнюємо кількість конверсій у звіті з кількістю угод у Бітрікс24 за той самий період. Розходження більше допустимого — шукаємо причину, поки цифри не зійдуться.
- Документація. Передаємо схему потоку даних, список цілей і стадій, регламент перевірки та інструкцію для маркетолога: як додати нову ціль або змінити правило без розробника.
Що отримуєте на виході
Після впровадження звіти показують не заявки, а гроші: видно, який канал приносить угоди, що доходять до оплати, а який — лише кліки. Далі зв'язку можна розширювати — додавати нові джерела та стадії, не перебудовуючи все заново.
Що залишається у вас після впровадження
Після впровадження у вас залишається не «набір налаштувань у чужому кабінеті», а робоча документація, за якою інтеграцію Битрикс24 з Google Analytics зможе супроводжувати будь-який ваш інженер або маркетолог.
Ми передаємо все у вашому контурі: репозиторій, доступи, описи — нічого не залишається на нашій стороні.
- Схема інтеграції — потік даних від угоди в CRM до завантаження офлайн-конверсії в Google Analytics: які події та на яких етапах воронки надсилаються, як зіставляються ідентифікатори клієнта, де саме виникають розбіжності.
- Конфігурація передачі — робочі налаштування вивантаження: перелік етапів і полів угоди, правила мапінгу на цілі, розклад і умови повторного надсилання у разі збою.
- Регламент супроводу — хто і що робить при зміні воронки, додаванні нового етапу або зміні правил атрибуції: покроково, з відповідальними та точками перевірки.
- Інструкція з діагностики — як за 10-15 хвилин зрозуміти, чому конверсія не дійшла: де дивитися журнал надсилань, як звірити угоду в CRM з подією в аналітиці, які помилки типові.
- Карта зіставлення даних — таблиця відповідності полів CRM і параметрів подій, щоб при доопрацюваннях не гадати, що куди мапиться.
- Чек-лист приймання — набір перевірок, за якими ви приймаєте роботу: тестова угода проходить весь шлях, звіт показує конверсію, відкат повертає попередню поведінку.
- Доступи та ролі — що і кому видано, які ключі та токени використовуються, де вони зберігаються і як змінюються без простою.
Усе це описано так, щоб через пів року, коли воронка зміниться, вам не довелося заново розбиратися, як влаштована передача. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом артефактів, що передаються.
Кейс: як офлайн-конверсії змінили звітність
Клієнт — мережа з кількох шоурумів з онлайн-заявками та продажами в залі. Угоди в Битрикс24 закривалися менеджерами вручну, а у звітах систем веб-аналітики враховувалися лише заявки з сайту.
Через це канал, який приносив заявки з довгим циклом прийняття рішення, виглядав збитковим, і на ньому скорочували активність.
Розібрали шлях клієнта: заявка з сайту → дзвінок → візит у шоурум → угода. Пов'язали CRM і веб-аналітику за ідентифікатором кліку: під час переходу на сайт відвідувачу присвоювався ідентифікатор, він же зберігався в картці угоди.
Коли менеджер переводив угоду в успішну, система надсилала в аналітику офлайн-конверсію з цим ідентифікатором і сумою угоди. Окремо налаштували передачу повернень і скасувань — щоб звітність не завищувала результат.
Що змінилося у звітності
До впровадження у звітах було видно 38% фактичних продажів — решта «губилася» між заявкою та закриттям угоди в CRM. Після налаштування передачі офлайн-конверсій покриття зросло до 94%: у звітах почали враховуватися й угоди, закриті через тижні після першого звернення.
Канали перезібралися в іншу картину. Частка заявок з довгим циклом зросла у звітах майже вдвічі, а один із каналів, який вважався слабким, вийшов у лідери за кількістю закритих угод.
Рішення щодо розподілу активності почали ухвалювати за фактичними продажами, а не за кількістю заявок.
Що дала зв'язка з урахуванням повернень
Скасування та повернення тепер зменшують результат каналу, а не залишаються за кадром. Розбіжність між звітами аналітики та даними CRM скоротилася з 40% до 6% — цифри у звіті для керівництва та в CRM стали зіставними.
Повторні продажі наявним клієнтам теж прив'язалися до вихідного каналу. Це показало, що частину виторгу приносять клієнти, які прийшли каналами, що раніше вважалися неефективними, — і їхній внесок став видимим у звітності.
Проєкт реалізовано на Битрикс24 з передачею даних у системи веб-аналітики.
Чим відрізняється передача офлайн-конверсій від наскрізної аналітики?
Наскрізна аналітика відповідає на питання «який канал привів клієнта», офлайн-конверсії — на питання «що сталося з цим клієнтом після того, як він пішов із сайту». Це два різних шари даних, і плутати їх — означає будувати звітність на неповній картині.
Наскрізна аналітика пов'язує джерело трафіку з дією на сайті: рекламний клік, перехід із пошуку, візит за посиланням із листа.
Офлайн-конверсія фіксує подію, яка сталася поза браузером: оплату за рахунком, підписання договору, дзвінок у відділ продажів, повторну покупку через менеджера.
Різниця проявляється в момент, коли угода закривається не на сайті. Клієнт залишив заявку, менеджер вів його тиждень, оплата надійшла на розрахунковий рахунок — для системи веб-аналітики цей шлях обривається на формі.
Наскрізна аналітика покаже джерело заявки, але не покаже, що угода відбулася і скільки вона принесла. Офлайн-конверсія закриває цей розрив: подія з облікової системи повертається в аналітику і прив'язується до вихідного джерела трафіку.
Технічно це влаштовано так: у Битрикс24 фіксується стадія угоди, при переході на цільову стадію система формує ідентифікатор клієнта і передає подію в аналітику. Ідентифікатор пов'язує закриту угоду з тим рекламним кліком або візитом, який її породив.
Без цієї зв'язки рекламні канали оцінюються за заявками, а не за виручкою — і рішення про перерозподіл бюджету приймається на невірних даних.
Коли потрібен який підхід. Наскрізна аналітика — якщо цикл угоди короткий і закривається на сайті: інтернет-магазин, онлайн-оплата, швидка покупка. Офлайн-конверсії — якщо між заявкою та оплатою є робота менеджера, рахунок, договір, тривале узгодження.
На практиці обидва шари працюють разом: наскрізна аналітика дає верхню частину воронки, офлайн-конверсії — її грошове завершення.
Інтеграція Битрикс24 з Google Analytics якраз і налаштовує передачу цих подій, щоб звітність спиралася на фактично закриті угоди, а не на кількість залишених форм.
Часті технічні питання
Інтеграція Битрикс24 з Google Analytics найчастіше впирається не в сам обмін даними, а в коректну передачу офлайн-конверсій — подій, які відбуваються поза сайтом: оплата за рахунком, підтвердження угоди менеджером, повторна покупка. Без них аналітика бачить лише кліки та заявки, а реальний виторг за каналами не показує.
Нижче — відповіді на технічні сумніви, які виникають до початку налаштування.
Які дані взагалі потрібно передавати в Google Analytics?
Мінімум — ідентифікатор кліку (gclid або аналог із рекламної системи), суму та час конверсії, статус угоди. Без gclid подія не прив'яжеться до джерела трафіку й піде в «прямі заходи».
Ми зберігаємо ідентифікатор у картці ліда при першому візиті та тримаємо до закриття угоди — інакше на момент оплати він губиться.
Що буде, якщо зв'язка налаштована неправильно?
Дублі конверсій спотворюють звітність сильніше, ніж їхня відсутність: одна угода може зарахуватися двічі при зміні статусу. Ми ставимо передачу за конкретним фінальним статусом і захист від повторного надсилання — у звіті залишається один запис на угоду.
Як налаштовується передача з Битрикс24?
Через бізнес-процеси та вебхуки: при переході угоди в цільовий статус система надсилає подію в Measurement Protocol. Налаштування займає кілька днів, включно з тестовим прогоном на реальних угодах і звіркою цифр із CRM.
Чи можна відкотити зміни, якщо щось піде не так?
Так. Логіка виноситься в окремий бізнес-процес, який вимикається одним налаштуванням без правки ядра. Перед запуском робимо резервну копію конфігурації — повернення до попереднього стану займає хвилини.
Чи потрібно чіпати сам сайт і 1С?
Зазвичай ні: ідентифікатор кліку та статуси вже є в CRM. Сайт доопрацьовуємо, лише якщо він не передає мітку при створенні ліда. З 1С зв'язка працює через обмін статусами оплати — окрема інтеграція не потрібна.
Обговоримо ваше завдання
Збираємо вхідні дані щодо вашого контуру: які сутності в Битрикс24 вважаються цільовими (угода, оплата, повторна покупка), які джерела розмічені в Google Analytics, де зараз втрачається зв'язок між заявкою та закритою угодою.
Цього достатньо, щоб повернутися з оцінкою та планом — без попереднього «технічного інтерв'ю на три години».
- Розбираємо поточну схему: як заявки потрапляють у CRM, які поля фіксують джерело та ідентифікатор кліку, де обривається ланцюжок до офлайн-конверсії.
- Звіряємо довідники: статуси угод, причини відмови, категорії товарів і послуг — приводимо їх до вигляду, придатного для передачі в аналітику без ручних правок.
- Проєктуємо передачу офлайн-конверсій: зіставлення угоди з візитом, правила відправлення при зміні статусу, обробка повторних і скасованих угод.
- Налаштовуємо вивантаження та перевіряємо його на тестових угодах: контрольні суми, дублі, затримки між закриттям угоди та появою даних у звітах.
- Зводимо звітність: зв'язка джерел, кампаній і фактичного виторгу за закритими угодами, а не за надісланими формами.
- Фіксуємо регламент: хто і коли змінює статуси, що відбувається при відмові клієнта, як відкочується помилкова передача.
- Передаємо документацію та навчаємо вашу команду — щоб правки в довідниках не ламали передачу даних.
Щоб повернутися з планом, нам потрібно від вас небагато: доступ до CRM з правами на читання довідників, список цільових статусів угод і розуміння, які звіти ви дивитеся сьогодні.
Опишіть завдання у двох-трьох абзацах — що вже налаштовано, що не сходиться в цифрах, який результат потрібен. Далі ми запропонуємо схему, терміни та порядок робіт.