Большинство рекламодателей работают с несколькими различными рекламными сетями для показа рекламы в приложениях издателей. Если рекламные сети регистрируют собственные источники атрибуции и триггеры с помощью API, они будут получать отчеты о событиях и сводках с собственной атрибутикой.
Однако рекламодатели, желающие использовать третью сторону для выполнения кросс-сетевой атрибуции (XNA) с целью определения единственного выигрышного объявления для данной конверсии, могут продолжать делать это, используя следующие методы:
- Настройте внутренний сервер для регистрации событий триггера и получения отчетов об атрибуции от API
- Продолжайте использовать существующего партнера по мобильным измерениям
Независимо от того, какой метод выберет рекламодатель, API отчетов об атрибуции поддерживает ряд различных функций, которые позволяют третьей стороне настраивать логику XNA от имени рекламодателя:
- Третья сторона может выполнять атрибуцию с помощью API с перенаправлениями из рекламных сетей или без них .
- Приоритет, фильтры и ключи дедупликации могут обеспечить дополнительную настройку атрибуции на основе параметров источника и триггера.
- Окна атрибуции после установки позволяют источникам, которые привели к установке, продолжать получать кредиты за будущие события конверсии в приложении.
Модель атрибуции, которую используют специалисты по рекламе для межсетевой дедупликации и выбора выигрышных источников, может иметь разный уровень сложности в зависимости от того, как используются эти функции API.
Следующие примеры иллюстрируют сценарии использования этих функций и то, как различные конфигурации влияют на то, какой источник атрибуции в конечном итоге получит кредит для данного события-триггера.
Процесс
В следующем списке перечислены этапы процесса XNA. Для простоты перечисленные здесь этапы предполагают модель, в которой рекламодатель использует обслуживающую рекламную технологию для доставки рекламы и MMP для измерения конверсии. Однако дизайн API является гибким — функциональность не отличается в зависимости от разных типов рекламных технологий, и он не требует использования рекламной технологии.
- Регистрация источника : пользователь просматривает или нажимает на рекламу, и техническая служба обслуживания рекламы регистрирует эти источники с помощью API. Техническая служба обслуживания рекламы может также перенаправлять других технических служб рекламы, которые также могут регистрировать источники напрямую с помощью API или включать кросс-сетевую атрибуцию без перенаправлений .
- Регистрация триггера : пользователь выполняет действие, связанное с конверсией, например, первое открытие приложения, покупку или добавление в корзину, после чего MMP регистрирует триггер с помощью API. MMP также может перенаправлять к другим рекламным специалистам, которые могут регистрировать триггеры напрямую с помощью API. Если MMP необходимо включить кросс-сетевую атрибуцию без перенаправлений , необходимо указать конфигурацию атрибуции во время регистрации триггера.
- Attribution : Если конфигурация attribution указана во время регистрации триггера, производные источники генерируются от имени MMP. Каждый триггер пытается сопоставить либо с допустимым источником, зарегистрированным непосредственно MMP, либо с допустимым производным источником, сгенерированным от имени MMP с использованием источников обслуживающей рекламной технологии. Оставшиеся источники, которые не выиграли атрибуцию, удаляются и больше не могут выиграть атрибуцию для будущих конверсий. Вы также можете увидеть это как «проиграть один раз, проиграть всегда» в других частях документации.
- Когда производный источник теряет атрибуцию, API не будет генерировать будущие производные источники на основе исходного источника, когда будущие события конверсии регистрируются MMP. Технология обслуживания рекламы и другие MMP могут по-прежнему использовать исходный источник для будущей атрибуции. Это подробно описано в Сценарии 6 .
- Генерация отчетов : Атрибуция приводит к генерации отчета о событиях или совокупном отчете. Обратите внимание, что для производных источников генерируются только совокупные отчеты.
- Доставка отчетов : Сформированные отчеты планируются к отправке.
Сценарий 1: Кросс-сетевая атрибуция с перенаправлениями
Рекламодатель работает с 2 обслуживающими рекламными технологиями и 1 MMP. Когда кликают по объявлениям, обслуживаемым обслуживающими рекламными технологиями, обслуживающие рекламные технологии перенаправляют на MMP при регистрации источника. Когда пользователь конвертируется в приложении, MMP перенаправляет на рекламных технологий при регистрации триггера.
MMP получит кросс-сетевой дедуплицированный отчет, а каждая обслуживающая рекламная технология получит отчеты с собственной атрибутикой.
Хронология регистраций
В момент t0 пользователь нажимает на рекламу, размещенную ad-tech1, которая регистрирует источник Source1 вместе с его перенаправлением Source2 от mmp-ad-tech:
"Attribution-Reporting-Register-Source": {
"source_event_id": "34532",
"web_destination": "https://destination.example.com",
"priority": "10",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x1"
}
},
"Attribution-Reporting-Redirect": [
"https://www.mmp-ad-tech.com/source2"
]
// Registered by mmp-ad-tech using redirects
"Attribution-Reporting-Register-Source": {
"source_event_id": "788324",
"web_destination": "https://destination.example.com",
"priority": "30",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x2",
"geoValue": "0x102"
}
}
В момент t1 пользователь нажимает на рекламу, размещенную ad-tech2, чтобы зарегистрировать Source3 вместе с его перенаправлением на mmp-ad-tech (Source4):
"Attribution-Reporting-Register-Source": {
"source_event_id": "6574435",
"web_destination": "https://destination.example.com",
"priority": "10",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x3"
}
},
"Attribution-Reporting-Redirect": [
"https://www.mmp-ad-tech.com/source"
]
// Registered by mmp-ad-tech using redirects
"Attribution-Reporting-Register-Source": {
"source_event_id": "4532343",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x4"
}
}
В момент t2 действие или конверсия пользователя в приложении рекламодателя приводит к регистрации триггера mmp-ad-tech (Trigger1), который также перенаправляет на ad-tech1 (Trigger2) и ad-tech2 (Trigger3):
неопределенный
Результат
Зарегистрированные mmp-ad-tech источники Source2 и Source4 конкурируют за атрибуцию для зарегистрированного mmp-ad-tech триггера Trigger1. Source2 побеждает Source4 из-за более высокого приоритета. Trigger2 от ad-tech1 приписывается Source1 от ad-tech1, а Trigger3 от ad-tech2 приписывается Source3 от ad-tech2.
Конкурирующие источники для
Поля | Источник1 | Источник2 | Источник3 | Источник4 |
Источник регистрации рекламных технологий | ad-tech1 | mmp-ad-tech | ad-tech2 | mmp-ad-tech |
исходный_идентификатор_события | 34532 | 788324 | 6574435 | 4532343 |
место назначения | https://destination.example.com | https://destination.example.com | https://destination.example.com | https://destination.example.com |
приоритет | 10 | 30 | 10 | 20 |
Триггеры зарегистрированы
Результат атрибуции
Trigger1 присваивает атрибуты Source2, Trigger2 присваивает атрибуты Source1, а Trigger3 присваивает атрибуты Source3.
Игнорируемые источники после атрибуции
Source4 - не будет конкурировать за указание авторства в будущем.
Отчеты о событиях
URL-адрес отчета: https://www.mmp-ad-tech.com/.well-known/attribution-reporting/report-event-attribution
{
"attribution_destination": "https://destination.example.com",
"scheduled_report_time": "800176400",
"source_event_id": "788324",
"trigger_data": "1",
"source_type": "navigation",
"randomized_trigger_rate": 0.0024263
}
URL-адрес отчета: https://www.ad-tech1.com/.well-known/attribution-reporting/report-event-attribution
{
"attribution_destination": "https://destination.example.com",
"scheduled_report_time": "800176400",
"source_event_id": "34532",
"trigger_data": "2",
"source_type": "navigation",
"randomized_trigger_rate": 0.0024263
}
URL-адрес отчета: https://www.ad-tech2.com/.well-known/attribution-reporting/report-event-attribution
{
"attribution_destination": "https://destination.example.com",
"scheduled_report_time": "800176400",
"source_event_id": "6574435",
"trigger_data": "3",
"source_type": "navigation",
"randomized_trigger_rate": 0.0024263
}
Сводные отчеты
URL-адрес отчета: https://www.mmp-ad-tech.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"attribution_destination": "https://destination.example.com",
"histograms": [
{
"key": "0x104",
"value": 11
}
]
}
URL-адрес отчета: https://www.ad-tech1.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"attribution_destination": "https://destination.example.com",
"histograms": [
{
"key": "0x201",
"value": 21
}
]
}
URL-адрес отчета: https://www.ad-tech2.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"attribution_destination": "https://destination.example.com",
"histograms": [
{
"key": "0x303",
"value": 31
}
]
}
Сценарий 2: Межсетевая атрибуция без перенаправлений
Рекламодатель работает с 2 обслуживающими рекламными технологиями и 1 MMP. Пользователь нажимает на рекламу от первой обслуживающей рекламной технологии, которая перенаправляет его на MMP при регистрации источника. Когда пользователь нажимает на рекламу от второй обслуживающей рекламной технологии, рекламная технология не перенаправляет его, а вместо этого заранее делится подмножеством своих ключей агрегации с MMP.
Затем пользователь конвертируется в приложении, где MMP регистрирует триггер, но не перенаправляет ни на одну из рекламных технологий. Технология без перенаправления выигрывает атрибуцию последнего касания. Только MMP получит кросс-сетевой дедуплицированный сводный отчет, который включает эту конверсию.
Хронология регистраций
В момент t0 пользователь нажимает на рекламу, что приводит к регистрации Source1 от ad-tech1 и регистрации Source2 от mmp-ad-tech с использованием перенаправления с ad-tech1:
"Attribution-Reporting-Register-Source": {
"source_event_id": "234543",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172801",
"aggregation_keys": {
"campaignCounts": "0x159"
}
},
"Attribution-Reporting-Redirect": [
"http://www.mmp-ad-tech.com"
]
// Registered by mmp-ad-tech using redirect
"Attribution-Reporting-Register-Source": {
"source_event_id": "45453",
"web_destination": "https://destination.example.com",
"priority": "100",
"expiry": "172801",
"aggregation_keys": {
"campaignCounts": "0x159",
"geoValue": "0x5",
}
}
В момент t1 пользователь нажимает на другое объявление, что приводит к переходу на Source3 от ad-tech2, который разделяет ключи агрегации:
// Registered by ad-tech2
"Attribution-Reporting-Register-Source": {
"source_event_id": "978",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172801",
"aggregation_keys": {
"campaignCounts": "0x159",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts"
]
}
В момент t2 действие/конверсия пользователя запускает регистрацию mmp-ad-tech, которая содержит конфигурацию атрибуции для ad-tech2:
"Attribution-Reporting-Register-Trigger": {
"event_trigger_data": [
{
"trigger_data": "2",
"priority": "101"
}
],
"aggregatable_trigger_data": [
{
"key_piece": "0x400",
"source_keys": [
"campaignCounts"
],
"x_network_data": {
"key_offset": 10
}
}
],
"aggregatable_values": {
"campaignCounts": 32768
},
"attribution_config": [
{
"source_network": "enrollment-id-ad-tech-2",
"source_priority_range": {
"start": 1,
"end": 1000
},
"priority": "200",
"expiry": "172800"
}
],
"x_network_key_mapping": {
"enrollment-id-ad-tech-2": "0x4"
}
}
Результат
Source2 сопоставляет регистрацию и назначение с триггером, поэтому он становится конкурирующим источником для атрибуции. Кроме того, во время регистрации триггера была указана конфигурация атрибуции для ad-tech2 и Source3 с использованием общих ключей агрегации ad-tech2. Это позволяет генерировать производный источник, Source3', как конкурирующий источник для атрибуции.
Конкурирующие источники
Поля | Источник2 | Источник3' |
Первоисточник регистрации рекламных технологий | mmp-ad-tech | ad-tech2 |
исходный_идентификатор_события | 45453 | 978 |
приоритет | 100 | 200 |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Trigger1 присваивается Source3', поскольку Source3' имеет более высокий приоритет, чем Source2.
Игнорируемые источники после атрибуции
Источник2
Отчеты о событиях
Нет — отчеты о событиях для производных источников не создаются.
Сводные отчеты
Родительский источник Source3, то есть Source3, разделяет только campaignCounts
, ключевая часть для trigger вычисляется по формуле:
(key_piece value) | ((x_network_key_mapping entry) << offset)
0x400 | (0x4 << 10) = 0x1400
Наконец, результирующий ключ генерируется путем выполнения операции ИЛИ над ключом триггера (0x1400) и исходным ключом (0x159), что дает 0x1559.
URL-адрес отчета: http://www.mmp-ad-tech.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"attribution_destination": "https://destination.example.com",
"histograms": [
{
"key": "0x1559",
"value": 32768
}
]
}
Сценарий 3: MMP зарегистрировал источник и родительского кандидата производного источника в одной и той же цепочке регистрации
Рекламодатель работает с 2 обслуживающими рекламными технологиями и 1 MMP. Пользователь нажимает на рекламу от первой обслуживающей рекламной технологии, которая не перенаправляет при регистрации источника, но делится ключами агрегации с MMP. Пользователь нажимает на рекламу от второй обслуживающей рекламной технологии, которая перенаправляет на MMP при регистрации источника и делится ключами агрегации с MMP.
Хронология регистраций
В момент t0 пользователь нажимает на рекламу, размещенную ad-tech1, что запускает регистрацию Source1:
"Attribution-Reporting-Register-Source": {
"source_event_id": "52343",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x159",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В точке t1, цепочка регистрации 2, ad-tech2 регистрирует Source2 и перенаправляет для регистрации источника MMP, Source3:
"Attribution-Reporting-Register-Source": {
"source_event_id": "234456",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172801",
"aggregation_keys": {
"campaignCounts": "0x159"
},
"shared_aggregation_keys": [
"campaignCounts"
]
},
"Attribution-Reporting-Redirect": [
"http://www.mmp-ad-tech.com"
]
"Attribution-Reporting-Register-Source": {
"source_event_id": "4234",
"web_destination": "https://destination.example.com",
"priority": "100",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x159"
}
}
В момент t2 регистрация триггера имеет настроенную атрибуцию для генерации производных источников из ad-tech1 и ad-tech2:
"Attribution-Reporting-Register-Trigger": {
"event_trigger_data": [
{
"trigger_data": "2",
"priority": "101"
}
],
"aggregatable_trigger_data": [
{
"key_piece": "0x400",
"source_keys": [
"campaignCounts"
],
"x_network_data" : {
"key_offset" : 10
}
}
],
"aggregatable_values": {
"campaignCounts": 32768,
"geoValue": 1664
},
"attribution_config": [
{
"source_network": "enrollment-id-ad-tech-1",
"source_priority_range": {
"start": 1,
"end": 1000
},
"priority": "20",
"expiry": "172800"
},
{
"source_network": "enrollment-id-ad-tech-2",
"source_priority_range": {
"start": 1,
"end": 1000
},
"priority": "20",
"expiry": "172800"
}
],
"x_network_key_mapping" : {
"enrollment-id-ad-tech-1" : "0x2",
"enrollment-id-ad-tech-2" : "0x4"
}
}
В результате источник, зарегистрированный в MMP во второй цепочке регистрации, выигрывает атрибуцию. Полученный совокупный отчет выглядит следующим образом:
Результат
Производный от Source2 источник (с " source_event_id": "234456
") не участвует в атрибуции, поскольку в той же цепочке регистрации также имеется зарегистрированный источник mmp-ad-tech.
Конкурирующие источники
Поля | Источник1' | Источник3 |
Первоисточник регистрации рекламных технологий | ad-tech1 | mmp-ad-tech |
исходный_идентификатор_события | 52343 | 4234 |
приоритет | 20 | 100 |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Trigger1 присваивается Source3, поскольку Source3 имеет более высокий приоритет, чем Source1.
Игнорируемые источники после атрибуции
Source1' - Source1 больше не будет считаться источником, создающим производный источник для mmp-ad-tech.
Отчеты о событиях
URL-адрес отчета: https://www.ad-tech1.com/.well-known/attribution-reporting/report-event-attribution
{
"attribution_destination": "https://destination.example.com",
"scheduled_report_time": "800176400",
"source_event_id": "4234",
"trigger_data": "2",
"source_type": "navigation",
"randomized_trigger_rate": 0.0024263
}
Сводные отчеты
URL-адрес отчета: http://www.mmp-ad-tech.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"report_url": "http://www.mmp-example.com",
"payload": {
"attribution_destination": "https://destination.example.com",
"histograms": [
{
"key": "0x559"
"value": 32768
}
]
}
}
Сценарий 4: Кросс-сетевая атрибуция без перенаправлений с критериями выбора источника
Рекламодатель работает с 4 обслуживающими рекламными технологиями и 1 MMP. Пользователь нажимает на рекламу от 1 обслуживающей рекламной технологии и просматривает рекламу от 3 других. Когда пользователь совершает конверсию в приложении рекламодателя, MMP регистрирует триггер и указывает, какие обслуживающие рекламные технологии зарегистрировали источники для создания производных источников на основе следующих фильтров:
- priority_range: выбрать источники, имеющие приоритет в указанном диапазоне
- истечение срока действия: выберите источники со сроком действия, превышающим указанную продолжительность
- source_filters: выберите источники, чьи filter_data соответствуют указанным source_filters
- source_not_filters: выбрать источники, чьи not_filters соответствуют указанным source_not_filters
После того, как производные источники будут созданы на основе критериев, они получат право участвовать в атрибуции.
Хронология регистрации
В момент t0 щелчок пользователя заставляет ad-tech1 регистрировать источник Source1, который связывает source_type в качестве навигации к этому зарегистрированному источнику:
"Attribution-Reporting-Register-Source": {
"source_event_id": "87456",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172801",
"filter_data": {
"filter1": [
"does_not_matter"
],
"filter2": [
"non-match"
]
},
"aggregation_keys": {
"campaignCounts": "0x119",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t1 пользователь просматривает рекламу, в результате чего ad-tech2 регистрирует источник Source2, который связывает source_type как событие с этим зарегистрированным источником:
"Attribution-Reporting-Register-Source": {
"source_event_id": "9078",
"web_destination": "https://destination.example.com",
"priority": "2000",
"expiry": "172801",
"filter_data": {
"filter1": [
"does_not_matter"
],
"filter2": [
"match"
]
},
"aggregation_keys": {
"campaignCounts": "0x129",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t2 пользовательское представление заставляет ad-tech3 зарегистрировать источник Source3, который связывает source_type как событие с этим зарегистрированным источником:
"Attribution-Reporting-Register-Source": {
"source_event_id": "2413",
"web_destination": "https://destination.example.com",
"priority": "20",
"filter_data": {
"filter1": [
"non-match"
],
"filter2": [
"non-match"
]
},
"aggregation_keys": {
"campaignCounts": "0x159",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t3 пользовательское представление заставляет ad-tech4 зарегистрировать источник Source4, который связывает source_type как событие с этим зарегистрированным источником:
"Attribution-Reporting-Register-Source": {
"source_event_id": "7567",
"web_destination": "https://destination.example.com",
"priority": "20",
"filter_data": {
"filter1": [
"match"
],
"filter2": [
"match"
]
},
"aggregation_keys": {
"campaignCounts": "0x169",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t4 конверсия пользователя приводит к тому, что mmp-ad-tech регистрирует триггер с конфигурацией атрибуции для всех других зарегистрированных источников ранее упомянутых ad-techs:
"Attribution-Reporting-Register-Trigger": {
"event_trigger_data": [
{
"trigger_data": "2",
"priority": "100"
}
],
"aggregatable_trigger_data": [
{
"key_piece": "0x400",
"source_keys": [
"campaignCounts"
]
}
],
"aggregatable_values": {
"campaignCounts": 32768,
"geoValue": 1664
},
"attribution_config": [
{
"source_network": "enrollment-id-ad-tech-1",
"source_priority_range": {
"start": 1,
"end": 100
},
"source_filters": {
"source_type": [
"event"
]
},
"priority": "100",
"expiry": "172801"
},
{
"source_network": "enrollment-id-ad-tech-2",
"source_priority_range": {
"start": 1,
"end": 1000
},
"source_filters": {
"source_type": [
"navigation"
]
},
"priority": "100",
"expiry": "172801"
},
{
"source_network": "enrollment-id-ad-tech-3",
"source_priority_range": {
"start": 1,
"end": 1000
},
"source_filters": {
"source_type": [
"navigation"
],
"filter1": [
"match"
],
"filter2": [
"match"
]
},
"priority": "50",
"expiry": "172801"
},
{
"source_network": "enrollment-id-ad-tech-4",
"source_priority_range": {
"start": 1,
"end": 1000
},
"source_filters": {
"source_type": [
"navigation"
],
"filter1": [
"match"
],
"filter2": [
"match"
]
},
"priority": "30",
"expiry": "172801"
}
],
"x_network_key_mapping": {
"enrollment-id-ad-tech-1": "0x1",
"enrollment-id-ad-tech-2": "0x2",
"enrollment-id-ad-tech-3": "0x3",
"enrollment-id-ad-tech-4": "0x4"
}
}
Результат
Следующие источники не считаются подходящими для создания производных источников из-за несоответствия критериям:
- Source1 не удовлетворяет фильтру
source_type:event
в конфигурации атрибуции ad-tech1 - Source2 имеет приоритет 2000, что выходит за пределы диапазона приоритетов фильтра ad-tech2 (1,1000)
- Source3 не соответствует значению для
filter2
Конкурирующие источники
Поля | Источник4' |
Оригинальный источник регистрации рекламных технологий | ad-tech4 |
исходный_идентификатор_события | 7567 |
место назначения | https://destination.example.com |
приоритет | 30 |
истечение срока действия | Время регистрации + 2 дня |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Trigger1 приписывается Source4, поскольку это единственный источник, подходящий для атрибуции.
Игнорируемые источники после атрибуции
Никто
Отчеты о событиях
Нет — отчеты о событиях не создаются для победителя, выбранного по производному источнику.
Сводные отчеты
URL-адрес отчета: http://www.mmp-ad-tech.com
{
"attribution_destination": "https://example.com",
"histograms": [
{
"key": "0x56d",
"value": 32768
},
{
"key": "0x5",
"value": 1664
}
]
}
Сценарий 5: Атрибуция после установки
Рекламодатель работает с 2 обслуживающими рекламными технологиями и 1 MMP. Пользователь нажимает на рекламу от первой рекламной технологии и устанавливает приложение рекламодателя. Во время атрибуции для конверсий после установки производный источник с атрибуцией установки побеждает другие источники, даже если у других более высокие приоритеты.
Хронология регистрации
В момент t0 взаимодействие с пользователем приводит к тому, что ad-tech1 регистрирует Source1:
"Attribution-Reporting-Register-Source": {
"source_event_id": "3645",
"destination": "android-app://com.example.app",
"priority": "20",
"expiry": "172801",
"install_attribution_window": "86400",
"post_install_exclusivity_window": "864000",
"aggregation_keys": {
"campaignCounts": "0x119",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t1 пользователь устанавливает приложение com.example.app
на свое устройство.
В момент t2 взаимодействие с пользователем приводит к тому, что ad-tech2 регистрирует Source2:
"Attribution-Reporting-Register-Source": {
"source_event_id": "345789",
"destination": "android-app://com.example.app",
"priority": "100",
"aggregation_keys": {
"campaignCounts": "0x159",
"geoValue": "0x5"
},
"shared_aggregation_keys": [
"campaignCounts",
"geoValue"
]
}
В момент t3 триггер регистрируется mmp-ad-tech с конфигурациями атрибуции для ad-tech1 и ad-tech2:
"Attribution-Reporting-Register-Trigger": {
"event_trigger_data": [
{
"trigger_data": "2",
"priority": "100"
}
],
"aggregatable_trigger_data": [
{
"key_piece": "0x400",
"source_keys": [
"campaignCounts"
]
}
],
"aggregatable_values": {
"campaignCounts": 32768,
"geoValue": 1664
},
"attribution_config": [
{
"source_network": "enrollment-id-ad-tech-1",
"priority": "10",
"expiry": "172801",
"post_install_exclusivity_window": "172800"
},
{
"source_network": "enrollment-id-ad-tech-2",
"priority": "20",
"expiry": "172801"
}
],
"x_network_key_mapping": {
"enrollment-id-ad-tech-1": "0x1",
"enrollment-id-ad-tech-2": "0x3"
}
}
Результат
Сгенерированные производные источники из Source1 и Source2 (Source1' и Source2' соответственно), которые конкурируют за атрибуцию.
Конкурирующие источники
Поля | Источник1' | Источник2' |
Первоисточник регистрации рекламных технологий | ad-tech1 | ad-tech2 |
исходный_идентификатор_события | 3645 | 345789 |
место назначения | android-app://com.example.app | android-app://com.example.app |
приоритет | 10 | 20 |
Ускоренная установка приложения | да | нет |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Trigger1 приписывается Source1', поскольку он привел к установке целевого приложения. Обратите внимание, что у Source2' был более высокий приоритет.
Игнорируемые источники после атрибуции
Source2' - производные источники из Source2 не будут учитываться при атрибуции для любых триггеров, зарегистрированных mmp-ad-tech.
Отчеты о событиях
Нет — отчеты о событиях не создаются для победителя, выбранного по производному источнику.
Сводные отчеты
URL-адрес отчета: http://www.mmp-ad-tech.com/.well-known/attribution-reporting/report-aggregate-attribution
{
"attribution_destination": "android-app://com.example.app",
"histograms": [
{
"key": "0x519",
"value": 32768
},
{
"key": "0x5",
"value": 1664
}
]
}
Сценарий 6: Проиграв один раз, проигрываешь всегда
Если ad-tech1 имеет источник, производный источник которого участвовал в атрибуции для триггера mmp-ad-tech и потерял атрибуцию, источник ad-tech1 не используется для создания производного источника для триггеров mmp-ad-tech в дальнейшем. Вот пример временной шкалы:
- В момент t0 источник Source1 ad-tech1 зарегистрирован с
"priority": "10"
. - В момент времени t1 источник Source2 компании ad-tech2 зарегистрирован с
"priority": "20"
. - В момент времени t2 Trigger1 mmp-ad-tech регистрируется в конфигурациях атрибуции ad-tech1 и ad-tech2.
- В момент t3 происходит атрибуция для Trigger1, где производный источник из ad-tech2 выигрывает атрибуцию, а источник ad-tech1 игнорируется.
- В момент времени t4 источник Source3 от ad-tech3 зарегистрирован с
"priority": "5"
. - В момент t5 Trigger2 mmp-ad-tech регистрируется в конфигурациях ad-tech1 и ad-tech3.
- В момент t6 происходит атрибуция для Trigger2, где производный от Source3 источник (Source3') выигрывает атрибуцию.
Объяснение результата
Производный источник от источника ad-tech1 потерял атрибуцию для Trigger1, поэтому Source1 не использовался для создания производного источника для атрибуции Trigger2. Если бы он не проиграл раньше в t3, он бы победил источник ad-tech3 из-за более высокого приоритета.