Отчеты по атрибуции для обзора мобильных устройств

Последние обновления

Обзор

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

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

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

API отчетов об атрибуции поддерживает следующие варианты использования:

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

На высоком уровне API Attribution Reporting работает следующим образом, что более подробно описано в последующих разделах этого документа:

  1. Специалист по рекламе завершает процесс регистрации для использования API Attribution Reporting.
  2. Рекламная технология регистрирует источники атрибуции — клики по рекламе или просмотры — с помощью API отчетов об атрибуции.
  3. Рекламная технология регистрирует триггеры — конверсии пользователей в приложении или на веб-сайте рекламодателя — с помощью API отчетов об атрибуции.
  4. API отчетов об атрибуции сопоставляет триггеры с источниками атрибуции (атрибуция конверсии), и один или несколько триггеров отправляются с устройства через отчеты на уровне событий и агрегированные отчеты рекламным специалистам.

Получите доступ к API-интерфейсам отчетов об атрибуции

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

Зарегистрируйте источник атрибуции (нажмите или просмотрите)

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

  • URI источника атрибуции: платформа отправляет запрос на этот URI, чтобы получить метаданные, связанные с источником атрибуции.
  • Событие ввода: объект InputEvent (для события щелчка) или null (для события просмотра).

Когда API делает запрос к URI источника атрибуции, рекламный техник должен ответить метаданными источника атрибуции в новом HTTP-заголовке Attribution-Reporting-Register-Source со следующими полями:

  • Идентификатор события источника : это значение представляет данные уровня события, связанные с этим источником атрибуции (клик по объявлению или просмотр). Должно быть 64-битным целым числом без знака, отформатированным как строка.
  • Назначение : источник, eTLD+1 или имя пакета приложения которого, где происходит событие-триггер.
  • Срок действия (необязательно) : срок действия в секундах, по истечении которого источник должен быть удален с устройства. По умолчанию — 30 дней, минимальное значение — 1 день, максимальное — 30 дней. Округляется до ближайшего дня. Может быть отформатирован как 64-битное целое число без знака или строка.
  • Окно отчета о событиях (необязательно) : Длительность в секундах после регистрации источника, в течение которой для этого источника могут быть созданы отчеты о событиях. Если окно отчета о событиях прошло, но срок действия еще не истек, триггер все еще может быть сопоставлен с источником, но отчет о событиях для этого триггера не отправляется. Не может быть больше, чем Expiry. Может быть отформатирован как 64-битное целое число без знака или строка.
  • Окно агрегируемого отчета (необязательно) : Длительность в секундах после регистрации источника, в течение которой для этого источника могут быть созданы агрегируемые отчеты. Не может быть больше, чем Expiry. Может быть отформатировано как 64-битное целое число без знака или строка.
  • Приоритет источника (необязательно) : используется для выбора источника атрибуции, с которым должен быть связан данный триггер, в случае, если с триггером могут быть связаны несколько источников атрибуции. Должно быть 64-битным целым числом со знаком, отформатированным как строка.

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

    Более высокие значения указывают на более высокие приоритеты.
  • Окна атрибуции установки и послеустановки (необязательно): используются для определения атрибуции для событий после установки , описанных далее на этой странице.
  • Фильтр данных (необязательно): используется для выборочной фильтрации некоторых триггеров, фактически игнорируя их. Для получения более подробной информации см. раздел Фильтры триггеров на этой странице.
  • Ключи агрегации (необязательно): укажите сегментацию , которая будет использоваться для агрегируемых отчетов .

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

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

Следующие шаги показывают пример рабочего процесса:

  1. SDK рекламных технологий вызывает API для инициирования регистрации источника атрибуции, указывая URI для вызова API:

    registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);

  2. API делает запрос к https://adtech.example/attribution_source? AD_TECH_PROVIDED_METADATA , используя один из следующих заголовков:

    <!-- For click events -->
Attribution-Reporting-Source-Info: navigation

<!-- For view events -->
Attribution-Reporting-Source-Info: event

  3. HTTPS-сервер этой рекламной технологии отвечает заголовками, содержащими следующее:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

  4. API делает запрос к каждому URL, указанному в Attribution-Reporting-Redirect . В этом примере указаны два URL-адреса партнеров по рекламным технологиям, поэтому API делает один запрос к https://adtechpartner1.example?their_ad_click_id=567 и другой запрос к https://adtechpartner2.example?their_ad_click_id=890 .

  5. HTTPS-сервер этой рекламной технологии отвечает заголовками, содержащими следующее:

    Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}

На основе запросов, показанных на предыдущих этапах, регистрируются три источника атрибуции навигации (кликов).

Регистрация источника атрибуции из WebView

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

Поскольку рекламные технологии используют общий код в Web и WebView, WebView следует перенаправлениям HTTP 302 и передает действительные регистрации на платформу. Мы не планируем поддерживать заголовок Attribution-Reporting-Redirect для этого сценария, но свяжитесь с нами, если у вас есть затронутый вариант использования.

Регистрация триггера (конверсии)

Платформы рекламных технологий могут регистрировать триггеры — конверсии, такие как установки или события после установки, — с помощью метода registerTrigger() .

Метод registerTrigger() ожидает параметр Trigger URI . API отправляет запрос на этот URI для извлечения метаданных, связанных с триггером.

