Введение

Любой, кто использовал Google Analytics или похожие системы веб-аналитики, знает, насколько они удобны для отслеживания и анализа данных по эффективности интернет-магазина. Основное удобство заключается в том, что в этих системах веб-аналитики есть заранее продуманная структура данных для отслеживания, — «Электронная торговля» или «Электронная коммерция». Это дает возможность не придумывать каждый раз с нуля, в каком виде собирать данные, и максимально быстро перейти к использованию данных для оптимизации эффективности.

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

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

В этой статье уделим внимание тому, как построить эффективный процесс внедрения электронной торговли Google Analytics в крупный проект. Под крупным проектом будем понимать сайт любого размера, с которым работает как минимум такая команда: веб-аналитик, frontend- и backend-разработчики, бизнес-аналитик и product owner. И, конечно, этому проекту нужны данные веб-аналитики для принятия решений, а не для того, чтобы просто закрыть задачу из своего бэклога разработки.

Дисклеймер

Всё описанное в статье — исключительно наш опыт. Если у вас получилось иначе, это всего лишь значит, что у вас получилось иначе.

У многих, даже крупных игроков рынка e-commerce, пока получилось не все. Данные электронной торговли передаются на фронте, поэтому их легко можно проверить в консоли или в GET-запросах вида https://www.google-analytics.com/r/collect/…, или чуть более удобно с расширением Google Analytics Debugger для Google Chrome. Поэтому вы можете достаточно быстро проверить, у кого из ТОП-100 крупнейших интернет-магазинов России по данным DataInsight все данные отслеживаются.

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

Список заинтересованных сторон может отличаться в зависимости от структуры компании. Как правило, основные пользователи систем веб-аналитики — это представители бизнеса, команда продукта и продуктовые аналитики.

1. Представители бизнеса

В зависимости от используемых данных систем веб-аналитики представителей бизнеса можно разделить на несколько частей:

Интернет-маркетологи и специалисты по различным каналам трафика — те, кто используют системы веб-аналитики для анализа и оптимизации трафика. У этой группы нет особых требований к данным электронной торговли. Достаточно того, что будут передаваться данные по транзакциям и доходу.
Категорийные менеджеры и закупки — те, кому принципиальна детализация данных по товарам. Основное требование этой группы — возможность получить ключевые показатели электронной торговли в разрезе характеристик продукта.
Руководители отдельных проектов или направлений — по своим задачам обычно очень универсальны, поэтому объединяют требования предыдущих двух групп.

2. Команда продукта

В команде продукта могут быть разные роли: разработчики, бизнес-аналитики, руководители проектов, дизайнеры, product owner’ы. Но у всех одна задача: сделать продукт лучше. И по возможности вносить улучшения, понимая не только свои приоритеты, но и частоту использования того или иного функционала.

Именно это является основным требованием к данным систем-аналитики. Но не стоит забывать, что после получения данных команда продукта формирует и проверяет гипотезы в рамках А/В-тестов.

3. Продуктовые аналитики (или веб-аналитики)

Команда, ответственная за целостность и консистентность данных систем веб-аналитики, необходимых для принятия решения о продукте. Задача продуктовых аналитиков в этом процессе — качество данных. Кроме того, они понимают, как собирает и обрабатывает данные Google Analytics. Поэтому именно они должны собирать все требования от остальных команд.

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

В финале этого процесса необходимо однозначно понимать:

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

Второй этап: обсуждение внедрения данных с командой продукта

После того, как будут сформулированы требования к передаваемым данным, обязательно необходимо вернуться к команде продукта и обсудить с бизнес-аналитиками, из каких источников будут передаваться все необходимые данные.
Например, скорее всего на некоторых страницах невозможно с фронта собрать часть характеристик товаров, необходимых категорийным менеджерам. Или на каких-то страницах для этого нужно делать отдельный запрос к базе. Если после обсуждения вы понимаете, что возникают такие сложности, стоит сразу пойти по пути импорта бОльшей части данных по товарам в Google Analytics напрямую из базы с данными по товарам. И, соответственно, на фронте передавать минимум информации по товарам: название, стоимость, принадлежность к списку товаров и позиция в списке.

Третий этап: описание решения по передаче данных

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

Поставить код Google Analytics напрямую в код сайта

Самый простой и неудобный вариант — разработчики ставят код Google Analytics в код сайта и на своей стороне реализуют передачу всех данных по электронной торговле.
Чаще всего к такому решению приходят в командах с сильной разработкой из-за ощущения того, что данные будут консистентны, — разработчики же никогда не ошибаются. К сожалению, они тоже ошибаются, но при такой реализации все завязано только на разработчиков и их релизный цикл. Любые изменения возможны только на стороне разработки, веб-аналитики нужны только для использования данных.

Плюсы этого варианта:

выглядит очень просто и дает ощущение консистентности собираемых данных.

Минусы этого варианта:

любая ошибка в разработке ведет к потере данных;
нет возможности передать те же самые данные в другую систему аналитики.

В целом такой вариант не рекомендуем использовать никому и никогда.

Поставить на сайт Google Tag Manager и передавать данные в dataLayer

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

