Архитектура измерений: как устроен учет конверсий и где теряются данные

Почему цифры не сходятся

Заявка одна, а чисел три. В кабинете Google Ads за месяц 42 конверсии, в GA4 за тот же месяц 37, в CRM 29 сделок. Подрядчик защищает кабинет, аналитик защищает GA4, собственник смотрит на CRM и решает, что его обманывают все трое.

Расхождение здесь - нормальное состояние систем, а не признак поломки. Три инструмента отвечают на три разных вопроса и относят одно и то же событие к разным датам.

Google Ads отвечает на вопрос, что принесли клики по рекламе. Конверсия приписывается дате клика, а не дате покупки. Человек кликнул 28 марта, оплатил 12 апреля - в отчете конверсия появится в марте, и мартовская цифра вырастет задним числом, когда отчет за март уже отправлен клиенту.

GA4 отвечает на вопрос, что происходило на сайте. Событие фиксируется в момент, когда оно произошло, и не зависит от того, была реклама или нет. CRM отвечает на третий вопрос: сколько денег пришло. Дата там - дата сделки, источник проставляет менеджер или интеграция, и в половине случаев это поле заполнено словом «интернет».

Второе различие - периметр. Тег Google Ads срабатывает на той же странице, что и событие GA4, но конверсия попадет в кабинет, только если Google сумел связать визит с кликом по объявлению. Не связал - событие останется в веб-аналитике и не появится в рекламном отчете. По этой причине в GA4 конверсий по сайту больше, а в разрезе рекламного трафика картина обратная: нативный тег Google Ads собирает на 10-15% больше конверсий, чем то же действие, импортированное из GA4.

Третье различие - атрибуция. Кабинет распределяет заслугу между всеми кликами в цепочке, поэтому в отчете попадаются нецелые значения вроде 9,65 конверсии. CRM отдает сделку одному источнику целиком. Совпасть эти два подхода не могут даже теоретически.

Отсюда практическое правило: сравнивать между собой имеет смысл динамику, а не абсолютные числа. Кабинет с кабинетом, месяц с месяцем, до изменения и после. Требование «пусть цифры сойдутся» невыполнимо, а попытки его выполнить заканчиваются тем, что в конверсии записывают все подряд и статистика становится хуже.

Из чего состоит измерение

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

За пятью участками стоит шестой, который редко считают частью измерения: сведение чисел в один отчет. Там встречаются кабинет, веб-аналитика, коллтрекинг и CRM, и там же появляется большинство спорных цифр. Правило для этого узла одно: у каждого показателя должен быть указан источник и правило подсчета. Строка «заявки: 42» без пометки, откуда число и по какой дате оно посчитано, порождает больше вопросов, чем закрывает.

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

Где теряются данные

Участок 1: считается не то событие

Самая дорогая ошибка не техническая. Она в том, что конверсией назначили действие, которое не приводит клиента.

Клик по номеру телефона, открытие мессенджера, тридцать секунд на странице, скролл до половины экрана - все это сигналы интереса. Умные стратегии охотятся за тем, что им назначили основной целью, и если основная цель дешевая и частая, алгоритм найдет людей, которые щедро совершают такие действия. В отчете будет рост, в кассе - тишина.

Диагностический признак: средняя ценность конверсии сильно ниже среднего чека. Если средний заказ $2 000-3 000, а средняя ценность конверсии в кабинете $562, значит в одну кучу собраны покупки и микрособытия. Каждый показатель окупаемости в таком аккаунте завышен, и стратегия ставок обучается на смешанном сигнале. До того как чинить ключи, объявления и ставки, чинят это.

Второй источник потерь на первом участке - смена платформы. Обновление checkout в интернет-магазине убирает старую страницу подтверждения, тег остается висеть на несуществующем адресе, и покупки перестают считаться в тот же день. Кампании при этом продолжают работать и тратить.

Участок 2: сигнал не доходит

Событие сработало, но до платформы не добралось. Причин несколько, и действуют они вместе.

