Как фильтры в Google Analytics портят аналитику и что с этим делать

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

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

Задача аналитики — собрать все цепочки взаимодействий пользователей в единую картину, а в 2020 году всё больше компаний стремится к user-centric модели, когда все события собираются в один клиентский профиль. И в то же время использование фильтров для отдельных поддоменов и источников трафика только сильнее разбивают разрозненные события.

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

Где и зачем применяется данный подход

Чаще всего подобные советы можно встретить при настройке Google Analytics. Идея заключается в следующем:

1. На сайт установлен счетчик, который собирает абсолютно все события с сайта.

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

3. У сайта есть несколько подрядчиков по рекламе: SEO, рекламе в Яндекс.Директе и Google Ads, Яндекс.Маркету и соцсетям. Клиент хочет разделить данные для всех подрядчиков, чтобы отслеживать эффективность каждого из подрядчиков в отдельном представлении или оставить доступ подрядчикам только к их данным.

Напомню, как выглядит структура аккаунта в Google Analytics. Аккаунт может вмещать в себя несколько ресурсов. Чаще всего один ресурс — это один сайт. В то же время данные с сайта можно отобразить в разных представлениях с преднастроенными фильтрами.

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

Путь пользователя при разделении на регионы

Есть сайт site1.ru. Его основная версия отвечает за Московский регион. При выборе пользователем другого региона, сайт его переадресовывает на поддомены типа spb.site1.ru, kazan.site1.ru и т. д.

По представлениям данные распределены так:

А теперь давайте представим следующую ситуацию:

1. Пользователь пришел на сайт по ссылке site1.ru из поиска Яндекса.

2. Посмотрел товары, добавил их в корзину и перешел к оформлению заказа.

3. На этом этапе его попросили выбрать его регион (Самара), после чего его перекинуло на поддомен samara.site1.ru/checkout/.

4. Клиент оформил заказ и ушел с сайта.

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

Что здесь произошло? В основном представлении были собраны все данные — и это логично, так как никакие фильтры для него у нас не заданы. В представлении Санкт-Петербурга данных нет, потому что не было пересечения по поддомену — тоже всё логично.

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

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

1. Клиент зашел из поиска.

2. Он посмотрел товары и добавил их в корзину.

3. Перешел к оформлению заказа.

4. И пропал.

Можно начинать впадать в депрессию и думать «как же так, почему он не купил?», но на самом деле он купил. И мы увидим это в представлении регионов:

1. Клиент также пришел из поиска и сразу попал на страницу оформления заказа.

2. Оформил заказ и был таков.

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

Путь пользователя при разделении по трафику

В случае, когда в представлении настраивается фильтр по источнику и каналу, происходит следующее: если клиент пришел по источнику yandex / cpc, все его перемещения по сайту в рамках сессии будут фиксироваться в представлении yandex / cpc.

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

Давайте на примере рассмотрим, как работает данный фильтр. Дано:

1. Клиент переходит с рекламы в Яндекс.Директе, в объявлении проставлены метки.

2. Попадает на сайт.

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

Все эти действия будут отнесены к источнику трафика Яндекс.Директ.

1. Клиент вернулся через динамический ремаркетинг Facebook на сайт.

2. Перешел к оформлению заказа и отвлекся.

3. Через два часа вернулся к открытой вкладке и завершил оформление заказа.

Все эти действия согласно модели атрибуции «Последний непрямой» будут отнесены к источнику трафика facebook / cpc.

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

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

Как не попасть в такие ловушки

Правило 1: не стоит бежать и сразу применять на живом проекте всё, что вы прочитали в интернете, насколько бы авторитетным ни был этот ресурс.

Правило 2: имейте как минимум три вида представлений:

• со всеми данными;

• мастер-представление — с проверенными настройками и фильтрами, которыми вы доверяете;

• тестовое представление — именно на этом представлении необходимо сначала проверить логику решений, прежде чем применить ее в мастер-представлении.

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

На этом у меня всё, храните ваши данные в целости и сохранности.