Как следить за качеством данных — подробное руководство

Материалы для скачивания

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

Хотите быть уверенными в качестве своих данных? Поручите это OWOX BI. Мы поможем вам разработать систему метрик и настроить веб-аналитику. С OWOX BI вам не нужно искать коннекторы, заниматься очисткой и обработкой данных. Вы получаете уже готовые наборы данных в максимально понятной и удобной для работы структуре. 

Содержание

бонус для читателей

Видео докладов с конференций: Analyze, GoAnalytics и Ecommerce

Скачать материал

Важность тестирования в веб-аналитике

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

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

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

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

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

Стоимость исправления ошибки

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

Стоимость исправления ошибки

Порядок внедрения сбора данных

Как правило, сбор данных состоит из пяти ключевых этапов:

  1. Вы формулируете бизнес-задачу. Допустим, необходимо оценить эффективность алгоритма подбора товаров в блок с рекомендациями.
  2. После этого аналитик или человек, отвечающий за сбор данных, проектирует систему метрик, отслеживание которых необходимо реализовать на сайте.
  3. Выполняет настройки Google Analytics и Google Tag Manager.
  4. Передает техническое задание на внедрение разработчикам.
  5. После внедрения метрик и настройки сбора данных вы работаете с отчетами.
Этапы сбора данных

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

Особенности тестирования сбора данных

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

  • Тестировать без инструментов невозможно. Как минимум вам придется работать с консолью для разработчиков в браузере.
  • Нет абстрактного ожидаемого результата. Нужно точно знать, что должно быть в итоге. У нас всегда есть определенный набор параметров, которые мы должны получить при каком-либо взаимодействии пользователя с сайтом. И мы знаем значения, которые должны принять эти параметры.
  • Нужны специальные знания. Как минимум это документация инструментов веб-аналитики, которые вы используете, практика, кейсы участников рынка.

Тестирование документации для сбора данных с сайта

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

Цели тестирования документации:

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

Наиболее распространенные ошибки в ТЗ:

  1. Опечатки. Разработчик может скопировать название параметров, не читая. Речь не про грамматические либо орфографические ошибки, а про неправильные названия параметров или значений, которые эти параметры передают.
  2. Пропущенные поля при отслеживании событий. Например, не учтено сообщение об ошибке в случае неуспешной отправки формы.
  3. Неправильное название полей и несоответствие схеме расширенной электронной торговли. Внедрение Enhanced Ecommerce с помощью переменной dataLayer требует четкого следования документации. Поэтому при составлении документа лучше проверить все поля дважды.
  4. Не предусмотрена валюта для мультивалютного сайта. Проблема, актуальная для всех отчетов, связанных с доходом.
  5. Не учтен размер хита, который должен соответствовать разрешенным лимитам. К примеру, на странице каталога может быть до 30 различных продуктов. И если мы будем передавать информацию о показах одновременно по всем продуктам, то с большой вероятностью хит в GA не отправится.

Тестирование настроек Google Analytics и Google Tag Manager

Следующий этап после проверки технической документации — это проверка настроек Google Analytics и Диспетчера тегов.

Зачем тестировать настройки GA и GTM:

  • Обеспечить корректную обработку параметров системами сбора данных. Настройка GA и GTM может выполняться параллельно с внедрением метрик на сайт. И до тех пор, пока работа аналитика не будет выполнена, данные в GA не появятся.
  • Облегчить тестирование внедредряемых на сайт метрик — нужно будет концентрироваться только на части работы разработчика. На финальной стадии причину ошибки в отправляемом параметре нужно будет искать непосредственно на сайте, не возвращаясь к пересмотру настроек платформы.
  • Низкая стоимость исправления — не нужно привлекать разработчиков.

Наиболее распространенные ошибки в Google Analytics:

  1. Не создана пользовательская переменная. Это особенно актуально для GA 360 аккаунтов, в которых может быть до 200 показателей и 200 параметров. В таком случае очень просто пропустить какой-нибудь из них.
  2. Указана неверная область доступа. Эту ошибку вы не сможете поймать на этапе проверки dataLayer либо пересматривая отправляемый хит, но при составлении отчетов вы увидите, что данные выглядят не так, как ожидается.
  3. Создание дубля уже существующего параметра. На отправляемые данные эта ошибка никак не влияет, но может создать проблемы при проверке и построении отчетов.

Наиболее распространенные ошибки в Google Tag Manager:

  1. Не добавлены параметры, к примеру, в тег Universal Analytics или в переменную GA Settings.
  2. Индекс в теге не соответствует параметру в GA. Это чревато тем, что значения будут передаваться не тем параметрам, которым нужно. К примеру, вы в GTM для параметра «рейтинг товара» указали индекс параметра «количество пользователей». Скорее всего при построении отчетов эта ошибка сразу будет найдена, но на собранные данные повлиять вы уже не сможете.
  3. Указано неправильное имя переменной в dataLayer. Создавая dataLayer, нужно обязательно указывать, по какому имени эта переменная будет найдена в массиве dataLayer. Если допустить опечатку или написать другое значение, то эта переменная никогда из dataLayer не прочтется.
  4. Не включено отслеживание расширенной электронной торговли.
  5. Неправильно настроен триггер запуска. К примеру, некорректно написано регулярное выражение, по которому будет запускаться триггер, или ошибка в названии события.

