Предложение по отчетности по атрибуции претерпело ряд изменений с учетом отзывов сообщества: от изменений механизма API до новых функций.
Журнал изменений
- 7 февраля 2022 г.: добавлен раздел о перенаправлении триггера заголовка .
- 27 января 2022 г.: статья впервые опубликована.
Для кого этот пост?
Этот пост для вас:
- Если вы уже разбираетесь в API — например, если вы наблюдали или участвовали в обсуждениях репозитория WICG и хотите понять пакет изменений, внесенных в предложение в январе 2022 года.
- Если вы используете API отчетов по атрибуции в демонстрационной версии или в эксперименте в рабочей среде.
Если вы только начинаете работать с этим API и/или еще не экспериментировали с ним, вместо этого перейдите непосредственно к введению в API .
Миграция впереди
Как только эти изменения будут реализованы в Chrome: если вы используете отчеты на уровне событий из API отчетов об атрибуции в демо-версии или в эксперименте в рабочей среде (первоначальная пробная версия), вам нужно будет отредактировать свой код, чтобы API продолжал работать. Вы также можете рассмотреть возможность использования новых функций.
В этой статье также перечислены изменения для агрегированных отчетов. Однако эти изменения, если они будут реализованы, не потребуют каких-либо действий или миграции, поскольку на момент написания этой статьи в браузере еще не реализована реализация агрегированных отчетов.
Изменение имени
Сводные отчеты и агрегированные отчеты
То, что вы раньше называли сводными отчетами, теперь будет называться сводными отчетами .
Сводные отчеты — это конечный результат объединения нескольких агрегируемых отчетов , ранее называвшихся вкладами или вкладами гистограмм.
Изменения механизма API
Регистрация источника на основе заголовка (отчеты на уровне событий)
Что меняется и почему?
Когда пользователь просматривает рекламу или нажимает на нее, браузер — локально на устройстве пользователя — записывает это событие вместе с параметрами, специфичными для отчетов по атрибуции (такими как attributionsourceeventid , attributiondestination , attributionexpiry и другие параметры). Значения этих параметров задаются рекламодателем.
Способ установки этих параметров меняется.
В предыдущем предложении параметры нужно было включать на стороне клиента: либо в теги привязки как атрибуты HTML, либо как аргументы вызова на основе JS. Параметры должны были быть известны во время клика или просмотра.
В новом предложении значение этих параметров определяется на сервере adtech.
Это имеет ряд преимуществ, особенно с точки зрения безопасности: механизм заголовка дает источнику отчетности (обычно рекламной технологии) прямой контроль над тем, зарегистрирован ли источник атрибуции в его области действия. Это частично снижает риск мошенничества, поскольку благодаря этому изменению настоящий браузер никогда не зарегистрирует источник без согласия источника сообщения.
Как происходит регистрация источника?
- Для данного объявления рекламному технологу теперь необходимо будет определить конкретный атрибут
attributionsrcна стороне клиента. Значением этого атрибута является URL-адрес, на который браузер отправит запрос; этот запрос будет включать новый HTTP-заголовокAttribution-Reporting-Source-Infoзначение которого,navigationилиevent,указывает, был ли источник кликом или просмотром соответственно. - Получив этот запрос, сервер отслеживания кликов/просмотров должен ответить HTTP-заголовком
Attribution-Reporting-Register-Source, который содержит нужные параметры атрибуции. Источник, возвращающий этот заголовок, теперь является источником отчетов (ранее определяемым как
attributionreportto).Заголовок HTTP-ответа
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Узнайте больше в техническом пояснении
Регистрация источников атрибуции
Присоединяйтесь к публичному обсуждению
Триггер атрибуции на основе заголовка (отчеты на уровне событий)
Что меняется и почему?
Подобно регистрации клика или просмотра, новое предложение заменяет триггер атрибуции (когда рекламная технология дает браузеру указание записать конверсию) на подход, основанный на заголовке.
Этот механизм согласован с регистрацией источника на основе заголовка и является более традиционным, чем ранее использовавшийся механизм перенаправления.
Кроме того, в новом предложении на странице конверсии необходим атрибут attributionsrc .
Обоснование заключается в разрешениях: в предыдущем предложении сайт на стороне триггера (обычно это сайт рекламодателя) имел общий контроль над функцией через заголовок Permissions-Policy , но не имел детального контроля на уровне элементов. может ли элемент отправить запрос стороне, которая в конечном итоге инициирует атрибуцию. attributionsrc меняет это: этот обязательный маркер дает рекламодателю возможность отслеживать и, следовательно, контролировать, какие элементы могут вызвать атрибуцию.
Обратите внимание, что на стороне источника (обычно на сайте издателя) присутствует элемент управления на уровне страницы через Permissions-Policy , а также элемент управления на уровне элемента через attributionsrc .
Как работает триггер атрибуции?
Получив запрос пикселя и приняв решение о том, что его следует классифицировать как конверсию, специалист по рекламе должен ответить новым HTTP-запросом.
заголовок Attribution-Reporting-Register-Event-Trigger .
Значение этого заголовка определяет, как обрабатывать событие триггера как объект JSON. Это та же информация, которая была определена как параметры запроса в предыдущем предложении.
Заголовок HTTP-ответа Attribution-Reporting-Register-Event-Trigger :
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Перенаправление (необязательно)
При желании сервер рекламных технологий может сделать ответ, содержащий Attribution-Reporting-Register-Event-Trigger ответом перенаправления. Благодаря этому третьи стороны могут наблюдать за событием конверсии и давать указание браузеру приписать его.
Перенаправление не является обязательным; в этом нет необходимости, если пиксели есть на странице как у рекламной технологии, так и у стороннего поставщика.
Подробности в Сторонней отчетности .
Узнайте больше в техническом пояснении
Присоединяйтесь к публичному обсуждению
Нет рабочего листа (агрегированные отчеты)
Что меняется и почему?
В предыдущем предложении для агрегированных отчетов требовался доступ к JavaScript для вызова ворлета — механизма на основе JavaScript, — который генерировал бы эти отчеты.
В новом предложении рабочий лист не требуется. Вместо этого рекламная технология будет определять декларативно — через HTTP-заголовки — правила, которые браузер должен использовать для создания агрегированных отчетов.
Новое предложение предлагает ряд преимуществ:
- Реализация в браузере: новый дизайн, в отличие от дизайна ворлета, существенно проще, поскольку не требует новой среды выполнения в браузерах.
- Опыт разработчиков: новый дизайн основан на заголовках, которые широко используются и широко известны разработчикам, в отличие от рабочих листов. Он также тесно связан с интерфейсом API для регистрации источников , что упрощает изучение и использование API.
- Внедрение: новый дизайн позволяет большему числу существующих измерительных систем использовать агрегированные отчеты. Многие решения для измерения поддерживают только HTTP: они полагаются на запросы изображений (запросы пикселей), которые не требуют доступа к JavaScript. Но поскольку метод ворлетов действительно требовал доступа к JavaScript, возможно, было сложно перейти на него с некоторых существующих систем измерения.
- Надежность: новый дизайн помогает уменьшить потерю данных, поскольку его легче интегрировать с семантикой
keepalive, например, если клик или просмотр регистрируются, когда пользователь покидает страницу.
Как работает механизм без ворлетов?
Этот декларативный механизм основан на заголовках HTTP — точно так же, как регистрация источника на уровне события и заголовок триггера атрибуции. Подробнее об этом в следующих разделах.
Присоединяйтесь к публичному обсуждению
Регистрация источника на основе заголовка (агрегированные отчеты)
Предлагается новый механизм регистрации источника сводного отчета; этот механизм аналогичен регистрации источника на уровне событий .
Отличается только имя заголовка: Attribution-Reporting-Register-Aggregatable-Source .
Узнайте больше в техническом пояснении
Регистрация источника атрибуции
Триггер атрибуции на основе заголовка (агрегированные отчеты)
Предлагается новый механизм регистрации источника сводного отчета; этот механизм аналогичен триггеру атрибуции на уровне события .
Отличается только имя заголовка: Attribution-Reporting-Register-Aggregatable-Trigger-Data .
Узнайте больше в техническом пояснении
Регистрация триггера атрибуции
Новые возможности
Сторонняя отчетность (отчеты на уровне событий и агрегированные отчеты)
Что меняется и почему?
Два аспекта нового предложения помогают лучше поддерживать сценарии использования сторонних отчетов:
- При желании рекламные специалисты могут перенаправлять сетевые запросы на другие серверы рекламных технологий , что позволяет этим другим рекламным технологиям использовать собственный источник и инициировать регистрацию. Сегодня это распространенный способ настройки третьих сторон. Это упрощает внедрение API, в том числе в существующие сторонние системы отчетности.
- Источники сообщений — обычно рекламные компании — больше не разделяют большинство ограничений конфиденциальности . Это поддерживает случаи использования, когда несколько рекламных технологий работают с одними и теми же издателями или рекламодателями.
Как работает сторонняя отчетность?
В новом предложении регистрация источника и триггер на основе ответа основаны на заголовках HTTP. Рекламная технология может использовать перенаправление HTTP для этих запросов.
Если запрос на клик/просмотр на сайте издателя (регистрация источника) впоследствии перенаправляется нескольким сторонам, каждая из этих сторон может зарегистрировать этот просмотр или клик (событие источника).
Аналогично, рекламная технология может перенаправить конкретный запрос атрибуции, сделанный с сайта рекламодателя, позволяя нескольким другим сторонам зарегистрировать конверсию (триггер атрибуции).
Каждая сторона может получить доступ к своим отдельным отчетам и настроить их с использованием отдельных данных.
Зарегистрируйте несколько триггеров без перенаправлений
Также можно зарегистрировать несколько триггеров атрибуции без использования перенаправлений, добавив несколько элементов пикселей на стороне конверсии (по одному на каждый триггер).
Присоединяйтесь к публичному обсуждению
Измерение просмотров (отчеты на уровне событий и агрегированные отчеты)
Что меняется и почему?
В новом предложении отслеживание просмотров и кликов работает единообразно:
-
registerattributionsrc, атрибут, специфичный для просмотра, который предписывал браузеру записывать просмотры вместе с кликами, больше не является частью предложения. - Механизмы конфиденциальности теперь унифицированы для кликов и просмотра. Подробности об этом смотрите в разделе «Шум и прозрачность» .
Это изменение предлагается согласовать с новым механизмом регистрации на основе заголовка . Это также упрощает работу разработчиков, если они планируют поддерживать измерение как кликов, так и просмотров.
Как работает отслеживание просмотров?
Измерение количества просмотров и количества кликов основано на регистрации на основе заголовка .
Узнайте больше в техническом пояснении
Отчеты на уровне событий (как по кликам, так и по просмотрам)
Присоединяйтесь к публичному обсуждению
Отладка/анализ производительности (отчеты на уровне событий и агрегированные отчеты)
Что меняется и почему?
В предложение добавлен механизм отладки, который поможет разработчикам обнаруживать ошибки, а также сравнивать производительность отчетов по атрибуции с существующими решениями для измерения на основе файлов cookie.
Как работает отладка?
Регистрация источника и триггера будет принимать новый параметр debug_key — 64-битное целое число без знака (то есть большое число).
Если отчет создается с ключами отладки источника и триггера и если файл cookie Samesite=None ar_debug=1 присутствует в банке cookie источника отчетов во время регистрации источника и триггера, отчет об отладке (JSON) будет отправлен в файл .well-known/attribution-reporting/debug :
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Отчеты на уровне событий и агрегированные отчеты также будут включать эти два новых параметра, чтобы их можно было связать с правильным отчетом об отладке.
Узнайте больше в техническом пояснении
Необязательно: расширенные отчеты об отладке.
Присоединяйтесь к публичному обсуждению
Возможности фильтрации (отчеты на уровне событий и агрегированные отчеты)
Что меняется и почему?
Поскольку они поддерживают важные варианты использования в современной рекламной экосистеме, ряд вариантов использования теперь будет поддерживаться как в отчетах на уровне событий, так и в агрегированных отчетах:
- Фильтрация конверсий: фильтрация конверсий на основе информации на стороне источника. Например, выберите разные триггерные данные (данные о конверсиях) для кликов и просмотров объявлений.
- Несоответствие атрибуции: фильтрация конверсий, которые были атрибуированы неправильно; это особый тип фильтрации конверсий. Например, отфильтруйте конверсии, которые соответствуют неправильному клику/просмотру объявления из-за области назначения etld+1 в API.
Как работают возможности фильтрации? (для отчетов на уровне событий)
Необязательное поле source_data в объекте JSON на стороне источника может определять элементы, которые впоследствии будут использоваться браузером во время преобразования для применения логики фильтрации.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
Регистрация триггера теперь будет принимать необязательный заголовок Attribution-Reporting-Filters .
Заголовок HTTP-ответа Attribution-Reporting-Filters :
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
В качестве альтернативы заголовок Attribution-Reporting-Register-Event-Trigger можно расширить с помощью поля filters , чтобы выполнить выборочную фильтрацию и установить trigger_data на основе source_data .
Если ключи в фильтрах JSON соответствуют ключам в source_data , триггер
полностью игнорируется, если перекресток пуст.
Узнайте больше в техническом пояснении
Дополнительные фильтры атрибуции
Присоединяйтесь к публичному обсуждению
Изменения в защите конфиденциальности
Шум и прозрачность (отчеты на уровне событий и агрегированные отчеты)
Что меняется и почему?
В новом предложении улучшен один из механизмов конфиденциальности отчетов: на отчеты предоставляется рандомизированный ответ .
Это означает, что некоторые реальные конверсии будут отражены правильно; и в определенном проценте случаев некоторые реальные конверсии будут подавляться или добавляться некоторые фальшивые конверсии .
Эта новая технология имеет несколько преимуществ:
- Он унифицирует механизм конфиденциальности кликов и просмотров.
- Это проще рассуждать, чем механизм, в котором данные триггера (данные преобразования) и шум канала триггера-источника будут разделены.
- Он устанавливает структуру конфиденциальности , которая при правильных настройках шума может гарантировать, что ни одна сторона не сможет полагаться на API, чтобы с уверенностью знать, что отдельный пользователь совершил (или нет) конверсию для определенной рекламы.
Этот новый механизм заменяет предыдущий механизм, в котором в 5% случаев данные триггера (данные конверсии) заменялись случайным значением.
Кроме того, в тело отчета добавлено значение рандомизированной вероятности ответа (поле randomized_trigger_rate ). В этом поле указывается вероятность (от 0 до 1) того, что источник получит рандомизированный ответ.
Это имеет два основных преимущества:
- Это делает базовое поведение браузера прозрачным для сторон, которые будут получать отчеты (обычно для специалистов по рекламе).
- Это полезно для будущего, когда API будет поддерживаться во всех браузерах : разные браузеры могут решить применять разные уровни шума в зависимости от своих целей конфиденциальности, и сторонам, которые будут обрабатывать отчет, потребуется это увидеть.
Как работает шум?
В новом предложении в момент регистрации источника (т. е. регистрации клика или просмотра объявления) браузер случайным образом решает, будет ли он правдиво атрибутировать конверсии и отправлять отчеты для этого клика/просмотра объявления или же он будет генерировать фейковую информацию . вместо этого выведите .
Ложный вывод может быть:
- Никакого отчета вообще — независимо от того, совершает ли пользователь конверсию;
- Один или несколько фейковых отчетов — независимо от того, совершает ли пользователь конверсию.
В поддельных отчетах триггерные данные (данные о конверсиях) являются случайными: случайное 3-битное значение для кликов (любое число от 0 до 7) и случайное 1-битное значение для просмотров (0 или 1).
Как и настоящие отчеты, фейковые отчеты не отправляются сразу после конверсии пользователя. Они отправляются в конце случайного окна отчетов .
Существует три окна отчетности по кликам (2 дня, 7 дней или 30 дней после клика). Каждый фейковый отчет случайным образом назначается одному из окон отчетов.
Отдельно, как уже говорилось в предыдущем предложении, порядок отчетов внутри окна является случайным.
Узнайте больше в техническом пояснении
Примеры шумных фейковых конверсий
Присоединяйтесь к публичному обсуждению
Ограничения отчетности (отчеты на уровне событий и агрегированные отчеты)
Отчетность об ограничениях происхождения
Что меняется и почему?
Новое предложение явно ограничивает количество сторон, которые могут измерять события между двумя площадками .
- Максимальное количество уникальных источников отчетов (обычно рекламных технологий), которые могут регистрировать источники для каждого {издателя, рекламодателя}, предлагается ограничить до 100 в течение 30 дней . Этот счетчик будет увеличиваться при каждом клике или просмотре объявления (исходное событие), даже если оно не атрибутировано.
- Максимальное количество уникальных источников отчетов (обычно рекламных технологий), которые могут отправлять отчеты на {издателя, рекламодателя}, предлагается ограничить до 10 в 30 дней . Этот счетчик будет увеличиваться для каждой приписываемой конверсии.
Эти ограничения должны быть достаточно высокими, чтобы не ограничивать возможности каких-либо субъектов измерять конверсии, но достаточно низкими, чтобы помочь смягчить некоторые формы злоупотреблений API.
Отчеты о времени восстановления/ограничениях скорости
Что меняется и почему?
Время восстановления отчетов — это механизм конфиденциальности, который ограничивает общий объем информации, отправляемой пользователю через этот API за определенный период времени.
В новом предложении можно запланировать 100 отчетов для каждого {исходного сайта, места назначения, источника отчетности} (обычно {издатель, рекламодатель, рекламная технология}) на 30 дней .
За пределами этого ограничения браузер перестанет планировать отчеты, соответствующие этому заданному {исходному сайту, месту назначения, источнику отчетов} (обычно {издатель, рекламодатель, рекламная технология}) — до тех пор, пока количество скользящих 30-дневных отчетов не упадет ниже 100 для этого {исходного сайта. , пункт назначения, отправитель сообщения}.
Узнайте больше в техническом пояснении
Отчеты о времени восстановления/ограничениях скорости
Ограничение целевых объектов (только отчеты на уровне событий)
Что меняется и почему?
Ограничение целевых мест изменено, чтобы включить в область источник отчета (обычно рекламную технологию): для каждого {publisher, adtech} разрешено 100 уникальных ожидающих целевых объектов (обычно сайты рекламодателей или сайты, на которых ожидаются конверсии).
Это защита конфиденциальности , позволяющая ограничить восстановление истории просмотров.
Узнайте больше в техническом пояснении
Ограничение количества уникальных направлений, охваченных ожидающими источниками.
Все ресурсы
- См. Отчеты по атрибуции .
- Прочтите Что следует знать об API .
Изображение заголовка от Дианы Полехиной на Unsplash .