Включить отслеживание конверсий

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

Например, у издателя обычно есть один или несколько рекламных специалистов, ответственных за показ рекламы. Сюда могут входить стороны, ответственные за разметку для креатива, стороны, предоставляющие показ или пиксель отслеживания для креатива, а также стороны, предоставление SDK или тега для рекламного места на странице издателя. Эти рекламные специалисты могут захотеть или не захотеть получать отчеты об атрибуции от ARA, но они имеют возможность гарантировать, что последующие рекламные специалисты смогут получать отчеты об атрибуции.

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

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

Распространенные сценарии измерения конверсий

В этом разделе мы рассмотрим два распространенных сценария измерения конверсии.

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

Рекламодатель желает атрибутировать конверсии в рекламных ресурсах с помощью стороннего поставщика показателей, а рекламная технология, размещающая креатив, желает атрибутировать конверсии в рекламных ресурсах. Это характерно для DSP или рекламных серверов рекламодателей (сторонний рекламный сервер — 3PAS), которые предоставляют разметку для рекламных объявлений, выполняют собственные отчеты по атрибуции и работают с рекламодателями, которые интегрируются со сторонними поставщиками измерений или аналитики.

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

Типичная настройка кампании может выглядеть так:

1. Сервер объявлений рекламодателя (3PAS) передает в DSP разметку рекламного объявления, которая включает в себя пиксели отслеживания показов и кликов стороннего поставщика услуг. Рекламный сервер должен обеспечить включение attributionsrc в разметку рекламного объявления.

2. DSP предлагает возможности добавлять дополнительные пиксели измерения показов и отслеживания кликов, а также должен убедиться, attributionsrc включен в окончательную разметку рекламного объявления, с которой они назначают ставки.

Сценарий 2. Только сторонний поставщик показателей должен получать отчеты от API отчетов по атрибуции.

Рекламодатель хочет атрибутировать конверсии на рекламных ресурсах с помощью стороннего поставщика показателей, но у рекламной технологии, на которой размещено объявление, нет требований к измерению атрибуции. Это характерно для издателей, SSP или рекламных серверов издателей, которые размещают креативы и не планируют сами использовать отчеты по атрибуции, но хотят включить API отчетов по атрибуции либо для своих партнеров DSP, либо для компаний, использующих теги измерений, таких как третьи компании. Сторонние рекламные серверы, поставщики измерений или аналитики.

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

В типичном примере настройки кампании из сценария 1 рекламному серверу издателя, SSP или самому издателю может просто потребоваться убедиться, что атрибут attributionsrc , предоставленный DSP, попадает на страницу издателя.

Детали реализации

В следующей таблице описаны этапы реализации API отчетов об атрибуции на высоком уровне:

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

Шаг 1. Включите источник атрибуции для существующих креативов и кода измерения.

На первом этапе включаются источники атрибуции.

Как работает атрибут attributionsrc

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

Для событий кликов, использующих перенаправления, в навигацию следует добавить атрибут attributionsrc . Любые 302-перенаправления после навигации не требуют добавления атрибута attributionsrc и будут иметь право на ARA, если при первоначальной навигации был добавлен attributionsrc .

Если attributionsrc пуст, запросы ARA будут отправляться на URL-адрес, определенный в атрибуте href тега привязки (URL-адрес перехода по клику). Если атрибут attributionsrc определен, запросы ARA будут отправляться на URL-адрес, определенный в атрибуте attributionsrc . URL перехода по клику также может регистрировать источники.

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

Пример пустого атрибута attributionsrc :

Если атрибут attributionsrc пуст, запросы API отчетов об атрибуции будут отправляться на URL-адрес, определенный атрибутом href тега привязки.

Пример непустого атрибута attributionsrc:

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

Добавьте attributionsrc для событий кликов и показов.

• Нажмите на события:
  • Субъектом, ответственным за добавление attributionsrc обычно является технический специалист по показу рекламы.
  • Теги привязки с событиями кликов должны иметь атрибут attributionsrc .
  • Клики с использованием window.open должны использовать аргумент windowFeatures вызова window.open для указания источника атрибуции.
• События-впечатления:
  • Субъектом, ответственным за добавление attributionsrc обычно является технология показа рекламы и поставщик(и) показателей.
  • События показа, запускаемые тегом <img> или тегом <script> , должны включать атрибут attributionsrc .
  • События показа с использованием Fetch API должны включать объект attributionReporting в аргументе параметров , передаваемом в вызов API Fetch.

