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

bookmark_border Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

Триггерные пути

Как описано в предложении по проектированию API отчетов об атрибуции , API позволяет атрибуцию следующих путей триггера на одном устройстве под управлением Android. Здесь мы определяем Интернет как любой из них; (1) Автономный браузер, работающий на Android (например, Chrome), или (2) WebView, работающий внутри приложения Android.

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

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

• Для специалистов по рекламе: обновления вызовов API и отчетов для обеспечения путей от приложения к Интернету.
• Для приложений и браузеров: возможность передавать регистрацию источников веб-атрибуции и веб-триггеров на Android.

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

Получите доступ к API отчетов по атрибуции

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

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

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

Изменения для рекламных технологий

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

Изменения в регистрации и атрибуции

При регистрации источника атрибуции специалисты по рекламе указывают поле назначения, которое представляет собой имя пакета приложения, в котором происходит триггерное событие. Чтобы обеспечить измерение взаимодействия приложений с Интернетом, мы планируем поддерживать одно поле назначения приложения (имя пакета приложения) и одно поле назначения веб-сайта (eTLD+1).

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

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

Получайте отчеты приложений и веб-сайтов

API отчетов по атрибуции Android может отправлять отчеты как о конверсиях в приложении, так и о веб-конверсиях. Если рекламные специалисты не хотят согласовывать триггерные данные и агрегированные пары «ключ-значение» на веб-сайтах и ​​в приложениях, они могут различать конверсии на веб-сайте и в приложении:

• Для отчетов на уровне событий мы будем поддерживать поле назначения, которое указывает, произошел ли триггер в Интернете (назначение — eTLD+1) или в приложении (назначение — имя пакета приложения).
• Для агрегированных отчетов пункт назначения отправляется в виде открытого текста.

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

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

• Доступен ли API отчетов по атрибуции на этом устройстве? Мы предоставим приложениям новый сигнал, который сообщит, доступен ли API отчетов об атрибуции на этом устройстве. Дополнительную информацию о том, как приложения могут проходить регистрацию в API отчетов по атрибуции, см. в разделе «Изменения приложений» .
• Какую часть источников атрибуции и триггеров следует передать в API? Это будет решение, принимаемое каждым приложением или рекламной технологией, если приложение допускает выбор. Если у приложения есть собственное решение для измерения, они могут рассмотреть возможность его использования. В конечном счете, передача всех регистраций источников и триггеров в API отчетов об атрибуции Android, если они доступны, обеспечивает наиболее точную атрибуцию в приложении и на сайте.

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

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

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

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

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

В отличие от браузеров, WebView поддерживает регистрацию в ОС только в заголовке Attribution-Reporting-Eligible если доступен API отчетов об атрибуции Android. Если API отчетов об атрибуции Android недоступен, WebView не устанавливает заголовок Attribution-Reporting-Eligible и никакие регистрации не выполняются.

Чтобы зарегистрировать источник/триггер атрибуции с помощью ОС:

• Специалисты по рекламе должны реагировать на регистрацию источника, используя заголовок Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из WebView к registerSource() или registerWebSource() .
• Специалисты по рекламе также могут реагировать на триггерные регистрации, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из WebView для registerWebTrigger() или registerTrigger() .

Обратите внимание: если ответ не включает предыдущие заголовки или также включает заголовки Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger даже если Интернет не поддерживается, вся регистрация завершится неудачно.

Подробные сведения о том, будет ли WebView использовать registerSource() / registerWebSource() и registerTrigger() / registerWebTrigger() (а также о том, как изменить это поведение), см. в разделе Источник атрибуции и триггерная регистрация из WebView .

Отчеты об отладке переходного периода

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

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

Для атрибуции между приложениями «приложение-сайт», «сеть-приложение» и «веб-сайт» доступны подробные отчеты об успешной атрибуции и подробные отчеты, если AdID доступен на стороне приложения и рекламная технология может передать тот же (правильный) AdID на веб-стороне.

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

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

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

Чтобы включить подробные отчеты об отладке для приложения в Интернете:

• Подробные отчеты об источнике зависят только от разрешений на стороне издателя. Для отправки подробных отчетов об источнике пользователь не должен отключать персонализацию AdID, а приложение издателя должно задекларировать разрешения AdID.
• Подробные отчеты о триггерах зависят только от разрешений стороны триггера (в данном примере — веб-сайта). Сторонние файлы cookie должны быть доступны в браузере для отправки подробных отчетов.
• Для подробных отчетов триггера, которые могут дополнительно включать source_debug_key , source_debug_key включается, если рекламный идентификатор доступен приложению издателя.

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

Изменения для приложений

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

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

См. предложение Privacy Sandbox for the Web, где приведен пример того, как браузеры могут интегрироваться с API отчетности по атрибуции Android, чтобы обеспечить измерение между приложениями и веб-сайтами. В предложение браузер добавит следующие заголовки запроса:

• Attribution-Reporting-Eligible сообщает, доступна ли поддержка атрибуции на уровне ОС. В этом случае заголовок указывает, доступен ли API отчетов об атрибуции Android.
• Если доступно, специалисты по рекламе могут дополнительно ответить с помощью Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из приложения браузера для registerWebSource() .
• Специалисты по рекламе также могут реагировать на триггерные регистрации, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из приложения браузера для registerWebTrigger() .

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

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

• URI источника атрибуции : платформа выдает запрос к каждому URI в этом списке, чтобы получить метаданные, связанные с источником атрибуции.
  
  Каждый URI должен сопровождаться логическим флагом отладки , указывающим, следует ли включать в отчет ключи отладки, предоставленные техническими специалистами.
