Понимание ключей агрегирования для отчетов по атрибуции

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

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

1. Сколько покупок каждой категории товаров было совершено в рамках каждой из моих рекламных кампаний в каждом географическом регионе?
2. Какой доход принесла каждая из моих рекламных кампаний в каждом географическом регионе по каждой категории товаров?

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

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

Размеры, ключи и значения

Чтобы ответить на эти вопросы, давайте рассмотрим измерения, ключи и значения.

Размеры

Чтобы понять, как ваши рекламные кампании приносят доход, как описано здесь, вам потребуется отслеживать следующие параметры:

• Идентификатор рекламной кампании: идентификатор конкретной кампании.
• Географический идентификатор: географический регион, где было показано объявление.
• Категория товара: тип товара, как вы его определили.

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

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

Что такое ключи агрегации (корзины)?

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

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

Например, предположим, что вы отслеживаете такие параметры, как категория товара, географический идентификатор и идентификатор кампании.

Когда пользователь, находящийся в географической зоне с ID 7, видит рекламу для кампании с ID 12 и впоследствии совершает покупку товара в категории «Товары» с ID 25, вы можете установить ключ агрегации, который выглядит так, как показано на следующем изображении:

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

Что такое агрегируемые значения?

Чтобы ответить на ваши вопросы относительно указанных нами размеров, вам нужно знать:

• Количество покупок (сумма покупок). После агрегирования и отображения в сводном отчете это будет общее количество покупок (суммарное значение).
• Выручка от каждой покупки (стоимость покупки). После суммирования и отображения в сводном отчете это будет общая выручка (суммарная стоимость).

Каждый из этих показателей — количество покупок для одной конверсии и стоимость покупок для одной конверсии — является агрегируемым значением. Агрегируемые значения можно рассматривать как значения ваших целей измерения.

Когда пользователь, находящийся в географическом регионе с ID 7, видит рекламу для кампании с ID 12 и впоследствии совершает покупку товара из категории 25 за 120 долларов США (при условии, что ваша валюта — USD), вы можете установить ключ агрегации и агрегируемые значения, которые будут выглядеть следующим образом:

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

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

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

От ключей и значений до отчетов

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

Агрегируемые отчеты

Когда пользователь кликает на рекламу или просматривает её, а затем совершает покупку, вы указываете браузеру сохранить пару {ключ агрегации, агрегируемое значение}.

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

Позже вы увидите, что агрегируемый отчет, содержащий {ключ агрегации, агрегируемое значение}, выглядит не совсем так, но сейчас давайте сосредоточимся на информации, содержащейся в отчете.

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

Сводная отчетность содержит:

• Вклад(ы), который(е) вы настроили.
• Метаданные о событии клика или просмотра, а также о событии конверсии: сайт, где произошла конверсия, и многое другое. Все поля можно увидеть в сводном отчете .

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

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

• bucket : ключ агрегации, закодированный в виде байтовой строки.
• value : агрегируемое значение для данной цели измерения, закодированное в виде байтовой строки.

Вот пример:

{
  "data": [
    {
      "bucket": "111001001",
      "value": "11111010000",
    }
  ],
  "operation": "histogram"
}

