שאלות נפוצות בנושא מדידה ורלוונטיות של ארגז החול לפרטיות

תשובות לשאלות נפוצות בנושא הרלוונטיות והמדידה של ממשקי ה-API של ארגז החול לפרטיות.

מה ההבדל בין הנושאים לבין קהלים בהגדרת המפיץ (SDA)?

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

• אתר המכירה מרחיב את הגדרת הקהל שלו בעזרת Topics
• הקונה משתמש ב-Topics כאות לציון סכום הצעת המחיר
• הקונה משתמש ב-Topics כדי לאמת שה-SDA מדויק

האם התכונה Protected Audience מאפשרת ל-Google לשלוט ביצירת הקהלים?

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

האם Protected Audience תומך בקבוצות תחומי עניין שנוצרו על ידי בעלי תוכן דיגיטלי?

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

איך כללי איכות המודעות אוכפים במכרזים עם Protected Audience?

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

האם Protected Audience תומך במודעות וידאו?

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

האם Protected Audience API תומך במודעות מותאמות?

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

האם עיבוד מודעות של Protected Audience מונע חדשנות?

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

האם Protected Audience API מאפשר שימוש בגישות מתוחכמות של קביעת קצב והערכת הצעות מחיר שקיימות כרגע במכרזים מסורתיים?

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

האם תקן OpenRTB יפעל ב-Protected Audience?

כן. העבודה הזו נמצאת בשלבי פיתוח ב-IAB Tech Lab באמצעות קבוצה מעורבת של פלטפורמות DSP ופלטפורמות SSP מייצגים. נראה שבהמשך הדרך להשתמש בחלקים מפרוטוקול OpenRTB כתקן תקשורת במכרזים של Protected Audience, וידוע לנו על כך שהמפתחים כבר נעזרים בהם.

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

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

מה יקרה למכרזים מסורתיים ברגע שחברות נוספות של טכנולוגיות פרסום יתמכו ב-Protected Audience API?

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

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

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

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

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

האם Protected Audience מפחית את הערך של תשתית עיצוב התנועה הקיימת?

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

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

בסופו של דבר, חלק מהתשתית מדור קודם שמבוססת על מזהים חוצי-אתרים לא תהיה שימושית יותר.

האם בקשות חדשות שנובעות ממכרז של 'קהל מוגן' יגבילו את קיבולת ה-SSP?

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

מהי העדיפות של Protected Audience כאשר יש משאבים מתחרים בדפדפן?

Protected Audience פועל בדרך כלל לפי הפרדיגמה הרגילה של אמצעי בקרה לבנייה, שמאפשרת למוכרים להחליט כמה זמן ומשאבים למגישי הצעות המחיר יוכלו לצרוך ובניית כלים שמאפשרים לקונים להחליט מהי הדרך הטובה ביותר להשתמש במשאבים שזמינים להם. אמצעי הבקרה והכלים האלה זמינים כבר עכשיו, אבל הקונים והמוכרים יוכלו לממש את התועלת המלאה שלהם אחרי ההטמעה שלהם. בנוסף, Chrome ממשיך לעבוד על מגוון שיפורים בתשתית של מהירות המכרז (לדוגמה, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/11983392/31).

מה קורה בזמן האחזור של Protected Audience API?

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

בנוסף, Chrome ממשיך לעבוד על מגוון שיפורים בתשתית של מהירות המכרז (לדוגמה crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev72/111). אנחנו מזמינים את המשוב לשני החלקים של התהליך הזה של זמן אחזור: כלים נוספים שעשויים להועיל לקונים ולמוכרים, ודיווחים על צווארי בקבוק שזוהו שכדאי למהנדסי Chrome לחקור.

האם בניית עבור Protected Audience במכשיר היא מאמץ מבוזבז כשקיימים שירותי בידינג ושירותי מכרזים (B&A)?

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

האם הדרישות מבוססות-הענן של סביבות ביצוע מהימנות (TEE) ל-Protected Audience API יגרמו לעסקים להשתמש ב-Google Cloud?

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

האם 'ארגז החול לפרטיות' יאפשר לסביבות ביצוע מהימנות (TEEs) לפעול במרכזי נתונים בענן שאינם ציבוריים?

סביבות ביצוע מהימנות (TEE) ניתנות לבדיקה הן חלק ממודל הפרטיות והאבטחה שלנו. התחלנו עם סביבות TEE שמציעות ספקי ענן ציבורי בגלל אמצעי האבטחה המחמירים. לשם הבהרה, ממשקי ה-API היחידים שמחייבים שימוש בסביבות ביצוע בטוחות בטווח הקרוב הם Attribution Reporting API ו-Private Aggregation API, ואף אחד מהם לא כולל קריאה ל-TEE בזמן אמת בהגדרת מכרז. אנחנו ממשיכים לבחון אפשרויות נוספות מעבר לפתרונות מבוססי-ענן ציבוריים.

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

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

ספקים של שירותי ענן ציבורי חייבים לעמוד ברף גבוה מאוד מבחינת אבטחה. לדוגמה, AWS היא ספק שירותי ענן מכובד שיש לו שיטות אבטחה מבוססות. באופן ספציפי, ל-AWS Nitro יש מודל אבטחה מתועד כדי להבטיח ש-Nitro Enclaves מונעים מאופרטורים לגשת לנתונים שמעובדים ב-Enclave, ושהמשאבים מוגנים (כמו מפתחות פענוח) זמינים רק לקוד מורשה שפועל ב-Enclave. יש גם גישה פיזית. AWS תכננה והטמיעה הקלות על סיכוני גישה פיזית, כולל מעובדי Amazon. יכול להיות שסביבות TEE קיימות שמבוססות על חומרה לא יגנו על כל ההתקפות הפיזיות שעננים ציבוריים נועדו לעשות. בנוסף, לאחרונה, Amazon פנתה אל קבוצת NCC, חברת מחקר עצמאית, כדי לבדוק את עיצובי ה-NCC שלה, שמתמקדים בטענות אבטחה שקשורות לגישה של עובדי פנים. הדוח הציבורי מצביע על כך שעיצובי AWS עומדים בטענות שלהם.

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

האם מערכת ארגז החול לפרטיות משנה את החיוב?

לא. חברות פרסום דיגיטלי וקריאות אחרות ל-API יכולים להמשיך לראות אם משהו מעובד בדף ובאיזה מחיר.

האם אפשר להגדיר מכסת תדירות בארגז החול לפרטיות?

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

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

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

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

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

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

מה לגבי תרחישים לדוגמה שלא נכללים בארגז החול לפרטיות?

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