Искажение данных о пользователях при кроссдоменном отслеживании в Google Analytics

, и как уменьшить это искажение.

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

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

Негативные последствия использования нескольких доменов в одной системе маркетинга

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

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

Можно подумать, что решением первой проблемы будет установка одного кода G.Analytics на все наши домены. Но это будет заблуждением. Для отслеживания пользователей G.Analytics использует идентификатор, который сохраняется в cookie браузера во время первого посещения сайта. Называется этот идентификатор Client ID. Область действия cookie с целью безопасности ограничена областью одного домена (максимум, можно расширить до поддомена). Поэтому пользователь, посещая разные домены, будет получать не один и тот же Client ID, а для каждого домена свой. Следовательно, для аналитики это по-прежнему будут разные пользователи.

Междоменное (кроссдоменное) отслеживание

Но не всё так плохо и есть решение, которое предлагает сам G.Analytics. Это настройка механизма междоменного (кроссдоменного) отслеживания. Суть его работы такая. Мы устанавливаем на все наши домены один код G.Analytics и вносим в него ряд изменений (инструкцию можно прочитать в справке Google). Если на одном из наших доменов есть ссылка на другой домен, то при переходе по ней одновременно передаётся текущий Client ID пользователя, а сам переход рассматривается, как внутренний, как если бы это был переход с одной страницы сайта на другую его страницу. В результате — внутри аналитики пользователь остался тем же (т.к. G.Analytics запишет в cookie нового посещенного домена тот же Client ID, что и на сайте, с которого был переход). Вторым плюсом этого механизма будет то, что сессия при таком переходе не прерывается и источником трафика остаётся источник, который привёл посетителя на сайт-донор.

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

Что не решает междоменное отслеживание?

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

Рассмотрим, что у нас будет в аналитике, когда пользователь посетил разные наши домены независимо друг от друга (без перехода с одного на другой). На каждом из них G.Analytics присвоил одному и тому же пользователю разные Client ID. Поэтому по-прежнему в нашей аналитике — два пользователя вместо одного.

Что произойдет, когда такой пользователь сделает переход с одного домена на другой? Механизм междоменного отслеживания передаст Client ID домена-донора на домен-перехода и он перезапишет уже существовавший Client ID. В результате история взаимодействия нашего пользователя с доменом-перехода будет прервана. Теперь для этого домена наш пользователь — это новый пользователь.

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

Доработка междоменного отслеживания

Если мы сможем при первом посещении пользователем любого из наших доменов сразу передать Client ID во все другие наши домены, то это избавит нашу аналитику от описанных недостатков.

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

Значит нам надо сделать так, чтобы при посещением одного нашего сайта происходило одновременно посещение всех наших других сайтов. Реализуем это «виртуальное посещение» через теги <iframe>  с нулевыми размерами по высоте и ширине, в которые загрузим специально созданные пустые страницы со всех других наших доменов. А в ссылку на загрузку добавим данные о Client ID, взяв их из механизма междоменного отслеживания G.Analytics. Таким образом посещение любого нашего сайта будет приводить к «виртуальному» посещению всех других наших сайтов и установки для них единого Client ID для пользователя.

К сожалению, этот метод не будет работать в 100% случаев. Некоторые браузеры (например, Safari) запрещают установку cookie через <iframe>. Также пользователь может в настройках браузера запретить такой метод работы с cookie.  В моей практике —  описанный метод срабатывает в 74% случаев. Это достаточно высокий процент и значит мы заметно снижаем погрешность нашей веб-аналитики.

Настраиваем код G.Analytics так, чтобы не создать себе новых проблем

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

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

Второе. Если у нас есть отдельные представления, в которых мы изолированно собираем данные по отдельным доменам, то в них не должны добавляться данные о пользователях. Так как в действительности, этих пользователей не было на этих сайтах.

