Back to archive
10.06Веб-аналитика и GTM

Сквозная аналитика: от клика до денег

TL;DR

  • Сквозная аналитика соединяет расходы на рекламу, поведение на сайте, звонки, заявки, CRM-статусы, оплату, возвраты и маржу.
  • GA4 видит онлайн-события. CRM видит продажи. Финансы видят деньги. Сквозная аналитика нужна, чтобы эти три мира перестали спорить.
  • Главный объект системы - стабильный ID: client_id, lead_id, deal_id, transaction_id, call_id.
  • Если менеджеры не ведут CRM, сквозная аналитика быстро превращается в красивый dashboard с неверными выводами.
  • Начинать нужно не с покупки SaaS, а с карты данных: какие ID где рождаются, как передаются и кто отвечает за качество.

1. Что это такое

Сквозная аналитика отвечает на вопрос, который обычная веб-аналитика закрывает только частично:

Сколько денег принес конкретный канал, кампания, креатив, ключевое слово или партнер после всех продаж, отказов, возвратов и операционных потерь?

GA4 может показать, что кампания дала 300 заявок. Но если 260 заявок не дозвонились, 30 не прошли скоринг, 8 отказались после консультации, а 2 купили с большой маржой, решение по бюджету нельзя принимать по CPL. Нужен путь до фактического результата.

Сквозная аналитика - это не один тег и не один отчет. Это договор между маркетингом, продажами, продуктом, CRM, BI и финансами.

2. Какие данные нужно склеить

Минимальная end-to-end модель включает четыре слоя.

СлойЧто хранитКлючевые поля
РекламаРасходы, показы, клики, кампанииcampaign_id, ad_id, cost, click_id
СайтВизиты, события, формы, звонкиclient_id, session_id, utm_*, lead_id, call_id
CRMСделки, статусы, менеджеры, причины отказаlead_id, deal_id, status, owner, reject_reason
ФинансыВыручка, маржа, возвраты, повторные покупкиdeal_id, transaction_id, revenue, margin, refund

Если нет общего ключа, таблицы не соединятся. Поэтому нельзя относиться к lead_id как к технической мелочи. Это мост между кликом и деньгами.

3. Пример: два канала с одинаковым CPL

Допустим, школа запускает рекламу курса.

КаналРасходЛидыCPLОплатыВыручкаROMI
Meta Ads500 000 KZT2502 000 KZT182 700 000 KZT440%
TikTok Ads500 000 KZT2502 000 KZT4600 000 KZT20%

В отчете по лидам каналы выглядят одинаково. В отчете по деньгам - это два разных бизнеса. Meta дает меньше шума и лучше закрывается. TikTok может быть полезен для охвата или ретаргетинга, но как источник прямых оплат он слабее.

Если команда смотрит только CPL, она будет делить бюджет поровну. Если смотрит ROMI, CAC и payback, бюджет уйдет туда, где есть реальные деньги.

4. Архитектура внедрения

Шаг 1. Справочник источников

Сначала приводим в порядок UTM, рекламные ID, naming convention кампаний и source/medium. Если источники уже грязные, сквозная аналитика просто покажет грязь в более дорогом интерфейсе.

Шаг 2. Единый ID заявки

Форма должна создавать lead_id и передавать его:

  • в GA4 как параметр события;
  • в CRM вместе с заявкой;
  • в call tracking, если заявка может стать звонком;
  • в backend/postback, если статус вернется позже.

Шаг 3. CRM дисциплина

CRM должна фиксировать статусы не "как-нибудь", а по воронке:

new_lead -> contacted -> qualified -> proposal_sent -> paid -> refunded
new_lead -> no_answer
new_lead -> disqualified
new_lead -> duplicate

Если менеджеры выбирают произвольные статусы, BI не сможет посчитать нормальную конверсию.

Шаг 4. Импорт расходов

Расходы нужно забирать из рекламных кабинетов или медиаплана. В простом варианте - через CSV/таблицы. В нормальном - через API или коннектор в BigQuery.

Шаг 5. BI и правила расчета

ROMI, CAC, LTV, gross margin, payback window должны иметь фиксированные формулы. Иначе маркетинг будет считать "по выручке", финансы - "по марже", продажи - "по оплатам", а директор каждый месяц будет смотреть на разные цифры.

5. Call tracking и offline-конверсии

Для Казахстана и СНГ это критично. Во многих нишах человек не оставляет форму, а звонит, пишет в WhatsApp, уходит в Kaspi, приходит в офис или закрывается через менеджера.

Если звонки не связаны с источниками, половина воронки становится невидимой.

Именно здесь рождается конфликт "маркетинг привел лиды, продажи говорят, что лиды плохие". Сквозная аналитика не решает конфликт дипломатией. Она показывает, где именно воронка теряет деньги.

6. Частые ошибки

Покупают платформу до карты данных

Roistat, Calltouch, Power BI, Looker Studio или BigQuery не исправят хаос в CRM. Сначала схема данных, потом инструмент.

Считают ROMI по выручке, забывая маржу

Для инфопродукта и для бытовой техники одна и та же выручка означает разную прибыль. Если есть себестоимость, логистика, рассрочка, бонусы или возвраты, считайте маржу.

Не учитывают задержку сделки

В недвижимости, образовании, авто, B2B и банковских продуктах продажа может закрываться через недели или месяцы. Нельзя оценивать кампанию по оплатам через 24 часа после запуска.

Нет причины отказа

Статус lost бесполезен. Нужны причины: не дозвонились, нет бюджета, дубль, не подходит продукт, отказ по скорингу, купил у конкурента.

7. QA чеклист

  • UTM и рекламные ID стандартизированы.
  • У каждой заявки есть стабильный lead_id.
  • lead_id уходит в GA4, CRM и backend.
  • Звонки имеют call_id и связываются с визитами.
  • CRM-статусы фиксированы и понятны.
  • Расходы импортируются по campaign/ad ID.
  • Выручка и возвраты связаны с deal_id или transaction_id.
  • ROMI считается по согласованной формуле.
  • Есть отчет не только по лидам, но и по оплатам, марже, отказам и LTV.

Видео к теме

Export data from Google Analytics 4 properties to BigQuery

Официальное видео Google про экспорт GA4 в BigQuery. Полезно для понимания, почему серьезная сквозная аналитика часто уходит из интерфейса GA4 в сырые события, SQL и собственные витрины.

Главный совет

Сквозная аналитика начинается не с dashboard. Она начинается с честного вопроса: "Можем ли мы провести одну оплату назад до клика, кампании и креатива?" Если ответ нет, сначала чините ID, CRM и статусы. Иначе вы будете оптимизировать бюджет по красивым, но недостоверным цифрам.

Sources / Notes