תמיכה במכרזים של כמה אתרי מכירה בעזרת Protected Audience Mediation

פלטפורמות פרסום בצד המוכר (SSP) בדרך כלל מגוונות את מקורות הביקוש למודעות כדי לבצע אופטימיזציה להגדלת ההכנסות מפרסום. תהליך בחירת הרשת מאפשר לרשת מודעות או לשירות להפעיל כמה רשתות מודעות כדי לקבוע איזו מודעה הכי מתאימה למיקום מודעה מסוים. בהצעה הזו מוסבר איך אפשר להרחיב את Protected Audience API ב-Android כדי להטמיע פונקציונליות של תהליך בחירת רשת (waterfall) לשמירה על פרטיות. כיום, רשתות מודעות מספקות למפתחי אפליקציות דרכים שונות לנהל מכירות פומביות של מודעות מכמה מוכרי מודעות:

1. תהליך בחירת רשת ב-Waterfall: מפתחי אפליקציות מגדירים רשימה מסודרת של רשתות מודעות, שלרוב מדורגות לפי eCPMs ההיסטוריות של הרשת. הרשימה הזו נקראת שרשרת גישור. פלטפורמת ה-Mediation של מפתח האפליקציה משתמשת ברשימה הזו כדי להפעיל רשתות פרסום בסדר שבו הן מופיעות, כדי לקבוע אילו מקורות רלוונטיים לביקוש למודעות.
2. תהליך בחירת רשת מבוסס-תוכנה (Programmatic Mediation): מפתח האפליקציה מגדיר כמה רשתות מודעות להשתתפות בבידינג על הזדמנויות להצגת מודעות. הרשתות האלה יכולות להגיש הצעות מחיר בזמן אמת על סמך הערך שהן מייחסות להזדמנות.
3. תהליך משולב לבחירת רשת (Mediation): שילוב של טכניקות Waterfall וטכניקות של תהליך ממוכן לבחירת רשת.

רשימת רשתות בתהליך בחירת רשת

בתהליך בחירת רשתות מסוג Waterfall, כשמתעוררת הזדמנות להצגת מודעה, SDK של מודעות שולח בקשה לשרת הקצה העורפי שלו. במקום להגיב לבקשה עם קריאייטיב של מודעה מנצחת, השרת מגיב עם שרשרת של תהליך בחירת הרשת (Mediation) שמכילה רשימה של רשתות מודעות שמסודרות לפי עלות בפועל לאלף חשיפות היסטורית.

איור 1. מודל ה-Waterfall בתהליך בחירת הרשת (Mediation).

במודל Waterfall בצד השרת, SDK של מודעות קורא לכל רשת מודעות (או ל-SDK של מכרז משלה) בסדר שצוין בשרשרת תהליך בחירת הרשת. אם רשת מודעות יכולה למלא את הבקשה להצגת מודעה, רשת המודעות מציגה את המודעה. אם לא, הבקשה נשלחת לרשת הבאה בשרשרת. התהליך הזה חוזר על עצמו עד שהבקשה מתבצעת או עד שרשרת הבקשות מסתיימת.

אופטימיזציה של תהליך בחירת הרשת ב-Waterfall מתבצעת לעיתים קרובות על ידי סידור מחדש של שרשרת בחירת הרשת על בסיס קבוע, בהתאם להערכה מחדש של העלות בפועל לאלף חשיפות ממקורות ביקוש למודעות של צד ראשון.

תהליך בחירת רשת פרוגרמטי

תהליך רגיל לבחירת רשת (שנקרא גם "בידינג על שטחי פרסום") הוא חלופה לשימוש בנתונים היסטוריים של עלות בפועל לאלף חשיפות כדי לקבוע איזו רשת מודעות תקבל את ההזדמנות להציג בקשה להצגת מודעה. בגישור פרוגרמטי, הספקים משתמשים בערכי בידינג בזמן אמת כדי למצוא את המודעה הזוכה.

איור 2: מודל התיווך הפרוגרמטי

תהליך משולב לבחירת רשת (Mediation)

חלק מהפתרונות של תהליך בחירת רשת (Mediation) מבוסס-תוכנה משלבים רשתות מודעות במצב היברידי של Waterfall ובידינג, כדי לספק יותר שליטה על המודעה וליהנות מהיתרון של שימוש בעלויות בפועל לאלף חשיפות בזמן אמת כדי למקסם את ההכנסות מרשתות מודעות משתתפות.