API следует перенаправлениям. Ответ сервера ad tech должен включать HTTP-заголовок Attribution-Reporting-Register-Trigger , который представляет информацию об одном или нескольких зарегистрированных триггерах. Содержимое заголовка должно быть закодировано в формате JSON и включать следующие поля:

  • Данные триггера: данные для идентификации события триггера (3 бита для кликов, 1 бит для просмотров). Должны быть 64-битным целым числом со знаком, отформатированным как строка.

  • Приоритет триггера (необязательно): представляет приоритет этого триггера по сравнению с другими триггерами для того же источника атрибуции. Должен быть 64-битным целым числом со знаком, отформатированным как строка. Более подробную информацию о том, как приоритет влияет на отчетность, см. в разделе «Приоритезация» .

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

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

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

  • Фильтры (необязательно): используются для выборочной фильтрации триггеров или данных триггеров. Для получения более подробной информации см. раздел «Фильтры триггеров» на этой странице.

При желании ответ сервера ad tech может включать дополнительные данные в заголовке Attribution Reporting Redirects . Данные содержат URL-адреса перенаправления, которые позволяют нескольким ad tech регистрировать запрос .

Несколько специалистов по рекламе могут регистрировать одно и то же событие-триггер, используя либо перенаправления в поле Attribution-Reporting-Redirect , либо несколько вызовов метода registerTrigger() . Мы рекомендуем использовать поле ключа дедупликации , чтобы избежать включения дублирующихся триггеров в отчеты в случае, если один и тот же специалист по рекламе предоставляет несколько ответов для одного и того же события-триггера. Узнайте больше о том, как и когда использовать ключ дедупликации .

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

Следующие шаги показывают пример рабочего процесса:

  1. Ad tech SDK вызывает API для инициирования регистрации триггера с использованием предварительно зарегистрированного URI. См. Регистрация для учетной записи Privacy Sandbox для получения дополнительной информации.

    registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));

  2. API делает запрос к https://adtech.example/attribution_trigger? AD_TECH_PROVIDED_METADATA .

  3. HTTPS-сервер этой рекламной технологии отвечает заголовками, содержащими следующее:

    Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

  4. API делает запрос к каждому URL, указанному в Attribution-Reporting-Redirect . В этом примере указан только один URL, поэтому API делает запрос к https://adtechpartner.example?app_install=567 .

  5. HTTPS-сервер этой рекламной технологии отвечает заголовками, содержащими следующее:

    Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}

    На основе запросов, полученных на предыдущих этапах, регистрируются два триггера.

Возможности атрибуции

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

Применен алгоритм атрибуции с приоритетом источника

API отчетов об атрибуции использует алгоритм атрибуции с приоритетом источника для сопоставления триггера (конверсии) с источником атрибуции.

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

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

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

Фильтры триггеров

Регистрация источника и триггера включает в себя дополнительные необязательные функции, позволяющие выполнять следующие действия:

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

Для выборочной фильтрации триггеров рекламный техник может указать данные фильтра, состоящие из ключей и значений, во время регистрации источника и триггера. Если для источника и триггера указан один и тот же ключ, то триггер игнорируется, если пересечение пустое. Например, источник может указать "product": ["1234"] , где product — это ключ фильтра, а 1234 — это значение. Если фильтр триггера установлен на "product": ["1111"] , то триггер игнорируется. Если нет ключа фильтра триггера, соответствующего product , то фильтры игнорируются.

Другой сценарий, в котором рекламные технологические платформы могут захотеть выборочно фильтровать триггеры, — принудительно установить более короткое окно истечения срока действия. При регистрации триггера рекламный технический специалист может указать (в секундах) окно обратного просмотра с момента, когда произошла конверсия; например, 7-дневное окно обратного просмотра будет определено как: "_lookback_window": 604800 // 7d

Чтобы решить, соответствует ли фильтр, API сначала проверит окно обратного просмотра. Если доступно, длительность с момента регистрации источника должна быть меньше или равна длительности окна обратного просмотра.

Платформы рекламных технологий также могут выбирать данные триггера на основе данных исходного события. Например, source_type автоматически генерируется API как navigation или event . Во время регистрации триггера trigger_data может быть задан как одно значение для "source_type": ["navigation"] и как другое значение для "source_type": ["event"] .

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

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

Атрибуция после установки

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

API может поддерживать этот вариант использования, позволяя специалистам по рекламе устанавливать период атрибуции после установки:

  • При регистрации источника атрибуции укажите окно атрибуции установки, в течение которого ожидаются установки (обычно 2-7 дней, приемлемый диапазон от 1 до 30 дней). Укажите это временное окно в виде количества секунд.
  • При регистрации источника атрибуции укажите окно эксклюзивности атрибуции после установки, где любые события триггера после установки должны быть связаны с источником атрибуции, который привел к установке (обычно 7-30 дней, приемлемый диапазон от 0 до 30 дней). Укажите это временное окно как количество секунд.
  • API Attribution Reporting проверяет, когда происходит установка приложения, и внутренне приписывает установку источнику атрибуции с приоритетом источника. Однако установка не отправляется техническим специалистам по рекламе и не учитывается в соответствующих ограничениях скорости платформ.
  • Проверка установки приложения доступна для любого загруженного приложения.
  • Любые будущие триггеры, которые происходят в течение окна атрибуции после установки, приписываются тому же источнику атрибуции, что и проверенная установка, при условии, что этот источник атрибуции является допустимым.

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

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

