Проблемы кросс-девайс трекинга включают технические и связанные с конфиденциальностью препятствия, которые мешают бизнесу отслеживать одного и того же пользователя на нескольких устройствах. Эта проблема возникает из-за того, что большинство технологий отслеживания полагаются на файлы cookie, которые привязаны к конкретному браузеру. Когда человек переключается с мобильного приложения на браузер ноутбука, связь прерывается. Для агентства цифрового маркетинга решение этой задачи необходимо для понимания истинного возврата инвестиций в рекламу и фактической длины пути клиента.
Почему кросс-девайс трекинг становится сложнее?
Основная причина растущей сложности отслеживания пользователей на разных устройствах — переход к более строгим стандартам конфиденциальности. Современные веб-браузеры внедрили такие функции, как Intelligent Tracking Prevention от Apple и Enhanced Tracking Protection от Firefox. Эти системы предназначены для блокировки сторонних файлов cookie и ограничения срока жизни собственных файлов cookie. Когда срок действия cookie истекает всего через двадцать четыре часа, возможность связать мобильный клик в понедельник утром с покупкой на десктопе в среду вечером исчезает. Эта фрагментация заставляет маркетологов искать новые способы преодоления разрыва, не полагаясь на традиционные методы отслеживания, которые браузеры теперь активно блокируют.
Еще один фактор — сложность современной аппаратной среды. Типичный потребитель может использовать рабочий ноутбук, личный смартфон, планшет и даже смарт-ТВ. Каждое из этих устройств работает в изолированной среде. Приложения на смартфоне не обмениваются данными с мобильным браузером на том же устройстве, создавая еще больше уровней разделения. Без унифицированного идентификатора, такого как логин, эти различные точки касания отображаются в ваших аналитических отчетах как совершенно разные пользователи. Это приводит к переоценке охвата и недооценке того, сколько взаимодействий на самом деле требуется для совершения конверсии.
Каковы основные технические препятствия при сопоставлении устройств?
Технические препятствия часто начинаются с уровня данных. Большинство веб-сайтов не настроены на последовательную передачу уникальных идентификаторов в свои аналитические инструменты. Когда пользователь входит в систему, сайт должен сгенерировать безопасную хешированную версию его ID и передать ее в уровень данных, чтобы Google Tag Manager мог ее считать. Если этот процесс непоследователен или дает сбой на определенных страницах, цепочка отслеживания разрывается. Кроме того, зависимость от клиентских скриптов делает сбор данных уязвимым для блокировщиков рекламы и ограничений браузера. Если скрипт не может загрузиться, данные не отправляются, и пользователь остается невидимым для ваших усилий по кросс-девайс маппингу.
Второе серьезное препятствие — зависимость от вероятностного сопоставления. Этот метод использует такие точки данных, как IP-адреса, разрешения экрана и версии браузеров, чтобы угадать, принадлежат ли две сессии одному и тому же человеку. Однако, поскольку защита конфиденциальности усиливается, браузеры скрывают или маскируют эти детали, чтобы предотвратить фингерпринтинг. Это делает вероятностные модели гораздо менее точными, чем они были несколько лет назад. Маркетологи оказываются перед выбором: либо принять более низкое качество данных, либо внедрить более продвинутые, детерминированные методы, которые требуют от пользователей идентификации через логины или взаимодействия по электронной почте.
Детерминированные и вероятностные модели данных
Понимание разницы между этими двумя моделями данных является ключом для любого старшего маркетолога. Детерминированное отслеживание основано на известных фактах. Когда пользователь входит на ваш сайт со своего телефона, а затем входит в ту же учетную запись на своем десктопе, у вас есть 100% уверенное совпадение. Это золотой стандарт отслеживания. Вероятностное отслеживание, с другой стороны, использует алгоритмы для поиска закономерностей. Оно может заметить, что смартфон и ноутбук часто находятся в одной сети Wi-Fi, и предположить, что они принадлежат одному человеку. Хотя это может заполнить пробелы, это никогда не будет так надежно, как прямое совпадение на основе ID пользователя.
- Детерминированный: Использует хешированные адреса электронной почты, номера телефонов или внутренние ID учетных записей для высокой точности.
- Детерминированный: Требует логина или прямого взаимодействия, где пользователь идентифицирует себя.
- Вероятностный: Использует IP-адреса, типы устройств и паттерны времени суток для оценки совпадений.
- Вероятностный: Не требует логина, но все чаще блокируется современными функциями конфиденциальности браузеров.
- Гибридный подход: Сочетает оба метода для максимизации объема данных при сохранении ядра высокоточных совпадений.
Как Alien Road применяет кросс-девайс трекинг
Alien Road подходит к разрешению идентичности через структурированный процесс, который отдает приоритет данным первой стороны. При типичной настройке аккаунта наша команда начинает с картирования каждой точки касания, где пользователь может предоставить идентификатор, например, адрес электронной почты или номер телефона. Мы не полагаемся на нестабильных сторонних поставщиков данных. Вместо этого мы используем серверный Google Tag Manager для сбора и хеширования этой информации перед отправкой в аналитические платформы. Этот метод гарантирует безопасность данных, обеспечивая при этом прочную основу для кросс-девайс распознавания. Затем наша команда настраивает идентификатор отчетов в Google Analytics 4, чтобы отдавать приоритет данным User-ID над информацией на основе устройств.
В ходе типичного сотрудничества Alien Road также фокусируется на продлении срока жизни файлов cookie с помощью серверных конфигураций. Устанавливая файлы cookie с вашего собственного домена, а не со стороннего сервера, мы часто можем обойти самые агрессивные ограничения браузеров, которые удаляют файлы cookie через двадцать четыре часа. Этот специфический рабочий процесс позволяет нашим клиентам видеть более точный путь к конверсии, часто показывая, что мобильная реклама вносит больший вклад в продажи, чем считалось ранее. Мы предоставляем четкие отчеты, которые показывают пересечение между различными категориями устройств, помогая брендам распределять бюджеты на те каналы, которые действительно начинают путь клиента, а не только на те, которые его завершают.
Как Google Analytics 4 обрабатывает кросс-девайс пути?
Google Analytics 4 был создан с кросс-девайс трекингом в качестве основной функции. Он использует иерархию под названием ‘Идентификатор отчетов’ (Reporting Identity), чтобы решить, как связывать события с пользователями. Верхний уровень этой иерархии — User-ID. Если ваш веб-сайт отправляет уникальный ID для вошедшего в систему пользователя, GA4 будет использовать его как основной способ объединения сессий. Если User-ID недоступен, он ищет данные из Google Signals. Эта функция использует данные пользователей, которые вошли в свои аккаунты Google и включили персонализацию рекламы. Это позволяет Google распознавать пользователей на разных устройствах, даже если они еще не вошли на ваш конкретный веб-сайт.
Если ни User-ID, ни Google Signals не дают совпадения, GA4 возвращается к Device ID, который по сути является ID клиента, хранящимся в файле cookie браузера. Этот многоуровневый подход гораздо эффективнее, чем старая версия Universal Analytics, которая часто хранила эти типы данных отдельно. Однако для правильной работы вы должны убедиться, что ваша политика конфиденциальности обновлена и что у вас установлены правильные сигналы согласия. Без правильных настроек ‘режима согласия’ (consent mode) GA4 может быть вынужден игнорировать эти данные для соблюдения правил, что приведет к пробелам в ваших кросс-девайс отчетах.
Влияние ограничений файлов cookie на измерение
Ограничения файлов cookie напрямую влияют на то, как вы оцениваете стоимость привлечения клиентов. Когда Intelligent Tracking Prevention в Safari ограничивает срок действия cookie семью днями, любой пользователь, которому требуется восемь дней для принятия решения о покупке, при возвращении будет отображаться как новый пользователь. Это разрывает связь с исходным кликом по рекламе. В результате ваши маркетинговые отчеты могут показывать очень большое количество конверсий из ‘Прямого’ или ‘Органического поиска’, в то время как ваши платные поисковые и социальные кампании могут казаться неэффективными. Эта неверная атрибуция может привести к плохим бюджетным решениям, когда вы сокращаете расходы на те самые объявления, которые стимулируют вашу первоначальную узнаваемость бренда.
Чтобы бороться с этим, компании должны отойти от полной зависимости от браузерных файлов cookie. Внедрение серверной среды тегирования позволяет вам выпускать файлы cookie с более длительными сроками действия, поскольку они воспринимаются как исходящие из вашей собственной серверной инфраструктуры. Кроме того, сбор данных первой стороны на раннем этапе воронки, например, через подписку на рассылку, обеспечивает постоянный якорь для идентичности этого пользователя. Как только у вас есть хешированный адрес электронной почты, вам больше не нужно беспокоиться о том, выживет ли cookie семь или тридцать дней, так как вы можете повторно идентифицировать пользователя каждый раз, когда он взаимодействует с вашими письмами или входит в систему.
Распространенные ошибки в кросс-девайс атрибуции
Частая ошибка — полагаться исключительно на модели атрибуции по последнему клику, которые, как правило, отдают предпочтение десктопным конверсиям. Во многих отраслях первоначальное открытие происходит на мобильном устройстве, но финальная транзакция совершается на десктопе, где пользователь чувствует себя в большей безопасности при вводе платежных данных. Если вы смотрите только на последний клик, вы можете сделать вывод, что ваши мобильные кампании не работают. Еще одна ошибка — игнорирование технической настройки функции User-ID. Простого сбора электронной почты недостаточно; эта почта должна быть преобразована в последовательную, не позволяющую идентифицировать личность строку, которую аналитическая платформа может распознать в разных сессиях. Невыполнение этого требования приводит к фрагментации данных.
Еще одна распространенная ловушка — не проверять данные, поступающие из Google Signals. Хотя Signals — мощный инструмент для заполнения пробелов, он иногда может приводить к пороговым значениям (thresholding) в ваших отчетах. Это происходит, когда недостаточно данных для гарантии анонимности пользователей, что заставляет Google скрывать определенные строки в ваших аналитических таблицах. Маркетологи, которые не осознают этого, могут подумать, что их трафик упал, хотя на самом деле он просто скрыт фильтрами конфиденциальности. Жизненно важно отслеживать настройки идентификатора отчетов и переключаться между представлениями ‘Смешанное’ (Blended) и ‘На основе устройства’ (Device-based), чтобы понять, какая часть ваших данных оценивается, а какая наблюдается напрямую.
Как настроить надежную стратегию User ID?
Построение стратегии User ID требует сотрудничества между вашими маркетинговыми и девелоперскими командами. Цель — создать постоянный идентификатор, который следует за пользователем независимо от устройства, которое он использует. Это начинается с идентификации всех ‘ворот’ на вашем веб-сайте, где пользователь может идентифицировать себя. К ним относятся экраны входа, страницы оформления заказа и формы лидогенерации. Как только пользователь идентифицирован, серверная часть должна сгенерировать уникальную, анонимную строку для этого пользователя и передать ее в уровень данных фронтенда. Оттуда Google Tag Manager может считать ее и отправить на ваши различные маркетинговые и аналитические платформы.
- Проведите аудит вашего веб-сайта, чтобы найти каждое место, где пользователь предоставляет электронную почту или создает учетную запись.
- Работайте с разработчиками, чтобы передать хешированную, не содержащую PII версию User ID в уровень данных.
- Включите функцию User-ID в настройках вашего ресурса Google Analytics 4.
- Настройте теги Google Tag Manager так, чтобы они включали параметр user_id в каждое событие, отправляемое в GA4.
- Обновите свою политику конфиденциальности и баннер cookie, чтобы убедиться, что у вас есть юридическое согласие на объединение идентичностей.
С чего начать на этой неделе
Начните с проверки вашего текущего идентификатора отчетов в Google Analytics 4. Перейдите в раздел Администратор, посмотрите в колонку Ресурс и выберите ‘Идентификатор отчетов’. Если у вас сейчас установлено ‘На основе устройства’, вы упускаете кросс-девайс возможности Google Signals и User-ID. Переключитесь на ‘Смешанное’, чтобы увидеть, как меняются ваши данные. Этот простой шаг часто может сразу раскрыть более сложный путь клиента. Отдельно посмотрите отчет ‘Сравнение моделей’ на вкладке Реклама, чтобы увидеть, как различные модели атрибуции, такие как Data-Driven против последнего клика, меняют ценность, присваиваемую вашему мобильному трафику.
Следующий шаг — поговорить с вашей технической командой о серверном тегировании. Спросите их, блокируются ли ваши текущие скрипты отслеживания распространенными блокировщиками рекламы или настройками конфиденциальности браузера. Перенос даже небольшой части вашего отслеживания в серверную среду может повысить точность данных и помочь вам поддерживать более длительные сроки действия файлов cookie. Предприняв эти небольшие шаги сейчас, вы сможете начать строить гораздо более точную картину того, как ваши клиенты перемещаются между устройствами, что приведет к более разумным маркетинговым инвестициям и лучшей общей производительности.
Читать далее: Стратегическое планирование · Цифровой маркетинг