Как связать UTM-метки с продажами в 1С Розница

UTM-метки 1С Розница сама не собирает — она их принимает. Метку ставит рекламная ссылка или сайт, в базу она попадает вместе с заказом через обмен, хранится в дополнительном реквизите документа, а анализируется универсальным отчётом с группировкой по источнику. Порядок одинаков для Розницы 2.3 и 3.0, различается лишь мелочами интерфейса.

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

Откуда в рознице берутся UTM-метки

UTM — это пять параметров, которые дописываются в адрес ссылки и показывают, откуда пришёл посетитель:

• 🔹 utm_source — конкретная площадка: yandex, vk, email;
• 🔹 utm_medium — тип трафика: cpc (платный клик), social, email;
• 🔹 utm_campaign — название кампании: autumn_sale;
• 🔹 utm_content — конкретное объявление или баннер;
• 🔹 utm_term — ключевое слово (для контекста).

Выглядит это так:

https://shop.example.ru/?utm_source=yandex&utm_medium=cpc&utm_campaign=autumn_sale

Главное: метка живёт в браузере и на сайте, а не в 1С. Розница никогда не видит сам адрес ссылки. Поэтому задача сводится к одному — сохранить метку в заказ на стороне сайта, а потом передать её в базу вместе с остальными данными заказа.

Работает это по модели last-click: сайт запоминает метку из ссылки, по которой человек пришёл, и держит её в cookie до оформления заказа. Если покупатель зашёл по рекламе, неделю думал и вернулся напрямую — засчитается тот источник, который сайт сохранил последним. Логику атрибуции (last-click, first-click, многоканальная) задают на стороне сайта и аналитики, в 1С приходит уже готовый результат — одна метка на заказ.

Что подготовить перед настройкой

Прежде чем что-то настраивать, проверьте три вещи. Без них метка просто некуда будет записать.

Пояснения по пунктам:

1. Хранилище для метки. В типовой Рознице нет готового поля «источник заказа». Его роль выполнит дополнительный реквизит — механизм, который есть в конфигурации и не требует правки кода.
2. Канал передачи. Заказы приходят в Розницу через обмен: по стандарту CommerceML, через API интернет-магазина или через управляющую систему (УТ, ERP). Без работающего обмена передавать нечего.
3. Сохранение метки на сайте. Самая частая точка потери. Если сайт не кладёт UTM в заказ (обычно через cookie по модели last-click), то в 1С приходить будет пусто. Эту часть настраивают разработчик сайта или маркетолог — до того, как браться за 1С, имеет смысл убедиться, что метка вообще доживает до оформления.

Куда класть метку: дополнительный реквизит заказа

Поле под метку создаётся без программирования — через дополнительные реквизиты.

1. Откройте Администрирование → Общие настройки и включите флажок «Дополнительные реквизиты и сведения». Название раздела в вашем релизе может отличаться на слово-два, но находится оно в настройках администрирования.
2. Перейдите к набору дополнительных реквизитов документа заказа и добавьте реквизит — например, «Источник заказа», тип значения Строка.
3. Для анализа чаще всего достаточно двух-трёх реквизитов: отдельно utm_source и utm_campaign (по ним строят отчёт), остальные параметры можно свести в один общий реквизит.

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

Реквизит привязывают к тому документу, в котором онлайн-заказ оседает после обмена. В Рознице это, как правило, заказ клиента : именно он приходит с сайта, тогда как чек ККМ пробивается уже при продаже и метку по нему вести бессмысленно. Если заказ в рознице после оплаты закрывается чеком, метку достаточно хранить на заказе — отчёт всё равно строится по нему.

Как передать метку с сайта в заказ

Создать реквизит мало — его ещё нужно наполнить данными из обмена. Здесь важно, чтобы метка прошла два рубежа без потерь: попала в пакет обмена и легла в нужное поле 1С.

Что происходит на практике:

• На стороне сайта. Платформа интернет-магазина сохраняет метку в заказ и добавляет её в выгружаемый пакет. В CommerceML произвольные данные заказа передают как значения реквизитов документа.
• На стороне 1С. При загрузке заказа значение из пакета нужно разложить по созданным дополнительным реквизитам.

Здесь кроется нюанс. Стандартный обмен CommerceML про UTM ничего не знает. Он переносит номенклатуру, количество, цены и типовые реквизиты заказа. Чтобы метка доехала до реквизита, передачу произвольных полей настраивают в правилах обмена, а если правила такой гибкости не дают — обработкой загрузки или расширением (следующий раздел).