Ни в коем случае не рекомендуем первым шагом изобретать или копировать у кого-то dataLayer, который будет сразу содержать все данные, которые вам приходят в голову. Часто в погоне за скоростью реализации разметки электронной торговли готовят большое универсальное задание разработчикам для передачи всех возможных данных в dataLayer в единой структуре, но с одинаковыми триггерами. У такой реализации есть несколько проблем. Во-первых, в погоне за универсальностью не учитываются требования бизнеса и особенности технической инфраструктуры хранения данных. Во-вторых, при использовании одинаковых триггеров отправки данных веб-аналитики теряют возможность простого изменения данных в Google Tag Manager, им приходится также оперировать универсальными данными и триггерами.

В любом из вариантов этого подхода наибольшая нагрузка ложится на команду разработки. Веб-аналитикам достаточно считывать и передавать данные примерно в том виде, в котором они есть. Но уже появляется возможность чуть более гибко обращаться с данными, чем в случае разметки без использования Google Tag Manager.

Какие проблемы могут возникнуть в этом варианте реализации? Любая ошибка отправки данных с сайта приводит к тому, что на стороне Google Tag Manager данные сложно изменить. Например, часто возникает проблема с тем, что сервер Google Analytics принимает запросы не больше 8 кб. А при отправке данных по показам товаров в списках товаров запрос получается значительно больше. Веб-аналитикам непросто пересобрать данные в Google Tag Manager и отправить в Google Analytics. И корень этой проблемы в том, что структура отправляемых данных не предполагает этого.

Плюсы этого варианта:

одни и те же данные можно передавать в разные системы;
требования к квалификации веб-аналитика минимальны.

Минусы этого варианта:

любая ошибка в данных приводит к проблемам с отправкой данных;
в погоне за универсальностью данных в dataLayer можно потерять в гибкости управления данными.

Поставить на сайт Google Tag Manager и передавать данные в js-объект

По нашему опыту, это наиболее удобный и гибкий вариант. Заключается он в том, что разработчики реализуют передачу всех необходимых данных в некий js-объект со структурой, аналогичной структуре обычного dataLayer электронной торговли. При каждом действии пользователя на фронте, которое связано с действиями электронной торговли, изменяются данные в js-объекте и отправляется пуш в dataLayer, в котором обозначено, какое изменение произошло (например, добавлен товар в корзину).

Такая реализация дает веб-аналитикам набор триггеров для каждого важного действия пользователя и возможность в зависимости от триггера собирать из js-объекта данные для электронной торговли Google Analytics, создав отдельный HTML-тег или переменную в Google Tag Manager.

Можно пойти еще дальше и развить эту логику. Создать стандарт структуры js-объекта с данными, свой вариант менеджера тегов и запустить стартап. Главное — следовать требованиям бизнеса к собираемым данным, а детали реализации могут варьироваться.

Плюсы этого варианта:

возможность гибкого управления передаваемыми данными за счет отдельных триггеров и полного наполнения js-объекта;
js-объект может пол

ностью генерироваться бэкендом, без нагрузки на фронт.

Минусы этого варианта:

требования к квалификации веб-аналитиков выше, чем во всех предыдущих вариантах реализации;
передача всех данных завязана на триггеры и наполнение js-объекта.

Поставить на сайт Google Tag Manager и собирать данные js-тегами с фронта

При соответствующей квалификации веб-аналитиков или подключении фронтендера в команду веб-аналитиков, можно собирать все необходимые данные HTML-тегами и переменными Google Tag Manager.

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

Еще одним ограничением в использовании такого подхода может быть сам код сайта. Наибольшие сложности могут быть с проектами, которые используют фреймворки типа Angular или React. В таком случае многие изменения кода сайта будут затрагивать код HTML-тегов Google Tag Manager и приводить к тому, что данные не будут собираться должным образом. Победить это сложно, но можно. Например, дополнив критичные для разметки элементы верстки отдельными идентификаторами, которые не будут меняться и при любом релизе проверяться автотестами.

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

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

По опыту, веб-аналитики часто забывают добавлять необходимые проверки значений переменных или конструкции типа try...catch в код своих скриптов. Поэтому, после реализации разметки таким образом, стоит дополнительно проверить корректность всех скриптов.

Плюсы этого варианта:

наиболее быстрый и гибкий вариант реализации разметки.

Минусы этого варианта:

высокие требования к квалификации веб-аналитиков;
сильная зависимость качества разметки от верстки и ее изменений.

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

Четвертый этап: подготовка гайда для разработчиков

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

Что стоит описать в гайде:

1. Особенности сбора данных

Что передавать, если по определенному полю данных нет: 0, пустое поле или какое-то специальное значение;
Какие из полей должны быть строковыми, а какие — числовыми значениями;
Какие спецсимволы нельзя использовать;
И так далее.

2. Какие минимальные поля должны передаваться по ключевым сущностям сбора данных

По странице;
По товару;
По баннеру.

3. Когда и в каком виде должны передаваться данные по каждому действию электронной торговли Google Analytics.

4. Когда и в каком виде должны передаваться данные по остальным действиям пользователей на сайте.

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

Пятый этап: реализация разметки и последующее ревью

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

Проверка должна содержать два этапа: качественный и количественный. Качественный этап заключается в проверке передаваемых данных силами веб-аналитика, который на препроде проверяет в своем браузере, как передаются данные по типовым страницам и действиям пользователей. Задача этой проверки — отловить очевидные ошибки и выкатить на прод уже проверенный вариант. Следующий этап — количественная проверка. Это проверка корректности разметки по данным Google Analytics. Она позволяет отловить менее очевидные ошибки и баги разметки на большой выборке данных.

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

Заключение

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

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

Как построить процесс разметки электронной торговли так, чтобы получать все нужные данные