4 основных метода сшивания сессий в Google Analytics

Одним щелчком мыши пользователь может уничтожить данные Google Analytics: переход со страницы AMP на основной сайт или с основного сайта на обработчик платежей может превратить одно посещение в несколько сеансов, путаясь на исходных данных.

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

Подпишись на наш Телеграм и читай все статьи и новости первым

Сеанс сшивки устраняет технические неисправности, сохраняя чистые аналитические данные и спасая атрибутивную информацию. Этот пост охватывает четыре распространенных варианта использования:

1. Отслеживание идентификатора пользователя
2. Отслеживание AMP
3. Отслеживание субдомена
4. Междоменное отслеживание

Что такое сшивание?

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

Любая попытка сшить сессии зависит от двух элементов:

• Объект отслеживания, который отслеживает тот же идентификатор свойства Google Analytics (UA-XXXXXX-Y)
• Cookie с тем же идентификатором клиента

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

Термин «сшивание сессий» используется цифровыми маркетологами чаще, чем Google, который совсем недавно предпочел два других термина:

1. Сеанс объединения. «Объединение сеансов позволяет попаданиям, собранным до назначения идентификатора пользователя, связываться с идентификатором».
2. Ссылка на сайт. «Междоменное отслеживание позволяет Google Analytics видеть это как один сеанс одним пользователем. Это иногда называется ссылкой на сайт».

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

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

Кого больше всего заботит сшивание?

Сшивание сессий полезно для каждого сайта, но важно для нескольких:

• Сайты с логинами. Сайты с логинами полагаются на «объединение сеансов» для сбора данных о событиях, которые ведут к входу пользователя в систему.
• AMP-сайты тяжелые. Надлежащее отслеживание сохраняет данные атрибуции, когда пользователи переходят со страницы AMP на локально размещенную страницу без AMP.
• Крупные многодоменные организации. Для нескольких доменов требуется отслеживание между доменами, чтобы сохранить информацию об атрибуции при миграции пользователей между доменами (или поддоменами).
• Сайты со сторонними платежными системами. Без сшивания сессий сайты, использующие сторонние платежные системы, могут потерять данные атрибуции для конверсий электронной торговли.
• Сайты, которые используют социальные логины. Как и сторонние платежные системы, социальные логины могут неправильно реклассифицировать пользователей после входа в систему как рефералов из социальной сети.

Сайты с формой iframe. Iframes встраивают проблему междоменного отслеживания на страницу вашего сайта.

1. Отслеживание идентификатора пользователя

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

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

Таким образом, вместо захвата только части второго сеанса (первое изображение), объединение сеансов объединяет обращения до входа в систему (белые) с попаданиями после входа в систему (синие):

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

Google Analytics применяет объединение сеансов во время ежедневной обработки аналитики – «в 5 часов утра каждый день на основе самого западного часового пояса, выбранного в любом представлении отчетов, связанном со свойством».

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

По умолчанию объединение сеансов переключается на при настройке ID пользователя отслеживания. 

Вы можете отключить объединение сеансов в Admin> Property> Tracking Info> User-ID:

Хотя отслеживание идентификаторов пользователей наиболее актуально для сайтов с ожидаемым входом в систему (например, SaaS, электронная торговля), существуют и другие способы стимулирования входа в систему. Например, такие сайты, как Quora и Glassdoor, скрывают ценный контент за стенами входа.

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

2. Отслеживание AMP

В результате внедрения Google AMP возникли проблемы с отслеживанием: клики AMP в результатах поиска приводят пользователей к версии «AMP on cache», которая размещена в CDN Google.

В конечном счете, пользователи могут получить доступ к страницам AMP одним из трех способов ; каждое воздействие, где хранится идентификатор клиента:

1. Поиск Гугл. Доступ к странице AMP осуществляется через результат поиска Google и отображается в «средстве просмотра AMP». Идентификатор клиента хранится на google.com.
2. Proxy / Cache. Доступ к странице AMP осуществляется через прокси / кэш. Идентификатор клиента хранится на cdn.ampproject.org.
3. Прямой AMP. Доступ к странице AMP осуществляется непосредственно в домене издателя. Идентификатор клиента хранится в домене издателя.

