Intelligent Tracking Prevention и другие механизмы борьбы с отслеживанием существенно изменили мир отслеживания. Они ввели ограничения на файлы cookie, которые бросают вызов предприятиям, в значительной степени полагающимся на онлайн-маркетинг, особенно на сбор данных третьих лиц для таргетирования рекламы.
В этой статье блога речь пойдет об ограничениях отслеживания, которые затрагивают файлы cookie, как они влияют на маркетинг и как использовать серверный Google Tag Manager для продления срока службы файлов cookie.
В наши дни куки третьей стороны блокируются многими браузерами. Два самых популярных браузера, которые ограничивают сторонние файлы cookie, - это Safari и Firefox. Chrome объявил, что к концу 2023 года начнет постепенно отказываться от сторонних файлов cookie. Это означает, что к концу 2023 года около 80% браузеров перестанут поддерживать сторонние файлы cookie. Куки первой стороны не будут затронуты.
Давайте поговорим о разнице между файлами cookie первой и третьей сторон. Упрощенно говоря, основное различие заключается в следующем: куки первой стороны устанавливаются с вашего сайта на ваш домен, а куки третьей стороны устанавливаются с вашего сайта на другие домены.
Ограничений на использование файлов cookie первой стороны нет. Куки третьей стороны приобрели плохую репутацию из-за межсайтового отслеживания. Рекламодатели используют этот тип файлов cookie для отслеживания пользователей на разных доменах и для составления профиля пользователей. С помощью файлов cookie третьей стороны крупные платформы могут следить за вами в Интернете и видеть, какие сайты вы посещаете. И, в конце концов, использовать эту информацию для показа персонализированной рекламы.
Алгоритмы интеллектуального предотвращения отслеживания, используемые в Firefox и Safari, ограничивают время жизни файлов cookie до 7 дней (когда файлы cookie устанавливаются с помощью JavaScript) или 24 часов (когда файлы cookie устанавливаются с помощью JavaScript, используется украшение ссылок и ссылающийся на сайт ´известный трекер´).
Большинство маркетологов используют UTM-теги для отслеживания параметров кампании. Когда ITP обнаруживает UTM-теги в URL, он уменьшает время жизни cookie до 1 дня. Это сильно влияет на атрибуцию, поскольку если пользователь посетит ваш сайт, кликнув на объявление с UTM-тегами, и совершит конверсию несколько дней спустя, конверсия не будет приписана рекламной кампании.
Поскольку файлы cookie удаляются через 1 или 7 дней, пользователь, посетивший ваш сайт 7 дней назад, будет считаться новым. Это окажет огромное влияние на движение клиента по сайту. Вы не сможете увидеть полную картину того, какие источники трафика повлияли на решение клиента совершить покупку.
Персонализация часто используется для обеспечения беспрепятственного взаимодействия с клиентами путем показа релевантных предложений, контента, продуктов и т.д. С уменьшением срока службы cookie персонализация может иметь негативные последствия. Поскольку пользователь будет относиться к новому пулу аудитории каждый раз, когда срок действия cookie истекает.
Каждое партнерское предложение имеет свое время жизни cookie. Если пользователь заходит на ваш сайт в Safari по реферальной ссылке сегодня и совершает переход через 10 дней, эта конверсия не будет засчитана партнеру. В результате партнер не получит комиссию.
Когда куки сбрасываются каждые 7 дней или 1 день, это негативно сказывается на размере аудитории ремаркетинга и частоте объявлений. У платформ также будет меньше данных для создания похожих или аналогичных аудиторий.
Установка или продление срока действия файлов cookie - это сложный вопрос, который следует рассматривать индивидуально для каждой платформы и браузера. Но если подвести итог, то можно использовать серверный контейнер Google Tag Manager с пользовательским доменом для установки cookie-файлов первой стороны и продления времени жизни cookie-файлов. Посмотрите на этом сайте cookiestatus.com, чтобы узнать, как работают файлы cookie в каждом браузере.
Стандартные клиенты Universal Analytics или Google Analytics 4 для серверного Google Tag Manager устанавливают серверные куки FPID с флагом HttpOnly. Это делает куки Google Analytics устойчивыми к ITP, потому что ITP в основном влияет на куки, установленные сторонними разработчиками JavaScript. Это означает, что куки Google Analytics на стороне сервера будут действовать в течение 2 лет, как и раньше.
Google Analytics 4 был выпущен год назад, и не так много компаний успели перейти на GA4, большинство все еще используют Universal Analytics. Если вы хотите перевести существующее свойство UA с веб-отслеживания на серверное, то обязательно включите "Migrate from JavaScript Managed Client ID" в шаблоне Universal Analytics Client. Это предотвратит создание новых пользователей для тех, кто уже посещал ваш сайт. GA будет продолжать использовать JavaScript Managed Client ID до тех пор, пока не будет сброшен файл cookie _ga. Как только срок действия _ga истечет, будет использоваться FPID.
Наш тег Facebook conversion API для серверного GTM автоматически продлевает срок жизни куки _fbp и _fbc до 2 лет. Все другие теги stape.io для серверного Google Tag Manager так же продлевают срок жизни cookie. Срок жизни cookie зависит от платформы.
Stape создал тег Cookie extender для sGTM, предназначенный специально для продления срока жизни файлов cookie. Может возникнуть множество ситуаций, когда вам нужно использовать этот тег для продления срока жизни cookie, из моего опыта можно выделить следующие наиболее популярные сценарии:
Несколько раз нам требовалось расширить cookies для платформ, чьи родные теги не могут этого сделать, например, для партнерских сетей и почтовых сервисов. Или, может быть, вам нужно расширить веб-куки, поскольку серверные куки, те, что с Httponly, не могут быть доступны JavaScript. И вы не можете использовать эти куки в веб-GTM. Или, может быть, вам нужно использовать формат ID клиента, сгенерированный веб-GA, на других платформах. Во всех этих ситуациях может помочь расширитель Cookie.
Еще один распространенный сценарий - когда вы используете веб- и серверное отслеживание, например, для таких платформ, как Facebook, TikTok или Snap. Даже если вы расширите куки fb с помощью серверного тега, могут возникнуть ситуации, когда сначала будут установлены веб-куки. Это означает, что серверные куки и регистр Safari все равно будут уменьшаться.
Как же продлить куки в таких случаях с помощью тега Cookie extender?
1. Загрузите тег Cookie extender с GitHub.
2. Импортируйте тег Cookie extender в ваши шаблоны тегов sGTM. Перейдите в разделы шаблонов в sGTM -> Нажмите создать новый тег -> Импортируйте тег Cookie extender, который вы скачали с GitHub.
3. Создайте тег Cookie extender в sGTM. В этом примере я буду расширять куки Facebook (fbc, fbp) и Google Analytics (gid и ga). В настройках тега я задал имена cookie и время жизни, до которого нужно расширить эти cookie.
Я также включил флажок Создавать резервные куки и восстанавливать их в случае, если основные куки не найдены. Эта настройка создает резервные куки, например, для _ga она создаст _ga_backup и сохранит там то же значение, что и _ga. Если вы установили тег Cookie extender и включили резервное копирование cookie, он восстановит cookie _ga из резервной копии cookie _ga_backup. Это означает, что у этого пользователя останутся те же файлы cookie, которые были у него во время первых посещений, даже если файл _ga cookie уже был стерт.
С файлами cookie Facebook (fbc, fbp) применяется другая логика. Серверный тег FB CAPI устанавливает куки на 3 месяца. Если вы используете как браузерное, так и серверное отслеживание FB, то возможны случаи, когда пиксельный тег FB срабатывает первым и устанавливает браузерный cookie, время жизни которого в Safari (и других браузерах с ITP) составляет максимум 7 дней. В этом случае куки не продлеваются. Чтобы устранить эту проблему, мы будем запускать пиксельные теги FB только после того, как серверный тег FB установит cookies.
4. Внутри контейнера web GTM я хочу изменить триггер для событий FB pixel, поскольку сначала мне нужно установить серверные cookies. Для этого я буду использовать Data Tag/Data Client, поскольку у них есть возможность отправить dataLayer push в web GTM после завершения запросов сервера. Моя идея состоит в том, чтобы запускать FB pixel только после того, как сработает тег FB CAPI на сервере, что означает, что серверные cookies были установлены.
Для этого я буду использовать Data Tag/Data Client для отправки data layer push в web GTM, когда сервер получил ответ.
Мой триггер для тега FB pageview выглядит следующим образом. Он срабатывает на пользовательское событие server_reponse, означающее, что серверные запросы были отправлены.
5. Теперь вы можете протестировать тег Cookie extender, используя предварительные просмотры GTM для веб и сервера. Как только вы убедитесь, что все работает правильно, я бы предложил открыть Safari (или любой другой браузер, который ограничивает время жизни куки) и протестировать куки. Вот как выглядят куки для моей установки.
С ограничениями ITP на куки и сбор других данных до сих пор Safari возглавлял борьбу за конфиденциальность. Однако другие браузеры также начали внедрять механизмы антитрекинга, включая Chrome, который занимает более 50% рынка браузеров.
Cookies оказывают значительное влияние на эффективность кампаний, атрибуцию, отслеживание конверсии и т.д. Именно поэтому вы можете захотеть внедрить отслеживание на стороне сервера, чтобы продлить время жизни cookie. Если вам нужна помощь, просто отправьте письмо на agency@stape.io.
Все, что для этого нужно, - ответить на несколько простых вопросов. Нажмите Получить помощь, заполните форму, и мы вышлем вам предложение.
