Сопоставление файлов cookie

В общих чертах, сопоставление файлов cookie — это процесс, в ходе которого рекламодатель или поставщик связывает файлы cookie в своем домене с файлами cookie в домене Google. Сопоставление этих файлов cookie позволяет связать собственные данные, которыми вы владеете, с рекламными данными Google (отслеживаемыми через Display & Video 360 и Campaign Manager 360) об одном и том же пользователе, что позволяет интегрировать данные CRM и лучше понимать поведение пользователей. Объединяя эти данные с помощью механизмов, ориентированных на конфиденциальность, вы можете:

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

Ограничения и конфиденциальность конечного пользователя

Несмотря на свою эффективность, сопоставление файлов cookie имеет некоторые ограничения:

  • Запрещено соединение таблиц, содержащих *_match , с таблицами, не содержащими *_match .
  • Для этого потребуется инженерная работа как с вашей стороны, так и со стороны Google.
  • Маловероятно, что вам удастся сопоставить все данные вашей рекламы Google. Коэффициенты соответствия зависят от ряда факторов и варьируются в зависимости от сценария использования и настроек на стороне клиента. Часто коэффициенты соответствия ниже, чем ожидают пользователи. Пользователи имеют право на сопоставление файлов cookie только в том случае, если они взаимодействовали с вашим доменом и вашей рекламой .
  • Google начинает заполнять ваши таблицы соответствия, как только они настроены. В зависимости от частоты посещения пользователями вашего сайта и получения пикселя соответствия, может потребоваться несколько месяцев, прежде чем ваши таблицы соответствия будут содержать полные и стабильные данные о ваших пользователях.
  • Вы не сможете привязать отдельных пользователей к нескольким устройствам, если у вас нет способа обеспечить связь пользователей между устройствами.
  • Нельзя сопоставить одного пользователя, используя несколько файлов cookie, как это было бы в случае, если бы пользователь удалил свои файлы cookie.
  • Задания, выполняемые на основе таблиц соответствия, подчиняются тем же требованиям агрегации, что и другие задания в Ads Data Hub. Низкий коэффициент соответствия в сочетании с редкими посещениями вашего домена может привести к трудностям в получении данных. Это связано с совокупным воздействием коэффициентов соответствия и требований агрегации¹ .
  • В соответствии с политикой Google в отношении конфиденциальности конечных пользователей, вы:
    • Запрещено сопоставлять данные о входе и выходе из системы конкретного пользователя.
    • Не удается сопоставить данные с пользователями, которые отказались от персонализации рекламы.
  • Для событий iOS можно сопоставлять только данные, поступающие из приложений на iOS 14.5 и выше от пользователей, предоставивших разрешение в рамках системы прозрачности отслеживания приложений Apple.

Чтобы обеспечить возможность использования ваших собственных данных в Ads Data Hub, вы должны подтвердить получение надлежащего согласия на передачу данных от конечных пользователей из ЕЭЗ компании Google в соответствии с политикой согласия пользователей ЕС и политикой Ads Data Hub . Это требование распространяется на каждый аккаунт Ads Data Hub и должно обновляться каждый раз при загрузке новых собственных данных. Любой пользователь может подтвердить это от имени всего аккаунта.

Обратите внимание, что те же правила запросов к сервисам Google, которые применяются к аналитическим запросам, также применяются к запросам на сопоставление cookie-файлов. Например, вы не можете выполнять межсервисные запросы к пользователям в ЕЭЗ при создании таблицы соответствия.

Чтобы узнать, как подтвердить согласие в Ads Data Hub, см. раздел «Требования к согласию для Европейской экономической зоны» .

Для того чтобы Google мог заполнить ваши таблицы соответствия, необходимо разместить тег соответствия на каждой странице вашего домена, где вы хотите сопоставить рекламные данные. Место размещения пикселя будет зависеть от ваших рекламных целей. Например, вы можете попытаться сопоставить каждого пользователя, посетившего ваш домен (для этого требуются пиксели почти на всех страницах), или вы можете сопоставить пользователей, совершивших конверсию (для этого требуются пиксели на странице конверсии). Как правило, более широкое распространение пикселя приведет к более высоким показателям соответствия.

Метка соответствия представляет собой прозрачный пиксель размером 1x1 пиксель, содержащий идентификатор вашего профиля, соответствующего файлу cookie, и закодированный идентификатор пользователя или файла cookie:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm=Q29va2llIG51bWJlciAxIQ" />

Этот тег соответствия инициирует обмен данными между вами и сервисами сопоставления файлов cookie Google.

