סקירה כללית של Protected Audience API

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

עדכון: השם של FLEDGE השתנה ל-Protected Audience API. למידע נוסף על שינוי השם, ניתן לקרוא את הפוסט בבלוג.

למי המאמר הזה מיועד?

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

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

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

מה זה Protected Audience API?

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

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

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

Protected Audience API בדקה

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

מחזור החיים של Protected Audience API.

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

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

• השם של קבוצת האינטרס: לדוגמה, 'אופניים בהתאמה אישית'.
• הבעלים של קבוצת האינטרס: לדוגמה, 'https://dsp.example'.
• פרטי התצורה של קבוצות תחומי עניין על מנת לאפשר לדפדפן לגשת לקוד הבידינג, לקוד המודעות ולנתונים בזמן אמת, במקרה שהבעלים של הקבוצה מוזמנים להגיש הצעות מחיר במכרז של מודעות.

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

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

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

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

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

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

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

בית העסק יכול לדווח על תוצאת המכרז (reportResult()), והקונים יכולים לדווח על הזכיות שלהם (reportWin()).

מידע נוסף על דוחות מכרזים של Protected Audience.

למה אנחנו צריכים את Protected Audience API?

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

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

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

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

איך אפשר לנסות את Protected Audience API?

• במדריך למפתחים בנושא Protected Audience API מוסבר איך משתמשים ב-API ואיך בודקים אותו באופן מקומי.

• באתר Protect-audience-demo.web.app תוכלו למצוא הדרכה מפורטת על פריסה בסיסית של Protected Audience באתרים של מפרסמים ובעלי תוכן דיגיטלי. בסרטון ההדגמה של Protected Audience מוסבר איך הקוד הזה פועל ואיך תוכלו להשתמש בכלי הפיתוח ל-Chrome לניפוי באגים.

אילו הגדרות דפדפן זמינות?

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

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

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

קריאות ל-API לא יכולות לגשת לחברות בקבוצה כשמשתמשים גולשים במצב פרטי, והחברות תוסר כשהמשתמשים מנקים את נתוני האתר.

האם אפשר לבטל את ההצטרפות ל-Protected Audience API?

כאן מוסבר איך חוסמים את הגישה ל-Protected Audience API כבעלי אתר או כמשתמשים פרטיים.

מושגים מרכזיים

מחפשים מידע נוסף על המינוח של Protected Audience? תוכלו להיעזר במילון המונחים של ארגז החול לפרטיות.

מהי קבוצת אינטרס?

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

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

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

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

סוגים של קבוצות של תחומי עניין

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

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

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

מהו קונה?

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

למשל:

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

לקונים יש שלוש עבודות:

• בוחרים אם להשתתף במכרז.
• בחר מודעות וחשב הצעת מחיר.
• מדווחים על תוצאת המכרז.

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

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

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

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

מי מנהל מכרז של מודעות?

יש כמה גורמים שעשויים לנהל מכרז כדי למכור שטח להצגת מודעות.

למשל:

• בעל תוכן דיגיטלי: פועל בשם עצמו לאירוח תוכן מודעות באתר שלו.
• פלטפורמה בצד האספקה (SSP): עבודה עם בעל התוכן הדיגיטלי ומתן שירותים אחרים.
• סקריפט של צד שלישי: פועל מטעם בעל התוכן הדיגיטלי כדי לאפשר השתתפות במכרזי מודעות.

באמצעות Protected Audience API, לאתר מכירה של שטחי פרסום יש שלוש משימות:

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

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

איך פועלת מכרז של מודעות Protected Audience API?

בתרשים הבא מפורט כל שלב במכרז מודעות של Protected Audience API:

שלבי המכרז של המודעות ב-Protected Audience API.

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

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

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

1. משתמש מבקר באתר שמוצגות בו מודעות.
2. קוד בית העסק מתחיל מכרז. בית העסק מציין איזה שטח להצגת מודעות מוצע למכירה ומי יכול להגיש הצעות מחיר, וכן את השיטה לדירוג הצעות המחיר האלה.
3. הקוד של הקונה שהוזמן פועל כדי ליצור הצעת מחיר, כתובת URL לקריאייטיב רלוונטי של המודעה ונתונים נוספים. סקריפט הבידינג יכול לבצע שאילתה כדי לקבל נתונים בזמן אמת, כמו התקציב הנותר של קמפיין הפרסום, משירות המפתח/הערך של הקונה.
4. הקוד של בית העסק נותן ניקוד לכל הצעת מחיר ובוחר זוכה. הלוגיקה הזו משתמשת בערך הצעת המחיר ובנתונים אחרים כדי להציג את הערך הרצוי של הצעת המחיר ולדחות מודעה שלא יכולה לגבור על המודעה הזוכה לפי הקשר. המוכרים יכולים להשתמש בשירות מפתחות/ערך משלו לנתונים בזמן אמת. לפני שהמכרז מתחיל, המפיץ מוצא את המודעה הטובה ביותר לפי הקשר למיקום המודעה הזמין.
5. המודעה הזוכה מוחזרת כאובייקט תצורת מסגרת מגודרת כשהדגל resolveToConfig מוגדר בהגדרת המכרז. ההגדרה משמשת לניווט במסגרת המבוזרת אל הקריאייטיב של המודעה, וכתובת ה-URL של הקריאייטיב מוסתרת גם מהמפיץ וגם מהבעל אתר. אם הדגל resolveToConfig מוגדר לערך false או לא מועבר, המודעה הזוכה מוחזרת כ-URN אטום, שניתן להשתמש בו כדי לעבד את המודעה ב-iframe. אובייקט fenced frame config זמין החל מגרסה M114.
6. המכרז מדווח למוכר ולקונים שזכו.
   הערה: reportResult() של המוכר וreportWin() של הקונה יכולים לכלול שיחה אל sendReportTo(). הדוח הזה זמין באופן זמני, עד שהדיווח המצטבר יהיה זמין דרך צבירת נתונים פרטית.

