Большинство рекламодателей работают с несколькими различными рекламными сетями для показа рекламы в приложениях издателей. Если рекламные сети зарегистрируют свои собственные источники атрибуции и триггеры с помощью API, они будут получать отчеты о событиях и сводные отчеты с собственной атрибуцией.
Однако рекламодатели, которые хотят использовать третью сторону для выполнения межсетевой атрибуции (XNA) для определения единственного выигрышного объявления для конкретной конверсии, могут продолжать делать это, используя следующие методы:
- Настройте собственный сервер для регистрации триггерных событий и получения отчетов об атрибуции через API.
- Продолжайте использовать существующего партнера по мобильным измерениям.
Независимо от метода, который выбирает рекламодатель, API отчетов об атрибуции поддерживает ряд различных функций, которые позволяют третьей стороне настраивать логику XNA от имени рекламодателя:
- Третья сторона может выполнять атрибуцию с помощью API с перенаправлением из рекламных сетей или без него .
- Ключи приоритета, фильтров и дедупликации могут обеспечить дополнительную настройку атрибуции на основе параметров источника и триггера.
- Окна атрибуции после установки позволяют источникам, которые привели к установке, продолжать получать признание за будущие события-конверсии в приложении.
Модель атрибуции, которую рекламные специалисты используют для межсетевой дедупликации и выбора выигрышных источников, может иметь разный уровень сложности в зависимости от того, как используются эти функции API.
Приведенные ниже примеры иллюстрируют примеры сценариев использования этих функций и то, как различные конфигурации влияют на то, какой источник атрибуции в конечном итоге получит признание за определенное триггерное событие.
Процесс
В следующем списке описаны этапы процесса XNA. Для простоты перечисленные здесь шаги предполагают модель, в которой рекламодатель использует технологию показа рекламы для показа рекламы и MMP для измерения конверсий. Однако дизайн API является гибким: функциональные возможности не различаются для разных типов рекламных технологий и не требуют использования рекламных технологий.
- Регистрация источника . Пользователь просматривает объявление или нажимает на него, а технология показа рекламы регистрирует эти источники с помощью API. Обслуживающая рекламная технология также может перенаправляться на других рекламных технологий, которые также могут регистрировать источники напрямую с помощью API или включать межсетевую атрибуцию без переадресации .
- Регистрация триггера . Пользователь выполняет действие, связанное с конверсией, например первое открытие приложения, покупку или добавление в корзину, после чего MMP регистрирует триггер с помощью API. MMP также может перенаправлять пользователей на других рекламных специалистов, которые могут регистрировать триггеры непосредственно с помощью API. Если MMP необходимо включить межсетевую атрибуцию без перенаправлений , конфигурация атрибуции должна быть указана во время регистрации триггера.
- Атрибуция : если конфигурация атрибуции указана во время регистрации триггера, производные источники генерируются от имени MMP. Каждый триггер пытается сопоставить либо с подходящим источником, зарегистрированным непосредственно MMP, либо с подходящим производным источником, созданным от имени MMP с использованием источников обслуживающей рекламной технологии. Остальные источники, не получившие атрибуцию, удаляются и больше не имеют права на атрибуцию для будущих конверсий. Вы также можете увидеть это как «проиграть один раз, потерять всегда» в других частях документации.
- Когда производный источник теряет атрибуцию, API не будет создавать будущие производные источники на основе исходного источника, когда будущие события конверсии регистрируются MMP. Технология показа рекламы и другие MMP по-прежнему могут использовать первоначальный источник для будущей атрибуции. Подробно это описано в сценарии 6 .
- Создание отчета . Атрибуция приводит к созданию отчета о событии или совокупного отчета. Обратите внимание, что для производных источников создаются только сводные отчеты.
- Доставка отчетов : доставка созданных отчетов запланирована.
Сценарий 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 via 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 via redirects
"Attribution-Reporting-Register-Source": {
"source_event_id": "4532343",
"web_destination": "https://destination.example.com",
"priority": "20",
"expiry": "172800",
"aggregation_keys": {
"campaignCounts": "0x4"
}
}
В момент времени 2 действие или конверсия пользователя в приложении рекламодателя приводит к регистрации триггера с помощью mmp-ad-tech (Trigger1), который также перенаправляет на ad-tech1 (Trigger2) ad-tech2 (Trigger3):
неопределенный
Результат
Зарегистрированные в mmp-ad-tech источники Source2 и Source4 конкурируют за атрибуцию зарегистрированного в mmp-ad-tech триггера Trigger1. Source2 выигрывает у Source4 из-за более высокого приоритета. Триггер2 от ad-tech1 присваивается источнику1 от ad-tech1, а триггер3 от ad-tech2 присваивается источнику3 от ad-tech2.
Конкурирующие источники
Поля | Источник1 | Источник2 | Источник3 | Источник4 |
Источник регистрации рекламной технологии | рекламные технологии1 | ммп-реклама-технология | реклама-tech2 | mmp-ad-tech |
source_event_id | 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. Межсетевая атрибуция без переадресации.
Рекламодатель работает с двумя специалистами по рекламе и одним 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 via 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"
]
}
В момент времени 2 действия пользователя/конверсии вызывают регистрацию в 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"
}
}
Результат
Источник 2 сопоставляет регистрацию и назначение с триггером, поэтому он становится конкурирующим источником атрибуции. Кроме того, во время регистрации триггера была указана конфигурация атрибуции для ad-tech2 и Source3 с помощью общих ключей агрегирования ad-tech2. Это позволяет создать производный источник Source3' в качестве конкурирующего источника для атрибуции.
Конкурирующие источники
Поля | Источник2 | Источник3' |
Первоисточник регистрации рекламных технологий | mmp-ad-tech | реклама-tech2 |
source_event_id | 45453 | 978 |
приоритет | 100 | 200 |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Триггер1 присваивается Источнику3', поскольку Источник3' имеет более высокий приоритет, чем Источник2.
Игнорируемые источники сообщают об авторстве
Источник2
Отчеты о мероприятиях
Нет — отчеты о событиях не создаются для производных источников.
Сводные отчеты
Родительский источник Source3', т.е. Source3, использует только campaignCounts
, ключевая часть триггера рассчитывается по формуле:
(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 и родительский кандидат производного источника в одной и той же цепочке регистрации.
Рекламодатель работает с двумя специалистами по рекламе и одним 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:
"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"
}
}
В момент времени 2 при регистрации триггера атрибуция настроена на создание производных источников из 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 |
Первоисточник регистрации рекламной технологии | рекламные технологии1 | mmp-ad-tech |
source_event_id | 52343 | 4234 |
приоритет | 20 | 100 |
Триггеры зарегистрированы
Trigger1 от mmp-ad-tech.
Результат атрибуции
Триггер1 присваивается Источнику3, поскольку Источник3 имеет более высокий приоритет, чем Источник1.
Игнорируемые источники сообщают об авторстве
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
После того как производные источники созданы на основе критериев, они имеют право участвовать в атрибуции.
График регистрации
В момент времени 0 щелчок пользователя заставляет 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"
]
}
В момент времени 1 пользователь просматривает рекламу, в результате чего 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"
]
}
В момент времени 2 пользовательское представление заставляет 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"
]
}
В момент времени 3 пользовательское представление заставляет 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 регистрирует триггер с конфигурацией атрибуции для всех других зарегистрированных источников, упомянутых выше, рекламными технологиями:
"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"
}
}
Результат
Следующие источники не считаются подходящими для создания производных источников из-за несоответствия критериев:
- Источник1 не соответствует фильтру "
source_type":"event
" в конфигурации атрибуции ad-tech1. - У Source2 приоритет установлен на 2000, что выходит за пределы фильтра диапазона приоритетов ad-tech2 (11000).
- Source3 не соответствует значению для "
filter2
"
Конкурирующие источники
Поля | Источник4' |
Оригинальный источник, регистрирующий рекламную технологию | реклама-tech4 |
source_event_id | 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. Атрибуция после установки
Рекламодатель работает с двумя специалистами по рекламе и одним 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"
]
}
В момент времени 1 пользователь устанавливает приложение com.example.app
на свое устройство.
В момент времени 2 взаимодействие с пользователем заставляет 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' |
Первоисточник регистрации рекламной технологии | рекламные технологии1 | реклама-tech2 |
source_event_id | 3645 | 345789 |
место назначения | Android-приложение://com.example.app | Android-приложение://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"
. - В момент времени 2 триггер1 mmp-ad-tech регистрируется в конфигурациях атрибуции ad-tech1 и ad-tech2.
- В момент времени 3 происходит атрибуция для Trigger1, когда производный источник от ad-tech2 получает атрибуцию, а источник ad-tech1 игнорируется.
- В момент t4 источник Source3 ad-tech3 регистрируется с
"priority": "5"
. - В момент t5 триггер2 mmp-ad-tech регистрируется в конфигурациях ad-tech1 и ad-tech3.
- В момент t6 происходит атрибуция для Trigger2, где производный источник из Source3 (Источник3') получает атрибуцию.
Объяснение результата
Производный источник из источника ad-tech1 потерял атрибуцию для Trigger1, поэтому Source1 не использовался для создания производного источника для атрибуции Trigger2. Если бы он не проиграл раньше в момент t3, он бы выиграл у источника ad-tech3 из-за более высокого приоритета.