• Событие ввода : либо объект InputEvent (для события щелчка), либо null (для события просмотра).
• Происхождение источника : Происхождение источника (веб-сайт издателя).
• Назначение ОС : имя пакета приложения, в котором происходит событие триггера.
• Веб-адресат : eTLD+1, где происходит триггерное событие.
• Подтвержденный пункт назначения : намерение URI назначения ОС или веб-сайта, используемое для навигации по щелчку мыши.

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

• API проверяет места назначения, указанные рекламной технологией, на соответствие местам назначения, указанным приложением. Если места назначения разные, API отменяет регистрацию источника атрибуции.
  
  Ожидается, что приложения проверят веб-адреса перед вызовом API веб-контекста. При кликах приложения должны проверять, соответствует ли указанный пункт назначения тому пункту назначения, к которому переходит пользователь.
• API игнорирует любые URI перенаправления, указанные в Attribution-Reporting-Redirects . Приложения должны самостоятельно следовать перенаправлениям и вызывать registerWebSource() для каждого перенаправления, чтобы при необходимости они могли применять свои собственные политики разрешений.

Приложения должны присоединиться к белому списку, чтобы вызывать registerWebSource() . Заполните эту форму , чтобы присоединиться к белому списку. Целью белого списка является смягчение вопросов конфиденциальности при установлении доверия к веб-контексту .

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

При регистрации триггера приложения могут вызывать метод registerWebTrigger() , который ожидает следующие параметры:

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

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

По умолчанию WebView будет использовать registerSource() и registerWebTrigger() . Это связывает источники с приложением и запускает триггеры с источником верхнего уровня WebView при возникновении триггера.

Если приложению требуется другое поведение (например, размещение веб-контента в WebView), ему необходимо использовать метод setAttributionRegistrationBehavior в классе androidx.webkit.WebViewSettingsCompat . Этот метод укажет, должен ли WebView вызывать registerWebSource() или registerSource() и registerWebTrigger() или registerTrigger() .

Доступны следующие параметры setAttributionRegistrationBehavior :

Соображения конфиденциальности и безопасности

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

Влияние на механизмы сохранения конфиденциальности, применяемые к отчетам

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

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

Установить доверие к веб-контексту

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

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

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

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

Пользовательские элементы управления

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

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

Будущие соображения и открытые вопросы

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

1. Как вы будете использовать решения для измерения браузера с Android Attribution Reporting API на устройстве с поддержкой Android Privacy Sandbox? Вы предпочтете перенести все на Android?
2. Есть ли какие-либо опасения по поводу потенциального получения двух пингов для каждого источника атрибуции и триггера: одного от браузера или приложения и одного от API отчетов об атрибуции?
3. Как мы можем облегчить вам отладку различных API?
4. Предложение не включает проверку связи приложений и веб-сайтов. В будущем мы, возможно, сможем проверять эти места назначения, проверяя ассоциации с помощью ссылок на цифровые активы . Будет ли это блокировать какой-либо из ваших вариантов использования? Имеет ли смысл использовать ссылки на цифровые активы для этой проверки?
5. При регистрации источника атрибуции необходимо указать пункт назначения. В случае с веб-приложением вы можете указать ссылку на приложение. Какие форматы вы используете для указания ссылки на это приложение?
6. При регистрации источника атрибуции между приложением и веб-сайтом это исходное событие необходимо зарегистрировать из приложения с помощью API отчетов об атрибуции Android. Например, если пользователь нажимает на объявление и клик открывается в браузере или на настраиваемой вкладке браузера, этот клик (исходное событие) должен быть зарегистрирован в приложении, а не в контексте браузера. Свяжитесь с нами, если у вас есть опасения по этому поводу или есть другие варианты использования, которые не попадают в категории, описанные в этом выпуске с описанием поддерживаемых потоков .

{% дословно %}

Рекомендуется для вас

• Примечание. Текст ссылки отображается, когда JavaScript отключен.
• Отчеты по атрибуции
• Руководство разработчика API отчетов по атрибуции
• Примечания к выпуску

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

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

Триггерные пути

Как описано в предложении по проектированию API отчетов об атрибуции , API позволяет атрибуцию следующих путей триггера на одном устройстве под управлением Android. Здесь мы определяем Интернет как любой из них; (1) Автономный браузер, работающий на Android (например, Chrome), или (2) WebView, работающий внутри приложения Android.

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

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

• Для специалистов по рекламе: обновления вызовов API и отчетов для обеспечения путей от приложения к Интернету.
• Для приложений и браузеров: возможность передавать регистрацию источников веб-атрибуции и веб-триггеров на Android.

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

Получите доступ к API отчетов по атрибуции

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

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

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

Изменения для рекламных технологий

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

Изменения в регистрации и атрибуции

При регистрации источника атрибуции специалисты по рекламе указывают поле назначения, которое представляет собой имя пакета приложения, в котором происходит триггерное событие. Чтобы обеспечить измерение взаимодействия приложений с Интернетом, мы планируем поддерживать одно поле назначения приложения (имя пакета приложения) и одно поле назначения веб-сайта (eTLD+1).

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

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

Получайте отчеты приложений и веб-сайтов

API отчетов по атрибуции Android может отправлять отчеты как о конверсиях в приложении, так и о веб-конверсиях. Если рекламные специалисты не хотят согласовывать триггерные данные и агрегированные пары «ключ-значение» на веб-сайтах и ​​в приложениях, они могут различать конверсии на веб-сайте и в приложении:

• Для отчетов на уровне событий мы будем поддерживать поле назначения, которое указывает, произошел ли триггер в Интернете (назначение — eTLD+1) или в приложении (назначение — имя пакета приложения).
• Для агрегированных отчетов пункт назначения отправляется в виде открытого текста.

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

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