В качестве «сноски на полях» замечу, что подобная ситуация возникает у нас в аналитике и тогда, когда мы передаём в неё оффлайн-конверсии. Обычно, ограничиваются тем, что, передавая событие (или транзакцию), указывают параметр ni=1. Для G.Analytics это означает, что данный хит не должен создавать сеанс. В итоге, сеанс не создаётся, но пользователь всё равно попадает в отчетный период. Например, мы в один день передали 10 оффлайн-конверсий и в этот же день у нас на сайте было 10 посетителей. В отчёте за этот день у нас будет такие данные: 20 пользователей и 10 сеансов. Как этого избежать, опишу в отдельной статье.

Чтобы не допустить этих проблем делаем так. В настройках кода G.Analytics на страницах, которые мы создали для загрузки в <iframe> прописываем только строчку активации кода: ga(‘create’, ‘UA-ХХХХХХХХ-1’, ‘auto’, {‘allowLinker’: true}) и не отправляем никаких хитов. Код запишет в cookie Client ID, но не будет отправлять никаких данных в нашу аналитику. Таким образом мы решим нашу задачу и не исказим собираемые данные.

Альтернативный метод

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

Этот метод также использует iframe, но вместо раздачи Client ID с текущего домена во все остальные, он, наоборот, получает уже существующие Client ID в текущий с других доменов. Если точнее, то схема такая. Проверяем есть ли cookie с Client ID в домене, который открыт в браузере. Если нет, то загружаем в iframe-ы другие наши домены и получаем с них Client ID и устанавливаем для текущего домена. Если ни в одном из доменов их не было обнаружено, то устанавливаем в текущий домен cookie с Client ID стандартным методом G.Analytics.

Как быть если в других доменах были обнаружены разные cookie? Первый и самый простой вариант — ставим ту, что обнаружили первой. Другой вариант — разработать систему ранжирования по значимости и записывать ту, что имеет больший вес. Это может быть значимость домена, значимость канала, при заходе с которого был получен Client ID, значимость действий, которые совершил пользователь (например, был получен лид / контактная информация пользователя).

У этого метода несколько важных плюсов.

  • Первый метод не отрабатывает в 100% случаев из-за политики в отношении сторонних доменов. Этот метод не имеет таких ограничений.
  • Позволяет подключать новые домены без перезаписи новыми Client ID уже существующих. При первом методе — если у пользователя после подключения нового домена первый визит будет на новый домен, то он получит новый Client ID , который перезапишет уже существующий в старый доменах и история отслеживания этого пользователя начнётся с начала.
  • При объединении ранее раздельно отслеживаемых доменов нам, если мы захотим отслеживать взаимодействие одного пользователя с разными доменами, нужно будет «вести» пользователя под одним Client ID и «отказаться» от всех других, которые были закреплены за этим пользователем в разных доменах. Первый метод принудительно назначал для пользователя тот Client ID, который был у домена первого посещения после объединения. Новый метод сохраняет уже существующие Client ID, а если в домене его не было, то получит его из другого.
  • Позволяет гибко настраивать правила получения и замены Client ID под наши задачи. Например, для кого-то домена — принудительно перезаписывать существующий Client ID другим из более значимого для нашей аналитики домена. Также, если мы создавали собственные cookie, фиксирующие важные данные о пользовательском поведении, то мы можем по собственным правилам выбирать какой конкретный Client ID закрепить далее за пользователем в новом домене.

Но есть и минус у метода. Первый хит PageView будет уходить с чуть большей задержкой, чем при стандартных настройках. Эта задержка не критична, но число посетителей, которых G.Analytics не успел «посчитать» из-за их практически моментального ухода с сайта, может  увеличиться. В большинстве случаев это посетители, которым сам сайт не успел «отрисоваться» на экране, и они его уже покинули. Т.е. скорее всего, если у нас нет проблем со скоростью загрузки сайта на устройства наших посетителей, то это «случайные» клики. Эти клики есть в рекламных кабинетах, но к ним нет пары — сеанса. Такие расхождения есть всегда и мы о них можем получить информацию. В многих случаях это не техническая проблема, а проблема с трафиком, который генерируется на сайт.