• Блокировщики рекламы вырезают запросы к доменам рекламных систем, а доля таких пользователей в технически подкованных нишах заметно выше средней
• Safari ограничивает хранение идентификаторов, поставленных скриптом на стороне браузера, семью днями - повторный визит через две недели выглядит как визит нового человека
• Отказ от сбора данных в интерфейсе согласия убирает часть событий из отчетов, и в европейском трафике это ощутимая доля
• Тег стоит не на всех страницах или срабатывает на клик по кнопке, а не на факт отправки формы

Общая логика участка простая с точки зрения бизнеса: чем больше событий проходит через браузер и чем меньше вы контролируете инфраструктуру передачи, тем выше потери. Это тот участок, который закрывает серверная передача.

Участок 3: клик и конверсия не сопоставились

Данные дошли, но Google не понял, чей это результат. Идентификатор клика GCLID теряется при промежуточных редиректах и при выключенной автопометке, покупка с другого устройства не связывается с кликом, если человек не вошел в аккаунт. Сделка, закрытая позже окна конверсии, не засчитывается вовсе. Окно по умолчанию 30 дней, максимум 90. В B2B цикл сделки бывает длиннее года, и там кабинет по определению видит меньшую часть выручки.

Расширенные конверсии закрывают часть этих потерь: вместе с событием уходят захешированные почта и телефон, и Google опознает человека по своей базе, даже если идентификатор клика не сохранился. Включение занимает несколько минут и не требует разработки, поэтому это первое, что делают после базовой настройки.

Участок 4: заслуга распределилась не так, как ждет бизнес

Модель атрибуции решает, кому засчитать конверсию, если касаний было несколько. При последнем клике почти все уходит брендовому запросу: человек увидел рекламу по общему запросу, ушел думать, вернулся по названию компании. В отчете сработал бренд, деньги на клиента потрачены раньше.

Модель на основе данных распределяет доли между взаимодействиями и дает те самые нецелые значения. Ей нужен объем: ориентир - порядка 200 конверсий и 2 000 взаимодействий с рекламой за 30 дней. Ниже этого распределять почти нечего, и картина повторяет последний клик. На объеме модель сдвигает заслугу к верхним касаниям, и это ближе к тому, как устроены продажи.

Смена модели редко переворачивает отчет: у большинства аккаунтов абсолютные числа меняются слабо. Ценность в другом - меняются выводы о том, какие кампании подготавливают продажу, а не закрывают ее.

Отдельная ловушка - дубли. Одно и то же действие приходит и из нативного тега, и из импорта GA4, кабинет считает обе записи, число конверсий удваивается, стоимость конверсии выглядит вдвое лучше. Проверяется это за минуту в списке конверсионных действий: два действия с похожими названиями и разными источниками, оба отмечены основными.

Участок 5: данные не вернулись из CRM

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

Разрыв тут сильнее всего заметен там, где качество лидов скачет: в услугах с высоким чеком, в B2B, в нишах с длинным циклом. Порядок величин бывает пугающим: кампания с приемлемой ценой заявки дает стоимость квалифицированного лида в тысячи долларов, и до сверки с выручкой этого не видно ни в одном отчете кабинета.

Рабочая схема возврата - три ступени вместо одной: заявка или звонок, затем статус «квалифицирован» из CRM, затем факт оплаты. Каждая ступень грузится обратно отдельным конверсионным действием, и алгоритм видит, чем заканчиваются обращения, а не только сам факт обращения. Там, где сделки разной величины, вместе со статусом отдают и ценность: либо сумму оплаты, либо оценку - вероятность закрытия умножить на средний размер сделки. Единица измерения при этом должна быть одна на весь аккаунт, иначе стратегия ставок сравнивает несравнимое.

Возврат данных срывают три причины: в CRM нет идентификатора клика, статусы не выгружаются автоматически, статус приходит позже окна загрузки. Первые две решаются интеграцией - у Google Ads для этого есть готовые подключения к CRM и почтовым платформам через Data Manager, ручные выгрузки перестали быть единственным способом. Третья причина помехой не считается: конверсии с опозданием грузить можно, алгоритм использует исторические закономерности. Отдельная ловушка при ручной загрузке через таблицы: каждому конверсионному действию нужен свой отдельный файл, иначе все строки припишутся первому действию и счетчики станут одинаковыми.

