Достаточно ли данных для MTA: проверка покрытия путей
Аудит данных перед MTA: связываем заказы с путями, считаем пропуски по сегментам и определяем, какие решения выдерживает неполная наблюдаемость.
Тысячи событий в аналитике могут принадлежать сотне хорошо отслеживаемых покупателей. Остальная база при этом остаётся за пределами отчёта. Перед MTA я бы проверил, кого именно видит система и какие решения позволяют принять эти данные.
Начните с управленческого вопроса: сравниваете источники заявок, оплаченных заказов или повторных продаж? У них разные события и идентификаторы. Если задача касается денег, а в наборе есть только отправки формы, сложная модель распределит кредит за заявки. Она не добавит отсутствующие оплаты.
Соберите карту от результата к касаниям
Выберите закрытый период конверсий и источник их контрольного количества: например, оплаченные заказы из учётной системы после удаления тестов и дублей. Затем двигайтесь назад по цепочке. Каким ключом заказ связан с клиентом? Каким ключом клиент связан с посещением? Где сохраняются источник, время и тип взаимодействия?
Для каждого соединения запишите таблицы, поля и правило сопоставления. Одинаковые имена или близкие даты не заменяют устойчивый ID. Если связь строится вероятностно, отметьте это отдельно от точного соединения. Сверку исходных количеств полезно выполнить по схеме GA4, Метрика и CRM до расчёта долей каналов.
| Участок | Доступная запись | Возможный разрыв | Что проверить |
|---|---|---|---|
| Посещение → заявка | ID сессии, время, ID заявки | Форма открывается на другом домене | Один контрольный путь до и после перехода |
| Заявка → заказ | ID заявки в CRM и заказе | Сделку создали вручную без связи | Доля заказов с проверяемым ключом |
| Заказ → оплата | ID заказа и статус платежа | Статус обновляется с задержкой | Время выгрузки и правила финального статуса |
| Раннее касание → покупка | История событий до конверсии | История начинается слишком поздно | Доступная глубина наблюдения |
GA4 использует собственные правила идентификации. В официальной справке cross-domain measurement описано, как при согласии пользователя идентификаторы передаются между доменами через параметр _gl. Без такой настройки разные корневые домены могут создать отдельные ID. Это проверка одного разрыва; она не восстанавливает всю межустройственную и офлайн-историю.
Общий процент скрывает место потери
В условной выгрузке есть 100 оплаченных заказов. Проверяем две отдельные характеристики: удалось ли связать заказ с цифровым путём и есть ли в нём хотя бы два наблюдаемых касания. Вторая характеристика не называется «полным путём»: его реальную полноту мы не знаем.
| Сегмент | Заказы | Связаны с путём | Есть минимум два касания |
|---|---|---|---|
| Компьютеры | 60 | 54 | 36 |
| Телефоны | 40 | 20 | 8 |
| Всего | 100 | 74 | 44 |
Общее покрытие соединением: 74 / 100 = 74%. На компьютерах оно равно 54 / 60 = 90%, на телефонах — 20 / 40 = 50%. Если сравниваемые каналы приводят разную долю мобильных покупателей, модель увидит их неодинаково. Делить 44 на 74 можно, но это уже другой показатель: доля многокасательных путей среди соединённых заказов, около 59,5%.
Не складывайте проценты разных проверок. Один заказ может одновременно не иметь источника и страдать от разрыва домена. Для оценки пересечений нужен построчный набор с флагами, а не сумма счётчиков ошибок.
Как понять, достаточно ли этого для решения
В описании атрибуции Google DDA использует конверсионные и неконверсионные пути, порядок взаимодействий и время. Простая таблица только с покупателями не воспроизводит такой алгоритм. Модели из обзора атрибуции каналов требуют проверки на собственных условиях; единого количества конверсий, после которого любые данные становятся пригодными, нет.
Я бы разделил решения на три уровня. Можно описывать доступные пути, если понятны их состав и ограничения. Можно сравнивать каналы внутри сопоставимого сегмента, если пропуски и определения не делают сравнение заведомо разным. Перераспределение бюджета потребует проверки чувствительности результата и других свидетельств, особенно когда большой канал почти не наблюдается.
Если неизвестны ключи соединения или пропуски резко различаются между каналами, остановите именно сравнительный вывод. Сбор данных и диагностика продолжаются. Не нужно объявлять весь отчёт бесполезным, но нельзя превращать удобную наблюдаемую часть базы в описание всех покупателей.
Что должно остаться после аудита
Сохраните версию выгрузки, определение конверсии, карту соединений, таблицу покрытия по сегментам и список непроверяемых касаний. Рядом запишите разрешённый вывод: например, «сравниваем цифровые пути веб-заказов с устойчивым ID; телефонные продажи исключены и показываются отдельно».
Следующий шаг должен исправлять обнаруженный разрыв. Если проблема в оплатах, добавление ещё одного события просмотра не поможет. Возьмите несколько заказов из каждой проблемной группы и проследите их вручную до источника: эта проверка часто полезнее настройки ещё одного алгоритма.