В первых двух случаях переход на другую страницу на сайте издателя со страницы AMP создает ссылку и новый сеанс, а не подсчет щелчка как второго взаимодействия в одном сеансе.

Каменный Храм детализирует доставку информации от поискового AMP, щелкающего к странице без AMP

Оставленные неуправляемыми, полученные аналитические данные страдают от нескольких проблем:

• Завышенное количество сеансов
• Высокий показатель отказов на страницах AMP
• Низкие страницы за сеанс / длительность сеанса для страниц AMP

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

Как использовать API Google AMP для передачи того же идентификатора клиента

Настройка отслеживания AMP состоит из двух этапов: изменения кода Google Analytics и исключения рефералов.

Передача идентификатора клиента со страницы AMP в домен издателя сохраняет исходные данные и объединяет действия пользователя в один сеанс

1. Аналитика кода меняется.

Надлежащее отслеживание AMP начинается с небольших дополнений к коду Google Analytics на страницах AMP и не-AMP. Google предоставляет подробную информацию о том, как вносить изменения в analytics.js, gtag.js и Google Tag Manager.

Поскольку некоторые браузеры отказываются от сторонних файлов cookie, в сентябре 2018 года Google анонсировала Linker AMP, который украшает URL-адреса информацией об идентификаторе клиента, минуя ограничение на основе файлов cookie. AMP Linker не требует дополнительной настройки, если вы уже включили API идентификатора клиента Google AMP.

2. Реферальные исключения.

Кроме того, вам нужно добавить ampproject.org в качестве исключения для рефералов. Если вы используете контент AMP из нескольких поддоменов, Google рекомендует добавить исключение для рефералов для каждого из них.

После первоначальной установки изменения повлияют на ближайшие данные Google Analytics:

• Общее количество пользователей и сеансов уменьшится. Соединение сеансов AMP и не-AMP объединит неправильно разделенных пользователей и сеансы.
• Связанные метрики станут более точными. Например, показатель отказов на страницах AMP снизится.
• Новые пользователи будут расти. API Google AMP выполняет однократный сброс идентификатора клиента для посетителей AMP. Как отмечает Google: «В зависимости от частоты, с которой пользователи посещают ваш сайт (сайты), это может вызвать заметное временное колебание показателя новых пользователей и связанных отчетов».)

3. Отслеживание поддоменов

Отслеживание поддоменов стало значительно проще и зависит от настроек для домена cookie. Ранее это был ручной шаг, при котором для домена cookie (cookieDomain) было установлено значение «auto», теперь это параметр по умолчанию в скриптах Google Analytics и в переменной Google Analytics Settings в диспетчере тегов Google.

Поскольку алгоритм устанавливает cookie на максимально возможный уровень (корневой домен), пользователь, который попадает на поддомен, а затем мигрирует в основной домен, не будет генерировать новый идентификатор клиента или инициировать новый сеанс.

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

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

4. Междоменное отслеживание

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

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

1. Аналитика будет дублировать сеансы между доменами (поскольку идентификатор клиента не будет передаваться из одного в другой).
2. Исходная информация об атрибуции будет потеряна, преобразована в реферал из другого домена, который, поскольку он использует тот же код отслеживания, будет отображаться как реферал.

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

Межфирменное отслеживание внутри компании

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

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

• Автоматическая ссылка Домены. Добавьте все домены в виде списка через запятую в переменной настроек Google Analytics в Google Tag Manager или измените код Google Analytics, чтобы включить эти домены.

• AllowLinker. Чтобы домены могли получать идентификаторы клиентов, переданные по ссылкам, добавьте поле в переменной настроек Google Analytics в Менеджере тегов Google с именем allowLinker и установите значение «true». (Если поток пользователя является однонаправленным, вам необходимо разрешить компоновщик только для целевых, а не исходных доменов.)

Компоновщик добавляет метку времени и другие метаданные для проверки идентификатора клиента, что снижает вероятность того, что общая ссылка с идентификатором клиента влияет на данные Google Analytics.

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

