Расширенная торговля — самая полезная функция в Google Analytics. Но ее сложно настроить так, чтобы не терялись данные и не появлялись ошибки в работе.
В этой статье — разбор 15 распространённых ошибок, которые мешают вам пользоваться инструментом по максимуму. Для удобства они разделены на: стратегические ошибки, проблемы с GA, с Google Tag Manager, проблемы с уровнями данных и с процессом отладки.
Стратегические проблемы
1. Мало времени на теоретическую подготовку
Я настоятельно рекомендую изучить несколько важных сайтов перед внедрением Расширенной торговли. У вас будет меньше рисков сделать ошибку, если вы уже будете знать, как происходит настройка.
Вот полезные ссылки (на английском языке):
- Гайд по настройке расширенной торговле через GTM.
- Гайд от Google по модулю расширенной торговле.
- 15 советов по внедрению расширенной торговли.
2. Не определен масштаб перед началом изменений
Модуль расширенной торговли включен в пакет стандартных отчетов Google Analytics. Его можно найти по адресу Conversion > E-commerce (перед этим активируйте модуль на уровне просмотра).
В главные отчеты подтянутся основные данные. Для этого включите в расширенной торговле следующие показатели:
- показы товаров;
- клики по карточкам товаров;
- просмотр деталей о товаре;
- добавление или удаление товара из корзины;
- показы внутренней рекламы;
- клики по внутренней рекламе;
- переход на страницу чекаута;
- заказы;
- возвраты товара.
Однако делать все сразу не обязательно. Я рекомендую добавлять новые показатели постепенно. Можно все шаги разбить на два-три этапа. Я обычно следую такой модели:
- На первом этапе реализуем отслеживание заказов и посещение страниц чек-аута.
- На втором — добавление и удаление из корзины.
- На третьем — клики по продуктам и просмотр карточек товаров.
- Далее — оставшиеся метрики.
3. Неверно определено время, которое требуется для реализации
Я думаю, вы поняли: настройка Расширенной электронной торговли — процесс не на один день. Есть ряд плагинов, которые упрощаю внедрение для определенных случаев, но все равно требуется время на тщательное планирование всех работ.
Обычно время требуется команде программистов на реализацию технической части и маркетологам на постановку четкого задания. Будьте внимательны при планировании всех действий. Лучше собирать данные на неделю позже, чем из-за спешки пропустить ошибку и получить неверную информацию в системе аналитики.
Проблемы с Google Analytics
4. Расширенная торговля недоступна
Google Analytics показывает по умолчанию только дату события, если вы включите модуль на уровне просмотра.
Обязательно включите обе настройки.
5a. Использование неверных шагов чекаута
Процесс оформления заказа можно настроить как часть модуля расширенной торговли. Для этого придется поработать как с GA, так и с GTM. Система аналитики — простая часть, но и здесь встречаются ошибки.
Например, в GA вам нужно только определить шаги — этапы оформления заказа. В них нельзя включать непосредственно покупку.
Вот хороший пример:
Имейте в виду:
- Не настраивайте страницу корзины в качестве шага оформления заказа.
- Не добавляйте покупку в конфигурацию Расширенной торговли GA.
5b. Не определены маркеры чекаута
Всегда добавляйте метки для шагов оформления заказа, которые вы определили и реализовали.
Часть настройки Google Analytics проста: гораздо больше проблем возникает при работе с Google Tag Manager и реализацией уровней данных.
Проблемы с Google Tag Manager
6. Использован неверный тег Universal Analytics
Создайте тег Universal Analytics и установите Track Type (тип отслеживания) Transaction (транзакция). Это нужно, когда вы внедряете стандартный модуль расширенной торговли. Однако такой вариант не рекомендуется.
Всегда выбирайте Расширенную торговлю, когда хотите реализовать покупку. Также нужно отправлять всю информацию, которая связана с просмотром страницы либо с тегом события в Google Analytics. Не забудьте включить функции Расширенной торговли.
Вот пример:
7. Неверно использован параметр не-взаимодействия
Для всех событий нужно определить параметр, который говорит об отсутствии взаимодействий пользователя с ним.
Вот пример для случая, когда мы хотим отследить действие «клик по продукту»:
Здесь все настроено правильно. Это взаимодействие действительно снижает показатель отказов конкретной страницы.
Будьте внимательны при передаче данных из модуля расширенной торговли непосредственно в Google Analytics. Событие «страницы с детальной информацией о товаре» — пользователь попадает на страницу с описанием товара и сразу покидает сайт. Это событие не должно влиять на показатель отказов, соответственно, нужно установить Non-Interaction-Hit в значение True.
Принять к сведению:
- Преимущество передачи событий в том, что в Google Analytics проще все отлаживать и настраивать. Кроме того, большинству пользователей проще применять сегментацию к определенным действиям.
- А преимущество использования просмотров страниц в том, что вы не отправляете информацию о взаимодействии в Google Analytics. Если вы близки к ограничениям GA на количество взаимодействий, это особенно важно.
8. Дублирующиеся страницы из-за неверных триггеров
Выше мы уже сказали: вы можете отправить данные из модуля торговли в GA с помощью настройки события или тега просмотра страницы.
Иногда необходимо ограничить число обращений к GA и использовать именно просмотры страниц. Тогда можно использовать два простых тега:
При такой настройке вы будете передавать два просмотра при посещении пользователем страницы информации о товаре. Чтобы такого не происходило, нужно изменить настройки в GTM.
Нужно добавить триггер исключения в тег: GA > Pageview > All Pages. Так он не будет срабатывать на странице информации о товаре (или другой страницы, реализованной в модуле расширенной торговли).
Лучший способ — настроить его на уровне страницы, чтобы исключительное событие соответствовало исключительному триггеру.
В приведенном выше примере повторного просмотра страницы не будет, потому что есть исключение. Это значит, что странице детальной информации сработает только тег «Электронная торговля — Сведения о продукте».
9. Использование GTM напрямую для передачи Custom Dimension на уровне продукта
Пользовательские измерения и показатели в рамках продукта уникальны для модуля расширенной торговли. Если эти атрибуты включить в тег GTM, они не сработают.
Это дополнительные данные, их нужно добавлять непосредственно в объекты массива продуктов.
В этом примере dimension5 находится в массиве products.
10. Передача дублирующейся транзакции
Есть много случаев, когда повторяющиеся транзакции хранятся в Google Analytics. Вот пример:
На скриншоте есть несколько транзакций с уникальным ID.
Это плохо влияет на остальные данные в Google Analytics, потому что система не может различать дублирующиеся ID.
Два варианта решения проблемы:
- Убедиться, что разработчик активирует код отслеживания (или dataLayer.push) один раз за транзакцию.
- Внедрите решение GTM для предотвращения дублирования транзаций.
Проблемы на уровне данных
11. Несоблюдение правильной структуры модуля и соглашения об именах
Модуль Расширенной торговли чаще всего реализуют так:
- Информация из модуля — сведения о просмотре продукта, заказы и т. д. — передаются разработчиком на уровень данных в GA.
- Universal Analytics Tag передает данные в GA через просмотр страницы или тег события.
Однако вот то, что обязательно нужно донести до разработчиков: данные об электронной торговле нужно отправлять в правильном формате, не нарушая соглашения об именах.
Вот три основных правила для «dataLayer.push»:
- Должен присутствовать объект электронной коммерции, который содержит данные, относящиеся к определенному шагу или действию воронки продаж.
- Название действия должно присутствовать, при этом быть неизменным.
- Данные, относящиеся к определенному действию, нужно передавать в Google Analytics.
Вот рабочий вариант:
В примере есть объект электронной коммерции, имя действия — add — и связанные с ним данные — product.
DataLayer.push должен содержать только обязательные данные. Например, поле variant таковым не является. Проверьте, использует ли разработчик правильные имена везде, когда обращается к определенному элементу.
12. Не отправлять информацию уровня продукта на следующий этап воронки
Согласованность действительно важна, когда речь заходит о модуле электронной торговли.
Вот пример. Разработчик отправляет сведения о товаре — вариант и бренд — в представление сведений о продукте. В таком случае их нужно передать вместе со всеми другими соответствующими действиями, например «добавление в корзину» и «оформление заказа».
Если вы этого не сделаете, то на страницах, отличных от страницы с деталями и товаре, вы просто потеряете информацию. Поэтому все нужное передавайте на каждом этапе воронки.
13. Непонятная и непоследовательная структура товарной категории
Категория в обычной электронной коммерции может иметь только один слой. В нем вы храните всю информацию о ней. Но в расширенной торговле есть пять уровней данных о товарах.
Обязательное требование: отправлять категорию с каждым продуктом на всех этапах воронки, к которым вы хотите выполнить запрос.
Вот пять потенциальных уровней, которые можно внедрить.
Категория, к которой относится продукт — например, одежда. Можно использовать разделитель « / » для указания иерархии: « Одежда / Для мужчин / Джинсы ». Одежда будет первым уровнем категории, а джинсы — третьим.
Вот, как выглядит код для этого примера:
Разделение полезно тем, что вы можете анализировать эффективность категорий на разных уровнях.
14. Путаница с Checkout и CheckoutOption
Модуль расширенной торговли может отправлять несколько видов информации о чекауте:
- Конкретный шаг оформления покупки.
- Опции заказа.
Всегда отправляйте опцию заказа после передачи текущего этапа оформления. Иначе это просто не сработает. Можно использовать, например, для передачи дополнительной информации о конкретном шаге пользователя.
Например, если пользователь выбирает способ оплаты на 3 шаге, вам нужно передать информацию со второго шага, когда пользователь впервые попадает на страницу с выбором метода оплаты. Тогда, после выбора человеком способа оплаты, вы сможете передать информацию о выбранном способы далее.
Проблемы с отладкой
15. Некорректное проведение тестирования
Часто компании внедряют Расширенную торговлю со всеми функциями за один раз, а потом ничего не тестируют и не проверяют.
Рекомендация общая: разбейте процесс внедрения модуля на несколько шагов. А перед отправлением очередной партии изменений в продакшн, проведите тщательное тестирование на некоторой выборке данных.
Заключение
Расширенная электронная торговля — очень полезный модуль в Google Analytics. И, как вы видели, с ним возникает много проблем самого разного характера.
Но затраченные усилия обязательно окупятся. А ошибки, которые мы с вами разобрали, помогут не наступать на одни и те же грабли.
