Анализ сайта и поиск ошибок в настройке событий электронной торговли

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

Во время обучения на моем онлайн-курсе по Google Tag Manager у одного из слушателей возникла очень интересная задача, мимо которой я просто не мог пройти. Название проекта целенаправленно скрыто по причине соглашения о неразглашении (NDA). Формат повествования оставлен прежним, без изменений, так, как он был отправлен самому заказчику.

Исходные данные

Исходные данные были такие: на сайте, средняя посещаемость которого составляет 4 миллиона пользователей в месяц, сделали перенос настроек расширенной электронной торговли из Universal Analytics в Google Analytics 4, но:

• в GA4 есть заказы с корректными номерами заказов, но без выручки и в поле количество транзакций - 0. То есть такие транзакции не учитываются при подсчете конверсии и количества транзакций. В UA эти заказы передаются корректно.

• еще в Google Analytics 4 есть заказы с нулевыми параметрами и с (not set) вместо номера заказа.

Исследование

Поскольку у проекта в GA4 присутствуют потоки данных для мобильных приложений (iOS и Android), первым делом необходимо найти дату начала сбора данных по событиям электронной торговли в Google Analytics 4 именно для веб-потока, чтобы отфильтровать данные приложений и не учитывать их при дальнейшем анализе.

Открыв отчет Совершенные покупки и выбрав фильтр по веб-потоку (web), увидим, что доход от покупок начал фиксироваться с 29 января 2023 года:

Хотя сами события purchase, но без суммы покупки, для сайта начали регистрироваться уже с 25 января 2023 года. Это подтверждается отчетом по конкретному событию:

А также простой таблицей в Исследовании по названию события, количество совершенных событий и доходу от покупок:

С 25 по 28 января были зафиксированы события покупки, но дохода от них нет. А вернувшись в отчет по совершенным покупкам, заметим, что с 25 января 2023 года в GA4 так же начали поступать данные о просмотренных товарах:

Вероятно, с этой даты разработчики сайта начали настраивать дополнительные события электронной торговли, включая просмотры информации о товаре (view_item), показы товара или нескольких товаров в списке (view_item_list), показы внутренних промоакций на сайте (view_promotion) и т.д.

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

 

Именно 25 января 2023 г. – дата начала регистрации новых событий по ecommerce GA4, а 29 января начал фиксироваться доход от покупок:

Именно с этой даты +1 (30 января) день можно начать сравнивать статистику по заказам, идентификаторам транзакций и пытаться найти причину такого расхождения данных. +1 день потому, что 29 января разработчики еще могли настраивать электронную торговлю в течение дня, и часть статистики просто не успело попасть в отчет.

Сразу же хотелось отметить, что в стандартном отчете по совершенным покупкам после начала сбора событий электронной торговли появилась надпись Некоторые данные объединены, а в самой таблице появилась новая строка (other) / (прочие):

В официальной документации Google об этом написано достаточно много и исчерпывающе. В частности, Google Analytics устанавливает ограничения на объем данных в базовой таблице базы данных, используемой для стандартного отчета. Если вы собираете данные, число уникальных значений которых превышает максимальное количество строк для таблицы, Google Analytics сгруппирует менее часто встречающиеся значения и пометит их как (другие). Одна из самых простых и частых рекомендаций – просматривать статистику в Исследованиях.

За 30 января статистика в обоих счетчиках выглядит следующим образом:

Universal Analytics - 684 транзакции и 1 464 588 руб. дохода

Google Analytics 4 - 739 транзакций и 1 638 782 руб. дохода

Теперь проверим данные по идентификаторам транзакций за выбранный день:

Universal Analytics – часть таблицы с заказами:

Google Analytics 4 – часть таблицы с заказами:

Примечательно, но транзакция 760-346019347 с отличающимся от других заказов идентификатором и суммой покупки 87 000 руб. присутствует в отчете Google Analytics 4, но ее нет в списке транзакций в Universal Analytics. Это видно невооруженным глазом.

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

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

Задача №1

в GA4 есть заказы с корректными номерами заказов, но без выручки и в поле количество транзакций - 0. То есть такие транзакции не учитываются при подсчете конверсии и количества транзакций. В UA эти заказы передаются корректно

Построив Исследование с 13 по 17 февраля 2023 г. с заданными параметрами и показателями, получим схожую с заказчиком таблицу:

Попробуем найти дополнительную информацию по заказам, у которых нет дохода и транзакций (по нулям). Будем идти поочередно и сравнивать эту статистику с данными из Universal Analytics, поскольку заказчик утверждает, в UA заказы передаются корректно и считаются правильно.

Начнем. Идентификатор транзакции 003-351371284 от 13 февраля 2023 г. (13 часов). Попробуем найти этот же заказ в Universal Analytics. Для этого пока не будем ограничиваться никаким диапазонами дат. Нам нужно просто найти этот идентификатор в GA3. Для этого можно построить специальный отчет с соответствующим параметром и показателями.

Как видим, данный заказ присутствует в Universal Analytics, имеет 1 транзакцию и доход 417 рублей, совершен 13 февраля в 13 часов. Все правильно:

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

Мы нашли пользователя с уникальным идентификатором 1927582703.1672125371. Теперь мы можем найти его профиль в отчете Статистика пользователей (GA3):

Как видим, данный пользователь в течение дня совершил несколько покупок на разные суммы. А если быть точнее – 4 заказа:

• 003-351316812 - в 12 часов
• 003-351371284 - в 13 часов
• 003-351415481 - в 16 часов
• 003-351518183 - в 21 час