• Доступен ли API отчетов по атрибуции на этом устройстве? Мы предоставим приложениям новый сигнал, который сообщит, доступен ли API отчетов об атрибуции на этом устройстве. Дополнительную информацию о том, как приложения могут проходить регистрацию в API отчетов по атрибуции, см. в разделе «Изменения приложений» .
• Какую часть источников атрибуции и триггеров следует передать в API? Это будет решение, принимаемое каждым приложением или рекламной технологией, если приложение допускает выбор. Если у приложения есть собственное решение для измерения, они могут рассмотреть возможность его использования. В конечном счете, передача всех регистраций источников и триггеров в API отчетов об атрибуции Android, если они доступны, обеспечивает наиболее точную атрибуцию в приложении и на сайте.

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

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

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

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

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

В отличие от браузеров, WebView поддерживает регистрацию в ОС только в заголовке Attribution-Reporting-Eligible если доступен API отчетов об атрибуции Android. Если API отчетов об атрибуции Android недоступен, WebView не устанавливает заголовок Attribution-Reporting-Eligible и никакие регистрации не выполняются.

Чтобы зарегистрировать источник/триггер атрибуции с помощью ОС:

• Специалисты по рекламе должны реагировать на регистрацию источника, используя заголовок Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из WebView к registerSource() или registerWebSource() .
• Специалисты по рекламе также могут реагировать на триггерные регистрации, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из WebView для registerWebTrigger() или registerTrigger() .

Обратите внимание: если ответ не включает предыдущие заголовки или также включает заголовки Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger даже если Интернет не поддерживается, вся регистрация завершится неудачей.

Подробные сведения о том, будет ли WebView использовать registerSource() / registerWebSource() и registerTrigger() / registerWebTrigger() (а также о том, как изменить это поведение), см. в разделе Источник атрибуции и триггерная регистрация из WebView .

Отчеты об отладке переходного периода

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

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

Для атрибуции между приложениями «приложение-сайт», «сеть-приложение» и «веб-сайт» доступны подробные отчеты об успешной атрибуции и подробные отчеты, если AdID доступен на стороне приложения и рекламная технология может передать тот же (правильный) AdID на веб-стороне.

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

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

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

Чтобы включить подробные отчеты об отладке для приложения в Интернете:

• Подробные отчеты об источнике зависят только от разрешений на стороне издателя. Для отправки подробных отчетов об источнике пользователь не должен отключать персонализацию AdID, а приложение издателя должно задекларировать разрешения AdID.
• Подробные отчеты о триггерах зависят только от разрешений стороны триггера (в данном примере — веб-сайта). Сторонние файлы cookie должны быть доступны в браузере для отправки подробных отчетов.
• Для подробных отчетов триггера, которые могут дополнительно включать source_debug_key , source_debug_key включается, если рекламный идентификатор доступен приложению издателя.

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

Изменения для приложений

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

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

См. Sandbox Crivacy Sandbox для предложения Интернета для примера того, как браузеры могут интегрироваться с API отчетности Android отчетности, чтобы обеспечить перекрестное приложение и веб -измерения. В предложении браузер добавит следующие заголовки запросов:

• Доступна ли поддержка Attribution-Reporting-Eligible для атрибуции. В этом случае заголовок указывает, доступен ли API отчетности Android отчетности.
• Если доступно, AD Techs могут при желании отвечать, используя Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из приложения браузера для registerWebSource() .
• AD Techs также могут реагировать на регистрации триггеров, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из приложения браузера в registerWebTrigger() .

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

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

• Источник атрибуции URIS : Платформа выдает запрос на каждый URI в этом списке, чтобы получить метаданные, связанные с источником атрибуции.
  
  Каждый URI должен сопровождать логический флаг отладки , чтобы указать, должны ли в отчет включены ключи отладки, предоставленные технологиями.
• Событие ввода : либо объект InputEvent (для события Click), либо null (для события просмотра)
• Происхождение источника : Происхождение, на котором произошел источник (веб -сайт издателя).
• ОС назначение : имя пакета приложений, где происходит событие триггера.
• Веб -назначение : Etld+1, где происходит событие триггера.
• Проверенное место назначения : ОС или веб -назначение намерение, используемое для навигации на клике пользователя.

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

• API проверяет направления, указанные Tech AD с направлениями, указанными приложением. Если направления различны, API отбрасывает регистрацию источника атрибуции.
  
  Ожидается, что приложения будут проверять веб -назначения перед вызовом API веб -контекста. Для кликов приложения должны проверить, что указанный пункт назначения соответствует пункту назначения, которому пользователь ориентируется.
• API игнорирует любое перенаправление URI, представленное в Attribution-Reporting-Redirects . Приложения должны следовать за перенаправлением самостоятельно и вызовы registerWebSource() для каждого перенаправления, чтобы они могли применять свои собственные политики разрешений по мере необходимости.

Приложения должны присоединиться к AllingList, чтобы позвонить registerWebSource() . Заполните эту форму , чтобы присоединиться к списку. Цель AllistList состоит в том, чтобы смягчить соображения конфиденциальности вокруг установления доверия для веб -контекста .

Триггер (преобразование) Регистрация

При регистрации триггеров приложения могут позвонить в registerWebTrigger() , который ожидает следующие параметры:

• Запустите URIS : Платформа выдает запрос на каждый URI в этом списке, чтобы получить метаданные, связанные с триггером
• Происхождение назначения : Происхождение, на котором произошел триггер (веб -сайт рекламодателя)

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

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

Если приложение требует другого поведения (например, для тех, кто проводит веб -контент в веб -просветительстве), им необходимо использовать метод setAttributionRegistrationBehavior на классе androidx.webkit.WebViewSettingsCompat . В этом методе указывается, должен ли WebView вызовать registerWebSource() или registerSource() и registerWebTrigger() или registerTrigger() .

Доступные параметры для setAttributionRegistrationBehavior являются следующими:

Конфиденциальность и соображения безопасности

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

