Что такое время жизни cookie

Как маркетологу выжить в мире без cookie

В последние месяцы стало много разговоров о cookie и том, что срок их жизни станет гораздо меньше, чем мы привыкли. Вместе с Владом Флаксом, CEO OWOX, разобрались в том, какие нововведения нас ждут и как адаптироваться маркетологам в новой реальности.

Что происходит?

Браузеры начинают ограничивать срок жизни cookie, игнорируя то время, которое устанавливается javascript или сервером сайта. Например, в Safari cookie сейчас хранятся 2 недели. Это означает, что если пользователь не заходит на сайт в течение 14 дней, то в следующий визит он получит новую cookie и может быть определен как новый пользователь. В новых версиях стандарта ITP 2.2 это ограничение становится еще более жесткими и для third party cookie (установленные сторонними сервисами) срок жизни сокращен до одного дня. Это ограничивает возможности для ретаргетинга сторонними площадками до одного дня, в течение которого, если пользователь не провзаимодействует с сайтом вновь, то cookie будут удалены.

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

Третье – платформы iOS, Android и браузеры ограничивают отслеживание на уровне пользователя. Например, iOS ограничивает использование IDFA – это аналог cookie для устройств Apple. Ограничение вступит в силу с начала 2021 года и будет заключаться в том, что использование IDFA в рамках мобильного приложения будет отключено, пока пользователь явно не даст свое согласие на сбор и хранение данных. Можем предположить, что процент пользователей, которые зароются так глубоко в настройки, будет невелик. А без этого идентификатора все действия, которые может отправлять приложение, не будут связаны с конкретным устройством.

Кроме того, сейчас обсуждается даже ограничение в использовании User Agent в Google Chrome, что сделает невозможным применением методик Fingerprint.

Какие альтернативы?

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

У Apple своя реализация – это инструмент SKAdNetwork, который так же позволяет получить оценку на уровне рекламной кампании, но не на уровне пользователя. Если рекламный сервис подключен к этой платформе, то из мобильного приложения можно отправлять конверсии и сигналы в этот сервис, а из него получать оценку того, какая ценность и какие были взаимодействия между конкретной рекламной кампанией и пользователями. Здесь появляется гораздо больше ограничений, например, до 100 рекламных кампаний в одном аккаунте, и нарезать эти кампании так, чтобы отследить конкретного пользователя не получится.

Как работает сбор данных о кампаниях и пользователях

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

Суть проблемы в том, что CRM рекламодателя, как и прежде, содержит информацию о заявках на уровне пользователя. Но пользователь обычно взаимодействует с несколькими рекламными сервисами и перед маркетологом стоит задача отследить эти посещения и связать конкретное конверсионное действие в браузере с источником, который привлек пользователя. Теперь же данные в сервис аналитики больше не будут поступать на уровне пользователя. В случае с данными, которые отправляются с мобильной платформы, например, iOS, не будет доступен идентификатор IDFA, который служит признаком для объединения данных на разных платформах. Есть аналог IDFA, который может использоваться для аналитики внутри одного приложения, но он не позволит объединять данные рекламных кампаний с данными приложения.

Схема сбора данных о пользователях и кампаниях

Второе изменение, о котором уже упоминали выше, – cookie, которые устанавливаются пользователю на сайте в веб-окружении, будут удаляться спустя сутки неактивности. И если такой пользователь, взаимодействовал с сайтом в понедельник утром и вернулся во вторник вечером, то он получит источник трафика direct, так как связи с предыдущей сессией не будет и ему будет назначен новый cookie.

Некоторые сервисы аналитики имеют исключительную интеграцию с рекламными сервисами, например, Google Analytics с Google Ads и Firebase или Яндекс.Метрика с Яндекс.Директ. То есть сервисы от вендоров дают дополнительную информацию, но по очевидным причинам, они не могут выступать медиатором, и каждый из них собирает свое подмножество данных. Маркетологам же нужно комплексно оценивать рекламные кампании. И так как рекламные кампании не могут быть связаны на уровне пользователя, то это ведет к следующим последствиям.

