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

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

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

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

Для кого эта статья?

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

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

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

Обзор

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

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

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

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

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

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

Дизайнерские решения

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

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

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

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

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

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

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

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

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

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

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

   

3. Позже пользователь посещает сайт рекламодателя.

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

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

6. Браузер на локальном устройстве пользователя получает этот ответ и сопоставляет данные о конверсиях с исходным исходным событием (клик по объявлению или просмотр). Узнайте больше в разделе «Сопоставление источников с триггерами».

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

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

   

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

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

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

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

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

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

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

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

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

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

Сбор данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Служба агрегации

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

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

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

Что дальше?

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

Обсудить API

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

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

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