Сквозная аналитика для e-com: как связать 93% заказов с визитами в Метрике

Заказчик
Z51.ru — крупный интернет-магазин игровых кресел и периферии, активно использующий RetailCRM и онлайн-рекламу.
Задача
Связать данные о заказах из RetailCRM с визитами в Яндекс Метрике для точной оценки эффективности трафика и выручки по каналам.

Клиент и его задача

Z51.ru — крупный интернет-магазин игровых кресел и периферии — обратился к нам с конкретным запросом: «Нужно, чтобы данные о заказах из RetailCRM были видны в Яндекс Метрике вместе со стоимостью каждого заказа». Звучит просто, но в реалиях e-commerce эта задача  требует детальной настройки сквозной аналитики и точной атрибуции визитов и заказов.

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

С чего начали

На первом этапе мы реализовали базовую настройку сквозной аналитики с помощью готового коннектора из маркетплейса RetailCRM. Это позволило отправлять заказы из CRM в Метрику. Однако вскоре стало понятно, что одного этого шага недостаточно.

 

По итогам тестового периода с 25 ноября 2024 по 1 декабря 2025 года Яндекс Метрика отобразила только 438 заказов, в то время как в самой RetailCRM их было зарегистрировано 845. 

Таким образом, после настройки сквозной аналитики при помощи одного из готовых коннекторов из магазина модулей RetailCRM нам удалось увидеть в Метрике менее 52% от общего числа заказов.

Такое расхождение — частая история: Метрика показывает только те заказы, которые она смогла связать с конкретными визитами пользователей. Также важно помнить, что спам-заказы не учитываются в столбце «Все заказы» в отчетах Метрики, а отсутствие уникального идентификатора клиента (ClientID) делает атрибуцию невозможной для части заказов.

Новый план действий

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

  • Выгрузили уникальные внешние ID заказов.
  • Запросили «сырые» данные при помощи Яндекс LogsAPI и обработали их при помощи Python.

После анализа результатов выяснилось: практически все заказы из CRM передаются в Метрику, но часть из них имеет некорректные внешние ID — именно они не попадали в отчеты.

Следующий шаг — реализация и проверка результатов.

Шаг 2. Настроили передачу ClientID с сайта в CRM

Цель — повысить процент связки заказов с визитами до 90-100%. Для этого реализовали передачу ClientID в профиль клиента в RetailCRM.

Что сделали технически:

  • Убедились, что счетчик Метрики корректно установлен на всех страницах сайта, включая личный кабинет.
  • Добавили JavaScript-код для получения ClientID с помощью метода:
  • Создали скрытое поле на форме заказа, куда автоматически подставляется ClientID, который затем записывается в профиль клиента в CRM.
  • Настроили отправку формы так, чтобы вместе с данными заказа в RetailCRM передавался и ClientID.
  • При входе пользователя в личный кабинет сайта реализовали автоматический апдейт профиля клиента в CRM — с сохранением ClientID в нужном поле.

Почему это важно:

1. Проверка отображения заказов в Метрике

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

Что дала: выявили, что заказы приходят, но многие из них остаются «анонимными» — без визита, к которому их можно привязать.

2. Добавление ClientID в CRM


Зачем: ClientID — это «мост» между визитом на сайте и заказом в CRM. Без него аналитика не может сопоставить одно с другим.

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

3. Автоматическое сохранение ClientID в профиле клиента CRM

Зачем: чтобы передавать ClientID автоматически при каждом оформлении заказа.

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

4. Обновление данных при входе в личный кабинет

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

Что дало: повысили охват — теперь даже повторные заказы авторизованных клиентов можно связать с источником трафика.

5. Исправление ошибки с внешними ID

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

Что дало: устранили потенциальные неточности при анализе и облегчили сверку данных между CRM и Метрикой.

Поле ClientID, доступное при выгрузке отчета по заказам из RetailCRM, должно содержать соответствующие данные.

Примерный алгоритм действий:

  1. Создать в RetailCRM отдельное поле в профиле клиента, в которое будет передаваться ClientID.
  2. Добавить в форму заказа на сайте скрытое поле для ClientID.
  3. Получить ClientID из Метрики с помощью метода getClientID.
  4. Присвоить скрытому полю значение ClientID.
  5. Изменить процесс отправки формы, чтобы ClientID сохранялся в профиле клиента в RetailCRM.
  6. Убедиться, что при передаче данных о заказе из CRM в Метрику, ClientID включается как часть информации о клиенте, что позволяет Метрике связать заказ с визитом.

 

Важно: ClientID в Метрике хранится в cookie с названием _ym_uid сроком на два года и создается при первом визите с нового устройства. Его значение представляет собой целочисленный идентификатор (например, 1528651862599277088).

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

Сложности возникшие за время работы:

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

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

После внедрения всех доработок — и особенно передачи ClientID — система начала связывать более 93% заказов с визитами. Это практически полное покрытие. Клиент получил полноценную сквозную аналитику: с точной атрибуцией и возможностью оценивать эффективность рекламных каналов по реальным деньгам, а не только по трафику.

Результат

После внедрения передачи ClientID и устранения технических ошибок нам удалось почти полностью закрыть разрыв между данными CRM и Метрики:

До доработки: в Яндекс Метрике отражалось менее 52% заказов из RetailCRM.

После внедрения ClientID: корректно отображается более 93% заказов.

Факт: по данным за февраль 2025 года — 2008 заказов в RetailCRM, 1873 заказа в Метрике.

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

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


Перейти на сайт

В карточку агентства

Письмо автору кейса

Пользуйтесь реальным опытом в IT и следите за успехами потенциальных подрядчиков и конкурентов
Подпишитесь на рассылку
Читайте также
Кейсы по теме#Товары народного потребления
Проекты компании Proactivity Group
Нажмите «ОК», если вы соглашаетесь с условиями обработки cookie и ваших данных о поведении на сайте, необходимых для аналитики. Запретить обработку cookie можете через браузер