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