Отчеты по атрибуции: полный обзор системы

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

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

Прежде чем продолжить, обязательно ознакомьтесь с обзором отчетов по атрибуции . Это поможет вам понять назначение API и порядок формирования различных отчетов ( отчеты на уровне событий и сводные отчеты ). Если вы столкнетесь с незнакомыми терминами, обратитесь к глоссарию терминов в «Песочнице конфиденциальности» .

Для кого предназначен этот документ?

Вам следует прочитать этот документ, если:

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

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

Обзор

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

• Примите решения по дизайну . Определите, какую информацию вы хотите собрать, выявите ожидаемые конверсии от каждой конкретной кампании и определите, какой тип отчета следует использовать. В результате вы получите один или оба типа отчетов: отчеты по отдельным событиям и сводные отчеты.

Для формирования отчетов всегда используются два (а иногда и три) компонента, которые работают вместе:

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

Если вы собирали сводные отчеты, вам понадобится третий компонент:

• Создание сводного отчета . Создавайте агрегируемые отчеты в пакетном режиме и используйте службу агрегации для обработки отчетов и генерации сводного отчета.

проектные решения

Ключевой принцип отчетности по атрибуции — это принятие решений на ранних этапах проектирования. Вы определяете, какие данные собирать, в каких категориях и как часто их обрабатывать. Полученные отчеты предоставляют ценную информацию о ваших кампаниях или бизнесе.

Результатом работы отчета может быть:

• Отчеты на уровне событий связывают конкретный клик или просмотр объявления (на стороне объявления) с данными на стороне конверсии. Для сохранения конфиденциальности пользователей путем ограничения сопоставления данных о пользователях на разных сайтах, данные на стороне конверсии очень ограничены и содержат много шума (это означает, что в небольшом проценте случаев вместо реальных отчетов отправляются случайные данные).
• Сводные отчеты не привязаны к конкретному событию на стороне объявления. Эти отчеты предоставляют более подробные данные о конверсиях и гибкость для объединения данных о кликах и просмотрах с данными о конверсиях.

Выбор типа отчета определяет, какие данные вам потребуется собрать.

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

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

Взаимодействие между веб-сайтом и браузером

Поток событий атрибуции

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

1. На сайте издателя рекламный элемент (тег <a> или <img> ) настраивается со специальным атрибутом attributionsrc . Его значением является URL-адрес, например, https://adtech.example/register-source/ad_id=... .

   Вот пример ссылки, которая при нажатии регистрирует источник:

   <a href="https://shoes.example/landing"
     attributionsrc="http://adtech.example/register-source?..."
     target="_blank">
   Click me</a>
   

   Вот пример изображения, которое при просмотре вызовет регистрацию источника:

   <img href="https://advertiser.example/landing"
     attributionsrc="https://adtech.example/register-source?..."/>
   

   В качестве альтернативы, вместо HTML-элементов, можно использовать вызовы JavaScript.

   Вот пример использования window.open() на JavaScript. Обратите внимание, что URL-адрес закодирован в формате URL, чтобы избежать проблем со специальными символами.

   const encodedUrl = encodeURIComponent(
     'https://adtech.example/attribution_source?ad_id=...');
   window.open(
     "https://shoes.example/landing",
     "_blank",
     `attributionsrc=${encodedUrl}`);
   

2. Когда пользователь кликает на объявление или просматривает его, браузер отправляет GET запрос на адрес attributionsrc — как правило, это конечная точка рекламодателя или поставщика рекламных технологий.

3. Получив этот запрос, рекламодатель или поставщик рекламных технологий решает дать указание браузеру зарегистрировать события-источники взаимодействия с рекламой, чтобы в дальнейшем конверсии можно было связать с этой рекламой. Для этого рекламодатель или поставщик рекламных технологий включает в свой ответ специальный HTTP-заголовок. К этому заголовку он добавляет пользовательские данные, предоставляющие информацию о событии-источнике (клик или просмотр рекламы) — если в результате просмотра этой рекламы произойдет конверсия, эти пользовательские данные в конечном итоге будут отображены в отчете об атрибуции.

   

4. Позже пользователь переходит на сайт рекламодателя.

