Сквозная аналитика и электронная торговля в 1С-Битрикс: Метрика и данные

Реклама интернет-магазина почти всегда упирается в один вопрос: какие каналы приносят деньги, а какие только тратят бюджет. Обычный счётчик покажет визиты и конверсии на сайте, но не скажет, чем закончился звонок и сколько принёс оплаченный заказ после возвратов. Именно этот разрыв закрывает сквозная аналитика битрикс: она сшивает рекламный клик, обращение и реальную выручку в одну цепочку и позволяет считать окупаемость каждого источника, а не гадать. Магазин на 1С-Битрикс для этого удобная площадка — в нём уже есть заказы, каталог и данные, которые остаётся связать с Яндекс Метрикой и CRM.

Эта статья — практический разбор того, как выстроить аналитику магазина на 1С-Битрикс: как включить и наполнить электронную торговлю метрика через ecommerce dataLayer и события просмотра, корзины и покупки, как настроить цели и UTM-метки, что такое сквозная аналитика от клика до оплаты, как свести рекламу, коллтрекинг, CRM и заказы, как работает атрибуция и как считать ROI каналов, ДРР и CPO. Материал вырос из нашей практики повышения конверсии интернет-магазинов — по делу, без выдуманных «средних по рынку» цифр.

Зачем магазину аналитика: решения на данных

Аналитика существует не ради красивых графиков, а ради решений. Каждый день владелец магазина отвечает на вопросы, которые стоят денег: увеличить бюджет на контекст или урезать, стоит ли SEO вложений, почему падают заказы, где в воронке теряются покупатели. Без данных на эти вопросы отвечают интуицией — и ошибаются дорого. С данными решения становятся проверяемыми: не «кажется, реклама работает», а «канал приносит столько-то заказов по такой-то цене».

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

• Куда вкладывать бюджет. Видно, какие каналы окупаются, а какие сжигают деньги, — и можно перераспределить рекламу в пользу прибыльных.
• Где чинить воронку. Аналитика показывает, на каком шаге отваливаются покупатели: карточка, корзина, оформление, оплата.
• Что продаётся, а что нет. Отчёты по товарам подсказывают, какие позиции тянут выручку, а какие лежат мёртвым грузом.
• Работают ли изменения. После доработок сайта или новой кампании видно, стало лучше или хуже, а не «вроде живее».
• Сколько стоит клиент и сколько он приносит. Связка расходов и выручки даёт стоимость заказа и отдачу на вложенный рубль.

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

Уровни аналитики: сайт, обращения, деньги

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

Веб-аналитика видит первый уровень отлично, но обрывается на «оформил заказ» или «оставил заявку». Что было дальше — дозвонился ли менеджер, оплатил ли клиент, не вернул ли товар — счётчик не знает. Учётная система видит деньги, но не знает, из какого рекламного объявления пришёл покупатель. Между этими уровнями — разрыв, и именно его закрывает сквозная аналитика: она протягивает единую нить от источника трафика до оплаченного заказа. Прежде чем строить эту нить, разберём фундамент — электронную торговлю в Метрике.

Электронная торговля в Яндекс Метрике

Электронная торговля (e-commerce) — это режим Метрики, в котором счётчик собирает не просто визиты, а действия с товарами и заказами: какие карточки смотрели, что добавляли и убирали из корзины, какие заказы оформили и на какую сумму. Из этих данных Метрика строит отдельные отчёты — по товарам, по заказам, по популярным категориям и «брошенным» корзинам, — где видна выручка, а не только клики.

Что даёт включённая электронная торговля магазину:

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

Что такое dataLayer и как он устроен

dataLayer (уровень данных) — это обычный JavaScript-массив на странице, через который сайт передаёт системам аналитики структурированные данные о событиях. Идея простая: вместо того чтобы каждый счётчик «выковыривал» цену и название товара прямо из вёрстки (которая меняется от дизайна к дизайну), сайт один раз кладёт данные в единый контейнер в понятном формате, а аналитика их считывает.

Работает это так: массив объявляют на странице как можно раньше, а затем «пушат» в него объекты-события методом push. Каждый объект описывает, что произошло и с какими товарами. Метрика (а при желании и другие счётчики) слушает этот массив и превращает события в отчёты.