В следующей таблице приведена сводка изменений, необходимых для событий кликов и показов:

Включить регистрацию источника атрибуции на аукционе защищенной аудитории.

Для измерения конверсий на аукционах Защищенной аудитории вместо использования attributionsrc вы можете использовать registerAdBeacon / registerAdMacro и setReportEventDataForAutomaticBeacons / reportEvent , чтобы включить регистрацию источников атрибуции.

Для отчетов о сигналах Защищенной аудитории функция registerAdBeacon доступна в рабочих модулях отчетов, а registerAdMacro доступна в рабочих модулях отчетов о победах покупателя. Затем данные о событиях внутри рекламного фрейма можно добавить к зарегистрированным маякам и макросам с помощью функций reportEvent и setReportEventDataForAutomaticBeacons API отчетов по рекламным объявлениям с огражденным фреймом . Это позволяет связать друг с другом сигналы рабочих модулей отчетности по защищенной аудитории и полезную нагрузку событий кадра рекламного объявления.

HTTP-заголовок Attribution-Reporting-Eligible добавляется к запросу, когда маяки и макросы запускаются вызовом reportEvent из кадра или когда автоматические маяки запускаются браузером. Вы можете использовать ответ маяка для регистрации источника атрибуции. Запросы маяка могут быть перенаправлены, чтобы разрешить сторонние измерения.

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

Включить отчеты по атрибуции для форматов VAST

VAST – это общий формат для показа и измерения ресурсов видеорекламы, и многие события, определенные в этом стандарте, следует рассматривать как потенциальные исходные события, подходящие для регистрации с помощью API отчетов по атрибуции. Это подробно описано в дополнении VAST для поддержки отчетов по атрибуции , но вкратце все события <Tracking> , <Impression> , <*ClickThrough> и <*ClickTracking> являются потенциальными событиями источника атрибуции. Все реализации VAST должны обеспечивать право на регистрацию для этих событий.

Дополнение к VAST определяет новые атрибуты для этих элементов, позволяющие задать дополнительный URL-адрес специально для регистрации атрибуции. Если событие содержит attributiontype="DOUBLE_PING" и attributionsrc="[URL]" , код, запускающий это событие, должен использовать [URL] в качестве значения атрибута attributionsrc при включении API отчетов об атрибуции. Приложение VAST содержит примеры для каждого сценария.

Чтобы обеспечить максимальный охват, реализации VAST должны обеспечить возможность регистрации всех перечисленных событий по умолчанию при отправке пингов событий. Например, при запуске URL-адреса события <Impression> (пустой) атрибут attributionsrc должен использоваться в элементе <img> , используемом для отправки запроса (или его эквиваленте в вызове выборки), чтобы всегда разрешить принимающей стороне потенциально зарегистрировать это событие с помощью API отчетов об атрибуции.

Шаг 2. Включите отчеты об атрибуции для сторонних источников

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

Обрабатывать сторонние источники в существующей цепочке перенаправления.

При обычном переходе по объявлению многие трекеры кликов могут присутствовать в виде цепочки из 302 редиректов, созданных как часть перехода на конечную целевую страницу. Каждый запрос в цепочке перенаправления подлежит регистрации с помощью API отчетов по атрибуции, если исходная цель клика была аннотирована с помощью attributionsrc или зарегистрирована с помощью registerAdBeacon/registerAdMacro в API Protected Audience API . Рекламная технология в цепочке редиректов также должна быть зарегистрирована .

Обратите внимание, что тело первоначального запроса не отправляется при перенаправлении. Для аукционов с защищенной аудиторией, если eventData , переданные в reportEvent , и setReportEventDataForAutomaticBeacons необходимо использовать как часть перенаправления, их необходимо явно передать как часть URL-адреса перенаправления.

В следующем примере мы будем использовать технологию показа рекламы ( serving-adtech.example ) и стороннего поставщика показателей ( 3p-measurement.example ) как два отдельных объекта, которые хотят создавать и получать отчеты об атрибуции. В этом примере технологией показа рекламы может быть DSP, который отображает креатив на сайте издателя и имеет собственный продукт для отчетности. Сторонним поставщиком показателей может быть организация, которую рекламодатель использует для составления отчетов о конверсиях.

