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

שליחת משוב

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

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

תהליך בחירת הרשת (Mediation) ב-Waterfall

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

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

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

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

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

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

תרשים של מודל תהליך בחירת הרשת (Mediation) הפרוגרמטי
איור 2: המודל הפרוגרמטי של תהליך בחירת הרשת (Mediation)

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

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

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

תהליך בחירת הרשת (Mediation) ב-Waterfall של קהל מוגן

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

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

תרשים זרימה של תהליך בחירת הרשת ב-Waterfall של 'קהל מוגן'
איור 3. תהליך בחירת הרשת (Mediation) ב-Waterfall עם Protected Audience API.

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

תוצאת בחירת המודעות

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

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId פועל כמו מצביע אל AdSelectionOutcome. כיום, הפרמטר AdSelectionId מועבר ל-method 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 מופעלת באמצעות מזהה בחירת המודעות וההגדרה שהתקבלה מהקריאה הזו.

הפעלת תהליך בחירת הרשת (Mediation) ב-Waterfall

זה סדר הפעולות להרצת התהליך של תהליך בחירת הרשת (Mediation) ב-Waterfall.

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

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

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

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

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

כדאי לצמצם את שרשראות תהליך בחירת הרשת (Mediation) במכשיר

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

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

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

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

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