Влияние на конфиденциальные механизмы, применяемые к отчетам

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

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

Установить доверие к веб -контексту

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

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

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

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

Пользовательские элементы управления

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

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

Будущие соображения и открытые вопросы

Средняя совместимость приложения на WEB для API отчета о атрибуции находится в стадии разработки. Мы хотели бы получить отзывы сообщества по нескольким идеям:

1. На поддержанном устройстве Soundbox для конфиденциальности Android, как вы будете использовать решения для измерения браузера с API отчетности Android Attribution API? Вы предпочитаете передать все Android?
2. Есть ли какие -либо проблемы с потенциальным получением 2 пингов для каждого источника атрибуции и триггера, один из браузера или приложения и один из API отчета о атрибуции?
3. Как мы можем помочь облегчить вам различные APIS?
4. Предложение не включает подтверждение того, что приложение и веб -назначения связаны. В будущем мы можем проверить эти направления, проверяя ассоциации, используя цифровые ссылки . Будет ли это блокировать любой вариант использования? Имеет ли смысл использовать ссылки на цифровые активы для выполнения этой проверки?
5. При регистрации источника атрибуции необходимо указать пункт назначения. В случае с веб-приложением вы можете указать ссылку приложения. Какие форматы вы используете для указания этой ссылки приложения?
6. При регистрации источника атрибуции приложения к пакете это событие источника должно быть зарегистрировано в приложении с помощью API отчета о атрибуции Android. Например, если пользователь нажимает на объявление, а щелчок открывается на вкладке браузера или на пользовательской вкладке браузера, этот клик (исходное событие) должно быть зарегистрировано из приложения, а не в контексте браузера. Обратитесь, если у вас есть опасения по поводу этого, или есть другие случаи использования, которые не попадают в категории, описанные в этом вопросе, описывающие поддерживаемые потоки .

{ % Vorbatim %}

Рекомендуется для вас

• Примечание. Текст ссылки отображается, когда JavaScript выключен
• Отчет о атрибуции
• Руководство разработчика API отчета о атрибуции
• Выпуск заметок

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

• Добавлен раздел о переходных отчетах об отладке
• Добавлены инструкции по присоединению AlluctList для регистрации веб -источников

Триггерные пути

Как описано в предложении API API отчетности по атрибуции , API обеспечивает атрибуцию следующих путей триггера на одном устройстве с Android. Здесь мы определяем Интернет как; (1) Отдельный браузер, работающий на Android (например, Chrome) или, (2) веб -просмотр, работающий в приложении Android.

• App-to-App: пользователь видит объявление в приложении, а затем преобразует либо в этом приложении, либо в другом установленном приложении.
• App-to-Web: пользователь видит объявление в приложении, а затем преобразует в Интернете.
• Интернет-приложение: пользователь видит объявление в Интернете, а затем преобразует в приложение.
• Web-to-Web: пользователь видит объявление в Интернете, а затем преобразуется в Интернете.

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

• Для AD Techs: обновления вызовов API и отчетности, чтобы включить пути приложения.
• Для приложений и браузеров: возможность передавать регистрацию источников веб -атрибуции и веб -триггеров в Android.

В этом документе объясняется, как API отчета о атрибуции расширен для поддержки путей запуска App-to-Web, с веб-до приложения и веб-запуска. В нем также описывается изменения, которые необходимы для AD Techs и Apps для удовлетворения требований для поддержки этих путей триггера.

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

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

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

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

Изменения для рекламных технологий

В этом разделе обсуждаются изменения для AD Techs с использованием API отчета о атрибуции.

Изменения в регистрации и атрибуции

При регистрации источника атрибуции AD Techs указывают поле назначения, которое является именем пакета приложений, где происходит событие триггера. Чтобы включить измерение приложения к панцированию, мы планируем поддержать одно поле назначения приложения (имя пакета приложений) и одно поле веб-назначения (ETLD+1).

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

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

Получить приложение и веб -отчеты

API отчетности Antrid Attribution может отправлять отчеты как для приложений, так и для веб -преобразований. Если AD Techs не хотят выравнивать данные запуска данных и значения ключей агрегации по всему веб-поверхностям и приложениям, они могут различать Интернет и преобразование приложения:

• Для отчетов на уровне событий мы будем поддерживать поле назначения, в котором указывается, произошел ли триггер в Интернете (назначение ETLD+1) или приложение (пункт назначения-имя пакета приложений)
• Для агрегируемых отчетов пункт назначения отправляется в ClareText.

Последствия для измерения в Интернете

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

• Доступен ли API отчета о атрибуции на этом устройстве? Мы разместим новый сигнал для приложений, который возвращает, доступен ли API отчетности по атрибуции на этом устройстве. См. Раздел «Изменения в приложении» для получения более подробной информации о том, как приложения могут передавать регистрацию в API отчетности по атрибуции.
• Какая часть источников атрибуции и триггеров должна быть передана в API? Это будет решение, принятое каждым приложением или рекламной технологией, если приложение разрешает выбор. Если в приложении есть свое решение измерения, они могут захотеть рассмотреть вопрос о использовании этого. В конечном счете, передача всех регистраций источника и запуска в API отчетности Antride Attribution, когда она доступна, позволяет наиболее точную атрибуцию в приложении и веб -странах.

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

• На 1 день пользователь нажимает на объявление в приложении браузера.
  • Приложение браузера может выбрать использовать свое собственное решение о измерении или пройти регистрацию веб -рекламы, нажмите на API отчетности по атрибуции.
• На 2-й день пользователь нажимает на объявление в приложении без браузера.
  • Щелчок зарегистрирован как источник атрибуции с помощью API. Приложение браузера не имеет видимости в этом щелчке, потому что событие произошло в другом приложении.
