Отчеты об атрибуции: межприкладные и веб-измерения

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

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

Пути запуска

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значение измерения «из веб-в веб»

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

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

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

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

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

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

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

В отличие от браузеров, WebView поддерживает регистрацию в ОС только в заголовке Attribution-Reporting-Eligible если доступен API Android Attribution Reporting. Если API Android Attribution Reporting недоступен, 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 отчетов об атрибуции поддерживает дополнительную функцию, называемую переходными отчетами об отладке , которая позволяет специалистам по рекламе узнать больше информации об отчетах об атрибуции, когда доступен рекламный идентификатор. Существует два типа отчетов об отладке: attribution-success и verbose . Эти отчеты поддерживаются для атрибуции кросс-приложений и веб-атрибуции, и оба типа отчетов содержат одну и ту же информацию; единственное различие заключается в разрешениях, которые блокируются при отправке отчетов об отладке.

Для атрибуции «из веба в веб», которая происходит в рамках одного приложения (например, в рамках одного и того же браузерного приложения), отчеты об успешной атрибуции и подробные отчеты доступны только при наличии сторонних файлов 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.
• Если доступно, специалисты по рекламе могут дополнительно ответить с помощью 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 Attribution Reporting.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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