Электронная торговля в GA4 и Яндекс Метрике: от первого события до проверки заказов

Контракты событий GA4 и электронной торговли Метрики повторно сверены с официальной документацией 9 октября 2026 года. Инструкции отдельных CMS и модулей проверялись 14 сентября; их интерфейсы и совместимость с вашим магазином нужно проверить перед внедрением. Все суммы в примере — новые учебные допущения в USD, а не пересчёт прежних BYN.

Покупатель выбрал кружку, добавил ещё одну, положил в корзину блокнот и применил промокод. Магазин принял заказ. Через несколько дней одну кружку вернули.

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

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

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

Выберите маршрут по своей работе. Если вы отвечаете за решение по рекламе и приёмку аналитики, прочитайте разделы 1–5 о показателях и договоре о данных, затем 10–12 о проверке и отчётах. Если внедряете события, после раздела 3 переходите к примерам GA4 и Метрики в разделах 6–7, проверьте ограничения своей CMSсистема управления сайтом или магазином в разделе 9 и примите настройку по разделу 10. Оба маршрута используют один учебный заказ, поэтому суммы и ID можно сверять между разделами.

1. Что такое электронная торговля в аналитике

В обычной настройке счётчик видит посещения страниц и часть действий. Например, посетитель открыл каталог, перешёл на карточку и отправил форму. Чтобы связать действия с конкретными товарами, магазину нужно передать дополнительные данные.

Электронная торговля, или ecommerceтоварные действия, состав и сумма покупок в аналитике, описывает товары, действия с ними и сумму заказа. Вместо общего сообщения «что-то добавили в корзину» аналитика получает: добавили одну синюю кружку с артикулом CUP-BLUE-350 по цене 18 USD.

В GA4 ecommerce строится на рекомендуемых событиях и параметрах. Сам по себе установленный счётчик не обеспечивает их полный сбор: нужны интеграция платформы, модуль или код магазина. Google: события электронной торговли.

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

Какие вопросы становятся доступными

• Какие товары часто просматривают, но редко кладут в корзину?
• Какие категории дают заказы из конкретного рекламного источника?
• На каком этапе оформления возникает потеря пользователей?
• Какие товары покупают вместе?
• Как меняется средняя сумма заказа при использовании промокода?
• Расходится ли количество покупок в аналитике с заказами магазина?

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

Где заканчиваются возможности счётчика

Из события purchase нельзя автоматически узнать, оплатил ли клиент заказ, доставлен ли он и сколько магазин заработал. Смысл события зависит от того, когда его отправляет ваша интеграция.

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

Себестоимость товара, комиссия эквайринга, доставка за счёт магазина, отмены и возвраты требуют дополнительных данных. Аналитика поведения помогает искать причины и сравнивать сегменты; финансовую картину нужно собирать из согласованных источников.

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

2. Как данные попадают из магазина в отчёт

Типовая цепочка выглядит так:

1. Действие: покупатель добавил товар.
2. Магазин: подтвердил изменение корзины.
3. dataLayer: получил описание действия.
4. Счётчики: обработали событие.
5. Отчёт: показал товар и сумму.

На каждом переходе можно проверить данные и найти место расхождения.

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

Google Tag Manager, или GTMGoogle Tag Manager — система управления тегами сайта, управляет тегами — кодом, который передаёт информацию в аналитические и рекламные системы. Триггер определяет, когда тег должен сработать. Например, сообщение add_to_cart запускает тег события GA4.

GTM не знает содержимое заказа, пока магазин его не передал. Создать тег с правильным названием недостаточно. Если в сообщении нет товаров, цен или ID заказа, GTM не восстановит их из бизнес-логики магазина.

Существует и прямой путь через gtag: разработчик вызывает библиотеку Google без GTM. Готовые модули CMS могут использовать собственную схему. Важен конечный результат: событие отправлено один раз, с правильными параметрами и в нужный счётчик.

Кто за что отвечает

В небольшой команде один человек может совмещать роли. Важно, чтобы у каждой части был понятный результат. Формулировка «аналитика настроена» слишком широка для приёмки.

3. Что согласовать до установки тегов

До настройки тега согласуйте на одной странице, что именно магазин считает покупкой, какой ID соединяет записи и какие суммы передаются. Тогда расхождение в отчётах можно проверить по принятому правилу, а не спорить о значении слова «заказ».

Момент покупки

Выберите конкретное состояние системы. Например: «магазин создал заказ, присвоил постоянный номер и показал подтверждение». Или: «платёжный сервис подтвердил успешную оплату».

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

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

Идентификатор заказа

transaction_id должен однозначно связывать покупку с заказом. Подойдёт постоянный номер из магазина, при необходимости с префиксом магазина или витрины. Новый случайный ID при каждом открытии страницы разрушит эту связь.

Не используйте пустую строку и не помещайте в ID телефон или email. Google отдельно описывает дедупликацию покупок по идентификатору транзакции для web-потоков; это полезная защита, но она не отменяет контроль источников отправки. Google: предотвращение повторных транзакций.