С чем столкнутся маркетологи

Увеличится доля «новых» пользователей в отчетах. Хотя мы понимаем, что это вернувшиеся пользователи, которых мы не можем идентифицировать из-за того, что браузер присвоил им новый cookie.

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

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

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

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

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

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

Какие изменения затронут рекламные кампании

Вырастет стоимость привлечения клиента. Прежде всего, потому что рекламные сервисы будут обладать меньшей информацией для таргетинга рекламного объявления подходящему пользователю. И чем меньше возможности у рекламного сервиса определить, что это предложение или этот креатив соответствует интересам пользователя, тем менее релевантно оно будет – снизится CTR, увеличится CPA.

Снизится охват Look-a-like кампаний, если он вообще сохранится, ведь фактически он будет сохраняться до тех пор, пока живет third party cookie. Если пользователь после получения third party cookie заходит на сторонний сайт, например, Google, то срок жизни такого cookie будет продлеваться. И значит ретаргетинг в Google, Facebook или любом другом Walled Garden будет жить дольше, чем ретаргетинг от условного Сreteo (так как у последнего меньший охват через свои площадки). Недоступность данных на уровне пользователя не позволяет строить Look-a-like креативы.

С рынка уйдут небольшие игроки. То, что себе может позволить большой рекламный сервис в качестве аргументации того, как его кампании драйвят продажи рекламодателя за счет ассоциированных конверсий, то маленьким игрокам эта стратегия не подойдет. Для этого нужно будет пробрасывать post-back конверсии во все рекламные сервисы. Ассоциированные конверсии работают от той информации о конверсиях, которую с сайта или приложения отправляет рекламодатель. И большинство имеют конверсионные пиксели от Google, Facebook или Яндекса, но если рекламодатель использует десятки рекламных сервисов, то в каждый из них пробрасывать свои конверсии он, скорее всего, не будет.

Как это отразится на отчетах

Рассмотрим на примере:

Изменения в отчете по рекламным кампаниям

Здесь несколько веб и мобайл рекламных кампаний. В таблице видно, что есть некоторое количество ассоциированных конверсий, которые по данным рекламного сервиса относятся к конкретной кампании. И есть конверсии, которые относятся к конкретной рекламной кампании, согласно атрибуции по модели последнего не прямого клика. Сумма всех конверсий равна 100, а сумма ассоциированных конверсий при этом – 195, потому что с одной конверсией взаимодействовало несколько рекламных кампаний и было совершено несколько кликов.

Что произойдет после изменений? Значительно уменьшится количество рекламных каналов, которые можно проассоциировать с конкретной конверсией. И число таких конверсий, связанных с кампанией, будет меньше, потому что информация на уровне пользователя в контексте мобильного приложения или браузера станет недоступна. Конечно эти конверсии не исчезнут, они будут аллоцированы в рамках рекламного сервиса аналитики в direct канал. То есть это будет выглядеть так, будто новый пользователь пришел из ниоткуда и совершил конверсию. Сами ассоциированные конверсии где-то вырастут, где-то уменьшатся. Вероятнее всего их число вырастет у больших игроков, и их не будет у мелких.

Как эти изменения влияют на бизнес и что сделать, чтобы не потерять в эффективности

Если рекламодатель оценивает эффективность рекламных кампаний непосредственно в кабинете рекламного сервиса (например, использует только Facebook Ads и не использует другие рекламные сервисы), то влияние изменений будет низкое и рекламодатель сможет продолжать работать, как и раньше.

Если же работать с охватными кампаниями в Walled Garden (крупнейшие сервисы Google, Facebook и Яндекс), то влияние будет среднее, потому что охватные кампании направлены на метрики, которые собираются вокруг кампаний, а не пользователя, и доступны в рекламном кабинете так же на уровне сегментов.

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

Если сейчас рекламодатель использует аудиторные сегменты и кросс-девайс отчеты, объединяя действия пользователей до отправки их в рекламные сервисы, то влияние будет очень высоким.

