Отчеты по атрибуции: полный обзор системы

Общий обзор подключенных сервисов для Attribution Reporting, предназначенный для лиц, принимающих технические решения.

API Attribution Reporting позволяет рекламодателям и техническим специалистам по рекламе измерять, когда клик или просмотр рекламы приводит к конверсии, например покупке. Этот API использует комбинацию клиентской и серверной интеграции в зависимости от потребностей вашего бизнеса.

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

Для кого предназначен этот документ?

Вам следует прочитать этот документ, если:

  • Вы рекламный техник или лицо, принимающее технические решения рекламодателя. Вы можете работать в сфере операций, DevOps, науки о данных, ИТ, маркетинга или другой роли, где вы принимаете технические решения по внедрению. Вам интересно, как API работают для измерения с сохранением конфиденциальности.
  • Вы — технический специалист (например, разработчик, системный оператор, системный архитектор или специалист по обработке данных), который будет проводить эксперименты с этим API и средой службы агрегации.

В этом документе вы прочтете высокоуровневое, сквозное объяснение того, как работают службы для API Attribution Reporting. Если вы технический специалист, вы можете поэкспериментировать с этим API локально.

Обзор

API Attribution Reporting состоит из множества служб, которые требуют определенной настройки, конфигураций на стороне клиента и развертываний сервера. Чтобы определить, что вам нужно, сначала:

  • Примите решения по дизайну . Определите, какую информацию вы хотите собирать, определите, какие конверсии вы ожидаете от любой данной кампании, и определите, какой тип отчета собирать. Конечный результат — один или оба из двух типов отчетов: отчеты на уровне событий и сводные отчеты.

Всегда есть два (а иногда и три) компонента, которые работают вместе, поддерживая отчетность:

  • Связь веб-сайта с браузером . В системах на основе файлов cookie информация о конверсиях и рекламных взаимодействиях прикрепляется к идентификатору, который позволяет вам или аналитической службе присоединиться к этим событиям позже. С помощью этого API браузер связывает конверсии с кликами/просмотрами рекламы на основе ваших инструкций, прежде чем они будут доставлены для анализа. Поэтому ваш код рендеринга рекламы и отслеживания конверсий должны:
    • Сообщите браузеру, какие конверсии следует приписывать тем или иным кликам или показам объявлений.
    • Сообщите о любых других данных для включения в окончательные отчеты.
  • Сбор данных . Вам понадобится конечная точка коллектора для получения отчетов, сгенерированных в браузерах пользователей. Выходные данные браузеров могут быть одним из двух возможных отчетов: отчеты на уровне событий и агрегированные отчеты (которые зашифрованы и используются для генерации сводных отчетов).

Если вы собираете агрегированные отчеты, вам понадобится третий компонент:

  • Генерация сводного отчета . Пакетная агрегация отчетов и использование службы агрегации для обработки отчетов с целью создания сводного отчета.

Проектные решения

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

Выходной отчет может быть:

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

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

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

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

Связь веб-сайта с браузером

Источники атрибуции на сайте издателя связываются с триггерами на сайте рекламодателя.
Источники атрибуции на сайте издателя связываются с триггерами на сайте рекламодателя.

Поток событий атрибуции

Представьте себе сайт издателя, который показывает рекламу. Каждый рекламодатель или поставщик рекламных технологий хочет узнать о взаимодействии со своими объявлениями и приписать конверсии правильному объявлению. Отчеты (как на уровне событий, так и агрегированные) будут генерироваться следующим образом:

  1. На сайте издателя элемент объявления (тег <a> или <img> ) настраивается с помощью специального атрибута attributionsrc . Его значением является URL, например https://adtech.example/register-source/ad_id=... .

    Вот пример ссылки, которая регистрирует источник после нажатия:

    <a href="https://shoes.example/landing"
  attributionsrc="http://adtech.example/register-source?..."
  target="_blank">
Click me</a>

    Вот пример изображения, при просмотре которого будет происходить регистрация источника:

    <img href="https://advertiser.example/landing"
  attributionsrc="https://adtech.example/register-source?..."/>

    В качестве альтернативы вместо HTML-элементов можно использовать вызовы JavaScript.

    Вот пример JavaScript с использованием window.open() . Обратите внимание, что URL-адрес закодирован в URL-коде, чтобы избежать проблем со специальными символами.

    const encodedUrl = encodeURIComponent(
  'https://adtech.example/attribution_source?ad_id=...');