Идентификатор товара и варианта

Решите, что является единицей учёта: модель товара или конкретный SKUстабильный идентификатор товара или его варианта — артикул варианта. Для магазина одежды это может быть отдельная комбинация модели, размера и цвета. Главное, чтобы один и тот же объект имел один ID при просмотре, добавлении и покупке.

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

Цена и скидка

Запишите, что хранится в price: цена одной единицы после скидки. Количество передавайте отдельно. Для GA4 величина discount описывает скидку на единицу товара; её нельзя ещё раз вычитать из уже уменьшенной цены.

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

Код промокода сообщает, какой промокод использовали; сам по себе он не пересчитывает цены. Актуальные параметры событий перечислены в справочнике GA4.

Валюта, доставка и налог

Выберите денежную базу для сравнения двух систем. В нашем примере товарная сумма, доставка и условный налог разделены. В GA4 value покупки равен сумме price × quantity, а shipping и tax передаются отдельно.

В реальном магазине цены могут включать налог, а учётная система — хранить его отдельной строкой. Попросите специалиста по учёту подтвердить преобразование. Не извлекайте налог из цены по случайно выбранной ставке.

Не подменяйте валюту ради красивого отчёта. Реальный заказ в BYN передавайте как BYN; заказ в другой валюте — с её кодом. Учебный заказ ниже задан в USD и не описывает пересчёт настоящей покупки. Рабочие суммы и преобразование валют в отчётах проверяйте отдельно.

Согласие и состав данных

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

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

4. Один заказ: проверяем числа до отправки

Новый учебный пример в USD, не данные реального магазина и не пересчёт прежних цен в BYN. Покупатель использовал промокод START10; скидка уже распределена по товарам. Заказу присвоен номер DEMO-1001. Налог равен нулю только для упрощения арифметики.

До скидки товары стоили 70 USD. Скидка составила 2 × 2 + 6 × 1 = 10 USD. После скидки — 60 USD. Доставка стоит 5 USD, покупатель платит 65 USD.

36 + 24 = 60 USD — товары.

60 + 5 USD доставки = 65 USD — платёж.

В GA4 передадим value: 60, shipping: 5, tax: 0. В собственном формате Метрики зададим revenue: 60, чтобы товарная база совпадала. В учётной системе сохраним отдельно полный платёж 65 USD.

Позже покупатель вернул одну кружку за 18 USD. Товарная сумма после возврата — 42 USD. Денежные поступления за вычетом этого возврата — 47 USD, если доставку не возвращали. Эти величины отличаются по составу.

Ни 60, ни 42, ни 47 USD нельзя назвать прибылью. Для этого ещё потребуются себестоимость и выбранный состав расходов. В нашем примере их нет.

Почему деньги лучше собирать в минимальных единицах

В коде примера исходные суммы хранятся в центах: 1800, 2400, 500. Сначала считаем целочисленный итог, затем делим на 100 перед отправкой. Это помогает избежать ошибок двоичной арифметики вроде 0.1 + 0.2.

Для валют с другим числом десятичных знаков нужен соответствующий масштаб. Приведённый адаптер рассчитан на учебный сценарий USD с двумя знаками; не переносите деление на 100 на любую валюту без проверки.

5. Какие события собирать

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

Таблица сопоставляет смысл действий и документированные форматы. Она не обещает, что любое событие GA4 превратится в одноимённый отчёт Метрики. Источники: справочник событий Google и контракт Метрики.

Количество в событии и количество в корзине

Покупатель добавил одну кружку, затем ещё одну. Правильная история добавлений: quantity: 1, затем снова quantity: 1. Если во второй раз передать уже накопленное количество 2, аналитика увидит три добавленные кружки.

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

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

События не обязаны происходить в одном визите

Человек может посмотреть товар сегодня, вернуться завтра и купить с другого устройства. А может сразу попасть на оформление по специальной ссылке. Отсутствие одного этапа у конкретной покупки ещё не доказывает поломку.

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

6. Настройка GA4 через Google Tag Manager

В учебном заказе магазин знает ID, товары и сумму. Теперь нужно передать их один раз после выбранного состояния покупки и увидеть в нужном счётчике. Ниже — последовательность для магазина, в котором разработчик может формировать dataLayer. Если выбран готовый модуль, сначала проверьте, какую часть этой цепочки он уже выполняет.

Шаг 1. Подготовьте поток данных и контейнер

В GA4 создайте ресурс и web-поток для сайта либо используйте существующий. Найдите Measurement ID вида G-…. Проверьте домен, часовой пояс и валюту отчётности. Список доступов должен включать того, кто проверяет события и публикует настройки.

Установите контейнер GTM по его официальной инструкции. Если он уже установлен через тему или модуль, второй экземпляр добавлять не нужно. В GTM настройте Google tag для выбранного потока. В старых руководствах этот шаг часто назван «GA4 Configuration»; текущую настройку сверяйте с документацией Google tag.

