Как настроить атрибуцию продаж с BTL-акции через QR-коды и промокоды

При офлайн-атрибуции определяют, после какого офлайн-контакта покупатель совершил покупку. Для этого физический контакт с BTL-акцией (промоакцией прямого контакта с покупателем) и последующий заказ связывают по общему набору идентификаторов. При контакте идентификатор QR-носителя (материала с размещенным QR-кодом) или промокод сохраняют в CRM и добавляют в заказ. Затем по идентификатору или промокоду в отчете связывают продажу с кампанией, точкой и материалом. Такая схема показывает путь покупателя, который можно отследить, но сама по себе не доказывает, что акция обеспечила прирост продаж.

На практике данные с промоматериала или от промоутера через QR-переход и лендинг поступают в CRM. Затем их связывают с заказом в кассовой системе, передают в Яндекс Метрику или Google Analytics 4 (GA4) и включают в итоговый отчет. Базовый контекст по форматам активаций дает материал о том, что такое BTL-реклама и какие задачи она решает.

Как работает атрибуция продаж с BTL-акции

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

Какие события образуют путь от контакта до заказа

Настройка включает семь последовательных действий:

1. Определить единицы учета: кампанию, город, точку, промоутера и физический носитель;

2. Присвоить этим единицам технические идентификаторы без персональных данных;

3. Добавить идентификаторы и UTM-параметры в QR-ссылку;

4. Сохранить параметры перехода и доступный идентификатор пользователя вместе с лидом в CRM;

5. Передать идентификаторы кампании, контакта и промокода в заказ;

6. Отправить завершенную покупку, сумму, валюту и идентификатор заказа в аналитическую систему;

7. Проверить уникальность заказов, потери полей, отмены и возвраты до расчета результата.

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

Где заканчивается наблюдаемая связь и начинается оценка эффекта

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

Что выбрать для отслеживания: QR-код, промокод или их сочетание

Когда достаточно QR-кода

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

Когда нужен промокод

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

Когда полезны обе механики

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

Какие идентификаторы нужны от промоматериала до заказа

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

В этой схеме идентификаторы кампании относятся к справочникам, а contact_id и order_id — к отдельным контактам и заказам. Email, телефон и ФИО из соображений безопасности и приватности не стоит помещать в QR-ссылку или промокод. transaction_id не должен содержать данные, позволяющие идентифицировать пользователя, согласно справке GA4. В отчет попадут только те разрезы, данные для которых передали по всей цепочке.

Как разметить QR-ссылку и различать физические носители

Условный URL передает данные о кампании, точке, промоутере и материале через UTM-разметку и собственные параметры:

https://promo.example/action?utm_source=btl&utm_medium=qr&utm_campaign={campaign_id}&utm_content={point_id}.{creative_id}&campaign_id={campaign_id}&city_id={city_id}&point_id={point_id}&promoter_id={promoter_id}&creative_id={creative_id}

Где:

• https://promo.example/action — условный адрес лендинга;

• utm_source — параметр источника, а литерал (заранее заданное текстовое значение) btl обозначает согласованную группу офлайн-размещений;

• utm_medium — параметр способа перехода, а литерал qr обозначает QR-код;

• utm_campaign — параметр кампании, который получает значение {campaign_id};

• utm_content — параметр варианта размещения, составленный из {point_id} и {creative_id} через разделитель .;

• campaign_id — внутренний идентификатор кампании;

• city_id — внутренний идентификатор города;

• point_id — внутренний идентификатор точки;

• promoter_id — внутренний идентификатор промоутера, если кампания поддерживает такой разрез;

• creative_id — внутренний идентификатор физического носителя или версии материала;

• Фигурные скобки {} — обозначение значения, которое генератор ссылок подставляет из справочника.

Для стороннего QR-кода Яндекс Метрика рекомендует использовать utm_medium=qr или utm_medium=qrcode. Параметры utm_campaign и utm_content различают кампании и физические носители, если значения последовательно заданы в справочнике согласно документации Яндекс Метрики.

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

Как передать данные QR-перехода в CRM

Какие поля сохранить при первом контакте

Лендинг считывает UTM-параметры и внутренние идентификаторы из URL, сохраняет их в браузере или серверной сессии (временном хранилище данных визита) и добавляет в скрытые поля формы, невидимые пользователю. После отправки формы сервер создает contact_id и записывает время контакта. Если в выбранной системе доступен аналитический идентификатор, интеграция сохраняет его в отдельном поле, не заменяя им идентификатор другого типа.

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

