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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При регистрации источника атрибуции специалисты по рекламе указывают поле назначения, которое представляет собой имя пакета приложения, в котором происходит триггерное событие. Чтобы обеспечить измерение взаимодействия приложений с Интернетом, мы планируем поддерживать одно поле назначения приложения (имя пакета приложения) и одно поле назначения веб-сайта (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 :

Ценить	Описание	Пример использования
APP_SOURCE_AND_WEB_TRIGGER (по умолчанию)	Позволяет приложениям регистрировать источники приложений (источники, связанные с именем пакета приложения) и веб-триггеры (триггеры, связанные с eTLD+1) из WebView.	Приложения, которые используют WebView для показа рекламы, а не для просмотра веб-страниц
WEB_SOURCE_AND_WEB_TRIGGER	Позволяет приложениям регистрировать веб-источники и веб-триггеры из WebView. Примечание. Приложениям, использующим эту опцию, необходимо будет подать заявку на присоединение к белому списку, чтобы использовать registerWebSource() .	Браузерные приложения на основе WebView, в которых показы рекламы и конверсии могут происходить на веб-сайтах в WebView.
APP_SOURCE_AND_APP_TRIGGER	Позволяет приложениям регистрировать источники приложений и триггеры приложений из WebView.	Приложения на основе WebView, в которых показы рекламы и конверсии всегда должны быть связаны с приложением, а не с eTLD+1 WebView.
НЕПОЛНОЦЕННЫЙ	Отключает регистрацию источника и триггера из WebView. Обратите внимание, что первоначальный сетевой вызов источника атрибуции или URI триггера все равно может произойти, но любой ответ отбрасывается, и на устройстве ничего не сохраняется.

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

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

Как описано в основном предложении по проектированию, 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. Предложение не включает проверку связи приложений и веб-сайтов. В будущем мы, возможно, сможем проверять эти направления, проверяя ассоциации с помощью Digital Asset Links . Будет ли это блокировать какой-либо из ваших вариантов использования? Имеет ли смысл использовать ссылки на цифровые активы для этой проверки?
5. При регистрации источника атрибуции необходимо указать пункт назначения. В случае с веб-приложением вы можете указать ссылку на приложение. Какие форматы вы используете для указания ссылки на это приложение?
6. При регистрации источника атрибуции типа "приложение-сайт" это исходное событие необходимо зарегистрировать из приложения с помощью API отчетов об атрибуции Android. Например, если пользователь нажимает на объявление и клик открывается в браузере или на настраиваемой вкладке браузера, этот клик (исходное событие) должен быть зарегистрирован в приложении, а не в контексте браузера. Свяжитесь с нами, если у вас есть сомнения по этому поводу или есть другие варианты использования, которые не попадают в категории, описанные в этом выпуске с описанием поддерживаемых потоков .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При регистрации источника атрибуции специалисты по рекламе указывают поле назначения, которое представляет собой имя пакета приложения, в котором происходит триггерное событие. Чтобы обеспечить измерение взаимодействия приложений с Интернетом, мы планируем поддерживать одно поле назначения приложения (имя пакета приложения) и одно поле назначения веб-сайта (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 являются следующими:

Ценить	Описание	Пример использования
App_source_and_web_trigger (по умолчанию)	Позволяет приложениям регистрировать источники приложений (источники, связанные с именем пакета приложений) и веб -триггерами (триггеры, связанные с ETLD+1) из WebView.	Приложения, которые используют WebView для обслуживания рекламы, а не для просмотра веб -страниц
Web_source_and_web_trigger	Позволяет приложениям регистрировать веб -источники и веб -триггеры от WebView. ПРИМЕЧАНИЕ. Приложения, использующие registerWebSource() опцию	Приложения браузеров на основе WebView, где рекламные впечатления и конверсии могут происходить на веб-сайтах в WebView.
App_source_and_app_trigger	Позволяет приложениям регистрировать источники приложений и триггеры приложения от WebView.	Приложения на основе WebView, где рекламные впечатления и конверсии всегда должны быть связаны с приложением, а не с ETLD+1 WebView.
НЕПОЛНОЦЕННЫЙ	Отключает регистрацию источника и триггера от WebView. Обратите внимание, что первоначальный сетевой вызов к источнику атрибуции или запуск URI все еще может произойти, но любой ответ отбрасывается, и на устройстве ничего не будет сохранено.

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

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

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

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

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

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

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

Чтобы смягчить это, мы ограничим, какие браузеры или приложения могут вызовы registerWebSource() в браузеры или приложения, которые свидетельствуют о том, что исходный сайт, используемый в регистрации, представляет фактический сайт, отображаемый пользователю. Заполните эту форму , чтобы присоединиться к AllowList, чтобы позвонить в 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. Например, если пользователь нажимает на объявление, а щелчок открывается на вкладке браузера или на пользовательской вкладке браузера, этот клик (исходное событие) должно быть зарегистрировано из приложения, а не в контексте браузера. Обратитесь, если у вас есть опасения по поводу этого, или есть другие случаи использования, которые не попадают в категории, описанные в этом вопросе, описывающие поддерживаемые потоки .

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

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

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

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