Тестирование внедрения Google Analytics

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

Зачем тестировать внедренные метрики:

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

Наиболее распространенные ошибки:

  1. Покрыты не все сценарии. К примеру, событие добавления товара в корзину может происходить на странице продукта, каталога, промо-странице или на главной. То есть в любом месте, где присутствует ссылка на товар. И при таком количестве входных точек можно что-нибудь упустить.
  2. Задание реализовано не на всех страницах. То есть для части страниц или какого-то раздела/каталога данные не собираются вообще либо собираются частично. Обычно, чтобы не допустить таких ситуаций, мы составляем чек-лист проверки. В некоторых случаях количество проверок одного функционала может достигать ста сценариев.
  3. Не все параметры внедрены, то есть dataLayer внедрен частично.
  4. Нарушена схема dataLayer для Enhanced Ecommerce. Особенно часто это касается таких событий: добавление товаров в корзину, переход между шагами чек-аута, клики по товарам и прочее. Одна из наиболее распространенных ошибок при внедрении Enhanced Ecommerce — это пропущенные квадратные скобки у массива Products.
  5. Для обнуления параметра в dataLayer используется пустая строка вместо null или undefined. В таком случае в отчеты GA попадают пустые строки. Если же использовать null или undefined, то этот параметр даже не попадет в отправляемый хит.

Инструменты для проверки данных

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

  • Расширение для Chrome — Google Analytics Debugger.
  • GTM Debugger, им можно воспользоваться включив режим предварительного просмотра в Google Tag Manager.
  • Команда dataLayer в консоли разработчика.
  • Вкладка Network в консоли разработчика.
  • Расширение для Chrome — Google Tag Assistant.

Рассмотрим подробнее некоторые из них.

Google Analytics Debugger

Для начала нужно установить расширение в браузер и включить. Затем открыть код страницы и перейти на вкладку Console. Информацию, которую вы там увидите — это уже результат работы расширения.

Здесь показаны параметры, которые передаются с хитами, и значения, передаваемые для этих параметров.

Google Analytics Debugger

Также тут есть блок расширенной электронной торговли. Его можно узнать по приставке «ec»:

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

Если вам нужно проверить состав dataLayer, то это проще всего сделать, набрав команду dataLayer в консоли:

Команда dataLayer в консоли разработчика

Здесь есть все параметры, которые передаются. Их можно подробно изучить и проверить. Каждое действие на сайте отражается в составе dataLayer. Вот сейчас у вас, допустим, семь объектов. Если кликнуть на пустом поле и снова вызвать команду dataLayer, в консоли должен появится восьмой объект.

Google Tag Manager Debugger

Откройте свой аккаунт GTM и нажмите кнопку «Предварительный просмотр»:

Предварительный просмотр в GTM

Затем откройте свой сайт и обновите страницу. В нижней области появилась панель, на которой видны все запущенные на странице теги.

Google Tag Manager Debugger

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

Тестирование мобильных браузеров и приложений

Особенности тестирования мобильных браузеров:

  • На смартфонах и планшетах сайты запускаются либо в адаптивном режиме, либо разработана отдельная мобильная версия сайта. Если запустить мобильную версию сайта на десктопе, она будет отличаться от себя же на телефоне.
  • Как правило, в мобильные браузеры невозможно устанавливать расширения.
  • Чтобы это компенсировать, нужно включить Debug режим в теге Universal Analytics либо в коде отслеживания GA на сайте.

Особенности тестирования мобильных приложений:

  • Работа с кодом приложения требует больше технических знаний.
  • Обязательно нужен локальный прокси-сервер для перехвата хитов. Чтобы не запутаться в том количестве запросов, которые отправляет девайс, можно фильтровать их либо по названию приложения, либо по хосту, на который они отправляются.
  • Все хиты собираются в формате Measurement Protocol и требуют дополнительной обработки. После того, как все хиты собраны и отфильтрованы, их нужно скопировать и разобрать на параметры. Для этого можно использовать любой удобный инструмент. Это может быть Hit Builder, формулы в Google Sheets либо приложение на JS или Python. Все зависит от того, что вам удобнее. Плюс тут вам понадобится знание параметров Measurement Protocol, чтобы выявить ошибки в отправляемом хите.

Как работать с мобильным браузером

  1. Подключите мобильное устройство к ноутбуку по USB.
  2. Откройте Google Chrome на устройстве.
  3. Затем в консоли разработчика откройте отчет «Remote Devices»:
Отчет «Remote Devices»
  1. Подтвердите подключение на устройстве, нажав кнопку «Ок» в диалоговом окне. Затем выберите вкладку, которую вы собираетесь проверять, и нажмите «Inspect».
  2. Теперь вы можете работать с консолью разработчика в стандартном режиме, как в браузере. У вас откроются все привычные вкладки: Console, Network и другие.

Как работать с мобильным приложением

  1. Для того, чтобы работать с мобильным приложением, нужно установить и запустить прокси-сервер. Мы рекомендуем Charles-proxy.
  2. Дальше нужно проверить, по какому IP-адресу подключается приложение:
  1. Затем нужно взять свой девайс и настроить подключение wifi через прокси-сервер, используя порт 8888. Это порт, который Charles-proxy использует по умолчанию:
Подключение wifi через прокси-сервер
  1. После этого собираем хиты. Обратите внимание, что в приложениях хиты отправляются не на collect, а на batch. Это пакетированный запрос, который помогает отправлять запросы по несколько штук. Во-первых, это экономит ресурсы приложения. Во-вторых, если есть проблемы с сетью, то запросы будут храниться в приложении и потом одним общим пулом отправятся, как только появится сеть.
  1. И наконец собранные данные нужно распарсить (разобрать) на параметры, проверить все ли в порядке, сверить их с техническим заданием.
Таблица с параметрами

Проверка данных в отчетах Google Analytics

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

Также отчеты GA позволяют проверить полноту передачи данных в dataLayer. То есть как в зависимости каждого из сценариев наполняется переменная, есть ли в ней все параметры, правильные ли значения принимают эти параметры и т. д.

Самые полезные отчеты

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

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

Отчет «Эффективность товаров»

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

Отчет «Эффективность товаров»

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

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

Отчет «Лучшие события»

Здесь в первую очередь необходимо пройтись по всем параметрам, которые передаются в GA, и посмотреть, какие значения принимает каждый из параметров. Обычно визуально сразу понятно, все ли в порядке или нет. Более детальный анализ по каждому из событий можно провести в кастомных отчетах.

Отчет «Лучшие события»

Отчет «Анализ расходов»

Еще один стандартный отчет, которые может быть полезен для проверки импорта данных о расходах в GA — это «Анализ расходов».

Часто мы наблюдали ситуацию, когда есть расходы по какому-то источнику или рекламной кампании, но отсутствуют сессии. Причиной могут быть проблемы или ошибки в UTM-метках. Либо же фильтры в GA могут исключать сессии по конкретному источнику и т. д. Эти отчеты время от времени нужно проверять.

Пользовательские отчеты

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

Пользовательский отчет

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

Проверка дублирования транзакций

Если вы найдете у себя подобную проблему, ознакомьтесь с подробной инструкцией, как ее исправить.

Узнайте больше, на что обращать внимание при настройке веб-аналитики и с помощью каких отчетов проверить качество данных, в статье «Как провести аудит аналитики сайта».

Автоматические оповещения на email

В Google Analytics есть очень хороший инструмент «Специальные оповещения», который позволяет отслеживать важные изменения, без просмотра отчетов. К примеру, если у вас перестанет собираться информация о сессиях в GA, вы получите соответствующее уведомление на email.

Оповещения в GA

Мы рекомендуем настроить уведомления хотя бы по этим четырем метрикам:

  • Количество сессий.
  • Показатель отказов.
  • Доход.
  • Количество транзакций.

Как настроить уведомления, читайте в статье «Автоматизация отчетов в Google Analytics».

Автоматизация тестирования

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

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

Зачем автоматизировать тестирование

Для автоматизации тестирования мы создали облачное решение, которое позволяет:

  • Проверять соответствие переменной параметров dataLayer на сайте эталонному значению.
  • Проверять наличие и работу кода GTM.
  • Проверять факт отправки данных в GA и OWOX BI.
  • Собирать отчеты об ошибках в Google BigQuery.

Преимущества автоматизации тестирования:

  • Существенное увеличение скорости тестирования. По нашему опыту, протестировать тысячи страниц можно за несколько часов.
  • Высокая точность результатов, поскольку исключается человеческий фактор.
  • Снижение стоимости тестирования — нужно привлекать гораздо меньше специалистов.
  • Увеличение частоты проведения тестов. Можно запускать тесты после каждого выливания на сайт.

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

Алгорит автоматического тестирования

На входе в наше приложение необходимо указать страницы, которые вы хотите проверить. Сделать это можно, просто загрузив CSV-файл или указав ссылку на Sitemap, или просто указать URL сайта (приложение найдет Sitemap самостоятельно).

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

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

Почитать подробнее о том, как настраивается и работает автоматическое тестирование метрик на сайте, вы можете в нашем кейсе с компанией OZON. ru.

P. S. Если вам нужен полный аудит сайта, вы можете заказать консалтинг от OWOX BI. Запишитесь на демо — и мы обсудим возможные варианты сотрудничества.

Записаться на демо