Как проверить, насколько это повлияет на вас

Компания Orange Valley подготовила дашборд, который помогает ответить на вопрос, какая доля дохода находится в зоне риска. Для этого она предлагает сравнить долю новых пользователей в браузере Safari и других браузерах. На картинке видно, что в Сафари на 10% больше новых пользователей, но мы уже понимаем, что они не новые, они просто получили новый идентификатор cookie.

Пример дашборда от Orange Valley

Что делать дальше

Самое главное – собирать first party и second party данные.

First party – это те данные, которые компания может собрать в своем приложении или на своем сайте, которые пользователи предоставили напрямую. Second party – это данные, собранные рекламным сервисом, например, данные из рекламных кабинетов.

Чтобы это сделать, надо в первую очередь внедрить Marketing Data Lake. Это нужно, чтобы данные принадлежали и контролировались вами, а не рекламным сервисом. Пока данные о пользователях хранятся в разных системах, особенно тех, которые не принадлежат вам, например, в рекламном аккаунте, CRM, никакой анализ рекламной кампании не возможен.

Собирать сырые данные о действиях пользователей с сайта и мобильного приложения. Сырые – это значит, что каждая строчка в базе и каждое действие приводит к его регистрации и сохранению, это не агрегированные данные. Здесь не должно быть метрик – это каждое взаимодействие записанное отдельным хитом. Важно, что здесь надо собирать данные с такими полями, которые могут быть использованы для связи неавторизованных пользователей. Например, UserAgent и FingerPrint.

Импортируйте в Data Lake максимально гранулированные данные из рекламных кабинетов. Многие ограничиваются только utm-метками для отслеживания переходов из рекламных кабинетов. Но этого недостаточно для построения аналитики без связи с конкретным пользователем. Например, Facebook Ads позволяет выгрузить до 200 полей.

Мотивация пользователей авторизоваться на сайте и в приложении. Это недооцененная активность, которая позволяет рекламодателю собирать данные в контексте конкретного пользователя без IDFA и cookie, а использовать собственный идентификатор и объединять по нему пользователя на разных платформах.

Что делать с собранными данным

Прежде всего нужно построить свою таблицу cross-device matching. Эта таблица объединяет все доступные идентификаторы пользователя в один уникальный профиль. Это расширит знания о пользователе и его действиях, которые могут быть связаны. Не всех пользователей можно объединить с помощью такого подхода, но увеличить количество сессий, идентифицировано связанных с профилем, можно в разы. В зависимости от того, насколько много используется источников, можно расширить долю тех взаимодействий с пользователем, которая будет объединена. Если раньше это были сессии неконвертировавшихся пользователей, то теперь можно увидеть, что они участвовали в цепочке cross-device и cross-browser.

Вот пример такого объединения. Столбец ProfileID – уникальный профиль пользователя, который объединяет в себе несколько идентификаторов Google Analytics 360 (столбец GoogleAnalytics.fullVisitorID) и несколько Client ID (столбец GoogleAnalytics.clientId).

Пример таблицы с объединенными данными

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

Применить cross-device профиль пользователя для расчета атрибуции рекламных кампаний. Это даст более объективную оценку, потому что с его помощью большая доля сессий будет оценена с точки зрения вклада в привлеченные конверсии. Раньше они заканчивались ничем, потому что пользователь не авторизовался и не оформил заказ, но позже он проявлял себя как покупатель (проверял статус заказа или переходил из письма, отправленного ему из CRM) и таким образом технически есть возможность связать его с идентифицированным пользователем. Этот подход позволит значительно увеличить качество оценки рекламных кампаний.

Применить cross-device профиль при отправке аудиторных сегментов. Даже с учетом ограничений, работа с аудиторными сегментами сохранится, потому что для их использования не нужно знать конкретный идентификатор пользователя во внутренней системе. Достаточно знать соответствие с идентификатором в рекламном сервисе. Проведя это соответствие и сохранив его в своей базе, в рекламные сервис будет отправляться идентификатор из рекламного же сервиса. Таким образом, применив cross-device профиль, можно увеличить охват тех аудиторных сегментов, которые применяются.

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

