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

Что такое ключи агрегирования, как они используются в 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 n различных вариантов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые части с использованием XOR.

Пример:

  • Ключевая часть исходной стороны = 0x159
  • Ключевая часть на стороне триггера = 0x400
  • Ключ = 0x159 ^ 0x400 = 0x559

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

Карта ключевой структуры.

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

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

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

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

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

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

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

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

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

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

  1. Выберите алгоритм хеширования.
  2. Во время показа объявления создайте строку, включающую все параметры, которые вы хотите отслеживать, и их значения. Чтобы сгенерировать ключевую часть на стороне источника, хэшируйте эту строку и рассмотрите возможность добавления 64-битного суффикса из нулей, чтобы выровнять ее с ключевой частью на стороне триггера и упростить анализ XOR.
    • Ключевая деталь на стороне источника
      = <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. Браузер выполняет XOR для этих ключевых частей, чтобы сгенерировать ключ.
    • 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"))
    • Как и в случае с браузером, выполните XOR для этих ключевых частей, чтобы сгенерировать тот же ключ, который браузер сгенерировал ранее.
      • 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.
Для каждого региона сравните стоимость покупки и количество различных категорий товаров.
Какие стратегии кампаний наиболее эффективны в каждом регионе? Суммируйте суммарное количество и стоимость покупок, представленных в сводных отчетах, по всем категориям продуктов.
Это дает вам количество покупок и стоимость каждого идентификатора кампании × географического идентификатора.
Для каждого региона сравните стоимость покупки и посчитайте для разных кампаний.

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

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

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

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

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

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

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

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

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

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

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

Стратегия сводного отчета B.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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 символов 1 ). Шестнадцатеричный хеш с добавленными нулями для упрощения операции XOR. Это ключевой момент на стороне источника.
key_purchaseCount ProductCategory=25 0x1c7ce88c4904bbe2 0x0000000000000000f9e491fe37e55a0c
key_purchaseValue (такой же) (такой же) (такой же)
1 Каждая шестнадцатеричная цифра представляет четыре бита (двоичные цифры).

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

// 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 XOR 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 XOR 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:
Метрика, которую вы хотите запросить 1 Ключевая часть исходной стороны Ключевой кусок триггерной стороны Ключ для запроса в службу агрегации 2
Общее количество покупок ( COUNT ) 0x3CF867903FBB73EC
000000000000000000		 0x0000000000000000
00F9E491FE37E55A0C		 0x3CF867903FBB73
ECF9E491FE37E55A0C
Общая стоимость покупки ( VALUE ) 0x245265f432f16e73
000000000000000000		 0x000000000000000000
F9E491FE37E55A0C		 0x245265f432f16e73
F9E491FE37E55A0C
1 метрика, которую вы хотите запросить (для идентификатора кампании 12 × география ID 7 × категория продукта 25). 2 Ключ для запроса на службу агрегации = ключ на стороне исходной стороны xor.
  • Запросите сводные данные в службу агрегации для этих ключей.

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

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

