Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

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

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

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

Размеры

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

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

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

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

Идентификатор кампании, географический идентификатор и категория продукта. — Размеры для отслеживания

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

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

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

Например, предположим, что вы отслеживаете параметры «Категория продукта», «Идентификатор географии» и «Идентификатор кампании».

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

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

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

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

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

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

Вопрос	Агрегированная стоимость = Цель измерения
Вопрос	Агрегированная стоимость = Цель измерения	Сколько покупок …	Количество покупок
Какой доход …	Стоимость покупки

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

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

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

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

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

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

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

Агрегированные отчеты

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

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

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

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

Агрегированный отчет содержит:

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

Агрегированные отчеты имеют формат 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 ). Бакет и значение являются байтовыми строками.

Ключи агрегирования на практике

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

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

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

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

Типы ключей

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

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

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

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

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

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

Размер ключа, размер размера

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

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

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

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

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

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

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

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

Примечание. Шестнадцатеричные данные обычно имеют префикс 0x . Например, 0x19 — это 19 в шестнадцатеричном формате; это 25 в десятичном формате, а не 19. Двоичные числа обычно имеют префикс 0b Например, 0b11001 — это 11001 в двоичном формате; это 25 в десятичном виде, а не 11 001.

Установите две части ключа для полного ключа.

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

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

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

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

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

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

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

Пример:

Ключевая часть на стороне источника = 0x159
Ключевая часть на стороне триггера = 0x400
Ключ = 0x159 v 0x400 = 0x559

Выравнивание ключевых деталей

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

Ключевая часть на стороне источника = 0xa7e297e7c8c8d0540000000000000000
Ключ на стороне спускового крючка = 0x0000000000000000674fbe308a597271
Ключ = 0xa7e297e7c8c8d0540000000000000000 v 0x0000000000000000674fbe308a597271 = 0xa7e297e7c8c8d054674fbe308a597271

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

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

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

Взгляните на стратегию Б в качестве еще одного примера.

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

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

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

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

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

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

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

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

Вот пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

Порядок размеров внутри ключа зависит от вас.

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

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

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

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

Согласно карте структуры ключей, этот ключ будет декодироваться в:

`11001 0 011 1100`

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

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

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

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

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

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

Вы можете думать о стратегии А как о стратегии «одного глубокого дерева»:

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

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

Вопрос	Отвечать
Какие категории продуктов являются наиболее ценными в каждом регионе?	Суммируйте суммарное количество и стоимость покупок, которые указаны в сводных отчетах, по всем кампаниям. Это дает вам количество и стоимость покупок для каждой категории Geo ID × Product. Для каждого региона сравните стоимость покупки и количество различных категорий товаров.
Какие стратегии кампаний наиболее эффективны в каждом регионе?	Суммируйте суммарное количество и стоимость покупок, представленных в сводных отчетах, по всем категориям продуктов. Это дает вам количество покупок и стоимость каждого идентификатора кампании × географического идентификатора. Для каждого региона сравните стоимость покупки и посчитайте для разных кампаний.

Вопрос

Отвечать

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

Суммируйте суммарное количество и стоимость покупок, которые указаны в сводных отчетах, по всем кампаниям.
Это дает вам количество и стоимость покупок для каждой категории Geo ID × Product.
Для каждого региона сравните стоимость покупки и количество различных категорий товаров.

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

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

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

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

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

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

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

Ключевая структура 1 и ключевая структура 2.

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

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

В итоге вы получите четыре типа ключей:

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

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

Вы можете думать о стратегии B как о стратегии «двух неглубоких деревьев»:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте сгенерируем ключевые части:

Ключевая часть исходного кода для идентификатора ключа…	Строка, содержащая значения измерения, которые вы хотите установить.	Хэш этой строки в шестнадцатеричном виде, обрезанный до первых 64 бит (64/4 = 16 символов ¹ ).	Шестнадцатеричный хэш с добавленными нулями для упрощения операции ИЛИ. Это ключевой момент на стороне источника.
`key_purchaseCount`	`COUNT, CampaignID=12, GeoID=7`	0x3cf867903fbb73ec	0x3cf867903fbb73ec0000000000000000
`key_purchaseValue`	`VALUE, CampaignID=12, GeoID=7`	0x245265f432f16e73	0x245265f432f16e730000000000000000