На практике агрегируемые отчеты кодируются таким образом, что сегменты и значения выглядят иначе, чем в предыдущем примере (то есть сегмент может выглядеть как \u0000\u0000\x80\u0000 "). И сегмент , и значение являются байтовыми строками.

Сводные отчеты

Агрегируемые отчеты формируются на основе данных из множества браузеров и устройств (пользователей) следующим образом:

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

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

Сводный отчет содержит набор пар «ключ-значение» в формате словаря JSON. Каждая пара содержит:

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

Пример:

[
  {"bucket": "111001001", "value": "2558500"},
  {"bucket": "111101001", "value": "3256211"},
  {...}
]

На практике сводные отчеты кодируются таким образом, что сегменты и значения выглядят иначе, чем указано в примере (то есть, сегмент может выглядеть как \u0000\u0000\x80\u0000 "). И сегмент , и значение являются байтовыми строками.

Агрегационные ключи на практике

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

Ключевая структура

Термин «ключевая структура» будет использоваться для обозначения набора измерений, закодированных в ключе.

Например, ключевая структура — это идентификатор кампании × геолокационный идентификатор × категория товара.

Ключевые типы

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

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

В нашем предыдущем примере этот тип цели измерения мог бы иметь два различных возможных значения:

• Количество покупок — это первый тип целей измерения.
• Второй тип целей измерения – это ценность покупки .

Если у вас n целей измерения, то тип цели измерения будет иметь n различных типов значений.

Параметры ключа можно рассматривать как метрику. Например, «количество покупок определенного товара за одну кампанию в каждом регионе».

Ключевой размер, габаритные размеры

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

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

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

Например, параметр «Страна» может иметь мощность 200, поскольку в мире около 200 стран. Сколько бит необходимо для кодирования этого параметра?

7 бит позволят хранить только ^2⁷ = 128 различных вариантов, что меньше необходимых 200.

8 бит позволят хранить ^2⁸ = 256 различных вариантов, что больше необходимых 200, поэтому для кодирования этого измерения можно использовать n=8 бит.

Кодирование ключа

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

Для полного комплекта ключей используйте две ключевые детали.

Предположим, вы используете ключ для отслеживания следующих параметров:

• Идентификатор кампании
• Географический идентификатор
• Категория товара

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

На практике это означает, что вы установите клавишу в два этапа:

1. Вы зададите одну часть ключа — Идентификатор кампании × Идентификатор географического региона — в момент клика или просмотра.
2. Вторую часть ключа — категорию товара — вы установите во время конверсии.

Эти различные части ключей называются клавишными элементами.

Ключ вычисляется путем вычисления операции ИЛИ ( v ) его ключевых элементов.

Пример:

• Ключевой элемент со стороны источника = 0x159
• Ключевой элемент со стороны спускового крючка = 0x400
• Ключ = 0x159 v 0x400 = 0x559

Согласование ключевых элементов

Если два 64-битных фрагмента ключа расширить до 128 бит с помощью тщательно расположенных 64-битных заполнителей или смещений (шестнадцати нулей), то операция ИЛИ над фрагментами ключа эквивалентна их конкатенации, что проще для понимания и проверки:

• Ключевой фрагмент со стороны источника = 0xa7e297e7c8c8d0540000000000000000
• Ключевой элемент со стороны спускового крючка = 0x0000000000000000674fbe308a597271
• Ключ = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

Несколько ключевых слов на один клик или просмотр объявления

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

• Ключ, отслеживающий соотношение между идентификатором географического региона и идентификатором кампании.
• Ещё один ключевой параметр, отслеживающий тип креатива и идентификатор кампании.

В качестве еще одного примера рассмотрим Стратегию B.

Кодирование измерений в ключи

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

Сводные отчеты содержат необработанные пары {ключ, сводное значение}, без дополнительной информации о ключе. Это означает, что:

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

Кодирование измерений с использованием карт ключевой структуры.

Для кодирования параметров в ключи можно создать и поддерживать карту структуры ключей заранее, при определении ключей (до показа рекламы).

Схема ключевой структуры отображает каждое из ваших измерений и его положение в ключе.

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

Вот пример:

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

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

С учетом этих целей измерения ваш ключ будет иметь следующие размеры:

• Категория товара
• Тип цели измерения
• Географический идентификатор
• Идентификатор кампании

Теперь, рассмотрев каждое измерение, предположим, что в вашем случае вам необходимо отслеживать следующее:

• 29 различных категорий товаров.
• 8 различных географических регионов: Северная Америка, Центральная Америка, Южная Америка, Европа, Африка, Азия, Карибский бассейн и Океания.
• 16 различных кампаний.

Вот количество битов, которое вам потребуется для кодирования каждого измерения в вашем ключе:

• Категория продукта: 5 бит (2 ⁵ = 32 > 29).
• Тип цели измерения: 1 бит. Целью измерения является либо количество покупок, либо стоимость покупок, то есть две различные возможности; следовательно, одного бита достаточно для хранения этой информации.

• Идентификатор географического региона: 3 бита ( ^2³ = 8). Также необходимо определить карту измерений для идентификатора географического региона, чтобы знать, какой географический регион представляет каждое двоичное значение. Ваша карта измерений для идентификатора географического региона может выглядеть следующим образом:

  Двоичное значение в ключе	География
  000	Северная Америка
  001	Центральная Америка
  010	Южная Америка
  011	Европа
  100	Африка
  101	Азия
  110	Карибский бассейн
  111	Океания

• Идентификатор кампании: 4 бита (2 ⁴ = 16)

Ключи, имеющие такую ​​структуру, будут иметь длину 13 бит (5 + 1 + 3 + 4).

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

Порядок размеров в легенде выбирайте сами.

Чтобы проиллюстрировать, как измерения формируют ключевую структуру, мы будем использовать двоичное представление, поэтому идентификатор кампании (первые биты) находится справа, а категория продукта (последние биты) — слева.

В каждом измерении старший бит — тот, который имеет наибольшее числовое значение, — это самый левый бит. Младший бит — тот, который имеет наименьшее числовое значение, — это самый правый бит.

Давайте посмотрим, как можно использовать карту структуры ключа для расшифровки ключа.

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

Согласно схеме структуры ключа, этот ключ будет расшифрован следующим образом:

`11001 0 011 1100`

Таким образом, ключ 0b1100100111100 обозначает количество покупок товаров категории 25 для кампании с идентификатором 12, запущенной в Европе.

Кодирование измерений с использованием хеш-функции

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

Это работает следующим образом:

1. Выберите алгоритм хеширования.
2. При показе рекламы сгенерируйте строку, содержащую все параметры, которые вы хотите отслеживать, и их значения. Для генерации ключевого элемента на стороне источника, хешируйте эту строку и рассмотрите возможность добавления 64-битного суффикса из нулей, чтобы выровнять ее с ключевым элементом на стороне триггера и упростить логику оператора ИЛИ.
   • Ключевой элемент со стороны источника
     = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
   • Обратите внимание, что COUNT кодирует то же самое, что и measurementGoalType=0 в подходе с использованием карты ключевых структур. COUNT немного проще и понятнее.
3. При преобразовании сгенерируйте строку, содержащую все параметры, которые вы хотите отслеживать, и их значения. Чтобы сгенерировать ключевой элемент на стороне триггера, хешируйте эту строку и добавьте 64-битный префикс из нулей:
   • Ключевой элемент со стороны спускового крючка = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
4. Браузер выполняет операцию ИЛИ над этими ключевыми элементами для генерации ключа.
   • 128-битный ключ агрегации
     = <64-bit hex source-side key piece hash><64-bit hex source-side key piece hash>
5. Позже, когда вы будете готовы запросить сводный отчет по этому ключу, сгенерируйте его в режиме реального времени:
   • Исходя из интересующих вас параметров, создайте ключевые элементы для стороны источника и стороны триггера, как вы делали это ранее.
     • Ключевой элемент со стороны источника
       = <64-bit hex hash("COUNT, campaignID=12, geoID=7"))><64-bit 00000000…>
     • Ключевой элемент со стороны спускового крючка
       = <64-bit 00000000…><64-bit hex hash("productCategory=25")>
     • ключевой элемент со стороны триггера = toHex(hash("productCategory=25"))
   • Точно так же, как и в браузере, ИЛИ используйте эти ключевые элементы для генерации того же ключа, который браузер сгенерировал ранее.
     • 128-битный ключ агрегации
       = <64-bit source-side key piece hash><64-bit source-side key piece hash>

Несколько практических советов, если вы используете этот подход, основанный на хешировании:

• Всегда используйте один и тот же порядок измерений. Это гарантирует надежное восстановление хешей. ( "COUNT, CampaignID=12, GeoID=7" не сгенерирует тот же хеш, что и "COUNT, GeoID=7, CampaignID=12" ). Один из простых способов добиться этого — сортировать измерения по алфавиту и цифрам. Именно это мы и будем делать в примере , за исключением того, что мы всегда будем размещать COUNT или VALUE первым элементом в измерении — это сделано для удобства чтения, поскольку COUNT или VALUE кодируют информацию, которая концептуально немного отличается от всех остальных измерений.
• Следите за набором измерений, которые вы используете в ключах. Следует избегать генерации ключей на основе набора измерений, которые вы никогда не использовали.
• Коллизии хешей редки, если используется подходящая хеш-функция, но проверка на соответствие ранее использованным хешам (которые следует сохранить для интерпретации результатов от службы агрегации) может предотвратить появление новых ключей, которые могут конфликтовать со старыми ключами.

Посмотрите, как на практике использовать ключи на основе хешей, в примере "одна конверсия за клик или просмотр" .

Агрегируемые значения на практике

Компания, занимающаяся рекламными технологиями, устанавливает агрегируемые значения при совершении пользователем конверсии.

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

Мы будем называть этот лимит CONTRIBUTION_BUDGET . В пояснительной статье этот лимит называется бюджетом L1 , но он идентичен CONTRIBUTION_BUDGET .

Для более подробного обсуждения бюджета взносов см. раздел «Бюджет взносов» с краткими отчетами .

Пример: одна конверсия на клик или просмотр

В качестве примера предположим, что вы хотите ответить на следующие вопросы:

• Какие категории товаров являются наиболее ценными в каждом регионе?
• Какие стратегии проведения кампаний наиболее эффективны в каждом регионе?

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

Вам также необходимо отслеживать следующее:

• 16 различных кампаний.
• 8 различных географических регионов: Северная Америка, Центральная Америка, Южная Америка, Европа, Африка, Азия, Карибский бассейн и Океания.
• 29 различных категорий товаров.

Что измерять

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

В этом примере мы сосредоточимся на настройках кампаний, которые измеряют только одну конверсию за клик или просмотр: покупку.

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

А что насчет валют?

Проведение рекламных кампаний в разных регионах подразумевает учет валютных курсов. Вы можете:

• Выделите валюту в качестве отдельного параметра в ключах агрегации.
• Или же определить валюту по идентификатору кампании и конвертировать все валюты в эталонные валюты.

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

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

Превратите цели в ключевые понятия.

С учетом ваших целей и показателей измерения, у вас есть несколько вариантов для вашей ключевой стратегии. Давайте сосредоточимся на двух из этих стратегий:

• Стратегия А: одна детализированная ключевая структура.
• Стратегия Б: две основные ключевые структуры.

Стратегия А: одно глубокое дерево (одна гранулированная ключевая структура)

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

Все ваши ключи используют эту структуру.

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

• Тип ключа 0: тип цели измерения = 0, который вы определяете как количество покупок .
• Тип ключа 1: тип цели измерения = 1, который вы определяете как стоимость покупки .

Сводные отчеты выглядят следующим образом:

Стратегию А можно рассматривать как стратегию, построенную по принципу «одного вложенного дерева»:

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

Применяя стратегию А, вы бы ответили на свои вопросы следующим образом:

Применяя стратегию А, вы также можете напрямую ответить на третий вопрос:

«Какой доход принесла каждая из моих рекламных кампаний в каждом географическом регионе по каждому продукту?»

Несмотря на то, что сводные значения будут содержать шумы, вы можете определить, когда различия в измеренных значениях между кампаниями обусловлены не только шумом. Узнайте, как это сделать, в разделе «Понимание шума» .

Стратегия B: два неглубоких дерева (две грубые ключевые структуры)

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

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

• Тип цели измерения = 0, который вы определяете как количество покупок .
• Тип цели измерения = 1, который вы определяете как стоимость покупки .

В итоге получается четыре основных типа:

• Ключевой тип I-0: Ключевая структура I, количество покупок.
• Ключевой тип I-1: Ключевая структура I, стоимость покупки.
• Ключевой тип II-0: Ключевая структура II, количество покупок.
• Ключевой тип II-1: Ключевая структура II, стоимость покупки.

Сводные отчеты выглядят следующим образом:

Стратегию B можно рассматривать как стратегию "двух неглубоких деревьев":

• Сводные значения в сводных отчетах соответствуют одному из двух небольших наборов измерений.
• Вы можете суммировать эти сводные значения по каждому из измерений в этих наборах — это означает, что суммирование не такое подробное, как в варианте А, поскольку измерений для суммирования меньше.

При стратегии Б вы бы ответили на свои вопросы следующим образом:

Решение: Стратегия А

Стратегия А проще; все данные имеют одинаковую ключевую структуру, а это значит, что вам нужно поддерживать только одну ключевую структуру.

Однако при стратегии А вам необходимо суммировать сводные значения, полученные в сводных отчетах, чтобы ответить на некоторые из ваших вопросов. Каждое из этих сводных значений содержит шум. Суммируя эти данные, вы также суммируете шум .

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

Как определить, какую стратегию использовать? Для существующих рекламодателей или кампаний вы можете полагаться на исторические данные, чтобы определить, какой объем конверсий больше подходит для стратегии А или стратегии Б. Однако для новых рекламодателей или кампаний вы можете принять следующее решение:

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

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

Поскольку стратегия А проще и приводит к шумовому воздействию, которое не влияет на вашу способность принимать решения, вы решаете выбрать стратегию А.

Выберите алгоритм хеширования

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

Предположим, вы выбрали алгоритм SHA-256. Вы также можете использовать более простой, но менее безопасный алгоритм, например, MD5.

В браузере: задайте ключи и значения

Теперь, когда вы определились со структурой ключей и алгоритмом хеширования, вы готовы регистрировать ключи и значения, когда пользователи кликают на рекламу или просматривают её и впоследствии совершают конверсию.

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

Установите ключевые элементы со стороны источника.

Когда пользователь кликает на объявление или просматривает его, установите ключи агрегации в заголовке Attribution-Reporting-Register-Aggregatable-Source . На этом этапе для каждого ключа можно установить только ту его часть , которая известна на момент показа объявления.

Давайте выделим ключевые элементы:

Теперь давайте расставим ключевые элементы:

// Upon receiving the request from the publisher site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Source",
  JSON.stringify([
    {
      "id": "key_purchaseCount",
      "key_piece": "0x3cf867903fbb73ec0000000000000000"
    },
    {
      "id": "key_purchaseValue",
      "key_piece": "0x245265f432f16e730000000000000000"
    }
  ])
);

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

