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

Важно: Сопоставление файлов cookie больше не поддерживается при подключении к Ads Data Hub. Существующие конфигурации, включающие сопоставление файлов 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+ от пользователей, которые предоставили разрешение в соответствии с фреймворком App Tracking Transparency компании Apple.

Подтверждение согласия первой стороны

Внимание: Неподтверждение согласия или отказ от его подтверждения приводит к невозможности использования ваших собственных данных (1PD) в Ads Data Hub. Например, вы не сможете добавить новые 1PD или объединить существующие 1PD со связанными рекламными данными. Все варианты использования, такие как сопоставление предоставленных пользователями данных и активация аудитории с помощью 1PD, недоступны. Это включает в себя любой запланированный импорт 1PD.

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

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

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

Как работает сопоставление файлов cookie

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

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

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

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

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

1. Пользователь посещает страницу с тегом соответствия.
2. Тег сопоставления инициирует серию перенаправлений на сервисы сопоставления 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), так и данные, не относящиеся к PII. Использование исходной таблицы может улучшить ваши отчёты и сделать их более информативными, поскольку она представляет все данные первой стороны в области охвата, по сравнению с таблицей соответствий.

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

Внимание: в связи с правилами ЕС UPDM больше недоступен для несетевых таблиц, изолированных от политик, таких как adh.google_ads_impressions_policy_isolated_youtube . Чтобы продолжить выполнение этих запросов, удалите _policy_isolated_youtube , чтобы ограничить доступ только пользователями с согласия.

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

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

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

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

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

Примечание: сравнение байтов и строк неявно кодирует байты в формате Base64.

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

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

Для обеспечения безопасной передачи идентификаторов различных форматов по URL-адресу все идентификаторы должны быть закодированы в формате Base64 для URL-адресов перед отправкой. Раскодированный в формате Base64 для URL-адресов идентификатор будет доступен в 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. Байты кодирования Base64, безопасные для URL.
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);

Питон

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. Шестнадцатеричное кодирование external_cookie .
3. external_cookie отформатирован как строка.

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

Если вы храните строку 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 . Это добавит данные о кампаниях с нулевым количеством показов в ваши результаты.

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 / .2 = 250. ↩

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