במודלים היברידיים של בחירת רשת, רשתות מודעות וספקי פתרונות לבחירת רשת יכולים לספק גמישות רבה יותר למפתחי אפליקציות על ידי שילוב של אלמנטים של Waterfall ובידינג בזמן אמת. מודלים היברידיים מאפשרים למפתחי אפליקציות להגדיר רשתות פרסום על סמך נתונים היסטוריים של עלות בפועל לאלף חשיפות. כך הם יכולים להציג מודעה לפני שהם מפעילים בידינג בזמן אמת עם רשתות משתתפות כדי למלא הזדמנויות להצגת מודעות.

תהליך בחירת רשת ב-Waterfall בשילוב עם Protected Audience API

‫Protected Audience API ב-Android תומך בתהליך בחירת הרשת לפי רשימה, באמצעות מספר מכרזים, כל אחד עבור צומת נפרד בתרשים תהליך בחירת הרשת. אם אין זוכה במכרז, מופעל הצומת הבא של מכרז הרשת עד שכל הרשתות ברשימה מופעלות. כך מתבצע תהליך בחירת הרשת (Mediation) בשיטת Waterfall:

1. ה-SDK של תהליך בחירת הרשת מאחזר את שרשרת תהליך בחירת הרשת מנקודת הקצה של שרת המודעות ההקשרי, שיכול להחזיר מודעות הקשריות או שרשראות של תהליך בחירת הרשת.
2. אם נקודת הקצה של שרת המודעות מחזירה שרשרת של תהליך בחירת הרשת, ה-SDK של תהליך בחירת הרשת חוזר על כל פריט בשרשרת לפי הסדר, ומפעיל את ה-SDK של רשת המודעות המשתתפת כדי להריץ בחירה של מודעות בהקשר וברימרקטינג. כל פריט בשרשרת מייצג בקשה של רשת מודעות לרכישת שטחי פרסום במחיר מסוים עבור מספר מסוים של חשיפות, קליקים או זמן הצגת מודעות.
3. אם אף אחד מפריטי התנועה בשרשרת לא בוחר מודעה מנצחת, יכול להיות ש-SDK של תהליך בחירת הרשת (Mediation) יבחר להציג מודעה מרשת המודעות שלו על ידי הפעלת תהליך בחירת מודעות לקהלים מוגנים, שמתחשב גם במודעות רימרקטינג וגם במודעות קונטקסטואליות.

איור 3. גישור בשיטת Waterfall עם Protected Audience API.

התרשים שלמעלה מייצג דוגמה לאלגוריתם של תהליך בחירת הרשת (Waterfall) ש-SDK של פלטפורמת גישור יכול להטמיע, אבל בלי האפשרות לרשת המודעות מאינטראקציה ישירה לבצע אופטימיזציה. ‫Protected Audience API תומך באופטימיזציה של רשתות פרסום מהדומיין הנוכחי, ומאפשר שרשור של תהליכי עבודה לבחירת מודעות ודיווח על חשיפות שזכו במכרז.

AdSelection outcome

סוג הערך שמוחזר של selectAds() הוא אובייקט AdSelectionOutcome. ‫AdSelectionOutcome מכיל את ה-URI של העיבוד של המודעה הזוכה ואת AdSelectionId, שהוא מספר שלם אטום שמזהה את הקריאייטיב של המודעה בפריט הזוכה.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

‫AdSelectionId פועל כמו מצביע ל-AdSelectionOutcome. היום, הערך AdSelectionId מועבר לשיטה reportResult() כפרמטר ReportImpressionInput כדי לעזור לזהות את המודעות הנכונות שהשיטות reportWin() ו-reportResult() מופעלות עליהן.

הצעה לבחירת מודעות בשרשרת

אנחנו מציעים להשתמש ב-selectAds() עם AdSelectionFromOutcomesConfig.

val config = AdSelectionFromOutcomesConfig.Builder()
        .setSeller(seller)
        .setAdSelectionIds(listOf(outcome1pAdSelectionId))
        .setSelectionSignals({"bid_floor": bidFloorOfNextNetworkInline})
        .setSelectionLogicUri(selectionLogicUri)
        .build()
adSelectionClient.selectAds(config)

