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

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

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

Пути запуска

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

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

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

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

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

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

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

После завершения процесса регистрации 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 поддерживает регистрацию в операционной системе только в том случае, если доступен API Attribution-Reporting-Eligible для Android. Если API Attribution Reporting для 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 отчетов по атрибуции может выполнять атрибуцию с приоритетом источника и по последнему касанию для приложений и веб-платформ.

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

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

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

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

• URI источников атрибуции : Платформа отправляет запрос к каждому URI из этого списка, чтобы получить метаданные, связанные с источником атрибуции.
  
  Каждый URI должен сопровождаться логическим флагом отладки (Debug ), указывающим, следует ли включать в отчет ключи отладки, предоставленные техническими специалистами.
• Событие ввода : либо объект 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, специфичные для приложения. Для предотвращения этого приложениям следует убедиться, что данный источник атрибуции не зарегистрирован одновременно в решении для измерения производительности приложения и в API отчетности по атрибуции Android.

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

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

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

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

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

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

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

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

Дальнейшие соображения и открытые вопросы

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

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

{% verbatim %} {% endverbatim %}

Рекомендуем вам

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