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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

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

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

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

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

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

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

Сценарии общего преобразования

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

Сценарий 1: как обслуживание AD Tech, так и сторонний поставщик измерений должны получать отчеты от API отчета о атрибуции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда attributionsrc пуст, запросы ARA будут отправлены на URL, определенный в атрибуте href тега Anchor (URL Clickthrough). Когда атрибут attributionsrc определяется, запросы ARA будут отправлены на URL -адрес, определенное в атрибуте attributionsrc . URL ClickThrough также имеет право на регистрацию источников.

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

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

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

Пример атрибута непустых атрибутов:

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

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

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

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

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

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

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

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

Для более глубокого погружения см. В разделе «Поддержка отчетности об атрибуции огороженного AD» об объяснении API.

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

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

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

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

Шаг 2: включить отчет о атрибуции для сторонних происхождений

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

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

В типичном рекламном клике многие трекеры кликов могут присутствовать в виде цепочки из 302 перенаправлений, сделанных в рамках навигации к конечной целевой странице. Каждый запрос в цепочке перенаправления имеет право на регистрацию в API отчетности Attribution, если исходный цель Click была аннотирована с помощью attributionsrc или зарегистрирована в registerAdBeacon/registerAdMacro в защищенной аудитории API . AD Tech в цепочке перенаправления также должна быть зарегистрирована .

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

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

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

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

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

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

Сценарии общего преобразования

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

Сценарий 1: как обслуживание AD Tech, так и сторонний поставщик измерений должны получать отчеты от API отчета о атрибуции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда attributionsrc пуст, запросы ARA будут отправлены на URL, определенный в атрибуте href тега Anchor (URL Clickthrough). Когда атрибут attributionsrc определяется, запросы ARA будут отправлены на URL -адрес, определенное в атрибуте attributionsrc . URL ClickThrough также имеет право на регистрацию источников.

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

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

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

Пример атрибута непустых атрибутов:

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

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

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

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

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

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

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

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

For a deeper dive, see the Support for Attribution Reporting section of the Fenced Frame Ad Reporting API explainer.

Enable attribution reporting for VAST formats

VAST is a common format for serving and measuring video ad inventory, and many of the events defined in that standard should be considered potential source events eligible for registration with the Attribution Reporting API. The VAST Addendum for Attribution Reporting Support covers this in detail, but in short, all <Tracking> , <Impression> , <*ClickThrough> , and <*ClickTracking> events are potential attribution source events. All VAST implementations should provide registration eligibility coverage for these events.

The VAST addendum defines new attributes for these elements to allow for setting a secondary URL specifically for attribution registration. When an event contains attributiontype="DOUBLE_PING" and attributionsrc="[URL]" , the code firing that event should use [URL] as the value of the attributionsrc attribute when enabling the Attribution Reporting API. The VAST addendum contains examples for each scenario.

To ensure maximum coverage, VAST implementations should make all events listed are registration eligible by default when firing event pings. For example, when firing an <Impression> event URL, the (empty) attributionsrc attribute should be used on the <img> element used to send the request (or the equivalent on the fetch call), to always allow for the receiving party to potentially register that event with the Attribution Reporting API.

Step 2: Enable Attribution Reporting for third-party origins

To allow third-parties to use the Attribution Reporting API, you can use existing redirects or add a list of third-parties to the attributionsrc attribute. In most cases, each ad tech has their own independent impression tracker, so redirects are more relevant for click trackers.

Handle third-party origins in an existing redirect chain

In a typical ad clickthrough, many click trackers may be present as a chain of 302 redirects made as part of the navigation to the final landing page. Every request in the redirect chain is eligible for registration with the Attribution Reporting API if the original click target was annotated with attributionsrc or registered with registerAdBeacon/registerAdMacro in Protected Audience API . The ad tech in the redirect chain must be also enrolled .

Note that the initial request's body is not sent on redirects. For Protected Audience auctions, if eventData passed in to reportEvent and setReportEventDataForAutomaticBeacons needs to be used as part of the redirect, it must be explicitly passed on as part of the redirect URL.

In the following example, we will use a serving ad tech ( serving-adtech.example ) and a third-party measurement provider ( 3p-measurement.example ) as two distinct entities that are looking to generate and receive attribution reports. The serving ad tech in this example can be a DSP that renders the creative on the publisher site, and has their own reporting product. The third-party measurement provider can be an entity that the advertiser uses for conversion reporting.

At source registration time, the following steps take place:

1. serving-adtech.example sets the attributionsrc attribute in the creative.The user visits the publisher page, and the browser sends a request to serving-adtech.example.
2. serving-adtech.example responds with the Attribution-Reporting-Register-Source header and the Location header.
   1. serving-adtech.example uses the Attribution-Reporting-Register-Source header to respond with metadata about the source to be registered.
   2. serving-adtech.example uses the Location header to include a redirect to 3p-measurement.example . Note that it's likely that the Location header is already being used in your existing clicktracking flows to support 302 redirects to a third-party.
3. The browser receives the response from serving-adtech.example and parses the Attribution-Reporting-Register-Source header. The browser stores the source event, using serving-adtech.example as the reporting origin.
4. Because this request is a redirect, the browser also makes a new request to 3p-measurement.example .
5. 3p-measurement.example responds with a response that contains the Attribution-Reporting-Register-Source header.
6. The browser receives this response from 3p-measurement.example and reads the Attribution-Reporting-Register-Source . The browser stores the source event, using 3p-measurement.example as the reporting origin.

Use attributionsrc for third-party origins not in a redirect chain

If multiple reporter origins want to register a source on a navigation event, but can't appear in a redirect chain for any reason, you can list multiple sites as attribution sources in attributionsrc as an alternative solution.

In this example, Attribution Reporting API-eligible requests will be sent to both REPORTING_URL_1 and. REPORTING_URL_2 . The navigation request sent to the clickthrough URL is also eligible to register attribution sources.

Step 3: Set up responses for Attribution Reporting API requests

For all origins receiving an Attribution Reporting API request, ensure that the server responds with the appropriate Attribution-Reporting-Register-Source header. See the Register sources guide and the explainer to learn how the response should be constructed.

Register multiple triggers

You can register multiple attribution triggers by adding multiple pixel elements on the conversion side (one per trigger). The attributionsrc element is optional for trigger registration .

You can also register multiple triggers from a single pixel element by using redirect requests or listing multiple URLs in the attributionsrc element in the same way as for source registration. Source events and trigger events that have been generated by the same origins will be matched.