Пошаговый обзор

  1. Пользователь посещает страницу, содержащую тег соответствия.
  2. Тег match инициирует серию перенаправлений на платформы Google Marketing Platform, Google Ads и сервисы сопоставления запросов YouTube. Запросы содержат идентификатор пользователя или cookie с вашего веб-сайта, а также cookie Google в каждом из полей идентификаторов сервисов сопоставления.
  3. Для подтверждения выполнения запроса браузеру возвращается прозрачный пиксель размером 1x1.

Этот процесс показан на следующей диаграмме:

Схема процесса перенаправления браузера и соответствующего сервиса.

Настраивать

Процесс настройки сопоставления файлов cookie в Ads Data Hub выглядит следующим образом:

  1. Свяжитесь со своим представителем по работе с клиентами и сообщите о своем интересе к сопоставлению файлов cookie. Он обсудит ваши цели и предоставит дополнительную информацию о развертывании пикселя отслеживания на вашем домене.
  2. Специалисты Ads Data Hub начнут еще одну беседу, чтобы обсудить технические требования и сценарии использования.
  3. Пока вы развертываете пиксель отслеживания и конечную точку обработки ошибок, Google создаст для вас таблицы соответствия.

После выполнения этих шагов никаких немедленных действий не требуется. Google будет ежедневно заполнять ваши таблицы совпадений² , поэтому вам потребуется достаточно времени, прежде чем ваша таблица будет содержать достаточно данных для предоставления значимых совпадений и выполнения требований агрегации. Это зависит от частоты посещения вашего сайта пользователями; сайт с ежедневными посетителями достигнет этого уровня гораздо быстрее, чем сайт с ежемесячными посетителями. По мере снижения количества новых совпадений ваши таблицы совпадений будут содержать более полные данные.

Запрос к таблицам матчей

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

Исходная таблица для данных от первого лица (1PD) представлена ​​таблицей my_data . Она включает как персональные данные (PII), так и данные, не являющиеся персональными. Использование исходной таблицы может улучшить ваши отчеты, предоставив больше аналитической информации, поскольку она отражает все данные 1PD в рамках данной таблицы по сравнению с таблицей соответствия.

Каждая таблица в схеме Ads Data Hub, содержащая поле user_id сопровождается таблицей соответствия. Например, для таблицы adh.google_ads_impressions Ads Data Hub также генерирует таблицу соответствия adh.google_ads_impressions_match , содержащую ваши идентификаторы пользователей. Отдельные таблицы соответствия создаются для таблиц сетевой политики. Например, для таблицы adh.google_ads_impressions_policy_isolated_network Ads Data Hub также генерирует таблицу соответствия adh.google_ads_impressions_policy_isolated_network_match , содержащую ваши идентификаторы пользователей.

Эти таблицы содержат подмножество пользователей, доступных в исходных таблицах, для которых найдено совпадение по user_id . Например, если исходная таблица содержит данные для пользователя A и пользователя B, но найдено совпадение только для пользователя A, то пользователь B не будет присутствовать в таблице совпадений.

В таблицах соответствия содержится дополнительный столбец под названием external_cookie , в котором хранится идентификатор пользователя в байтах.

При написании запросов важно учитывать тип поля. Операторы сравнения SQL ожидают, что сравниваемые литералы будут одного типа. В зависимости от того, как user_id хранится в вашей таблице с данными из первых рук, вам может потребоваться закодировать значения в таблице перед сопоставлением данных. Для успешного сопоставления необходимо преобразовать ключ объединения в байты:

JOIN ON
  adh.google_ads_impressions_match.external_cookie = CAST(my_data.user_id AS BYTES)

Кроме того, сравнение строк в SQL чувствительно к регистру символов, поэтому вам может потребоваться закодировать строки с обеих сторон сравнения, чтобы обеспечить их точное сравнение.

Кодирование идентификаторов пользователей

Кодирование идентификаторов пользователей на стороне клиента.

Для обеспечения безопасной передачи различных форматов идентификаторов по URL-адресу все идентификаторы должны быть закодированы в Base64, безопасном для использования в URL-адресах , перед отправкой. Закодированный в Base64 идентификатор будет доступен в Ads Data Hub в поле external_cookie , поэтому вам потребуется отменить все преобразования, примененные перед кодированием, чтобы получить исходный идентификатор.

