Отчеты по атрибуции: создание сводных отчетов

Измеряйте совокупные рекламные конверсии среди пользователей, не раскрывая отдельные данные. Ранее известный как сводные отчеты.

Статус реализации

Что такое сводный отчет Отчета об атрибуции?

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

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

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

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

Зачем нужны сводные отчеты?

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

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

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

В отличие от сторонних файлов cookie, типы отчетов из API Attribution Reporting API не позволяют каким-либо субъектам (например, рекламным технологиям, покупателям, издателям и т. д.) «видеть» поведение пользователя при просмотре на нескольких сайтах, но при этом позволяют измерить конверсии рекламы.

Как собираются и агрегируются пользовательские данные?

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

Процесс создания сводного отчета выглядит следующим образом:

  1. Агрегированные отчеты отправляются в источник отчетов , которым управляет поставщик рекламных технологий.
    • Эти отчеты могут включать сведения о местоположении, количестве кликов, ценности конверсии (например, цене покупки) или другие показатели, определенные поставщиком рекламных технологий. Отчеты зашифрованы, поэтому специалисты по рекламе не могут видеть или получать доступ к содержимому какого-либо отдельного отчета.
  2. Как только поставщик отчетов по рекламным технологиям получает агрегированные отчеты, он отправляет их в службу агрегирования .
    • В нашей первоначальной реализации служба агрегации управляется поставщиком рекламных технологий с доверенной средой выполнения (TEE), размещенной в облаке. Координатор гарантирует, что только проверенные лица имеют доступ к ключам дешифрования и что никакой другой посредник (рекламная технология, поставщик облачных услуг или любая другая сторона) не может получить доступ и расшифровать конфиденциальные данные вне процесса агрегирования.
  3. Служба агрегации объединяет расшифрованные данные и выдает сводный отчет поставщику рекламных технологий.
    • Сводный отчет включает сводку объединенных данных. Поставщик рекламных технологий может читать и использовать сводный отчет.
Процесс создания сводного отчета представляет собой зашифрованные отчеты, отправляемые на сервер-сборщик. Сервер-сборщик отправляет данные в безопасную службу агрегирования, у которой есть ключ для расшифровки данных и создания сводного отчета. Затем отчет отправляется обратно поставщику рекламных технологий.
Полную диаграмму последовательности см. в разделе «Введение в отчеты по атрибуции» .

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

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

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

Создание отчетов с помощью службы агрегирования

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

Код TEE — единственное место в службе агрегации, имеющее доступ к необработанным отчетам. Этот код будет проверяться исследователями безопасности, защитниками конфиденциальности и специалистами по рекламе. Чтобы подтвердить, что TEE использует именно утвержденное программное обеспечение и что данные остаются в безопасности, координатор проводит аттестацию.

У координатора есть несколько обязанностей:

  • Ведите список разрешенных бинарных изображений. Эти изображения представляют собой криптографические хэши сборок программного обеспечения службы агрегации, которые Google периодически выпускает. Это будет воспроизводимо, чтобы любая сторона могла убедиться, что изображения идентичны сборкам службы агрегации.
  • Используйте систему управления ключами. Ключи шифрования необходимы Chrome на устройстве пользователя для шифрования сводных отчетов. Ключи расшифровки необходимы для подтверждения соответствия кода службы агрегации двоичным изображениям.
  • Отслеживайте агрегированные отчеты, чтобы предотвратить повторное использование при агрегировании сводных отчетов, поскольку повторное использование может раскрыть личную информацию (PII).

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

Какая информация фиксируется?

Сводные отчеты предлагают сочетание агрегированных данных с подробными данными о рекламе и конверсиях.

Например, поставщик рекламных технологий запускает рекламную кампанию на news.example , где конверсия представляет собой нажатие пользователем рекламы обуви и совершение покупки обуви на сайте shoes.example . Рекламный технический специалист получает сводный отчет по этой рекламной кампании с идентификатором 1234567 , в котором указано, что на 12 января 2022 года было совершено 518 конверсий по обуви.пример с общими расходами 38 174 долларов США . 60 % конверсий пришлось на пользователей, купивших синие кроссовки с артикулом 9872 , а 40 % — на пользователей, купивших желтые сандалии с артикулом 2643 . Идентификатор кампании представляет собой подробные данные о рекламе, а SKU продукта — это подробные данные о конверсиях. Количество конверсий и общие расходы представляют собой агрегированные данные.

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

Как данные браузера собираются перед агрегированием?

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

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

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

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

Фильтрация идентификаторов

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

Диаграмма АРА

Имейте в виду, что все значения должны быть отформатированы как строки и чувствительны к регистру. Вы должны ответить метаданными триггера атрибуции в HTTP-заголовке Attribution-Reporting-Register-Trigger . Для начала мы рекомендуем следующее:

   app.get('/register-trigger', async (req, res) => {
      
      res.setHeader('Attribution-Reporting-Register-Trigger',
         JSON.stringify({
               "filtering_id_max_bytes": 1
               "aggregatable_trigger_data": [{
                     "key_piece": "0x400",
                     "source_keys": ["campaignCounts"]
               }],
               "aggregatable_values": {
                     "campaignCounts": { "value": 32768, "filtering_id": "1" }
               }
         })
      );
      res.sendStatus(200);
      
   });

Агрегированные отчеты будут отправляться туда, где вы определили конечную точку /.well-known/attribution-reporting/report-aggregate-attribution . После того как пакеты ваших агрегированных отчетов будут отправлены в вашу службу агрегирования и обработаны, отфильтрованные результаты должны быть отражены в окончательном сводном отчете.

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

Создать сводный отчет

Чтобы поставщики рекламных технологий могли получить сводный отчет, необходимо предпринять следующие шаги:

  1. Рекламная технология собирает агрегированные отчеты из браузеров отдельных пользователей.
  2. Поставщик рекламных технологий группирует агрегированные отчеты и отправляет их в службу агрегирования.
  3. Служба агрегации назначает исполнителя для агрегирования данных.
  4. Работник агрегации расшифровывает и агрегирует данные из агрегируемых отчетов вместе с зашумленными данными (механизм конфиденциальности данных).
  5. Служба агрегирования возвращает сводный отчет поставщику рекламных технологий.

Рекламный технический специалист может использовать сводный отчет для информирования о торгах и предоставления отчетов своим клиентам. Схема в формате JSON — это формат сводных отчетов.

Привлекайте и делитесь отзывами

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

Узнать больше