<!-- Объявляем контейнер данных ДО кода счётчика -->
<script>
  window.dataLayer = window.dataLayer || [];
</script>

<!-- Пример: передача одного события -->
<script>
  window.dataLayer.push({
    "ecommerce": {
      "currencyCode": "RUB",
      "detail": {
        "products": [{
          "id": "TShirt-45",
          "name": "Футболка Basic",
          "price": 1290,
          "brand": "Acme",
          "category": "Одежда/Футболки"
        }]
      }
    }
  });
</script>

Ключевой узел — объект ecommerce, внутри которого лежит одно из действий: detail (просмотр товара), add (добавление в корзину), remove (удаление), purchase (покупка). У каждого действия есть список products с их характеристиками. Валюту задают полем currencyCode. Такой единый формат — не прихоть Метрики: он совпадает с общепринятой моделью данных электронной торговли, поэтому корректный dataLayer переносится между инструментами почти без переделок.

Счётчик Метрики на 1С-Битрикс

Прежде чем передавать события, на сайте должен стоять сам счётчик. На 1С-Битрикс код счётчика подключают одним из аккуратных способов — так, чтобы он был на всех страницах и не дублировался. Ключевое правило: код счётчика ставят один раз, а объявление dataLayer — строго до него, иначе первые события могут не попасть в контейнер.

Типичные места для кода счётчика в шаблоне сайта:

• Шаблон сайта (header/footer). В файле header.php или footer.php активного шаблона — так счётчик оказывается на всех страницах.
• Через управляемую область. Аккуратный вариант — вынести код в подключаемый файл и вставлять его одной строкой, чтобы не плодить копии.
• Штатные настройки счётчиков. В некоторых редакциях есть места для служебных кодов в настройках сайта или модуля веб-аналитики.

Порядок подключения важнее места. Сначала — объявление контейнера данных, затем — код счётчика Метрики, в котором указано, что источник электронной коммерции равен этому контейнеру. Если поменять порядок местами, события, отправленные при загрузке страницы (например, просмотр товара), рискуют «улететь» раньше, чем счётчик начнёт слушать. Поэтому на 1С-Битрикс объявление window.dataLayer обычно ставят в самом верху <head> или в начале шаблона.

<!-- 1) Контейнер данных — в самом верху, до счётчика -->
<script>window.dataLayer = window.dataLayer || [];</script>

<!-- 2) Код счётчика Метрики (схематично) -->
<script>
  (function(m,e,t,r,i,k,a){ /* инициализация счётчика */ })
  (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

  ym(XXXXXX, "init", {
    clickmap: true,
    trackLinks: true,
    accurateTrackBounce: true,
    ecommerce: "dataLayer"   // источник данных электронной торговли
  });
</script>

События e-commerce: просмотр, корзина, покупка

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

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

Каждое событие несёт список товаров с полями: идентификатор (обязательно — он связывает данные с каталогом), название, цена, бренд, категория, а для покупки — ещё количество. Для события purchase добавляется блок actionField с идентификатором заказа и суммой. Единый и полный набор полей — залог того, что отчёты по товарам будут читаемыми, а не «безымянными позициями без цен».

dataLayer в шаблоне: реализация

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

Просмотр товара (detail). На странице карточки, где уже известны данные товара, отправляем событие при загрузке:

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    "ecommerce": {
      "currencyCode": "RUB",
      "detail": {
        "products": [{
          "id": "<?= htmlspecialchars($productId) ?>",
          "name": "<?= htmlspecialchars($productName) ?>",
          "price": <?= (float)$productPrice ?>,
          "category": "<?= htmlspecialchars($productCategory) ?>"
        }]
      }
    }
  });
</script>

Добавление в корзину (add). Это событие привязывают к нажатию кнопки «В корзину». В момент клика в dataLayer уходит объект с добавленным товаром:

<script>
  document.querySelectorAll("[data-add-to-cart]").forEach(function (btn) {
    btn.addEventListener("click", function () {
      window.dataLayer.push({
        "ecommerce": {
          "currencyCode": "RUB",
          "add": {
            "products": [{
              "id": btn.getAttribute("data-id"),
              "name": btn.getAttribute("data-name"),
              "price": parseFloat(btn.getAttribute("data-price")),
              "quantity": 1
            }]
          }
        }
      });
    });
  });
