7 грубых ошибок при настройке электронной торговли

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

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

1. При обновлении страницы "спасибо за заказ" код транзакции должен отправлятья только один раз

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

Распознать такую ошибку  очень просто. Вы можете либо обновить страницу "Спасибо за заказ" и убедиться, что при обновлении страницы код не сработал повторно, либо заглянуть в Google Analytics. Если в Google Analytics увидите вот такую картину, значит, вы допустили самую распространенную ошибку при настройке передачи данных с сайта в систему аналитики:

На скриншоте видно, что пользователь в рамках одной транзакции несколько раз в течение длительного периода обновлял финальную страницу сайта или просто переходил на нее из закладок:

И в результате:

1) вместо одной транзакции в системе аналитики мы видим восемь;

2) показан доход в 8 раз выше реального.

2.В статистике не учитываются заказы, сделанные в один клик

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

Отслеживать заказ в один клик точно так же важно, как и покупки через корзину. Сейчас уже довольно большой процент заходит к вам мобильных устройств – с маленького экрана купить в один клик гораздо проще и быстрее. Так, по статистике одного нашего крупного клиента, магазина бытовой техники, – за три месяца 20% пользователей сделали покупки в один клик. Поэтому не пренебрегайте отслеживанием покупок данного типа – это поможет видеть вам более полную картину по продажам.

3. В статистике не отображаются заказы, оплаченные банковской картой

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

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

4. При наличии сторонней платежной системы все транзакции падают в реферальный трафик

Если не настроить список исключения источников перехода, то в Google Analytics все транзакции будут присваиваться одному источнику – сайту платежной системы. Это приведет к дальнейшим ошибкам в интерпретации данных:

1) вы не поймете отдачу от рекламных источников – будете знать, сколько вы потратили на тот или иной рекламный канал, но не будете знать, сколько денег и транзакций он на самом деле вам принес.

2) в реферал будут сыпаться все оплаченные покупки – от прямых переходов до рекламных: вы не сможете даже понять откуда приходит конверсионная аудитория. Вы будете видеть просто факт покупки, которая была оплачена столько-то раз и принесла вам такой-то доход.

5. При повторной транзакции данные о предыдущей покупке попадают в текущий заказ

Нельзя сказать, что ошибка распространенная, скорее наоборот. Но знать, что такое встречается, тоже полезно. Совсем недавно мы столкнулись с тем, что в Google Analytics начался сбой в последовательности идентификаторов транзакций. В норме у этого клиента идентификаторы должны идти по порядку (в интернет-магазине можно купить только через сайт, а сайт у компании только один). Ошибку искали долго и мучительно. Но когда нашли – были удивлены.

Суть заключалась в следующем. Когда залогиненный в интернет-магазине пользователь совершал первую покупку – код электронной торговли отрабатывал корректно, все данные передавались в Google Analytics без проблем. Но когда пользователь совершал под своим логином повторную покупку, данные о продукте, категории, стоимости суммировались с данными по предыдущему заказу, и это не так-то просто было заметить, глядя в Google Analytics. Мы радовались тому, что пользователи стали покупать большее количество товаров, что стал расти средний чек покупки и доход. А потом выяснилось, что, когда пользователь совершает три и более транзакций под одним логином, все данные о предыдущих покупках суммируются с текущей транзакцией. Поскольку отправка данных в Google Analytics у нас чаще всего происходит с помощью протокола передачи статистических данных Measurement Protocol, то сообщения ограничены лимитом текстовых значений. В Measurement Protocol действуют ограничения длины в байтах. Например, максимальная длина для поля составляет 2048 байтов. Если длина некоторых значений превышает допустимую, они будут автоматически укорочены. Если многобайтовый символ слишком длинный, он будет удален. Так же и происходило с нашими транзакциями.

Ошибка может привести к тому, что:

1) первичные покупки будут считаться корректно: код транзакции отрабатывает, данные о названиях, количестве купленных товаров и доходе передаются в GA;

2) но при повторных покупках начинаются сбои, что приодвит к кривому подсчету LTV и данных по продажам в целом. Как следствие, "поедут" все калькулируемые метрики и отслеживание выполнения KPI.

Чтобы ее избежать нужно при оформлении заказа заполнять массив dataLayer = [] данными о только что завершенной транзакции единожды для одного заказа.

6. При транзакции фигурирует разное название товаров (на разных языках), а идентификатор один и тот же

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

7. При автоматической подстановке гео-префикса затирается рекламная метка

Предположим, что у вас сайт www.test.ru с возможностью автоматического определения города. Это означает, что когда вы заходите на сайт, находясь в Санкт-Петербурге, при переходе на последующие страницы подставляется гео-префикс www.test/spb/catalog/. В этом случае рекламная метка не режется. Но если вы изначально ведете трафик уже с определенным гео-префиксом, а потом автоматическое определение города меняется или исчезает, есть вероятность, что в зависимости от технических настроек сайта будет биться сессия, вследствие чего – затирается рекламная метка. Все транзакции присвоятся прямым переходам. При наличии гео-префиксов– проверьте на тестовых заказах, всё ли в порядке со ссылками и метками в этом случае.

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

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

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

Еще о настройке Google Analytics: Google Analytics для ecommerce: с чего начать