Вот как может выглядеть схема сбора и движения данных, если собирать их из мобильного приложения (AppsFlyer), сайта (Google Analytics), подключить Ads Data Hub, как инструмент объединения данных о рекламных кампаниях; подключить сбор данных из других рекламных кабинетов с помощью коннектора, добавить данные из CRM и на основе этого строить отчеты и атрибуцию.

Схема сбора и движения данных

Пусть никакие обновления не застают вас врасплох и may the force data be with you!

Источник

Cookies — Протокол HTTP

HTTP является протоколом без сохранения состояния (англ. stateless protocol). Это означает, что каждая пара запрос-ответ не связана с предыдущим запросом-ответом. В реальной жизни это оказывается не очень удобно, так как иногда нам нужно запомнить аутентификацию пользователя или, например, хранить данные корзины с товаром пользователя в интернет-магазине. Тут возникает проблема: «Как запомнить, что это тот пользователь, с которым мы только что работали?» Решение этой проблемы было найдено более 10 лет назад, когда был придуман механизм, который называется — Cookie.

Давайте сделаем запрос к сайту Хекслета и посмотрим как этот механизм работает. Мы будем использовать программу curl. Она позволяет делать HTTP запросы и флагами управлять различными их параметрами. В отличие от telnet нам не нужно заранее устанавливать соединение и потом набирать сырой запрос. При работе с curl можно сразу определить параметры и она сама отправит все нужные заголовки запроса, в том числе и по HTTPS.

Давайте выполним запрос для получения только заголовков, для этого добавим к запуску curl флаг —head.

Мы видим два заголовка, которые занимаются установкой cookie — set-cookie. Обратите внимание, что каждая cookie посылается в отдельном заголовке. Соответственно таких заголовков может быть достаточно много. Внутри кука представляет из себя пару ключ=значение и отделяется от дополнительных параметров точкой с запятой. Куки сохраняются в браузере на клиенте и при следующем запросе он отправляет их обратно на сервер. Непосредственно в браузере они никак не используются. Хорошая аналогия — это как получить номерок в гардеробе и потом вернуть его, чтобы понять какая куртка ваша. При этом сам номерок никакой ценности не представляет и его нельзя использовать самостоятельно.

Куки делятся как минимум на два типа:

Сессионные куки в нашем запросе не устанавливаются, так как мы видим дополнительные параметры в заголовке set-cookie. Если бы их не было, то кука называлась бы сессионной. Основное их отличие от постоянных в том, что как только закрывается браузер кука удаляется. Например, на некоторых сайтах, если вы не отметите галочку «запомнить меня» и после закрытия браузера зайдёте на сайт снова, то будете не авторизованы. Так происходит потому, что используется сессионная кука.

Время жизни куки

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

В параметре expires указывается дата удаления куки, после которой она не будет отсылаться на сервер. Стоит сказать, что есть еще один параметр, который используется для тех же целей — MAX-AGE. В его значении указывается количество секунд по истечении которых кука будет удалена.

Так как часть браузеров не поддерживают MAX-AGE, некоторые фреймворки часто устанавливают сразу оба параметра и браузеры просто игнорируют тот, который им не нужен. Таким образом заголовок set-cookie, который содержит два параметра MAX-AGE и expires, считается валидным. В стандарте также говорится и о том, что регистр имени куки не имеет значения.

Параметры domain и path

Параметры domain и path задают область видимости куки, то есть URL, на которые кука может отправляться. Если они не заданы, то по умолчанию кука будет пересылаться на сервер только для текущего пути и домена. В нашем примере в path указан корень сайта.

То есть кука будет отправляться для всех страниц. Есть нюанс, если установлен domain=.hexlet.io, причём наличие точки перед именем домена не имеет значения, то кука будет работать не только для всех страниц сайта, но и для всех поддоменов. А если мы совсем не установим параметр domain, хотя по умолчанию его значение будет hexlet.io, то кука для поддоменов работать не будет.