Во время регистрации источника выполняются следующие шаги:

1. serving-adtech.example устанавливает атрибут attributionsrc в объявлении. Пользователь посещает страницу издателя, и браузер отправляет запрос на serving-adtech.example.
2. serving-adtech.example отвечает заголовком Attribution-Reporting-Register-Source и заголовком Location .
   1. serving-adtech.example использует заголовок Attribution-Reporting-Register-Source для ответа метаданными об источнике, который необходимо зарегистрировать.
   2. serving-adtech.example использует заголовок Location для включения перенаправления на 3p-measurement.example . Обратите внимание: вполне вероятно, что заголовок Location уже используется в существующих потоках отслеживания кликов для поддержки 302 перенаправления на стороннее устройство.
3. Браузер получает ответ от serving-adtech.example и анализирует заголовок Attribution-Reporting-Register-Source . Браузер сохраняет исходное событие, используя serving-adtech.example в качестве источника отчета.
4. Поскольку этот запрос является перенаправлением, браузер также отправляет новый запрос к 3p-measurement.example .
5. 3p-measurement.example отвечает ответом, содержащим заголовок Attribution-Reporting-Register-Source .
6. Браузер получает этот ответ от 3p-measurement.example и считывает Attribution-Reporting-Register-Source . Браузер сохраняет исходное событие, используя 3p-measurement.example в качестве источника отчета.

Используйте attributionsrc для сторонних источников, не входящих в цепочку перенаправления.

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

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

Шаг 3. Настройте ответы на запросы API отчетов об атрибуции

Для всех источников, получающих запрос API отчетов об атрибуции, убедитесь, что сервер отвечает соответствующим заголовком Attribution-Reporting-Register-Source . См. руководство по источникам Регистра и пояснение , чтобы узнать, как следует строить ответ.

Регистрация нескольких триггеров

Вы можете зарегистрировать несколько триггеров атрибуции, добавив несколько элементов пикселей на стороне конверсии (по одному на каждый триггер). Элемент attributionsrc является необязательным для регистрации триггера .

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

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

Например, у издателя обычно есть один или несколько рекламных специалистов, ответственных за показ рекламы. Сюда могут входить стороны, ответственные за разметку для креатива, стороны, предоставляющие показ или пиксель отслеживания для креатива, а также стороны, предоставление SDK или тега для рекламного места на странице издателя. Эти рекламные специалисты могут захотеть или не захотеть получать отчеты об атрибуции от ARA, но они имеют возможность гарантировать, что последующие рекламные специалисты смогут получать отчеты об атрибуции.

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

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

Распространенные сценарии измерения конверсий

В этом разделе мы рассмотрим два распространенных сценария измерения конверсии.

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

Рекламодатель хочет атрибутировать конверсии в рекламных ресурсах с помощью стороннего поставщика показателей, а рекламная технология, размещающая креатив, желает атрибутировать конверсии в рекламных ресурсах. Это характерно для DSP или рекламных серверов рекламодателей (сторонний рекламный сервер — 3PAS), которые предоставляют разметку для рекламных объявлений, выполняют собственные отчеты по атрибуции и работают с рекламодателями, которые интегрируются со сторонними поставщиками измерений или аналитики.

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

Типичная настройка кампании может выглядеть так:

1. Сервер объявлений рекламодателя (3PAS) передает в DSP разметку рекламного объявления, которая включает в себя пиксели отслеживания показов и кликов стороннего поставщика услуг. Рекламный сервер должен обеспечить включение attributionsrc в разметку рекламного объявления.

2. DSP предлагает возможности добавлять дополнительные пиксели измерения показов и отслеживания кликов, а также должен убедиться, attributionsrc включен в окончательную разметку рекламного объявления, с которой они назначают ставки.

Сценарий 2. Только сторонний поставщик показателей должен получать отчеты от API отчетов по атрибуции.

Рекламодатель хочет атрибутировать конверсии на рекламных ресурсах с помощью стороннего поставщика показателей, но у рекламной технологии, на которой размещено объявление, нет требований к измерению атрибуции. Это характерно для издателей, SSP или рекламных серверов издателей, которые размещают креативы и не планируют сами использовать отчеты по атрибуции, но хотят включить API отчетов по атрибуции либо для своих партнеров DSP, либо для компаний, использующих теги измерений, таких как третьи компании. Сторонние рекламные серверы, поставщики измерений или аналитики.

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

