Атрибуция не находит единственную «истинную причину» покупки. Она применяет правило или алгоритм к тем контактам, которые система смогла наблюдать, и распределяет между ними кредит за конверсию. Последний клик отдаёт результат завершающему контакту и по конструкции не показывает полный вклад ранних этапов. Первый контакт отвечает на другой вопрос. Алгоритмическая модель использует доступные данные, но всё равно ограничена окнами, идентификацией и consent. Причинный прирост проверяют отдельным экспериментом.
Три слоя, которые нельзя смешивать
Слой | Что в нём есть | Какой вывод допустим |
|---|---|---|
Наблюдение | Зафиксированные визиты, клики, показы, UTM, события, CRM-заказы. | Какие контакты система увидела и связала. |
Атрибуция | Правило, окно, scope и алгоритм распределения кредита. | Как отчёт приписал наблюдаемую конверсию. |
Инкрементальность | Контрфактуальное сравнение с тем, что было бы без воздействия. | Какой результат вызвало изменение при допущениях дизайна. |
Хорошая разметка улучшает первый слой, но не создаёт третий. Если человек увидел публикацию, перешёл из поиска, позже кликнул рекламу и вернулся напрямую, UTM последнего объявления достоверно описывает один переход. Она не доказывает, что без объявления покупки не было бы. Атрибуционная модель может распределить кредит между контактами, но формулировка «канал создал 40 продаж» требует более сильного причинного основания.
Один путь, четыре разных ответа
Представим синтетический путь: в понедельник человек впервые пришёл из поиска и прочитал обзор; в среду открыл письмо; в пятницу перешёл по платному объявлению; в воскресенье ввёл адрес напрямую и оплатил. Сам путь один, но вопросы различаются. Первый контакт показывает источник знакомства. Последний переход описывает текущий визит. Последний значимый контакт может перенести кредит с прямого захода на объявление. Алгоритмическая модель распределит вес по своим данным и правилам. Ни один вариант не меняет историю — меняется аналитическая линза.
Поэтому сначала сформулируйте вопрос отчёта. «Где люди впервые знакомятся?» требует first-touch логики. «Какой источник непосредственно предшествовал оплате?» — last-touch. «Какие наблюдаемые контакты получают кредит по платформенному алгоритму?» — data-driven или automatic в границах системы. «Что произойдёт, если выключить канал?» — это уже вопрос инкрементальности, и одной смены модели недостаточно.
Сравнительная схема моделей атрибуции
Модель или схема | Куда идёт кредит | Полезный вопрос | Главная слепая зона |
|---|---|---|---|
Последний переход | Контакту текущего или последнего визита по правилам системы. | Что непосредственно завершило наблюдаемый путь? | Ранние контакты теряют вес; прямой заход может забрать завершение. |
Последний значимый переход | Последнему контакту, который система считает значимым. | Что предшествовало прямому возврату? | Классификация «значимости» зависит от платформы. |
Первый переход | Первому наблюдаемому источнику в истории или окне. | Где начинается знакомство? | Не показывает контакты, которые довели до решения. |
Data-driven / automatic | Контактам по алгоритму и доступным данным платформы. | Как система распределяет кредит с учётом путей? | Непрозрачность деталей, потерянные контакты и зависимость от данных. |
Линейная, time decay, position based | По заранее заданным весам между контактами. | Как выглядел бы отчёт при иной политике кредита? | Вес является правилом, а не оценкой причинности; в Google эти модели устарели. |
Последняя строка — концептуальные схемы для понимания и исторического сравнения. Google сообщает, что first click, linear, time decay и position-based больше не поддерживаются в Google Ads, а в GA4 были удалены из актуального набора. Не стройте инструкцию по интерфейсу на старой таблице из учебника. Для каждого отчёта проверяйте фактически доступные настройки в день анализа.
Текущее состояние Яндекс Метрики
Русская справка Метрики на дату проверки перечисляет последний переход, первый переход кросс-девайс, последний значимый переход кросс-девайс и автоматическую атрибуцию. С 20 мая 2026 года прежние варианты, включая отдельные старые модели, отключены. Для моделей с историей действует окно: после перерыва между визитами в 90 дней прежняя история завершается, и пользователь не может изменить это правило. Это продуктовое условие нужно хранить в отчёте.
Кросс-девайс и автоматическая атрибуция могут объединять больше наблюдений, чем cookie одного браузера, но это не означает полное знание пути. Объясните, включён ли режим, с какой даты доступны данные и можно ли сравнивать его с прошлым периодом. При смене модели пересчитайте сравнительный срез или поставьте разрыв ряда; нельзя приписывать изменение каналов поведению аудитории, если поменялась аналитическая линза.
Почему два отчёта показывают разные цифры
Разный scope: первый пользователь, сессия или событие.
Разная цель либо определение конверсии, статуса оплаты и возврата.
Разное окно атрибуции, часовой пояс и дата признания конверсии.
Разная идентификация между браузерами, устройствами, CRM и офлайн-заказами.
Разный набор наблюдаемых каналов и правила direct traffic.
Разная зрелость данных, задержка импорта и последующее моделирование.
Потерянные UTM, click IDs или параметры на редиректе.
Разный учёт расходов, НДС, валюты, спам-заказов и отмен.
Google Analytics отдельно документирует scope источников: user- и session-scoped dimensions используют собственные правила, а event-scoped измерения зависят от выбранной модели свойства. Поэтому Session source и источник, которому присвоен кредит key event, могут не совпасть и оба быть корректными в своих определениях. Прежде чем искать ошибку в цифре, сопоставьте словарь полей.
Consent, моделирование и зрелость
Выбор пользователя и технические ограничения меняют объём наблюдаемых данных. Google consent mode управляет поведением тегов в зависимости от согласия, а платформы могут моделировать часть ненаблюдаемых key events. Модельный результат не следует выдавать за прямое наблюдение. В отчёте укажите, включено ли моделирование, какой объём или статус сообщает платформа и какие сегменты исключены из прямого сравнения.
Атрибуционные цифры могут дозревать. Google предупреждает, что кредит по key events способен изменяться до двенадцати дней после регистрации события. Значит, вчерашний канал нельзя окончательно оценивать сегодня без оговорки. Установите лаг отчёта: например, фиксируйте закрытый период только после документированного окна зрелости конкретной системы. Это не универсальные двенадцать дней для всех платформ, а пример продуктового ограничения.
Протокол сверки платформ
Выбрать одну конверсию и записать её техническое и бизнес-определение.
Зафиксировать модель, окно, scope, часовой пояс, валюту и дату зрелости в каждой системе.
Сверить общее число фактических оплаченных заказов до распределения по каналам.
Проверить покрытие CRM-связки, UTM, click ID, редиректов и офлайн-импорта.
Сравнить один и тот же закрытый период и не смешивать дату клика с датой оплаты.
Объяснить остаточное расхождение категориями, а не принудительно свести суммы.
Сохранить версии настроек и повторить сверку после изменения модели.
Выберите систему принятия решения, но не называйте её абсолютной истиной. CRM может быть источником статуса оплаты и суммы, аналитика — пути визитов, рекламный кабинет — показа и расхода. Сводный слой соединяет их и показывает несвязанный остаток. Если сумма распределённых конверсий отличается от CRM, это сигнал качества данных или границ отчёта, а не повод пропорционально дорисовать недостающие продажи каналам.
Где начинается причинная проверка
Если решение звучит «увеличить бюджет, потому что канал получил кредит», задайте контрфактуальный вопрос: сколько покупок произошло бы без дополнительного бюджета? Ответ может потребовать рандомизированного holdout, геоэксперимента или другого заранее обоснованного причинного дизайна. Простое before/after сравнение уязвимо для сезонности, цены, конкурентов и параллельных кампаний. А смена last click на data-driven меняет распределение уже наблюдаемых конверсий, но сама по себе не создаёт новые.
Платформенная data-driven модель может использовать контрфактуальные элементы внутри своего алгоритма, однако бизнес всё равно должен понимать доступный scope, наблюдаемость и назначение результата. Не переносите автоматически кредит конкретного аккаунта на решение об отключении всего канала. Для значимого бюджета проведите отдельный тест, заранее выбрав primary, MDE и guardrails.
Практический следующий шаг
Возьмите одну завершённую неделю после окна зрелости и выгрузите четыре числа: фактические оплаты CRM, конверсии текущей модели, конверсии последнего перехода и несвязанные заказы. Рядом запишите scope, окно, режим cross-device, статус моделирования и дату выгрузки. Объясните разницу на одном синтетическом пути и только затем обсуждайте бюджет. Если вопрос остаётся причинным, сформулируйте эксперимент вместо очередного переключения модели.
Журнал настроек как часть данных
Сохраняйте не только выгрузку, но и конфигурацию, по которой она построена: идентификатор цели, модель, окно, scope, cross-device, валюта, часовой пояс, фильтры, статус consent и дату последней обработки. Скриншота интерфейса недостаточно, если он не позволяет воспроизвести выбор. При изменении настройки создайте новую версию и отметьте первый затронутый день. Тогда резкий перераспределённый кредит не будет ошибочно принят за изменение поведения аудитории.
Для регулярной сверки заведите таблицу расхождений: категория, сумма или число заказов, предполагаемая причина, подтверждающее наблюдение, владелец и статус. Допустимые категории — иной период признания, несвязанный CRM-заказ, потерянная метка, возврат, моделируемая конверсия, другая цель и ещё не созревшие данные. Строка «платформы считают по-разному» слишком общая и не помогает улучшить измерение. Остаток без объяснения сохраняется отдельной категорией UNKNOWN, а не распределяется вручную.
Обсуждение
Комментарии
Обсуждение загрузится при приближении к разделу.