Если ваш идентификатор всегда состоит из 24 символов (или байтов) или меньше, вы можете включить в пиксель безопасный для URL-адресов идентификатор, закодированный в Base64, как показано в примере 1. Если ваш идентификатор превышает 24 символа (или байта), вам потребуется преобразовать его в представление размером 24 байта или меньше. В некоторых случаях (например, GUID в примере 2) достаточно преобразования в байтовое представление. В других случаях вам может потребоваться отправить Google подмножество (или хеш) вашего идентификатора. Обратите внимание, что в любом случае вам необходимо убедиться, что вы можете написать SQL-запрос JOIN, который преобразует идентификатор в вашей таблице данных таким же образом.

Пример 1

Значение вашего идентификатора пользователя всегда будет меньше 24-байтового ограничения. Ads Data Hub рекомендует просто отправлять ваш идентификатор пользователя напрямую в ADH (предварительно закодировав его в безопасный для URL-адресов формат Base64 для целей передачи по URL).

var userId = 'abcdef123456789';
// Encode the string (or number) in normal base64.
var userIdBase64 = btoa(userId);

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_')
    .replace(/=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);
Пример 2

В качестве идентификатора пользователя присваивается универсальный уникальный идентификатор (UUID), например: 123e4567-e89b-12d3-a456-426655440000 .

Ads Data Hub рекомендует следующие преобразования при сопоставлении:

  1. UUID имеет формат 36-символьной строки.
  2. Декодирование UUID в шестнадцатеричном формате.
  3. UUID форматируется в байты.
  4. Безопасное для URL-адресов кодирование байтов в формате Base64.
  5. UUID форматируется как строка.

Это можно реализовать с помощью следующего кода:

JavaScript

var userId = '123e4567-e89b-12d3-a456-426655440000';

// A helper function for converting a hex string to a byte array.
function strToBytes(str) {
        for (var bytes = [], i = 0; i < str.length; i += 2) {
          bytes.push(parseInt(str.substr(i, 2), 16));
        }
        return bytes;
}

// Remove the formatting dashes from the UUID.
userId = userId.replace(/-/g, '');

// Encode the hex string as a byte array.
var userIdBytes = strToBytes(userId);

// Encode the byte array in normal base64.
var userIdBase64 = btoa(String.fromCharCode(...new Uint8Array(userIdBytes)));

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_').replace(
    /=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);

Python

import base64

user_id = '123e4567-e89b-12d3-a456-426655440000'
user_id_as_bytes = bytes.fromhex(user_id.replace('-', ''))
base64.urlsafe_b64encode(user_id_as_bytes)

Если найдено совпадение с идентификатором пользователя Google, поле external_cookie будет содержать ваш идентификатор в виде байтового значения. Для восстановления исходного идентификатора требуется следующее преобразование:

  1. external_cookie имеет формат байтов.
  2. Hexadecimal encode external_cookie .
  3. Параметр external_cookie имеет строковый формат.

Внесите идентификаторы пользователей в Центр данных рекламы.

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

В следующем примере показано, как закодировать ваш UUID и связать его с полем внешнего cookie-файла:

JOIN my_data ON imp.external_cookie = FROM_HEX(REPLACE(my_data.uuid, '-', ''))

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

JOIN my_data ON imp.external_cookie = CAST(CAST(my_data.user_id AS STRING) AS BYTES)

Помните, что кодировка, необходимая для сопоставления ваших данных, будет зависеть от способа их хранения и от того, как вы закодировали их перед отправкой в ​​Ads Data Hub.

Узнайте больше о строковых функциях в BigQuery SQL .

Пример запроса

В следующем примере данные из первых рук объединяются с google_ads_impressions_match , а затем эти результаты объединяются с adh_google_ads_impressions во втором запросе.

SELECT
  imp.campaign_id as campaign_id,
  sum(my_data.recent_orders) as orders,
  average(my_data.lifetime_value) as ltv
FROM
  adh.google_ads_impressions_match as imp
LEFT JOIN
  my_data ON imp.external_cookie = my_data.company_guest_id_bytes
GROUP BY
  campaign_id

Сохранив результаты предыдущего запроса в previous_results , теперь вы можете объединить их с google_ads_impressions . Это добавит в результаты данные по кампаниям с 0 показами.

SELECT
  campaign_id,
  COALESCE(orders, 0) as orders,
  COALESCE(ltv, 0) as ltv,
FROM (SELECT DISTINCT campaign_id
   FROM adh.google_ads_impressions)
LEFT JOIN previous_results USING (campaign_id)

  1. Пример: 20% совпадений фактически означает, что для достижения порога агрегации в 50 пользователей вам потребуется 250 пользователей в каждой строке, так как 50 / 0,2 = 250.

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