קרא איך המערכת מסיקה נושאים, איך הם מוקצים למשתמשים ואיך משתמשים יכולים לשלוט ברשימת הנושאים שלהם.
סטטוס הטמעה
- Topics API השלים את שלב הדיון הציבורי והוא זמין כרגע ל-99% מהמשתמשים, עד 100 אחוזים.
- כדי לשלוח משוב על Topics API, אפשר ליצור בעיה בהסבר של Topics או להשתתף בדיונים ב-שיפור הקבוצה העסקית של הפרסום באינטרנט. הסבר מכיל מספר שאלות פתוחות שעדיין מחייבות הגדרה נוספת.
- לוח הזמנים של ארגז החול לפרטיות מספק לוחות זמנים להטמעה של Topics API והצעות אחרות של ארגז החול לפרטיות.
- ב-Topics API: העדכונים האחרונים מפורטים השינויים והשיפורים ב-Topics API ובהטמעות.
מה זה נושא?
נושא ב-Topics API הוא נושא שהמשתמש מתעניין בו, לפי האתרים שבהם הוא מבקר.
בעזרת נושאים אפשר לעזור לפלטפורמות של טכנולוגיות פרסום לבחור מודעות רלוונטיות. בשונה מקובצי Cookie של צד שלישי, המידע הזה משותף בלי לחשוף מידע נוסף על המשתמש עצמו או על פעילות הגלישה של המשתמש.
Topics API מאפשר לצדדים שלישיים, כמו פלטפורמות פרסום דיגיטלי, לצפות בנושאים שמעניינים את המשתמשים ולגשת אליהם. לדוגמה, ה-API עשוי להציע את הנושא 'סיבים אומנויות טקסטיל למשתמש שמבקר באתר knitting.example
.
רשימת הנושאים שבה משתמשים ב-Topics API היא ציבורית, בהרכבה אנושית, קריאים לאנשים והמטרה שלה היא להימנע מקטגוריות רגישות. זו הרשימה הנוכחית, שתתרחב עם הזמן. הרשימה בנויה לפי טקסונומיה. הנושאים יכולים להיות כלליים או ספציפיים יותר. לדוגמה, Food & Drink
היא קטגוריה רחבה עם קטגוריית המשנה Cooking & Recipes
. יכול להיות שקטגוריות המשנה יתחלקו לקטגוריות משנה נוספות.
טקסונומיית נושאים כזו צריכה לבוא לידי ביטוי בין התועלת לבין הפרטיות. אם הנושאים ספציפיים מדי, אפשר להשתמש בהם כדי לזהות משתמש מסוים. אם הן כלליות מדי, הן לא מתאימות לבחירת פרסום או תוכן אחר.
הטקסונומיה של הנושאים מבוססת על שתי דרישות בסיסיות:
- תמיכה בפרסום המבוסס על תחומי עניין
- הגנה על המשתמשים והגנה על הפרטיות שלהם
עשויות להיות לכך כמה שאלות. לדוגמה:
- מהי הדרך הטובה ביותר לגרום ל-API להסיק מהם תחומי העניין של המשתמש על סמך פעילות הגלישה שלו, תוך שמירה על פרטיות המשתמש?
- איך ניתן ליצור את הטקסונומיה כדי שהיא תהיה מועילה יותר?
- אילו פריטים ספציפיים צריכה לכלול הטקסונומיה?
איך ה-API מסיק מהם הנושאים של אתר
הנושאים נגזרים ממודל סיווג שממפה את שמות המארחים של אתרים לאפס או יותר נושאים. ניתוח מידע נוסף (כגון כתובות URL מלאות או תוכן של דפים) עשוי לאפשר הצגה של מודעות רלוונטיות יותר, אבל גם עשוי לפגוע בפרטיות.
מודל הסיווג למיפוי שמות מארחים לנושאים זמין באופן ציבורי, וכפי הערות ההסבר, ניתן להציג את הנושאים של אתר באמצעות הכלים למפתחים בדפדפן. המודל צפוי להתפתח ולהשתפר עם הזמן, והוא יעודכן מדי פעם. התדירות של זה עדיין משוקללת.
רק אתרים שכוללים קוד שקורא ל-Topics API נכללים בהיסטוריית הגלישה שעומדת בדרישות לחישובים של תדירות נושאים, והקוראים ל-API מקבלים רק נושאים שהם צפו בהם. במילים אחרות, אתרים אינם כשירים לחישובים של תדירות נושאים ללא האתר או שירות מוטמע שקוראים ל-API.
בנוסף, המתקשר יכול לקבל רק נושאים שהקוד שלו 'ראה'. לכן, אם קוד של מתקשר אחר ביצע רישום של נושא, למשל /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks
, בדפדפן של המשתמש, והקוד שלכם לא גרם לרישום של הנושא הזה בדפדפן של אותו משתמש, לא תוכלו ללמוד על אותו נושא שמעניין את הדפדפן של אותו משתמש כשתבצעו קריאה ל-API מהקוד המוטמע שלכם. הערה: ה-API כולל עכשיו ישויות אב שנמדדו בעקבות צפייה, בדוגמה שלמעלה /Autos & Vehicles/Motor Vehicles (By Type)/Hatchbacks
, יגרום גם למעקב אחר Autos & Vehicles
ו-Motor Vehicles
.
נושאים שהוחזרו עבור משתמש מחושבים מחדש עבור המתקשר בהתאם לאתר ברמה העליונה. לדוגמה, אם המשתמש adtech.example
מבקש נושאי משתמש באתר news-a.example
, לאחר מכן ב-news-b.example
ולאחר מכן ב-news-c.example
, נושאים שהוחזרו אליהם יחושבו מחדש בכל אתר. כלומר, סביר להניח שהמתקשר יקבל נושאים שונים אצל המשתמש באתרים שונים ברמה העליונה, מכיוון ששלושת הנושאים (המקסימליים) שהוחזרו למשתמש נבחרים באופן אקראי מתוך חמשת הנושאים המובילים בשלושת התקופות האחרונות בתקופה האחרונה (עם סיכוי של 5% לקבל נושא אקראי). לכן למתקשר קשה יותר לזהות את המשתמש לפי הנושאים, כי סביר להניח שהנושאים האלה יהיו שונים באתרים שונים ברמה העליונה (גם במקרה של אותו משתמש, אותה קריאה ותקופת זמן לקביעת נושאים).
מודל הסיווג
הנושאים נאספים באופן ידני עבור 50,000 דומיינים מובילים, והאיסוף הזה משמש לאימון של המסווג. הרשימה הזו מופיעה ב-override_list.pb.gz
, שזמינה ב-chrome://topics-internals/
מתחת למודל הנוכחי בכרטיסייה מסווג. שיוכים בין דומיינים לרשימה משמשים את ה-API במקום הפלט של המודל עצמו.
כדי להפעיל את המודל ישירות, אפשר לעיין במדריך של TensorFlow להפעלת מודל.
כדי לבדוק את הקובץ override_list.pb.gz
, קודם צריך לפתוח אותו:
gunzip -c override_list.pb.gz > override_list.pb
משתמשים ב-protoc
כדי לבדוק אותו כטקסט:
protoc --decode_raw < override_list.pb > output.txt
טקסונומיה מלאה של נושאים עם מזהים זמינה ב-GitHub.
שליחת משוב או קלט לגבי מודל הסיווג
יש כמה ערוצים לשליחת משוב על Topics API. כדי לקבל משוב על מודל הסיווג, מומלץ לשלוח בעיה ב-GitHub או להשיב לבעיה קיימת. לדוגמה:
איך נבחרים חמשת הנושאים המובילים של המשתמש
ה-API מחזיר נושא אחד בכל תקופה של זמן מערכת, עד שלושה נושאים לכל היותר. אם מוחזרות שלוש, הוא כולל נושאים לתקופה הנוכחית ולשתיים הקודמות.
- בסוף כל תקופה של זמן מערכת, הדפדפן יוצר רשימה של דפים שעומדים בקריטריונים הבאים:
- המשתמש ביקר בדף בתקופה של תקופת הזמן.
- הדף כולל קוד שקורא ל-
document.browsingTopics()
. - ה-API הופעל (לדוגמה, לא נחסם על ידי המשתמש או דרך כותרת תגובה).
- במכשיר של המשתמש, הדפדפן משתמש במודל המסווג שסופק על ידי Topics API כדי למפות את שם המארח של כל דף לרשימה של נושאים.
- הדפדפן צובר את רשימת הנושאים.
- הדפדפן יוצר רשימה של חמשת הנושאים המובילים לפי תדירות.
לאחר מכן, השיטה document.browsingTopics()
מחזירה נושא אקראי מתוך חמשת המובילים בכל תקופה של זמן מערכת, ויש סיכוי של 5% שכל אחד מהם ייבחר באופן אקראי מתוך הטקסונומיה המלאה של הנושאים. ב-Chrome, משתמשים יכולים גם להסיר נושאים ספציפיים, או לנקות את היסטוריית הגלישה שלהם כדי לצמצם את מספר הנושאים שהוחזרו על ידי ה-API. המשתמשים יכולים גם לבטל את ההסכמה לשימוש ב-API.
בדף chrome://topics-internals
אפשר להציג מידע על נושאים שנצפו במהלך התקופה הנוכחית.
איך ה-API מחליט אילו מתקשרים יראו את הנושאים
מתקשרים ל-API מקבלים רק נושאים שהם צפו בהם לאחרונה, והנושאים של המשתמש עוברים רענון בכל תקופה של זמן מערכת. כלומר, ה-API מספק חלון מתגלגל שבו מבצע הקריאה החוזרת עשוי לקבל נושאים מסוימים.
הטבלה הבאה מתארת דוגמה (אם כי קטנה באופן ריאליסטי) להיסטוריית גלישה היפותטית של משתמש בתקופת זמן יחידה. בטבלה מופיעים נושאים המשויכים לאתרים שבהם הוא ביקר, והקריאות ל-API שנמצאות בכל אתר (הישויות קוראים ל-document.browsingTopics()
בקוד JavaScript הכלולות באתר).
אתר | נושאים | קריאות ל-API באתר |
---|---|---|
yoga.example | כושר גופני | adtech1.example adtech2.example |
knitting.example | אומנות | adtech1.example |
hits-holiday.example | כושר, נסיעות ו תחבורה | adtech2.example |
diy-clothing.example | יצירה, אופנה סגנון | [ללא] |
בסוף התקופה (כרגע יש שבוע), Topics API יוצר את הנושאים המובילים של הדפדפן לשבוע הזה.
- adtech1.example זכאית עכשיו לקבל את התג 'כושר' ו'מלאכת יד' כי הוא ראה אותם ב-יוגה.example וגם ב-knitting.example.
- המודעה adtech1.example אינה כשירה לקבל את טופס העזרה 'נסיעות תחבורה" נושא למשתמש הזה מכיוון שהוא לא קיים באתרים שהמשתמש ביקר בהם לאחרונה שמשויכים לנושא הזה.
- adtech2.example צפתה במדד "כושר" ו'נסיעות תחבורה" אך לא ראה "יצירות" נושא.
המשתמש ביקר באתר diy-clothing.example, שמכיל את האתר 'אופנה סגנון" אבל לא בוצעו קריאות ל-Topics API באתר הזה. בשלב זה המשמעות היא "אופנה סגנון" הנושא לא יוחזר על ידי ה-API עבור אף מבצע קריאה.
בשבוע השני, המשתמש מבקר באתר אחר:
אתר | נושאים | קריאות ל-API באתר |
---|---|---|
sewing.example | אומנות | adtech2.example |
בנוסף, קוד מ-adtech2.example מתווסף ל-diy-clothing.example:
אתר | נושאים | קריאות ל-API באתר |
---|---|---|
diy-clothing.example | יצירה, אופנה סגנון | adtech2.example |
וגם למדד 'כושר' ו'נסיעות תחבורה" מהשבוע הראשון, המשמעות היא שעכשיו adtech2.example יוכל לקבל את ה-Crafts ו"אופנה סגנון" אבל לא עד לתקופה הבאה, שבוע 3. כך ניתן להבטיח שצדדים שלישיים לא יוכלו לקבל מידע נוסף על העבר של המשתמש (במקרה הזה, העניין באופנה) ממה שהם יכולים לקבל בעזרת קובצי cookie.
אחרי שבועיים נוספים, "כושר" ו'נסיעות תחבורה" עשויים לצאת מרשימת הנושאים הכשירים של adtech2.example, אם המשתמש לא מבקר באתרים עם הנושאים האלה שכוללים קוד מ-adtech2.example.
אמצעי בקרה, שקיפות וביטול הסכמה למשתמשים
למשתמשים צריכה להיות אפשרות להבין את המטרה של Topics API, לזהות מה אומרים עליהם, לדעת מתי ה-API נמצא בשימוש ולספק להם אמצעי בקרה להפעלה או להשבתה של ה-API.
הטקסונומיה של ה-API מאפשרת למשתמשים ללמוד ולנהל את הנושאים שמוצעים להם בדפדפן. המשתמשים יכולים להסיר נושאים שהם לא רוצים ש-Topics API ישתף עם מפרסמים או בעלי תוכן דיגיטלי, וניתן להשתמש באמצעי בקרה כדי לעדכן את המשתמשים לגבי ה-API ואיך להפעיל או להשבית אותו. דפדפן Chrome מספק מידע והגדרות ל-Topics API בכתובת chrome://settings/adPrivacy
. בנוסף, הנושאים לא זמינים למתקשרים ל-API במצב פרטי, והנושאים נמחקים כשהיסטוריית הגלישה נמחקת.
רשימת הנושאים שיוחזרו תהיה ריקה אם:
- המשתמש ביטל את ההסכמה לשימוש ב-Topics API דרך הגדרות הדפדפן בכתובת
chrome://settings/adPrivacy
. - המשתמש נקה את הנושאים שלו (דרך הגדרות הדפדפן בכתובת
chrome://settings/adPrivacy
) או מחק את קובצי ה-Cookie שלו. - הדפדפן במצב פרטי.
ההסבר מספק פרטים נוספים על יעדי פרטיות ועל האופן שבו ה-API רוצה לטפל בהם.
ביטול ההסכמה לשימוש באתר
בנוסף ליכולת של המשתמשים לבטל את הסכמתם, אתם יכולים לבטל את ההסכמה לשימוש ב-Topics באתר או בדפים שבו. במדריך למפתחים מוסבר איך לעשות זאת.
שימוש ב-Topics API באתרים עם prebid.js
כפי שצוין בגרסה של Prebid 7: חברי הקהילה פיתחו באופן פעיל שילוב עם Topics API באמצעות מודול חדש. המודול הזה מוזג בדצמבר 2022.
מידע נוסף זמין כאן:
- קוראים את מסמכי התיעוד של מודול Topics API של Prebid.
- לקבלת מידע נוסף, אפשר לפנות אל Prebid.js דרך הערוץ הרגיל שהם מציעים.
השלבים הבאים
- אם אתם מפתחי טכנולוגיות פרסום, אתם יכולים להתנסות ב-Topics API ולהשתתף בו.
- למקורות מידע מעמיקים יותר, אפשר לעיין במדריך למפתחים.
- במדריך השילוב של Topics API אפשר למצוא פרטים על תרחישים ספציפיים לדוגמה של פרסום דיגיטלי.
עניין ושיתוף משוב
- GitHub: קוראים את ההסבר של Topics API, ומעלים שאלות ועוקבים אחרי דיונים בבעיות במאגר ה-API.
- W3C: דיון על מקרי שימוש בתחום בשיפור הקבוצה העסקית של הפרסום באינטרנט.
- הודעות: הצטרפות לרשימת התפוצה או הצגה של רשימת התפוצה
- תמיכה למפתחים של ארגז חול לפרטיות: אפשר לשאול שאלות ולהצטרף לדיונים על מאגר התמיכה למפתחים של ארגז החול לפרטיות.
- Chromium: דיווח על באג ב-Chromium כדי לשאול שאלות לגבי ההטמעה שזמינה כרגע לבדיקה ב-Chrome.