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

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

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

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

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

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

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

Сбор данных обычно состоит из пяти основных этапов:

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

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

Прежде чем перейти к каждому шагу, давайте рассмотрим некоторые требования к тестированию данных:

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

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

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

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

Наиболее распространенные ошибки в спецификациях:

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

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

Зачем тестировать настройки Google Analytics и Диспетчера тегов Google?

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

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

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

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

1. Не было добавлено никаких параметров, таких как тег Universal Analytics или переменная настроек Google Analytics.
2. Индекс в теге не соответствует параметру в Google Analytics, что создает риск того, что значения будут переданы неправильным параметрам. Например, предположим, что вы указали индекс параметра количества пользователей в GTM для параметра рейтинга элемента. Эту ошибку, скорее всего, сразу обнаружат при построении отчетов, но вы уже не сможете повлиять на собранные данные.
3. В dataLayer указано неверное имя переменной. Когда вы создаете dataLayer, обязательно укажите, по какому имени переменная будет найдена в массиве dataLayer. Если вы введете или напишете другое значение, эта переменная никогда не будет прочитана из dataLayer.
4. Расширенное отслеживание электронной торговли не включено.
5. Триггер запуска настроен неправильно. Например, неправильно написано регулярное выражение для срабатывания X или в названии события есть ошибка.

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

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

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

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

1. Охвачены не все сценарии. Например, скажем, элемент можно добавить в корзину на странице продукта, каталога, промо или главной страницы — то есть в любом месте, где есть ссылка на элемент. С таким количеством точек входа можно что-то упустить.
2. Задача реализована не на всех страницах. То есть для некоторых страниц или какого-то раздела/каталога данные вообще не собираются или собираются только частично. Для предотвращения подобных ситуаций мы можем составить чек-лист. В некоторых случаях у нас может быть до 100 проверок для одной функции.
3. Не все параметры реализованы; то есть dataLayer реализован лишь частично.
4. Схема dataLayer для расширенной электронной торговли не работает. Это особенно верно для таких событий, как добавление товаров в корзину, переход между этапами оформления заказа и нажатие на товары. Одной из наиболее распространенных ошибок при внедрении расширенной электронной торговли является отсутствие квадратных скобок в массиве « Продукты ».
5. DataLayer использует пустую строку вместо null или undefined для обнуления параметра. В этом случае отчеты Google Analytics содержат пустые строки. Если вы используете null или undefined, эта опция даже не будет включена в отправляемое обращение.

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

• Расширение отладчика Google Analytics для Chrome
• Отладчик GTM, который можно использовать для включения режима предварительного просмотра в Диспетчере тегов Google.
• Команда dataLayer в консоли разработчика
• Вкладка «Сеть» в консоли разработчика
• Расширение Google Tag Assistant для Chrome

Давайте поближе познакомимся с этими инструментами.

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

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

Также есть расширенный блок электронной коммерции. Вы можете найти его в консоли как ec :

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

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

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

Чтобы получить доступ к отладчику Диспетчера тегов Google, откройте свою учетную запись Диспетчера тегов Google и нажмите кнопку Предварительный просмотр :

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

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

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

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

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

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

1. Подключите мобильное устройство к ноутбуку через USB.
2. Откройте Google Chrome на своем устройстве.
3. В консоли разработчика Chrome откройте отчет об удаленных устройствах:

1. Подтвердите подключение к вашему устройству, нажав Ok в диалоговом окне. Затем выберите вкладку, которую хотите проверить, и нажмите « Проверить ».
2. Теперь вы можете работать с консолью разработчика в стандартном режиме, как в браузере. У вас будут все привычные вкладки: Консоль, Сеть и другие.

1. Для работы с мобильным приложением необходимо установить и запустить прокси-сервер. Рекомендуем Чарльза.
2. Если у вас установлен прокси-сервер, проверьте, к какому IP-адресу подключается приложение:

3. Затем возьмите свое устройство и настройте соединение Wi-Fi через прокси-сервер, используя порт 8888. Это порт, который Чарльз использует по умолчанию.

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

5. Наконец, собранные данные должны быть разобраны (разобраны) на параметры, проверены по порядку и сверены со спецификациями.

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

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

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

• Отчеты об электронной торговле:
  • Производительность продукта
  • Эффективность списка продуктов
  • Внутреннее продвижение
• Поведение — События — Основные события
• Приобретение — Кампании — Анализ затрат
• Пользовательские отчеты — например, тот, который показывает повторяющиеся заказы.

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

Самая ценная вкладка в этом отчете — покупательское поведение. Он анализирует полноту сбора данных на каждом этапе расширенной электронной коммерции. То есть мы можем видеть, передает ли Google Analytics просмотры списка товаров, клики, просмотры сведений о товарах, добавление/удаление товаров в/из корзины и сами покупки.

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

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

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

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

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

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

Обратите внимание: если в отчете более одной транзакции, это означает, что информация об одном и том же заказе была отправлена ​​более одного раза.

Если вы обнаружите подобную проблему, прочтите подробную инструкцию по ее устранению.

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

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

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

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

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

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

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

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

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

Используемая нами упрощенная схема алгоритма:

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

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

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

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