</script>

Аналогично строится событие remove — на удаление позиции из корзины. Обратите внимание: данные для событий берутся из атрибутов элементов (data-id, data-name, data-price), которые вы выводите в вёрстке из свойств товара. Это надёжнее, чем парсить текст цены со страницы, где формат может меняться. В шаблонах 1С-Битрикс такие атрибуты удобно проставлять там же, где выводится карточка или элемент списка каталога.

Событие покупки на странице «Спасибо»

Событие purchase — сердце электронной торговли, поэтому разберём его отдельно и подробно. Отправляют его в один момент — когда заказ уже создан, на странице благодарности («Спасибо за заказ»). Именно на этой странице у вас есть номер заказа, его сумма и состав — их и передают в dataLayer.

<!-- Страница "Спасибо за заказ" (после оформления) -->
<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    "ecommerce": {
      "currencyCode": "RUB",
      "purchase": {
        "actionField": {
          "id": "<?= htmlspecialchars($orderId) ?>",
          "revenue": <?= (float)$orderTotal ?>,
          "coupon": "<?= htmlspecialchars($orderCoupon) ?>"
        },
        "products": [
          <?php foreach ($orderItems as $item): ?>
          {
            "id": "<?= htmlspecialchars($item['id']) ?>",
            "name": "<?= htmlspecialchars($item['name']) ?>",
            "price": <?= (float)$item['price'] ?>,
            "quantity": <?= (int)$item['quantity'] ?>
          },
          <?php endforeach; ?>
        ]
      }
    }
  });
</script>

Здесь actionField.id — номер заказа, revenue — его сумма, а список products собирается циклом из состава заказа. Данные берут из объекта заказа, который на 1С-Битрикс доступен на странице оформления после создания. Ключевой момент — событие должно отправиться ровно один раз на заказ. Отсюда два практических правила.

1. Одна страница благодарности — одно событие. Событие покупки живёт только на финальной странице, а не на промежуточных шагах оформления.
2. Защита от повторной отправки. Если пользователь обновит страницу «Спасибо», заказ не должен посчитаться снова: событие привязывают к факту нового заказа, а не к каждому открытию страницы.
3. Реальная сумма заказа. В revenue передают итог заказа так, как он учитывается в бизнесе (со скидкой, с учётом доставки — по вашей методике), и делают это единообразно.
4. Идентификатор заказа настоящий. В id кладут реальный номер заказа — он потом свяжет данные Метрики с заказом в магазине и CRM.

Цели и конверсии в Метрике

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

Какие цели обычно настраивают для интернет-магазина:

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

UTM-метки и источники трафика

Чтобы аналитика знала, откуда пришёл посетитель, ссылки в рекламе размечают UTM-метками — параметрами в адресе, которые описывают источник перехода. Метрика читает их и раскладывает трафик по каналам, кампаниям и объявлениям. Без разметки платные каналы сливаются в безликий «переход по рекламе», и посчитать их по отдельности невозможно.

Пять стандартных UTM-параметров:

Главная дисциплина UTM — единый справочник значений. Если один и тот же канал в разных кампаниях размечен как yandex, Yandex и ya, аналитика разложит их в три разных источника, и картина рассыплется. Поэтому заранее фиксируют соглашение: как называется каждый источник и medium, в нижнем регистре, без пробелов. Метки удобно генерировать по шаблону, а не руками. И ещё важное для сквозной аналитики: значения UTM нужно не только прочитать Метрикой, но и сохранить в заказе — об этом дальше.

Что такое сквозная аналитика

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

Что именно «сшивает» сквозная аналитика:

• Рекламу и клики. Расходы на каналы и переходы с UTM-метками — сколько потратили и сколько привели.
• Поведение на сайте. Визиты, воронку, добавления в корзину и заказы из электронной торговли.
• Обращения. Заявки из форм и звонки через коллтрекинг с привязкой к источнику.
• Деньги. Статусы и суммы заказов из магазина и CRM — что реально оплачено, а не просто оформлено.

