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

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

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

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

1. Выберите несколько событий для проверки

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

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

• Просмотр страницы: одна загрузка страницы должна создавать одно событие просмотра.
• Отправка формы: успешно отправленная форма должна создавать одно событие и одну сохранённую запись.
• Покупка: у завершённого заказа должен быть идентификатор транзакции и зафиксированная сумма.

Учитывайте и ожидаемые условия. Если событие отправки формы должно срабатывать только после успешной проверки данных, неудачная попытка не должна засчитываться. Это важно, например, когда пользователь нажимает «Отправить», не заполнив обязательное поле: нажатие было, но отправки формы не произошло.

2. Проследите путь события от действия до отчёта

Чтобы понять, как проверить настройку отслеживания событий, проследите тестовое действие на каждом этапе: от слоя данных или кода отслеживания сайта до исходящего запроса, системы сбора аналитики и, наконец, отчёта. В инструментах разработчика браузера можно проверить, был ли отправлен запрос и какое название события или параметры он содержал. Если запроса нет, проблема, вероятно, связана с сайтом или браузером; если запрос есть, но события нет в отчёте, проверьте настройки обработки и формирования отчётов.

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

Название события должно быть последовательным на всех этапах. Сайт может отправлять событие form_success, а в отчёте может быть настроено отображение generate_lead. Оба названия могут быть уместны, но между ними должно быть настроено соответствие или правило формирования отчёта. Командам, которые поддерживают несколько ресурсов, инструмент мониторинга, например платформа веб-аналитики и мониторинга, поможет заметить изменения, но не заменит проверку самого события.

3. Проводите контролируемые тесты в чистой сессии браузера

По возможности используйте новый профиль браузера или приватное окно с отключёнными расширениями. Так меньше риск влияния сохранённых файлов cookie, предыдущих посещений и дополнений браузера. Записывайте точные действия и время: откройте целевую страницу в 10:04, посмотрите один товар, добавьте его в корзину и остановитесь. По временным отметкам проще сопоставить действия в браузере с запросами аналитики и записями на сервере.

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

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

4. Сравните аналитику с независимой записью

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

Если вы выясняете, почему данные веб-аналитики не совпадают с заказами, выберите фиксированный временной интервал и небольшое количество тестовых записей. Где возможно, сопоставляйте их по времени, номеру заказа или другому общему идентификатору. Не сравнивайте общие итоги за разные периоды: на количество могут влиять часовые пояса, задержки обработки, фильтры и правила хранения данных. Если в аналитике за время теста отображается 12 покупок и в системе заказов есть 12 завершённых заказов, это полезный признак точности, но всё равно проверьте совпадение идентификаторов отдельных транзакций.

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

5. Проверьте, нет ли дублирующихся или пропущенных событий

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

Прерванные сценарии помогают выявить другой тип ошибок. Начните оформление заказа, выйдите до оплаты и убедитесь, что событие завершённой покупки не появилось. Затем оформите тестовый заказ и проверьте, что событие сработало один раз и содержит правильный идентификатор транзакции. Если событие покупки срабатывает при нажатии «Оформить заказ», данные могут быть завышены, когда платёж не проходит или покупатель возвращается на страницу.

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

6. Проверьте влияние согласия, блокировок и переходов между доменами

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

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

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

7. Задокументируйте результаты и повторите проверку после изменений

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

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