Проверьте обычный просмотр страницы. Только затем переходите к товарным событиям: так легче отделить проблему загрузки счётчика от проблемы ecommerce.

Шаг 2. Передайте покупку в dataLayer

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

// Учебные данные: замените подтверждёнными данными магазина.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  "event": "purchase",
  "ecommerce": {
    "transaction_id": "DEMO-1001",
    "currency": "USD",
    "value": 60,
    "shipping": 5,
    "tax": 0,
    "coupon": "START10",
    "items": [
      {
        "item_id": "CUP-BLUE-350",
        "item_name": "Кружка 350 мл",
        "item_brand": "Demo Store",
        "item_category": "Посуда",
        "item_variant": "Синий",
        "price": 18,
        "discount": 2,
        "quantity": 2
      },
      {
        "item_id": "NOTE-A5-GRAPH",
        "item_name": "Блокнот A5",
        "item_brand": "Demo Store",
        "item_category": "Канцелярия",
        "item_variant": "Графит",
        "price": 24,
        "discount": 6,
        "quantity": 1
      }
    ]
  }
});

Здесь три единицы товаров, две товарные позиции и одна транзакция. Эти числа обозначают разные вещи. Значение ecommerce: null перед событием очищает предыдущие ecommerce-данные в GTM; уже отправленные покупки сохраняются.

Этот код показывает формат. Его нельзя вставить без изменений на все страницы магазина: фиксированный заказ тогда станет ложной покупкой каждого посетителя. В реальном коде значения приходят из подтверждённого ответа магазина.

Шаг 3. Создайте один тег для товарных событий

1. Создайте тег типа Google Analytics: GA4 Event.
2. Укажите Measurement ID нужного web-потока.
3. В поле имени события выберите встроенную переменную {{Event}}.
4. В настройках Ecommerce включите отправку ecommerce-данных и выберите источник Data Layer.
5. Привяжите триггер типа Custom Event к разрешённому списку имён.

Например, для этого руководства можно использовать регулярное выражение:

^(view_item_list|select_item|view_item|add_to_cart|remove_from_cart|view_cart|begin_checkout|add_shipping_info|add_payment_info|purchase|refund|view_promotion|select_promotion)$

В триггере включите распознавание регулярного выражения. Якоря ^ и $ фиксируют полное имя. Без ограниченного списка слишком широкий триггер может отправлять в GA4 технические события контейнера.

Конфигурация одного тега с ecommerce из Data Layer описана в документации Google. Отдельные теги допустимы, если событиям действительно нужны разные параметры или правила. Для базового случая единый тег проще проверять.

Шаг 4. Добавьте остальные действия

Для просмотра и добавления одной кружки данные выглядят так:

// Учебные данные: замените подтверждёнными данными магазина.
window.dataLayer = window.dataLayer || [];
// В обработчике просмотра товара:
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  "event": "view_item",
  "ecommerce": {
    "currency": "USD",
    "value": 18,
    "items": [
      {
        "item_id": "CUP-BLUE-350",
        "item_name": "Кружка 350 мл",
        "item_brand": "Demo Store",
        "item_category": "Посуда",
        "item_variant": "Синий",
        "price": 18,
        "discount": 2,
        "quantity": 1
      }
    ]
  }
});

// В ДРУГОМ обработчике: после успешного добавления одной штуки.
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  "event": "add_to_cart",
  "ecommerce": {
    "currency": "USD",
    "value": 18,
    "items": [
      {
        "item_id": "CUP-BLUE-350",
        "item_name": "Кружка 350 мл",
        "item_brand": "Demo Store",
        "item_category": "Посуда",
        "item_variant": "Синий",
        "price": 18,
        "discount": 2,
        "quantity": 1
      }
    ]
  }
});

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

Для начала оформления отправляем всю корзину, уже с двумя кружками:

// Учебные данные: замените подтверждёнными данными магазина.
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  "event": "begin_checkout",
  "ecommerce": {
    "currency": "USD",
    "value": 60,
    "coupon": "START10",
    "items": [
      {
        "item_id": "CUP-BLUE-350",
        "item_name": "Кружка 350 мл",
        "item_brand": "Demo Store",
        "item_category": "Посуда",
        "item_variant": "Синий",
        "price": 18,
        "discount": 2,
        "quantity": 2
      },
      {
        "item_id": "NOTE-A5-GRAPH",
        "item_name": "Блокнот A5",
        "item_brand": "Demo Store",
        "item_category": "Канцелярия",
        "item_variant": "Графит",
        "price": 24,
        "discount": 6,
        "quantity": 1
      }
    ]
  }
});

В проекте лучше вынести подготовку товара в общий адаптер. Тогда изменение названия поля или правила округления не придётся повторять в пяти местах. В приложенном файле ecommerce.mjs есть учебный вариант такого адаптера: он проверяет исходные суммы и собирает покупку из заказа.

Шаг 5. Передайте частичный возврат