Если интернет-магазин общается с базой не файловым обменом, а через веб-сервис или REST API, картина проще: метку добавляют отдельным полем в тело запроса, а приёмная сторона раскладывает его по реквизитам. Но и тут поле не появится само — его закладывают при настройке интеграции. Какой бы канал ни использовался, правило одно: метка должна быть явно описана и на отправке, и на приёме, иначе она теряется на границе систем.

Ещё один практичный ход — не плодить по реквизиту на каждый из пяти параметров. Для анализа рекламы хватает источника и кампании; utm_content и utm_term при желании складывают в один строковый реквизит через разделитель и разбирают уже в отчёте. Меньше полей — меньше точек, где обмен может «не довезти» значение.

Если метки доходят, но приходят «кракозябрами» — почти всегда это кодировка пакета. Проверьте, что обмен идёт в UTF-8 с обеих сторон.

Перед первой полноценной передачей выгрузите один тестовый заказ и посмотрите его в базе: пришёл ли реквизит заполненным. Так проще локализовать разрыв. Если метка есть в пакете, но реквизит пуст — проблема в загрузке на стороне 1С. Если метки нет и в пакете — разбираться нужно с сайтом. Делать это удобнее на одном заказе, пока данные не накопились вперемешку.

Автоматизация: расширение вместо правки конфигурации

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

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

Что обычно делает такое расширение:

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

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

Альтернатива расширению на старте — ручное заполнение. Пока заказов немного, менеджер может вписывать источник в реквизит руками, сверяясь с системой аналитики сайта. Это не масштабируется, но позволяет проверить саму идею отчёта по каналам до того, как вкладываться в доработку обмена.

Отдельно про «автоматическое создание маркетинговых акций» по меткам. Маркетинговая акция в Рознице — это инструмент скидок и бонусов, а не аналитики. Привязывать акции к UTM автоматически — нетиповая доработка, и в большинстве случаев она не нужна: для оценки рекламы достаточно, чтобы метка лежала в реквизите и попадала в отчёт. Автоматика оправдана, только если канал должен включать конкретную скидку, — тогда логику описывают в том же расширении.

Отчёт по эффективности рекламных каналов

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

Порядок такой:

1. Откройте универсальный отчёт (в разделе отчётов конфигурации).
2. Источником выберите документ заказа или регистр продаж.
3. Добавьте группировку по дополнительному реквизиту «Источник» и, вторым уровнем, «Кампания».
4. В показатели поставьте сумму продаж и количество заказов, задайте отбор по периоду.

На выходе — таблица «канал → выручка → число заказов → средний чек». По ней сразу видно, какой источник окупается, а какой только тратит бюджет.

Группировка по двум уровням — источник, внутри него кампания — отвечает сразу на два вопроса: какая площадка приносит больше денег и какая конкретная кампания внутри неё сработала. Если добавить третьим уровнем utm_content, видно и то, какой баннер или объявление ведёт к покупкам. Отбор по периоду позволяет сравнивать месяцы или отдельные рекламные волны между собой.

Что считать по этой таблице и откуда брать недостающие цифры:

1С покажет только выручку по каналу — стоимость клика и показа остаётся на стороне рекламной системы. Конверсию «клик → покупка» в чистом виде база тоже не посчитает: число кликов знает рекламный кабинет, число заказов — 1С, и сопоставляют их вручную по общему признаку источника. Поэтому полную окупаемость (ROMI) считают, сводя выручку из отчёта с расходами из рекламного кабинета. Заказы без метки выносите в отдельную группу «без источника» — это нормальная категория (офлайн и прямые заходы), удалять её из отчёта не нужно.

Частые ошибки при передаче меток

Большинство сбоев — не в 1С, а в том месте, где метка должна была сохраниться или передаться.

• 🔸 В реквизите пусто у всех заказов. Сайт не сохраняет метку в заказ: не настроена cookie last-click либо метки нет в пакете обмена. Проверяют с сайта, а не из 1С.
• 🔸 Метка есть в пакете, но реквизит пуст. Правило обмена не заполняет реквизит или не подключено расширение. Смотрят настройку загрузки.
• 🔸 Вместо текста «кракозябры». Рассогласование кодировок пакета, нужен UTF-8.
• 🔸 Метка задвоилась или реквизитов два. Набор дополнительных реквизитов создали дважды — лишний удаляют, чтобы отчёт не дробил данные.
• 🔸 Часть заказов без источника. Это не ошибка: офлайн-продажи и прямые заходы метки не имеют.

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