Последний участок к рекламе уже не относится, а на цифры влияет сильнее многих настроек: обработка обращения. Скорость ответа, доходимость до встречи, подтверждения перед визитом. В услугах с записью часть подтвержденных визитов не состоится, и разрыв между записью и приходом съедает результат кампании точно так же, как потерянный тег. Измерение имеет смысл доводить до этой точки, иначе оптимизация упирается в потолок, который стоит не в рекламе.

Отдельный случай: источники дают разные действия

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

Отсюда практика: конверсии смотрят в разрезе источника и типа действия, а не суммой. Третья точка проверки - вопрос менеджеру, сколько человек назвали рекламу как повод обратиться. Совпадение этих трех картин важнее, чем точность любой из них по отдельности.

Серверная передача: что дает и чего стоит

Браузерная схема отправляет события из браузера человека напрямую в рекламные системы. Серверная - сначала на ваш сервер, а оттуда в Google, Meta и куда угодно еще. Событие уходит из среды, которую контролируете вы, а не из среды, где работают блокировщики и ограничения браузера.

Что это дает:

• Часть событий, которые не проходили в браузерной схеме, доходит; больше всего выигрывают магазины и все, у кого много мобильного трафика
• Сопоставление события с человеком улучшается, потому что вместе с событием уходят серверные данные заказа - почта, телефон, идентификатор транзакции
• Один поток вместо десятка отдельных пикселей: события формируются в одном месте и раздаются по системам с одинаковым составом полей
• Идентификаторы, поставленные с серверной стороны на собственном домене, хранятся дольше, чем поставленные скриптом

Что это стоит:

• Серверный контейнер надо где-то держать и обслуживать - это ежемесячный счет и человек, который понимает, что там происходит
• Настройка требует разработчика; отправить событие мало, его надо собрать с нужными параметрами
• При переезде тегов на поддомен собственного домена изменения DNS расходятся до 48 часов
• В магазинах на готовых платформах нужны оба контура сразу - клиентский пиксель и серверный вебхук; при одном из них часть событий выпадает

Кому это оправдано: магазинам с потоком заказов от тысячи в неделю, проектам с ощутимой долей трафика через блокировщики, компаниям, у которых сделка оформляется вне сайта. Кому нет: лидогенерации на 30-50 заявок в месяц. Там стоимость обслуживания выше, чем ценность возвращенных данных, и те же деньги дадут больше, если вложить их в качество обработки заявок.

Есть промежуточный вариант - раздача тегов через собственный домен без полноценного серверного контейнера. У Google это оформлено отдельным механизмом, Tag Gateway: запросы идут через ваш домен, поэтому часть блокировок обходится, а идентификаторы хранятся дольше. Настраивается силами того, кто ведет сайт, и стоит заметно дешевле полной серверной схемы.

First-party контур: что бизнес контролирует сам

First-party данные - это то, что клиент оставил вам напрямую: почта, телефон, история заказов, статусы в CRM, идентификатор клиента. Не куки, не сегменты рекламных систем, не покупные аудитории.

Два года назад этот контур был приятным дополнением, сейчас он несущий. Сторонние идентификаторы сжимаются во всех браузерах, часть событий не доходит до отчетов из-за отказов в интерфейсе согласия, а рекламные платформы переходят на модели, которым нужен качественный сигнал, а не объем сигнала. Оптимизация опирается на то, что вы сумели передать о своих клиентах. Больше данных о клиентах - точнее сопоставление и дешевле результат.

Куда first-party данные попадают в рекламе:

• Расширенные конверсии - захешированные почта и телефон уходят вместе с событием и улучшают сопоставление
• Списки клиентов - выгрузка базы для таргетинга и исключений, отдельно работает по повторным продажам
• Офлайн-конверсии - статусы сделок возвращаются в кабинет и переучивают стратегию ставок
• Ценность конверсии - если вместе с фактом продажи уходит сумма, кампании можно переводить на стратегии по ценности

Условие для всего перечисленного - порядок в CRM. Дубли контактов, телефоны в пяти форматах, пустое поле почты у половины сделок дадут низкое качество сопоставления, и никакая передача этого не исправит. Второе условие - юридическая часть: согласие на обработку и политика, где описано, что данные передаются рекламным системам в захешированном виде.

От того, насколько точно вы знаете ценность клиента, зависит и целевая рентабельность, которую вы ставите кампаниям. Расчет от маржи и повторных продаж - в материале про целевой ROAS от юнит-экономики.