• На 3 -й день пользователь преобразует в приложении браузера.
  • Если приложение браузера оба регистрируют щелчок и преобразование, используя свое собственное решение измерения и передает эту информацию в API отчетности по отчетам о атрибуции, маловероятно, что AD -технология может дать отчеты о преобразовании по решениям измерения. Кроме того, рекламная технология может потреблять как ограничения ставки приложений браузера, так и ограничения API отчета об атрибуции. Поэтому мы рекомендуем, чтобы приложения передавали все рекламные события и преобразования, которые будут зарегистрированы на API, когда API доступен.

Зарегистрировать источник атрибуции и триггер из WebView

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

Подобно браузерам, WebView поддерживает registerWebTrigger() для регистрации триггеров, которая связывает триггер с происхождением верхнего уровня. В WebView нет поддержки для регистрации триггера приложения; Обратитесь, если у вас есть вариант использования для этого. Для полного списка комбинаций, поддерживаемых WebView, см. РЕГИСТРАЦИИ ИСТОЧНИКОВ АТИБИИ И РЕГИСТРАЦИИ ТРИГЕРГИ В WEBVIEW .

В отличие от браузеров, WebView поддерживает регистрацию с ОС в заголовке Attribution-Reporting-Eligible если доступен API отчета о атрибуции Android. Если API отчетности Antribution отчетности Android недоступен, WebView не устанавливает заголовок Attribution-Reporting-Eligible и регистрации не взимаются.

Чтобы зарегистрировать источник / триггер атрибуции с использованием ОС:

• AD Techs должны реагировать на регистрацию источников, используя заголовок Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из WebView to registerSource() или registerWebSource() .
• AD Techs также могут отвечать на регистрации триггеров, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из WebView в registerWebTrigger() или registerTrigger() .

Обратите внимание, что если ответ не включает в себя предыдущие заголовки, или он также включает в себя заголовки Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger даже если WEB не поддерживается, тогда вся регистрация потерпит неудачу.

Для получения подробной информации о том, будет ли WebView использовать registerSource() / registerWebSource() и registerTrigger() / registerWebTrigger() (а также как изменить это поведение), обратитесь к источнику атрибуции и регистрации триггера из WebView .

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

API отчетности по атрибуции поддерживает дополнительную функцию под названием отчеты о переходной отладке , которая позволяет AD Techs узнать больше информации о отчетах об атрибуции, когда доступен идентификатор рекламы. Существует два типа отчетов отладки: Attribution-Success и Verbose . Эти отчеты поддерживаются для Cross App и веб -атрибуции, и оба типа отчетов содержат одну и ту же информацию; Единственная разница заключается в разрешениях, которые ворота при отладке отчеты отправляются.

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

Для приложений к вае, веб-к приложению и отчетному атрибуту с перекрестным приложением отчеты, атрибуция и словесные отчеты доступны, если ADID доступен на стороне приложения, а AD Tech может передавать тот же (правильный) Adid на веб-стороне.

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

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

• Пользователь не должен отказаться от персонализации, используя рекламный идентификатор
• Приложение издателя должно было объявить Adid разрешения
• AD Tech должна передавать доверенное значение в регистрации триггера (из веб -контекста)

Чтобы включить отчеты отладки отладки для приложений к панели:

• Отчеты об исходных словесных отчетах зависят только от разрешений издателя. Чтобы отправлять отчеты об уровне исходных слоев, пользователь не должен был отказаться от персонализации Adid, а приложение издателя должно было объявить о договоренности.
• Отчеты о том, что Trigger Arbose зависят только от разрешений на триггер (в этом примере) разрешения в Интернете). Сторонние файлы cookie должны быть доступны в браузере, чтобы отправить отчеты о том, чтобы быть отправленными.
• Для отчетов о триггерах, которые могут при желании включать в себя source_debug_key , source_debug_key включен, если идентификатор рекламы доступен в приложении Publisher.

Обратите внимание, что во всех случаях AD Tech по -прежнему необходимо выбрать для получения отчетов отладки словесной отладки, используя поле debug_reporting Dictionary в заголовках Source и Trigger.

Изменения для приложений

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

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

См. Sandbox Crivacy Sandbox для предложения Интернета для примера того, как браузеры могут интегрироваться с API отчетности Android отчетности, чтобы обеспечить перекрестное приложение и веб -измерения. В предложении браузер добавит следующие заголовки запросов:

• Доступна ли поддержка Attribution-Reporting-Eligible для атрибуции. В этом случае заголовок указывает, доступен ли API отчетности Android отчетности.
• Если доступно, AD Techs могут при желании отвечать, используя Attribution-Reporting-Register-OS-Source , который инициирует вторичный вызов API из приложения браузера для registerWebSource() .
• AD Techs также могут реагировать на регистрации триггеров, используя заголовок Attribution-Reporting-Register-OS-Trigger , который инициирует вторичный вызов API из приложения браузера в registerWebTrigger() .

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

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

• Источник атрибуции URIS : Платформа выдает запрос на каждый URI в этом списке, чтобы получить метаданные, связанные с источником атрибуции.
  
  Каждый URI должен сопровождать логический флаг отладки , чтобы указать, должны ли в отчет включены ключи отладки, предоставленные технологиями.
• Событие ввода : либо объект InputEvent (для события Click), либо null (для события просмотра)
• Происхождение источника : Происхождение, на котором произошел источник (веб -сайт издателя).
• ОС назначение : имя пакета приложений, где происходит событие триггера.
• Веб -назначение : Etld+1, где происходит событие триггера.
• Проверенное место назначения : ОС или веб -назначение намерение, используемое для навигации на клике пользователя.

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