После подтверждения возврата одной кружки отправьте refund с исходным ID транзакции и данными возвращённой позиции:

// Учебные данные: замените подтверждёнными данными магазина.
window.dataLayer = window.dataLayer || [];
// После подтверждения частичного возврата; один раз для этого возврата.
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  "event": "refund",
  "ecommerce": {
    "transaction_id": "DEMO-1001",
    "currency": "USD",
    "value": 18,
    "items": [
      {
        "item_id": "CUP-BLUE-350",
        "item_name": "Кружка 350 мл",
        "item_brand": "Demo Store",
        "item_category": "Посуда",
        "item_variant": "Синий",
        "price": 18,
        "discount": 2,
        "quantity": 1
      }
    ]
  }
});

Сумма возврата положительная: 18, а не −18. Тип события уже описывает возврат. Количество — одна возвращённая кружка. Так можно анализировать возвраты на уровне товара. Актуальный контракт см. в описании refund.

Возврат часто оформляется сотрудником в CRM, когда покупатель давно закрыл сайт. Браузерный код на витрине тогда не увидит действие. Потребуется отдельная серверная интеграция или отчёт по возвратам из учётной системы. Пример выше объясняет структуру события; он не создаёт канал из CRM автоматически.

Шаг 6. Проверьте, затем опубликуйте

В GTM Preview пройдите контрольный путь. Найдите нужное сообщение слева, проверьте содержимое ecommerce и сработавший тег. Затем проверьте событие в GA4 DebugView и раскройте параметры.

Проверьте хотя бы два разных заказа. У них должны быть разные ID, правильные товары и суммы. Повторите открытие подтверждения первого заказа. Именно эта проверка часто обнаруживает дубли, которые незаметны при единственной покупке.

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

Когда использовать gtag напрямую

Если разработчик управляет отправкой без GTM, можно передать те же параметры через Google tag. Это альтернативный маршрут, а не второй отправитель той же покупки. Пример ниже оставлен для сверки полного payload.

// Альтернатива GTM. Google tag уже установлен и настроен.
// Значения учебные; примените настройки согласия до отправки.
gtag('event', 'purchase', {
  "transaction_id": "DEMO-1001",
  "currency": "USD",
  "value": 60,
  "shipping": 5,
  "tax": 0,
  "coupon": "START10",
  "items": [
    {
      "item_id": "CUP-BLUE-350",
      "item_name": "Кружка 350 мл",
      "item_brand": "Demo Store",
      "item_category": "Посуда",
      "item_variant": "Синий",
      "price": 18,
      "discount": 2,
      "quantity": 2
    },
    {
      "item_id": "NOTE-A5-GRAPH",
      "item_name": "Блокнот A5",
      "item_brand": "Demo Store",
      "item_category": "Канцелярия",
      "item_variant": "Графит",
      "price": 24,
      "discount": 6,
      "quantity": 1
    }
  ]
});

Выберите одного основного отправителя и задокументируйте исключения. Параметры прямого вызова сверяйте с руководством Google по purchase.

7. Настройка электронной коммерции в Метрике

Вариант А. Магазин уже отправляет GA4 ecommerce

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

Яндекс документирует поддержку электронной торговли GA4. Поэтому сначала проверьте сбор на уже работающем потоке, прежде чем писать вторую реализацию. Яндекс: электронная коммерция для магазина.

Практическая последовательность:

1. Найдите, откуда установлен счётчик: шаблон, GTM, официальный модуль или настройки платформы.
2. Включите ecommerce в этом единственном действующем способе установки и в настройках счётчика, где это требуется интеграцией.
3. Пройдите заказ с известными ID и суммой.
4. Проверьте обработку товара и покупки в отладке Метрики.
5. После обработки данных найдите этот заказ в отчёте.

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

Вариант Б. Нужен собственный формат Метрики

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

// Учебные данные: замените подтверждёнными данными магазина.
window.dataLayer = window.dataLayer || [];
// Альтернатива общему GA4-потоку для того же счётчика Метрики.
window.dataLayer.push({
  "ecommerce": {
    "currencyCode": "USD",
    "purchase": {
      "actionField": {
        "id": "DEMO-1001",
        "revenue": 60,
        "coupon": "START10"
      },
      "products": [
        {
          "id": "CUP-BLUE-350",
          "name": "Кружка 350 мл",
          "brand": "Demo Store",
          "category": "Посуда",
          "variant": "Синий",
          "price": 18,
          "quantity": 2,
          "discount": 2
        },
        {
          "id": "NOTE-A5-GRAPH",
          "name": "Блокнот A5",
          "brand": "Demo Store",
          "category": "Канцелярия",
          "variant": "Графит",
          "price": 24,
          "quantity": 1,
          "discount": 6
        }
      ]
    }
  }
});

В этом варианте используются currencyCode, purchase.actionField и products. В GA4 используются currency, transaction_id и items. Совпадение слова ecommerce не делает объекты взаимозаменяемыми.

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

Как добавить цель начала оформления