Отличие от обычной аналитики в том, где заканчивается измерение. Веб-аналитика меряет до «оформил заказ», сквозная — до «оплатил и не вернул». Это меняет сам вопрос: не «какой канал даёт больше визитов и конверсий», а «какой канал приносит больше денег на вложенный рубль». Именно поэтому сквозная аналитика — инструмент управления бюджетом, а не только наблюдения за сайтом. Разберём её ядро — путь клиента.

Путь клиента: от клика до оплаты

Ядро сквозной аналитики — прослеживаемый путь клиента. Представим его как цепочку точек, между которыми нужно сохранить связь. Если хоть одно звено рвётся — теряется привязка заказа к источнику, и всё рассыпается на «отдельно реклама, отдельно деньги».

1. Клик по рекламе. Пользователь переходит по объявлению с UTM-метками — фиксируется источник, кампания, объявление.
2. Визит и идентификатор. Метрика присваивает визиту идентификатор посетителя (ClientID) и запоминает источник перехода.
3. Обращение. Клиент оставляет заявку или звонит; коллтрекинг связывает звонок с визитом и его метками.
4. Заказ. При оформлении в самом заказе сохраняются метки и идентификатор — источник «переезжает» в заказ.
5. Оплата. Менеджер меняет статус на «оплачен»; сквозная аналитика уже знает канал, потому что метка лежит в заказе.

Ключевая техническая идея — сохранять источник в заказе. На 1С-Битрикс для этого при оформлении читают UTM-метки (из адреса или из куки, куда их положили при входе на сайт) и идентификатор Метрики, а затем записывают их в свойства заказа или передают в карточку CRM. С этого момента заказ «носит» свой источник с собой по всем статусам — от «новый» до «оплачен» и «доставлен». Именно эта запись превращает разрозненные системы в сквозную аналитику.

Связка «реклама ↔ CRM ↔ заказы»

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

Самое слабое звено обычно третье: заказ создаётся без сохранённого источника, и потом невозможно понять, из какого канала он пришёл. Поэтому связка выстраивается «от заказа»: при оформлении на 1С-Битрикс источник (UTM и ClientID) записывают в свойства заказа, а при интеграции с CRM переносят в карточку сделки. Дальше, когда сделка проходит статусы и оплачивается, вся её выручка автоматически относится к правильному каналу. Как технически связать магазин и CRM, распределить роли систем и не задвоить данные, мы разбираем в материале про интеграцию телефонии и коллтрекинга в 1С-Битрикс — там же о том, как звонок становится измеримым обращением.

Отдельно про «деньги, а не заявки». Сквозная аналитика оценивает каналы по оплаченным заказам, а не по всем оформленным. Это принципиально: канал может давать много заказов, которые потом отменяются или не оплачиваются, — и по «оформленным» он выглядит героем, а по «оплаченным» проваливается. Поэтому связка с CRM важна не только для источника, но и для статуса: система должна знать, дошёл ли заказ до денег.

Коллтрекинг как часть сквозной аналитики

Во многих нишах значимая доля заказов приходит звонком, а не через корзину. Если звонки не измерять, каналы, которые их приносят, выглядят «пустыми» — и бюджет уходит не туда. Коллтрекинг (отслеживание звонков) закрывает этот пробел: он связывает телефонный звонок с рекламным источником, из которого пришёл позвонивший.

Как это устроено — два основных типа:

Динамический коллтрекинг — самый точный для сквозной аналитики: он подставляет каждому посетителю свой номер из пула, поэтому звонок можно связать не просто с каналом, а с конкретным визитом, его UTM-метками и даже ключевым словом. Дальше звонок попадает в CRM как обращение с источником, а из обращения вырастает заказ — и цепочка «клик → звонок → заказ → оплата» замыкается. Как подключить телефонию и коллтрекинг на 1С-Битрикс, связать звонки с CRM и не потерять источник, мы подробно разбираем в отдельной статье про интеграцию телефонии и коллтрекинга.

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

Атрибуция: последний клик и модели

Клиент редко покупает с первого касания: увидел баннер, вернулся из поиска, пришёл по бренду и оформил заказ. Возникает вопрос — какому каналу «засчитать» заказ? Правило распределения этой заслуги называется моделью атрибуции. Разные модели дают разный ответ, и это не философия, а деньги: от модели зависит, какой канал вы сочтёте прибыльным.

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

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