В типичном примере настройки кампании из сценария 1 рекламному серверу издателя, SSP или самому издателю может просто потребоваться убедиться, что атрибут attributionsrc , предоставленный DSP, попадает на страницу издателя.

Детали реализации

В следующей таблице описаны этапы реализации API отчетов об атрибуции на высоком уровне:

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

Шаг 1. Включите источник атрибуции для существующих креативов и кода измерения.

На первом этапе включаются источники атрибуции.

Как работает атрибут attributionsrc

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

Для событий кликов, использующих перенаправления, в навигацию следует добавить атрибут attributionsrc . Любые 302-перенаправления после навигации не требуют добавления атрибута attributionsrc и будут иметь право на ARA, если при первоначальной навигации был добавлен attributionsrc .

Если attributionsrc пуст, запросы ARA будут отправляться на URL-адрес, определенный в атрибуте href тега привязки (URL-адрес перехода по клику). Если атрибут attributionsrc определен, запросы ARA будут отправляться на URL-адрес, определенный в атрибуте attributionsrc . URL перехода по клику также может регистрировать источники.

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

Пример пустого атрибута attributionsrc :

Если атрибут attributionsrc пуст, запросы API отчетов об атрибуции будут отправляться на URL-адрес, определенный атрибутом href тега привязки.

Пример непустого атрибута attributionsrc:

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

Добавьте attributionsrc для событий кликов и показов.

• Нажмите на события:
  • Субъектом, ответственным за добавление attributionsrc обычно является технический специалист по показу рекламы.
  • Теги привязки с событиями кликов должны иметь атрибут attributionsrc .
  • Клики с использованием window.open должны использовать аргумент windowFeatures вызова window.open для указания источника атрибуции.
• События-впечатления:
  • Субъектом, ответственным за добавление attributionsrc обычно является технология показа рекламы и поставщик(и) показателей.
  • События показа, запускаемые тегом <img> или тегом <script> , должны включать атрибут attributionsrc .
  • События показа с использованием Fetch API должны включать объект attributionReporting в аргументе параметров , передаваемом в вызов API Fetch.

В следующей таблице приведена сводка изменений, необходимых для событий кликов и показов:

Включить регистрацию источника атрибуции на аукционе защищенной аудитории.

Для измерения конверсий на аукционах Защищенной аудитории вместо использования attributionsrc вы можете использовать registerAdBeacon / registerAdMacro и setReportEventDataForAutomaticBeacons / reportEvent , чтобы включить регистрацию источников атрибуции.

Для отчетов о сигналах Защищенной аудитории функция registerAdBeacon доступна в рабочих модулях отчетов, а registerAdMacro доступна в рабочих модулях отчетов о победах покупателя. Затем данные о событиях внутри рекламного фрейма можно добавить к зарегистрированным маякам и макросам с помощью функций reportEvent и setReportEventDataForAutomaticBeacons API отчетов по рекламным объявлениям с огражденным фреймом . Это позволяет связать друг с другом сигналы рабочих модулей отчетности по защищенной аудитории и полезную нагрузку событий кадра рекламного объявления.

HTTP-заголовок Attribution-Reporting-Eligible добавляется к запросу, когда маяки и макросы запускаются вызовом reportEvent из кадра или когда автоматические маяки запускаются браузером. Вы можете использовать ответ маяка для регистрации источника атрибуции. Запросы маяка могут быть перенаправлены, чтобы разрешить сторонние измерения.

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

Включить отчеты по атрибуции для форматов VAST

VAST – это общий формат для показа и измерения ресурсов видеорекламы, и многие события, определенные в этом стандарте, следует рассматривать как потенциальные исходные события, подходящие для регистрации с помощью API отчетов по атрибуции. Это подробно описано в дополнении VAST для поддержки отчетов по атрибуции , но вкратце все события <Tracking> , <Impression> , <*ClickThrough> и <*ClickTracking> являются потенциальными событиями источника атрибуции. Все реализации VAST должны обеспечивать право на регистрацию для этих событий.

Дополнение к VAST определяет новые атрибуты для этих элементов, позволяющие задать дополнительный URL-адрес специально для регистрации атрибуции. Если событие содержит attributiontype="DOUBLE_PING" и attributionsrc="[URL]" , код, запускающий это событие, должен использовать [URL] в качестве значения атрибута attributionsrc при включении API отчетов об атрибуции. Приложение VAST содержит примеры для каждого сценария.