Для дополнительного этапа создайте в Метрике цель типа JavaScript-событие с согласованным идентификатором, например begin_checkout. После реального начала оформления вызовите:

// counterId — номер вашего счётчика; цель заранее создана в Метрике.
ym(counterId, 'reachGoal', 'begin_checkout');

Не вызывайте это на каждом изменении поля формы. Отдельная JS-цель описывает достижение этапа; она не создаёт товарный ecommerce-отчёт по этому этапу. Формат вызова: reachGoal в Метрике.

Возвраты и большие заказы

В документированном нативном контракте ecommerce Метрики нет прямого аналога refund. Поэтому не заменяйте его отрицательным purchase по собственной догадке. Для контроля оплат, отмен и возвратов используйте отдельный согласованный канал учётных данных; возможности CRM-интеграции описаны в справке Яндекса.

Есть и различие ограничений: документация Метрики ограничивает размер ecommerce-контейнера 8192 символами. Если большой заказ требуется делить на подзаказы, это меняет подсчёт заказов; Яндекс описывает отдельную JS-цель для контроля их фактического количества. Размер контейнера и деление заказа.

Перед внедрением проверьте крупную корзину из реального ассортимента. Несколько десятков длинных названий и категорий могут оказаться важнее числа товарных позиций. Для GA4 отдельно проверяйте лимит массива items и ограничения выбранного способа передачи. Избегайте универсального правила «один большой JSON подойдёт всем».

8. Как избежать дублей и потерь

Назначьте одного отправителя покупки

Самый понятный способ поймать дубли — составить список источников. Покупку могут отправлять плагин GA4, тег GTM, код в шаблоне, встроенная интеграция платформы и серверный обработчик.

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

Дедупликация по transaction_id полезна на стороне GA4, но не исправляет неправильный ID. Она также не даёт права считать, что правила другой системы совпадают. Стабильный ID нужен и для сопоставления, и для диагностики.

Не выдавайте запись в браузере за подтверждение доставки

Флаг в sessionStorage может уменьшить повторные вызовы после перезагрузки. Но он не доказывает, что первый вызов дошёл до аналитики. Другая вкладка или устройство могут иметь другую память; очистка браузера тоже меняет состояние.

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

Повтор запроса и новая покупка — разные события. При повторе того же заказа ID остаётся прежним; при новом заказе создаётся новый ID.

Учитывайте переход на оплату

Человек может оплатить на внешней странице и не вернуться в магазин. Если покупка отправляется только после возврата, этот сценарий даст пропуск. Наоборот, страница «Спасибо» до подтверждения платежа не подходит для показателя оплаченных заказов.

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

Для переходов между собственными доменами проверьте cross-domain measurement в GA4. Для платёжных посредников отдельно изучите нежелательные переходы. Эти настройки влияют на измерение и атрибуцию, но не создают потерянное событие покупки.

Отправляйте данные из бизнес-логики

Парсинг названия и цены из HTML бывает быстрым прототипом, но ломается после смены верстки, локали или формата валюты. Кнопка «Добавить» может находиться и в каталоге, и в рекомендации, и в быстром просмотре. Один обработчик по CSS-селектору не обязательно охватит все места.

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

9. Настройка на популярных CMS и платформах

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

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

1С-Битрикс

Метрика. Официальный модуль Яндекса поддерживает добавление счётчика и основные ecommerce-действия. Документация указывает совместимость с «1С-Битрикс: Управление сайтом» от версии 18.0. Устанавливайте актуальную версию модуля, предварительно проверив существующие способы установки счётчика.

1. Включите электронную коммерцию в счётчике.
2. Установите «Яндекс Метрику» через Marketplace.
3. Откройте Настройки → Настройки продукта → Настройки модулей → Яндекс Метрика.
4. Выберите сайт, проверьте номер счётчика, при необходимости сопоставьте поле бренда.
5. Проверьте просмотр товара, добавление, удаление и заказ.

Для просмотра карточки официальная инструкция предусматривает доработку шаблона компонента. После получения ID элемента добавляется компонент detail:

$APPLICATION->IncludeComponent(
    "yandex.metrika:detail",
    "",
    array("PRODUCT_ID" => $elementId),
    $component
);

Это фрагмент для описанного Яндексом шаблона: $elementId и $component должны существовать в вашем контексте. Место вставки и полный пример — в документации модуля.

GA4. Выберите модуль, который явно поддерживает GA4 ecommerce, либо поручите разработчику сформировать общий контракт из раздела 6. Сравните ID торгового предложения при просмотре и покупке. Для нестандартного оформления проверьте, вызываются ли нужные обработчики модуля.

Приёмка: заказ из двух вариантов одного товара должен сохранить различие вариантов и правильные количества. Попросите показать payload из быстрого просмотра и обычной карточки. Если второй путь работает, а первый нет, внедрение охватывает магазин лишь частично.

WordPress + WooCommerce

Здесь удобны два маршрута для GA4. Выберите один основной способ отправки, чтобы модули не дублировали покупку.