כך ערכת ה-SDK לגישור יכולה להשוות בין הצעת המחיר של המודעה הזוכה לבין מחיר המינימום להצעת מחיר של הרשת הבאה בתור.

דוגמה 1:

דוגמה 2:

דיווח על חשיפות שזכו

אם יש מודעה שזכתה במכרז selectAds(AdSelectionFromOutcomes), היא תזכה בתהליך בחירת הרשת. לאחר מכן מתבצעת קריאה אל reportImpression עם מזהה בחירת המודעה של המודעה הזוכה מ-selectAds(AdSelectionFromOutcomes) ועם AdSelectionConfig התואם.

אם המודעה המנצחת מוחזרת מ-selectAds(AdSelectionConfig) עבור אחת מהרשתות, מתבצעת קריאה ל-reportImpression עם מזהה בחירת המודעה וההגדרה מהקריאה הזו.

הפעלת רשימת רשתות בתהליך בחירת רשת

זהו סדר הפעולות בתהליך בחירת הרשת בשיטת Waterfall.

1. הפעלת בחירת מודעות מאינטראקציה ישירה.
2. חזרה על התהליך בשרשרת לבחירת רשת. לכל רשת של צד שלישי, מבצעים את הפעולות הבאות:
   1. בניית AdSelectionFromOutcomeConfig, כולל מחיר המינימום לבידינג של outcomeId מאינטראקציה ישירה ושל SDK של צד שלישי
   2. מבצעים קריאה ל-selectAds() עם config מהשלב הקודם.
   3. אם התוצאה לא ריקה, מחזירים את המודעה.
   4. מפעילים את השיטה selectAds() של מתאם הרשת הנוכחי של ה-SDK. אם התוצאה לא ריקה, מחזירים את המודעה.
3. אם לא נמצא מנצח בשרשרת, המערכת מחזירה את המודעה מהדומיין הנוכחי.

שיטות מומלצות

הפעלת מכרזים בהקשר לפני אופטימיזציה של נתונים שנאספים ישירות מהמשתמשים

הביקוש לרימרקטינג יכול ליצור הצעות מחיר גבוהות שיכולות להניב תוצאות טובות בשרשרת גישור. חיתוך הוא תהליך שמשמש לעיתים קרובות לשיפור רשימת הקהלים לרימרקטינג, כדי לאפשר אופטימיזציה של נתונים ממקור ראשון.

הביקוש לרימרקטינג של Protected Audience API זמין רק בצד הלקוח במכרזים של Protected Audience. לכן, יכול להיות שיהיה לכם קשה להפעיל אופטימיזציה של צד ראשון בצד השרת. כדי לצמצם את הבעיות שקשורות לאופטימיזציה של נתונים ממקור ראשון, מומלץ להפעיל קודם את המכרז ההקשרי ואז לבצע אופטימיזציה של נתונים ממקור ראשון על סמך תוצאת המודעה הזוכה, כפי שמתואר בהמשך הדף הזה.

שמירה על שרשראות תיווך קצרות במכשיר

כדי להשיג ביצועים אופטימליים, חשוב לשמור על שרשראות קטנות של תהליכי בחירת רשת לניוד במכשיר. עלות החישוב של הביצוע במכשיר עשויה להיות לינארית במספר המכרזים שנבדקים כחלק משרשרת תהליך הבחירה של רשת המודעות. במילים אחרות, יותר צמתים מובילים לדרישות גבוהות יותר של מחזורי חישוב ולזמן אחזור ארוך יותר. כשמעבירים צמתים להערכת תהליך גישור במכשיר, חשוב להביא בחשבון את ההשפעה של זמן האחזור על ההכנסות.

שיקולים נוספים

‫Protected Audience API לא מציע פתרון מקיף לגישור בין כמה מיקומי מודעות. כל משבצת פרסום צריכה לעבור עיבוד בנפרד.

‫Protected Audience Mediation API תומך ברשימת רשתות בתהליך בחירת הרשת ובחלק מהאפשרויות של תהליך בחירת הרשת בתכנות. בעתיד נשתף פרטים נוספים על תמיכה בתרחישי שימוש נוספים בתיווך פרוגרמטי.

מכיוון שתהליך בחירת המודעות ב-Protected Audience מתבצע אחרי שליפת המודעות הקונטקסטואליות, הפעלת Protected Audience API עשויה להשפיע על זמן האחזור מקצה לקצה של בקשות להצגת מודעות.