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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробности реализации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для отчетов о сигналах Protected Audience функция registerAdBeacon доступна внутри отчетных ворклетов, а registerAdMacro доступна внутри отчетного ворклета buyer's win. Затем данные о событиях внутри фрейма рекламы можно добавить к зарегистрированным маякам и макросам с помощью функций reportEvent и setReportEventDataForAutomaticBeacons API отчетов Fenced Frame Ads . Это позволяет связать друг с другом сигналы отчетов Protected Audience и полезную нагрузку события фрейма креатива рекламы.

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

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

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

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

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

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

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

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

Шаг 3: Настройте ответы на запросы API Attribution Reporting

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

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

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

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