Первый — Google Analytics for WooCommerce. После установки откройте WooCommerce → Settings → Integration → Google Analytics, задайте Measurement ID вида G-… и включите нужные опции отслеживания. Документация описывает покупки и добавления; для транзакций отдельно оговаривает платёжный сценарий с возвратом на страницу полученного заказа. WooCommerce: Google Analytics integration.

Второй — GTM4WP и GTM. В документации GTM4WP 2.x настройка находится в разделе WooCommerce → General → Track e-commerce; для 1.x указан прежний путь Integration → WooCommerce. Включите товарную интеграцию, затем настройте Google tag и ecommerce-тег в GTM.

Можно использовать актуальный шаблон контейнера автора плагина, но перед импортом просмотрите изменения. В шаблоне присутствуют дополнительные теги Google Ads; если реклама сейчас не настраивается, они не должны срабатывать с тестовыми ID. Не включайте расширенные данные клиента только ради ecommerce. GTM4WP: актуальная инструкция GA4.

Метрика. Официальный плагин Яндекса предусматривает WooCommerce для товарных событий. В настройках задайте номер счётчика и источник бренда, если он используется. Проверьте, не устанавливает ли счётчик ещё и тема. Документация отдельно отмечает зависимость просмотра товара от хуков темы. Яндекс: плагин WordPress.

Приёмка: простой товар, вариативный товар, добавление через AJAX, изменение количества, оформление гостем и возврат после оплаты. Отдельно проверьте применяемые Cart/Checkout Blocks или сторонний checkout: название платформы не гарантирует одинаковую совместимость всех компонентов.

OpenCart и ocStore

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

Для GA4 нужен модуль с явной поддержкой формата GA4 либо собственный dataLayer. Надпись «Google Analytics» в настройке расширения не доказывает наличие items, transaction_id и правильного purchase.

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

Практический порядок выбора модуля:

1. Запросите список событий и пример purchase-payload у разработчика расширения.
2. Сверьте поля с вашим контрактом: ID варианта, скидка, валюта, доставка.
3. Установите модуль в тестовый магазин с вашей темой.
4. Проверьте обычную корзину и фактически используемый checkout.
5. Повторите покупку после перезагрузки подтверждения.

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

Tilda

Для штатной корзины начните с настроек самой Tilda. В её документации описаны подключение счётчика в Настройках сайта → Аналитика, цены у товаров, подключённая платёжная система и дополнительная опция отправки добавлений в корзину в блоке ST100. После изменения настроек опубликуйте страницы и проверяйте публичную версию. Tilda: ecommerce, Яндекс: подключение Tilda.

Есть важная оговорка: страница справки Tilda содержит фрагменты про «представления» и включение электронной торговли в старом Google Analytics. В GA4 этот путь не применяется. Принимайте работу по фактически отправленным GA4-событиям, а не по совпадению с устаревшим скриншотом.

Порядок проверки:

1. Подключите актуальную интеграцию счётчика, доступную вашему проекту.
2. Убедитесь, что товар имеет ID, цену и нужный вариант.
3. Добавьте товар через используемый блок магазина.
4. Оформите заказ выбранным способом оплаты.
5. Посмотрите реальные имена и данные событий; отдельно зафиксируйте, когда возникает purchase.

Если штатная интеграция не формирует нужный GA4-контракт, сначала определите, какие данные уже доступны, затем проектируйте адаптер. Установка GTM сама по себе не добавляет товары в события. Для кастомных Zero Block-сценариев и сторонних корзин требуется отдельная реализация и проверка.

InSales

Официальный маршрут подключения GA4 в InSales проходит через GTM. Идентификатор контейнера добавляется в Сайт → Счётчики и коды, теги настраиваются на стороне GTM. InSales: установка GA4.

Эта инструкция подтверждает подключение счётчика. Полный ecommerce-контракт для любого шаблона из неё не следует. Поэтому сразу после установки откройте GTM Preview и проверьте, какие товарные сообщения уже формирует магазин.

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

Для Метрики используйте один действующий способ установки счётчика и включите ecommerce. Не считайте обычные визиты доказательством передачи заказов. По установленному приложению запросите точный список действий и условие покупки.

Приёмка: зафиксируйте реальный payload одного заказа из вашего шаблона. Если доступны только page_view и URL страницы благодарности, товарная аналитика ещё не готова. Не пытайтесь восстановить товарный состав по одному адресу страницы.

Shopify

Для GA4 официальный маршрут — канал Google & YouTube. Подключите нужный ресурс GA4 через этот канал и проверьте, какие ecommerce-события собираются автоматически. Shopify предупреждает, что сбор не начнётся, пока магазин закрыт приватным режимом. Shopify: настройка GA4.

Встроенная интеграция и произвольный код темы имеют разную область действия. Код витрины нельзя считать гарантированно работающим внутри checkout. Для дополнительных событий и сторонних систем проверяйте поддерживаемые механизмы Customer events и pixels.