Как связать форму, звонок или регистрацию с записью CRM

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

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

Как связать промокод и офлайн-покупку с BTL-акцией

Покупка после QR-перехода

После QR-перехода CRM связывает contact_id с лидом или сделкой. При создании заказа касса или интернет-магазин получает contact_id, доступные поля кампании и примененный promo_code. Затем система присваивает заказу order_id и сохраняет его во всех событиях оплаты, отмены и возврата.

Покупка только по промокоду

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

Для анализа таких заказов отчет Яндекс Метрики «Промокоды» группирует покупки и доход по кодам. Система сформирует его, если получает данные электронной торговли в соответствии с документацией сервиса.

Покупка без доступного идентификатора контакта

Если заказ не содержит промокода, contact_id, ClientId, UserId или другого допустимого ключа, система не сможет детерминированно (однозначно по общему идентификатору) связать его с конкретным контактом на акции. Заказ останется в общих продажах: его можно будет учесть при оценке общего эффекта по группам, но в атрибуционном отчете ему не будут искусственно приписывать источник.

Как задать окно атрибуции и разрешать конфликты источников

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

Поэтому спецификация кампании должна отвечать на следующие вопросы:

• Какое событие открывает окно: QR-переход, регистрация, выдача кода или другое фиксируемое действие;

• Какое событие закрывает окно: покупка, окончание срока предложения или установленная дата;

• Как система выбирает источник при нескольких QR-переходах: первый допустимый, последний допустимый либо заранее описанная многоканальная схема;

• Как система учитывает QR-источник и промокод: выбирает один источник по утвержденному приоритету или сохраняет два признака без двойного учета заказа;

• Какие статусы заказа входят в результат и в какой момент продажа считается завершенной;

• Как отчет обрабатывает повторную загрузку события, отмену и возврат.

Что делать с несколькими QR-переходами

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

Как разрешить конфликт между QR-источником и промокодом

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

Как выбрать окно для отложенной покупки

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

Как передать офлайн-продажи в Яндекс Метрику и GA4

Импорт офлайн-данных в Яндекс Метрику

Пакет офлайн-данных формируют после того, как CRM или касса подтвердит нужный статус заказа. В запись добавляют один из поддерживаемых идентификаторов, по которому система сопоставит офлайн-конверсию с данными визита, а также время конверсии, цель или тип события и сумму, если она известна. Яндекс Метрика поддерживает связь через ClientId, UserId, Yclid или PurchaseId и принимает данные через CSV (табличный формат обмена данными) либо API по правилам импорта офлайн-данных.

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

Передача события покупки через GA4 Measurement Protocol

GA4 Measurement Protocol принимает серверные события в POST-запросах по HTTPS. Для веб-потока (источника веб-данных в GA4) тело запроса содержит обязательный client_id, необязательный user_id и массив events. Параметр timestamp_micros задает время события в микросекундах и применяется к событиям, произошедшим в прошлом согласно справочнику Measurement Protocol.

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

Какие параметры проверить после отправки

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

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

Как исключить дубли и учесть отмены и возвраты

Как работает transaction_id в GA4

Один заказ должен получать один постоянный order_id, который передается в GA4 как transaction_id. GA4 дедуплицирует покупки с одинаковым transaction_id, то есть удаляет повторы; пустая строка может привести к дедупликации всех покупок с таким значением. Этот механизм действует для данных веб-потоков и не применяется к потокам приложений (источникам данных мобильных приложений) согласно справке GA4.

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

Как хранить статус заказа

Карточка заказа должна хранить исходную сумму, статус оплаты, дату изменения, возвращенную сумму и ссылку на исходный order_id. Полная отмена исключает заказ из завершенных продаж. При частичном возврате заказ сохраняется, а чистый доход уменьшается на фактически возвращенную сумму.

С учетом этих статусов чистый доход после возвратов рассчитывают по формуле:

Чистый доход = доход по завершенным заказам − сумма возвратов

Где:

• Чистый доход — сумма за вычетом возвратов;

• Доход по завершенным заказам — сумма заказов, которые соответствуют принятому статусу продажи;

• − — операция вычитания;

• Сумма возвратов — фактически возвращенная покупателям сумма, включая возврат всей стоимости или ее части.

Как пересчитать результат после возврата