מנגנון דיווח לגבי איבוד קונים נמצא בדיון.

מהו שירות מפתח/ערך של Protected Audience API?

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

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

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

קוד השירות של מפתח/ערך Protected Audience API זמין עכשיו במאגר GitHub של ארגז חול לפרטיות. מפתחי Chrome ומפתחי Android יכולים להשתמש בשירות הזה.

תוכלו לקרוא מידע נוסף על Protected Audience API Key/Value Service בהסבר על API ובהסבר על מודל אמון.

איך משולבים נתוני זמן אמת במכרזים?

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

כדי לעמוד בדרישות הפרטיות של Protected Audience API, שירות מפתח/ערך מספק נתונים בזמן אמת שנדרשים במהלך מכרז של מודעות. כשכל קונה מתקשר אל navigator.joinAdInterestGroup(), הקונה מציין כתובת URL של שירות של מפתח/ערך ומציין את המפתחות שיש לשלוח אליהם שאילתות לשירות במהלך מכרז. בדומה לכך, כשאתר המכירה מפעיל מכרז של מודעות על ידי קריאה ל-navigator.runAdAuction(), המפיץ מספק כתובת URL עבור שירות המפתח/ערך שלו. שירות 'מפתח/ערך' של המוכר יקבל שאילתה עם כתובת ה-URL לעיבוד של הקריאייטיב.

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

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

איך נעשה שימוש בנתונים מאינטראקציה ישירה (First-Party) במכרז עם Protected Audience API?

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

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

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

const interestGroup = {
  owner: 'https://example-buyer.com',
  name: 'running-shoes',
  userBiddingSignals: {
    favoriteColor: 'blue' // First-party data
  },
  // ...other interest group settings
};

navigator.joinAdInterestGroup(interestGroup, 3600);

בעל האפליקציה יכול גם להעביר את הנתונים מאינטראקציה ישירה (First-Party) על ידי הגדרת האותות בהגדרת המכרז בתחילת המכרז, והוא יכול לקבוע מי יקבל את הנתונים מאינטראקציה ישירה. כשבעל אפליקציה מעביר את הנתונים מאינטראקציה ישירה בתור auctionSignals, הם זמינים גם לקונים וגם למוכרים. כשהנתונים מועברים בתור sellerSignals, הם זמינים רק למפיץ, וכשמעבירים אותם בתור perBuyerSignals הם זמינים רק לקונים שצוינו. בעל האפליקציה יכול גם להעביר נתונים מאינטראקציה ישירה (First-Party) במכרזים של רכיבים. בעל התוכן הדיגיטלי והמשתתפים במכרז צריכים להסכים לפני אילו נתונים מאינטראקציה ישירה צריך לשתף, ואיך צריך להגדיר את הפורמט של הנתונים.

בדוגמה הבאה מוסבר איך בעל התוכן הדיגיטלי יכול להעביר נתונים מאינטראקציה ישירה (First-Party) למשתתפים שונים במכרז:

const auctionConfig = {
  seller: 'https://example-seller.com',
  auctionSignals: {
    favoriteColor: 'blue', // Both buyer and seller will receive this signal
  },
  sellerSignals: {
    favoriteIceCreamFlavor: 'chocolate', // Only the seller will receive this signal
  },
  perBuyerSignals: {
    'https://example-buyer.com': {
      favoriteDrink: 'tea', // Only a specific buyer will receive this signal
    },
  },
  // The same pattern applies to the component auction
  componentAuctions: [{
    seller: 'https://example-component-seller.com',
    auctionSignals: { ... },
    sellerSignals: { ... },
    perBuyerSignals { ... }
  }],
  // ...other auction settings
};

navigator.runAdAuction(auctionConfig);

מידע נוסף

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

מפתחים

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

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

יצירת מעורבות ושיתוף משוב

• GitHub: קראו את המסביר, העלו שאלות ועקבו אחר הדיון.
• הודעות: אפשר להצטרף להודעות קודמות או להציג אותן ברשימת התפוצה של Protected Audience API.
• W3C: שוחח על תרחישים לדוגמה בתחום בשיפור הקבוצה העסקית לפרסום באינטרנט.
• תמיכה למפתחים: אפשר לשאול שאלות לגבי ההטמעה ושיטות מומלצות, או להצטרף לדיונים לגבי מאגר התמיכה למפתחים של ארגז חול לפרטיות.
• ההטמעה הנוכחית: אם יש לכם שאלות לגבי ההטמעה של Protected Audience ב-Chrome: אפשר לדווח על באג ב-Chromium.