[
  {"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 долл. США Общая стоимость покупки.

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

  • В течение периода времени отчетности кампания № 12 в Европе проехала около 156 покупок (± шум) для категории продукта № 25.
  • В течение периода отчетности кампания № 12 в Европе принесла 31 230 долларов покупок (± шум) для категории продукта № 25.
,

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

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

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

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

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

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

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

Размеры

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

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

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

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

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

Что такое клавиши агрегации (ведра)?

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

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

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

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

Ключ агрегации для преобразования.

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

Каковы агрегируемые ценности?

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

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

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

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

Когда пользователь, расположенный в Geography Id 7, видит объявление о ID Campaign ID 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 ). Ведре и ценность - оба.

Ключи агрегации на практике

Ключи агрегации (ведра) определяются компанией Ad Tech, как правило, в двух шагах: когда реклама нажимается или просматривается, и когда пользователь преобразуется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключ рассчитывается путем взятия XOR ( ^ ) своих ключевых частей.

Ключевые кусочки XOR-ing.

Пример:

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

Выравнивание ключевых кусочков

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

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

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

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

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

Взгляните на стратегию B для другого примера.

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

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

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

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

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

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

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

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

Вот пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно карте структуры ключей, этот ключ будет декодировать на 11001 0 011 1100 .

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

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

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

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

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

Посмотрите, как использовать хэш-ключи на практике в примере One Conversion Per Click или View .

Агрегируемые ценности на практике

Ad Tech Company устанавливает обширные значения, когда пользователь преобразуется.

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

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

Для углубленного обсуждения бюджета взносов см. Бюджет взносов для сводных отчетов .

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

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

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

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

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

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

Что измерить

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

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

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

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

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

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

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

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

Перевести цели в ключи

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

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

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

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

Одна гранулированная ключевая структура

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

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

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

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

Стратегия Краткий отчет.

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

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

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

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

Со стратегией A вы также можете напрямую ответить на этот третий вопрос:

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

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

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

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

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

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

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

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

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

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

Стратегия сводного отчета B.

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

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

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

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

Решение: стратегия а

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

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

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

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

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

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

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

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

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

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

В браузере: установите клавиши и значения

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

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

Зарегистрируйте ключи и значения для просмотра или нажмите.
Register keys and values for a conversion.

Set source-side key pieces

When a user clicks or views an ad, set the aggregation keys in the Attribution-Reporting-Register-Aggregatable-Source header. At this stage, for each key, you can only set the part of the key, or key piece , that's known at ad-serving time.

Let's generate the key pieces:

Source-side key piece for the key ID… String containing the dimension values you want to set Hash of this string as hex, trimmed to the first 64 bits (64/4 = 16 characters 1 ) Hex hash with appended zeros to simplify XOR-ing. This is the source-side key piece.
key_purchaseCount COUNT, CampaignID=12, GeoID=7 0x3cf867903fbb73ec 0x3cf867903fbb73ec0000000000000000
key_purchaseValue VALUE, CampaignID=12, GeoID=7 0x245265f432f16e73 0x245265f432f16e730000000000000000
1 Each hexadecimal digit represents four bits (binary digits).

Let's now set the key pieces:

// 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"
    }
  ])
);

Note that key IDs will not appear in the final reports. They're only used when setting keys in the browser, so that source-side and trigger-side key pieces can be mapped with each other and combined into a full key.

Optional: event-level reports

If you need to use event-level reports alongside aggregatable reports ensure that for a given source, the event-level data (source event ID and trigger data) and the aggregation key can be matched.

You might use both reports if, for example, you plan to use event-level reports to run models on which types of ads tend to lead to the greatest number of purchases.

A user converts

When a user converts, a pixel request is typically sent to the ad tech server. Upon receiving this request:

  • Set the conversion-side (trigger-side) key pieces to complete the key. You'll set these key pieces via the header Attribution-Reporting-Register-Aggregatable-Trigger-Data .
  • Set the aggregatable value for that conversion, via the header Attribution-Reporting-Register-Aggregatable-Values .

Set trigger-side key pieces to complete the key

Let's generate the key pieces:

Trigger-side key piece for the key ID… String containing the dimension values you want to set Hash of this string as hex, trimmed to the first 64 bits (64/4 = 16 characters 1 ) Hex hash with appended zeros to simplify XOR-ing. This is the source-side key piece.
key_purchaseCount ProductCategory=25 0x1c7ce88c4904bbe2 0x0000000000000000f9e491fe37e55a0c
key_purchaseValue (такой же) (такой же) (такой же)
1 Each hexadecimal digit represents four bits (binary digits).

Let's now set the key pieces:

// 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"]
    },
  ])
);

Note how you're adding the same key piece to several keys, by listing several key IDs in source_keys —the key piece will be added to both keys.

Set aggregatable values

Before you set the aggregatable values, you need to scale them up in order to reduce noise.

Let's assume one purchase was made for product type 25 for $52.

You won't set these directly as aggregatable values:

  • key_purchaseCount : 1 conversion
  • key_purchaseValue : $52

Instead, before you register these aggregatable values, you need to scale them in order to minimize noise.

You have two goals to spend your contribution budget against, so you might decide to split the contribution budget in two.

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 XOR 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 XOR 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:
Metric you want to request 1 Source-side key piece Trigger-side key piece Key to request to the aggregation service 2
Total purchase count ( COUNT ) 0x3cf867903fbb73ec
0000000000000000		 0x00000000000000
00f9e491fe37e55a0c		 0x3cf867903fbb73
ecf9e491fe37e55a0c
Total purchase value ( VALUE ) 0x245265f432f16e73
0000000000000000		 0x0000000000000000
f9e491fe37e55a0c		 0x245265f432f16e73
f9e491fe37e55a0c
1 Metric you are looking to request (for Campaign ID 12 × Geography ID 7 × Product category 25). 2 Key to request to the aggregation service = Source-side key piece XOR Trigger-side key piece.
  • 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.
  • Within the reporting time period, campaign #12 run in Europe drove $31,230 of purchases (± noise) for the product category #25.