¹ Каждая шестнадцатеричная цифра представляет четыре бита (двоичные цифры).

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

// 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 .

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

Давайте сгенерируем ключевые части:

Ключ на стороне триггера для идентификатора ключа…	Строка, содержащая значения измерения, которые вы хотите установить.	Хэш этой строки в шестнадцатеричном виде, обрезанный до первых 64 бит (64/4 = 16 символов ¹ ).	Шестнадцатеричный хэш с добавленными нулями для упрощения операции ИЛИ. Это ключевой момент на стороне источника.
`key_purchaseCount`	`ProductCategory=25`	0x1c7ce88c4904bbe2	0x0000000000000000f9e491fe37e55a0c
`key_purchaseValue`	(такой же)	(такой же)	(такой же)

¹ Каждая шестнадцатеричная цифра представляет четыре бита (двоичные цифры).

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

// 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~~

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

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

В этом случае на каждую цель выделяется максимум CONTRIBUTION_BUDGET/2 (=65 536/2=32 768).

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

Ваш коэффициент масштабирования стоимости покупки должен составлять:

(( CONTRIBUTION_BUDGET /2) / 1500) = 32 768/1 500 = 21,8 ≈ 22

Ваш коэффициент масштабирования для количества покупок составляет 32 768/1 = 32 768, поскольку вы решили отслеживать не более одной покупки за клик или просмотр объявления (исходное событие).

Теперь вы можете установить эти значения:

key_purchaseCount : 1 × 32 768 = 32 768
key_purchaseValue : 52 × 22 = 1144

На практике вы можете установить их следующим образом, используя специальный заголовок 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,
  })
);

Формируется сводный отчет

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

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

[
  {
    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]
  },
]

Здесь вы можете увидеть два отдельных вклада в одном сводном отчете.

Запросить сводный отчет

Пакетные агрегированные отчеты. Следуйте советам, предлагаемым в разделе Пакетная обработка .
Сгенерируйте ключи, для которых вы хотите просмотреть данные. Например, чтобы просмотреть сводные данные для COUNT (общее количество покупок) и VALUE (общая стоимость покупок) для идентификатора кампании 12 × идентификатора географии 7 × категории продуктов 25:
- Создайте ключевую часть исходного кода, как вы это делали при настройке ее в браузере .
- Создайте ключевую часть на стороне триггера, как вы это делали при настройке ее в браузере .

Метрика, которую вы хотите запросить¹	Ключевая деталь на стороне источника	Ключ со стороны спускового крючка	Ключ для запроса к сервису агрегации ²
Общее количество покупок ( `COUNT` )	0x3cf867903fbb73ec 0000000000000000	0x00000000000000 00f9e491fe37e55a0c	0x3cf867903fbb73 ecf9e491fe37e55a0c
Общая стоимость покупки ( `VALUE` )	0x245265f432f16e73 0000000000000000	0x0000000000000000 f9e491fe37e55a0c	0x245265f432f16e73 f9e491fe37e55a0c

¹ показатель, который вы хотите запросить (для идентификатора кампании 12 × идентификатора географии 7 × категории продукта 25). ² Ключ для запроса к службе агрегации = Ключевая часть на стороне источника ИЛИ Ключевая часть на стороне триггера.

Запросить сводные данные в сервисе агрегации по этим ключам.

Обработка сводного отчета

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

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

Первый сегмент — это ключ COUNT в двоичном формате. Второй сегмент — это ключ VALUE в двоичном формате. Обратите внимание: хотя ключи неоднородны ( COUNT и VALUE ), они содержатся в одном отчете.

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

Уменьшите значения

2 558 500 означает количество покупок для этого ключа, увеличенное на ранее рассчитанный вами коэффициент масштабирования. Коэффициент масштабирования для количества покупок составил 32 768. Разделите 2 558 500 на бюджет вклада цели: 2 558 500/32 768 = 156,15 покупок.
687 060 → 687 060/22 = общая стоимость покупки 31 230 долларов США.

В результате сводные отчеты дают следующую информацию:

- 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.