מודעות להתקנת אפליקציות הן בדרך כלל המקור העיקרי להתקנות חדשות של אפליקציות לנייד. כדי למקסם את החזר ה-ROI על הוצאות הפרסום, מומלץ לא להציג מודעה להתקנת אפליקציה במכשירים שבהם האפליקציה הזו כבר מותקנת. במסמך הזה אנחנו מתייחסים לשיטה הזו כאל "סינון של מודעות לקידום התקנת אפליקציה".
במאמר הזה אנחנו מציגים הצעה לשימוש ב-Protected Audience ב-Android כדי לתמוך בסינון מודעות בהתאם להקשר, ובפרט בסינון מודעות להתקנת אפליקציות, תוך שמירה על הפרטיות. כדי להשתתף, צריך להביע הסכמה מפורשת לסינון מודעות לקידום התקנת אפליקציה באפליקציה במכשיר. במהלך בחירת המודעות, מודעות פוטנציאליות מסוננות על סמך רשימת האפליקציות שמותקנות במכשיר, שמוכרות לטכנולוגיית הפרסום.
רשימת האפליקציות המותקנות גלויה רק בתהליך בחירת המודעות, והיא מסתמכת על פלטפורמת הקנייה כדי לסמן שמודעה מסוימת צריכה להיפילטר על סמך קיומה של אפליקציה במכשיר.
כדי להגדיר סינון של מודעות להתקנת אפליקציות, פועלים לפי השלבים הבאים:
שלב 1: רישום האפליקציה לסינון מודעות להתקנת אפליקציה
כדי להפעיל סינון של מודעות לקידום התקנת אפליקציות, מפתח האפליקציה מפעיל את registerForAdFiltering API לרישום אפליקציות מהאפליקציה שלו או מ-SDK של טכנולוגיית פרסום, עם רשימה של כתובות eTLD+1 של קונים בטכנולוגיית פרסום. כך הקונים ברשימה, ורק הם, יכולים לסנן מודעות על סמך סטטוס ההתקנה של האפליקציה, ישירות או באמצעות ה-SDK של טכנולוגיית הפרסום שלהם. הרשמה מאפשרת למפתח האפליקציה לשלוט באופן מלא בשאלה אם האפליקציה שלו צריכה להשתתף או לא בסינון של מודעות להתקנת אפליקציות.
java
void registerForAdFiltering(List<AdTechIdentifier> buyers);
שלב 2: שליחת בקשה לסינון מודעות להתקנת אפליקציות
כשמודעה נשקלת להגשת הצעת מחיר, הקונים יכולים לסמן את המודעה לסינון על סמך סטטוס ההתקנה של האפליקציה. הפעולה הזו מתבצעת על ידי הכללת שם החבילה של האפליקציה במטא-נתונים של המודעה. בקשת הסינון של מודעות להתקנת אפליקציות היא חלק מנתוני המודעות שמועברים לתהליך המכרז של Protected Audience. נתוני המודעות האלה נוצרים באופן שונה בהתאם לסוג המודעה: מודעה קונטקסטואלית או מודעה לרימרקטינג.
- בתרחיש לדוגמה של מודעות קונטקסטואליות, שהוא התרחיש העיקרי לסינון מודעות להתקנת אפליקציות, מידע הסינון נכלל כחלק מנתוני המודעות שהקונים יכולים להעביר למוכרים בתגובה להצעת מחיר קונטקסטואלית מחוץ ל-Protected Audience. ב-Protected Audience, מידע הסינון אמור לחזור כחלק מהתגובה ההקשרית, בדיוק כמו כל מטא-נתונים אחרים שספציפיים למודעה.
- בתרחיש השימוש של רימרקטינג, ב-Protected Audience מצפים שמידע על סינון ייכלל בקהל המותאם אישית. יש 2 הזדמנויות להכללה הזו: כשמצטרפים לקהל וכשמאחזרים נתוני קהל חדשים כחלק מתהליך עדכון הקהל.
הבקשה לסינון מודעות להתקנת אפליקציות צריכה להיראות כך באובייקט ה-JSON
AdData:json { "render_uri": "https://..", "metadata": {..}, "filters": { "app_install": { "app_package_names": ["app1.package", "app2.package"] } } }
שלב 3: סינון מודעות להתקנת אפליקציות במהלך בחירת המודעות
במהלך בקשה להצגת מודעה, הקונה יכול להעביר כמה מודעות בחזרה למוכר עם פרטי סינון, כדי שאפשר יהיה לסנן מודעות של אפליקציות מותקנות. הצד המוכר נדרש להעביר את פרטי הסינון כחלק מהגדרת הפונקציה selectAds בשדה adData. ב-Android מצפים לפורמט הודעה דומה לזה.
AdData myAdData = new AdData.Builder()
.setRenderUri(Uri.parse("https://.."))
.setMetadata("{...}")
.setFilters(new AdFilters.Builder()
.setAppInstalledFilter(new AppInstalledFilter.Builder()
.setPackageNames(ImmutableList.of("app1.package", "app2.package"))
.build())
.build())
.build();
AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig.Builder()
.setSeller(AdTechIdentifier.fromString("example-ssp1.com"))
.setDecisionLogicUri(Uri.parse("https://..."))
...
.setContextualAds(ImmutableList.of(new ContextualAd.Builder()
.setBuyer(AdTechIdentifier.fromString("example.com"))
.setReportingUri("https://example.com/reporting")
.setBid(20)
// myAdData could be taken from the JSON defined earlier
.setAd(myAdData)
.build()))
.build();
// Invoke ad services API to initiate ad selection workflow.
selectAds(myAdSelectionConfig);
הסינון מתבצע ב-selectAds API. מסנני Protected Audience מסננים את המודעה אם האפליקציה שצוינה בהודעה תואמת לאפליקציה ברשימת האפליקציות הספציפיות של הקונים בטכנולוגיית הפרסום. יש שתי תוצאות אפשריות:
- האפליקציה לא נמצאת ברשימה הזו, כלומר היא לא מותקנת ולא נפתחה.
- האפליקציה מופיעה ברשימה, כלומר היא מותקנת ופתוחה.
אם Protected Audience מזהה שאפליקציה כבר קיימת, המודעה לא תיכלל ברשימת המודעות שהמכרז משתמש בה כדי לפעול
scoreAds.
שיקולים כשמדובר במודעות קונטקסטואליות
עם סינון מודעות להתקנת אפליקציות, ממשקי Protected Audience API מתחילים לתמוך בסינון מודעות בהתאם להקשר. יש כמה דברים שחשוב לציין במצבים שבהם המכרז הוא שילוב של מודעות הקשריות ומודעות רימרקטינג, או שהוא מורכב רק ממודעות הקשריות.
- כשמריצים
selectAdמכרז, לקונה יש אפשרות להעביר רשימה של אובייקטים מסוגContextualAd. האובייקטים האלה מכילים את eTLD+1 של הקונה של המודעה, את הצעת המחיר על המודעה, כתובת URL שמפנה ללוגיקה של הדיווח על המודעה, ואתAdDataשמכיל את כתובת ה-URL של תוכן המודעה בפועל, וחתימת אימות ששייכת לקונה (פרטים נוספים זמינים במאמר בנושא חתימה על מודעות קונטקסטואליות). שימו לב שהפורמטAdDataמשמש גם במודעות לפי הקשר וגם במודעות רימרקטינג. - בתחילת תהליך המכרז, מודעות לרימרקטינג ומודעות שמטרגטות לפי הקשר מסוננות באמצעות קבוצת שמות החבילות שצוינו ב-
AdData.adFilters.appInstallFilters.packageNames. לאחר מכן, המערכת קובעת את ערכי הצעות המחיר לכל מודעות הרימרקטינג, ומקצה ניקוד למודעות הרימרקטינג ולמודעות ההקשריות באמצעות הפונקציהscoreAdsשסופקה. המודעה עם הציון הכי גבוה מנצחת. הערה: התהליך הזה פועל גם אם לא מוצגות מודעות רימרקטינג. אם מודעה קונטקסטואלית זוכה במכרז ומופעל דיווח על חשיפה על ידי האפליקציה, Protected Audience מוריד ומבצע פונקציית JS בשם
reportWin()מכתובת הדיווח שכלולה בנתוני המודעה הקונטקסטואלית. זה דומה לדיווח על מודעת רימרקטינג שזכתה במכרז.פונקציית דיווח לדוגמה ב-JavaScript:
function reportWin(ad_selection_signals, per_buyer_signals, signals_for_buyer, contextual_signals) { let reporting_address = 'https://reporting.example.com'; return {'status': 0, 'results': {'reporting_uri': reporting_address + '?some_signal=' + per_buyer_signals.some_signal} }; }
חתימה על מודעות לפי הקשר
מודעות קונטקסטואליות שכוללות סינון של מודעות להתקנת אפליקציות צריכות להיות חתומות על ידי הקונה. הפלטפורמה משתמשת בחתימה הזו כדי לאמת את הטכנולוגיה הפרסומית שסיפקה את המודעות, ואת המסננים של הטכנולוגיה הפרסומית להתקנת אפליקציות שצריך להחיל על המודעות. הפעולה הזו נועדה למנוע מפרסום דיגיטלי זדוני להשתמש בזהות של פרסום דיגיטלי אחר כדי להפיק תועלת מההרשמה של הפרסום הדיגיטלי האחר לסינון התקנות של אפליקציות.
ארגז החול לפרטיות יאחזר את המפתחות האלה מנקודת הקצה של טכנולוגיית הפרסום שסופקה במהלך ההרשמה. השיטה המומלצת היא לעדכן את המפתחות לעיתים קרובות, אבל לפחות כל 6 חודשים.
במהלך תהליך ההרשמה, ארגז החול לפרטיות יבקש מספקי טכנולוגיות פרסום לאשר את הזמינות של נקודת הקצה שסופקה על ידי טכנולוגיית הפרסום. פרטים נוספים על הפעולות שספקי טכנולוגיות פרסום קיימים וחדשים צריכים לבצע זמינים בהוראות ההרשמה.
מדריך למפתחים עם הוראות מפורטות יותר להטמעה יפורסם בעתיד הקרוב.
מומלץ בשבילכם
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- מדריך למפתחים בנושא Protected Audience API ב-Android
- הערות מוצר
- תמיכה בטירגוט מותאם אישית לפי קהל באמצעות Protected Audience API