Теперь у нас есть уникальный идентификатор пользователя и еще несколько идентификаторов заказов, которые можно сопоставить с данными в Google Analytics 4. Вернувшись туда, произведем поиск по исследованию Статистика пользователя. Мы должны найти профиль этого человека и посмотреть, какую информацию записал GA4 за 13 февраля.

Выполнив поиск, я нашел этого пользователя по Client ID:

Открыв его, мы можем увидеть все его события, зарегистрированные в GA4, включая покупки:

Проанализировав всю историю, я убедился, что данный пользователь действительно совершил 4 покупки 13 февраля и для него было зарегистрировано 4 события purchase в 12 часов, в 13 часов, в 16 часов и в 21 час. То есть количество заказов конкретно для этого пользователя одинаково для Universal Analytics и Google Analytics 4.

Далее я попробовал найти все идентификаторы транзакций и сопоставить их с событиями пользователя. Получилось очень интересно. Идентификатор транзакции 003-351316812 не был найден ни за 13 февраля, ни за другие даты. Вероятно, такая транзакция в GA4 не попала.

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

Идентификатор транзакции 003-351415481 в статистике GA4 нашелся с событием purchase и тем же временем, что и в Universal Analytics. Вдобавок он был передан еще с событием view_promotion:

Идентификатор транзакции 003-351518183 тоже был найден вместе с событием purchase и view_promotion:

Построив Исследование от обратного, исключив события purchase и все not set в идентификаторах транзакций, я оставил только статистику по тем событиям, у которых были реальные ID заказа, но не у события purchase:

За 13-17 февраля 2023 года я получил список из 208 заказов с реальными идентификаторами, но с нулевым количеством транзакций и дохода. Все они относятся к событию view_promotion. Оно срабатывает когда осуществляется показ рекламной акции на сайте. Схожее событие в Universal Analytics - promoView.

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

Тогда я открыл в Исследовании другой диапазон дат (с 1 по 31 марта), чтобы посмотреть, действительно ли ошибка повторяется во времени и в другой период.

Да, некоторые из них продолжались и в марте месяце:

Причем идентификатор транзакции был не только у события view_promotion, но еще и у select_item и select_promotion.

Вывод:

• когда есть идентификатор транзакции -> должно быть событие purchase, транзакция и доход;
• когда нет идентификатора транзакции -> должно быть (not set), но передаваться другое название события и количество событий.

Нехарактерные транзакции отмечены цветом:

Потому что список со стандартными событиями покупки, как правило, выглядит так:

С целью упрощения дальнейшего поиска расхождений данных и нехарактерных транзакций я создал отчет в Looker Studio (Google Data Studio) и подключил к одному листу два источника – представление Universal Analytics и ресурс Google Analytics 4. Добавив к нему фильтр по идентификатору транзакции и таблицу с нужными параметрами и показателями, мы можем легко сравнивать оба счетчика и видеть расхождения в транзакциях и покупках:

А еще можно построить сводную таблицу по идентификатору заказа и названиям событий, чтобы быстро увидеть те события, у которых есть ID заказа, но нет транзакций и дохода:

И найдя такие идентификаторы, подставить их в поиск, чтобы убедиться, что в одном счетчике такая транзакция есть, а в другом нет. Например, по транзакции с идентификатором 003-352178430:

В Google Analytics 4 были зафиксированы события select_item и view_promotion, и не было purchase, а в Google Analytics 3 такое событие записалось вместе с доходом. Аналогично и по другим транзакциям.

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

• Google Analytics 4 – 32 372 472,42 руб. и 14 971 транзакция
• Universal Analytics - 32 669 567,2 руб. и 15 318 транзакций

Разница в статистике между двумя счетчика аналитики составляет менее 1% по доходу и менее 2,5% между транзакциями. Это очень хороший показатель для проекта с такой посещаемостью и объемом данных.

Проанализировав срез по страницам, на которых совершались события, оказалось, что большинство событий view_promotion и др., имеющих идентификаторы транзакций в Google Analytics 4, но без самой транзакции и дохода, регистрировались на страницах, содержащих URL /checkout/fastOrderConfirmation:

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

Я сообщил об этом заказчику, и он внес соответствующие правки на сайте. Вместе с этим были даны рекомендации и совершены некоторые изменения в настройках электронной торговли, поскольку она была произведена переносом существующих сущностей расширенной электронной торговли Universal Analytics в Google Analytics 4 с помощью Google Tag Manager и решения стороннего разработчика (пользовательские шаблоны).

Задача №2

В Google Analytics 4 есть заказы с нулевыми параметрами и с (not set) вместо номера заказа.

Это было как раз связано с тем, что (not set) добавляется там, где событие не равно purchase. То есть если построить Исследование, в которое добавить еще один параметр Название события, тогда будет видно почему в таблице такие данные:

Там, где название события равно purchase, там везде присутствует ID заказа:

Резюме

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

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

• анализ данных - творческий процесс, местами долгий, и свет в конце туннеля может так и не появиться. Это всегда поиск и предположения, исследования множеств путей и различные гипотезы, в основе которых лежат процессы логического мышления, и обязательно проверки или опровержения своих же наблюдений;
• глубокий технический анализ возможен только тогда, когда вы разбираетесь в инструментарии, с которым работаете;
• в любом анализе статистики, будь то это отчет в Google Analytics или таблица из базы данных, всегда должна присутствовать количественная (данные, представленные в числовом формате: метрики в отчетах, поиск проблем внутри счетчиков аналитики) и качественная информация (сбор, анализ и интерпретация данных путем наблюдения за тем, что люди делают и говорят);
• результат анализа - это всегда вывод, заключение, как у врача.

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