Событие День, когда произошло событие Примечания
Нажмите 1 1 install_attribution_window установлен на 172800 (2 дня), а post_install_exclusivity_window установлен на 864000 (10 дней)
Проверенная установка 2 API внутренне атрибутирует проверенные установки, но эти установки не считаются триггерами. Поэтому на данном этапе отчеты не отправляются.
Триггер 1 (первое открытие) 2 Первый триггер, зарегистрированный рекламной технологией. В этом примере он представляет собой первое открытие, но может быть любым типом триггера.
Приписано клику 1 (соответствует приписыванию проверенной установки).
Нажмите 2 4 Использует те же значения для install_attribution_window и post_install_exclusivity_window , что и Click 1
Триггер 2 (после установки) 5 Второй триггер, зарегистрированный рекламной технологией. В этом примере он представляет собой конверсию после установки, например покупку.
Приписано клику 1 (соответствует приписыванию проверенной установки).
Клик 2 отброшен и не подлежит дальнейшей атрибуции.

В следующем списке приведены некоторые дополнительные примечания относительно атрибуции после установки:

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

Поддерживаются все комбинации путей запуска приложений и веб-приложений.

API отчетов об атрибуции позволяет атрибуцию следующих путей триггера на одном устройстве Android:

  • Из приложения в приложение: пользователь видит рекламу в приложении, а затем совершает конверсию либо в этом приложении, либо в другом установленном приложении.
  • Из приложения в веб: пользователь видит рекламу в приложении, а затем совершает конверсию в мобильном браузере или приложении.
  • Из веба в приложение: пользователь видит рекламу в мобильном браузере или приложении, а затем совершает конверсию в приложении.
  • Веб-в-веб: пользователь видит рекламу в мобильном браузере или приложении, а затем совершает конверсию либо в том же браузере, либо в другом браузере на том же устройстве.

Мы разрешаем веб-браузерам поддерживать новые функции, доступные в Интернете, такие как функциональность, похожая на API отчетов об атрибуции Privacy Sandbox for the Web , которая может вызывать API Android для включения атрибуции в приложении и на веб-сайте.

Узнайте об изменениях, которые необходимо внести рекламным специалистам и приложениям для поддержки путей триггеров для измерения эффективности между приложениями и веб-сайтами .

Приоритезация нескольких триггеров для одного источника атрибуции

Один источник атрибуции может привести к нескольким триггерам. Например, поток покупки может включать триггер «установка приложения», один или несколько триггеров «добавить в корзину» и триггер «покупка». Каждый триггер приписывается одному или нескольким источникам атрибуции в соответствии с алгоритмом атрибуции с приоритетом источника , описанным далее на этой странице.

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

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

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

Разрешить нескольким рекламным специалистам регистрировать источники атрибуции или триггеры

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

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

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

Источники атрибуции

Перенаправления источника атрибуции поддерживаются в методе registerSource() :

  1. Рекламная технология, вызывающая метод registerSource() может предоставить в своем ответе дополнительное поле Attribution-Reporting-Redirect , которое представляет собой набор URL-адресов перенаправления партнерской рекламной технологии.
  2. Затем API вызывает URL-адреса перенаправления, чтобы специалисты по рекламе партнера могли зарегистрировать источник атрибуции.

В поле Attribution-Reporting-Redirect можно указать несколько URL-адресов партнерских рекламных технологий, и партнерские рекламные технологии не могут указывать собственное поле Attribution-Reporting-Redirect .

API также допускает использование различных рекламных технологий для каждого вызова registerSource() .

Триггеры

Для регистрации триггера поддержка третьих сторон осуществляется аналогичным образом: специалисты по рекламе могут либо использовать дополнительное поле Attribution-Reporting-Redirect , либо каждый из них может вызвать метод registerTrigger() .

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

Обработка дублирующихся триггеров

Рекламный техник может регистрировать один и тот же триггер несколько раз с помощью API. Сценарии включают следующее:

  • Пользователь выполняет одно и то же действие (триггер) несколько раз. Например, пользователь просматривает один и тот же продукт несколько раз в одном и том же окне отчета.
  • Приложение рекламодателя использует несколько SDK для измерения конверсии, которые все перенаправляют на одну и ту же рекламную технологию. Например, приложение рекламодателя использует двух партнеров по измерению, MMP #1 и MMP #2. Оба MMP перенаправляют на рекламную технологию #3. Когда происходит триггер, оба MMP регистрируют этот триггер с помощью API отчетов об атрибуции. Затем рекламная технология #3 получает два отдельных перенаправления — одно от MMP #1 и одно от MMP #2 — для одного и того же триггера.

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

Рекомендуемый метод: ключ дедупликации

Рекомендуемый метод заключается в том, чтобы приложение рекламодателя передало уникальный ключ дедупликации любым рекламным технологиям или SDK, которые оно использует для измерения конверсии. Когда происходит конверсия, приложение передает ключ дедупликации рекламным технологиям или SDK. Затем эти рекламные технологии или SDK продолжают передавать ключ дедупликации перенаправлениям с использованием параметра в URL-адресах, указанных в Attribution-Reporting-Redirect .

Специалисты по рекламе могут зарегистрировать только первый триггер с заданным ключом дедупликации или могут зарегистрировать несколько триггеров или все триггеры. Специалисты по рекламе могут указать deduplication_key при регистрации дублирующих триггеров.

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

Альтернативный метод: специалисты по рекламе согласовывают типы триггеров для каждого рекламодателя

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