Дополнительно: отчеты на уровне событий

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

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

Пользователь совершает конверсию

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

• Для завершения формирования ключа необходимо указать ключевые элементы, относящиеся к конверсии (триггеру). Эти ключевые элементы задаются с помощью заголовка Attribution-Reporting-Register-Aggregatable-Trigger-Data .
• Укажите агрегируемое значение для этой конверсии, используя заголовок Attribution-Reporting-Register-Aggregatable-Values .

Установите ключевые элементы со стороны спускового крючка, чтобы завершить сборку ключа.

Давайте выделим ключевые элементы:

Теперь давайте расставим ключевые элементы:

// Upon receiving the pixel request from the advertiser site
res.set(
  "Attribution-Reporting-Register-Aggregatable-Trigger-Data",
  JSON.stringify([
    // Each dictionary independently adds pieces to multiple source keys
    {
      "key_piece": "0x0000000000000000f9e491fe37e55a0c",
      "source_keys": ["key_purchaseCount", "key_purchaseValue"]
    },
  ])
);

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

Задайте значения, допускающие агрегирование.

Прежде чем задавать агрегируемые значения, необходимо масштабировать их, чтобы уменьшить шум.

Предположим, была совершена покупка товара типа 25 на сумму 52 доллара.

Вы не будете задавать их напрямую в качестве агрегируемых значений:

