Как маркетологу выжить в мире без 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 или Яндекс.Метрика с Яндекс.Директ.  То есть сервисы от вендоров дают дополнительную информацию, но по очевидным причинам, они не могут выступать медиатором, и каждый из них собирает свое подмножество данных. Маркетологам же нужно комплексно оценивать рекламные кампании. И так как рекламные кампании не могут быть связаны на уровне пользователя, то это ведет к следующим последствиям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    4. Мотивация пользователей авторизоваться на сайте и в приложении. Это недооцененная активность, которая позволяет рекламодателю собирать данные в контексте конкретного пользователя без 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!

    Комментарии 17

      0
      А почему не рассмотрена самая очевидная альтернатива, которая напрямую логически вытекает из всех этих ограничений браузеров и платформ? Я имею ввиду вообще перестать собирать метрики, привязанные к пользователю, чего, собственно, многие пользователи и хотят?
        +2
        Я стараюсь всё «хождение» по интернету проводить в приватном режиме.
          0
          Давно хочу спросить тех, кто так старается скрыть свой путь в интернете — для чего? Реклама же не прекратится, она просто станет не релевантной интересам пользователя. Да и куда проще бороться с ней блокировщиком
          Или дело не в рекламе?
          +1
          Эта альтернатива лишает возможности рекламодателей оптимизировать рекламные кампании и повышать релевантность рекламы. Это сдерживает их не только их прибыль, но и возможности предложить более широкий ассортимент рекламодателям по более низким ценам. Причина в том, что в цену товара заложена стоимость привлечения клиента и если реклама работает хуже, то и цены будут выше
            +1
            Раздражает же именно нерелевантная реклама. К примеру, я не прячусь, работаю программистом больше десятка лет. Но реклама постоянно приглашает меня пройти курсы типа «JavaScript для начинающих» или «Освой С++». Так что пространсво для повышения релевантности большое.
              0
              Система не знает, что вы «работаете программистом», она только знает, что вы «интересуетесь программированием». Знала бы подробности — не показывала. А в будущем, похоже, система будет знать о вас даже меньше, так что даже после того, как вы пройдете какие-либо курсы, она будет вам предлагать их снова и снова.
          0
          Очень актуальная и полезная статья. Спасибо большое!

          1) Самого интересно не увидел. По какому принципу можно объединять пользователей в cross-device matching таблице?

          2) Например, как мне связать пользователя, который зашел на мой промо сайт (1st party cookie) и на мое приложение запущенное внутри iframe на стороннем домене (3rd party cookie)? Используя fingerprinting по user agent / ip? Так его тоже скоро ограничат.

          3) Если Google analytics код установлен на многих сайтах, то ставит ли GA общую для всех сайтов cookie, по которой он видит человека, который гулет по сайтам? В этом случае вероятность того, что человек не зашел ни на один сайт с GA будет очень низкой, соответственно cookie GA будет жить очень долго. И может тогда можно использовать GA user id для такого связывания посетителей из вопроса 1)?
            +1
            3) Google больше не может выставлять cookie c вашего сайта на google.com вот более детально про текущий статус www.cookiestatus.com

            Вообще почти все описанные проблемы в статье решает GTM Server Side. Вы можете раздавать cookie аналитики со своего домена на 2 года. Это работает и в Safari и Firefox и любых других браузерах с ITP 2.2 и даже обходить CNAME cloaking.

            2) Зависит от того какой конкретно домен использован для iframe.

            В рамках одного домена можно пользователя обеднить по cookie даже сейчас. Не важно как открывается сайт через iframe или sub домен или просто на прямую.

            А касательно того как идентифицировать пользователя с разных девайсов/браузеров. Я обедняю по своим признакам email/phone/ip+user agent. Пользователь мог подписаться на рассылку/зарегистрироваться/рекламный источник передать идентификатор. Это все можно отправлять в аналитику и привязывать к пользователю. Примерно по такому же принципу Facebook определяет пользователя на сайте с пользователем у себя. Вот по этому Facebook пиксель просит присылать им email/phone/ip/user agent.
              0
              А разве «сафари», к примеру, не трет аналитические куки? Чем они отличаются от обычных?
              0
              brgr сможете прокомментировать?
                0
                1. Мы рекомендуем больше всего использовать first party данные (clientId, userId, emailHash), но если совесть позволяет можете использовать и fingerprint

                2. Да, fingerprinting, да ограничат. Тем ни менее, в зависимости от масштаба ваших вложений, это можно быть выгодно сделать даже на время.

                3. GA нет, DoubleClick — да.
                Заход на другие сайты GA не влияет на срок жизни. Технически возможно вызывать код GA в контейнере вашего объявления на внешнем сайта, но проще использовать готовые трекинг-пиксели
                +2

                mkulesh


                Продавец может потратить 10000 денег, чтобы обеспечить продажу 1000 товара (оформление прилавка, реклама, штат, налоги, реклама, электричество, реклама, аренда торговой площади, реклама). Куда он засунет 10000 растрат? В цену единицы товара, разумеется. Хорошо вам от этого? Вот и продавцу тоже плохо — товар не идёт.


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


                Значит умный продавец тратит 10 для рекламы и 990 за выборку таких людей, на которых эта реклама мощнее всего подействует. На кого подействует? На тех, кто достаточно детально демонстрирует профиль своих интересов. Может не в этот раз, в этот раз вы не в выборке для продавца, но в следующий раз точно.


                "Вы требуете написать на бумаге инвойс на требуемые мной 100$ за ремонт электромотора одним ударом кувалды? Сам удар кувалдой стоит 1$, я вам могу сделать скидку до бесплатного. 99$ стоит знание, куда надо было стукнуть. Вот вам инвойс на 99$, платите за решение проблемы" /история про эксперта/.

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


                Это цена, которую платите вы, чтобы отпускные цены товаров были дешевле.


                https://www.youtube.com/watch?v=S6U0Jx-zBM8


                Лично вы можете выбрать максимально сократить отдачу профиля личных предпочтений до мизера. Как и я.


                Но "Отучаемся говорить за всех" /FIDO/

                  0
                  Результат любого действия надо мерять, чтобы понимать что усилия уходят не зря.

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

                  А теперь мерять результаты многих своих маркетинговых активностей становится очень сложно без нормальных 1st / 3rd party cookies.
                  0
                  Кроме того, сейчас обсуждается даже ограничение в использовании User Agent в Google Chrome, что сделает невозможным применением методик Fingerprint.

                  User-agent не используется в современном фингерпринтинге, например, в известной библиотеке FingerprintJS. Отсутствие user-agent никак не помешает фингерпринтингу.

                    0
                    Решение о том, что использовать в качестве ограничений, принимается на стороне браузера. Поэтому вопрос не конкретно в User-agent, а любом параметре, доступном библиотекам fingerprint только потому, что доступ к ним не ограничен браузером
                    0
                    Отличный материал. Спасибо. Можно пару примеров про импорт в Data Lake максимально гранулированных данные из рекламных кабинетов, на примере FB? Забираем по API и как связываем с конкретным пользователем? Или речь идет о получении данных о сегментах?
                      0
                      Вот пример того, что мы понимаем под гранулированными данными из Facebook. Связать их с пользователем напрямую нельзя, но можно на основе вероятностного анализа

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

                    Самое читаемое