Выберите тип материала
Фильтры
- Все категории
- Статьи
- Видео
- Подкасты
- CPA-сети
- Рекламные сети
- Сервисы
- Мероприятия
1638
CPA-статей
2 418
Отзывов
4 405
Пользователей
Gambling
Кейсы
Антидетект
Браузеры
обучение
арбитражу
Беттинг
партнерки
03 июня 2019
0
3 148 просмотров
Одним щелчком мыши пользователь может уничтожить данные Google Analytics: переход со страницы AMP на основной сайт или с основного сайта на обработчик платежей может превратить одно посещение в несколько сеансов, путаясь на исходных данных.
Важно отметить, что такие клики часто происходят в точках перехода с высокой ценностью — от анонимного посетителя к зарегистрированному пользователю или с момента до покупки.
Подпишись на наш Телеграм и читай все статьи и новости первым
Сеанс сшивки устраняет технические неисправности, сохраняя чистые аналитические данные и спасая атрибутивную информацию. Этот пост охватывает четыре распространенных варианта использования:
В Google Analytics сшивание сеансов связывает действия пользователей, которые происходят в одном сеансе, но из-за технических ограничений отслеживания неправильно генерируют несколько сеансов.
Любая попытка сшить сессии зависит от двух элементов:
Современные браузеры не позволяют сайтам из одного домена обмениваться файлами cookie с другим доменом. Преодоление этого ограничения имеет решающее значение для объединения сеансов, которые в противном случае разрываются.
Термин «сшивание сессий» используется цифровыми маркетологами чаще, чем Google, который совсем недавно предпочел два других термина:
В этой статье я буду использовать сшивание сессий — это всеобъемлющий термин, который включает в себя все попытки правильно сгруппировать действия пользователей, которые происходят в одном сеансе.
Задача, независимо от того, как вы ее называете, влияет на качество данных и атрибуцию почти для каждого сайта.
Сшивание сессий полезно для каждого сайта, но важно для нескольких:
Сайты с формой iframe. Iframes встраивают проблему междоменного отслеживания на страницу вашего сайта.
Для сайтов с функцией входа в систему отслеживание идентификаторов пользователей связывает несколько посещений с течением времени, что позволяет компании, например, видеть, какие функции SaaS находят отклик у клиентов.
Объединение сеансов объединяет действия до входа в систему с идентификатором пользователя после входа в систему, создавая один сеанс из двух. Таким образом, вы можете увидеть, какое поведение предшествует входу в систему, что особенно ценно, если этот вход представляет точку конверсии.
Таким образом, вместо захвата только части второго сеанса (первое изображение), объединение сеансов объединяет обращения до входа в систему (белые) с попаданиями после входа в систему (синие):
Важно отметить, что объединение сеансов связывает попадания только в том случае, если «эти совпадения происходят в том же сеансе, в котором определенное значение идентификатора назначается впервые». Другими словами, он включает данные из сеанса, который предшествует входу в систему, а не предыдущих сеансов.
Google Analytics применяет объединение сеансов во время ежедневной обработки аналитики - «в 5 часов утра каждый день на основе самого западного часового пояса, выбранного в любом представлении отчетов, связанном со свойством».
Эта временная задержка может привести к «более высоким прямым сессиям и прямому доходу в течение внутридневных дат, потому что: Информация о реферальной кампании отправляется во время первого обращения к сеансу, где пользователь еще не вошел в систему».
По умолчанию объединение сеансов переключается на при настройке ID пользователя отслеживания.
Вы можете отключить объединение сеансов в Admin> Property> Tracking Info> User-ID:
Хотя отслеживание идентификаторов пользователей наиболее актуально для сайтов с ожидаемым входом в систему (например, SaaS, электронная торговля), существуют и другие способы стимулирования входа в систему. Например, такие сайты, как Quora и Glassdoor, скрывают ценный контент за стенами входа.
Для этих типов входа в систему унификация сеансов предоставляет важные данные о наиболее привлекательном контенте — ответы или статьи, которые катализируют входы в систему и регистрации.
В результате внедрения Google AMP возникли проблемы с отслеживанием: клики AMP в результатах поиска приводят пользователей к версии «AMP on cache», которая размещена в CDN Google.
В конечном счете, пользователи могут получить доступ к страницам AMP одним из трех способов ; каждое воздействие, где хранится идентификатор клиента:
В первых двух случаях переход на другую страницу на сайте издателя со страницы AMP создает ссылку и новый сеанс, а не подсчет щелчка как второго взаимодействия в одном сеансе.
Каменный Храм детализирует доставку информации от поискового AMP, щелкающего к странице без AMP
Оставленные неуправляемыми, полученные аналитические данные страдают от нескольких проблем:
Как и в случае других проблем сшивания сеансов, решение заключается в передаче одного и того же идентификатора клиента между страницами в разных доменах, что Google делает возможным с помощью API идентификатора клиента AMP.
Настройка отслеживания AMP состоит из двух этапов: изменения кода Google Analytics и исключения рефералов.
Передача идентификатора клиента со страницы AMP в домен издателя сохраняет исходные данные и объединяет действия пользователя в один сеанс
Надлежащее отслеживание 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.
Кроме того, вам нужно добавить ampproject.org в качестве исключения для рефералов. Если вы используете контент AMP из нескольких поддоменов, Google рекомендует добавить исключение для рефералов для каждого из них.
После первоначальной установки изменения повлияют на ближайшие данные Google Analytics:
Отслеживание поддоменов стало значительно проще и зависит от настроек для домена cookie. Ранее это был ручной шаг, при котором для домена cookie (cookieDomain) было установлено значение «auto», теперь это параметр по умолчанию в скриптах Google Analytics и в переменной Google Analytics Settings в диспетчере тегов Google.
Поскольку алгоритм устанавливает cookie на максимально возможный уровень (корневой домен), пользователь, который попадает на поддомен, а затем мигрирует в основной домен, не будет генерировать новый идентификатор клиента или инициировать новый сеанс.
Вторым шагом является добавление корневого домена в список исключений рефералов, чтобы посещения между поддоменами и основным доменом не инициировали новые сеансы. (Первый шаг гарантирует, что Google видит посетителя как того же пользователя.) Google автоматически добавляет корневой домен в список исключений рефералов, когда вы создаете свойство Google Analytics, но настройка стоит двойной проверки.
Теоретически, эти обновления автоматизируют отслеживание субдоменов — по умолчанию списки Cookie-доменов и исключений для рефералов установлены на правильные значения.
Междоменное отслеживание является наиболее сложным процессом из всех сшиваемых сессий, поскольку многие решения выполняются на заказ: правильная реализация зависит от настройки вашего сайта, обработчика платежей, средства входа в систему.
Если несколько сайтов используют один и тот же код отслеживания, но другие технические изменения не выполняются:
Как и в случае с отслеживанием AMP, успешное отслеживание между доменами требует передачи идентификатора клиента с одного сайта на другой без передачи самого файла cookie. Есть несколько основных вариантов использования, каждый с уникальными решениями.
Крупные организации часто управляют несколькими доменами, но хотят отслеживать посетителей при переходе с одного на другой. Предполагая, что сайты используют один и тот же код Google Analytics, отслеживание пользователей в нескольких доменах имеет три дополнительных этапа.
Первые два шага изменяют код отслеживания, чтобы позволить доменам проходить и получать идентификаторы клиентов по ссылкам:
Компоновщик добавляет метку времени и другие метаданные для проверки идентификатора клиента, что снижает вероятность того, что общая ссылка с идентификатором клиента влияет на данные Google Analytics.
Последний шаг — добавить все домены в список исключений рефералов. В противном случае вы создадите горы саморефералов — Google Analytics правильно распознает одного пользователя между доменами, но все равно создаст новый сеанс.
Для эффективного анализа данных, собранных в результате междоменного отслеживания, добавьте имя хоста к URL-пути. В противном случае пути, совместно используемые несколькими доменами, будут сгруппированы вместе. Оба URL-адреса ниже будут отображаться только как / about-us / в отчетах на уровне страницы:
https://example.com/about-us/
https://another-example.com/about-us/
Вы можете добавить имя хоста предварительно, настроив пользовательский фильтр со следующими значениями:
(Если вы пытаетесь спасти исторические данные, которые не были должным образом отфильтрованы, вы можете использовать вторичное измерение с именем хоста для разграничения URL-адресов в представлении.)
Для сторонней обработки платежей жизненно важна правильная настройка: без нее вы потеряете данные атрибуции для всех транзакций, которые будут отображаться в качестве рефералов от обработчика платежей. Тем не менее, вы имеете ограниченный контроль над страницей обработчика платежей.
Одним из решений является настройка исключения из рефералов для домена вашего обработчика платежей; однако, это усилие — ручное — может стать непростой задачей, если:
Комплексный ответ? Исключите всех рефералов на странице квитанции
Ahava предлагает креативное, комплексное решение: создание исключения из рефералов для всего трафика на вашу квитанцию или страницу «Спасибо». Исключение рефералов сохраняет исходные данные источника и не позволяет Google Analytics создавать новый сеанс, когда пользователи возвращаются на ваш сайт из домена обработчика платежей.
Реализация решения Ahava состоит из двух этапов:
Социальные логины не могут полагаться на общий домен Исключение рефералов — в то время как логин Google может исходить от account.google.com (поддомен, который вы можете безопасно исключить), другие, например Facebook, заходят через facebook.com, и почти на каждом сайте есть не авторизованный реферальный трафик с Facebook.
Распространенным решением является открытие авторизации в новой вкладке или окне, которое поддерживает непрерывность сеанса на вашем сайте. Однако блокировщики рекламы могут вмешиваться в этот процесс или же вы можете — для удобства пользователей — не открывать новое окно.
Другое решение — очень похожее на стратегию Ahava для страниц с благодарностями — состоит в переопределении или игнорировании информации о реферерах для страницы после входа в систему, размещенной на вашем сайте. Установка значения реферера для вашего собственного домена или «ноль» гарантирует, что источник регистрируется как Direct, тем самым сохраняя один сеанс. Стратегия работает, только если страница пост-входа имеет уникальный URL-адрес.
Частично 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 в соответствие с тем, что, как мы знаем, является правдой: пользователи за один раз переходят между доменами, совершают покупки или заполняют формы, которые кратко переносят их в другой домен и из него.
Критическая природа этих взаимодействий — до и после входа в систему, анонимный посетитель по сравнению с известным лидером и потенциальный клиент по сравнению с прошлым покупателем — делает сшивание сеанса вполне оправданным.
Сплетение взаимодействий пользователя улучшает данные об атрибуции и уменьшает слепые зоны в критические моменты в пути пользователя.
Содержание статьи
Фильтры
Выберите тип материала
0 Комментариев
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.