• API проверяет направления, указанные Tech AD с направлениями, указанными приложением. Если направления различны, API отбрасывает регистрацию источника атрибуции.
  
  Ожидается, что приложения будут проверять веб -назначения перед вызовом API веб -контекста. Для кликов приложения должны проверить, что указанный пункт назначения соответствует пункту назначения, которому пользователь ориентируется.
• API игнорирует любое перенаправление URI, представленное в Attribution-Reporting-Redirects . Приложения должны следовать за перенаправлением самостоятельно и вызовы registerWebSource() для каждого перенаправления, чтобы они могли применять свои собственные политики разрешений по мере необходимости.

Приложения должны присоединиться к AllingList, чтобы позвонить registerWebSource() . Заполните эту форму , чтобы присоединиться к списку. Цель AllistList состоит в том, чтобы смягчить соображения конфиденциальности вокруг установления доверия для веб -контекста .

Триггер (преобразование) Регистрация

При регистрации триггеров приложения могут позвонить в registerWebTrigger() , который ожидает следующие параметры:

• Запустите URIS : Платформа выдает запрос на каждый URI в этом списке, чтобы получить метаданные, связанные с триггером
• Происхождение назначения : Происхождение, на котором произошел триггер (веб -сайт рекламодателя)

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

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

Если приложение требует другого поведения (например, для тех, кто проводит веб -контент в веб -просветительстве), им необходимо использовать метод setAttributionRegistrationBehavior на классе androidx.webkit.WebViewSettingsCompat . В этом методе указывается, должен ли WebView вызовать registerWebSource() или registerSource() и registerWebTrigger() или registerTrigger() .

Доступные параметры для setAttributionRegistrationBehavior являются следующими:

Конфиденциальность и соображения безопасности

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

Влияние на конфиденциальные механизмы, применяемые к отчетам

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

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

Установить доверие к веб -контексту

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

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

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

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

Пользовательские элементы управления

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

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

Будущие соображения и открытые вопросы

Средняя совместимость приложения на WEB для API отчета о атрибуции находится в стадии разработки. Мы хотели бы получить отзывы сообщества по нескольким идеям:

1. На поддержанном устройстве Soundbox для конфиденциальности Android, как вы будете использовать решения для измерения браузера с API отчетности Android Attribution API? Вы предпочитаете передать все Android?
2. Есть ли какие -либо проблемы с потенциальным получением 2 пингов для каждого источника атрибуции и триггера, один из браузера или приложения и один из API отчета о атрибуции?
3. Как мы можем помочь облегчить вам различные APIS?
4. Предложение не включает подтверждение того, что приложение и веб -назначения связаны. В будущем мы можем проверить эти направления, проверяя ассоциации, используя цифровые ссылки . Будет ли это блокировать любой вариант использования? Имеет ли смысл использовать ссылки на цифровые активы для выполнения этой проверки?
5. При регистрации источника атрибуции необходимо указать пункт назначения. В случае с веб-приложением вы можете указать ссылку приложения. Какие форматы вы используете для указания этой ссылки приложения?
6. При регистрации источника атрибуции приложения к пакете это событие источника должно быть зарегистрировано в приложении с помощью API отчета о атрибуции Android. Например, если пользователь нажимает на объявление, а щелчок открывается на вкладке браузера или на пользовательской вкладке браузера, этот клик (исходное событие) должно быть зарегистрировано из приложения, а не в контексте браузера. Обратитесь, если у вас есть опасения по поводу этого, или есть другие случаи использования, которые не попадают в категории, описанные в этом вопросе, описывающие поддерживаемые потоки .

{ % Vorbatim %}

Рекомендуется для вас

• Примечание. Текст ссылки отображается, когда JavaScript выключен
• Отчет о атрибуции
• Руководство разработчика API отчета о атрибуции
• Выпуск заметок

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

• Добавлен раздел о переходных отчетах об отладке
• Добавлены инструкции по присоединению AlluctList для регистрации веб -источников

Триггерные пути

As described in the Attribution Reporting API design proposal , the API enables attribution of the following trigger paths on a single Android-powered device. Here we define Web as either; (1) A standalone browser running on Android (eg Chrome) or, (2) A WebView running inside an Android app.

• App-to-app: The user sees an ad in an app, then converts in either that app or another installed app.
• App-to-web: The user sees an ad in an app, then converts on the web.
• Web-to-app: The user sees an ad on the web, then converts in an app.
• Web-to-web: The user sees an ad on the web, then converts on the web.

The preceding trigger paths translate to the following requirements:

• For ad techs: updates to API calls and reporting to enable app-to-web paths.
• For apps and browsers: ability to pass registration of web attribution sources and web triggers to Android.

This document explains how the Attribution Reporting API is extended to support app-to-web, web-to-app, and web-to-web trigger paths. It also describes the changes that ad techs and apps need to make to satisfy the requirements for supporting these trigger paths.

Get access to Attribution Reporting APIs

Ad tech platforms need to enroll to access the Attribution Reporting APIs, see Enroll for a Privacy Sandbox account for more information.

Once the enrollment process is finalized, the API will discard the registration if an unenrolled registration call is received.

When enrolling, ad tech platforms should ensure they are enrolling with all the server URLs that they might use across app and web to register attribution sources and triggers. Multiple server registration URLs are supported, but only one reporting origin is supported. This reporting origin is derived from the domain of one of the server registration URLs.

Changes for ad techs

This section discusses changes for ad techs using the Attribution Reporting API.

Changes to registration & attribution

When registering an attribution source , ad techs specify a destination field which is the app package name where the trigger event occurs. To enable app-to-web measurement, we plan to support one app destination field (app package name) and one web destination field (eTLD+1).

When registering web attribution sources or triggers, the API does not support redirects because each app hosting web content could have its own permissions model. Each app is responsible for following redirects (if supported) and calling the web context APIs for each redirect hop.

Additionally, this integration enables ad techs to use app-specific attribution logic on web attribution sources. For example, you can now specify post-install attribution windows on a web attribution source.

