רוב המפרסמים עובדים עם כמה רשתות מודעות שונות כדי להציג מודעות באפליקציות של בעלי תוכן דיגיטלי. אם רשתות מודעות ירשמו מקורות שיוך וטריגרים משלהן באמצעות ה-API, הן יקבלו דוחות על אירועים ששויכו לעצמן ודוחות סיכום.
עם זאת, מפרסמים שרוצים להשתמש בצד שלישי כדי לבצע שיוך (Attribution) בין רשתות (XNA) כדי לקבוע איזו מודעה אחת מניבה את ההמרה הטובה ביותר יכולים להמשיך לעשות זאת באמצעות הטכניקות הבאות:
- הגדרת שרת פנימי לרישום אירועי טריגר ולקבלת דוחות שיוך מה-API
- המשך שימוש בשותף קיים למדידת ביצועים בנייד
לא משנה באיזו טכניקה המפרסם בוחר להשתמש, Attribution Reporting API תומך במספר תכונות שמאפשרות לצד שלישי להתאים אישית את הלוגיקה של XNA בשם המפרסם:
- צד שלישי יכול לבצע שיוך באמצעות ה-API עם או בלי הפניות אוטומטיות מרשתות מודעות.
- הגדרות כמו עדיפות, מסננים ומפתחות לביטול כפילויות יכולות לספק התאמה אישית נוספת של השיוך על סמך מאפייני המקור והטריגר.
- חלונות שיוך אחרי התקנה מאפשרים למקורות שהניבו התקנה להמשיך לקבל קרדיט על אירועי המרה עתידיים באפליקציה.
מודל השיוך שספקי טכנולוגיות הפרסום משתמשים בו לביטול כפילויות ברשתות שונות ולבחירת המקורות המניבים יכול להיות ברמות מורכבות שונות, בהתאם לאופן השימוש בתכונות של ממשקי ה-API האלה.
בדוגמאות הבאות מוצגים תרחישים לשימוש בתכונות האלה, והסבר על האופן שבו הגדרות שונות משפיעות על מקור השיוך שמקבל בסופו של דבר את הקרדיט על אירוע מפעיל נתון.
עיבוד
בקטע הבא מפורטים השלבים בתהליך של XNA. לצורך פשטות, השלבים שמפורטים כאן מבוססים על מודל שבו המפרסם משתמש בטכנולוגיית הצגת מודעות להצגת מודעות ובפלטפורמה לניהול מדיה (MMP) למעקב המרות. עם זאת, עיצוב ה-API הוא גמיש – הפונקציונליות לא שונה בין סוגים שונים של טכנולוגיות פרסום, והשימוש בטכנולוגיית פרסום לא נדרש.
- רישום מקורות: המשתמש צופה במודעה או לוחץ עליה, וטכנולוגיית הפרסום שמציגה את המודעה רושמת את המקורות האלה ב-API. טכנולוגיית הצגת המודעות עשויה גם להפנות לטכנולוגיות פרסום אחרות שיכולות לרשום מקורות ישירות ב-API, או לאפשר שיוך (Attribution) בין רשתות ללא הפניות אוטומטיות.
- הפעלת רישום: משתמש מבצע פעולה שמשויכת להמרה, כמו פתיחה ראשונה של האפליקציה, רכישה או הוספה לעגלת הקניות. בתגובה, פלטפורמת MMP רושמת טריגר ב-API. יכול להיות שפלטפורמת ה-MMP תפנה אוטומטית גם לטכנולוגיות פרסום אחרות שיכולות לרשום טריגרים ישירות באמצעות ה-API. אם ספק MMP צריך להפעיל שיוך בין רשתות ללא הפניות אוטומטיות, צריך לציין את הגדרות השיוך במהלך רישום הטריגר.
- שיוך (Attribution): אם צוינה הגדרת שיוך במהלך רישום הטריגר, מקורות נתונים נגזרים נוצרים בשם ה-MMP. המערכת מנסה להתאים כל טריגר למקור שעומד בדרישות ונרשם ישירות על ידי פלטפורמת ה-MMP, או למקור נגזר שעומד בדרישות ונוצר בשם פלטפורמת ה-MMP באמצעות המקורות של טכנולוגיית הצגת המודעות. המקורות הנותרים, שלא זכו בשיוך, נפסלים ולא יכולים יותר לזכות בשיוך להמרות עתידיות. יכול להיות שמונח זה יופיע גם כ 'הפסד אחד, הפסד תמיד' בחלקים אחרים של התיעוד.
- כשמקור נגזר מאבד את השיוך, ה-API לא ייצור מקורות נגזרים עתידיים על סמך המקור המקורי כשאירועי המרה עתידיים יירשמו על ידי פלטפורמת ה-MMP. טכנולוגיית הצגת המודעות ושותפי מדידה אחרים עדיין יכולים להשתמש במקור המקורי לשיוך עתידי. הסבר מפורט על כך מופיע בתרחיש 6.
- יצירת דוחות: השיוך מוביל ליצירת דוחות אירועים או דוחות מצטברים. חשוב לזכור שרק דוחות מצטברים נוצרים למקורות נגזרים.
- שליחת דוחות: הדוחות שנוצרו מתוזמנים לשליחה.
תרחיש 1: שיוך (Attribution) חוצה-פלטפורמות עם הפניות אוטומטיות
מפרסם עובד עם 2 טכנולוגיות להצגת מודעות ועם פלטפורמה אחת למדידת ביצועים (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 (טריגר 1), שמפנה גם אל ad-tech1 (טריגר 2) ואל ad-tech2 (טריגר 3):
לא מוגדר
תוצאה
מקורות Source2 ו-Source4 שרשומים ב-mmp-ad-tech מתחרים בשיוך (Attribution) של טריגר Trigger1 שרשום ב-mmp-ad-tech. מקור2 מקבל עדיפות על פני מקור4 כי יש לו עדיפות גבוהה יותר. הטריגר Trigger2 של ad-tech1 משויך למקור Source1 על ידי ad-tech1, והטריגר Trigger3 של ad-tech2 משויך למקור Source3 על ידי ad-tech2.
מקורות מתחרים ל
שדות |
Source1 |
Source2 |
Source3 |
Source4 |
טכנולוגיית פרסום לרישום מקורות |
ad-tech1 |
mmp-ad-tech |
ad-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 |
טריגרים רשומים
תוצאת השיוך (Attribution)
מאפיינים של Trigger1 אל Source2, מאפיינים של Trigger2 אל Source1 ומאפיינים של Trigger3 אל Source3.
שיוך פוסטים למקורות שהמערכת התעלמה מהם
מקור4 – לא יתחרה על שיוך בעתיד.
דוחות אירועים
כתובת ה-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 טכנולוגיות להצגת מודעות ועם פלטפורמה אחת למדידת ביצועים (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"
}
}
תוצאה
המקור2 תואם להרשמה וליעד עם הטריגר, ולכן הוא הופך למקור מתחרה לשיוך. בנוסף, במהלך רישום הטריגר, צוינה הגדרת שיוך (Attribution) עבור ad-tech2 ו-Source3 באמצעות מפתחות צבירה לשיתוף של ad-tech2. כך אפשר ליצור מקור נגזר, Source3, כמקור מתחרה לשיוך.
מקורות מתחרים
שדות |
Source2 |
מקור3' |
רישום טכנולוגיות פרסום במקור |
mmp-ad-tech |
ad-tech2 |
source_event_id |
45453 |
978 |
עדיפות |
100 |
200 |
טריגרים רשומים
הפעלת Trigger1 על ידי mmp-ad-tech.
תוצאת השיוך (Attribution)
הטריגר Trigger1 משויך למקור Source3' כי למקור Source3' יש עדיפות גבוהה יותר מאשר למקור Source2.
שיוך פוסטים למקורות שהמערכת התעלמה מהם
Source2
דוחות אירועים
ללא – לא נוצרים דוחות אירועים למקורות נגזרים.
דוחות צבירה
מקור 3, שהוא מקור האב של מקור 3, משתף רק את campaignCounts. החלק המרכזי של הטריגר מחושב כך:
(key_piece value) | ((x_network_key_mapping entry) << offset)
0x400 | (0x4 << 10) = 0x1400
לבסוף, המפתח שמתקבל נוצר על ידי פעולת OR של מפתח הטריגר (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: מקור רשום ומועמד להיות מקור נגזר שרשומים באותו שרשור רישום
מפרסם עובד עם 2 טכנולוגיות להצגת מודעות ועם פלטפורמה אחת למדידת ביצועים (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.
מקורות מתחרים
שדות |
מקור1' |
Source3 |
טכנולוגיית פרסום שנרשמה כמקור מקורי |
ad-tech1 |
mmp-ad-tech |
source_event_id |
52343 |
4234 |
עדיפות |
20 |
100 |
טריגרים רשומים
הפעלת Trigger1 על ידי mmp-ad-tech.
תוצאת השיוך (Attribution)
הטריגר 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 טכנולוגיות להצגת מודעות ועם פלטפורמה אחת למדידת ביצועים (MMP). משתמש לוחץ על מודעה מטכנולוגיית פרסום אחת ומציג מודעות מ-3 הטכנולוגיות האחרות. כשמשתמש מבצע המרה באפליקציה של המפרסם, פלטפורמת ה-MMP רושמת טריגר ומציינת אילו מקורות רשומים של טכנולוגיות פרסום להצגת מודעות ליצור מהם מקורות נגזרים, על סמך המסננים הבאים:
- priority_range: בחירת מקורות עם עדיפות בטווח הנתון
- תפוגה: בחירת מקורות שתפוגתם חלה אחרי משך הזמן שצוין
- source_filters: בחירת מקורות שבהם filter_data תואם ל-source_filters שצוין
- source_not_filters: בחירת מקורות שהערך שלהם ב-not_filters תואם לערך שצוין ב-source_not_filters
אחרי שמקורות נגזרים נוצרים על סמך הקריטריונים, הם יכולים להשתתף בשיוך.
ציר הזמן של ההרשמה
בזמן t0, קליק של משתמש גורם לטכנולוגיית פרסום 1 לרשום מקור 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, צפייה של משתמש גורמת לטכנולוגיית פרסום 3 לרשום מקור 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 עם הגדרת שיוך לכל מקורות המודעות הטכנולוגיות הקודמים שצוינו:
"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)
- הערך של
filter2לא תואם למקור3
מקורות מתחרים
שדות |
מקור 4' |
טכנולוגיית פרסום שרושמת את מקור התנועה המקורי |
ad-tech4 |
source_event_id |
7567 |
יעד |
https://destination.example.com |
עדיפות |
30 |
expiry |
מועד ההרשמה + יומיים |
טריגרים רשומים
הפעלת Trigger1 על ידי mmp-ad-tech.
תוצאת השיוך (Attribution)
הטריגר 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 טכנולוגיות להצגת מודעות ועם פלטפורמה אחת למדידת ביצועים (MMP). משתמש לוחץ על מודעה מטכנולוגיית הפרסום הראשונה ומתקין את האפליקציה של המפרסם. במהלך השיוך של המרות אחרי ההתקנה, המקור הנגזר עם שיוך ההתקנה מקבל עדיפות על פני מקורות אחרים, גם אם יש להם עדיפות גבוהה יותר.
ציר הזמן של ההרשמה
בזמן t0, אינטראקציה של משתמש גורמת לטכנולוגיית פרסום1 לרשום את מקור1:
"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 |
source_event_id |
3645 |
345789 |
יעד |
android-app://com.example.app |
android-app://com.example.app |
עדיפות |
10 |
20 |
הגדלת מספר ההתקנות של האפליקציה |
כן |
לא |
טריגרים רשומים
הפעלת Trigger1 על ידי mmp-ad-tech.
תוצאת השיוך (Attribution)
הטריגר Trigger1 משויך למקור Source1 כי הוא הוביל להתקנת אפליקציית היעד. שימו לב שלמקור 2 הייתה עדיפות גבוהה יותר.
שיוך פוסטים למקורות שהמערכת התעלמה מהם
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, המקור3 של טכנולוגיית הפרסום3 רשום ב-
"priority": "5". - בזמן t5, Trigger2 של mmp-ad-tech רשום בהגדרות של ad-tech1 ו-ad-tech3.
- בזמן t6, מתבצעת שיוך לטריגר Trigger2, שבו המקור הנגזר מ-Source3 (Source3') זוכה בשיוך
הסבר על התוצאה
השיוך של Trigger1 אבד במקור הנגזר ממקור ad-tech1, ולכן לא נעשה שימוש ב-Source1 כדי ליצור מקור נגזר לשיוך של Trigger2. אם המקור לא היה מפסיד לפני כן בזמן t3, הוא היה מנצח את המקור של ad-tech3' כי יש לו עדיפות גבוהה יותר.