Несмотря на наличие подробной документации от Google настройка расширенной электронной торговли в Google Analytics зачастую сопряжена с не документированными нюансами. В этой статье мы разберем сложности, с которыми наиболее часто сталкиваемся в агентстве, и предложим варианты решения проблем. Написанное ниже по большей части справедливо и для электронной коммерции Яндекс.Метрики.
Ситуация 1: разный уровень параметризации товара на разных шагах воронки
В интернет-магазине есть конфигурируемые товары, т. е. товары, которые детализируются в процессе заказа. Для простоты восприятия назовем общий товар словом «товар», а наиболее конкретную единицу — «товарное предложение».
Например, сначала пользователь видит в каталоге на сайте красные ботинки определенной модели — это товар. На странице товара пользователь может выбрать размер: 23, 24, 25, 26. Ботинки каждого размера — это разные товарные предложения. В этой ситуации id товара и id товарных предложений не могут совпадать (и их названия, вероятно, тоже различаются).
Мы знаем, что расширенная электронная торговля позволяет получать данные на нескольких этапах взаимодействия с товаром, в том числе уже на этапе просмотра товара в списке.
Проблема. Если у одного и того же товара будет меняться ID и/или наименование в процессе движения клиента по воронке, то Google Analytics сочтет их разными товарами. Например, мы смотрим в списке «красные ботинки_модель_1», кликаем на этот товар, смотрим его карточку, а вот в корзину добавляем «ботинки красные_модель_1_размер_23». Это значит, что по отчетам в Analytics часть товаров никогда не будут покупать, а будут только просматривать; другую часть не будут просматривать, а будут только добавлять в корзину и покупать.
Иными словами, характеристики товара должны оставаться неизменными на протяжении всего процесса прохождения покупателем воронки от просмотра товара до покупки.
Варианты решения
К сожалению, идеального решения этой проблемы не существует, и приходится искать компромисс или хотя бы меньшее из зол. Признаём, что данные в GA не отражают действительность на 100%, и мысленно делаем на это поправку.
Первый вариант
Наиболее простой, но наименее правильный способ — передавать данные только о товаре, отказавшись от передачи данных товарного предложения.
Плюс этого варианта — упрощает жизнь разработчиков. Других преимуществ у него нет, так что если второй вариант реализовать невозможно или очень сложно, то первый — лучше, чем ничего.
Зато у него есть минус: он не подойдет, если вы планируете использовать динамический ремаркетинг. Характеристики товаров в фиде и в электронной торговле должны совпадать, а это значит, что вам придется строить фиды, используя ID товара, а не товарного предложения. Google не рекомендует так делать: «Не задавайте один идентификатор для разных вариантов одного товара». Если не следовать этой рекомендации, Google может полностью отклонить фид, и объявления на основе фида станут недоступны для вашего интернет-магазина.
Второй вариант
На всех этапах, на которых неизвестно конкретное товарное предложение, а известен только товар (например, неизвестен размер обуви и предполагается несколько вариантов), передавать данные о действии с неким товаром по умолчанию.
Например, у нас есть красные ботинки 23, 24, 25, 26 размера, пусть по умолчанию будут ботинки 23 размера. Тогда при просмотре товара в списке, при клике на товар и при просмотре карточки товара передаем данные так, будто эти действия совершаются с ботинками 23 размера. Как только на карточке товара пользователь выбирает размер, отличный от размера по умолчанию, например, 24 размер, передаем информацию о просмотре карточки нового актуального размера.
Все последующие действия (добавление в корзину, чекаут, покупка) производятся с конкретным товаром. И так с каждым параметром, разумеется.
Плюсы второго варианта:
-
каждый физический экземпляр товара будет отдельно отражен в отчетах в Google Analytics;
-
нет проблем с динамическим ремаркетингом.
Минусы второго варианта
Понятно, что в этом случае у вас будет ряд товаров, которые, согласно отчетам Google Analytics, будут чаще всего отображаться в списке и по которым будут чаще всего кликать — это будут товары по умолчанию. При этом некоторые товары (опять же, согласно отчетам) не будут отображаться в списке, на них не будут кликать, и тем не менее их будут добавлять в корзину и покупать. Из этой ситуации можно выйти, применив следующую рекомендацию.
Для различающихся физически товаров одного типа делайте одно название, например, пусть название будет «Ботинки красные_модель_1», одинаковое для ботинок 23, 24, 25, 26 и т. д. размера. При этом пусть у них будут разные ID, а размер пусть будет отражен в поле variant если есть больше одной характеристики (например, размер и цвет), можно передавать их в пользовательских показателях на уровне товара.
Третий вариант
Передавать данные о действиях сразу со всеми товарными предложениями одного товара. По умолчанию мы не рекомендуем использовать этот вариант, однако в некоторых случаях его можно рассмотреть. Например, если на одной карточке товара есть сразу пять разных вариантов товара и они отображаются одновременно. Тогда будет логичным считать, что пользователь просматривает карточки сразу пяти товаров одновременно.
Ситуация 2: превышение максимального размера запроса Analytics
Максимальный размер запроса в Google Analytics — 8 КБ, и хотя это немало, очень часто при передаче данных о просмотре товаров в списке он превышается, и данные не попадают в Analytics.
Скриншот проблемы в Google Analytics Debugger:
Решение
Рекомендуем разбивать скрипт передачи данных о просмотре товара в списке на несколько скриптов, в каждом из которых не более восьми товаров. Это с хорошим запасом, в подавляющем большинстве случаев его должно хватать. Однако если вы передаете очень много пользовательских параметров, это количество придется еще снизить.
Ситуация 3: передача данных непосредственно перед редиректом
Данные о клике по товару не всегда успевают отправиться в Analytics, потому что между кликом по товару и загрузкой карточки товара проходит слишком мало времени.
По нашему опыту, между совершением отслеживаемого действия и передачей данных в аналитическую систему может проходить 200-1000 мс в зависимости от скорости работы сайта и скорости интернета пользователя. В каждом конкретном случае время может отличаться, поэтому рекомендуем проверять экспериментально.
Пользователь кликает по товару, после чего сразу должна происходить передача данных о клике, а затем должна начаться загрузка страницы карточки товара. Однако по умолчанию загрузка страницы, скорее всего, будет начинаться сразу после клика, выполнение JavaScript может быть приостановлено, и значительная часть данных о кликах не попадет в GA.
Решение
Используйте метод navigator.sendBeacon, описанный в справке Google. К сожалению, он поддерживается не всеми браузерами, но придется с этим смириться.
Альтернативным вариантом решения проблемы могла бы стать задержка на загрузку страницы карточки товара после клика, чтобы данные почти наверняка успели передаться. Однако мы не рекомендуем его использовать, потому что задержка может негативно повлиять на пользовательский опыт. На наш взгляд, в этом случае лучше потерять немного данных о кликах пользователей, чьи браузеры не поддерживают метод navigator.sendBeacon.
Аналогичная ситуация иногда возникает при передаче данных о транзакции, так как некоторые интернет-магазины моментально перенаправляют пользователя со страницы «Спасибо за заказ» (на которой осуществляется передача данных о транзакции) на страницу платежной системы для онлайн-оплаты. В этом случае рекомендуем рассмотреть вариант с добавлением задержки в несколько секунд перед редиректом. Чтобы снизить недоумение пользователя от задержки, можно добавить отсчет времени до редиректа.
Или сделать переход на страницу оплаты ручным — по кнопке «Оплатить».
Ситуация 4: невозможность передать данные о транзакции с сайта
Когда передавать данные — после оформления заказа или после оплаты?
Типичный случай: после оформления заказа пользователя перекидывает на страницу «Спасибо за заказ», а для оплаты необходимо совершить дополнительное действие. Чаще всего надо нажать кнопку «перейти к оплате», которая будет переадресовывать на платежный шлюз.
Обычно тут все легко: можно настраивать передачу данных об успешном заказе на странице «Спасибо за заказ», скрипт успеет прогрузиться.
Нетипичный случай: после чекаута пользователя сразу автоматически направляют на платежный шлюз для оплаты. У скрипта передачи данных о транзакции не будет времени, чтобы отработать (предположим, что задержки на редирект нет).
Казалось бы, в этом случае можно было бы передавать данные о транзакции после оплаты, т. е. когда пользователя перекинет с платежного шлюза обратно на сайт. Но, во-первых, пользователь может не дождаться редиректа обратно на сайт, во-вторых, такого редиректа может вовсе не быть. Так что это ненадежно.
Вариант решения
Используя Measurement Protocol, можно передавать данные о транзакции из CRM непосредственно в Analytics (по аналогии существует также передача данных об офлайн-действиях в Яндекс.Метрику). В большинстве случаев этот вариант будет нормально работать. Подробная инструкция по Measurement Protocol — в справке Google.
Дополнительные комментарии
При типичном случае вы также можете использовать Measurement Protocol, если хотите видеть в Analytics данные только по реальным заказам.
Компромиссный вариант — в типичном случае можно использовать передачу данных со страницы «Спасибо за заказ» и дополнительно досылать через Measurement Protocol событие, содержащее идентификатор транзакции и статус оплаты. Тогда вы сможете построить отчет, в котором будете видеть и все заказы, которые были просто оформлены пользователями, и все заказы, которые были успешно оплачены.
Ситуация 5: пропускаются шаги воронки электронной торговли
У сайтов интернет-магазинов бывает нетипичная структура, при которой не представлены явно некоторые шаги. Например, при нажатии кнопки «купить» не происходит добавления товара в корзину, пользователя сразу перекидывает на оформление покупки. Сюда же относится покупка в один клик: отсутствует добавление в корзину и полноценный чекаут.
Если ничего не предпринимать, мы увидим пропущенные шаги в воронке в отчетах по электронной торговле, и в данных будет сложнее ориентироваться.
Вариант решения
Вызывайте одновременно несколько скриптов подряд, чтобы заполнить пропущенные шаги. Например, при передаче данных о покупке в один клик после отправки формы «купить в 1 клик» вызывайте последовательно скрипты добавления в корзину, чекаута и покупки. Тогда в воронке продаж в Google Analytics будет меньше разрывов.
Дополнительный комментарий
Существует альтернативное мнение, что не стоит намеренно искажать данные в системах аналитики, подменяя «правильные» данные (с разрывами) «удобными» данными (без разрывов в воронке). Поскольку не существует однозначного ответа, а на тему можно было бы провести долгую дискуссию, можем только порекомендовать тестировать разные варианты. Например, вы можете создать два представления в Google Analytics, в одном отфильтровать события, служащие искусственным заполнением воронки продаж, а в другом представлении не делать такого фильтра. Через некоторое время можете посмотреть на свои данные и решить, какой вариант вам больше подходит.
Ситуация 6: дублирование транзакций
При переходе на страницу «Спасибо за заказ» происходит передача данных об успешной покупке, но на эту страницу пользователь может зайти несколько раз. Например, некоторые клиенты добавляют в закладки страницу «Спасибо за заказ», потом каждый раз начинают визит с нее, и каждый раз передаются данные о транзакции. Из-за этого в отчетах можно заметить дублирование данных о заказах.
Первый вариант решения
Сделать страницу «Спасибо за заказ» доступной только один раз для каждого конкретного заказа. То есть пользователь не сможет попасть на эту страницу более одного раза, даже если просто обновит страницу. Это значит, что и данные нельзя будет передать более одного раза.
Второй вариант
Сделать так, чтобы скрипт передачи данных о транзакции срабатывал только один раз, даже если на страницу можно зайти несколько раз. Аналог первого варианта, но с сохранением возможности повторно зайти на страницу «Спасибо за заказ».
Третий вариант
Сохранять ID транзакции в куки, а при передаче данных в GA о транзакции каждый раз проверять, не была ли транзакция с таким ID уже записана в куки. Если была, то не отправлять данные.
Плюс третьего варианта — реализуется полностью при помощи Google Tag Manager, т. е. участие разработчиков не обязательно (инструкция на английском языке).
И минус: если пользователь почистит куки, этот метод перестанет работать. Однако очистка куки — это достаточно редкий случай, поэтому если первый и второй варианты решения невозможно, долго или дорого сделать, третий вариант вполне подойдет.
Заключение
Разумеется, выше описаны далеко не все проблемы, с которыми вы можете столкнуться при настройке электронной торговли, но мы рискнем предположить, что эти наиболее распространены. Надеемся, что вам помогла эта статья. Если у вас остались вопросы или вы хотели бы, чтобы мы описали решения дополнительных проблем, пожалуйста, напишите об этом в комментариях.