Receive app and web reports

The Android Attribution Reporting API can send reports for both app and web conversions. If ad techs don't want to align trigger data and aggregation key-values across web and app surfaces, they can differentiate between a web and an app conversion:

• For event-level reports , we will support a destination field that specifies whether the trigger happened on web (destination is a eTLD+1) or app (destination is an app package name)
• For aggregatable reports , the destination is sent in cleartext.

Web-to-web measurement implications

Apps choose when to pass registration to the Attribution Reporting API. There are several considerations here:

• Is the Attribution Reporting API available on that device? We will expose a new signal to apps which returns whether the Attribution Reporting API is available on that device. See the app changes section for more details on how apps can pass registration to the Attribution Reporting API.
• What portion of attribution sources and triggers should be passed to the API? This will be a decision made by each app, or the ad tech if the app permits a choice. If the app has their own measurement solution, they may want to consider using that instead. Ultimately, passing all source and trigger registrations to the Android Attribution Reporting API, when available, enables the most accurate attribution across app and web.

The following example shows how browser apps can work with the Attribution Reporting API to provide accurate measurement when the user clicks on an ad in both a browser app and a non-browser app:

• On day 1, the user clicks on an ad in the browser app.
  • The browser app can choose to use their own measurement solution or pass registration of the web ad click to the Attribution Reporting API.
• On day 2, the user clicks on an ad in a non-browser app.
  • The click is registered as an attribution source with the API. The browser app has no visibility into this click because the event occurred within a different app.
• On day 3, the user converts in the browser app.
  • If the browser app both registers the click and conversion using their own measurement solution and passes that information to the Attribution Reporting API, it's unlikely that an ad tech can deduplicate conversion reports across measurement solutions. Additionally, an ad tech could consume both the browser app rate limits and the Attribution Reporting API rate limits. Therefore, we recommend that apps pass all ad events and conversions to be registered on the API, when the API is available.

Register attribution source and trigger from WebView

In the case where the app is using WebView to show web content rather than an Android ad, the app can apply to join the allowlist for registerWebSource() and provide the top-level origin of the website to be associated with the attribution source rather than the app package name.

Similar to browsers, WebView supports registerWebTrigger() for trigger registrations, which associates the trigger with the top-level origin. There is no support for WebView to register an app trigger; reach out if you have a use case for this. For the full list of combinations supported by WebView, refer to Attribution source and trigger registration from WebView .

Unlike browsers, WebView only supports registration with the OS within the Attribution-Reporting-Eligible header if Android's Attribution Reporting API is available. If Android's Attribution Reporting API is unavailable, WebView doesn't set an Attribution-Reporting-Eligible header and no registrations are made.

To register an attribution source / trigger using the OS:

• Ad techs should respond to source registrations using the Attribution-Reporting-Register-OS-Source header, which initiates a secondary API call from the WebView to registerSource() or registerWebSource() .
• Ad techs can also respond to trigger registrations using the Attribution-Reporting-Register-OS-Trigger header, which initiates a secondary API call from the WebView to registerWebTrigger() or registerTrigger() .

Note that if the response does not include the previous headers, or it also includes the Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger headers even though web is not supported, then the entire registration will fail.

For details on whether WebView will use registerSource() / registerWebSource() and registerTrigger() / registerWebTrigger() (as well as how to change this behavior) refer to Attribution source and trigger registration from WebView .

Transitional debugging reports

The Attribution Reporting API supports an optional feature called transitional debugging reports , which allows ad techs to learn more information about attribution reports when an advertising ID is available. There are two types of debugging reports: attribution-success and verbose . These reports are supported for cross app and web attribution, and both report types contain the same information; the only difference being around permissions that gate when debugging reports are sent out.

For web-to-web attribution that happens within a single app (for example, within the same browser app), attribution-success and verbose reports are available only when third-party cookies are available, and are not based on advertising ID availability.

For app-to-web, web-to-app, and web-to-web cross-app attribution, attribution-success and verbose reports are available if AdID is available on the app side and the ad tech can pass the same (correct) AdID on the web side.

In a later app-to-web example the source happens in a publisher app, but the trigger happens on an advertiser site inside a browser app.

To enable an attribution-success debugging report for app-to-web, the following conditions must be met:

• The user must not have opted out of personalization using the advertising ID
• The publisher app must have declared AdID permissions
• The ad tech must pass the AdID value in trigger registration (from a web context)

To enable verbose debugging reports for app-to-web:

• Source verbose reports depend on the publisher side permissions only. For source verbose reports to be sent, the user must not have opted out of AdID personalization, and the publisher app must have declared AdID permissions.
• Trigger verbose reports depend on the trigger side (in this example, web) permissions only. Third-party cookies must be available in the browser for trigger verbose reports to be sent.
• For trigger verbose reports that can optionally include a source_debug_key , the source_debug_key is included if the advertising ID is available to the publisher app.

Note that in all cases, the ad tech still needs to opt in to receiving verbose debugging reports using the debug_reporting dictionary field in source and trigger registration headers.

Changes for apps

We will support attribution across app and web surfaces by allowing apps to pass registration of web attribution sources and web triggers to the Attribution Reporting API on Android using a new set of web context API calls.

After completing the registration steps in the following sections, app and web attribution sources and triggers are stored on the device, and the Attribution Reporting API can perform source-prioritized, last-touch attribution across app and web surfaces.

See Privacy Sandbox for the Web's proposal for an example of how browsers can integrate with Android's Attribution Reporting API to enable cross app and web measurement. In the proposal, the browser will add the following request headers:

• Attribution-Reporting-Eligible broadcasts whether OS-level support for attribution is available. In this case, the header indicates whether Android's Attribution Reporting API is available.
• If available, ad techs can optionally respond using Attribution-Reporting-Register-OS-Source , which initiates a secondary API call from the browser app to registerWebSource() .
• Ad techs can also respond to trigger registrations using the Attribution-Reporting-Register-OS-Trigger header, which initiates a secondary API call from the browser app to registerWebTrigger() .

Attribution source registration

When registering an attribution source, apps can call registerWebSource() , which expects the following parameters:

• Attribution source URIs : The platform issues a request to each URI in this list in order to fetch metadata associated with the attribution source.
  
  Each URI should accompany a boolean Debug flag to indicate if the debug keys provided by the techs should be included in the report.
• Input event : Either an InputEvent object (for a click event) or null (for a view event)
• Source origin : Origin on which the source occurred (publisher website).
• OS destination : An app package name where the trigger event happens.
• Web destination : An eTLD+1 where the trigger event happens.
• Verified destination : OS or web destination URI intent used for navigation on user click.

When the API makes a request to the Attribution Source URI, the ad tech should respond with the attribution source metadata in an HTTP header, Attribution-Reporting-Register-Source . This header uses the same fields as app-to-app attribution source registration , with a few changes:

• The API validates the destinations specified by the ad tech with the destinations specified by the app. If destinations are different, the API discards the attribution source registration.
  
  Apps are expected to validate web destinations before calling the web context API. For clicks, apps should check that the destination specified matches the destination to which the user is navigating.
• The API ignores any redirect URIs provided in Attribution-Reporting-Redirects . Apps should follow redirects on their own and call registerWebSource() for each redirect, so that they can apply their own permissions policies as needed.

Apps must join an allowlist to call registerWebSource() . Complete this form to join the allowlist. The intent of the allowlist is to mitigate privacy considerations around establishing trust for web context .

Trigger (conversion) registration

On trigger registration, apps can call registerWebTrigger() , which expects the following parameters:

• Trigger URIs : The platform issues a request to each URI in this list in order to fetch metadata associated with the trigger
• Destination origin : Origin on which the trigger occurred (advertiser website)

Attribution source and trigger registration from WebView

By default, WebView will use registerSource() and registerWebTrigger() . This associates sources with the app and triggers with the top-level origin of the WebView when the trigger occurs.

If an app requires different behavior (such as those that host web content in a WebView) they need to use the setAttributionRegistrationBehavior method on the androidx.webkit.WebViewSettingsCompat class. This method will specify whether WebView should call registerWebSource() or registerSource() and registerWebTrigger() or registerTrigger() .

The available options for setAttributionRegistrationBehavior are the following:

Privacy and security considerations

This section discusses privacy and security considerations for apps using the Attribution Reporting API.

Impact on privacy-preserving mechanisms applied to reports

As described in the main design proposal, the API applies privacy-preserving rate limits to reports . Some limits are partitioned across source and destination apps. When a web attribution source or trigger is registered, the rate limit is partitioned by the source or destination site instead of the app.

If the app maintains separate rate limits, it would be possible for an adversary to consume app-specific rate limits in addition to the API rate limits. To mitigate this, apps should ensure that a given attribution source isn't registered on both the app's measurement solution and the Android Attribution Reporting API.

Establish trust for web context

In the web context API calls, the API places trust in the app to detect and specify the source and destination origins. This can open up potential privacy and security considerations:

• An adversary can claim to be hosting websites it owns in an attempt to bypass rate limits around the amount of information any source can transfer.
• Multiple adversaries can collude to register separate attribution sources, claiming the same source site. This could cause the source site to hit ad tech platform rate limits and prevent the actual source site from registering legitimate attribution sources.

To mitigate this, we will limit which browsers or apps can call registerWebSource() to browsers or apps that attest that the source site used in registration represents the actual site being shown to the user. Fill out the Web-to-App Attribution Reporting registration form to join the allowlist to call registerWebSource() .

Any app could call registerWebTrigger() because the privacy and security considerations on the trigger side aren't applicable without source-side collusion.

Пользовательские элементы управления

Apps can continue to support user controls or permissions policies as long as they can be defined at registration time. For example, if apps allow any site-level or user-level permissions, the app should evaluate those and determine whether to call the web context APIs.

Additionally, we will support a new API call from apps to delete any attribution sources, triggers, and pending reports stored for that app on the device. For example, if apps allow the user to clear their browsing history, they may want to call the API to delete attribution sources, triggers, and pending reports stored for that app on the user's device.

Future considerations & open questions

The app-to-web interoperability for the Attribution Reporting API is a work in progress. We'd like to seek feedback from the community on a few ideas:

1. On an Android Privacy Sandbox supported device, how will you use browser measurement solutions with the Android Attribution Reporting API? Will you prefer to pass everything to Android?
2. Are there any concerns with potentially receiving 2 pings for each attribution source and trigger, one from the browser or app and one from the Attribution Reporting API?
3. How can we help make debugging across different APIs easier for you?
4. The proposal does not include validation that app and web destinations are affiliated. In the future, we may be able to validate these destinations by checking associations using Digital Asset Links . Would that block any of your use cases? Does it make sense to use Digital Asset Links to do this validation?
5. When registering an attribution source, you must specify a destination. In the web-to-app case, you may want to specify an app link. What formats do you use to specify this app link?
6. When registering an app-to-web attribution source, that source event would need to be registered from the app with the Android Attribution Reporting API. For example, if the user clicks on an ad and the click is opened in a browser or a browser's custom tab, that click (source event) should be registered from the app rather than in the browser context. Reach out if you have concerns about this, or if there are other use cases that don't fall into the categories covered in this issue describing supported flows .

{% verbatim %}

Рекомендуется для вас

• Note: link text is displayed when JavaScript is off
• Attribution reporting
• Attribution Reporting API developer's guide
• Release notes