Аналитика электронной торговли в Яндекс Метрике: план событий и проверка данных

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

Зачем бизнесу аналитика электронной торговли в Яндекс Метрике и где её границы

Электронная коммерция отвечает на вопросы, которые обычная статистика посещаемости не закрывает: какие товары и бренды пользуются спросом, какие категории чаще попадают в корзину, какие источники приводят заказы, а не просто визиты. В Яндекс Метрике доступны отчёты «Популярные товары», «Популярные категории и бренды», «Заказы», «Содержимое заказов», «Товары в корзине», «Заказанные товары» и «Промокоды», которые показывают спрос, доход, источники и детализацию по составу заказов.

Границы решения стоит обозначить сразу. Электронная коммерция — не «ещё один счётчик» и не замена учётной системе магазина. Она не считает деньги вместо бухгалтерии и не заменяет складской учёт. Её задача — связать действия покупателя на сайте с товарными данными и показать это в отчётах. Если магазин только проектируется, разметку удобнее закладывать на этапе разработки интернет-магазина, а не прикручивать задним числом.

Второе ограничение — редакция продукта. Функционал электронной коммерции в Яндекс Метрике доступен для редакций «Малый бизнес» и выше. Это значит, что перед планированием работ нужно свериться с фактической лицензией проекта, а не полагаться на общее описание.

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

Наконец, электронная коммерция не объясняет причины поведения покупателя. Она показывает, что произошло, но не отвечает на вопрос «почему». Ответ на «почему» ищется отдельно: через тесты, опросы, разбор воронки. Смешивать эти задачи не стоит — иначе от разметки будут ждать того, чего она не даёт.

План событий: какие действия магазина описывать

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

Минимальный набор действий, который стоит описать:

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

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

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

Кто владелец плана событий

План событий не должен оставаться документом «для галочки». У него есть владелец — обычно это аналитик или руководитель digital-направления, который отвечает за актуальность документа. Разработчик отвечает за реализацию, маркетолог — за то, что события покрывают нужные ему вопросы. Приёмку проводит тот, кто будет пользоваться отчётами.

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

Как выбрать способ передачи событий

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

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

Просмотр, корзина, заказ и оплата: как разложить путь покупателя

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

Просмотр списка и карточки товара

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

Корзина: добавление и удаление

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

Оформление заказа и оплата

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

Сверка событий с реальными заказами

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

Причины расхождений обычно такие:

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

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

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

Учебный пример: план событий для тестового магазина

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Условный интернет-магазин «Ромашка» продаёт товары для дома: около 1200 позиций, три верхнеуровневые категории, оформление заказа в два шага, оплата онлайн. Есть тестовый счётчик и тестовый контур магазина, отделённый от боевого.

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

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

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

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

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

Как проверить результат и принять работу

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

• План событий согласован и подписан владельцем: перечислены все действия, состав данных, ответственные.
• Для каждого события указан момент срабатывания и понятно, что считается дублем.
• Тестовый контур отделён от боевого, тестовые заказы не попадают в рабочие отчёты.
• Пройден полный путь покупателя: список, карточка, корзина, оформление, оплата.
• Проверены крайние случаи: удаление из корзины, повторное подтверждение, заказ без оплаты, применение промокода.
• Число событий оформления заказа сверено с числом заказов в учётной системе за один и тот же период.
• Расхождения объяснены и либо устранены, либо зафиксированы как известное ограничение.
• Состав данных о товаре соответствует плану: идентификатор, название, категория, бренд, цена, количество.
• Определён ответственный за поддержку разметки при изменениях на сайте.
• Зафиксирован порядок возврата: если после изменений данные пошли не так, есть копия прежней конфигурации и план отката.

Типичные ошибки и ограничения

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

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

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

Третья — тестовые заказы в боевых отчётах. Они искажают и число заказов, и суммы.

Четвёртая — смешение оформления и оплаты. Заказ без оплаты и оплаченный заказ — разные состояния, и их нельзя считать одним событием.

Пятая — изменения на сайте без обновления разметки. Переверстали корзину, поменяли шаги оформления — события отвалились, и никто этого не заметил.

Шестая — разные правила именования на разных витринах. Один и тот же товар или заказ начинает учитываться дважды, и отчёты перестают сходиться.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, нужен не «доступ к сайту», а конкретный набор сведений.

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

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

Кто отвечает за настройку и поддержку

Ответственность стоит разделить, иначе разметка останется «ничьей».

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

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

Что делать с отчётами дальше

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

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