התקנות חדשות של אפליקציות לנייד נובעות בדרך כלל ממודעות להתקנת אפליקציה. כדי למקסם את החזר ה-ROI על הוצאות הפרסום, מומלץ לא להציג מודעה להתקנת אפליקציה במכשירים שבהם אותה אפליקציה כבר מותקנת. בהצעה הזו, אנחנו קוראים לכלל הזה "סינון מודעות להתקנת אפליקציה".
בהצעה הזו נסביר איך התכונה 'קהל מוגן' ב-Android תומכת בסינון מודעות לפי הקשר, ובמיוחד בסינון מודעות להתקנת אפליקציות, באופן שמגן על הפרטיות. כדי להשתמש בתכונה הזו, האפליקציה במכשיר צריכה להביע הסכמה מפורשת לסינון מודעות להתקנות אפליקציה. במהלך בחירת המודעה, המערכת מסננת את הבקשות להצגת מודעות על סמך רשימת האפליקציות המותקנות במכשיר שמוכר על ידי טכנולוגיית הפרסום.
רשימת האפליקציות המותקנות מוצגת רק בתהליך בחירת המודעות, והיא מבוססת על הפלטפורמה של צד הקנייה כדי לסמן שמודעה מסוימת צריכה לעבור סינון על סמך נוכחות האפליקציה במכשיר.
כדי להגדיר סינון מודעות להתקנת אפליקציה, מבצעים את השלבים הבאים:
שלב 1: רישום האפליקציה לצורך סינון של מודעות להתקנת אפליקציה
כדי להביע הסכמה לסינון מודעות להתקנת אפליקציות, מפתח האפליקציה מפעיל את ה-API לרישום אפליקציה registerForAdFiltering
מהאפליקציה שלו, או את ה-SDK של הפרסום הדיגיטלי, עם רשימה של מפתחות eTLD+1 של קנייני פרסום. כך הקונים ברשימה, ורק הם, יוכלו לסנן מודעות על סמך סטטוס ההתקנה של האפליקציה, בין שבאופן ישיר ובין שבאמצעות ה-SDK של פלטפורמת הפרסום שלהם. ההרשמה מעניקה למפתח האפליקציה שליטה מלאה בהחלטה אם האפליקציה שלו תשתתף בסינון של מודעות להתקנת אפליקציות או לא.java
void registerForAdFiltering(List<AdTechIdentifier> buyers);
שלב 2: שליחת בקשה לסינון מודעות להתקנת אפליקציות
כשמודעה נלקחת בחשבון לבידינג, הקונים יכולים לסמן אותה לסינון על סמך סטטוס ההתקנה של האפליקציה. כדי לעשות זאת, צריך לכלול את שם החבילה של האפליקציה במטא-נתונים של המודעה. בקשת הסינון של מודעות להתקנת אפליקציות היא חלק מנתוני המודעות שמוזנים לתהליך המכרז של Protected Audience. נתוני המודעות האלה נוצרים באופן שונה בהתאם לסוג המודעה: מודעה לפי הקשר או מודעה לרימרקטינג.
- בתרחיש לדוגמה של מודעות לפי הקשר, שהוא התרחיש העיקרי לסינון של מודעות להתקנת אפליקציות, פרטי הסינון נכללים בנתוני המודעות שהקונים יכולים לספק למוכרים בתגובה להצעת מחיר לפי הקשר מחוץ ל'קהל מוגן'. התכונה 'קהל מוגן' מצפה שהמידע על הסינון יוחזר כחלק מהתגובה לפי הקשר, בדיוק כמו כל מטא-נתונים אחרים שספציפיים למודעה.
- בתרחיש לדוגמה של רימרקטינג, Protected Audience מצפה שהמידע מהסינון יהיה כלול בקהל המותאם אישית. יש שתי הזדמנויות להכללה הזו: כשמצטרפים לקהל ומאחזרים
נתוני קהל חדשים כחלק מתהליך עדכון הקהל.
הבקשה לסינון מודעות להתקנת אפליקציות צריכה להיראות כך באובייקט ה-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 above
.setAd(myAdData)
.build()))
.build();
// Invoke ad services API to initiate ad selection workflow.
selectAds(myAdSelectionConfig);
הסינון מעובד בתוך ה-API של selectAds
. התכונה 'קהל מוגן' מסננת את המודעה אם האפליקציה שצוינה בהודעה תואמת לאפליקציה ברשימת התקנות האפליקציות הספציפית של רוכשי טכנולוגיות הפרסום. יש שתי תוצאות אפשריות:
- האפליקציה לא נמצאת ברשימה הזו, כלומר היא לא מותקנת ולא נפתחת.
- האפליקציה נמצאת ברשימה הזו, כלומר היא מותקנת ואפשר לפתוח אותה.
אם Protected Audience מזהה שכבר קיימת אפליקציה, המודעה מוחרגת מרשימת המודעות שבהן נעשה שימוש במכרז כדי להציג את
scoreAds
.
שיקולים כשמדובר במודעות לפי הקשר
בעזרת סינון של מודעות להתקנת אפליקציות, ממשקי Protected Audience API מתחילים לתמוך בסינון של מודעות לפי הקשר. יש כמה דברים חשוב לציין במצבים שבהם המכרז הוא שילוב של מודעות לפי הקשר ומודעות לרימרקטינג, או שהוא מורכב רק ממודעות לפי הקשר.
- כשמופעל מכרז של
selectAd
, לקונה יש אפשרות להעביר ברשימה של אובייקטים שלContextualAd
. האובייקטים האלה מכילים את ה-eTLD+1 של רוכש המודעה, את הצעת המחיר על המודעה, כתובת URL שמפנה ללוגיקת הדיווח על המודעה ואתAdData
שמכיל את כתובת ה-URL של תוכן המודעה בפועל, וכן חתימה לאימות ששייכת לקונה (פרטים נוספים זמינים במאמר חתימה על מודעות לפי הקשר). שימו לב שהפורמטAdData
משמש גם במודעות לפי הקשר וגם במודעות לרימרקטינג. - בתחילת תהליך המכרז, מודעות לפי הקשר ומודעות רימרקטינג מסוננות באמצעות קבוצת שמות החבילות שצוינה ב-
AdData.adFilters.appInstallFilters.packageNames
. לאחר מכן, המערכת קובעת את ערכי הצעות המחיר לכל מודעות הרימרקטינג, ומחשבת את הדירוג של מודעות הרימרקטינג ושל מודעות לפי הקשר באמצעות הפונקציהscoreAds
שסופקה. המודעה עם הדירוג הגבוה ביותר תנצח. חשוב לדעת שהתהליך הזה פועל גם אם אין מודעות רימרקטינג. אם מודעה לפי הקשר מנצחת במכרז והדיווח על חשיפות מופעל על ידי האפליקציה, הקהל המוגן מוריד ומפעיל פונקציית JS בשם
reportWin()
מכתובת ה-URL לדיווח שכלולה בנתוני המודעה לפי הקשר. הדיווח הזה דומה לדיווח על מודעה לרימרקטינג שזכתה במכרז.דוגמה לפונקציית דיווח ב-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} }; }
חתימה על מודעות לפי הקשר
על הקונה לחתום על מודעות לפי הקשר שכוללות סינון של התקנות אפליקציות. הפלטפורמה משתמשת בחתימה הזו כדי לאמת את טכנולוגיית הפרסום שסיפקה את המודעות ואת אפליקציית טכנולוגיית הפרסום שמטמיעה מסננים שיוחלו על המודעות. המטרה של כך היא למנוע מ-AdTech זדוני להשתמש בזהות של AdTech אחר כדי ליהנות מהרשמה של AdTech אחר לסינון התקנות של אפליקציות.
ארגז החול לפרטיות יאתר את המפתחות האלה מנקודת הקצה של טכנולוגיית הפרסום שצוינה במהלך ההרשמה. השיטה המומלצת היא לעדכן את המפתחות לעיתים קרובות, אבל לא מאוחר יותר מכל 6 חודשים.
במהלך תהליך ההרשמה, ארגז החול לפרטיות יבקש מספקי טכנולוגיות הפרסום לאשר את הזמינות של נקודת הקצה שסופקו על ידי ספקי טכנולוגיות הפרסום. פרטים נוספים על הפעולות הנדרשות מצוותים טכניים של מומחים במודעות שכבר רשומים ומהצוותים הטכניים החדשים שיירשמו מפורטים בהוראות הרישום.
בעתיד הקרוב יתפרסם מדריך למפתחים עם הוראות מפורטות יותר להטמעה.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- מדריך למפתחים בנושא Protected Audience API ב-Android
- נתוני גרסה
- תמיכה בטירגוט לפי קהל מותאם אישית באמצעות Protected Audience API