Работа с Google Analytics часто связана с тестированием Google Analytics. Если Вы тестируете слишком часто и много, меняете настройки, добавляете/удаляете фильтры не протестировав их предварительно — все идет под откос, и отчеты, которые в противном случае выглядят чистыми и правильными, превращаются в бардак.
В программировании всегда существует стадия разработки. На этой стадии может случится все, что угодно (и как правило, случается). Вы делаете свои грязные дела, облажаетесь, переделываете все снова, и, когда наконец все выглядит чисто и круто, презентуете свое творение общественности.
Хотя тестирование в Analytics не такое уж и заумное, оно выполняет свое дело и позволяет убедиться в том, что отчеты и данные, на которые смотрят люди в вашей компании, не выглядят дерьмом.
Если Вы занимались веб-аналитикой некоторое время, Вы, вероятно, попадали в ситуацию, когда необходимо исключить некоторых рефералов и предотвратить их появление в таких отчетах, как «Основные пути конверсий» («Top Conversion Paths»), и «Кампании». Cамый распространенный пример — исключение из рефералов платежных систем.
Предположим, ваш сайт использует платежную систему PayPal для обработки платежей пользователей. После осуществления платежа и возвращения пользователя на сайт, все принесенные им деньги будут присвоены каналу PayPal, а ваш отчет «Основные пути конверсий» будет выглядеть примерно так:
Это, конечно же, неверно.
Короче говоря, на примере исключения определенных рефералов в аккаунте Google Analytics, я продемонстрирую, каким образом я тестирую изменения настроек данного сервиса.
Копируем основное представление
Первое, что нам необходимо сделать — это скопировать наше основное, «рабочее» представление со всеми его целями, фильтрами и настройками. Таким образом, мы получим что-то вроде тестовой площадки для наших изменений.
Мы сможем убедиться, что данные и отчеты, на которые все смотрят, не превратятся в мусор.
К тому же, если на вашем сайте людно, не так уж и просто отследить тестовые обращения в отчете «В режиме реального времени» — мы просто не найдем наши тестовые запросы во всей этой суматохе.
Добавляем парочку новых фильтров для тестов
Теперь, когда у нас есть точная копия нашего основного представления, нам необходимо немножко «подкрутить» ее для целей тестирования. Самый простой способ — создать фильтр, который принимает обращения только с нашего IP-адреса, и блокирует все остальные. Таким образом, мы будем понимать, что все, что отображается в отчетах (включая отчет «В режиме реального времени»), было сгенерировано нами. Это очень сильно поможет нам сосредоточится на дебаггинге путем отсечения всех «реальных» запросов.
Если ваше основное представление имело фильтр, который отсекал ваш офисный (или домашний) IP — вам необходимо его удалить с тестового представления.
Если вы работаете в большой компании, где рабочие места имеют один и тот же IP-адрес, данный фильтр не предотвратит попадания обращения ваших коллег. Если вам уж наверняка нужно убедиться, что ни один лишний запрос не пройдет, вы можете проявить смекалку и создать еще один фильтр. Например, в моем случае, я создаю фильтр, который принимает только те обращения, в которых фигурирует URI с параметром «filter-testing»
Теперь нам, соответственно, нужно убедиться, что все «просматриваемые» страницы (ассоциированные с параметром dl в платформе Measurement Protocol, имеют данный параметр).
yourwebsite.com/some-random-page.html превращается в yourwebsite.com/some-random-page.html?filter-testing
Подготавливаем «тестировочную среду»
Открываем отчет «В режиме реального времени» в новосозданном представлении. Будет просто прекрасно, если мы сможем иметь этот отчет на виду все время, когда мы будем отправлять обращения. Лично я предпочитаю открывать этот отчет в отдельном окне и перемещать его на другой монитор (у меня 2-хмониторное рабочее место, как и у многих из нас). Если этот отчет постоянно на виду — у нас будет возможность следить за отправленными обращениями в реальном времени.
Вот окно, которое я использую для отправки обращений через Measurement Protocol.
А вот окно отчета «В режиме реального времени»:
«Генерируем» обращения и применяем новые настройки
Теперь можно начинать отправлять обращения. Опять же таки, это лучше делать с помощью Measurement Protocol, как босс (если вам не знакома эта платформа — это печально).
Так как мне нужно сделать так, чтобы определенный реферал не ломал мои отчеты и не запускал новую сессию для посетителей сайта (это то, что он делает), я беру пример обращения, которое я имею в результате перехода с этого сайта на свой сайт.
Теперь, мне нужно отправить это обращения пару раз. Для этого я просто вставляю полученную ссылку в адресную строку браузера и несколько раз обновляю страницу (на всякий случай). Это нужно для того, чтобы убедится, что данная ссылка Measurement Protocol-а работает корректно.
Теперь настало время применить наши новые настройки. Я иду в «Список исключаемых источников перехода» и добавляю упомянутого реферера.
Теперь, если вы поменяете clientid в параметре урла Measurement Protocol-а (с целью запустить новую сессию)
cid=133064705.1470902689На любое другое значение (я заменил одну цифру)
cid=133064705.147902688Вы увидите, что реферальный трафик, который мы «генерировали» пару минут назад, теперь успешно конвертируется в «прямой» трафик с соответствующими метками ("(direct)/(none)"), что в данном случае означает: «наше исключение работает корректно».
Раз:
И два:
Если мне нужно протестировать пару-тройку новых фильтров, данный метод мне кажется самым эффективным для того, чтобы убедится в их корректности и больше никогда не возвращаться к ним снова.
Когда дело сделано, мы можем оставить данное представление для будущих нужд, или же просто его удалить.
Автор: Cockchafer