window.open(
  "https://shoes.example/landing",
  "_blank",
  `attributionsrc=${encodedUrl}`);

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

  3. Получив этот запрос, рекламодатель или поставщик рекламных технологий решает поручить браузеру зарегистрировать исходные события для взаимодействия с рекламой, чтобы впоследствии конверсии можно было приписать этой рекламе. Для этого рекламодатель или поставщик рекламных технологий включает в свой ответ специальный заголовок HTTP. Он прикрепляет к этому заголовку пользовательские данные, которые предоставляют информацию об исходном событии (клик по рекламе или просмотр) — если конверсия в конечном итоге произойдет для этой рекламы, эти пользовательские данные в конечном итоге будут отображены в отчете об атрибуции.

    Просмотрите или нажмите на объявление.

  4. Далее пользователь заходит на сайт рекламодателя.

  5. На каждой релевантной странице сайта рекламодателя, например, на странице подтверждения покупки или на странице продукта, пиксель конверсии (элемент <img> ) или вызов JavaScript отправляет запрос на https://adtech.example/conversion?param1=...&param2=... .

  6. Служба по этому URL-адресу — обычно рекламодатель или поставщик рекламных технологий — получает запрос. Он решает классифицировать это как конверсию, поэтому ему нужно дать указание браузеру записать конверсию — то есть запустить атрибуцию . Для этого рекламодатель или поставщик рекламных технологий включает в свой ответ на запрос пикселя специальный заголовок HTTP, который содержит пользовательские данные о конверсии.

  7. Браузер на локальном устройстве пользователя получает этот ответ и сопоставляет данные о конверсии с исходным исходным событием (клик по объявлению или просмотр).

  8. Браузер планирует отправку отчета в attributionsrc . Этот отчет включает в себя:

    1. Данные конфигурации пользовательской атрибуции, которые поставщик рекламных технологий или рекламодатель прикрепил к исходному событию на шаге 3.
    2. Пользовательский набор данных конверсии на шаге 6.
    На схеме показаны элементы запуска отчетов по атрибуции, приводящие к созданию отчетов на уровне событий и агрегированных отчетов.
    На схеме показаны элементы запуска отчетов по атрибуции, приводящие к созданию отчетов на уровне событий и агрегированных отчетов.

  9. Позже браузер отправляет отчеты в конечную точку, определенную в attributionsrc , с некоторой задержкой и шумом. Агрегируемые отчеты зашифрованы, а отчеты на уровне событий — нет.

Триггеры атрибуции (сайт рекламодателя)

Триггер атрибуции — это событие, которое сообщает браузеру о необходимости фиксировать конверсии.

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

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

Сопоставьте источники с триггерами

Когда браузер получает ответ триггера атрибуции, он обращается к локальному хранилищу, чтобы найти источник, который соответствует как источнику триггера атрибуции, так и URL-адресу eTLD+1 этой страницы.

Например, когда браузер получает триггер атрибуции от adtech.example на shoes.example/shoes123 , браузер ищет источник в локальном хранилище, который соответствует как adtech.example , так и shoes.example .

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

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

Сбор данных

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

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

Отчеты на уровне событий задерживаются на срок от 2 до 30 дней. Агрегированные отчеты отправляются со случайной задержкой в ​​течение одного часа, а события должны соответствовать бюджету взносов . Эти варианты защищают конфиденциальность и предотвращают эксплуатацию действий любого отдельного пользователя.

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

Формирование сводного отчета

Для создания сводных отчетов вы будете использовать Aggregation Service (управляемый рекламным техником) для обработки агрегируемых отчетов. Aggregation Service добавляет шум для защиты конфиденциальности пользователя и возвращает окончательный сводный отчет.

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

После пакетирования собранных агрегируемых отчетов пакет обрабатывается Aggregation Service. Координатор выдает ключи дешифрования только аттестованным версиям Aggregation Service. Затем Aggregation Service расшифровывает данные, агрегирует их и добавляет шум перед возвратом результатов в виде сводного отчета.

Пакетные агрегируемые отчеты

Перед обработкой агрегируемых отчетов их необходимо объединить в пакет. Пакет состоит из стратегически сгруппированных агрегируемых отчетов. Ваша стратегия, скорее всего, будет отражать определенный период времени (например, ежедневно или еженедельно). Этот процесс может происходить на том же сервере, который выступает в качестве конечной точки отчетности.

Пакеты должны содержать много отчетов, чтобы обеспечить высокое соотношение сигнал/шум.

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

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

Агрегация услуг

Служба агрегации отвечает за обработку агрегируемых отчетов для создания сводного отчета. Агрегируемые отчеты зашифрованы и могут быть прочитаны только службой агрегации, которая работает в доверенной среде выполнения (TEE).

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

Практики могут генерировать агрегируемые текстовые отчеты для локального тестирования Aggregation Service . Или вы можете протестировать зашифрованные отчеты на AWS с Nitro Enclaves .

Что дальше?

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

Обсудить API

Как и другие API Privacy Sandbox, этот API документирован и обсуждается публично .

Эксперимент с API

Вы можете экспериментировать и участвовать в обсуждении API Attribution Reporting.