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

שליחת משוב

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

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

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

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

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

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

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

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

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

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

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

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

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

רשימת הרשתות בתהליך בחירת הרשת של Protected Audience API

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

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

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

בתרשים הקודם מוצגת דוגמה לאלגוריתם של רשימת הרשתות בתהליך בחירת הרשת. SDK של תהליך בחירת הרשת (Mediation) יכול להטמיע, אבל בלי יכולת של הצד הראשון. רשת המודעות כדי לבצע אופטימיזציה. 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 של תהליך בחירת הרשת (Mediation) תוכל להשוות את הצעת המחיר של המודעה המנצחת להצעת המחיר הבאה הסף המינימלי להצעת מחיר ברשת.

דוגמה 1:

דוגמה 2:

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

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

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

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

זהו סדר הפעולות לביצוע ברשימת הרשתות בתהליך בחירת הרשת תהליך האימות.

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

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

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

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

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

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

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

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

Protected Audience API לא מציע פתרון מקיף לתהליך בחירת הרשת (Mediation) של כמה מיקומי מודעות בדף. יש לעבד כל מיקום מודעה בנפרד.

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

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