Уникальность куки определяется тремя параметрами key (имя куки), domain и path. Это значит, что если какую-то куку нужно переустановить, например, поменять время её жизни, то при следующем запросе в set-cookie эти параметры должны совпадать. Если хотя бы один из них отличается, то будет установлена новая кука.

Удаление куки

Заголовка для удаления куки не существует, чтобы удалить её, нужно установить нулевой или отрицательный MAX-AGE, либо задать expires в прошлом, тогда кука будет немедленно удалена.

HttpOnly cookie

Можно заметить, что в нашем примере установлен дополнительный параметр HttpOnly. HttpOnly куки передаются с AJAX-запросами, но их нельзя получить через JavaScript на странице сайта. Это дополнительный уровень безопасности от XSS атак.

Отправка на сервер

После того как мы обновляем страницу в браузере, происходит отправка следующего заголовка:

Источник

Apple ограничил срок жизни cookies (в 2023 то же сделает Google): это мешает отслеживать, откуда приходят клиенты

В чём проблема: представьте пользователя, который использует Safari, как основной браузер. Он три раза зашел на сайт продавца из рекламных каналов. А потом вернулся на сайт более, чем через 7 дней, и сделал покупку. Google Analytics определит его, как нового пользователя, а источник — Direct/None.

Поэтому усложняется понимание, из какого рекламного канала на сайт приходят клиенты. Доля прямых заходов будет расти. И ситуация станет ещё сложнее, когда аналогичные блокировки в 2023 году задействует Google.

В июле Calltouch провел онлайн-дискуссию, на которой Алексей Никушин (Матемаркетинг), Алексей Бирюков (Цифровой паспорт), Дмитрий Осиюк (MacPaw), Игорь Селицкий (SegmentStream) и Сергей Довганич (Renta.im) обсуждали — какие есть решения этой проблемы. Модерировал встречу аналитик Calltouch Павел Мрыкин.

Команда Renta.im выбрала главное из двухчасового обсуждения.

Apple начала работать над технологией ITP — Intelligent Tracking Prevention — ещё в 2017 году. Что делает эта технология: блокирует популярные трекеры третьих сторон (3dr party cookies), если те запрашивают слишком много информации о пользователях.

То есть, «куки» Google Analytics и других сервисов хранятся не более 7 дней, а иногда и до 24 часов. Междоменное отслеживание вовсе попало под запрет.

С апреля этого года, после противостояния с Facebook, Apple начала блокировать идентификатор IDFA для iOS-устройств (это мешает отслеживать действия юзеров в приложениях). В июне ограничение на трекинг начало действовать и для ПК-пользователей Safari.

Facebook и многие другие IT-площадки и сервисы позиционируют себя «бесплатными», но на деле имеют свою выгоду — собирают большой пул данных по каждому пользователю. И продают эти данные третьим лицам.

Из-за этого в последние годы возник ряд скандалов. Очень громкой была история с английской компанией Cambridge Analytica (оказывает консалтинговые политические услуги), которая, возможно, повлияла на итоги президентских выборов в США в 2016 году:

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

Бывший сотрудник Cambridge Analytica

Также совсем недавно вышла книга-расследование журналистов The New York Times, которые выяснили, что тысячи сотрудников Facebook имеют доступ к персональным данным пользователей соцсети. И некоторые пользуются этим доступом также для собственной выгоды или слежки за другими людьми.

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

Алексей Никушин (Матемаркетинг) считает, что Apple следует принципу «не можешь победить — возглавь». В 2012 году компания отказалась от CD-дисковода в Маках — на то время не все поняли такой шаг, но сегодня это привычное решение для тонких ноутбуков.

Вероятно, Apple хочет быть первопроходцем и на рынке privacy.

Я спрашиваю у мамы, что она обо всём этом думает, и она отвечает: «Мне кажется, что если у меня будет Айфон, у меня не украдут данные банковской карты». Ограничения для cookies — вообще не про это, но в сознании людей всё путается. Думаю, Apple знает, что люди так думают. Они понимают, что следующая битва — за пользовательские данные.