В условном примере показано, как учитывают завершенный заказ, частичный возврат и отмену:

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

Как найти участок, на котором теряются идентификаторы

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

Какие контрольные числа сравнивать

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

Как проверить события и их параметры

В Google Analytics 4 (GA4) такую проверку проводят через DebugView: инструмент показывает события электронной торговли и их параметры по мере поступления. В нем можно увидеть имя события, transaction_id, сумму и товарные данные до анализа стандартных отчетов согласно инструкции Google.

Как оформить журнал расхождений

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

Какие метрики включить в отчет по BTL-акции

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

Как считать конверсию и стоимость связанной продажи

Для расчета конверсии в покупку заранее выбирают знаменатель:

Конверсия в покупку = завершенные связанные покупки ÷ допустимые контакты × 100%

Где:

• Конверсия в покупку — доля допустимых контактов, завершившихся связанной покупкой;

• Завершенные связанные покупки — уникальные заказы с нужным статусом, соответствующие правилу атрибуции;

• ÷ — операция деления;

• Допустимые контакты — выбранный знаменатель: учтенные офлайн-контакты, QR-визиты или лиды;

• × 100% — перевод доли в проценты.

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

Стоимость связанной продажи = расходы на акцию ÷ завершенные связанные покупки

Где:

• Стоимость связанной продажи — расходы на один технически атрибутированный завершенный заказ;

• Расходы на акцию — согласованный состав затрат на проведение и измерение кампании;

• ÷ — операция деления;

• Завершенные связанные покупки — уникальные заказы после исключения отмен и дублей.

Он показывает стоимость связанной продажи по данным атрибуции. Чтобы рассчитать инкрементальный ROMI (окупаемость подтвержденного прироста от маркетинга), фактический результат дополнительно сравнивают с результатом контрольного сценария.

Как считать окупаемость с учетом прироста

Инкрементальный ROMI рассчитывают по дополнительной валовой прибыли, подтвержденной выбранным дизайном оценки:

Инкрементальный ROMI = (инкрементальная валовая прибыль − расходы на акцию) ÷ расходы на акцию × 100%

Где:

• Инкрементальный ROMI — возврат маркетинговых инвестиций с учетом причинно оцененного прироста;

• Инкрементальная валовая прибыль — дополнительная валовая прибыль относительно контрфактического результата;

• − — операция вычитания;

• Расходы на акцию — согласованный состав маркетинговых затрат;

• ÷ — операция деления;

• × 100% — перевод отношения в проценты.

Какие разрезы поддерживает минимальный отчет

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

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

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

Почему атрибутированные продажи не равны приросту продаж

Что показывает техническая атрибуция

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

Когда нужна контрольная группа

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

Как геоэксперимент оценивает причинный эффект

В геоэксперименте непересекающиеся территории распределяют между тестовыми и контрольными условиями, а эффект оценивают по различию результатов при соблюдении дизайна согласно методологии Google Research. Для небольшого числа территорий Time-Based Regression прогнозирует контрфактический временной ряд и оценивает накопленный причинный эффект при выполнении допущений модели согласно описанию метода.

Причинный эффект оценивают по разнице между наблюдаемым и контрфактическим результатом:

Инкрементальный эффект = результат тестовой группы − контрфактический результат без акции

Где:

• Инкрементальный эффект — оценка дополнительного результата, вызванного воздействием при выполнении допущений дизайна;

• Результат тестовой группы — фактически наблюдаемые продажи, прибыль или другой заранее выбранный показатель;

• − — операция вычитания;

• Контрфактический результат без акции — оценка показателя, который ожидался бы без воздействия.

Заключение

Чтобы атрибуция продаж к BTL-акции давала корректный результат, нужно выполнить два условия. Первое — обеспечить сквозную связь между идентификаторами покупателя, заказа и точки контакта (QR-кода или промокода) на всем пути заказа. Второе — до расчета результата утвердить правила: как задается окно атрибуции, как разрешаются конфликты и как учитываются статусы заказов и возвраты. При соблюдении этих условий можно посчитать продажи, связанные с акцией, и выявить разрывы в данных между системами — например, когда чек есть, а сканирования QR нет. При этом QR-коды и промокоды дают данные для наблюдательной атрибуции, но не доказывают причинность: чтобы утверждать, что рост продаж вызван именно акцией, нужен эксперимент или сравнение с контрольной группой.