На высоком уровне сопоставление файлов 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. Низкий коэффициент соответствия в сочетании с редкими посещениями вашего домена может привести к трудностям с получением данных. Это происходит из-за совокупного эффекта коэффициентов совпадения и требований агрегирования 1 .
- В соответствии с политикой Google в отношении конфиденциальности конечных пользователей вы:
- Запрещено сопоставлять данные для входа и выхода данного пользователя.
- Невозможно сопоставить данные с пользователями, которые отказались от персонализации рекламы.
- Для событий iOS вы можете сопоставлять данные, полученные из приложений на iOS 14.5+ от пользователей, которые предоставили разрешение в рамках прозрачности отслеживания приложений Apple.
Подтверждение согласия первой стороны
Чтобы гарантировать, что вы можете использовать свои собственные данные в 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.
Пошаговый обзор
- Пользователь посещает страницу с тегом соответствия.
- Тег соответствия инициирует серию перенаправлений на Google Платформу для маркетинга, Google Рекламу и службы сопоставления YouTube. Запросы содержат идентификатор этого пользователя или файл cookie с вашего веб-сайта, а также файл cookie Google в каждом из полей идентификатора соответствующей службы.
- Прозрачный пиксель размером 1х1 возвращается в браузер для подтверждения выполнения запроса.
Этот процесс показан на следующей схеме:
Настраивать
Процесс настройки сопоставления файлов cookie в Ads Data Hub выглядит следующим образом:
- Свяжитесь с представителем вашего аккаунта и сообщите о своей заинтересованности в сопоставлении файлов cookie. Они обсудят ваши цели и предоставят дополнительную информацию о развертывании пикселя отслеживания в вашем домене.
- Специалисты Ads Data Hub инициируют еще одну беседу, чтобы обсудить технические требования и варианты использования.
- Пока вы развертываете пиксель отслеживания и конечную точку ошибки, Google создаст таблицы соответствия.
После выполнения этих действий никаких немедленных действий не требуется. Google будет заполнять ваши таблицы соответствия ежедневно 2 , поэтому вам потребуется некоторое время, прежде чем ваша таблица будет содержать достаточно данных, чтобы обеспечить значимые совпадения и соответствовать требованиям агрегирования. Это зависит от частоты, с которой пользователи посещают ваш сайт; сайт с ежедневными посетителями достигнет этой точки гораздо быстрее, чем сайт с ежемесячными посетителями. Поскольку новое количество совпадений замедляется, ваши таблицы совпадений будут содержать более полные данные.
Запрос таблиц соответствия
Когда ваши таблицы соответствий содержат достаточно данных для проверки конфиденциальности, вы готовы выполнять запросы к таблицам.
Исходная таблица для собственных данных (1PD) представлена my_data . Сюда входят как личная информация (PII), так и данные, не относящиеся к 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_youtube Ads Data Hub также создает таблицу соответствия adh.google_ads_impressions_policy_isolated_youtube_match содержащую ваши идентификаторы пользователей.
Эти таблицы содержат подмножество пользователей, доступных в исходных таблицах, где есть совпадение по user_id . Например, если исходная таблица содержит данные для пользователя A и пользователя B, но сопоставляется только пользователь A, то пользователя B не будет в таблице соответствия.
Таблицы соответствия содержат дополнительный столбец с именем external_cookie , в котором хранится идентификатор пользователя в формате BYTES.
При написании запросов важно учитывать тип поля. Операторы сравнения SQL ожидают, что сравниваемые литералы будут одного и того же типа. В зависимости от того, как user_id хранится в вашей таблице собственных данных, вам может потребоваться закодировать значения в таблице перед сопоставлением данных. Для успешного сопоставления вам необходимо преобразовать ключ соединения в BYTES:
JOIN ON
adh.google_ads_impressions_match.external_cookie = CAST(my_data.user_id AS BYTES)
Кроме того, сравнения строк в SQL чувствительны к использованию заглавных букв, поэтому вам может потребоваться закодировать строки с обеих сторон сравнения, чтобы обеспечить их точное сравнение.
Кодирование идентификаторов пользователей
Кодирование идентификаторов пользователей на стороне клиента
Чтобы обеспечить безопасную передачу различных форматов идентификаторов через 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 рекомендует при сопоставлении выполнять следующие преобразования:
- UUID форматируется как строка из 36 символов.
- Шестнадцатеричное декодирование UUID.
- UUID форматируется в байтах.
- URL-безопасные байты кодирования Base64.
- 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 содержит ваш идентификатор в виде байтового значения. Чтобы восстановить исходный идентификатор, требуется следующее преобразование:
-
external_cookieформатируется как байты. - Шестнадцатеричное кодирование
external_cookie. -
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 . Это добавит к вашим результатам данные о кампаниях с 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)
Пример: коэффициент совпадения 20% фактически означает, что вам нужно 250 пользователей в каждой строке, чтобы достичь порога агрегации в 50 пользователей, так как 50 / 0,2 = 250. ↩
Матчи, сделанные в определенный день, могут появиться с задержкой до 48 часов, прежде чем они появятся в ваших таблицах. ↩
На высоком уровне сопоставление файлов 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. Низкий коэффициент соответствия в сочетании с редкими посещениями вашего домена может привести к трудностям с получением данных. Это происходит из-за совокупного эффекта коэффициентов совпадения и требований агрегирования 1 .
- В соответствии с политикой Google в отношении конфиденциальности конечных пользователей вы:
- Запрещено сопоставлять данные для входа и выхода данного пользователя.
- Невозможно сопоставить данные с пользователями, которые отказались от персонализации рекламы.
- Для событий iOS вы можете сопоставлять данные, полученные из приложений на iOS 14.5+ от пользователей, которые предоставили разрешение в рамках прозрачности отслеживания приложений Apple.
Подтверждение согласия первой стороны
Чтобы гарантировать, что вы можете использовать свои собственные данные в 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.
Пошаговый обзор
- Пользователь посещает страницу с тегом соответствия.
- Тег соответствия инициирует серию перенаправлений на Google Платформу для маркетинга, Google Рекламу и службы сопоставления YouTube. Запросы содержат идентификатор этого пользователя или файл cookie с вашего веб-сайта, а также файл cookie Google в каждом из полей идентификатора соответствующей службы.
- Прозрачный пиксель размером 1x1 возвращается в браузер для подтверждения выполнения запроса.
Этот процесс показан на следующей схеме:
Настраивать
Процесс настройки сопоставления файлов cookie в Ads Data Hub выглядит следующим образом:
- Свяжитесь с представителем вашего аккаунта и сообщите о своей заинтересованности в сопоставлении файлов cookie. Они обсудят ваши цели и предоставят дополнительную информацию о развертывании пикселя отслеживания в вашем домене.
- Специалисты Ads Data Hub инициируют еще одну беседу, чтобы обсудить технические требования и варианты использования.
- Пока вы развертываете пиксель отслеживания и конечную точку ошибки, Google создаст таблицы соответствия.
После выполнения этих действий никаких немедленных действий не требуется. Google будет заполнять ваши таблицы соответствия ежедневно 2 , поэтому вам потребуется некоторое время, прежде чем ваша таблица будет содержать достаточно данных, чтобы обеспечить значимые совпадения и соответствовать требованиям агрегирования. Это зависит от частоты, с которой пользователи посещают ваш сайт; сайт с ежедневными посетителями достигнет этой точки гораздо быстрее, чем сайт с ежемесячными посетителями. Поскольку новое количество совпадений замедляется, ваши таблицы совпадений будут содержать более полные данные.
Запрос таблиц соответствия
Когда ваши таблицы соответствий содержат достаточно данных для проверки конфиденциальности, вы готовы выполнять запросы к таблицам.
Исходная таблица для собственных данных (1PD) представлена my_data . Сюда входят как информация, позволяющая установить личность (PII), так и данные, не относящиеся к 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_youtube Ads Data Hub также создает таблицу соответствия adh.google_ads_impressions_policy_isolated_youtube_match содержащую ваши идентификаторы пользователей.
Эти таблицы содержат подмножество пользователей, доступных в исходных таблицах, где есть совпадение по user_id . Например, если исходная таблица содержит данные для пользователя A и пользователя B, но сопоставляется только пользователь A, то пользователя B не будет в таблице соответствия.
Таблицы соответствия содержат дополнительный столбец с именем external_cookie , в котором хранится идентификатор пользователя в формате BYTES.
При написании запросов важно учитывать тип поля. Операторы сравнения SQL ожидают, что сравниваемые литералы будут одного и того же типа. В зависимости от того, как user_id хранится в вашей таблице собственных данных, вам может потребоваться закодировать значения в таблице перед сопоставлением данных. Для успешного сопоставления вам необходимо преобразовать ключ соединения в BYTES:
JOIN ON
adh.google_ads_impressions_match.external_cookie = CAST(my_data.user_id AS BYTES)
Кроме того, сравнения строк в SQL чувствительны к использованию заглавных букв, поэтому вам может потребоваться закодировать строки с обеих сторон сравнения, чтобы обеспечить их точное сравнение.
Кодирование идентификаторов пользователей
Кодирование идентификаторов пользователей на стороне клиента
Чтобы обеспечить безопасную передачу различных форматов идентификаторов через 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 рекомендует при сопоставлении выполнять следующие преобразования:
- UUID форматируется как строка из 36 символов.
- Шестнадцатеричное декодирование UUID.
- UUID форматируется в байтах.
- URL-безопасные байты кодирования Base64.
- 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 содержит ваш идентификатор в виде байтового значения. Чтобы восстановить исходный идентификатор, требуется следующее преобразование:
-
external_cookieформатируется как байты. - Шестнадцатеричное кодирование
external_cookie. -
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 . Это добавит к вашим результатам данные о кампаниях с 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)
Пример: коэффициент совпадения 20% фактически означает, что вам нужно 250 пользователей в каждой строке, чтобы достичь порога агрегации в 50 пользователей, так как 50 / 0,2 = 250. ↩
Матчи, сделанные в определенный день, могут появиться с задержкой до 48 часов, прежде чем они появятся в ваших таблицах. ↩