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

Что такое ключи агрегирования, как они используются в 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
0000000000000000		 0x0000000000000000
00F9E491FE37E55A0C		 0x3CF867903FBB73
ECF9E491FE37E55A0C
Общая стоимость покупки ( VALUE ) 0x245265f432f16e73
0000000000000000		 0x0000000000000000
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.