Для эффективного анализа данных, собранных в результате междоменного отслеживания, добавьте имя хоста к URL-пути. В противном случае пути, совместно используемые несколькими доменами, будут сгруппированы вместе. Оба URL-адреса ниже будут отображаться только как / about-us / в отчетах на уровне страницы:

https://example.com/about-us/

https://another-example.com/about-us/

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

(Если вы пытаетесь спасти исторические данные, которые не были должным образом отфильтрованы, вы можете использовать вторичное измерение с именем хоста для разграничения URL-адресов в представлении.)

Обработка платежей третьей стороной

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

Одним из решений является настройка исключения из рефералов для домена вашего обработчика платежей; однако, это усилие — ручное — может стать непростой задачей, если:

• Вы работаете со многими платежными системами.
• Платежные системы часто меняют домены.
• Исключение домена производителя также может исключить «реальный» трафик рефералов (например, вы получаете посещения рефералов по ссылке в блоге PayPal).

Комплексный ответ? Исключите всех рефералов на странице квитанции

Ahava предлагает креативное, комплексное решение: создание исключения из рефералов для всего трафика на вашу квитанцию ​​или страницу «Спасибо». Исключение рефералов сохраняет исходные данные источника и не позволяет Google Analytics создавать новый сеанс, когда пользователи возвращаются на ваш сайт из домена обработчика платежей.

Реализация решения Ahava состоит из двух этапов:

1. Создание пользовательской переменной JavaScript. Установите значение реферера «null» для URL вашей страницы благодарности.
2. Модификация тегов, которые появляются на странице благодарности. Для любого тега, который срабатывает на вашей странице благодарности, установите в поле «referrer» недавно созданную переменную.
3. Общий запрет на переходы на данную страницу может показаться рискованным, но страницы с благодарностью доступны (или должны быть доступны) только в пределах последовательности покупок – никто не отправляется в путь пользователя на странице с благодарностью — поэтому нет риска потерять ценную информацию источник данных.

Социальные логины

Социальные логины не могут полагаться на общий домен Исключение рефералов — в то время как логин Google может исходить от account.google.com (поддомен, который вы можете безопасно исключить), другие, например Facebook, заходят через facebook.com, и почти на каждом сайте есть не авторизованный реферальный трафик с Facebook.

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

Другое решение — очень похожее на стратегию Ahava для страниц с благодарностями — состоит в переопределении или игнорировании информации о реферерах для страницы после входа в систему, размещенной на вашем сайте. Установка значения реферера для вашего собственного домена или «ноль» гарантирует, что источник регистрируется как Direct, тем самым сохраняя один сеанс. Стратегия работает, только если страница пост-входа имеет уникальный URL-адрес.

Iframes

Частично iframe является проблемой для сшивания сессий, потому что контент iframe обычно загружается до того, как сработают теги Analytics. Это означает, что традиционные решения для отслеживания, такие как добавление идентификатора клиента в URL-адрес, требуют корректировки, как указано в Руководстве разработчика Google:

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

Больно, как может быть междоменное отслеживание в iframes — Ahava называет их «неотслеживаемыми маленькими дерьмовыми монстрами, которые существуют в пустоте между сайтами» — они (слишком) часто используются в веб-формах продавцами, которые больше внимания уделяют перемещению форм данные в CRM, чем отслеживание этих взаимодействий в Google Analytics.

Есть важное предупреждение: вы должны иметь возможность добавлять код в iframe. Если нет, процесс не будет работать.

Ahava разработала два решения для междоменного отслеживания iframe, последнее из которых использует customTask:

CustomTask API — это функция библиотеки Universal Analytics (также используется тегами Google Tag Manager). Это позволяет вам получать и устанавливать значения от и до (протокол измерений), когда он генерируется.

Для междоменного отслеживания iframe «customTask использует скрипт setInterval (), который периодически опрашивает страницу, пока не будет найден целевой iframe или не истечет время ожидания».

Параметры для объекта iframeDecorator в решении Ahava

Когда Google Analytics регистрирует попадание на родительскую страницу, решение Ahava предлагает customTask найти iframe, который соответствует предварительно установленному селектору CSS, а затем украсить URL iframe идентификатором клиента первоначального попадания.

Однако даже это решение является хрупким, особенно если в iframe включены перенаправления.

Заключение

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

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

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