ROI, ДРР и CPO по каналам

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

Как их читать. CPO показывает, во сколько обходится заказ: если стоимость заказа выше маржи с него, канал убыточен, каким бы «трафиковым» ни был. ДРР удобна для сравнения каналов между собой — какая доля выручки уходит на рекламу; чем ниже, тем эффективнее. ROI/ROMI отвечает на главный вопрос — вернулись ли вложения и сколько прибыли принёс каждый рубль. Считать эти метрики корректно можно только при сквозной связке: без привязки заказа к источнику числитель и знаменатель берутся из разных «вселенных».

Мы сознательно не приводим «нормальных» значений ROI или ДРР — их не существует в отрыве от бизнеса. Приемлемая доля рекламных расходов зависит от маржинальности товара, среднего чека, доли повторных покупок и длины цикла сделки: то, что убыточно для низкомаржинального товара, отлично работает для высокого чека с повторными покупками. Поэтому ориентиры считают под конкретный магазин, а не берут «среднее по рынку». Помочь свести эти расчёты и увязать их с ростом конверсии — задача, которую мы решаем в рамках услуги CRO, а привлечение целевого трафика — в рамках SEO-продвижения.

Отчёты и дашборды

Собранные данные бесполезны, если в них никто не смотрит. Задача отчётов — превратить массив цифр в несколько экранов, по которым принимают решения. Здесь работает то же правило, что и в начале статьи: отчёт существует ради решения, а не ради полноты.

Какие срезы обычно выносят в рабочие отчёты магазина:

• Каналы и деньги. Выручка, число заказов, CPO и ДРР по источникам — главный экран для решений по бюджету.
• Воронка. Визит → карточка → корзина → оформление → оплата: где теряются покупатели.
• Товары. Что смотрят, добавляют и покупают — из отчётов электронной торговли.
• Обращения. Заявки и звонки по источникам, доля дошедших до заказа.
• Динамика. Как метрики меняются во времени и после изменений на сайте или в рекламе.

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

GA-альтернативы и место Метрики

Исторически веб-аналитику часто ассоциировали с Google Analytics, но для магазина в российском контексте базовой системой сегодня разумно считать Яндекс Метрику: у неё сильная электронная торговля, вебвизор, карты, встроенные отчёты по источникам и хорошая совместимость с рекламной экосистемой Яндекса. Именно поэтому в этой статье мы строим примеры на Метрике.

Как соотносятся инструменты и слои аналитики:

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

Приватность и согласие на cookie

Аналитика работает с данными пользователей — идентификаторами, cookie, поведением, — а это область законодательства о персональных данных (в России — прежде всего 152-ФЗ). Мы описываем принципы, а не даём юридическую консультацию: конкретные формулировки баннера согласия, политику обработки данных и порядок их хранения сверьте с вашим юристом.

Общие ориентиры осторожной практики:

• Уведомление о cookie. Как правило, на сайте размещают заметное сообщение об использовании cookie и веб-аналитики.
• Политика конфиденциальности. Действующая и доступная политика обработки персональных данных со ссылкой в подвале и формах.
• Согласие там, где требуется. Сбор согласия на обработку данных и рассылки — явным действием, а не «по умолчанию».
• Не собирать лишнего. В аналитику и dataLayer не передают персональные данные, которые там не нужны (телефоны, адреса в открытом виде).

Технический аспект: при отказе пользователя от cookie часть данных объективно теряется, и это нормально — задача не «собрать всё любой ценой», а собирать корректно и в рамках закона. Не кладите в dataLayer чувствительные персональные данные: для аналитики достаточно идентификаторов заказа и товаров, а не имени и телефона покупателя. И ещё раз подчеркнём: правовую часть — тексты согласий, баннер cookie, политику хранения — должен оценить юрист, потому что требования зависят от деталей бизнеса и меняются.

Пошаговое внедрение

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