Сергей Довганич (Renta.im) думает, что главная причина — в разборках IT-гигантов и регуляторов по теме конфиденциальности. А сегменту e-commerce сопутствующие проблемы с необходимостью перестраивать веб-аналитику прилетели «по касательной».

И Алексей Бирюков представляет «теорию заговора»:

Я точно знаю, что это всё про деньги. Эпл делает рекламную сетку и будет работать над монетизацией своего трафика. Они предложат всем разработчикам встроить свою сетку внутрь, чтобы проводить таргетирование и монетизацию.

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

А другим по ряду причин необходимо время, чтобы подумать и определиться.

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

Участники круглого стола поделились своими идеями и опытом:

У себя мы фингерпринтинг не делаем, потому что это тупиковый вариант. Apple и многие другие компании сказали, что это будет запрещено.

Можно трансформировать utm-метку в уникально сокращенный get-параметр, который крайне тяжело отключить от основной части урла. Мы сейчас так делаем и имеем 99.99% точности получения своих данных.

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

Если говорить про самые простые вещи — нам не обойтись без установки cookies на сервере. Можно создавать их по той логике, как создается «кука» GA, но создавать на бэкенде своим сервером и писать через response header, как это разрешают политики браузера. Такая «кука» не будет удаляться через 7 дней. Это самое минимальное, что можно сделать, и закрыть тем самым 80% проблем.

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

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

Я жду, что рекламные системы и площадки в скором времени будут выпускать новые инструменты, похожие на Conversion API от Фейсбука. Мы будем отдавать свои данные им, и в ответ получать агрегированные данные с результатами рекламных кампаний.

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

Крупные компании будут делать «коробочные» сервисы:

Google и Facebook будут делать решения, в которых не нужно будет много кодить, а внедрить несколько изменений по мануалу.

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

Что касается маркетинга — перед ним встает задача еще больше акцентироваться на действия клиента в реальном времени. Нужно поймать человека «на лету», пока он не ушёл.

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

По мнению Дмитрия Осиюка, у рекламных систем появится возможность «чуть-чуть врать в отчётах» — а у нас не будет возможности это проверить до уровня юзера или уровня клика. Это будет возможным только для того клиента, который даст на это разрешение.

Алексей Бирюков считает, что реклама для малого и среднего бизнеса в целом будет уходить в сторону автостратегий и сервисов:

Альтернатива автостратегиям: бери сам все рычаги и сам всё настраивай.

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

Если проблемы с трафиком от Safari вас пока не затронули, то напоминаем, что когда cookies начнёт ограничивать Google в 2023 году, это повлияет на точность отслеживания существенно большей части трафика со всего мира.

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

«Маркетинг-аналитика без cookies» — бесплатная методичка от Renta: более подробное руководство, как организовать трекинг на базе 1st party данных и позаботиться о качестве данных в маркетинг-аналитике.

Хватит ныть, используйте разные URL для разных источников трафика.

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

Это не рабочее решение, так как ломается любая маркетинг-атрибуция, а при кроссдоменном отслеживании срок жизни куки ограничивается до 24 часов.

Чем вас атрибуция счетчиков Метрики и Гугл Аналитики не устраивает?

Тем, что описано выше:

«В чём проблема: представьте пользователя, который использует Safari, как основной браузер. Он три раза зашел на сайт продавца из рекламных каналов. А потом вернулся на сайт более, чем через 7 дней, и сделал покупку. Google Analytics определит его, как нового пользователя, а источник — Direct/None.»

и что делать в итоге?

(если брать реальный кейс пускай это будет, к примеру, пожилая пара которая выбирала себе триммер для милых сердцу 6 соток)

«Вероятно, Apple хочет быть первопроходцем и на рынке privacy» — тенденция прослеживается. Я имею ввиду последнюю новость о том, что Эпл будет сканировать контент в детских телефонах.

Источник