Технические специалисты по рекламе, инициирующие вызов регистрации триггера, например, SDK, включают параметр в URL-адреса, указанные в Attribution-Reporting-Redirect , например, duplicate_trigger_id . Этот параметр duplicate_trigger_id может включать информацию, например имя SDK и тип триггера для этого рекламодателя. Технические специалисты по рекламе могут затем отправлять подмножество этих дублирующих триггеров в отчеты на уровне событий. Технические специалисты по рекламе также могут включать этот duplicate_trigger_id в свои ключи агрегации.

Пример кросс-сетевой атрибуции

В примере, описанном в этом разделе, рекламодатель использует две обслуживающие платформы рекламных технологий (Ad tech A и Ad tech B) и одного партнера по измерению (MMP).

Для начала Ad tech A, Ad tech B и MMP должны каждый завершить регистрацию для использования API Attribution Reporting. См. Регистрация для учетной записи Privacy Sandbox для получения дополнительной информации.

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

День 1: Пользователь нажимает на рекламу, размещенную рекламной компанией A.

Ad tech A вызывает registerSource() со своим URI. API делает запрос к URI, и клик регистрируется с метаданными из ответа сервера Ad tech A.

Ad tech A также включает URI MMP в заголовок Attribution-Reporting-Redirect . API делает запрос к URI MMP, и клик регистрируется с метаданными из ответа сервера MMP.

День 2: Пользователь нажимает на рекламу, размещенную рекламной компанией B.

Ad tech B вызывает registerSource() со своим URI. API делает запрос к URI, и клик регистрируется с метаданными из ответа сервера Ad tech B.

Как и Ad tech A, Ad tech B также включил URI MMP в заголовок Attribution-Reporting-Redirect . API делает запрос к URI MMP, и клик регистрируется с метаданными из ответа сервера MMP.

День 3: Пользователь просматривает рекламу, размещенную рекламной компанией A

API отвечает так же, как и в первый день, за исключением того, что представление регистрируется для Ad tech A и MMP.

День 4: Пользователь устанавливает приложение, которое использует MMP для измерения конверсии.

MMP вызывает registerTrigger() с их URI. API делает запрос к URL, и преобразование регистрируется с метаданными из ответа сервера MMP.

MMP также включает URI для Ad tech A и Ad tech B в заголовок Attribution-Reporting-Redirect . API делает запросы к серверам Ad tech A и Ad tech B, и конверсия регистрируется соответствующим образом с метаданными из ответов сервера.

Следующая диаграмма иллюстрирует процесс, описанный в предыдущем списке:

Пример того, как API Attribution Reporting реагирует на ряд действий пользователя.

Атрибуция работает следующим образом:

  • Рекламная технология A устанавливает приоритет кликов выше, чем просмотров, и поэтому приписывает установку клику первого дня.
  • Рекламная технология B получает установку, атрибутированную на 2-й день.
  • MMP устанавливает приоритет кликов выше, чем просмотров, и присваивает установку клику Дня 2. Клик Дня 2 имеет наивысший приоритет, является самым последним рекламным событием.

Межсетевая атрибуция без перенаправлений

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

Высокий уровень потока

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

Регистрация источника

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

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

Регистрация триггера

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

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

Атрибуция

API отчетности по атрибуции выполняет припиотизированную исходную атрибуцию для измерения AD Tech на основе их конфигурации атрибуции, общих ключей и любых зарегистрированных ими источников. Например:

  • Пользователь нажал на рекламу, обслуживаемые AD Techs A, B, C и D. Затем пользователь установил приложение рекламодателя, в котором используется Tech Partner Measurement AD (MMP).
  • AD Tech A перенаправляет свои источники MMP.
  • AD Techs B и C не перенаправляют, но делятся своими ключами агрегации.
  • AD Tech D не перенаправляет и не разделяет ключи агрегации.

MMP регистрирует источник от Ad Tech A и определяет конфигурацию атрибуции, которая включает AD Tech B и Ad Tech D.

Атрибуция для MMP теперь включает в себя:

  • Ad Tech A, так как MMP зарегистрировал источник из перенаправления этой рекламной технологии.
  • Ad Tech B, так как Ad Tech B общие ключи и MMP включали его в свою конфигурацию атрибуции.

Атрибуция для MMP не включает:

  • AD Tech C, поскольку MMP не включила его в свою конфигурацию атрибуции.
  • AD Tech D, поскольку они не перенаправляли и не разделяли ключи агрегации.

Отладка

Для поддержки отладки для атрибуции по перекрестной сети без перенаправлений, дополнительное поле, shared_debug_key , доступно для AD Techs для установки при регистрации источника. Если установлено на исходной регистрации источника, она также будет установлена на соответствующем производном источнике в качестве debug_key во время регистрации триггеров для атрибуции поперечной сети без перенаправлений. Этот ключ отладки прикреплен как source_debug_key в отчетах о событии и совокупности.

