הגדרה של נתוני קהל

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

אינכם מפתחים? אפשר לקרוא את המאמר סקירה כללית על Protected Audience API.

קבוצות אינטרס ב-Protected Audience API

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

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

פונקציות API

joinAdInterestGroup()

הפלטפורמה בצד הביקוש (DSP) של המפרסם או המפרסם עצמו מתקשרים אל navigator.joinAdInterestGroup() כדי לבקש מהדפדפן להוסיף קבוצת תחומי עניין לרשימת החברים של הדפדפן.

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

joinAdInterestGroup() זקוקה להרשאה מ:

• האתר שבו מבקרים
• הבעלים של קבוצת תחומי העניין

פירוש הדבר הוא ש-malicious.example לא יכול להפעיל את joinAdInterestGroup() עבור קבוצת אינטרס בבעלות dsp.example.com, מבלי להעניק את ההרשאה dsp.example.com.

הרשאה מהאתר שבו ביקרת

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

שימוש לדוגמה

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

const interestGroup = {
  owner: 'https://dsp.example',
  name: 'custom-bikes',
  biddingLogicUrl: ...,
  biddingWasmHelperUrl: ...,
  updateUrl: ...,
  trustedBiddingSignalsUrl: ...,
  trustedBiddingSignalsKeys: ['key1', 'key2'],
  userBiddingSignals: {...},
  ads: [bikeAd1, bikeAd2, bikeAd3],
  adComponents: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2],
};

navigator.joinAdInterestGroup(interestGroup, 7 * kSecsPerDay);

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

נקודה חשובה: כל כתובות ה-URL שמשמשות כפרמטרים לשיטות של Protected Audience API חייבות להגיע ממקורות מאובטחים: יש להציג את כל המשאבים באמצעות כתובות URL מסוג HTTPS. איך משתמשים ב-HTTPS לפיתוח מקומי מסביר איך לעשות זאת כשמפעילים את Protected Audience API באופן מקומי. בנוסף, biddingLogicUrl, decisionLogicUrl ו-trustedBiddingSignals מחייבים כותרת תגובת HTTP מסוג X-Allow-FLEDGE: true.

מאפיינים נדרשים

המאפיינים היחידים הנדרשים לקבוצות אינטרס הם owner ו-name:

מאפיין (property)	דוגמה	תפקיד
owner	https://dsp.example	מקור הבעלים של קבוצת תחומי העניין.
name	custom-bikes	השם של קבוצת האינטרס.

מאפיינים אופציונליים

שאר המאפיינים הם אופציונליים:

biddingLogicUrl^{1, 2}

דוגמה: https://dsp.example/bid/custom-bikes/bid.js

תפקיד: כתובת URL לבידינג של JavaScript ב-worklet.

biddingWasmHelperUrl^{1, 2}

דוגמה: https://dsp.example/bid/custom-bikes/bid.wasm

תפקיד: כתובת URL של קוד WebAssembly שנוצר מ-biddingLogicUrl.

updateUrl²

דוגמה: https://dsp.example/bid/custom-bikes/update

תפקיד: כתובת URL שמחזירה קובץ JSON כדי לעדכן את המאפיינים של קבוצת תחומי העניין. (עדכון נתוני קהל ורענון מודעות).

trustedBiddingSignalsUrl²

דוגמה: https://dsp.example/trusted/bidding-signals

תפקיד: כתובת URL בסיסית לבקשות מפתח/ערך לשירות מפתח/ערך מהימן של מגיש הצעות המחיר.

trustedBiddingSignalsKeys

דוגמה: ['key1', 'key2' ...]

התפקיד: מפתחות לבקשות לשירות מפתח/ערך מהימן במפתח/ערך.

userBiddingSignals

דוגמה: {...}

תפקיד: מטא-נתונים נוספים שהבעלים יכולים להשתמש בהם במהלך הבידינג.

ads¹

דוגמה: [bikeAd1, bikeAd2, bikeAd3]

תפקיד: מודעות שייתכן שיוצגו עבור קבוצת תחומי העניין הזו.

adComponents

דוגמה: [customBike1, customBike2, bikePedal, bikeFrame1, bikeFrame2]

תפקיד: רכיבים של מודעות שמורכבות מכמה חלקים.

¹ הנכסים biddingLogicUrl ו-ads הם אופציונליים, אך נדרשים כדי להשתתף במכרז. יכולים להיות תרחישים לדוגמה ליצירת קבוצת תחומי עניין בלי המאפיינים האלה: לדוגמה, יכול להיות שבעלים של קבוצת תחומי עניין ירצה להוסיף דפדפן לקבוצת תחומי עניין בקמפיין שעדיין לא פועל או לשימוש עתידי אחר, או שתקציב הפרסום שלו ייגמר באופן זמני.

² בהטמעה הנוכחית של Protected Audience API, לbiddingLogicUrl, biddingWasmHelperUrl, updateUrl ו-trustedBiddingSignalsUrl צריך להיות מקור זהה לזה של הבעלים. יכול להיות שזו לא מגבלה לטווח ארוך, ובכתובות ה-URL ads ו-adComponents אין מגבלה כזו.

ציון מודעות לקבוצת עניין

האובייקטים ads ו-adComponents כוללים כתובת URL לקריאייטיב של מודעה, ואפשר גם להשתמש במטא-נתונים שרירותיים בשלב הבידינג.

למשל:

{
  renderUrl: 'https://cdn.example/.../bikeAd1.html',
  metadata: bikeAd1metadata // optional
}

leaveAdInterestGroup()

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

navigator.leaveAdInterestGroup({
  owner: 'https://dsp.example',
  name: 'custom-bikes'
});

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

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

שאלות נפוצות

מהו המספר המרבי של קבוצות אינטרס לכל בעלים של קבוצה למשתמש יחיד?

Chrome מאפשר עד 1,000 קבוצות של תחומי עניין לכל בעלים, ועד 1,000 בעלים של קבוצות של תחומי עניין. המגבלות האלה נועדו לשמש כמעקות הגנה, ולא לפגוע בהן במסגרת הפעלה רגילה.

איך אוכל למקסם מודעות מקבוצות של תחומי עניין שעומדות בדרישות הסף של k-anon?

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

מנקודת מבט טקטית, כדאי לשקול את האפשרויות הבאות:

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

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

כל ההפניות ל-Protected Audience API

תוכלו להיעזר במדריכים הבאים עם ה-API:

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

הסבר על Protected Audience API כולל גם פרטים על התמיכה בתכונות והאילוצים.