Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

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

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

Мы будем поддерживать атрибуцию в приложениях и на веб-страницах, позволяя приложениям передавать регистрацию источников веб-атрибуции и веб-триггеров в 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. Чтобы избежать этого, приложения должны гарантировать, что данный источник атрибуции не зарегистрирован ни в решении для измерения приложения, ни в API отчетов об атрибуции Android.

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

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

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

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

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

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

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

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

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

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

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

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