1. Поставьте счётчик Метрики. Один экземпляр на всех страницах, объявление dataLayer — строго до кода счётчика.
2. Включите электронную торговлю. Активируйте опцию в счётчике и укажите контейнер данных (dataLayer).
3. Настройте событие покупки. Отправляйте purchase на странице «Спасибо» один раз на заказ, с номером, суммой и составом.
4. Добавьте события товаров. Просмотр, добавление и удаление из корзины — чтобы собрать воронку.
5. Заведите цели. Заказ, заявка, звонок — ключевые действия для оценки каналов.
6. Разметьте рекламу UTM. Единый справочник значений, метки на всех платных ссылках.
7. Сохраняйте источник в заказе. Пишите UTM и ClientID в свойства заказа и переносите в CRM.
8. Подключите коллтрекинг. Свяжите звонки с источником и с обращениями в CRM.
9. Сведите расходы и выручку. Соедините затраты каналов с оплаченными заказами — получите CPO, ДРР, ROI.
10. Соберите рабочие дашборды. Экран «каналы и деньги» и «воронка», проверка на двойной счёт и правовую часть с юристом.

Частые ошибки

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

• Двойной счёт покупки. Событие purchase уходит при каждом открытии страницы «Спасибо» — выручка завышена, решения кривые.
• Нет привязки заказа к источнику. Заказ не хранит UTM и ClientID, поэтому невозможно понять, из какого канала он пришёл.
• Задвоенный счётчик. Код Метрики вставлен в нескольких местах — двойные визиты и события.
• Разнобой в UTM. Один источник размечен по-разному (yandex/Yandex/ya) — трафик рассыпается на «фантомные» каналы.
• Оценка по оформленным, а не оплаченным. Каналы хвалят за заказы, которые потом отменяются и не оплачиваются.
• Игнор звонков. Без коллтрекинга каналы, приносящие звонки, выглядят «пустыми» — бюджет режут не там.
• Одна модель атрибуции вслепую. Решения только по последнему клику срезают верх воронки.
• Событие покупки без идентификатора и суммы. Пустой revenue или отсутствующий номер заказа — данные бесполезны.
• Персональные данные в dataLayer. Телефоны и адреса в открытом виде в контейнере данных — риск и лишнее.
• Гигантский дашборд. Десятки виджетов, в которые перестают смотреть, вместо двух рабочих экранов.
• «Аналитика ради аналитики». Отчёты собраны, но ни одно решение по ним не принимается.
• Забыть про cookie-согласие. Сбор данных без уведомления и политики — правовой риск, который не согласован с юристом.

Чек-лист

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

1. Счётчик один. Метрика стоит на всех страницах ровно в одном экземпляре, dataLayer объявлен до неё.
2. E-commerce включена. Опция активна, контейнер данных указан, события реально приходят.
3. Покупка не двоится. Событие purchase отправляется один раз на заказ, с номером, суммой и составом.
4. Товарные события работают. Просмотр, добавление и удаление из корзины попадают в отчёты.
5. Цели заданы. Заказ, заявка, звонок настроены и срабатывают.
6. UTM едины. Единый справочник значений, все платные ссылки размечены.
7. Источник в заказе. UTM и ClientID сохраняются в заказ и переносятся в CRM.
8. Звонки измеримы. Коллтрекинг связывает звонок с источником и с обращением.
9. Деньги сведены. Расходы каналов соединены с оплаченными заказами: считаются CPO, ДРР, ROI.
10. Отчёты и право. Рабочие дашборды «каналы» и «воронка» на месте, cookie-согласие согласовано с юристом.

Вывод

Сквозная аналитика в 1С-Битрикс — это не отдельный «магический» сервис, а дисциплина связывания данных: электронная торговля Метрики через dataLayer, цели и UTM-метки, коллтрекинг для звонков и связка заказов с CRM складываются в единую нить от рекламного клика до оплаченного заказа. Ценность рождается не из количества счётчиков, а из сохранённого в заказе источника: как только каждый заказ «носит» свой канал, вы считаете не визиты, а деньги — CPO, ДРР и ROI по источникам.

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

Другие разборы по продвижению и конверсии магазина на 1С-Битрикс — в рубрике SEO и продвижение: от структуры каталога и индексации до удержания и аналитики. Смежные темы — email- и CRM-маркетинг для повторных продаж и A/B-тестирование и CRO для роста конверсии по данным.