Custom pixels работают в ограниченной среде. Поэтому пример вида «вставьте произвольный скрипт в тему, и он увидит всё оформление» непригоден как универсальная инструкция. Shopify: custom pixels.

Для Метрики выбирайте интеграцию, которая документирует передачу нужных товарных действий из доступных событий Shopify. До подключения проверьте охват checkout, требования к согласию и возможность просмотра итогового payload. Не предполагайте, что установленный на витрине счётчик автоматически получит покупку из другого окружения.

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

10. Как принять настройку: четыре уровня проверки

Проследите один контрольный заказ от магазина до отчёта. Зелёный статус тега подтверждает отправку на одном участке; совпадение ID, товаров и сумм проверяется на всех четырёх уровнях. Проверку повторите для особых сценариев из таблицы ниже.

Уровень 1. Магазин

Сначала запишите, что произошло в самом магазине: номер заказа, время, валюта, позиции, количество, скидка, доставка и статус. Без этого сравнивать аналитику будет не с чем.

Для учебного заказа ожидаем две кружки и один блокнот, товарную сумму 60 USD, доставку 5 USD и общий платёж 65 USD. Если тестируете заказ без оплаты, так и отметьте его статус.

Уровень 2. Сообщение в dataLayer

В GTM Preview найдите сообщение покупки и раскройте данные. Проверьте имя события, transaction_id, валюту, items, числовые типы и суммы. Значение "18 USD" не является числом 18.

При прямой отправке через gtag путь проверки другой: ищите вызов и отправленные параметры. Отсутствие объекта в привычной форме ecommerce внутри массива не обязательно означает отсутствие события gtag. Проверяйте именно архитектуру, которая используется в проекте.

Уровень 3. Отправка и получение

В GTM убедитесь, что на нужном событии сработал один ожидаемый тег. В GA4 включите отладку и найдите событие в DebugView. Раскройте параметры, проверьте ID и товары. Если выбран неправильный поток, правильный payload окажется в другом месте. Google: проверка ecommerce, DebugView.

Для Метрики с актуальным кодом счётчика откройте сайт с параметром ?_ym_debug=2 и используйте панель отладки. Для предыдущего кода или при отсутствии панели документация предлагает консольный режим _ym_debug=1. Если в URL уже есть параметры, добавляйте новый через &. Важно сохранить начальное подчёркивание: _ym_debug, а не ym_debug. Яндекс: проверка электронной коммерции.

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

Уровень 4. Отчёт

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

Отсутствие ecommerce-раздела в навигации GA4 может зависеть от опубликованной коллекции отчётов и прав. Но добавление отчёта в меню не восстановит события, которые никогда не отправлялись. Разделяйте наличие данных и настройку их отображения.

Набор контрольных сценариев

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

Когда настройку можно считать принятой

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

11. Что смотреть в отчётах после запуска

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

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

Товары: что смотрят, кладут в корзину и покупают

В GA4 начните с Ecommerce purchases. Отчёт помогает сравнивать товары и товарные показатели. Если его нет в меню, проверьте доступную коллекцию отчётов и права на её изменение. Google: отчёт Ecommerce purchases.

В Метрике откройте Отчёты → Электронная коммерция. «Содержимое заказов» удобно для проверки ID и состава покупки; «Заказанные товары» — для ассортимента; «Товары в корзине» — для действий с корзиной; «Источники заказов» — для источников трафика. Нужные отчёты зависят от передаваемых действий. Яндекс: назначение ecommerce-отчётов.

Сначала определите единицу анализа: человек, визит, событие, заказ или штука товара. У нашего заказа один ID, две позиции и три купленные единицы. Три единицы не означают три покупки или трёх покупателей. В GA4 товарные и событийные показатели имеют разную область действия; не все сочетания с группировкой по товару совместимы. Google: показатели ecommerce.

Воронка: где люди прекращают путь

Для последовательности действий используйте Purchase journey или собственное исследование воронки в GA4. Задайте этапы, порядок, условия входа и допустимое время между действиями. Сравнивайте мобильные устройства и компьютеры, новые и повторные покупки, разные варианты оформления. Google: Purchase journey, настройка Funnel exploration.

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

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

Реклама: какую сумму ставить в знаменатель

Продолжим учебный пример. Предположим, затраты на привлечение этого заказа составили 12 USD. Здесь это заданное условие расчёта, а не результат атрибуции реальной кампании.

После частичного возврата товарная сумма снизилась с 60 до 42 USD. Остаток денежных поступлений в нашем примере — 47 USD, поскольку доставку за 5 USD не возвращали. Это другой показатель. Ни 42, ни 47 USD не описывают прибыль: ещё нужны себестоимость, расходы на исполнение и прочие согласованные статьи.

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

Не переносите учебные 20% в норматив для магазина. Приемлемая доля расходов зависит от экономики товаров и условий бизнеса. Решение о бюджете опирается на согласованный показатель и достаточное количество наблюдений.

Почему GA4, Метрика и магазин показывают разные числа