• key_purchaseCount : 1 конверсия
• key_purchaseValue : $52

Вместо этого, прежде чем регистрировать эти агрегируемые значения, необходимо масштабировать их, чтобы минимизировать шум.

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

In this case, each goal is allocated a maximum of CONTRIBUTION_BUDGET/2 (=65,536/2=32,768).

Let's assume the maximum purchase value for a single user, based on purchase history across all users of the site, is $1,500. There may be outliers, for example very few users who spent over that sum, but you may decide to ignore these outliers.

Your scaling factor for the purchase value should be:

(( CONTRIBUTION_BUDGET /2) / 1,500) = 32,768/1,500 = 21.8 ≈ 22

Your scaling factor for purchase count is 32,768/1 = 32,768, since you decided to track at most one purchase per ad click or view (source event).

You can now set these values:

• key_purchaseCount : 1 × 32,768 = 32,768
• key_purchaseValue : 52 × 22 = 1,144

In practice, you would set them as follows, using the dedicated header Attribution-Reporting-Register-Aggregatable-Values :

// Instruct the browser to schedule-send a report
res.set(
  "Attribution-Reporting-Register-Aggregatable-Values",
  JSON.stringify({
    "key_purchaseCount": 32768,
    "key_purchaseValue": 1144,
  })
);