Чего увидеть нельзя

Часть результата не попадет в отчеты никогда, и с этим работают отдельно.

Моделированные конверсии. Когда пользователь не дал согласия или идентификатор потерян, Google достраивает недостающие конверсии статистически по поведению похожих сессий. Эти конверсии уже подмешаны в общий столбец, отдельного переключателя «показать только прямые» в интерфейсе нет. Отсюда рабочий подход: динамике верить, точной цифре нет, для сверки держать второй контур - выручку в CRM.

Дробные значения. Нецелые конверсии в отчете - следствие распределения долей, а не ошибка настройки. Искать причину в тегах здесь не нужно.

Показы без клика. Человек увидел объявление, не кликнул, через неделю пришел из поиска по названию компании. В кабинете это либо не отражается, либо отражается косвенно - через метрику брендовых поисков, приписанных кампаниям.

Будущие продажи. Часть выручки от сегодняшнего клика придет через месяцы, и кабинет уже пробует это показывать: появилась метрика прогноза конверсий, которая оценивает, сколько результатов цепочка добавит после отчетного периода. Это оценка, а не факт, и в решениях она работает как поправка на длинный цикл сделки, не более.

Ответы AI-систем. Когда поисковик отвечает текстом, а не списком ссылок, упоминание вашей компании в ответе не создает ни клика, ни строки в отчете. Клики из AI-поверхностей, если они есть, попадают в общую отчетность по поиску без отдельного разреза. На спрос это влияет: люди приходят позже, по названию компании или напрямую. Единственный доступный способ измерения - регулярные замеры видимости вручную: одни и те же вопросы, одни и те же системы, фиксация того, кого называют в ответе. Как реклама попадает на эти поверхности - в материале про рекламу в AI Mode.

Сам Google в 2026 году описывает измерение тремя требованиями: закрыть базу по тегированию и подключить все источники данных, мерить причинный вклад расходов, а не только приписанные конверсии, и проверять результат медиамикс-моделями. Формулировка звучит корпоративно, но направление читается однозначно: отчет кабинета перестал быть единственным основанием для решений даже по версии самой платформы.

Чем крупнее решение, тем менее детальные данные для него нужны. Вопрос «отключать ли ключевое слово» решается по отчету кабинета. Вопрос «сколько канал приносит бизнесу» решается сравнением периодов, тестами с отключением рекламы в отдельных регионах и сведением выручки, а не суммой конверсий в интерфейсе. Крупные рекламодатели закрывают это медиамикс-моделированием, и Google развивает открытый фреймворк Meridian под ту же задачу, но для бизнеса среднего размера дешевле и честнее работают географические тесты: выключить канал в одном регионе, оставить в сопоставимом, сравнить выручку.

Порядок внедрения при ограниченном ресурсе

Полная схема измерения строится месяцами. Если разработка доступна редко, порядок такой - от того, что дает больше всего при минимальных вложениях, к тому, что дорого:

1. Одно основное действие с ценностью. Покупка или заявка, которая приводит клиента. Микрособытия переводятся в дополнительные - они полезны для диагностики воронки и не должны участвовать в назначении ставок. 2. Проверка дублей и источников. Одно действие не должно приходить сразу из нативного тега и из импорта GA4. Одна основная цель на аккаунт, остальное вторичное. 3. Расширенные конверсии. Включаются в настройках конверсионного действия, разработчик для базового варианта не нужен, прирост сопоставленных конверсий заметен на любом объеме. 4. Режим согласия, если есть европейский трафик. Без него часть конверсий не восстанавливается вообще. 5. Возврат статусов из CRM. Сначала хотя бы ручная выгрузка раз в неделю, потом автоматическая через интеграцию. Это самый сильный шаг для лидогенерации. 6. Серверная передача. Последней, когда объем оправдывает обслуживание.

Отдельное правило на случай, когда источник конверсий меняется: новое действие сначала ставят дополнительным и дают ему поработать месяц параллельно со старым. За это время видно, насколько расходятся цифры, и есть с чем сравнивать. Мгновенное переключение основного действия сбивает обучение стратегии ставок, и просадка после такой замены выглядит как проблема с рекламой, хотя менялось только измерение.