5. На каждой соответствующей странице сайта рекламодателя — например, на странице подтверждения покупки или странице товара — пиксель конверсии (элемент <img> ) или вызов JavaScript отправляет запрос по адресу https://adtech.example/conversion?param1=...&param2=... .

6. Запрос получает сервис по этому URL-адресу — как правило, рекламодатель или поставщик рекламных технологий. Он решает классифицировать его как конверсию, поэтому ему необходимо дать указание браузеру зарегистрировать конверсию, то есть запустить атрибуцию . Для этого рекламодатель или поставщик рекламных технологий включает в свой ответ на запрос пикселя специальный HTTP-заголовок, содержащий пользовательские данные о конверсии.

7. Браузер на локальном устройстве пользователя получает этот ответ и сопоставляет данные о конверсии с исходным событием (клик по объявлению или просмотр).

8. Браузер планирует отправку отчета в attributionsrc . Этот отчет включает в себя:

   1. Пользовательские данные конфигурации атрибуции, которые поставщик рекламных технологий или рекламодатель прикрепил к исходному событию на шаге 3.
   2. Пользовательский набор данных о конверсиях на шаге 6.

   

9. Позже браузер отправляет отчеты на конечную точку, определенную в attributionsrc , с некоторой задержкой и шумом. Агрегируемые отчеты шифруются, в то время как отчеты на уровне событий — нет.

Триггеры атрибуции (веб-сайт рекламодателя)

Триггер атрибуции — это событие, которое сообщает браузеру о необходимости фиксировать конверсии.

Мы рекомендуем фиксировать наиболее важные для рекламодателя конверсии, такие как покупки. В сводных отчетах можно фиксировать различные типы конверсий и метаданные.

Это подтверждает, что сводные результаты по этим событиям являются подробными и точными.

Сопоставьте источники с триггерами

Когда браузер получает ответ от триггера атрибуции, он обращается к локальному хранилищу, чтобы найти источник, который соответствует как источнику триггера атрибуции, так и eTLD+1 URL этой страницы.

Например, когда браузер получает триггер атрибуции от adtech.example по адресу shoes.example/shoes123 , он ищет в локальном хранилище источник, который соответствует как adtech.example , так и shoes.example .

Можно установить фильтры (или пользовательские правила), определяющие, когда триггер соответствует определенному источнику. Например, можно установить фильтр, который будет учитывать только конверсии для определенной категории товаров и игнорировать все остальные категории. Фильтры и модели приоритезации позволяют создавать более сложные отчеты по атрибуции.

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

Сбор данных

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

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

Отчеты по отдельным событиям отправляются с задержкой от 2 до 30 дней. Агрегированные отчеты отправляются со случайной задержкой в ​​течение одного часа, и события должны укладываться в бюджет сбора средств . Эти решения защищают конфиденциальность и предотвращают использование действий отдельных пользователей в корыстных целях.

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

Создание сводного отчета

Для создания сводных отчетов вы будете использовать сервис агрегации (управляемый рекламной технологической компанией) для обработки агрегируемых отчетов. Сервис агрегации добавляет «шум» для защиты конфиденциальности пользователей и возвращает итоговый сводный отчет.

Пакетные агрегируемые отчеты

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

Пакеты данных должны содержать множество отчетов, чтобы обеспечить высокое соотношение сигнал/шум.

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

Сервис агрегации

Служба агрегации отвечает за обработку агрегируемых отчетов для генерации сводного отчета. Агрегируемые отчеты зашифрованы и могут быть прочитаны только службой агрегации, которая работает в доверенной среде выполнения (TEE).

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

Специалисты могут создавать агрегируемые отчеты в открытом текстовом формате для локального тестирования сервиса агрегации . Или же можно протестировать сервис с помощью зашифрованных отчетов на AWS с использованием Nitro Enclaves .

Что дальше?

Мы хотим вступить с вами в диалог, чтобы убедиться, что мы создаём API, который будет работать для всех.

Обсудите API

Как и другие API для «песочниц конфиденциальности», этот API документирован и обсуждается публично .

Поэкспериментируйте с API.

Вы можете поэкспериментировать и поучаствовать в обсуждении API для составления отчетов об атрибуции.