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

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

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

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

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

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

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

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

Размеры

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

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

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

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

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

Термины ключ агрегации и контейнер обозначают одно и то же. Ключ агрегации используется в 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 ⁿ различных вариантов.

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

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

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

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

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

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

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

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

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

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

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

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

Ключ вычисляется путем вычисления OR ( 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 бит. Целью измерения является либо количество покупок, либо стоимость покупки, что означает две различные возможности; поэтому для хранения этого достаточно одного бита.

• Geography ID: 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, запущенной в Европе.

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

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

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

1. Выберите алгоритм хеширования.
2. Во время показа рекламы сгенерируйте строку, которая включает все измерения, которые вы хотите отслеживать, и их значения. Чтобы сгенерировать часть ключа на стороне источника, хэшируйте эту строку и рассмотрите возможность добавления 64-битного суффикса из нулей, чтобы выровнять ее с частью ключа на стороне триггера и упростить рассуждение об OR.
   • Ключевая часть на стороне источника
     = <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 различных категорий продуктов.

Что измерять

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

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

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

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

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

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

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

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

Переводим цели в ключи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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,
  })
);

Созданный отчет генерируется

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

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

[
  {
    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:
  • Сгенерируйте ключевую часть на стороне источника, как вы делаете при настройке в браузере .
  • Сгенерируйте кусок ключа на стороне триггера, как и при настройке его в браузере .

• Запросите сводные данные в службу агрегации для этих ключей.

Обрабатывать сводный отчет

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

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

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

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

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