The aggregatable report is generated

The browser matches the conversion to a previous view or click and generates an aggregatable report, which includes the encrypted payload next to report metadata.

The following is an example of the data that could be found within the payload of the aggregatable report, if it was readable in cleartext:

[
  {
    key: 0x3cf867903fbb73ecf9e491fe37e55a0c, // = source-side key piece OR conversion-side key piece for the key key_purchaseCount
    value: 32768 // the scaled value for 1 conversion, in the context of [CONTRIBUTION_BUDGET/2]
  },
  {
    key: 0x245265f432f16e73f9e491fe37e55a0c, // source-side key piece OR conversion-side key piece for the key key_purchaseValue
    value: 1144 // the scaled value for $52, in the context of [CONTRIBUTION_BUDGET/2]
  },
]

Here, you can see two separate contributions within one single aggregatable report.

Request a summary report

• Batch aggregatable reports. Follow the advice offered in Batching .
• Generate the keys you want to see data for. For example, to see summary data for COUNT (total number of purchases) and VALUE (total purchase value) for the Campaign ID 12 × Geography ID 7 × Product category 25:
  • Generate the source-side key piece, as you did when setting it in the browser .
  • Generate the trigger-side key piece, as you did when setting it in the browser .

• Request summary data to the aggregation service for these keys.

Handle the summary report

Ultimately, you receive a summary report that may look like this:

[
  {"bucket": "00111100111110000110011110010000001111111011101101110011111011001111100111100100100100011111111000110111111001010101101000001100",
    "value": "2558500"},
  {"bucket": "00100100010100100110010111110100001100101111000101101110011100111111100111100100100100011111111000110111111001010101101000001100",
    "value": "687060"},
  …
]

The first bucket is the COUNT key in binary. The second bucket is the VALUE key in binary. Note that while the keys are heterogeneous ( COUNT versus VALUE ), they're contained in the same report.

Scale down the values

• 2,558,500 refers to the number of purchases for this key, scaled up by your previously calculated scaling factor. The scaling factor for the purchase count was 32,768. Divide 2,558,500 by the goal's contribution budget: 2,558,500/32,768 = 156.15 purchases.
• 687,060 → 687,060/22 = $31,230 total purchase value.

As a result, the summary reports give you the following insights:

- Within the reporting time period, campaign #12
  run in Europe drove about 156 purchases (± noise)
  for the product category #25
  ```

  ```text
- Within the reporting time period, campaign #12
  run in Europe drove $31,230 of purchases (± noise)
  for the product category #25.