Совпадение каждого общего итога не является универсальным критерием качества. Системы могут по-разному определять визит, относить покупку к источнику и учитывать выбранные ограничения сбора. Но необъяснённое расхождение нельзя автоматически списать на особенности аналитики.

Для более подробной сверки откройте статью «Почему GA4, рекламный кабинет и CRM показывают разные результаты». В ней разобраны определения, даты и идентификаторы, которые помогают проследить путь от клика до оплаты. При работе со связкой «Метрика — магазин» сначала определите, какие шаги этого разбора применимы к вашим данным. Зафиксируйте, что именно считается заказом в каждой системе, и выберите одинаковый период. Затем вернитесь к проверкам этого руководства: когда отправляется событие покупки и какой компонент отвечает за его отправку. Сопоставление отдельных заказов поможет уточнить причину расхождения перед изменением настройки.

Для ручной разметки рекламных ссылок используйте генератор UTM-меток WiseLab и сохраняйте одинаковые правила именования кампаний.

Сверяйте сначала конкретные ID, затем агрегаты. Объяснение «системы всегда расходятся» не помогает найти заказ, который потерялся из-за новой страницы оплаты.

12. Что передать разработчику и как поддерживать настройку

Хорошее техническое задание позволяет двум людям независимо получить одинаковый результат. Фраза «подключить расширенную электронную торговлю» этого не обеспечивает.

В шаблоне технического задания есть поля для проекта. Заполните их до реализации:

1. Системы и доступы: ресурс GA4, web-поток, контейнер GTM, счётчик Метрики, тестовая среда и ответственные.
2. Покупка: какое подтверждённое состояние её создаёт, где берётся ID и как обрабатывается повторное открытие.
3. Товары и деньги: ID вариантов, цена после скидки, количество, валюта, доставка и налог.
4. События: точное действие, источник данных, формат и отправитель каждого события.
5. Особые маршруты: быстрый заказ, покупка без регистрации, внешний платёж, мобильное оформление, возвраты.
6. Согласие и ограничения: правила запуска тегов, исключаемые поля, известные непокрытые сценарии.
7. Приёмка: ожидаемый и фактический payload, заказ в отчёте, проверка дублей и контроль сумм.

Скачать весь комплект: текст, ТЗ, список проверок и код.

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

Что делать после обновлений

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

В рабочем мониторинге полезно сопоставлять долю попавших в аналитику подходящих заказов и распределение расхождений сумм. Порог тревоги выбирайте по собственному стабильному периоду с учётом объёма заказов и режима согласия. Универсальная допустимая погрешность для всех магазинов была бы ложной точностью.

Когда нужен отдельный проект интеграции

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

Учебный адаптер из статьи не реализует такой канал: в нём нет серверной очереди, авторизации, повторных попыток доставки или подключения к CMS. Он помогает проверить структуру и арифметику данных перед интеграцией.

13. Что почитать у Якова Осипенкова

Материалы Якова Осипенкова полезны для понимания логики внедрения и связи GA4 с GTM. При подготовке руководства отдельно рассмотрены его статьи и фрагменты ecommerce-раздела бесплатной книги. Год публикации здесь важен: интерфейсы и рекомендуемые способы настройки успели измениться.

• «Электронная торговля в Google Analytics 4» — материал 2021 года для знакомства с событиями и процессом настройки.
• Новый способ отслеживания ecommerce через GTM — статья 2022 года о передаче ecommerce из Data Layer через общий тег событий. Для текущих параметров используйте документацию Google, приведённую в разделе 6.
• GA4 ecommerce на WordPress — полезный разбор интеграции; меню и шаблон GTM4WP сверяйте с актуальной инструкцией самого плагина.
• Официальный шаблон Метрики для GTM — материал 2025 года о подключении счётчика через шаблон.
• Товарная воронка в BigQuery по данным GA4 — продолжение для самостоятельного анализа. При переносе расчётов отдельно определяйте, считаете ли вы штуки товаров, события или последовательность действий пользователей.

Бесплатная книга «Google Analytics 4: Веб-потоки» вышла в 2022 году и содержит 699 страниц. Для этой статьи изучены фрагменты раздела электронной торговли, включая примеры событий и покупки. Это полезный учебный материал, однако старые скриншоты, способ создания тегов и числовые примеры нельзя автоматически считать текущей спецификацией GA4. В частности, в нашем коде value содержит товарную сумму без доставки и налога, согласно актуальному контракту Google.

У автора также есть книга «GA4 и Google BigQuery» 2025 года. Здесь использованы только её публичное описание и оглавление; полный текст не изучался. Её можно рассматривать как следующий уровень после надёжного сбора событий, если понадобятся собственные запросы и модели отчётности.

14. С чего начать в своём магазине

Выберите один реальный маршрут покупки и один контрольный заказ с понятными суммами. Запишите, когда он должен считаться покупкой, кто отправляет событие и какой ID связывает его с магазином. Затем проверьте цепочку до отчёта.

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

Словарь