Эта функция отладки будет поддерживаться только для атрибуции перекрестной сети без перенаправлений в соответствии с следующими сценариями:

  • Приложение к измерению приложения, где разрешено ADID
  • Приложение к веб -измерению, где ADID разрешено и соответствует как источника приложения, так и в веб -триггере
  • Интернет -измерение (в одном и том же приложении браузера), когда ar_debug `присутствует как на источнике, так и на триггере

Ключевое обнаружение для атрибуции поперечной сети без перенаправлений

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

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

  • Список всех возможных ключей большой:
    • Объявляющая рекламная сеть выполняет сложную инициативу по привлечению пользователей, которая включает в себя 20 кампаний, каждая из которых имеет 10 групп AD, и каждая группа AD с 5 креативщиками, которые обновляются каждую неделю в зависимости от производительности.
  • Список всех возможных ключей неизвестен:
    • Объявляющая рекламная сеть обслуживает рекламу во многих мобильных приложениях, где полный список идентификаторов приложений издателя не известен при запуске кампании.
    • Рекламодатель работает в нескольких порционных рекламных сетях, которые не перенаправляются на MMP при регистрации источника; Каждая сервировая рекламная сеть имеет различную ключевую структуру и значения, которые могут быть ранее разделены с MMP.

С введением ключевого открытия:

  • Служба агрегации больше не требует полного перечисления возможных ключей агрегации.
  • Вместо того, чтобы указать полный список возможных клавиш, MMP может создать пустые (или частично пустые) набор клавиш и установить порог, так что в выходные данные включены только (не предварительно декоративные) клавиши со значениями, превышающими порог.
  • MMP получает сводный отчет, который включает в себя шумные значения для ключей, которые имеют значения, превышающие пороговое значение SET. Отчет также может включать в себя ключи, которые не имеют связанных реальных вкладов пользователей и являются чисто чушцом.
  • MMP использует поле x_network_bit_mapping в регистрации триггеров, чтобы определить, какая технология AD соответствует какой ключ.
  • Затем MMP может связаться с соответствующей службой AD Tech, чтобы понять значения в клавише источника.

Таким образом, Key Discovery позволяет MMP получать ключи агрегации, не зная их заранее, и избегать обработки большого объема клавиш исходных клавиш за счет дополнительного шума.

Дейзи цепно перенаправляет

Предоставляя несколько заголовков Attribution-Reporting-Redirect в исходном или регистрации запуска HTTPS-сервер-ответ, AD Tech может использовать API отчетности по атрибуции для выполнения нескольких регистраций источника и триггеров с помощью одного вызова API регистрации.

В серверном ответе AD Tech также может включать заголовок одного Location (302 перенаправления) с URL, который, в свою очередь, приводит к другой регистрации, до установленного предела.

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

Перенаправления не принимаются для RegisterWebSource и RegisterWebtrigger, используемых браузерами. Более подробную информацию можно найти в Руководстве по реализации Cross Web и App .

Просмотреть данные измерения в отчетах по атрибуции

API отчета о атрибуции позволяет следующим типам отчетов, более подробно описанные позже на этой странице:

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

Эти два типа отчетов дополняют друг друга и могут использоваться одновременно.

Отчеты об уровне событий

После того, как триггер приписывается источнику атрибуции, отчет об уровне событий генерируется и хранится на устройстве, пока он не может быть отправлен обратно на URL-обратный адрес каждого технологии Ad Tech в одном из Windows Time для отправки отчетов , более подробно описанных позже на этой странице.

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

Отчет на уровне событий содержит данные, такие как следующие:

  • Пункт назначения: имя пакета приложений рекламодателя или Etld+1, где произошел триггер
  • Идентификатор источника атрибуции: тот же идентификатор источника атрибуции, который использовался для регистрации источника атрибуции
  • Тип триггера: 1 или 3 бита данных триггера с низкой точки зрения, в зависимости от типа источника атрибуции

Содержание конфиденциальности, применяемые ко всем отчетам

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

Ограничения на количество рекламных технологий

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

  • 100 Techs AD с источниками атрибуции на {исходное приложение, приложение назначения, 30 дней, устройство}.
  • 10 AD Techs с приписанными триггерами на {Source App, приложение для назначения, 30 дней, устройство}.
  • 20 Techs могут зарегистрировать единый источник или триггер (через Attribution-Reporting-Redirect )

Ограничения на количество уникальных направлений

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

  • Во всех зарегистрированных источниках, во всех рекламных технологиях, API поддерживает не более 200 уникальных направлений, согласно исходному приложению, в минуту.
  • Во всех зарегистрированных источниках, для одной рекламной технологии, API поддерживает не более 50 уникальных направлений, согласно исходному приложению в минуту. Этот предел предотвращает использование всего технологии AD в увеличении всего бюджета из ранее упомянутого предела ставки.

Срок действия источников не учитывается в пределах ставки.

Один из сообщений о происхождении на исходное приложение в день

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

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

  1. Ad Tech Origity Origin 1 регистрирует источник в приложении B
  2. 12 часов спустя, Ad Tech Arating Origin 2 пытается зарегистрировать источник в приложении B

Второй источник, для API, будет отклонен API. Ad Tech Orying 2 Origin 2 не сможет успешно зарегистрировать источник на том же устройстве в приложении B до следующего дня.

Отсудания и пределы ставок

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

Текущее предложение состоит в том, чтобы ограничить каждую технологию AD 100 приписанными триггерами на {исходное приложение, приложение для назначения, 30 дней, устройство}.

Количество уникальных направлений

API ограничивает количество направлений, которые AD Tech может попытаться измерить. Чем меньше ограничение, тем сложнее AD -технологии использует API, чтобы попытаться измерить деятельность просмотра пользователей, которая не связана с показанной рекламой.

Текущее предложение состоит в том, чтобы ограничить каждую технологию AD 100 различными пунктами назначения невыполненными источниками в соответствии с исходным приложением.

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

Ограниченная верность данных триггера

API предоставляет 1 бит для просмотра триггеров и 3 бита для триггеров. Источники атрибуции продолжают поддерживать полные 64 бита метаданных.

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

Структура для дифференциального шума конфиденциальности

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

Шум применяется на том, правдиво ли сообщено событие источника атрибуции. Источник атрибуции зарегистрирован на устройстве с вероятностью 1-P $, что источник атрибуции зарегистрирован как нормальный, и с вероятностью $ p $, что устройство случайным образом выбирает среди всех возможных состояний вывода API (включая вообще ничего не сообщать, или сообщать о нескольких поддельных отчетах).

K-рандомизированный ответ-это алгоритм, который является эпсилоном дифференциально частным, если выполняется следующее уравнение:

\[ p = \frac{k}{k + e^ε - 1} \]

Для низких значений ε истинный выход защищен механизмом K-Рэндомизированного отклика. Точные параметры шума находятся в процессе работы и могут быть изменены на основе обратной связи, с текущим предложением следующего:

  • P = 0,24% для источников навигации
  • P = 0,00025% для источников событий

Ограничения на доступные триггеры (преобразования)

Существуют ограничения на количество триггеров на источник атрибуции, с текущим предложением следующего:

  • 1-2 Триггеры для источников атрибуции AD (2 триггера доступны только в случае атрибуции после установки)
  • 3 триггера для клика. Источники атрибуции AD

Конкретные временные окна для отправки отчетов (поведение по умолчанию)

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

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

  • 2 дня: устройство собирает все триггеры, которые произошли не более чем через 2 дня после зарегистрированного источника атрибуции. Отчет отправляется через 2 дня и через 1 час после регистрации источника атрибуции.
  • 7 дней: устройство собирает все триггеры, которые произошли более 2 дней, но не более чем через 7 дней после зарегистрированного источника атрибуции. Отчет отправляется через 7 дней и через 1 час после регистрации источника атрибуции.
  • Пользовательский продолжительность времени, определяемый атрибутом «истечения» источника атрибуции. Отчет отправляется через 1 час после указанного времени истечения. Это значение не может быть менее 1 дня или более 30 дней.

Гибкая конфигурация на уровне событий

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

Эта дополнительная гибкость будет введена в API отчета о атрибуции в два этапа:

  • Фаза 1: Гибкая конфигурация уровня событий Lite
    • Эта версия предоставляет подмножество полных функций и может использоваться независимо от фазы 2.
  • Фаза 2: Полная версия гибкой конфигурации уровня событий

Фаза 1 (Lite гибкий уровень событий) может быть использован для:

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

Фаза 2 (полный уровень гибкого события) может быть использован для выполнения всех возможностей на фазе 1 и:

  • Варьировать кардинальность данных триггера в отчете
  • Уменьшить количество общего шума за счет уменьшения кардинальности данных триггеров

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

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

  • Максимум 20 общих отчетов, глобально и за trigger_data
  • Максимум 5 возможных отчетных окон на trigger_data
  • Максимум 32 данных за триггер (не применимо для фазы 1: Lite гибкий уровень события)

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

Совокупные отчеты

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

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

  • Отчеты о значениях триггера, такие как доход
  • Обработка больше типов триггеров

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

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

  1. Устройство отправляет зашифрованные агрегируемые отчеты в AD Tech. В производственной среде рекламные технологии не могут использовать эти отчеты напрямую.
  2. AD Tech отправляет партию агрегируемых отчетов в службу агрегации для агрегации.
  3. Служба агрегации читает множество агрегируемых отчетов, расшифровывает и агрегирует их.
  4. Окончательные заполнители отправляются обратно в AD Tech в сводном отчете .
Процесс, который использует API отчетности по атрибуции для подготовки и отправки обширных отчетов.

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

  • Пункт назначения: имя пакета приложения или веб -URL ETLD+1, где произошел триггер.
  • Дата: дата, когда произошло событие, представленное источником атрибуции.
  • Полезная нагрузка: значения запуска, собранные в виде зашифрованных паров ключей/значений, которые используются в службе доверенной агрегации для вычисления агрегаций.

Агрегационные услуги

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

Эти услуги управляются разными сторонами, которые более подробно описаны позже на этой странице:

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

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

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

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

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

Для получения дополнительной информации о разработке, рабочем процессе и соображениях безопасности Службы агрегации см. В документе службы агрегации на GitHub.

Ключевой сервис управления

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

Агрегируемый отчет бухгалтерский учет

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

Агрегируемые отчеты API

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

Зарегистрируйте агрегатируемые исходные данные

Когда API делает запрос на URI источника атрибуции, AD Tech может зарегистрировать список клавиш агрегирования с именем histogram_contributions , ответив новым полем, называемой aggregation_keys в HTTP Header Attribution-Reporting-Register-Source , с ключом в качестве key_name и Value As key_piece : Piece: Piece: Piece:

  • (Ключ) Имя ключа: строка для имени ключа. Используется в качестве клавиши соединения для объединения с ключами на стороне триггера, чтобы сформировать конечную клавишу.
  • (Значение) Ключевая часть: значение битстроирования для ключа.

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

Последние ключи ограничены максимум 128 бит; Ключи длиннее этого усечены. Это означает, что шестигранные струны в JSON должны быть ограничены не более 32 цифр.

Узнайте больше о том, как структурированы клавиши агрегации и как вы можете настроить клавиши агрегации.

В следующем примере рекламная технология использует API для сбора следующего:

  • Совокупное количество конверсии на уровне кампании
  • Совокупные стоимость покупки на уровне GEO 
// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Зарегистрируйте агрегируемый триггер

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

Первое поле используется для регистрации списка совокупных ключей на стороне триггера. AD Tech должна ответить с помощью поля aggregatable_trigger_data в HTTP Header Attribution-Reporting-Register-Trigger , со следующими полями для каждого ключа агрегата в списке:

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

Второе поле используется для регистрации списка значений, которые должны способствовать каждому ключу. AD Tech должна ответить обратно с помощью поля aggregatable_values в HTTP Header Attribution-Reporting-Register-Trigger . Второе поле используется для регистрации списка значений, которые должны вносить вклад в каждый ключ, который может быть целым числом в диапазоне $ [1, 2^{16}] $.

Каждый триггер может внести несколько вкладов в агрегируемые отчеты. Общая сумма взносов в любое данное событие исходного события связана параметром $ L1 $, который является максимальной суммой взносов (значений) во всех совокупных ключах для данного источника. $ L1 $ относится к чувствительности L1 или норме взносов на гистограмму в отношении исходного события. Превышение этих ограничений приводит к тому, что будущий вклад в молчащее падение. Первоначальное предложение - установить $ l1 $ $ 2^{16} $ (65536).

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

В следующем примере бюджет конфиденциальности распределяется в равной степени между campaignCounts и geoValue , разделяя вклад $ L1 $ на каждый: 

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

Предыдущий пример генерирует следующий вклад гистограммы: 

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

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

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Дифференциальная конфиденциальность

Цель этого API - иметь структуру, которая может поддерживать дифференциально частное совокупное измерение. Это может быть достигнуто путем добавления шума, пропорционального бюджету $ L1 $, таким как выбор шума со следующим распределением:

\[ Laplace(\frac{L1}{ε}) \]

Защищенная аудитория API и атрибуция отчетности API интеграция

Интеграция Cross-API в области защищенной аудитории и отчетности по атрибуции позволяет AdTechs оценивать свои показатели атрибуции по различной тактике ремаркетинга, чтобы понять, какие типы аудитории обеспечивают наибольшую рентабельность инвестиций.

Благодаря этой кросс-афийской интеграции Adtechs Can:

  • Создайте карту ключа URI, которая будет использоваться как для 1) отчетности по взаимодействию, так и для регистрации источника.
  • Включите CustomAudience в их картирование ключей со стороны исходной стороны для совокупной сводной отчетности (с использованием API отчета о атрибуции).

Когда пользователь видит или нажимает на объявление:

  • URL -адрес, используемый для сообщений об этих взаимодействиях с использованием защищенной аудитории, также будет использоваться для регистрации представления или щелчка в качестве подходящего источника с помощью API отчета о атрибуции.
  • AD Tech может выбрать передачу CustomAudience (или другую соответствующую контекстную информацию о рекламе, такой как размещение рекламы или продолжительность просмотра), используя этот URL -адрес, чтобы эти метаданные могли распространяться на сводные отчеты, когда AD Tech рассматривает агрегатную эффективность кампании.

Для получения дополнительной информации о том, как это включено в защищенную аудиторию, см. В соответствующем разделе «Объяснитель API защищенной аудитории» .

Приоритет регистрации, атрибуция и отчетность примеры

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

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

Рассмотрим случай, когда пользователь делает следующее:

  1. Пользователь видит объявление. AD Tech регистрирует источник атрибуции с API с приоритетом 0 (просмотр № 1).
  2. Пользователь видит объявление, зарегистрированное с приоритетом 0 (представление № 2).
  3. Пользователь нажимает объявление, зарегистрированное с приоритетом 1 (нажмите № 1).
  4. Пользователь преобразует (достигает целевой страницы) в приложении для рекламодателя. AD Tech регистрирует триггер с API с приоритетом 0 (преобразование № 1).
    • Поскольку триггеры зарегистрированы, API сначала выполняет атрибуцию перед созданием отчетов.
    • Доступно 3 источника атрибуции: Просмотр № 1, просмотр № 2 и нажмите #1. API приписывает этот триггер, чтобы щелкнуть #1, потому что он является наивысшим приоритетом и последним.
    • View #1 и View #2 отброшены и больше не имеют права на будущую атрибуцию.
  5. Пользователь добавляет элемент в свою корзину в приложение для рекламодателя, зарегистрированное с приоритетом 1 (конверсия № 2).
    • Нажмите #1 - единственный подходящий источник атрибуции. API приписывает этот триггер, чтобы щелкнуть #1.
  6. Пользователь добавляет элемент в свою корзину в приложение для рекламодателя, зарегистрированное с приоритетом 1 (конверсия № 3).
    • Нажмите #1 - единственный подходящий источник атрибуции. API приписывает этот триггер, чтобы щелкнуть #1.
  7. Пользователь добавляет элемент в свою корзину в приложение для рекламодателя, зарегистрированное с приоритетом 1 (преобразование № 4).
    • Нажмите #1 - единственный подходящий источник атрибуции. API приписывает этот триггер, чтобы щелкнуть #1.
  8. Пользователь совершает покупку в приложении для рекламодателей, зарегистрированной с приоритетом 2 (конверсия № 5).
    • Нажмите #1 - единственный подходящий источник атрибуции. API приписывает этот триггер, чтобы щелкнуть #1.

Отчеты на уровне событий имеют следующие характеристики:

  • По умолчанию первые 3 триггера, приписываемые щелчке, и первый триггер, приписываемый представлению, отправляются после применимых отчетных окон.
  • В окне отчетности, если есть триггеры, зарегистрированные с более высоким приоритетом, они имеют приоритет и заменяют самый последний триггер.
  • В предыдущем примере AD Tech получает 3 отчеты о событиях после двухдневного окна отчетности, для преобразования № 2, конверсии № 3 и преобразования № 5.
    • Все 5 триггеров приписываются на щелчок #1. По умолчанию API отправит отчеты для первых 3 триггеров: преобразование № 1, преобразование № 2 и преобразование № 3.
    • Однако приоритет конверсии № 4 ( 1 ) выше, чем приоритет конверсии № 1 ( 0 ). Отчет о событии конверсии № 4 заменяет отчет о событии конверсии #1, который будет отправлен.
    • Кроме того, приоритет конверсии № 5 ( 2 ) выше, чем любой другой триггер. Отчет о событии конверсии № 5 заменяет отчет о преобразовании № 4, который будет отправлен.

Агрегируемые отчеты имеют следующие характеристики:

  • Зашифрованные агрегируемые отчеты отправляются в AD Tech, как только они обрабатываются, через несколько часов после зарегистрированы триггеры.

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

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

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

  • В предыдущем примере отправляются 5 агрегируемых отчетов, по одному для каждого зарегистрированного триггера.

Отчеты о переходной отладке

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

Прочитайте Руководство по отчетам о переходной отладке для получения подробной информации о отладке отчетов с измерением приложений и пакета.

Отчеты отладки Attribution-Success

Регистрация источника и триггера принимает новое 64-разрядное поле debug_key (отформатированное как строка), которое населяет AD Tech. source_debug_key и trigger_debug_key передаются в отчетах как на уровне событий, так и в совокупных отчетах.

Если отчет создан как с клавишами отладки источника, так и с запусками, отчет о дубликате отладки отправляется с ограниченной задержкой в знаменитую конечную точку .well-known/attribution-reporting/debug/report-event-attribution Отчеты отладки идентичны обычным отчетам, включая оба поля отладки. Including these keys in both allows tying normal reports to the separate stream of debug reports.

  • For event-level reports:
    • Duplicate debug reports are sent with limited delay and therefore aren't suppressed by limits on available triggers , which allows ad tech to understand the impact of those limits for event-level reports.
    • Event-level reports associated with false trigger events won't have trigger_debug_key s. This allows ad tech to more closely understand how noise is applied in the API.
  • For aggregatable reports:
    • We will support a new debug_cleartext_payload field which contains the decrypted payload, only if both source_debug_key and trigger_debug_key are set.

Verbose debugging reports

Verbose debugging reports allow developers to monitor certain failures in the attribution source or trigger registrations. These debugging reports are sent with limited delay after attribution source or trigger registrations to a . well-known/attribution-reporting/debug/verbose endpoint.

Each verbose report contains the following fields:

  • Type : what caused the report to be generated. See the full list of verbose report types .
    • In general, there are source verbose reports and trigger verbose reports.
    • Source verbose reports require the advertising ID to be available to the publisher app, and trigger verbose reports require the advertising ID to be available to the advertiser app.
    • Trigger verbose reports (with the exception of trigger-no-matching-source ) can optionally include the source_debug_key . This can only be included if the advertising ID is also available to the publisher app.
  • Body : The report's body, which depends on its type.

Ad techs need to opt in to receive verbose debugging reports using a new debug_reporting dictionary field in the Attribution-Reporting-Register_Source and Attribution-Reporting-Register-Trigger headers.

  • Source verbose reports require opt-in on the source registration header only.
  • Trigger debug reports require opt-in on the trigger registration header only.

How to use debug reports

If a conversion took place (according to your existing measurement system) and a debug report was received for that conversion, this means the trigger was successfully registered.

For each debug attribution report, check if you're receiving a regular attribution report that matches the two debug keys.

When there's no match, it can be for a number of reasons.

Works as intended:

  • Privacy-preserving API behaviors:
    • A user hits the report rate limit—causing all subsequent reports to not be sent in the time period; or a source is removed due to the pending destination limit.
    • For event-level reports: the report is subject to randomized response (noise) and is suppressed, or you may receive a randomized report.
    • For event-level reports: the limit of three (for clicks) or one (for views) reports has been reached, and subsequent reports have no explicit priority set, or a priority that is lower than existing reports.
    • The contribution limits for aggregatable reports have been exceeded.
  • Ad tech-defined business logic:
    • A trigger is filtered out using filters or priority rules.
  • Time delays or interactions with network availability (eg, the user turns off their device for an extended period of time).

Unintended causes:

  • Implementation issues:
    • The source header is misconfigured.
    • The trigger header is misconfigured.
    • Other configuration issues.
  • Device or network issues:
    • Failures due to network conditions.
    • Source or trigger registration response doesn't reach the client.
    • API bug.

Future considerations & open questions

The Attribution Reporting API is a work in progress. We're also exploring future potential features, such as non-last-click attribution models and cross-device measurement use cases.

Additionally, we'd like to seek feedback from the community on a few issues:

  1. Are there any use cases where you'd like the API to send out reports for the verified install? These reports would count against ad tech platforms' respective rate limits.
  2. Do you foresee any difficulties with passing the InputEvent from the app to ad tech for source registration?
  3. Do you have any special attribution use cases for pre-loaded apps or re-installed apps?