Чтобы обеспечить максимальный охват, реализации VAST должны обеспечить возможность регистрации всех перечисленных событий по умолчанию при отправке пингов событий. Например, при запуске URL-адреса события <Impression> (пустой) атрибут attributionsrc должен использоваться в элементе <img> , используемом для отправки запроса (или его эквиваленте в вызове выборки), чтобы всегда разрешить принимающей стороне потенциально зарегистрировать это событие с помощью API отчетов об атрибуции.

Шаг 2. Включите отчеты об атрибуции для сторонних источников

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

Обрабатывать сторонние источники в существующей цепочке переадресации.

При обычном переходе по объявлению многие трекеры кликов могут присутствовать в виде цепочки из 302 редиректов, созданных как часть перехода на конечную целевую страницу. Каждый запрос в цепочке перенаправления может быть зарегистрирован с помощью API отчетов по атрибуции, если исходная цель клика была аннотирована с помощью attributionsrc или зарегистрирована с помощью registerAdBeacon/registerAdMacro в API Protected Audience . Рекламная технология в цепочке редиректов также должна быть зарегистрирована .

Обратите внимание, что тело первоначального запроса не отправляется при перенаправлении. Для аукционов с защищенной аудиторией, если eventData , переданные в reportEvent , и setReportEventDataForAutomaticBeacons необходимо использовать как часть перенаправления, их необходимо явно передать как часть URL-адреса перенаправления.

В следующем примере мы будем использовать технологию показа рекламы ( serving-adtech.example ) и стороннего поставщика показателей ( 3p-measurement.example ) как два отдельных объекта, которые хотят создавать и получать отчеты об атрибуции. В этом примере технологией показа рекламы может быть DSP, который отображает креатив на сайте издателя и имеет собственный продукт для отчетности. Сторонний поставщик измерений может быть организацией, которую рекламодатель использует для отчетности по конверсии.

Во время регистрации источника представлены следующие шаги:

1. serving-adtech.example Устанавливает атрибут attributionsrc в Creative. Пользователь посещает страницу издателя, а браузер отправляет запрос на serving-adtech.example.
2. serving-adtech.example отвечает заголовком Attribution-Reporting-Register-Source и заголовком Location .
   1. serving-adtech.example использует заголовок Attribution-Reporting-Register-Source чтобы ответить метаданными о зарегистрированном источнике.
   2. serving-adtech.example использует заголовок Location , чтобы включить перенаправление на 3p-measurement.example . Пример. Обратите внимание, что вполне вероятно, что заголовок Location уже используется в ваших существующих потоках ClickTracking, чтобы поддержать 302 перенаправления на стороннюю партию.
3. Браузер получает ответ от serving-adtech.example и анализирует заголовок Attribution-Reporting-Register-Source . Браузер хранит исходное событие, используя serving-adtech.example в качестве отчетного происхождения.
4. Поскольку этот запрос является перенаправлением, браузер также делает новый запрос на 3p-measurement.example . Пример.
5. 3p-measurement.example отвечает ответом, который содержит заголовок Attribution-Reporting-Register-Source .
6. Браузер получает этот ответ от 3p-measurement.example и считывает Attribution-Reporting-Register-Source . Браузер хранит исходное событие, используя 3p-measurement.example в качестве отчетного происхождения.

Используйте attributionsrc для сторонних происхождений, а не в цепочке перенаправления

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

В этом примере запросы APIBLIBLE AP-адреса будут отправлены как на REPORTING_URL_1 так и. REPORTING_URL_2 . Запрос навигации, отправленный на URL ClickThrough, также имеет право на регистрацию источников атрибуции.

Шаг 3: Настройка ответов для запросов API отчета о атрибуции

Для всех источников, получая запрос API отчетности по отчетам о атрибуции, убедитесь, что сервер реагирует с соответствующим заголовком Attribution-Reporting-Register-Source . См. Руководство по источникам регистра и объяснение , чтобы узнать, как должен быть построен ответ.

Зарегистрируйте несколько триггеров

Вы можете зарегистрировать несколько триггеров атрибуции, добавив несколько пиксельных элементов на стороне преобразования (один на триггер). Элемент attributionsrc является необязательным для регистрации триггеров .

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