Настроенное измерение разъезжается само по себе, поэтому дальше идет режим поддержки. Раз в неделю стоит смотреть статусы конверсионных действий: неактивное действие или резкий скачок числа конверсий означают, что где-то поменялся сайт. Раз в месяц - сверять кабинет с CRM по одному показателю: сколько сделок пришло с рекламы и сколько из них видит кабинет. Разрыв, который держится стабильно, - это ваша рабочая поправка. Разрыв, который скачет от месяца к месяцу, - повод искать причину.

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

Частые вопросы

Почему в Google Ads конверсий больше, чем в GA4?

Системы считают по разным правилам. Google Ads относит конверсию к дате клика и учитывает конверсии, восстановленные моделированием, а также покупки с других устройств, связанные через аккаунт Google. GA4 записывает событие по дате самого события и раздает источники по своим правилам. Разница в 10-20% при рабочей настройке - норма. Расхождение в разы означает другое: дубль конверсионного действия или потерянный тег.

Какое расхождение между кабинетом и CRM считать нормальным?

Стабильное. Важна не величина разрыва, а его постоянство: если кабинет систематически показывает на треть больше сделок, чем CRM, это учитывается поправкой при планировании. Разрыв, который скачет от месяца к месяцу, означает, что что-то поменялось - на сайте, в CRM или в настройке передачи данных.

Что такое моделированные конверсии и можно ли им доверять?

Так Google достраивает результат, когда прямых данных нет: человек отказался от сбора данных, идентификатор клика потерян, покупка прошла с другого устройства. Такие конверсии входят в общий столбец без отдельной пометки. Динамике верить можно, точной цифре - только вместе со сверкой по выручке в CRM.

Нужна ли серверная передача небольшому бизнесу?

Обычно нет. При потоке в несколько десятков заявок в месяц стоимость серверного контейнера и работы разработчика выше, чем ценность возвращенных данных. Расширенные конверсии и импорт статусов из CRM дадут больше за меньшие деньги. Серверная схема оправдана на объеме, при большой доле мобильного трафика и там, где заказ оформляется вне сайта.

Почему конверсии в отчете появляются задним числом?

Кабинет привязывает результат к тому дню, когда человек кликнул по объявлению. Клик в конце месяца, оплата в начале следующего - число за прошлый месяц вырастет после того, как отчет уже сдан. Добавляется техническая задержка: новым событиям из аналитики нужно 24-48 часов, чтобы дойти до рекламного кабинета. По этой причине окончательные цифры за период смотрят с отступом в длину окна конверсии, а не на следующий день.

Что дают расширенные конверсии?

Вместе с событием в Google уходят захешированные почта и телефон, и система опознает человека по своей базе, даже если идентификатор клика не сохранился. Это возвращает часть конверсий, потерянных из-за ограничений браузеров и переходов между устройствами. Включается в настройках конверсионного действия, для базового варианта разработчик не нужен.

Как правильно считать звонки?

Через коллтрекинг, а не через клик по номеру телефона. Клик - это намерение, а не разговор: часть тапов случайные, часть заканчивается сбросом. В конверсии засчитывают звонки длиннее 30-60 секунд и ставят подсчет уникальных, чтобы повторные звонки одного человека не надували статистику.

Можно ли обойтись без CRM и мерить по конверсиям в кабинете?

Можно, пока заявки однородные по качеству и цикл сделки короткий. Как только появляется разброс - часть заявок отваливается на первом звонке, часть приносит крупные сделки - кабинет перестает отражать результат. Классическая картина: цена заявки выглядит отличной, а стоимость продажи по той же кампании оказывается в разы выше допустимой. Без возврата статусов алгоритм оптимизируется на количество обращений и уводит бюджет туда, где обращений много, а денег мало.

Как измерять видимость в ответах AI-систем?

Отчетов по этому нет ни в рекламном кабинете, ни в поисковой консоли: упоминание бренда в сгенерированном ответе не создает клика. Рабочий способ - регулярный ручной замер: список типичных вопросов ниши, фиксированный набор систем, проверка раз в квартал с записью того, кого называют в ответе и на какие источники ссылаются. Это дает динамику, сопоставимую между замерами, чего нет в автоматических отчетах.