דוח משוב – רבעון 1 לשנת 2024

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

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

כחלק מההתחייבויות שלה ל-CMA, Google הסכימה לפרסם דוחות רבעוניים על תהליך המעורבות של בעלי העניין בהצעות שלה לארגז החול לפרטיות (ראו פיסקאות 12 ו-17(ג)(2) בהתחייבויות). דוחות הסיכום האלה של המשוב על ארגז החול לפרטיות נוצרים על ידי צבירת המשוב ש-Chrome מקבל מהמקורות השונים שמפורטים בסקירה הכללית של המשוב, כולל, בין היתר: בעיות ב-GitHub, טופס המשוב שזמין בכתובת privacysandbox.com, פגישות עם בעלי עניין בתעשייה ופורומים של תקני אינטרנט. אנחנו ב-Chrome מקבלים בברכה את המשוב שאנחנו מקבלים מהסביבה העסקית, ומחפשים דרכים לשלב את הלקחים האלה בהחלטות העיצוב שלנו.

נושאי המשוב מדורגים לפי שכיחות לכל ממשק API. כדי לעשות זאת, אנחנו אוספים את כמות המשוב שקיבל צוות Chrome בנושא מסוים וממיינים אותו בסדר יורד לפי כמות. כדי לזהות את הנושאים הנפוצים של המשוב, בדקנו את נושאי הדיון בפגישות ציבוריות (W3C, ‏ PatCG,‏ IETF), משוב ישיר, GitHub ושאלות נפוצות שהופיעו בצוותים הפנימיים של Google ובטפסים ציבוריים.

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

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

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

מילון ראשי תיבות

ARA

Attribution Reporting API

CHIPS

קובצי Cookie עם חלוקה עצמאית למחיצות

DSP

פלטפורמה בצד הביקוש

FedCM

Federated Credential Management

FPS

קבוצות מאינטראקציה ישירה (First-Party Sets)

IAB

הרשות לפרסום אינטראקטיבי (Interactive Advertising Bureau)

IDP

ספק זהויות

IETF

ארגון תקינה בנושאי האינטרנט (IETF)

קניין רוחני (IP)

כתובת פרוטוקול אינטרנט

openRTB

בידינג בזמן אמת

הארכה

גרסת מקור לניסיון

PAT API

Protected Audience API (לשעבר FLEDGE)

PatCG

קבוצת הקהילה של טכנולוגיית פרסום פרטית

RP

צד נסמך

RWS

קבוצות של אתרים קשורים (לשעבר 'קבוצות של צד ראשון')

SSP

פלטפורמה לספקים

TEE

סביבת מחשוב אמינה

UA

מחרוזת של סוכן משתמש

UA-CH

רמזים על הלקוח (Client Hints) לגבי סוכן משתמש

W3C

World Wide Web Consortium

WIPB

עיוורון מכוון של כתובות IP

משוב כללי, ללא API או טכנולוגיה ספציפיים

נושא המשוב	סיכום	תגובה מ-Chrome
ניהול	עניין בתקופה של פרסום תגובות ציבוריות לגבי עדכוני ממשל בארגז החול לפרטיות.	אנחנו פתוחים למשוב סביר מהגורמים השותפים לגבי כל התפתחות משמעותית לגבי ארגז החול לפרטיות, כולל הניהול העתידי של ארגז החול לפרטיות.
בדיקה	שלבי בדיקה נוספים ל-3PCD, בנוסף ל-1% הנוכחי של בדיקות שמבוצעות באמצעות Chrome.	אנחנו לא מתכוונים להציע בדיקה באמצעות Chrome מעבר ל1% הנוכחי של תנועת הגולשים ב-Chrome שהופעלה מתחילת ינואר.
Web to App	לא כדאי להפעיל 3PCD במכשירים ניידים לפני שאפשרות הפעולה ההדדית המלאה בין האינטרנט לאפליקציה תושג.	אנחנו מסכימים שחשוב לתמוך בתאימות הדדית בין אפליקציות לאתרים, ולכן השקנו מדידת שיוך (Attribution) בין אפליקציות לאתרים, ואנחנו בודקים פתרונות לטירגוט מהאתר לאפליקציה. עם זאת, אנחנו לא מתכננים לדחות את ההשקה של 3PCD באתרים לנייד. אין לנו יעד של כיסוי של 100% בסוף תקופת ה-3PCD. במקום זאת, אנחנו מצפים שהתאימות ב-Android למדידת ביצועים באפליקציות ובאתרים תהיה גבוהה למדי ב-3PCD, ותגבר עם הזמן ככל שהמשתמשים יעדכנו את הטלפונים שלהם.
התפקיד של הדפדפן	נראה ש-Chrome ממלא את התפקיד של שרת מודעות או SSP.	Chrome לא ממלא את התפקיד של שרת מודעות או של פלטפורמת SSP. באמצעות PA API, Chrome מספק מאגר לשרתי מודעות, ל-SSP, ל-DSP ולטכנולוגיות פרסום אחרות, כדי שיוכלו להשתמש בלוגיקה שלהם לבידינג ולניקוד.
הנחיות לתרחישים לדוגמה	הנחיות ברורות יותר לגבי תרחישים לדוגמה שתהיה להם תמיכה בממשקי ה-API של ארגז החול לפרטיות.	בתחילת הפרויקט של ארגז החול לפרטיות, מסמכי העזרה למפתחים התמקדו בעיקר ביצירת קשר עם מפתחים והצגת תהליכי המשוב לגבי כל ההצעות. המשמעות היא שהתוכן היה בדרך כלל מובנה סביב הבנת המוטיבציה והמושגים שמאחורי הפרויקט, ולאחר מכן פרטים על הפיתוח המוקדם ופרטי הבדיקה של כל הצעה. השיטה הזו הייתה יעילה ליצירת שיתוף פעולה אמיתי בסביבה העסקית בפיתוח ההצעות, אבל ככל שממשקי ה-API התקדמו לזמינות כללית, יש קהל חדש של מפתחים שמגיעים בעיקר כדי לבנות על ממשקי ה-API ולא כדי לתרום לפיתוח הבסיסי שלהם. עדכנו לאחרונה את הניווט באתר למפתחים של ארגז החול לפרטיות כך שיתמקד בתרחישי שימוש, באמצעות סיווגים דומים לאלה של IAB Tech Lab בדוח האחרון של צוות המשימה של ארגז החול לפרטיות. נמשיך להשתמש בגישה הזו בעתיד.
סביבת פיתוח מקומית	איך ממשיכים לפתח ולבדוק את חזית האתר באופן מקומי בכתובת http://localhost כשהקובץ cookie הוא SameSite=Secure ו-CDN נמצא בחזית הקצה העורפי?	אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
מיטיגציה של 3PCD	האם יש דרך פרוגרמטית לדעת אם מודעות 3PC חסמו או מתי שיטות הניתוח ההסתברותי פעילות?	ב-Chrome, גם זיהוי התכונות וגם הקריאה ל- document.hasStorageAccess ב-iframe מאפשרים למפתח לדעת אם למקור ב-iframe יש גישה ל-3PC.
בדיקת סרטונים	בשלב זה אי אפשר לבדוק מודעות וידאו בארגז החול לפרטיות.	היום פורסמה ב-Chrome סקירה והדגמה של כמה דרכים אפשריות להצגת סרטונים באמצעות PA API (ראו 242 ו- 254 במאגר ההדגמות שלנו ב-GitHub). חשוב לזכור שהקודים האלה לא מיועדים לשמש כדוגמאות שספקי טכנולוגיות הפרסום יאמץ באופן מלא, אלא כרעיון להמחשה והדגמה של השיטות שיכולות לתמוך ברינדור של סרטוני VAST באמצעות PA API. במהלך הדיון הזה, התברר גם שאפשר כבר לבצע רינדור של סרטונים, אבל יש שינויים שאפשר לבצע ב-Chrome כדי לפשט את ההטמעה באמצעות PA API. לדוגמה, עדכונים בנושא החלפת מאקרו (שנדונו כאן) שכבר תכננו לטפל בהם על סמך משוב לגבי תרחישים לדוגמה של שירותי אימות מודעות של צד שלישי להגנה על מותגים, יטפלו גם במשוב לגבי תרחיש לדוגמה של מודעות וידאו, שבו הקונה מחפש את המאקרו של המוכר שרוצים להשתמש בו ברינדור. רוב הדיונים עד כה התמקדו במיוחד ברינדור של מודעות וידאו מסוג VAST. אפשר להשתמש באותן גישות לעיבוד של מודעות מותאמות, והעיבוד שלהן קל יותר בהרבה מובנים. נראה שמודעות נתמכות לא מקבלות כרגע תשומת לב רבה כמו מודעות וידאו, אבל זו רק שאלה של תעדוף בתעשיית טכנולוגיית הפרסום, ולא מחסום טכני כלשהו להטמעה.
מדידה ללא מודעות	3PCD עשוי להשפיע על פתרונות למדידת קהלים שאינם קשורים למודעות.	בממשקי ה-API למדידת ביצועים אין דרישה שתרחיש השימוש יהיה קשור למודעות. ARA ספציפי יותר לתהליך פרסום אופייני,אבל צבירה פרטית היא לשימוש כללי. אפשר להשתמש בשני אבני הבניין האלה כדי לטפל במגוון רחב של פעילויות מדידה.
יוצרי תוכן	ארגז החול לפרטיות נועד לעודד יוצרים ליצור יותר תוכן ל-YouTube ופחות תוכן באתרים שלהם.	יוזמת 'ארגז החול לפרטיות' מתמקדת בשמירה על הפרטיות של הפעילות של אנשים באינטרנט פתוח וחופשי. אנחנו יודעים שבעלי תוכן דיגיטלי מסתמכים על מודעות כדי ליצור תוכן ולהפוך אותו לזמין לכמה שיותר אנשים. מפרסמים עוזרים לאנשים לגלות מוצרים או מבצעים חדשים שעשויים לעניין אותם. התכונות של ארגז החול לפרטיות מאפשרות לאתרים מכל הסוגים, כולל אתרים שעובדים עם יוצרים של תוכן, להציג לאנשים מודעות מועילות על סמך הפעילות שלהם עם גורמים שונים, בלי לחשוף את זהות המשתמש לגורמים האלה.
לוחות זמנים ברורים יותר	לוחות זמנים ברורים ומפורטים יותר להשקות של הטכנולוגיות של ארגז החול לפרטיות.	המסמכים של ממשקי ה-API של ארגז החול לפרטיות כוללים דפים של סטטוס וזמינות של ממשקי API. בדפים האלה מפורטות תכונות עתידיות ותזמוני ההשקה שלהן (למשל, PA API,‏ ARA). כאן אפשר לראות תצוגה מרכזית של הסטטוסים האלה.
למידת מכונה	טכנולוגיות הפרסום לא יכולות לאמן מודלים של למידת מכונה בצורה נכונה עד ש-3PCD חורג מ-1%.	הרחבת 3PCD לדפדפנים נוספים לצורך בדיקה לא מבטיחה שהשימוש ב-API יגדל, וזה כנראה מה שספקי טכנולוגיות הפרסום מחפשים כדי לאמן מודלים נוספים של למידת מכונה. אם אנשי טכנולוגיית הפרסום לא מחפשים שימוש נרחב יותר בסביבה העסקית כדי לאמן מודלים של למידת מכונה, אין סיבה להרחיב את 3PCD. אנשי טכנולוגיית הפרסום שרוצים לאמן מודלים על סמך תנועה רחבה יותר יכולים לעשות זאת כבר היום בלי להגדיל את 3PCD. אפשר לעשות זאת בלי ש-Chrome ייראה כשהוא מתקדם ב-3PCD לפני סיום המצב 'המתנה'.
תרחיש לדוגמה שאינו נתמך	בשלב הזה אנחנו לא מביאים בחשבון תרחישים לדוגמה של פלטפורמת DSP בשירות עצמי.	יש כמה פלטפורמות ניהול רשתות (DSP) בשירות עצמי שמספקות באופן קבוע משוב ציבורי על ממשקי ה-API. כמה מ-DSP האלה שנותנים משוב ציבורי קבוע ציינו את עצמם כבודקים. בנוסף, אנחנו ב-Chrome עוסקים באופן פעיל בנושאים אופייניים של פלטפורמות ניהול מודעות בשירות עצמי, כמו סרטונים ושרתי מודעות של צד שלישי. בקריאות השבועיות האחרונות ל-PA API נדונו הנושאים האלה.
Origin Trial	בקשה ל-OT לאתרים שרוצים להאיץ את ההצטרפות ל-3PCD ולהרחיב את הכיסוי בבדיקות.	אנחנו מפתחים כרגע ב-Chrome פתרון OT מאינטראקציה ישירה (First-Party), שיאפשר למקורות להביע הסכמה להתנהגות של הוצאה משימוש הדרגתית של צד שלישי שלישי. מקורות ברמה העליונה שנרשמים לתוכנית הניסוי הזו ופורסים אסימונים ייחסמו על ידי 3PCs, כאילו שהגנה מפני מעקב מופעלת במכשיר של המשתמש. תקופת הניסיון הזו תספק הזדמנות חשובה לאתרים לבצע בדיקות רחבות יותר של חלופות לטווח ארוך ל-3PC, לקראת ההוצאה משימוש של 3PC שתתבצע לאחר התייעצות עם CMA. אנחנו עדיין עובדים על סיום לוח הזמנים להשקה של תקופת הניסיון.
דוח של IAB Tech Lab	משוב על ארגז החול לפרטיות שקיבלנו מהדוח של IAB Tech Lab.	כאן יש תשובה מפורטת שלנו לדוח של IAB Tech Lab. ציינו גם ש "הדוח מעלה שאלות לגבי תיעוד מקוטע, דרישות מסחריות, ביקורות של צד שלישי, הסמכה בתחום, יכולת התאמה לעומס, שקיפות ופיקוח עתידי. אנחנו נעבוד עם הסביבה העסקית ונעדכן את השאלות הנפוצות הציבוריות שלנו בהתאם". התייחסנו לתיעוד מקוטע בעבר. אנחנו מתייחסים לדרישות המסחריות בקטע 'התחייבויות לגבי נתונים' כאן, וחלק מהמוצרים של Google Ads שיתפו את הגישות שלהם. אנחנו מתייחסים לבדיקות של צד שלישי בקטע 'התחייבות לתקינות האלגוריתמים' כאן. בנוגע לאישור, אנחנו מצפים שהגופים האלה ימשיכו לאשר מוצרים, כולל השימוש שלהם בטכנולוגיות, במקום לאשר את הטכנולוגיות בעצמן. בנוגע ליכולת התאמה לעומס, אנחנו ממשיכים לקבל נתונים ממפתחים שמציגים בעיות. בנוגע לשקיפות ולממשל, אנחנו ממשיכים לפתח את הנושאים האלה באופן פתוח ב-GitHub ובפורומים כמו W3C, תוך כדי עבודה עם CMA במסגרת ההתחייבויות.
כניסה באמצעות חשבון Google	כניסות באמצעות חשבון Google עלולות לאפשר ל-Google להשתמש בנתוני כניסה לזיהוי חוצה בניגוד להתחייבויות.	הכניסה באמצעות חשבון Google לא מאפשרת ל-Google להשתמש בנתונים בניגוד להתחייבויות.
תאימות	מהם התוכניות לתמיכה בממשקי ה-API של ארגז החול לפרטיות ולתאימות לאחור ולפנים?	אחרי שאנחנו משיקים תכונה ב-Chrome לכלל המשתמשים, אנחנו שואפים להמשיך לתמוך בה. כמובן, לא תמיד אפשר לשמור על תאימות לאחור, ובמקרים כאלה יש לנו תהליך ברור להוצאה משימוש ולהסרה של תכונות קיימות, שמתואר כאן. אנחנו צופים שנמשיך להוסיף תכונות לממשקי ה-API של ארגז החול לפרטיות עם הזמן, בתגובה למשוב מהסביבה העסקית לגבי תרחישים לדוגמה שבהם תמיכה משופרת תהיה מועילה. במקרים כאלה, אנחנו נוטים לכלול סוג כלשהו של טכניקה לזיהוי תכונות, כדי שספקי טכנולוגיות פרסום שרוצים להתנסות בתכונה חדשה יוכלו לשאול את הדפדפן ישירות אם התכונה נתמכת. זוהי שיטה טובה יותר מאשר לבקש מהמפתחים לבדוק אם מספר גרסת Chrome מסוים זמין, כי יכול להיות שחלק מהתכונות לא יושקעו לכל המשתמשים ב-Chrome בו-זמנית. לדוגמה, כאן אפשר למצוא את העבודה שלנו בתחום זיהוי התכונות ב-PA API.
הטמעה בשרת	במקום לשייך את ההטמעה שלהם, ב-Chrome צריך לציין את ההתנהגויות שצריכות להתקיים בהטמעה מספקת של שרת אותות מהימנים, שרת צבירת נתונים וכל רכיב אחר שאינו דפדפן שנדרש. כך נוכל לעודד חדשנות תוך שמירה על גבולות פרטיות מקובלים.	אנחנו מעריכים את הרצון של גורמים חיצוניים לחדשנות ומקבלים אותו בברכה. בכל ממשקי ה-API והשירותים, אנחנו שואפים לספק לטכנאי הפרסום גמישות כדי שיוכלו ליישם את הפונקציונליות שלהם. לדוגמה, אנחנו מאפשרים לטכנולוגיות פרסום להשתמש במידע עסקי סודי בתכנון הלוגיקה של הבידינג במכרזים. בנוסף, אנחנו מקבלים משוב באופן שוטף מטכנולוגיות פרסום, ובמקרים הרלוונטיים אנחנו משלבים אותו בתכנונים שלנו. כדי לאפשר לגורמים אחרים להריץ קוד משלהם בסביבות של ביצוע מהימן, ארגז החול לפרטיות יצטרך לבדוק את הקוד (ואת כל השינויים) כדי לוודא שהוא עומד בהתחייבויות שלנו לשמירה על הפרטיות. כדי לעשות זאת, צוות ארגז החול לפרטיות יצטרך להשקיע מאמצים רבים. לכן, אנחנו רוצים להבין אילו יתרונות בעלי העניין רוצים להשיג, ושאנחנו לא מספקים כרגע.
שיטות ניתוח	מהם התוכניות לטווח ארוך לגבי שיטות ניתוח נתונים שמבוססות על ניסיון?	בהתאם למה שציינו דפדפנים אחרים, אנחנו מתכוונים להוציא משימוש את שיטות הניתוח האלה בסופו של דבר, כאשר פתרונות חלופיים ייכנסו לשימוש נרחב, בכפוף לניתוח היתכנות נוסף. שיתוף המידע הזה זמין כאן.
נפח הבדיקה	נפח תנועה שונה בהשוואה בין מאפיינים שונים.	לניסוי של 1% יש קריטריונים להחרגה שמובילים להבדלים בזכאות להשתתף בניסוי בין אוכלוסיות שונות של לקוחות Chrome. לדוגמה, הניסוי לא כולל משתמשים ב-Chrome Enterprise, ולכן צפוי שהחלק של התנועה עם תוויות הניסוי יהיה גבוה יותר בסופי שבוע. צפויים להיות אחוזים שונים של תנועה בפלחים שונים של נתונים (כמו מיקום גיאוגרפי, תאריך ופלטפורמה), והנתונים האלה תואמים לנתונים שאנחנו רואים ב-Chrome.
הפעלה מחדש ידנית של 3PCs	האם אתרים יוכלו לדעת כמה משתמשים (%) הפעלו מחדש קובצי cookie באופן ידני אחרי שההגבלה על קובצי cookie של צד שלישי תתחיל להיות נאכפת?	אם המשתמשים יתקלו בבעיה, הם יוכלו להפעיל מחדש את הגישה ל-3PC ברמת האתר באמצעות User Bypass. אפשר גם להפעיל מחדש את ה-3PC באמצעות אמצעים אחרים, כמו Storage Access API. יש אמצעים טכניים, כמו hasStorageAccess(), שמאפשרים לאתרים לזהות אם 3PCs מופעלים או מושבתים. עם זאת, Chrome לא יאפשר לאתרים לדעת מהן הסיבות להפעלה מחדש.
חסימת מעקב	למשך כמה זמן תהיה זמינה תכונת ממשק המשתמש של חסימת המעקב ב-Chrome?	ממשק המשתמש של הגנה מפני מעקב בסרגל הכתובות צפוי להישאר גם אחרי ההוצאה משימוש של 3PC.
(דווח גם ברבעונים קודמים) תמיכה בדפדפנים שונים	ספקים אחרים של דפדפנים שמאמצים את ממשקי ה-API של ארגז החול לפרטיות.	ספקי דפדפנים אחרים, כמו Apple,‏ Mozilla ו-Microsoft, משתתפים באופן פעיל בפורומים הציבוריים שבהם מתנהלים דיונים על עקרונות פרטיות ועל גישות מבוססות-דפדפן. אנחנו מעודדים מהדיונים המשותפים בפורומים כמו הפגישה השנתית האחרונה של W3C TPAC והפורומים המתמשכים של W3C PATCG, שבהם אנחנו רואים סימנים להתכנסות. לדוגמה, לאחרונה Microsoft Edge הודיעה על התוכנית שלה "שמטרתה למקסם את התאימות התחבירית" ל-PA API ול-ARA, תוך מתן תכונות נוספות למפתחים.
אפשרות חלופית להטמעות לא תואמות אחרי 3PCD	לספק ווקרי API כדי לזהות אם iframe או הטמעה של צד שלישי תואמים ל-3PCD או לא.	אנחנו מדברים על הבקשה כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
בדיקה	בקשה להגדרת דגלים נוספים במכונות מנוהלות של Chrome, שמשביתה באופן זמני את ההתנהגויות המותאמות אישית.	אנחנו שוקלים את הבקשה הזו לגבי מכונות מנוהלות של Chrome, ונשמח לקבל משוב נוסף מהסביבה העסקית אם דגל כזה יהיה שימושי.

הרשמה ואימות

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

הצגת מודעות ותוכן רלוונטיים

נושאים

נושא המשוב	סיכום	תגובה מ-Chrome
(דווחו גם ברבעונים קודמים) לוח זמנים ותיעוד של הסווג	צריך להיות מנגנון כלשהו לבדיקה של הסיווג, או לפחות שקיפות נוספת לגבי האופן שבו מצב הסיווג קובע את הקטגוריות.	התשובה שלנו לא השתנתה מארבעי החודשים הקודמים: "סיווג שגוי של אתרים עשוי להפחית מעט את השימושיות של האות 'נושאים' כאות באופן כללי, אבל לא תהיה לכך השפעה משמעותית על האתרים הספציפיים שסווגו באופן שגוי, בהשוואה לאתרים אחרים. הסיבה לכך היא שמידע ההקשר של האתר תמיד יהיה זמין במכרזים באתר, וכך יוכל לספק מידע דומה לנושא הנכון, גם במקרה של סיווג שגוי. נשמח לקבל משוב בנושא הזה כאן."
Google Ad Manager	Google Ad Manager כבר מוטמע ברוב האתרים, והוא יכלול מידע רחב יותר על נושאי העניין של המשתמשים בהשוואה למתחרים שנמצאים בפחות אתרים.	דרישה למעקב נדרשת כדי להבטיח ש-Topics API לא יוביל לשיתוף של נתוני משתמשים עם ישויות רבות יותר מאשר הטכנולוגיות שה-API מחליף (כולל צדדים שלישיים). פתרונות אחרים בתחום, כמו Prebid, פועלים עם עשרות אלפי אתרים ומאפשרים לגורמים בשוק לבצע קריאה ל-Topics API דרך הטכנולוגיה שלהם. בנוסף, חשוב לציין שהמגבלה של עד 5 נושאים מובילים בשבוע עשויה להשפיע על השוויון, כי משתתפי שוק שנמצאים באתרים רבים ויכולים ללמוד יותר מ-5 נושאים מקבילים באמצעות 3PCs, יוגבלו ל-5.
(דיווח גם ברבעונים קודמים) השימושיות לסוגים שונים של בעלי עניין	חששות לגבי הערך שנוצר וההפצה של הערך הזה באתרים, בהתאם לרמת התנועה בהם או לרמת המומחיות של התוכן שלהם.	אנחנו מבינים שיש סיכוי גבוה יותר שאתרים מיוחדים יעזרו לנו להוסיף נושאים מפורטים יותר מאשר דומיינים של תחומי עניין כלליים. עם זאת, לא כל האתרים המיוחדים תורמים לנושאים בעלי ערך מסחרי. בנוסף, הדינמיקה הזו משקפת את הסטטוס קוו והיא לא קשורה בכלל לסיום התמיכה ב-3PC ב-Chrome. בנוסף, בסביבה הנוכחית, יש אתרים שמספקים ערך רב יותר מאתרים אחרים במערכות לקביעת רלוונטיות של מודעות שמבוססות על 3PC. בנוסף, נושאים באתרים ייעודיים יכולים להועיל לשני הצדדים, כי מפרסמים מגוונים יכולים להפעיל קמפיינים במגוון נושאים, ולוגיק הבידינג יכול לזהות ערך במגוון רחב של נושאים.
שמות מארחים לעומת כתובות URL מלאות	האם הסיווג על סמך שמות המארחים של אתרים יעיל מספיק, והאם הוא מפחית את הסיכון לפגיעה בפרטיות בהשוואה לכתובות URL מלאות?	העלינו בחשבון שימוש בכתובות URL של מידע או בכותרות של דפים בנוסף לשמות המארחים, והגענו למסקנה שהסיכונים לפרטיות ולאבטחה של המשתמשים יהיו גבוהים יותר מהיתרונות הפוטנציאליים. דוגמה לסיכונים לפרטיות המשתמשים היא סיווג של מידע רגיש שמופיע בכתובת ה-URL או בשם הדף לנושאים של משתמש.
נושאים כאות	בקשה לקבלת הנחיות לגבי שילוב של 'נושאים' עם אותות אחרים, ואילו אותות אחרים עשויים להיות שימושיים.	פתרונות טכנולוגיית הפרסום יכולים להשיג את התוצאות הטובות ביותר על ידי שילוב של כל הכלים הזמינים, כמו למידת מכונה ואותות ללא פגיעה בפרטיות מממשקי API לשמירה על הפרטיות, יחד עם נתונים לפי הקשר, נתוני קריאייטיב ונתונים מאינטראקציה ישירה (First-Party). הדרכה נוספת בנושא זמינה כאן.

Protected Audience API (לשעבר FLEDGE)

נושא המשוב	סיכום	תגובה מ-Chrome
נפח התנועה לבדיקה	הבודקים מדווחים על נפח נמוך של תגובות לבקשות להצעת מחיר במכרז של PA API.	1. צפיפות הצעות המחיר קשורה להשתתפות של גורמים בסביבה העסקית ב-PA API, ואנחנו צופים שהיא תמשיך לעלות במהלך 2024 ואילך. בסופו של דבר, המפרסמים, הסוכנות שלהם וספקי הטכנולוגיה הם אלה שקובעים איך להקצות את תקציבי הקמפיינים. אנחנו צופים שחלק מהגורמים בסביבה העסקית עשויים לדחות את ההשקעה שלהם בפתרונות שונים ללא שימוש בקובצי Cookie, כולל PA API, עד אחרי 3PCD. בשלב הזה, אנחנו מצפים שהם יגדילו את הקצאת התקציב של הקמפיין לפתרונות כאלה. 2. נפח הבקשות להצעות מחיר במכרזים של PA API עשוי להיות מושפע מגורם (1), מאחר שבעלי תוכן דיגיטלי וספקי טכנולוגיית הפרסום שלהם עשויים להחליט לא להתחיל מכרזים של PA API אם הם סבורים שהביקוש נמוך. בעלי האפליקציות והאתרים הם אלה שקובעים את סדר העדיפויות של עדכון הדפים שלהם והשתתפות בתוכנית. אנחנו צופים שבעלי תוכן דיגיטלי עשויים להקדיש זמן לבדיקות ולעלייה הדרגתית בנפח התנועה מהסיבות האלה. הדוח הזה כולל גם תשובה מ-Google Ad Manager לגבי אמצעי הבקרה של בעלי האפליקציות להשתתפות ב-PA API.
(דווחו גם ברבעונים קודמים) הונאה / ניצול לרעה	איך הסביבה העסקית יכולה לצמצם את הסיכונים ולמנוע מגורמים זדוניים או מלקוחות להציג את עצמם כקהל רצוי?	מנגנוני הדיווח של מודעות PA API שומרים את המידע שמשמש היום להבדיל בין תנועה של בני אדם לתנועה של בוטים. בנוסף, אפשר להשתמש בשיטות הנוכחיות שמבוססות על דומיינים כדי לכלול או להחריג דומיינים ב-PA API. הנושא הזה מתואר בפירוט נוסף בתגובה שלנו לדוח של IAB Tech Lab בנושא ארגז החול לפרטיות.
הגבלת מקור זהה על כתובת ה-URL של הבעלים ב-IG וכתובת ה-URL של לוגיקת הבידינג	אם תהיה דרישה למקור זהה, נקודות קצה של בעלי IG ייאלצו לעבור דרך אותו מאזן עומסים, מה שעלול להוביל לדחיית הפניות אוטומטיות.	הדרישה לטעינה מאותו מקור של סקריפט היא אמצעי אבטחה חשוב. כאן מפורטת פתרון מוצעת שמאזנת בין משוב מהסביבה העסקית לבין שיקולים אחרים.
מכרז פרטי עם כמה משבצות	יש הרבה מקום לאפשר מכרזים פרטיים עם כמה משבצות במסגרת גבולות הפרטיות, באמצעות שימוש ברעשי רקע ושילוב הדוק יותר עם השיטות הנוכחיות של הצגת מודעות.	אנחנו מביאים בחשבון את המשוב הזה ומעריכים את הבקשה למכרזים עם כמה תגים בהשוואה לסיכון המוגבר לפרטיות ולמורכבות המוגברת שקשורים לתכונה הזו. דיברנו על הבעיה הזו בהרחבה במהלך שיחה של קבוצת הקהילה של PA API Web Incubator Group‏ (WICG) כאן.
מוכרים ברמה העליונה	המבנה הנוכחי של PA API מספק לכל מוכר ברמה העליונה הרבה יותר נתונים והבנה של הערך היחסי של חשיפות בהשוואה לבעלי תוכן דיגיטלי או למוכרי רכיבים.	במכרז עם כמה מוכרים, לכל מוכר תהיה הצעת המחיר הטובה ביותר. בנוסף, למדנו מהסביבה העסקית של בעלי התוכן הדיגיטלי שיכול להיות שהם ירצו להביא בחשבון ביקוש שנמכר ישירות לצד הצעות המחיר הטובות ביותר של כל מוכר שהם עובדים איתו. כדי לקבוע איזו מודעה להציג, צריך לבחון את כל ההזדמנויות האפשריות למונטיזציה. המצב הזה, שבו גורם כלשהו צריך לראות את קבוצת האפשרויות המלאה כדי לבחור מודעה להצגה, היה קיים עוד לפני PA API. PA API נועד לתמוך במכרזים עם מספר מוכרים וברצון של בעלי תוכן דיגיטלי להביא בחשבון את הצעת המחיר הטובה ביותר של כל מוכר לצד קמפיינים של מודעות שנמכרו ישירות, במקרים שבהם האפשרות הזו רלוונטית. כלומר, צריך להיות מנגנון לבחירה מבין הזדמנויות המונטיזציה האלה, כמו שיש היום. לא חשבנו שזה התפקיד של הדפדפן לבחור איזו מודעה להציג. לכן, המושג 'מוכר ברמה העליונה' נחוץ כדי לבחור מודעה מנצחת מתוך אפשרויות רבות. הלוגיקה של המוכר ברמה העליונה צריכה לאפשר לו להביא בחשבון את הצעות המחיר הטובות ביותר מכל מוכר שבעלי התוכן הדיגיטלי בחר לעבוד איתו. לוגיקה של המוכר הזה עשויה לספק מידע על הקמפיינים של בעל האפליקציה שנמכרו ישירות, אם המידע הזה זמין. כל המידע הזה יכול להיכלל בלוגיקה של בחירת המודעות ברמה העליונה. כלומר, כדי לקבוע מי המנצח, הלוגיקה ברמה העליונה מציגה את הצעות המחיר הטובות ביותר מהמכרז של PA API, ואם רלוונטי, גם את כל אפשרויות המודעות שנמכרו ישירות מהבעלים של אתר החדשות. הטמעת PA API כבעלים של מודעות ברמה העליונה ב-Google Ad Manager מפורטת בדוח הזה בקטע גישה למידע.
הפרדה בין מודעות מתחרות	בקשה להפרדה בין מודעות מתחרות, למשל, למנוע הצגה של מודעות של מותגים מתחרים זו לצד זו.	אנחנו לא יודעים איך להבטיח הפרדה תחרותית בסביבה העסקית של הפרסום הדיגיטלי של היום, שמבוססת על בידינג פרוגרמטי ומשתתפים מרובים. עם זאת, PA API מאפשר למוכרים לאחזר אותות נוספים בזמן אמת על סמך שילוב של renderURL ו-hostname (שמייצג את הדומיין של בעל התוכן הדיגיטלי), שאפשר להשתמש בהם במהלך scoreAd() כשנותנים ניקוד לנכסי קריאייטיב. בעלי מוצרים יכולים להשתמש באפשרות הזו כדי למנוע הצגה של מודעות של מותגים מתחרים זו לצד זו, בהנחה שהבעלים של אתר החדשות רוצה לאכוף את הכלל הזה.
מידע מוגבל	באמצעות PA API, אנחנו מצמצמים את המידע שזמין לבעלי תוכן דיגיטלי, כמו ערך המודעה, שם הקונה של הרכיב, שם המפרסם, כתובת דף הנחיתה, גודל הקריאייטיב, זמן התגובה, שיעור הבידינג וגם הצעות מחיר שהפסידו.	כאן הצגנו כמה פתרונות אפשריים, ונשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח ברמת האירוע	בעלי אתרים לא יכולים לקבל מספיק מידע על המודעה שמוצגת אחרי ההוצאה משימוש של PA API לדיווח ברמת האירוע.	אנחנו מודעים לתרחישים לדוגמה שונים של דיווח שאנחנו צריכים להמשיך לתמוך בהם אחרי שנסיים את השימוש בדיווח ברמת האירוע. לכן, היעד שלנו הוא להפסיק את הדיווח ברמת האירוע לא יאוחר משנת 2026. עד אז, אנחנו מזמינים אתכם להשתתף באופן פעיל בעבודה שלנו עם הסביבה העסקית כדי למצוא דרכים עמידות קדימה, שעשויות לכלול רעיונות חדשים לאיסוף מידע תוך שמירה על הפרטיות.
מספר ספקי SSP	הערך המוסף של שימוש בכמה פלטפורמות SSP יהיה נמוך מדי לבעלי תוכן דיגיטלי.	אנחנו לא מאמינים שהטענה הזו נכונה, ונשמח לקבל משוב נוסף מהסביבה העסקית כדי להבין את ההיגיון מאחורי ההצהרה הזו.
פעילויות של ניהול תוכן	אי אפשר לבצע פעילויות של ניהול תוכן באמצעות PA API.	קיבלנו משוב לגבי היכולת של בתי עסק להשתמש ב-PA API כדי להציג את נתוני הקהל שלהם לקונים ברחבי האינטרנט (נקרא גם תוסף קהל). אנחנו מאמינים שאפשר לעשות זאת כבר היום, באמצעות פונקציונליות הענקת הגישה של PA בשילוב עם הסכמים עסקיים. במקביל, אנחנו בודקים באופן פעיל אם אנחנו יכולים להתאים את השירות לתרחישים לדוגמה מהסוג הזה, ואיך אנחנו יכולים לעשות זאת.
ביטול ההסכמה מצד הקונה	סביר להניח שביטול ההסכמה כברירת מחדל של הקונים יוביל לתוצאות נמוכות יותר במכרזים של רכיבי מודעות.	בין שהמוכר מגדיר מכרז PA של מוכר יחיד ובין שהוא מגדיר מכרז PA של כמה מוכרים, הוא חייב לציין את הקונים באופן מפורש בשדה interestGroupBuyers של AuctionConfig. ההחלטה הזו מבוססת על משוב מהסביבה העסקית, לפיו למוכרים יש הסכמים חוזיים עם חלק מהקונים ולא עם אחרים, ולכן הם צריכים לשלוט באופן מפורש באילו קונים לכלול במכרז. אנחנו מזמינים אותך להמשיך את הדיון בנושא ב-GitHub.
Adsize	לא ניתן לבצע סינון מראש על סמך adsize ו-adSlotSize.	אנחנו עובדים על הוספת היכולת הזו, ופרטים נוספים זמינים כאן.
תמיכה בטירגוט שלילי ב-IG	ממשק API לתמיכה בטירגוט של IG שלילי: הצגת מודעות רק אם המשתמש לא שייך ל-IG.	בבעיה הזו ב-GitHub הוצעה דרך חלופית להטמיע טירגוט שלילי, שבה הדפדפן מודיע ישירות לשרת המודעות אילו כללי טירגוט שלילי צריכים להיות בתוקף לגבי בקשה מסוימת להצגת מודעה. נראה שזו גישה מושכת, אבל כל הגרסאות של הרעיון הזה שבדקנו מאפשרות לשרת לזהות את המשתמש באופן ייחודי.
חוק השירותים הדיגיטליים (DSA)	איך בעלי תוכן דיגיטלי יכולים להשתמש ב-Fenced Frames, אבל גם למנוע את העיבוד של תגובות שמכילות מידע שכפוף ל-Digital Services Act (חוק השירותים הדיגיטליים)?	כמו בכל טכנולוגיה חדשה, כל חברה אחראית לוודא שהשימוש שלה בארגז החול לפרטיות עומד בדרישות החוק. Google לא יכולה לספק ייעוץ משפטי לאחרים. לכל ממשק API פרסמנו מסמכי תיעוד טכניים מקיפים, שיכולים לספק את הבסיס לביצוע ההערכות המשפטיות הנדרשות. לא תהיה דרישה להשתמש ב-Fenced Frames ב-PA API לפני שנת 2026, כדי לתת לגורמים מעורבים זמן נוסף לוודא שהשימוש שלהם בטכנולוגיה הזו עומד בכל החוקים הרלוונטיים.
מאמרי עזרה	האם updateAdInterestGroups()‎ הוא זמני?	לא הודענו על תוכניות להוצאה משימוש של updateAdInterestGroup. בעתיד, יכול להיות שנחיל אמצעי הגנה דומים על הפרטיות, כמו אלה שציינו בפומבי לגבי מנגנונים אחרים של עדכונים ב-IG. למשל, שימוש בכתובת IP גם כשרת proxy והוספת עיכוב מסוים לפני שהעדכון מתבצע.
תמיכה בבעלות על מטא-נתונים ועל לוגיקה בצד הקונה עבור פלטפורמות שאינן פלטפורמות ניהול מודעות (DSP)	בקשה לקבלת דרך לפעול כשרתי proxy עבור פלטפורמות DSP.	אנחנו מודעים למשוב הזה מפלחים שאינם DSP, ואנחנו שוקלים את הבקשה הזו. נשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח	בקשה להוספת תכונה של טיפול מותאם אישית לקטגוריה או לערך של אותות בדוחות על צבירת נתונים פרטית.	אנחנו מודעים לכך, ובקשת התכונה הזו נמצאת בתור שלנו לבדיקה נוספת. נשמח לקבל משוב נוסף מהסביבה העסקית כאן.
מאמרי עזרה	האם יש קישור שבו אפשר לראות את כל כותרות התגובה שצריך להגדיר המפרסם והדומיין של הבעלים (שהוא העביר את הגישה)?	אנחנו מתכננים עדכונים במסמכים כדי להבהיר את הנושא הזה, ונשמח לקבל משוב נוסף מהסביבה העסקית.
בידינג בכמה פלטפורמות	בקשה להסבר על תהליך העבודה (אימון והסקה) באמצעות ארכיטקטורה או תרשים זרימה, שמציגים את הגישה של כמה מגדלים בהקשר של PA API.	תודה על המשוב. יש לנו כמה מצגות בנושא, ומהן אנחנו מתכוונים ליצור מסמכים נוספים.
טירגוט שלילי	היכולת של ארגז החול לפרטיות להגן על קהלים רגישים ועל קטינים מפני מודעות בלתי הולמות, למשל מודעות בנושא הימורים.	המערכת של PA API לא מביאה בחשבון את התוכן של המודעות שמוצגות. האפשרות הזו נמצאת בשליטת מפתחי טכנולוגיות הפרסום שמשתמשים ב-PA. באופן כללי, בעלי התוכן הדיגיטלי וספקי טכנולוגיות הפרסום שלהם יכולים לחסום נכסי קריאייטיב של מודעות במכרזים של קהלים מוגנים באמצעות מידע לפי הקשר מהדף וכן קבוצות של כללים של בעלי התוכן הדיגיטלי. זה משקף את ההבנה שלנו לגבי הגישה של הסביבה העסקית לאתגרים האלה כיום. לקונים, הפונקציונליות של טירגוט שלילי ב-IG עשויה להיות שימושית גם בתרחישי שימוש מסוימים של תאימות.
תכנון ממשקי API	Google מתנגדת לכך ומבקשת מטכנאי הפרסום להשתמש בפונקציה של בידינג אוניברסלי, וכך להגדיל את זמן האחזור, במקום להשתמש ב-biddingLogicURLs שונים ב-IGs שונים, מה שמורשה.	במהלך הדיונים שלנו על זמן האחזור במכרז, הדגשנו ששימוש חוזר באותו סקריפט בכל ה-IG של הקונה יקצר את זמן הבידינג של הקונה. פרטים נוספים מופיעים כאן, יחד עם המלצות נוספות שלנו לשיפור זמן האחזור במכרזים של PA API.
שיווק מבוסס-חשבון	ממשק PA API הוא לא ממשק API נקי לתרחישים לדוגמה של שיווק מבוסס-חשבון.	אנחנו מקבלים בברכה משוב מהסביבה העסקית לגבי תרחישי שימוש ספציפיים שלדעתם לא אפשריים, ומעודדים את המשתתפים בסביבה העסקית להמשיך את הדיון הזה דרך המאגר הציבורי שלנו ב-GitHub או באמצעות שיחות השבועיות שלנו.
בדיקת A/B	כשמגדירים את PA API ב-GAM לבעל תוכן דיגיטלי, צריך להפעיל אותו כרגע לכל מלאי שטחי הפרסום או לאף אחד מהם. כך מוגבלת היכולת של בעלי התוכן הדיגיטלי להריץ בדיקת A/B יעילה.	תגובה שסופקה על ידי Google Ad Manager: אמצעי הבקרה של PA API ב-Google Ad Manager‏ (GAM) משפיעים על היכולת של GAM להשתמש ב-API, בתנאי שה-API זמין לשימוש. לכן, בעלי תוכן דיגיטלי יכולים להריץ בדיקות A/B באמצעות הפונקציונליות של מדיניות ההרשאות ב-Chrome כדי להשבית את השימוש ב-API בקבוצת משנה של תנועה, ולהשתמש בה כזרוע בקרה לבדיקה.
למידת מכונה	לבעלי האפליקציות צריכה להיות יותר שליטה על השימוש המוצע ב-GAM בלמידת מכונה.	התשובה שקיבלנו מ-Google Ad Manager: בינואר 2024 השקנו אמצעי בקרה שמאפשר לבעלי תוכן דיגיטלי להשבית את המנגנון שלנו לוויסות התנועה על סמך למידת מכונה, ולהפעיל מכרזים של PA API עם מוכרים שאינם Google בכל התנועה שלהם. פרטים נוספים על אמצעי הבקרה הזה זמינים במרכז העזרה שלנו.
(דווחו גם ברבעונים קודמים) מכרזים ברמה העליונה	היכולת להשתמש בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי לתת ל-GAM גם שליטה במכרז ברמת ה-API של PA.	התשובה שקיבלנו מ-Google Ad Manager: מהסיבות שמפורטות בדוח הרבעון השלישי של Google לשנת 2023, התוכניות של GAM לשילוב עם PA API לא כוללות תמיכה באתרי חדשות שמשתמשים ב-GAM כשרתי המודעות שלהם ללא שליטה במכרז ברמה העליונה.
גישה למידע	ל-GAM יש גישה למידע חשוב ממתחרים, כולל מחירי מכרזים לפי הקשר, אותות שקיבל הקונה מ-SSP למכרז PA API ופרמטרים של הגדרות מ-SSP.	התשובה של Google Ad Manager: אנחנו מתמקדים כבר שנים בשמירה על הוגנות במכרזים, כולל ההבטחה שלנו שלא נשתף עם קונה אחר מחירים ממקורות פרסום לא מובטחים של בעלי תוכן דיגיטלי, כולל מחירים של פריטים לא מובטחים, לפני שהקונה יציע מחיר במכרז. מאוחר יותר אישרנו את ההבטחה הזו במחויבויות שלנו לרשות התחרות בצרפת. במכרזים של PA API, אנחנו מתכוונים לעמוד בהבטחה שלנו ולא לשתף את הצעת המחיר של כל משתתף במכרז עם משתתף אחר במכרז לפני סיום המכרז במכרזים עם מספר מוכרים. חשוב להבהיר: אנחנו לא נשתף את המחיר של המכרז לפי הקשר עם אף מכרז רכיבים, כולל המכרזים שלנו, כפי שמוסבר בעדכון הזה. בנוסף, אנחנו לא משתמשים במידע על הגדרות המכרז של הרכיבים, כולל אותות שהקונים מספקים ל-SSP, כחלק מהמכרז שלנו. למעשה, נשמח לשינויים ב-PA API שיאפשרו למוכרי רכיבים לציין את הגדרות המכרזים של הרכיבים שלהם באופן שהמוכר ברמה העליונה לא יוכל לראות.
מכרזים של רכיבים	כמכרז ברמה העליונה, מערכת GAM תשלוט ב-SSPs שיפעילו מכרזים של רכיבים לכל הזדמנות להצגת מודעה.	התשובה שסופקה על ידי Google Ad Manager: כשרתף פרסום של בעלי תוכן דיגיטלי, GAM מציע ממשק API קל משקל ל-SSPs שבהם בעלי תוכן דיגיטלי עשויים לעבוד, כדי לציין את הגדרות המכרז של הרכיבים שלהם דרך Google Publisher Tag (GPT) API. פרטים נוספים זמינים כאן. אם מערכת SSP מספקת הגדרה של מכרז רכיב דרך ה-API הזה, היא תהיה כלולה ברשימת מכרזי הרכיבים של הזדמנות הפרסום הזו. מערכת GAM לא מטילה הגבלות על מכרזי הרכיבים הכלולים. כל פלטפורמת SSP שרוצה להפעיל מכרז רכיב תוכל לעשות זאת, בתנאי שבעל התוכן הדיגיטלי העניק לה הרשאה להריץ את הקוד הנדרש בדף של בעל התוכן הדיגיטלי.
מכרזים של רכיבים	מערכת GAM עשויה להחיל סף ספציפי ולא ידוע על כל הצעת מחיר מנצחת במכרז רכיב.	התשובה שסופקה על ידי Google Ad Manager: ב-GAM אנחנו מתמקדים כבר שנים בשמירה על הוגנות במכרזים. כחלק מהמאמצים שלנו לשמור על מכרז הוגן ושקוף, אנחנו לא תומכים במחירי רצפה שחלים רק על פלחים ספציפיים של ביקוש. זהו עיקרון עקבי במוצר שלנו, והוא ימשיך לחול על מכרזים של PA API.
שרתי מודעות של צד שלישי	לשרתי המודעות של צד שלישי לא תהיה גישה להשתתפות של Google במכרז ברמה הגבוהה יותר, וכך תוגבל היכולת שלהם ליהנות מביקוש ב-SSP של Google בהקשר של PA API.	תשובת Google Ad Manager: נכון לעכשיו, מערכת GAM תומכת בבדיקה של PA API עם כמה מוכרים ב-GAM דרך ה-API שמתואר כאן. בשלב הזה אין תמיכה בהשתתפות של GAM כמכרז רכיב במכרזים אחרים ברמה העליונה.
(הנתונים האלה דווחו גם ברבעונים קודמים) ביצועים של מכרזים של PA API	דיווח מבודקים על זמן אחזור ארוך במכרזים של PA API.	קיבלנו דיווחים על חששות לגבי זמן האחזור, וזו אחת הסיבות לכך שפיתחנו כמה תכונות במסגרת PA API, שיאפשרו ל-SSPs להגדיר מגבלות על זמן האחזור ב-DSP וגם לבצע שיפורים שיכולים לקצר את זמן האחזור. לאחרונה עדכנו את מדריך השיטות המומלצות בנושא זמן אחזור, שכולל מידע נוסף על האופן שבו אפשר לנצל את התכונות האלה. אנחנו גם ממשיכים לפתח שיפורים חדשים בזמן האחזור, חלק מהם מפורטים כאן.
(דווח גם ברבעונים קודמים) עיבוד וידאו	תמיכה ברינדור של סרטונים באמצעות PA API ו-Fenced Frames.	בינואר פרסמנו הדגמה של האופן שבו מודעות וידאו In-stream עשויות לפעול במכרז PA, עם פרטים נוספים על גישות חלופיות. אנחנו גם רואים ששחקנים בסביבה העסקית מתחילים להציע הצעות לגבי אופן העיבוד של סרטונים לשותפים שמשתלבים איתם, כמו הצעות של GAM לגבי בניית renderURL תואם לסרטונים או התהליך המלא מקצה לקצה. בנוסף, אנחנו מקשיבים למשוב מהסביבה העסקית לגבי שינויים שאנחנו יכולים לבצע כדי להגדיל את השימוש, ואחד מהשינויים האלה מפורט ב-GitHub. אנחנו ממשיכים לפעול באופן פעיל בסביבה העסקית כדי לזהות מכשולים אחרים לשימוש שעשויים להופיע ולטפל בהם בזמן.
(דווח גם ברבעונים קודמים) מדיניות טיפול בנתונים	מהי המדיניות בנושא טיפול בנתונים של ממשקי API של IG או של PA?	בתכנון של PA API, כל הנתונים שמאוחסנים ב-IGs, או לגבי האנשים שנמצאים ב-IGs מסוימים, (1) נשארים במכשיר או (2) עוברים עיבוד בשירותי הבידינג והמכרזים (B&A) שפועלים בסביבת Trusted Execution Environment‏ (TEE). בשני המקרים, צדדים אחרים לא יכולים לקרוא את הנתונים או להשתמש בהם בשום דרך אחרת מלבד לצורך יצירת הצעות מחיר במכרז. חלק משיפורי הפרטיות שאנחנו בודקים ב-Chrome כוללים אינטראקציה עם שרת אנונימיות מסוג k שמנוהל על ידי Google. האינטראקציה הזו תוכננה בקפידה כדי למנוע שיתוף מידע על משתמשים, ולהריץ אותה בסביבה מאובטחת (TEE) כדי להבטיח שוויון במידע בסביבת הפרסום. Google התחייבה בפני CMA לתכנן ולהטמיע את ההצעות של ארגז החול לפרטיות באופן שלא יפגע בתחרות על ידי מתן עדיפות לעסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום הדיגיטלי ועל בעלי תוכן דיגיטלי ומפרסמים. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם CMA כדי לוודא שהעבודה שלנו עומדת בהתחייבויות האלה.
(דווח גם ברבעונים קודמים) משך החיים ב-IG	שליחת בקשה להארכת משך החיים של מודעות IG מ-30 ל-90 יום.	שינוי כזה מחייב הערכה מדוקדקת, שבה צריך לשקול את היתרונות לתעשייה מול ההשפעה על משתמשי Chrome וגורמים אחרים בעלי עניין. אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.
(הנתונים האלה דווחו גם ברבעונים קודמים) modelingSignals	מבקשים שדה חדש בנוסף ל-modelingSignals שיכולים לקודד רק מידע על חשיפות וקליקים.	הגבנו למשוב הזה עם הצעה נגדית כאן. אנחנו פועלים באופן פעיל בתחום כדי להבין את הדעות של הגורמים השונים לגבי ההצעה שלנו, ואנחנו שוקלים כרגע את היתרונות לתעשייה מול ההשפעה על משתמשי Chrome וגורמים אחרים בעלי עניין.
ביטים נוספים בפונקציה reportWin()‎	יש לספק עוד ביטים ב-reportWin() מהמגבלה הנוכחית של 12 לפני 3PCD.	אנחנו בודקים כרגע גישות שיעזרו לנו לתמוך בתרחיש לדוגמה הזה. התהליך הזה נמשך זמן מה כי אנחנו גם מחפשים גישות שיעזרו לנו להבטיח שתהיה לנו תוכנית פרטיות לטווח ארוך.
עיצוב המכרז	בקשות למכרז יחיד שמחזירות כתובות URL שעברו עיבוד עם הדירוג המתאים.	האפשרות לשתף כמה כתובות URL לעיבוד (renderURL) ואת הדירוג שלהן מאותו מכרז של מודעות לרשת המדיה נבחנה על ידנו, אבל לא יושמה בגלל חששות לגבי פרטיות. אנחנו מבינים את הרצון להימנע מהצגת אותה מודעה מספר פעמים למשתמש בדף אחד, ונשמח לדון בנושא בהמשך ב-GitHub.
reportWin	רישום ביומן של שדות שרירותיים בפונקציה reportWin().	זה כבר קורה היום במהלך תקופת הבדיקה. אחרי שנסיים את התמיכה ב-3PC ב-Chrome, גרסת ה-API forDebuggingOnly תעבור כדי לאפשר ניפוי באגים עם דגימה למטה, כפי שמפורט כאן.
מוכרי רכיבים	יש לו מנגנון עצמאי לספירת החשיפות והאירועים האחרים שלו, ולא צריך להסתמך רק על דוחות של טכנולוגיות פרסום.	בקשת התכונה הזו נמצאת בתור שלנו לבדיקה נוספת. אנחנו לא צפויים לטפל בבעיה הזו במהלך תקופת הבדיקה שמתבצעת באמצעות Chrome.
חיוב לפי עלות לקליק	הטמעת חיוב לפי עלות לקליק ב-PA API.	אנחנו מביאים בחשבון את הבקשה הזו כאן, כרגע אנחנו מתייחסים אליה כבקשה להצעות לאופן ההטמעה שלה בממשק ה-API הנוכחי.
browserSignals	מוסיפים את incomingBidInSellerCurrency למפרט של דיווח על אותות הדפדפן עבור המוכר.	אנחנו בוחנים את הבקשה הזו ונשמח לקבל משוב נוסף כאן.
תמיכה בבעלות על מטא-נתונים ועל לוגיקה בצד הקונה ללא פלטפורמות DSP	העיצוב הנוכחי של ה-API עשוי להוביל לשינוי משמעותי בקמפיינים של טירגוט מחדש ברמת המוצר, שבהם יכול להיות שיהיה צורך להעביר את הקמפיינים לפלטפורמות שמשמשות גם כ-DSP וגם כספקי DCO.	אנחנו מדברים על הבעיה הזו ונשמח לקבל משוב נוסף כאן.
תמיכה בבעלות על מטא-נתונים ועל לוגיקה בצד הקונה ללא פלטפורמות DSP	יש לשתף דוגמאות שבהן פלטפורמת ה-DSP היא לא הבעלים של החשבון ב-IG.	אנחנו מבינים שחלק מהמשתמשים שלא מגישים הצעות מחיר רוצים להשתמש בחלק מהפונקציונליות של מודעות ה-IG, אבל לא בחלק אחר. אנחנו בודקים באופן פעיל אפשרויות לטיפול בתרחישי השימוש האלה, ונשמח לקבל משוב נוסף כאן.
אמצעי בקרה על זמן קצוב	בעלי האפליקציות צריכים להיות מסוגלים לקבוע את מספר החשבונות ב-IG שיכולים להשתתף ואת הזמן הקצוב לתפוגה ברמה העליונה או ברמה הגלובלית.	אנחנו מבינים שיש לך רצון לקבל בקרה משופרת על זמן הקצאת הזמן ולשפר את היכולת לראות את הקשר בין מוכר ברמה העליונה לבין מוכר רכיבים, ואנחנו שוקלים את הבקשה הזו.
גדלים שונים של מודעות	תמיכה ב-PA API בתרחישי שימוש עם כמה גודלי מודעות.	אנחנו שוקלים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
מאמרי עזרה	האם יש רשימה של מאפייני IG שעוברים אנונימיזציה לפי K?	השבנו על השאלה הזו כאן.
ניפוי באגים	יכולות משופרות לניפוי באגים ב-PA API.	אנחנו מבינים את החשיבות של כלים חזקים לניפוי באגים למפתחים שעובדים עם PA API. אנחנו מחויבים לשפר את חוויית המפתחים, ולשם כך אנחנו בודקים דרכים לשילוב טוב יותר של אחזור קבצים מסוג ‎ .well-known עם כלים למפתחים. המטרה שלנו היא לספק יותר שקיפות ויכולות לפתרון בעיות בסביבת הפיתוח. אנחנו ממשיכים לדון בבעיה הזו כאן ונשמח לקבל משוב נוסף.
תוויות	האם ממשקי ה-API של ארגז החול לפרטיות מופעלים אצל כל המשתמשים בתוויות הטיפול במצב B?	ההקצאות לקבוצות הניסוי ב-Chrome נקבעות באופן אקראי, ללא קשר להגדרות Chrome שהמשתמשים מגדירים. יכול להיות ש-API האלה יהיו זמינים למשתמשים בקבוצות טיפול ספציפיות (למשל, treatment_1.*), אבל אפשר לשנות או להשבית את הפונקציונליות שלהם דרך הגדרות Chrome. קבוצת control_2 במצב B: ההכללה בקבוצה הזו משביתה באופן מהותי את ממשקי ה-API למדידת הביצועים ולקביעת הרלוונטיות של ארגז החול לפרטיות, והמשתמש לא יכול לשנות את ההגדרה הזו בהגדרות Chrome.
שימוש ב-API	האם הקריאה ל-reportWin() והעיבוד של המודעה מתרחשים במקביל או אחד אחרי השני?	הפונקציה reportWin()‎ נקראת ישירות אחרי השלמת הפונקציה runAdAuction(). ‎ במקביל, תהליך הרינדור של המודעה עשוי להתחיל כשתוצאת המכרז ממוקמת בתוך iframe או בתוך מסגרת מוקפת. אחרי שההרצה של reportWin() תסתיים והמודעה תתחיל להירטן, יתבצע אחזור של כתובות ה-URL שסופקו ל-sendReportTo().
(דווח גם ברבעונים קודמים) תמיכה בבדיקות A/B	בקשת תמיכה בבדיקות A/B של PA API.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
עיצוב תעבורת נתונים	הצעה של Google לניהול תהליך קבלת ההחלטות הנדרש דרך שרת KV לא מועילה, כי המוכרים לא יכולים לקיים אינטראקציה עם הקצה העורפי שלהם, מה שמקשה על יצירת פרופיל תנועה.	כפי שצוין בבעיה ב-GitHub, חשיפת העובדה אם פלטפורמות DSP מסוימות משתמשות ב-IGs עלולה לגרום לבעיות שקשורות ליצירת טביעות אצבע של משתמשים. הצגנו חלופות אחרות בנושא הבעיה, ואנחנו פתוחים להצעות נוספות.
עיצוב תעבורת נתונים	מנגנוני האחסון במטמון מוסיפים שכבה משמעותית של מורכבות ומונעים מ-DSP לדעת מהו המבנה האמיתי של התנועה שהם מגישים עליה הצעות מחיר.	מנגנון השמירה במטמון הוצג פשוט כהצעה. חברות AdTech יכולות להשתמש בהצעות שמתאימות לתרחיש לדוגמה שלהן, ואנחנו מזמינים אתכם לדון בנושא כאן.
תוויות	Chrome צריך לשתף את התווית כפרמטר בבקשות לשרתים מהימנים של קונים ומוכרים.	נראה שזו בקשה סבירה, כי היא תואמת באופן כללי למטרה של שימוש אחראי בנתונים מ-IG. עם זאת, אנחנו שוקלים את הבקשה, בכפוף לבדיקה פנימית, ונעדכן את הציבור בנושא הזה בהתאם להתקדמות הדיונים.
שימוש ב-API	הבהרה לגבי ההגדרה המפורשת של הקבוצה control_1 במסמך 'הנחיות נוספות של CMA לצדדים שלישיים בנושא בדיקה'. באופן ספציפי, יש חשש ששינוי בניסוח עלול להוביל לפרשנות שגויה שלפיה צריך להחריג את כל ממשקי ה-API של ארגז החול לפרטיות מקבוצת הבקרה control_1.	הבעתנו את דעתנו בנושא הזה ב שרשור הזה ב-GitHub. עם זאת, אנחנו לא יכולים לדבר בשם CMA, ואנחנו ממליצים לפנות ישירות ל-CMA לגבי בעיות שקשורות לפרשנות של ההנחיות לבדיקות שלהם.
שימוש ב-API	האם Chrome יאפשר להפעיל את joinAdInterestGroup() בדף ריק בזמן הפניה אוטומטית למשאב אחר?	אם משתמש מבקר באתר כלשהו, בעלי האתר יכולים להעניק לצד שלישי את היכולת להפעיל את השיטה joinAdInterestGroup. הענקת הגישה הזו מאפשרת לצד שלישי ליצור מודעות IG בלי להוסיף שום סוג של הפניה אוטומטית דרך דף ריק. אנחנו מקבלים בברכה משוב על סיבות ספציפיות ליצירת מודעות IG באמצע הפניה אוטומטית במקום להשתמש במנגנון הענקת הגישה המיועד.
שימוש ב-API	פלטפורמות ה-Exchange צריכות להיות מסוגלות לכתוב תגי IG לדפים שבבעלות בעלי האפליקציות הדיגיטליות שהן עובדות איתם, ולאחר מכן להעניק הרשאה להגיש הצעות מחיר על התג הזה לכל קונה או פלטפורמת ניהול רשתות מודעות (DSP) נתונים.	קיבלנו את המשוב ואנחנו בודקים אם נוכל לתמוך בבקשה כזו. נשמח לקבל משוב נוסף מהסביבה העסקית.
שימוש ב-API	לא תופיע התראה על אובדן של ניפוי באגים אם אף אחד לא יזכה במכרז של PA API.	הפונקציות reportWin ו-reportResult של Chrome מיועדות לדיווח על זכיות ברמת האירוע במערכת של מכרז הפרטיות (PA). במקרים שבהם כל הצעות המחיר נדחות במכרז PA, לא צפוי שהפונקציות האלה יופעלו כי לא נקבע מנצח. עדכון אחרון ל-Chrome עשוי להסביר אי-התאמות שבהן כתובות URL שהועברו אל forDebuggingOnly.reportAdAuctionLoss() לא מופיעות בחלונית Network (רשת) של DevTools. מומלץ לאמת את הפונקציונליות הזו באמצעות גרסה של Chrome בערוץ Canary או Dev.
שימוש ב-API	האם הערך של adCost שמוחזר מ-generateBid יכול להיות שלילי (הוא כבר מעוגל באופן אקראי ל-2 בייטים)?	AdCost הוא עלות הקליק או ההמרה של המפרסם, שמועברת מ-generateBid() אל reportWin(). הערך הזה יכול להיות Null או double. המערכת תתעלם מערכים שליליים ולא תעביר אותם. הערך יעוגל באופן אקראי כשיעובר.
שיפור ממשק ה-API	האם אפשר להשתמש בשרתים מהימנים ומאובטחים לביצוע כדי לטפל בטירגוט, בקבוצות בעלות מאפיינים משותפים, בשיוך ובמכרזים במקום בדפדפן Chrome?	מומלץ לבדוק את הרכיבים והאפשרויות שמבוססים על TEE ב-PA API (למשל, שרתי KV ושירותי B&A), וגם את הרכיבים שמבוססים על TEE בדיווח על שיוך (Attribution) ובצבירה פרטית (למשל, שירות צבירה), שנותנים מענה לשאלה הזו.
שיפור ממשק ה-API	האם התגובה במכרז של ארגז החול לפרטיות יכולה להיות תגובה לבידינג (כמו בידינג בכותרת) במקום תגובה למודעה (כמו תגי מודעות)?	שינוי כזה משנה באופן מהותי את מאפייני הפרטיות של PA API, ולכן אנחנו לא שוקלים לבצע אותו.
אמצעי בקרה לבעלי תוכן דיגיטלי	האם בעלי תוכן דיגיטלי יכולים לחסום נכסי קריאייטיב של PA API בדפים שלהם?	ב-Chrome יש הצעה לסריקה של נכסי קריאייטיב בזמן אמת, שעדיין לא זמינה לבדיקה. האפשרות הזו עדיין לא זמינה, אבל שמנו לב שרוב ה-SSP יצרו פתרונות שמאפשרים זאת.
שימוש ב-API	מהי מגבלת הגודל של perBuyerSignals?	בצורתו הקלאסית, ל-perBuyerSignals אין מגבלות גודל מובנות ב-Chrome. האילוצים העיקריים הם שהנתונים יישארו ניתנים לסריאליזציה ב-JSON ולא יגרמו לשימוש מוגזם בזיכרון. עם זאת, חשוב לציין ש-perBuyerSignals גדולים ומורכבים מאוד עלולים להשפיע לרעה על הביצועים. יש שיטה חלופית להעברת perBuyerSignals דרך directFromSellerSignalsHeaderAdSlot. הגישה הזו מעבירה את perBuyerSignals בתוך כותרת, בכפוף למגבלת גודל מקסימלית של 10KB לכל תגובת הכותרת. בנוסף, שרתי אינטרנט מסוימים עשויים להטיל מגבלות משלהם על הגודל המקסימלי של כותרות.
מאמרי עזרה	צריך לשנות את המסמך בנושא הקריאה registerAdBeacon מתוך generateBid.	עדכנו את המסמכים האלה ב-17 בפברואר.
שימוש ב-API	איך reportEvent בוחרת את כתובת ה-URL הנכונה של ה-beacon מבין כמה אפשרויות רשומות?	כל מכרז יוצר הגדרה נפרדת, שמובילה למפת דיווח נפרדת. מכרזים נפרדים (והפריימים שנוצרים כתוצאה מהם) הם נפרדים לחלוטין זה מזה, והם לא משתפים נתונים. במאמר ההסבר דיווח על מודעות בפריימים מגודר מפורט מידע נוסף בנושא הזה.
ממשק המשתמש של Chrome	הוספת מסנן בכרטיסייה 'Application' (אפליקציה) -> 'Interest groups' (קבוצות תחומי עניין) ב-Chrome DevTools, שמאפשר לסנן לפי הבעלים של החשבון ב-IG (או אולי גם לפי שם החשבון ב-IG).	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית.
דפדפן Chrome ללא ממשק גרפי	תמיכה ב-PA API ב-Headless Chrome.	יש רכיבים מסוימים של PA API שמקושרים ל-Chrome, למשל הקריאות ל-k-anon לשרתים של Google, שעשויות שלא לפעול ב-Headless Chrome 'הישן'. אנחנו סבורים שהבעיה הזו עשויה להיפתר ב גרסה 'החדשה' של Headless Chrome שפורסמה ב-Chrome 112.
שימוש ב-API	במקרה של דיווח על הפסדים באמצעות reportAdAuctionLoss, אנחנו רואים את הערך 'topLevelWinningBid=0' במקרים רבים. מה המשמעות של זה?	הערך של topLevelWinningBid מגיע מהפונקציה scoreAd() ברכיב המוכר ברמה העליונה. הערך הזה משפיע על תוצאת המכרז ברמה העליונה. כפי שמוסבר במאמר, אם הערך של topLevelWinningBid הוא אפס או מספר שלילי כלשהו, המשמעות היא שהמודעה המתאימה לא עומדת בדרישות לזכייה במכרז. אפשר להשתמש במנגנון הזה, למשל, כדי לסנן מודעות שמטורגטות לקבוצות של תחומי עניין ולא עוברות את סף המודעות שמטורגטות לפי הקשר. הערך zero ב-topLevelWinningBid עשוי להצביע על כך שמכרז לפי הקשר זכה, אבל במפרט של PA API צוין שגורמים אחרים עשויים לתרום לתוצאה הזו.
בדיקת A/B של מצב	הבהרה לגבי בחירת התנועה במצב B ובמצב A והנחיות לביטול ההסכמה.	קריטריונים ההכללה של מצב A ומצב B זהים. המטרה היא ליצור קבוצות שמייצגות את התנועה הרגילה ב-Chrome, כל עוד הן תומכות בממשקי ה-API של ארגז החול לפרטיות ובשיטת התיוג. לכן, חלק מההגדרות של לקוחות לא תואמות. למטרות הניסוי, חשוב להשוות רק בין תנועה מתויגת לתנועה מתויגת אחרת. במשתמשים במצב ב', התכונה 'הגנה מפני מעקב' מופעלת, ולכן הם מקבלים התראה על התכונה הזו.
שיפור ממשק ה-API	האם אפשר לכלול את 'lifetimeMs' כנכס ישיר בקריאה joinAdInterestGroup או לנהל אותו כארגומנטים נפרדים?	אנחנו בוחנים בקפידה את המשוב מהקהילה של מפתחי האינטרנט לגבי הפונקציונליות של joinAdInterestGroup בהצעה ל-PA API. אחד מהנושאים המרכזיים לדיון הוא השיטה האופטימלית לניהול משכי החיים של מודעות IG. אנחנו בודקים את היתרונות של ארגומנטים נפרדים לפרמטר lifetimeMs, כי הם מאפשרים גמישות והתאמה לשיפורים פוטנציאליים עתידיים במפרט. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	עלייה פוטנציאלית בשיעורי תוצאות שליליות שגויות במסגרת ה-API של PA עקב התנגשויות עם מזהי דפדפן בעלי אנטרופיה נמוכה.	צוות Chrome מעורב באופן פעיל בשיפור המתמשך של מסגרת ה-API של PA. אנחנו מעריכים את הדיון לגבי שיעורי תוצאות שליליות שגויות פוטנציאליות שנובעות מקונפליקטים של מזהי דפדפנים. אנחנו בודקים את המשוב הזה בקפידה ונשתדל לוודא שהניתוחים המעודכנים ישקפו באופן מקיף את כל הגורמים הרלוונטיים. אנחנו מחויבים לפתרון שמאפשר להשיג את תוצאות הפרטיות הרצויות תוך שמירה על דיוק ואמינות. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	האם מזהה דפדפן בעל אנטרופי נמוך נדרש כדי למנוע מלקוחות לשלוח בקשות 'הצטרפות' שוב ושוב עבור אותו אובייקט במערכת עם אנונימיות מסוג k?	אנחנו מקבלים ומעריכים את הדיון המתמשך לגבי השימוש במזהי דפדפנים בהטמעה של מערכות עם אנונימיות של k. אנחנו מבינים את החששות לגבי ההשלכות האפשריות על הפרטיות של מזהים כאלה. בהטמעה הראשונית שלנו השתמשנו במזהה בעל אנטרופיה נמוכה כמנגנון למניעת ניצול לרעה, אבל אנחנו בודקים באופן פעיל שיטות חלופיות, כמו אסימוני ספירה אנונימיים, שמעניקות עדיפות לפרטיות המשתמשים תוך שמירה על תקינות המערכת. אנחנו מחויבים למצוא פתרונות שיאזנו בין שימוש אחראי בנתונים לבין אמצעי הגנה חזקים על הפרטיות, ואנחנו מקדמים דיאלוג מתמשך עם קהילת המחקר. אנחנו מדברים על זה כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	האם AMP ‏ (Accelerated Mobile Pages) תומך ב-PA API.	נכון לעכשיו, אין ב-AMP תמיכה מקורית ב-PA API. אנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית אם תמיכה ב-AMP היא בעדיפות גבוהה.
שיפור ממשק ה-API	כדאי להסיר את הסוג מבדיקות של פרטיות ברמת k.	אנחנו בוחנים בקפידה את המשוב לגבי אופטימיזציה פוטנציאלית של מבני הבקשות של פרטיות ברמת k. אנחנו מבינים את ההצעה לאחד פרמטרים ולייחד סוגים כדי לייעל את התהליך. המטרה שלנו היא להבטיח יעילות וניתןות לתחזוקה, ואנחנו בודקים את כל האפשרויות במהלך הפיתוח של פתרונות הפרטיות שלנו. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	בקשה למנגנון שיאפשר למשתמשים פחות טכניים להציג ולנהל בקלות את הקבוצות שלהן הם משתייכים, כולל אמצעי בקרה פוטנציאליים ברמת האתר לביטול ההסכמה.	אנחנו מבינים את החשיבות של מתן כלים ידידותיים למשתמש להבנה ולניהול של מודעות IG. בדקנו שיטות שונות ומצאנו שהזיהוי של קבוצות IG לפי האתר שאליו הן הצטרפו מספק את האיזון הטוב ביותר בין בהירות להגנה על הפרטיות. נכון לעכשיו, הניהול הגלובלי של תגי IG נמצא בהגדרות של Chrome. אנחנו כל הזמן בוחנים דרכים לשפר את חוויית המשתמש בתחום הזה. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
בטיחות API	האם PA API חשוף לדלפות פרטיות דרך אינטראקציות עם מודעות קריאייטיב, גם בהקשר של פריימים מגודרים?	אנחנו מכירים באפשרות של דליפת מידע דרך אינטראקציות מתוחכמות עם מודעות. אנחנו בודקים באופן פעיל את האינטראקציה בין Fenced Frames,‏ PA API וכיווני התקפה פוטנציאליים. צמצום הסיכונים לפרטיות הוא בעדיפות גבוהה, ואנחנו מחויבים לפתח פתרונות חזקים שמאזנים בין חדשנות להגנה על המשתמשים. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
זמן אחזור	האם ערך ברירת המחדל של 50 אלפיות השנייה לזמן קצוב לתפוגה של לוגיקה של בידינג של קונה הוא ערך ריאלי?	אנחנו מביעים הסכמה לגבי החששות שהעלו לגבי חוסר עקביות פוטנציאלי בין המפרט לבין התזמון של בקשות הרשת לקבלת לוגיקה של בידינג. אנחנו בודקים באופן פעיל את המפרטים כדי לוודא שהם מדויקים, ובודקים את הגדרות ברירת המחדל האופטימליות של זמן הקצאת הזמן הקצוב כדי לאזן בין הביצועים לבין ההיתכנות. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
מאמרי עזרה	דליפת זמן פוטנציאלית במפרט, שבה אתר יכול להסיק אם מודעה לא עמדה בסף של פרטיות k-anonymity, והשלכות פוטנציאליות על מעקב בכמה אתרים.	אנחנו מבינים את הבעיה שצוינה לגבי דליפת זמן פוטנציאלית. אישרנו שיש אי-התאמה במפרט, ואנחנו נוקטים צעדים כדי לוודא שסטטוס האנונימיות של המודעות נקבע לפני המכרז, כדי למנוע דליפות כאלה. אנחנו מתייחסים לחששות האלה ברצינות ונעדכן את המפרט כך שישקף את השינויים האלה. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	דרכים להטמיע רשימת ספקי SSP חסומים ב-PA API.	אנחנו מכירים בצורך במנגנונים לניהול הגבלות על מודעות על ידי פלטפורמות SSP. אנחנו ממליצים לבחון פתרונות שמעניקים עדיפות לבדיקות במכשיר ומנצלים את המטא-נתונים הקיימים של המודעות כדי להגן על פרטיות המשתמשים תוך שמירה על גמישות. אנחנו מחויבים לעבוד עם מפתחים כדי לזהות את הגישות האופטימליות ב-PA API. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	האם מישהו יכול להורות לדפדפן שלו להעמיד פנים שהוא מבצע קריאה ל-PA API באופן שהאתרים לא יכולים לזהות?	אנחנו מזהים שבצורתו הנוכחית, יכול להיות שאתרים יוכלו לזהות ביטול הסכמה ל-PA API. אנחנו פועלים באופן פעיל על פיצ'רים כמו הצעות מחיר נוספות וטירגוט שלילי, יחד עם עיבוד של פריימים מגודר, כדי לשפר את הפרטיות ולספק אפשרויות ביטול הסכמה שלא ניתן לזהות. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
בדיקת A/B של מצב	תעבורת נתונים במרכז נתונים שמתיימרת להיות טיפול מסוג 1.1.	צוות Chrome אישר עם צוות GAM שהתנועה הזו מסוננת עכשיו מהניסוי. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	היעילות והצדק של ההטמעה של interestGroupBuyers ב-PA API.	אנחנו מודעים לדיון המתמשך לגבי היעילות וההוגנות של השדה interestGroupBuyers במכרזים של PA API. אנחנו מכירים בפשרות שצריך למצוא בין יעילות, פרטיות וצדק בשוק. המוכרים צריכים לנהל את היחסים העסקיים עם הקונים, אבל אנחנו בודקים דרכים לבצע אופטימיזציה של תהליך ההתאמה. התאמות כאלה עשויות לכלול התאמות דינמיות שמבוססות על נתונים בזמן אמת ועל מודלים היברידיים. אנחנו עדיין מחויבים למצוא פתרונות שמעניקים עדיפות לפרטיות המשתמשים ותומכים בסביבת פרסום תחרותית. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	בעיות פוטנציאליות שקשורות לזיכרון ולבהירות של ממשק המשתמש ב-IG ב-Chrome.	אנחנו מבינים את החששות שהעלו לגבי הצגת IGs ב-DevTools. התצוגה הנוכחית משקפת את כל אירועי ה-IG למעקב היסטורי, אבל אנחנו מבינים את הערך של מתן שקיפות ברורה יותר לגבי המצב הנוכחי של אירועי ה-IG השמורים. נבחן אופטימיזציות ושיפורים פוטנציאליים בממשק המשתמש כדי לשפר את התובנות למפתחים. בנושא ניהול זיכרון, ההטמעה של IG נועדה למנוע דליפות זיכרון, אבל אנחנו עוקבים באופן שוטף אחרי השימוש במשאבים ומבצעים אופטימיזציה שלהם. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
מאמרי עזרה	המפרסם המקורי נתקל בשגיאה כשניסה להשתמש בגדלים של מודעות עם שמות ישירות בשדה 'sizeGroup' של הפונקציה 'joinAdInterestGroup'. הם רוצים לדעת אם זו התנהגות מכוונת.	אנחנו מבינים את הערך של ייעול הגדרת המודעות בתוך הפונקציה joinAdInterestGroup. אנחנו פועלים כדי לטפל במגבלה הזו, ואנחנו מתכננים להפעיל את הפונקציונליות הזו בעדכונים עתידיים. השיפור הזה עומד בהתחייבות שלנו לספק למפתחים כלים גמישים ויעילים לניהול מודעות. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
תווית בדיקה שמתבצעת באמצעות Chrome	בקשה לקבל נתונים ישירים לגבי מצב א' לעומת מצב ב' ותוויות מדויקות ב-sendReportTo כדי שנוכל לעקוב אחרי הניסוי באופן עקבי.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
מאמרי עזרה	האם שם הדומיין של המוכר נכלל בבקשות שנשלחות לשרת המהימן של המוכר לצורכי אימות?	אנחנו מאשרים שהפרמטר של שם המארח לא צוין במסמכי העזרה של Protected Audience KV Server API. אנחנו רוצים להבטיח למפתחים ששם הדומיין של המוכר נכלל באופן אוטומטי בבקשות לשרת המהימן של המוכר. הפונקציונליות הזו חיונית לתהליכי אימות מודעות יעילים. עדכנו את המסמכים כדי לטפל בהחמצה הזו, ונמשיך לתת עדיפות לשקיפות ולבהירות עבור קהילת המפתחים. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	שיטות אפשריות שאפשר להשתמש בהן כדי לכלול את שם ה-IG בקריאות למעקב אחר חשיפות של מודעות למטרות דיווח.	אנחנו מחויבים לאזן בין הצורך במנגנוני דיווח חזקים לבין העיקרון הבסיסי של פרטיות המשתמשים. ההכללה של שמות ב-IG במעקב אחר חשיפות של מודעות כפופה לאמצעי הגנה של אנונימיות מסוג k שנועדו למנוע זיהוי של אנשים פרטיים. נמשיך לבחון פתרונות חדשניים לדיווח במסגרת מגבלות הפרטיות האלה. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
מאפיין API	בקשה לשרת המהימן של הקונה לקבל כותרות HTTP של Client Hints.	אנחנו עוקבים אחרי בקשת התכונה הזו כאן.
שימוש ב-API	האם קובץ הענקת הגישה צריך לדרוש את הטעינה של הכותרת Access-Control-Allow-Origin, מכיוון שהיא קובעת את התנהגות החברות ב-IG בדפדפן?	אנחנו מחויבים לפעול בהתאם לשיטות המומלצות לאבטחת אתרים. הדרישה לכותרת Access-Control-Allow-Origin בקובצי הענקת הגישה מבטיחה עקביות עם עקרונות CORS ומונעת חשיפה לא מכוונת של מידע רגיש. אנחנו בוחנים דרכים לבצע אופטימיזציה של התהליך הזה תוך שמירה על רמת אבטחה גבוהה. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	מאפשרים לשרתים של מודעות להתאים אישית נכסי קריאייטיב במסגרת PA API.	אנחנו מבינים את התפקיד ששרתי המודעות יכולים למלא בהתאמה אישית של נכסי קריאייטיב. אנחנו בודקים באופן פעיל פתרונות לשיפור יכולות השרתים של המודעות ב-PA API, כמו המודל 'IG משותף' שבו אפשר לשלב בידינג עם לוגיקה לבחירת נכסי קריאייטיב של מודעות. המטרה שלנו היא לשמור על איזון בין מתן יכולות חזקות ליצירת נכסי קריאייטיב למודעות לבין שמירה על פרטיות המשתמשים. אנחנו מזמינים אתכם לשתף איתנו פעולה ולשלוח משוב כאן כדי שנוכל לפתח את ה-API בהתאם לצרכים של כל בעלי העניין.
בעיית פרטיות	זמינות של מזהים חלופיים (למשל, שימוש במזהים ספציפיים לאתר (RampID, ‏ ID5) בבקשות להצעות מחיר לפי הקשר עלול לפגוע ביעדים של פרטיות ב-PA API על ידי סיוע באיסוף נתונים בכמה אתרים.	אנחנו מבינים את המתח הפוטנציאלי בין מזהים בין-אתרים לבין יעדי הפרטיות של PA API. בעלי האפליקציות יכולים לבחור לשתף מזהים כאלה, אבל העיצוב של PA API נועד ביסודו לנתק את בחירת המודעות מהצורך במעקב בכמה אתרים. אנחנו מחויבים ליצירת סביבה עסקית של פרסום שמתמקדת בפרטיות, ומעודדים מפתחים לתת עדיפות לגישה של PA API. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שמירה במטמון	האם יש דרך למנוע שימוש חוזר בסקריפטים של בידינג במספר מכרזים?	אנחנו מאשרים את התנהגות האחסון במטמון שנצפתה בסקריפטים של הבידינג במסגרת PA API. יש תמיכה במנגנוני מטמון HTTP רגילים, אבל יש אפשרות לשימוש חוזר בסקריפטים במכרזים שונים בגלל התנהגות ההשעיה של המכשיר והעיצוב של מנהלי הבידינג. הצוות שלנו בודק פתרונות שיעזרו לקנייני מדיה לשלוט טוב יותר בשמירת הסקריפטים במטמון כדי לנהל את שיטות הבידינג שלהם בצורה יעילה. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	דיווח מרוכז על פעילות הבידינג בכל ה-IGs של פלטפורמת ניהול שטחי הפרסום, תוך שמירה על פרטיות המשתמשים.	אנחנו נותנים עדיפות לפרטיות המשתמשים בתכנון של PA API. לא ניתן לדווח ישירות על אירועי בידינג ספציפיים בגלל סיכוני מעקב בכמה אתרים, אבל אנחנו מציעים מנגנונים כמו אחסון משותף וצבירה פרטית. כך פלטפורמות ה-DSP יכולות לקבל תובנות מצטברות על פעילות הבידינג, באופן שמגן על פרטיות המשתמשים.
שימוש ב-API	האחזור מ-sendReportTo() ב-reportResult() מתרחש רק ב-94% מהמקרים, בהשוואה לאחזור שמירשם באמצעות forDebuggingOnly.reportAdAuctionWin().	יכול להיות שהן לא יתבצע באותו זמן, אבל ייתכן ששתי כתובות ה-URL יאוחזו בו-זמנית. במקרים מסוימים, ה-worklet של מוכר הרכיב הושמד וצריך לטעון אותו מחדש כדי להריץ את הפונקציה reportResult(). עם זאת, זמן האחזור של לוגיקה הניקוד וזמן הטעינה מחדש של ה-worklet לא משפיעים על זמן הקצאת הזמן של 50 אלפיות השנייה של reportResult(). חשוב לזכור ש-Chrome ישתמש בכותרות של שמירת מטמון כדי להגדיר את התנהגות האחזור במקרים שבהם צריך לטעון מחדש את ה-worklet. כאן אפשר לקרוא מידע נוסף על השלבים במכרז PA.
K-anonymity	בקשה לאישור שהשם של interestGroup לא משפיע על האנונימיות של k בהצגת המודעות.	כדי שנכס קריאייטיב ייחשב כאנונימי לפי k, הקבוצה המורכבת מכתובת ה-URL של הבעלים ב-IG, כתובת ה-URL של סקריפט הבידינג, כתובת ה-URL של הקריאייטיב וגודל המודעה צריכה לעמוד בערך הסף שצוין (k) במהלך תקופת זמן קודמת (w). סטטוס האנונימיות ברמת k מתעדכן מדי פעם (p).
ממשק המשתמש של Chrome	הצעה לספק את סוג ה'חשיפה הפנימית' שמוצעת על ידי הרבה מסגרות של MVC,‏ ORM וכו'. לדוגמה, אפשר להתחיל ברישום פשוט ביומן של אירועים פנימיים נבחרים בחלונית חדשה בקטע Dev Tools --> Application --> Application	אנחנו מדברים על ההצעה כאן ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	כשמצרפים את Dev Tools ל-IG, לא מוצגים רכיבים שקשורים לעדיפות.	טיפלנו בבעיה הזו כאן.
שיפור ממשק ה-API	עדיף לאפשר לשרת המודעות של הקריאייטיב לעקוב אחרי האירועים שלו. האם אפשר להגדיר רשימה של דומיינים מורשים למעקב?	שיתוף ההצעה שלנו זמין כאן, ונשמח לקבל משוב נוסף מהסביבה העסקית.
בקשה להוספת תכונה ל-API	האם אפשר להרחיב את PA API כדי לתמוך בעסקאות מדיה שאינן RTB ולשמור על תרחישים קריטיים של שימוש, כמו הצגת מודעות ו-DCO?	אנחנו מדברים על הבעיה כאן ונשמח לקבל משוב נוסף.
הזמן הקצוב לתפוגה של מכרז של בעל תוכן דיגיטלי	לבעלי תוכן דיגיטלי צריכה להיות שליטה על משך המכרז כדי למנוע אובדן חשיפות, במיוחד בהגדרות של בידינג בכותרת שבהן המודעות נבחרות ברצף.	אנחנו מבינים את החשיבות של מתן שליטה מפורטת לבעלי תוכן דיגיטלי על זמן הקצוב לתפוגה של מכרזים של מודעות. אנחנו בודקים איך להטמיע מנגנון זמן קצוב לכל המכרזים, אולי באובייקט auctionConfig, תוך התחשבות בקפידה במקרים הקיצוניים. מטרת התכונה הזו היא לבצע אופטימיזציה של שיעורי מילוי החשיפות לבעלי תוכן דיגיטלי, ואנחנו נמשיך לשתף פעולה עם הקהילה כדי למצוא את הפתרון הטוב ביותר. אנחנו מדברים על הבעיה כאן ונשמח לקבל משוב נוסף.
שיפור ממשק ה-API	העיצוב הנוכחי של IGs ב-PA API מוביל לגדלים גדולים של מטא-נתונים בגלל כתובות URL ארוכות לעיבוד. הבודקים רוצים למצוא דרך לדחוס את כתובות ה-URL האלה כדי לשפר את היעילות.	אנחנו מבינים את החשיבות של אופטימיזציה של גודל המטא-נתונים ב-IG, במיוחד במכרזים של מודעות שמושפעים מיעילות. לדעתנו, פתרון שמבוסס על תבנית לדחיסת כתובות renderURLs מציע פוטנציאל משמעותי. אנחנו נבדוק בקפידה את עיצובי התבניות המוצעים ונבטיח שכל פתרון שייושם יכלול מנגנונים חזקים למניעת ניצול לרעה, כדי לשמור על יציבות הדפדפן. שיתוף פעולה עם קהילת תקני האינטרנט כדי לפתח את הגישה האופטימלית, תוך התחשבות בשיקולים האלה, עדיין נמצא בראש סדר העדיפויות שלנו. אנחנו מדברים על הבעיה כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	בודקים שמטפלים בפורמטים של מודעות מותאמות אישית רוצים לבצע אופטימיזציה של תהליך המכרז של ארגז החול לפרטיות על ידי אחזור של כמה תוצאות של מודעות בקריאה אחת, כדי להפחית את העומס על הרשת ולשפר את מהירות העיבוד של המודעות.	אנחנו מבינים את החששות לגבי הביצועים של עיבוד מודעות מותאמות אישית בארגז החול לפרטיות. אנחנו מחויבים למצוא איזון בין יעילות לבין הגנה חזקה על פרטיות המשתמשים. הצגת כמה מודעות עם ציונים מלאים עלולה לפגוע בפרטיות, אבל אנחנו בודקים באופן פעיל דרכים לבצע אופטימיזציה של תהליך המכרז. אנחנו שואפים לשפר את התמיכה של PA API בפורמטים של מודעות מותאמות, ולבחון מנגנונים חלופיים לשיפור היעילות תוך התחשבות באילוצים המשמעותיים של ארגז החול לפרטיות בנושא פרטיות. אנחנו מדברים על הבעיה כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	גמישות באופן שבו ניתנות ציונים להצעות מחיר על מודעות ומבוצעת למהן מיון בארגז החול לפרטיות, במיוחד כדי לייצג רמות עדיפות או כללים של זירת מסחר פרטית.	אנחנו מבינים את הצורך בשליטה מפורטת על הניקוד והמיון של המודעות בארגז החול לפרטיות, במיוחד בתרחישי בידינג מורכבים. אנחנו מאשרים את הפתרונות המוצעים שמשתמשים בקבוצות של ערכים (tuples) ובפונקציות מתמטיות כדי לקבל ניקוד בממדים מרובים בלי לפגוע בפרטיות המשתמשים. הגישה הזו עשויה להוסיף מורכבות למפתחים, אבל היא מספקת את היכולת לבטא את הצורך הנדרש. אנחנו מחויבים למצוא דרכים לייעל את התהליכים האלה, אולי באמצעות פונקציות עזר או הנחיות, כדי להבטיח שימוש אופטימלי בתכונות של ארגז החול לפרטיות לצורך לוגיקה מתקדמת של מכרזים. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
reportEvent()	מוסיפים אירוע חדש ששמור (אולי משואה אוטומטית) שמופעל על ידי הדפדפן ברגע שמתבצעת האינטוליזציה של מסגרת עם קריאייטיב של מודעה.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
adCost	מתן אפשרות לפירוט של adCost.	כל ערך עלות הוא הזדמנות לשלוח כמות מוגבלת של מידע מחוץ למכרז. מתן הרשאה לשלוח רשימה מלאה של N מהעלויות האלה מספיקה כדי לשלוח מזהה משתמש מלא, שיאפשר מעקב בכמה אתרים. אנחנו מדברים על זה כאן ונשמח לקבל משוב נוסף.
resolveToConfig	האם צריך להעביר בירושה את resolveToConfig מהרמה העליונה ולהציג אותו ב-browserSignals?	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף.
כלים משופרים	האם יש משהו שדומה לכתובת chrome://topics-internals אבל ל-PA API?	אין דבר שדומה בדיוק לזה. עם זאת, יש כלים נרחבים למפתחים ל- PA API.
תוויות	האם Chrome יכול להשתמש בתוויות כדי לזהות את 20% מהמשתמשים ב-k-anon?	אנחנו שוקלים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית.
מאמרי עזרה	האם נכסי ה-worklet של מכרזים בארגז החול לפרטיות יהפכו לסוגי worklet רגילים?	בגלל דרישות פרטיות ואבטחה ייחודיות, רכיבי ה-worklet האלה שונים באופן משמעותי מסוגים רגילים של רכיבי worklet בדפדפן, ולכן אנחנו לא צופים שהם יהפכו בקרוב לסוגי worklet רגילים במפרט HTML. אנחנו מחויבים לשפר את המשאבים למפתחים שלנו ולהוסיף להם הסברים ברורים על סביבת ההטמעה וההפעלה של רכיבי worklet של מכרזים, כדי שהמידע הזה יהיה נגיש יותר למשתתפים ב-Privacy Sandbox. כאן מוסבר בהרחבה על הנושא הזה.
שרת מפתח/ערך (KV) מסוג 'הבאת השרת שלך' (BYOS)	צדדים עשויים להיות מסוגלים ללמוד על כמה IGs (מאותו הבעלים) שהמשתמש הצטרף אליהם באמצעות שאילתות של שירותי KV בהגדרה של שירות KV ב-BYOS.	זה לא יהיה אפשרי יותר כששרתי KV יפעלו ב-TEEs, ואנחנו נוכל לוודא שהם יכולים לציית למודל האמון שפורסם.
userBiddingSignals	לעדכן חלק מה-'userBiddingSignals' תוך שמירה על אחרים.	אפשר לעשות זאת כבר עכשיו בלי שצריך לבצע שינויים ב-API.
שימוש ב-API	הטמעת מכסת תדירות בכמה מודעות IG בתוך ארגז החול לפרטיות, אפשר גם באמצעות שרת KV או נתונים משתנים של 'prevWinsMs'.	אנחנו מבינים את הרצון שלכם לקבל יכולות מתקדמות של הגבלת תדירות בארגז החול לפרטיות. אנחנו מבינים שהמגבלות הקיימות על שיתוף נתונים בין חשבונות IG יכולות להוות אתגרים בהטמעת האסטרטגיות האלה. שרת ה-KV מספק מנגנון פוטנציאלי עם אמצעי הגנה מתאימים על הפרטיות, אבל אנחנו ממליצים למפתחים לבחון פתרונות במודל IG יחיד. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	למוכרי רכיבים (אלה שמשתתפים במכרזים בתצוגת עץ בארגז החול לפרטיות) צריכה להיות גישה למידע על זמן הקצאת הזמן הקצוב למכרזים ברמה העליונה, כדי לבצע אופטימיזציה של ההגדרות שלהם ולהימנע מעיכובים מיותרים.	אנחנו מבינים את הצורך בשיפור התיאום של זמן הקצוב לתפוגה בין מוכרים ברמה העליונה למוכרים של רכיבים בתוך ארגז החול לפרטיות. אנחנו בודקים באופן פעיל את הוספת מנגנוני זמן קצוב חדשים, כולל זמן קצוב פוטנציאלי למכרז כולו, ובודקים דרכים להחיל זמן קצוב ברמה העליונה על מכרזים של רכיבים. המטרה שלנו היא לשפר את היעילות והחזאות התוצאות לכל המשתתפים בתהליך המכרז של ארגז החול לפרטיות. אנחנו מדברים על הבעיה הזו כאן ונשמח לקבל משוב נוסף.

שירותי Protected Audience

נושא המשוב	סיכום	תגובה מ-Chrome
סביבות מחשוב מהימנות (TEE)	האם ריצה של TEEs בעננים ציבוריים יקרה יותר מאשר במרכזי נתונים מקומיים של טכנולוגיות פרסום?	התשובה שלנו דומה לתשובות שלנו ברבעונים קודמים: מודל האבטחה הנוכחי של TEE נהנה מהשיטות של הטמעות בענן הציבורי. באופן ספציפי, סביבות TEE מבוססות-חומרה לא מגינות מפני כל ההתקפות הפיזיות. ספקי הענן הציבורי הנתמכים הקיימים שלנו, AWS ו-Google Cloud, תכננו והטמיעו אמצעי מיטיגציה לסיכוני גישה פיזית, כולל מצד עובדים. פרטים נוספים על תמיכה בארגון מופיעים בהמשך. מומחים בתחום טכנולוגיות הפרסום ציינו לנו שהפעלת שירותי ענן יקרה יותר ממרכזי נתונים של טכנולוגיות פרסום בארגון. אנחנו לא יכולים להעריך את ההצהרות האלה, אבל נשמח לקבל משוב נוסף על העלויות. אנחנו ממשיכים לבדוק אפשרויות להרחבת התמיכה שלנו ב-TEE.
TEEs	תמיכה ב-TEE בסביבות ענן לא ציבוריות	התשובה שלנו דומה לתשובות שלנו ברבעונים קודמים: אנחנו ממשיכים לבדוק אפשרויות תמיכה מעבר לפתרונות מבוססי ענן ציבורי, אבל אין לנו כרגע תוכניות לתמוך ב-TEEs בארגון. בשלב הזה, בהתאם לדרישות האבטחה של ארגז החול לפרטיות ולאתגרים המשמעותיים שמציגות פריסות בארגון, אנחנו מאמינים שהדרך הטובה ביותר לשפר את הסביבה העסקית היא להמשיך להרחיב ולשפר את הפריסות מבוססות-הענן (לדוגמה, תמיכה ב-Google Cloud בנוסף ל-AWS). עם זאת, נשמח לקבל משוב נוסף לגבי הסיבות לכך שדרישה כזו נדרשת ומתאפשרת, בהתחשב במגבלות הפרטיות והאבטחה.
ספקי שירותי ענן אחרים	תמיכה בספקים אחרים של שירותי ענן	אנחנו תמיד פתוחים להצעות לגבי ספקי ענן אחרים, אבל אנחנו מתכננים לתמוך לפחות ב-Google Cloud וב-AWS כשהכלל 3PCD יופעל. מידע נוסף זמין במאמר ההסבר הזה.
B&A Services API	מהי הכיוון של Google לגבי B&A Services API? האם העדיפות שלו תהיה מעל או מתחת לקהל המוגן בדפדפן Chrome במכרזים למכשירים?	התשובה שלנו דומה לתשובה שנתתם ברבעונים קודמים: אנחנו עדיין מחויבים לתכנון הנוכחי של הבידינג במכשיר עם קהלים מוגנים. השירותים של B&A הוצעו כדי לבחון פתרונות אפשריים לתמיכה בקבוצת משנה של תרחישים לדוגמה שבהם יכול להיות שהעוצמה המחשובית או מהירות הרשת של המכשיר מוגבלות.
סטנדרטיזציה	שירותי B&A לא עברו תהליך סטנדרטיזציה.	ההצעה לשירותי B&A נמצאת באמצע שלב אחד בתהליך התקינה, ואנחנו מקדמים בברכה מעורבות נוספת כדי לתמוך ביעד הזה. היא התחילה בהצעה (על סמך הצעות קודמות), היא מתפתחת באופן ציבורי באמצעות דיון פתוח נרחב ב-W3C, ומפתחים מעוניינים יכולים להתחיל להתנסות בה ולספק משוב. זהו התבנית הרגילה לפיתוח תכונות אינטרנט, כפי שמתואר למשל בפוסט בבלוג שלנו כאן.
שרת KV	חשיפת כתובת ה-URL המלאה לשרת ה-KV של הקונה לצורך טירגוט לפי תוכן, לפי הקשר או לפי אתר.	אנחנו מדברים על הבקשה הזו כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
מאמרי עזרה	המסמכים בנושא 'רכיבים מהימנים/מאולצים לעומת רכיבים אופציונליים' ב-GitHub יוצרים בלבול אצל חלק מהטכנאים של מודעות שיש להם קבוצה משלהם של תמונות פריסה ותשתית.	אנחנו רוצים לשפר את המסמכים בנושא 'רכיבים מהימנים/מאולצים לעומת רכיבים אופציונליים', ואשמח לשמוע מהסביבה העסקית אם יש צורך לתת עדיפות לעבודה כזו.
שיפור ממשק ה-API	קוד מצב ה-HTTP של קריאה לשרת KV צריך להיות זמין גם לפונקציה scoreAd() כפרמטר.	אנחנו בודקים את הבקשה הזו ונשמח לקבל משוב נוסף מהסביבה העסקית.
מאמרי עזרה	יש לספק מידע נוסף על האופן שבו עומסי העבודה של JS ו-WASM יטופלו בדיוק באמצעות ביצוע UDF.	אנחנו בודקים את האפשרות לספק את המידע הזה, ונשמח לקבל משוב נוסף כאן.
מאמרי עזרה	שליחת בקשה לעדכון השם של המאגר.	שינינו את שם המאגר ל-'protected-auction-key-value-service'. השם הזה תואם למונח של אוסף השירותים שאליו הוא שייך, שכולל גם מאגרים אחרים, כמו הדיון בנושא שירותי קהל מוגנים ומאגרי המסמכים של שירותי מכרזים מוגנים.
מאמרי עזרה	מסירים את ההפניה ל-Cloud debugger API בקובץ bidding_auction_services_gcp_guide.md.	עדכנו את המסמכים והסרנו את ההפניה.
שימוש ב-API	זמן האחזור שנגרם מחיפוש המפתח-ערך נמשך יותר מ-50 אלפיות השנייה. התהליך נמשך כמעט 100 אלפיות השנייה. האם יש לך הנחיות לגבי מה שעובד טוב אצל מוכרים אחרים? יש לך הצעות למדידת הזמן הקצוב לתפוגה והתזמון?	הקריאה לשרת ה-KV מתבצעת בהקשר של Script Runners, כלומר הסביבה המוגנת המיוחדת בתוך דפדפן Chrome. המטרה שלו היא להגן על המידע במפעילי הסקריפטים האלה מפני גישה שאינה של API. הסבר מפורט זמין כאן.
שימוש ב-API	האם יש זמן קצוב לתפוגה של השרת של KV כדי להגיב בזמן מסוים?	מוכרים יכולים לציין את השדה 'perBuyerCumulativeTimeouts' בהגדרות המכרז. הזמן הזה כולל את הזמן הדרוש לאחזור אותות בידינג מהימנים.
זמן אחזור	איך הצוות של ארגז החול לפרטיות עובד על פתרון הבעיה של זמן האחזור?	כאן מפורטות האסטרטגיות שאנחנו בודקים כדי לשמור על זמן האחזור בגבולות מקובלים.

מדידת מודעות דיגיטליות

דוחות שיוך (Attribution) (וממשקי API אחרים)

נושא המשוב	סיכום	תגובה מ-Chrome
אופטימיזציה ידנית של קמפיינים	אין תמיכה ב-ARA באופטימיזציה ידנית של קמפיינים.	דנו בתרחיש הזה עם חברת טכנולוגיית הפרסום והראינו דרכים שבהן אפשר להשתמש ב-ARA כדי לתמוך באופטימיזציה ידנית של קמפיינים. ARA נוצר כך שיאפשר התאמה אישית של טכנולוגיית הפרסום וגמישות לפתרון מגוון תרחישים לדוגמה של טכנולוגיית פרסום. כמה מההצעות שסופקו כללו שימוש בהגדרות גמישות שונות ברמת האירוע, ושימוש בדוחות ברמת האירוע עם דוחות סיכום כדי לצמצם את ההשפעה של רעשי רקע ולעמוד בצורכי האופטימיזציה הידנית והאוטומטית שלהם. אנחנו פתוחים למשוב נוסף מהסביבה העסקית לגבי ההתאמה האישית והגמישות של הגדרות ARA.
סוג ההמרה	Google מאפשרת רק שמונה סוגי המרות, וזה מגביל.	הטמענו את רוב הדיווח הגמיש ברמת האירוע, שמעניק לטכנאי הפרסום גמישות נוספת מבחינת מספר חלונות הדיווח, מספר דוחות השיוך וקטעי נתוני הטריגר שבהם הם יכולים להשתמש. טכנאי הפרסום יכולים לבחור הגדרה שמאפשרת למדוד עד 32 סוגי המרות שונים.
מגבלת האירועים בדוח שאפשר לצבור	המספר המינימלי של אירועי המרה לדוח שאפשר לצבור הוא 20, וזה לא מתאים למפרסמים קטנים עם תקציב מוגבל.	אין מספר מינימלי של אירועי המרה שנדרש לכל דוח שאפשר לצבור. בנוסף, יש כמה החלטות תכנון שאפשר לקבל כדי לבצע אופטימיזציה של דוחות שאפשר לצבור למפרסמים קטנים יותר, כמו שינוי המבנה של המפתחות או המאפיינים שאחריהם מתבצע מעקב, בדיקה של רמות שונות של אפסילון, בדיקה של תדירויות ארוכות יותר של צבירה וחלוקה של תקציב לפי תרומה בין יעדי המדידה. טכנולוגיות פרסום קטנות יותר יכולות גם להתנסות בשילוב של דוחות ברמת האירוע ודוחות סיכום, כדרך לצמצם את ההשפעה של רעש.
נתונים בזמן אמת	מניעת נתונים בזמן אמת (למשל, על קליקים, סשנים והמרות) מ-DSP, שבהם פלטפורמות ה-DSP משתמשות כדי להתאים את שיטת הבידינג שלהן ולשפר את היעילות של הקמפיינים, מנוגדת להתחייבות שלנו לשמור על הפונקציונליות הקיימת.	גם עם ARA, הקליקים והסשנים נשארים בזמן אמת, וההמרות תמיד מתועדות בדיעבד, גם עם 3PC.
שדות חסרים	דרישות שלא מולאו בהשקה של אירועים עם גמישות מלאה: 1) שדה מטבע, 2) שדה orderID או TransactionID.	אנחנו לא מתכננים כרגע לתמוך בשדה מטבע או בשדה מזהה הזמנה / מזהה עסקה כחלק מרמת אירוע גמישה מלאה, כי כבר יש דרכים לעשות זאת בדוחות הנוכחיים ברמת האירוע. אנחנו פתוחים למשוב נוסף לגבי השדות האלה, ונשקול מחדש אם יהיו תרחישי שימוש נוספים שבהם הם נדרשים. הדרכים שבהן אפשר להשתמש בתכנון הנוכחי של ARA כדי למדוד מידע מסוג מטבע ומספר הזמנה: 1. על סמך המשוב, המטבע נקבע לפי המיקום הגיאוגרפי של המשתמש, שאפשר להוסיף כחלק מ-source_event_id כדי לקבוע באיזה מטבע נעשה שימוש. 2. על סמך המשוב, השדה 'מזהה הזמנה' נדרש כדי להבטיח שההמרות והערכים לא ייספרו כפול בטעות. אפשר לעשות זאת באמצעות מפתחות להסרת כפילויות.
מכסת פרטיות	תקציב הפרטיות של ARA מגביל את היכולת למדוד במספר מאפיינים	ARA תוכנן כך שתטכנאי הפרסום יוכלו להתאים אישית את ההגדרות שלו כדי לכסות מגוון תרחישים של שיוך. בעיצוב הנוכחי של ARA, מומחי טכנולוגיות הפרסום יצטרכו לחשוב על הפשרה בין המאפיינים החשובים ביותר למדידה לבין ההשפעה של הרעש על הנתונים שלהם. הוספת רעש לנתונים בהתאם לרמת הפירוט של המאפיינים שנמדדים חיונית לשמירה על הפרטיות. אנחנו פתוחים למשוב נוסף על הסביבה העסקית בנוגע ליכולת למדוד מאפיינים שונים, אבל נצטרך להבין את תרחישי השימוש הספציפיים שבהם יש צורך בכך.
עדכון המפרט	Google הודיעה שהיא עברה מחלונות דיווח קבועים על אירועים לחלונות גמישים, אבל זה לא בא לידי ביטוי במפרטים הטכניים של Google, שבהם עדיין מופיע חלון מינימלי של שעה אחת.	דיווח גמיש ברמת האירוע מאפשר כרגע לטכנאי הפרסום לשנות את מספר דוחות השיוך לכל אירוע מקור, את הביטים של נתוני הטריגר ואת מספר חלונות הדיווח או את אורך שלהם. ל-ARA עדיין יש חלון דיווח מינימלי של שעה אחת לדוחות ברמת האירוע, שנחוץ כדי לשמור על הפרטיות ולצמצם את הסיכון לסוגים מסוימים של התקפות לשחזור היסטוריה. מכיוון שדוחות הסיכום מספקים מידע מצטבר, ספקי טכנולוגיות הפרסום יכולים להביע הסכמה לקבל דוחות שניתנים לצבירה באופן מיידי וללא עיכוב, אם יש צורך בתרחישי השימוש שלהם.
תכנון ממשקי API	חשש שהקטנת המידע בדוחות ההמרות והוספת רעש עלולים להשפיע על הסביבה העסקית יותר מאשר על Google.	Google התחייבה בפני CMA לתכנן ולהטמיע את ההצעות של ארגז החול לפרטיות באופן שלא יפגע בתחרות על ידי מתן עדיפות לעסק של Google, ולקחת בחשבון את ההשפעה על התחרות בפרסום דיגיטלי ועל בעלי תוכן דיגיטלי ומפרסמים בכל הגדלים.
תיקון שיוך	ARA לא מאפשרת לספק הטכנולוגיה לשלוט ולאמת את השיוך הנכון.	יש פתרונות רבים ב-ARA שמספקים יכולות אימות: 1. טכנאי הפרסום יכולים לוודא שההתנהגות של ARA תואמת לציפיות שלהם: – הקוד בצד הלקוח של ARA הוא קוד פתוח. – הקוד בצד השרת של ARA הוא גם קוד פתוח, והתיאום מוודא שרק גרסאות מותרות של Aggregation Service יכולות לפענח ולעבד דוחות שניתנים לצבירה. 2. ב-Chrome הוספנו ספריית סימולציות לטכנולוגיות פרסום כדי לאמת את התנהגות השיוך. הטכנולוגיות האלה יכולות להשתמש בספרייה הזו כדי לבדוק איך מתבצע השיוך ב-ARA בסביבה מדומה. 3. ARA תומך במספר אותות לניפוי באגים שיעזרו לכם לוודא אם העיבוד הצפוי התרחש או לא, ואם לא, למה.
(דווח גם ברבעונים קודמים) רעש	משוב על כך שרמת הרעש גבוהה מדי והיא משפיעה על השימושיות של הדיווח.	דיברנו עם טכנאי פרסום ששלחו את אותו משוב, והצלחנו לזהות דרכים להתאמה אישית של ARA כך שיתאים טוב יותר לתרחישי השימוש שלהם, גם עם רעש. יש לנו מסמכי עזרה למפתחים שמכילים את רוב ההחלטות לגבי העיצוב וההתאמות אישיות שדנו בהן עם מומחי טכנולוגיית הפרסום. ARA תוכנן כך שמומחי טכנולוגיית הפרסום יוכלו להתאים אישית את ההגדרות שלו כדי לכסות מגוון תרחישים של שיוך (Attribution). עם זאת, מומחי טכנולוגיות הפרסום יצטרכו לחשוב על האיזון בין המאפיינים שהכי חשוב להם למדוד לבין ההשפעה של הרעש על הנתונים שלהם. אנחנו פתוחים למשוב נוסף מהסביבה העסקית בנוגע להשפעת הרעש, ואנחנו יכולים לספק הנחיות נוספות לגבי אמצעי בקרה ל-ARA שאפשר להשתמש בהם כדי לשנות את ההשפעה של הרעש.
שיוך בכמה דומיינים	איך עוקבים אחרי השיוך (Attribution) בכמה דומיינים?	טכנאי הפרסום יכולים להפנות לכתובות URL שונות לדיווח כדי לפתור את התרחיש לדוגמה הזה. אנחנו פתוחים למשוב נוסף מהסביבה העסקית לגבי היבט העיצוב הזה של ARA.
שיפור ממשק ה-API	מומלץ לשנות באופן קבוע את גורם ההתאמה שמשומש בזמן רישום השיוך בדוחות הסיכום של ARA.	על סמך הדיון ב-GitHub, נראה שהטיפול בכמה גורמי התאמה ב-Aggregation Service יוביל ככל הנראה להוספה של כמות גדולה יותר של רעשי רקע לדוחות הסיכום בהשוואה לפונקציונליות הנוכחית. אנחנו פתוחים למשוב נוסף לגבי הצורך בגורמי התאמה כחלק מדוחות שאפשר לצבור, אבל חשוב לנו לציין את הפשרה הפוטנציאלית של הוספת רעשי רקע. אנחנו גם בודקים אם תכונות ARA עתידיות אחרות יכולות לעזור לפתור את התרחיש לדוגמה הזה.
שימוש ב-API	הזדמנות לאחד את האופן שבו אירועי שיוך משותפים עם כל המשתתפים, דבר שמועיל ל-SSP, ל-DSP וכו'.	אנחנו מתכננים לסנכרן עם ספקי טכנולוגיות הפרסום כדי להבין טוב יותר את המשוב שלהם ואת המגבלות שהם נתקלים בהן.
נפח התנועה לבדיקה	האם תנועת הבדיקה של מצב ב' בכל הגרסאות של Chrome יציבה?	ההכללה בקבוצת ניסוי לא מושפעת מההגדרות של Chrome (לא תלויה בהן).
מאמרי עזרה	תמיכה ב-ARA ל-Pixel.	פרסמנו מידע על האופן שבו אנחנו תומכים בתרחיש לדוגמה הזה, ונשמח לקבל משוב נוסף מהסביבה העסקית.
שימוש ב-API	יכול להיות שהמערכת לא תשייך המרות מסוג ARA למקור הנכון עבור מוכרים של צד שלישי בפלטפורמות מסחר אלקטרוני, אם ההמרה לא מתבצעת במגע האחרון.	חברות יכולות להשתמש במסננים כדי למנוע שיוך שגוי (כלומר, לא ייוצר דוח המרות). אנחנו גם עובדים על הצעה לסינון לפני שיוך כדי לעזור בתרחישים לדוגמה כאלה.
תמיכה בדפדפנים	האם תהיה תמיכה ב-ARA בדפדפנים שונים?	אנחנו מזמינים דפדפנים אחרים לאמץ את ממשקי ה-API של ארגז החול לפרטיות, וממשיכים להקדיש זמן לדיון בגישה שלנו באופן פתוח ב-W3C. צייננו במפורש שאחד היעדים של השקת ARA הוא יכולת פעולה הדדית, והעיצוב של ARA נועד להיות בלתי תלוי בדפדפן, עם ערכים גמישים שספקים יכולים לציין עבור ספקים עם עמדות שונות בנושא פרטיות. דפדפנים אחרים מקבלים החלטות משלהם לגבי האפשרות לספק חלופות קיימות למזהים באתרים שונים שיכולים לתמוך בסביבה הדיגיטלית של תוכן ושירותים. אנחנו שמחים לשמוע ש-Microsoft Edge ציין שהוא יתמוך ב-RA.
שימוש ב-API	מהו סוג המקור הצפוי לרישומי מקורות של ARA עבור registerAdBeacon/reportEvent (ו-navigation_start/commit beacons אוטומטיים)?	זה תלוי אם המשׂואות הרשת האלה אוטומטיות או ידניות: - שמור.* אירועים (כלומר אוטומטיים) מסוג 'מקור ניווט'. - אירועים שמופעלים באופן ידני צריכים להיות מסוג 'מקור אירועים'.
שימוש ב-API	האם המגבלה המקסימלית של 20 דוחות שאפשר לצבור לכל מקור מתייחסת לכל אירוע מקור? האם המגבלה היא גלובלית או יומית? האם יש תוכנית להגדלת המגבלה?	המגבלה של 20 דוחות שאפשר לצבור לכל מקור היא מגבלה גלובלית, וניתן ליצור 20 דוחות שאפשר לצבור לכל מקור. המגבלה מוגדרת על ידי הדפדפן ואי אפשר לשנות אותה. המטרה של המגבלה הזו היא למנוע ניצול לרעה של ההגנה על דוחות שיוך אמיתיים באמצעות דוחות null. כאן מוסבר בהרחבה על הנושא הזה.
שימוש ב-API	תמיכה בשיווק באימייל באמצעות ARA.	בשלב הזה אין תמיכה ישירה בתרחיש השימוש הזה ב-ARA (אם אתם לא שולטים באתר לאירוח האימייל). אנחנו מדברים על זה כאן ונשמח לקבל משוב נוסף.
Epsilon	מתי נקבע הערך של epsilon עבור Aggregate API?	ספקי טכנולוגיות הפרסום יכולים להגדיר את ערך האפסון הנוכחי עד לסף מוגדר מראש שהוגדר על ידי ארגז החול לפרטיות (הערך הנוכחי הוא 64). מומלץ לבדוק ערכים שונים של אפסון ולזהות נקודות מפנה בתרחישי לדוגמה שלכם, ולשלוח משוב. אנחנו נוודא לעדכן את הטכנאים של מודעות מראש לפני שנעשה שינויים בטווח של ערכי האפסילון.
שיפור ממשק ה-API	תמיכה בתרחיש לדוגמה שבו המפרסם יכול להוסיף מזהה לשדה trigger_data לצורך התאמה לנתוני CRM חיצוניים, כדי לאפשר למפרסמים לאמת את איכות ההמרות.	אנחנו דנים בבקשה ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	איך מטפלים בכתובות URL להפניה אוטומטית ככתובות URL של יעד.	טכנאי הפרסום יכולים לבצע אחת מהפעולות הבאות: 1. מזינים את כתובת ה-URL הסופית של היעד בשדה היעד, 2. בשדה היעד אפשר להזין עד 3 כתובות URL, כך שאפשר להזין כמה כתובות URL בשדה. בשני המקרים, צריך לדעת מהי כתובת היעד הסופית. כאן מוסבר בהרחבה על הנושא הזה.

Aggregation Service

נושא המשוב	סיכום	תגובה מ-Chrome
מנגנון לגילוי מפתחות	בקשה למנגנון לגילוי מפתחות	יש לנו הצעה לגילוי מפתחות, ונשמח לקבל משוב מהסביבה העסקית לגבי ההצעה.
שימוש ב-API	מפת דרכים לניראות ב-Aggregation Service	אנחנו בודקים אפשרויות להרחבת יכולת התצפית, ונשמח לקבל משוב מהסביבה העסקית כאן.
שיפור ממשק ה-API	בקשה לאפשרות לשלוח שאילתות חוזרות לדוחות.	צוות שירות האגרגציה עובד על הצעה לשליחת בקשה מחדש, שבה טכנאי הפרסום יוכלו לפצל את הערך של epsilon לכל דוח. הפעולה הזו עלולה להגדיל את רמת הרעש בכל שאילתה, אבל היא תאפשר לטכנאי הפרסום לשלוח שאילתה חוזרת ולשמור על הפרטיות.
שיפור ממשק ה-API	רוצים לשייך כמה מקורות לאותו מזהה AWS.	מעכשיו, שירות הצבירה יאפשר להוסיף כמה אתרים לאותו חשבון ענן (Google Cloud או AWS). כך טכנאי הפרסום יוכלו להשתמש באותו נספח של שירות האגרגציה לעיבוד דוחות מכמה אתרים וממספר מקורות באותו אתר.
שימוש ב-API	כשאוספים קבוצות של בקשות שתואמות לאגרגציה, לא ברור אם התקציב נצרך או לא, ואם אפשר לעבד מחדש את הקבוצה. כששירות צבירת נתונים נתקל בשגיאת תקציב בדוחות כפולים, שאר הדוחות הולכים לאיבוד. איך אפשר לצמצם את האובדן הזה?	בתרחיש טיפוסי, אם כל המשימה נכשלת, התקציב לא ינוצל. במקרים נדירים של כשל שבו התקציב נוצל, מומחי הפרסום יכולים לבקש שחזור תקציב. אם מומחי הפרסום נתקלים בכשל תכופים של משימות עם השגיאה 'התקציב נוצל', הם צריכים לוודא את אסטרטגיית האצווה שלהם. כאן מוסבר איך ליצור קבוצות בצורה נכונה ולהימנע מדוחות כפולים ושגיאות. אנחנו מזמינים אתכם לשלוח לנו משוב על שחזור התקציב כאן.
שימוש ב-API	שימוש ב-Private Aggregation API עם הטריגר שמתואר כאן ייצור דוח שניתן לצבור מכל מכרז. מהן יכולות ההתאמה לעומס של Aggregation Service?	שירות הצבירה עצמו לא מגביל את מספר המפתחות או הדוחות בקבוצה, אבל כרגע אין תמיכה בהיקף של 10^14 דוחות ו-10^12 מפתחות בגלל כמות הזיכרון הנדרשת. ההנחיות שלנו לקביעת הגודל מצביעות על טווחי הגודל שבדקנו ואנחנו ממליצים עליהם לקבלת ביצועים אופטימליים, בהתאם לעומס הצפוי ולסוגי המכונות הווירטואליות הנתמכות בענן.
עיבוד נתונים	אם נתונים מוצפנים מכילים מידע אישי, מהם ההסדרים המשפטיים של העברת נתונים מוצפנים לשירות האגרגציה? האם מובטח שהרכז לא יקבל גישה לנתונים מוצפנים?	שירות האגרגציה לא משתף נתונים מוצפנים או נתוני משתמשים עם התאמת. שירות Aggregation משתמש במרכז התאום לניהול ולחשבון של מפתחות. כאן אפשר למצוא פרטים נוספים על התאמת הבקשות. לצורכי חשבונאות, שירות האגרגציה משתף עם PBS רק את המזהה המשותף ואת מקור הדיווח לצורך שימוש בתקציב. אחרי ההשקה של 'אתרים מרובים', נחליף את המקור באתר. שימו לב ששירות האגרגציה פועל בסביבת TEE, שהיא המקום היחיד שבו אפשר לפענח דוחות מהלקוחות. הקוד שפועל ב-TEE הוא בקוד פתוח ונבדק על ידי גורמים חיצוניים, כפי שמתואר כאן.

Private Aggregation API

נושא המשוב	סיכום	תגובה מ-Chrome
שימוש ב-API	היכולת של מוכרי רכיבים לשלוח דוחות למספר שרתי צבירת נתונים בתוך TEE.	סטטוס Private Aggregation API הנוכחי לא תומך בתכונה הזו. כאן פירטנו את הנושא הזה.
מאמרי עזרה	מהו ערך האפסילון שמשמש בניסויים של Google?	ב-Private Aggregation API, ערך ε שצוין בשאילתה של שירות צבירת נתונים תואם לתקציב התרומה ברמה L1 של 2^16, שחלה על בסיס מצטבר של 10 דקות. יש גם תקציב 'גיבוי' של 2^20 לתרומות ברמה L1, שמופעלת על בסיס גלילי של 24 שעות. במילים אחרות, פרמטר הפרטיות הוא ε על בסיס 10 דקות מתגלגל, והוא 16ε על בסיס 24 שעות מתגלגל (במקום 144ε). שירות הצבירה תומך כרגע במגוון ערכים של ε לצורך בדיקה (עד 64) כדי לאפשר ניסוי באסטרטגיות צבירה שונות ולספק משוב על התועלת של המערכת עם פרמטרים שונים של פרטיות עבור Private Aggregation וממשקי API אחרים. אנחנו מתכננים לבדוק מחדש את ערך האפסילון המקסימלי המותר עם הזמן, ככל שנקבל משוב מהבודקים ונוסיף תכונות שיאפשרו שימוש יעיל יותר בתקציב הפרטיות.

הגבלת מעקב סמוי

הפחתת מידע בסוכן משתמש/רמזים על הלקוח (Client Hints) לגבי הסוכן המשתמש

לא התקבל משוב ברבעון הזה.

הגנה על כתובת ה-IP (לשעבר Gnatcatcher)

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

הקלה במעקב אחר עזיבה מהדף הראשון

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

מכסת פרטיות

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

חיזוק גבולות הפרטיות באתרים שונים

קבוצות של אתרים קשורים (לשעבר 'קבוצות מאינטראקציה ישירה')

נושא המשוב	סיכום	תגובה מ-Chrome
בקשה לתכונה	המערכת מאפשרת גישה אוטומטית ל-CHIPs או לחלוקת אחסון ב-RWS, ללא צורך ב-Storage Access API או באינטראקציה עם משתמשים.	אנחנו שוקלים את היתרונות וההיתכנות של תכונה שעשויה לבצע את הפונקציה הזו. אחד השיקולים הוא פער פוטנציאלי ביכולת הפעולה ההדדית בין הדפדפנים, ש-RWS פותר על ידי ניצול של Storage Access API. אין כרגע תכונה מקבילה לפונקציונליות המבוקשת הזו שנתמכת בדפדפנים אחרים. אנחנו מעודדים מפתחים לשלוח את תרחישי השימוש שלהם בנושא הזה כדי לאפשר דיון כאן.
הסרה של קבוצות לא תואמות	מהו התהליך להסרת קבוצות מהמאגר שהן לא עומדות בדרישות?	אנחנו פועלים כדי להגדיר תהליך לכך, ונשתף עדכונים ברגע שהם יהיו זמינים.
תהליך האכיפה	אין בהירות לגבי התפקיד הסובייקטיבי של Google בתהליך האכיפה של RWS.	RWS הוא פרויקט מתמשך ואנחנו ממשיכים לקבל בקשות חדשות, ולכן עדיין יש היבטים בתהליך והקריטריונים שלנו שאנחנו ממשיכים לחדד. אנחנו מסכימים שחשוב להציג בהנחיות לשליחת בקשות את הדרישות שלנו לשליחת בקשות באופן מלא, ונעלה את רמת הפירוט בהנחיות לשליחת בקשות בהמשך כדי למנוע אי-בהירות ובלבול. הכוונה שלנו היא שתהליך שליחת הבקשות יהיה טכני ככל האפשר, כדי שנוכל להפסיק בהדרגה את ההתערבות האנושית ולהסתמך לגמרי על בדיקות אוטומטיות. בקשות תמיכה כמו זו מצריכות יותר אינטראקציה אנושית כי הן כוללות התנהגויות שלא צפינו, אבל הן מאפשרות לנו לזהות תחומים נוספים לאוטומציה ודרכים שבהן נוכל לתקן את ההנחיות שלנו כדי למנוע את הבעיות האלה בעתיד.
שיתוף נתונים	בקשה לתכונה שמאפשרת לבעלי דומיינים לציין שהם רוצים שצד שלישי ישתף גם נתוני RWS, בהסכמת המשתמשים.	הפונקציונליות המבוקשת כבר זמינה דרך ממשקי API כמו FedCM וממשקי Storage Access API שמאפשרים גישה לזהות מאומתת אחרי שהמשתמש מאשר בקשת הרשאה. אנחנו מקבלים בברכה משוב מהסביבה העסקית לגבי תרחישי שימוש ספציפיים שלדעתם לא אפשריים.
שיטות אחסון אחרות	האם מידע שנשמר באחסון המקומי או באחסון הסשן יפורש גם כ-3PC?	אחסון מקומי, אחסון בסשן ודרכי אחסון אחרות שאינן קובצי Cookie, כשהן נמצאות בשימוש בהקשרים של צד שלישי, חולקו למחיצות ב-Chrome החל מגרסה 115. פרטים נוספים זמינים בפוסט הזה בבלוג.
מגבלת קבוצות משויכות	מה קורה לארגונים ששולחים יותר מ-5 דומיינים, למרות שהמכסה היא '5 אתרים משויכים'?	הקבוצות האלה יאושרו דרך התהליך ב-GitHub, אבל הדפדפן (Chrome) יחיל את הכללים שלנו להקצאה אוטומטית של Storage Access API רק על 5 הדומיינים הראשונים, ויתעלם מהדומיינים הנותרים, כפי שמתואר כאן.
find_robots_txt	הבדיקה find_robots_txt לא פועלת עם הפניות אוטומטיות.	כאן נשלח תיקון לבעיה הזו.
תנועה של משתמש	הסרת הדרישה לתנועת משתמש כדי להשתמש ב-accessStorage().	הדרישה הזו נקבעה על סמך תכנון דומה שמופעל בכל הדפדפנים העיקריים עבור requestStorageAccess API. אנחנו מזמינים מכם לשלוח משוב נוסף ותרחישי שימוש בבעיה הזו ב-GitHub כדי לעזור לנו לתת עדיפות לבקשה הזו ולאפשר דיונים בנושא בכל הדפדפנים.
תנועה של משתמש	האם נדרשת מחווה של המשתמש כדי להעניק הרשאת גישה לאחסון של צד שלישי לאחר הפעלה מחדש של Chrome או של מערכת ההפעלה?	כן, אבל אנחנו מקבלים בברכה משוב נוסף מהסביבה העסקית לגבי שינוי ההתנהגות הזו. אפשר לשלוח משוב כאן.

Fenced Frames API

נושא המשוב	סיכום	תגובה מ-Chrome
adComponent	חוסר בתיעוד ובגמישות בשימוש ב-AdComponents עם פריימים מוקפים.	אנחנו שוקלים לשתף מסמכים נוספים לגבי התרחיש הזה. בנוסף, רכיבי מודעות נתמכים בפריימים מגודר באמצעות getNestedConfigs()‎, שמתואר במפרט כאן.
(דווח גם ברבעונים קודמים) עיבוד (render) של adComponent	בקשה לקבלת קודי לדוגמה להצגת adComponents ב-Fenced Frame.	אנחנו עובדים על שיתוף כמה קודים לדוגמה כאן.
אימות מודעות של צד שלישי	צריך להוסיף פרטים לגבי התפקיד של אימות מודעות של צד שלישי בהקשר של פריימים מגודר, במיוחד בנוגע לבטיחות בהקשר או לבטיחות המותג.	כיום, דיווח על מודעות במסגרות מוגנות מאפשר ל-DSP לשלוח נתונים ברמת האירוע של חשיפות ומכרזים למאמתי מודעות של צד שלישי לצורך חיוב ובדיקות של הגנה על המותג לאחר העיבוד.
מודעות מתרחבות	בקשה לתמיכה במודעות הניתנות להרחבה.	אם צריך להחליף את גודל המודעה בין שני גדלים באותו יחס גובה-רוחב, ואין הבדל פונקציונלי בין השניים (רק גודל), הגורם שמטמיע את המודעות יכול לשנות את הגודל של המסגרת המגודרת לפי גודל המודעה השני, והדפדפן יבצע שינוי בהתאם לגודל של רכיב המסגרת המגודרת.
(דווח גם ברבעונים קודמים) תמיכה במלאי שטחי פרסום של מודעות וידאו ומודעות מותג	האם מודעות Fenced Frames תומכות במלאי שטחי פרסום של מודעות וידאו ומודעות רגילות?	התשובה שלנו דומה לתשובות שלנו ברבעונים קודמים: PA API תומך ברינדור וידאו באמצעות מנגנון שמסתמך על iframes. עם זאת, עדיין לא פיתחנו פתרון לעיבוד של מודעות וידאו ומודעות מותגות שתואמות למסגרות מוקפות, וזו אחת הסיבות לכך שהחלטנו לדחות את האכיפה של המסגרות המוקפות לשנת 2026. כלומר, אם שותף יחליט לאכוף את התכונה 'פריימים מגודרים' כבר עכשיו, הוא לא יוכל להשתמש בתכונות 'סרטון' ו'מודעות מותג'.
מועצה מייעצת	בקשה ליצירת מועצה מייעצת של ספקי מודעות נתמכות כדי להבטיח שהטמעות של מודעות מוקפות יתבצעו בהתאם לסטנדרטים המקובלים בתחום.	לא תהיה דרישה להשתמש ב-Fenced Frames ב-PA API לפני שנת 2026. הזמן הנוסף יאפשר לנו להמשיך לעבוד עם התעשייה כדי לתכנן ולהטמיע תמיכה במגוון רחב יותר של תרחישים קריטיים לדוגמה. צייננו בעבר שאנחנו נפתח את התכונה 'פריימים מגודר' לפני שהיא תידרש כדי לשמור על תמיכה במודעות וידאו ובמודעות מותג באמצעות PA API. בהתאם להתחייבויות שלנו, נתייעץ עם CMA ונעדכן אותו לגבי שינויים כאלה, ונמשיך לקבל משוב מהסביבה העסקית לפני שנחייב להשתמש בפריימים מגודר. מודל המעורבות שלנו בסביבה העסקית ב-W3C ובארגונים של תקני פרסום כמו IAB Tech Lab מאפשר למומחי ענף מכל הסוגים להנחות את התכנון לפני שהוא נדרש.
(דווח גם ברבעונים קודמים) הבדלים בגודל בין הפלטפורמות	דיווח על כך שגודל התוכן שמוצג ב-Fenced Frame נראה שונה במחשבים ובסמארטפונים.	זו בעיה מוכרת ב-Chromium שאנחנו בודקים. נשמח לקבל משוב נוסף כאן.
שיפור ממשק ה-API	האם הדרישה לגבי פריימים מגודרים נדחתה ל-2025 כדי שתהיה תמיכה במודעות מותאמות עכשיו במסגרת ארגז החול לפרטיות?	כפי שציינו בהודעה הציבורית שלנו על אכיפת פריימים מגודרים לא יאוחר משנת 2026, שמענו על 'מאמצים משמעותיים להתאמה' לפריימים מגודרים. אחת מהן הייתה מודעה רגילה, אבל זה לא היה הגורם היחיד. המטרה הייתה לתת לכם יותר זמן כדי לוודא שהסביבה העסקית מוכנה לתמוך בתרחישי שימוש מרכזיים, כולל, בין היתר, תרחישי שימוש מקומיים.

Shared Storage API

נושא המשוב	סיכום	תגובה מ-Chrome
ביצועים	נראה שזמני ההחזרה של Shared Storage מחוץ ל-worklet תלויים בפעילות ב-worklet.	אנחנו דנים בתוצאת הבדיקה הזו כאן.
אימוץ נרחב יותר	אחסון משותף צריך להיות סטנדרט לכל תעשיית האינטרנט שזמין בכל הדפדפנים.	אנחנו מקבלים בברכה את המשוב הזה ומבינים את החשיבות שלו. אנחנו ב-Chrome ממשיכים להשתתף באופן פעיל בפורומים של W3C, כולל WICG, כדי לקדם את ההצעה, לקבל משוב ולעודד את השימוש בה.
Worklets של בידינג	האם אפשר לקרוא מ-Shared Storage בתוך generateBid (שכבר פועל ב-worklet) כדי להחיל החלטות לגבי מודעות או לוגיקה עסקית (כמו הגבלת תדירות) על סמך מידע ממספר אתרים ולבחור קבוצת משנה של מודעות?	לא, אי אפשר לקרוא מאחסון שיתופי בתוך רכיבי worklet לבידינג.

CHIPS

נושא המשוב	סיכום	תגובה מ-Chrome
קיבולת המחיצה	הבהרה לגבי ההתנהגות כשחורגים מיכולת האחסון של המחיצה.	כשמגיעים לקיבולת, קובצי ה-cookie הישנים ביותר מגורשים מקובצי ה-cookie שנגישו אליהם הכי מעט לאחרונה כדי לפנות מקום בזיכרון עד שהמגבלה לא תושג יותר. המפתחים רואים את כותרת ה-Cookie המעודכנת בבקשות הבאות.
גישה של צד שלישי ל-iFrame	לתוכן iFrame מוטמע של צד שלישי שפותח כרטיסייה או חלון חדשים לאותו אתר של הצד השלישי צריכה להיות גישה לאותם קובצי cookie שמחולקים לקטעים כמו לתוכן שפותח אותם.	אנחנו מדברים על התרחיש הזה ונשמח לקבל משוב נוסף מהסביבה העסקית כאן.
קובצי cookie כפולים	אם יש קובץ cookie מפולח וקובץ cookie לא מפולח עם אותו שם, איזה ערך מפתח הדפדפן מחליט לשלוח?	אם יש שני קובצי cookie עם אותו שם (אחד מחולק למחיצות והשני לא), יוצגו שני קובצי ה-cookie – לצערי, אין דרך להבדיל ביניהם. המפרט של RFC בנושא הזה זמין כאן, ומוסבר בו שאין להסתמך על הסדר שבו קובצי ה-cookie נשלחים.
בקשה לתכונה	להביע הסכמה לשימוש בקובצי cookie עם חלוקה למחיצות לפי מקור.	אנחנו בוחנים את הבקשה הזו ומקבלים בברכה משוב נוסף מהסביבה העסקית כאן.

FedCM

לא התקבל משוב ברבעון הזה.

נלחמים בספאם ובהונאות

Private State Token API (וממשקי API אחרים)

נושא המשוב	סיכום	תגובה מ-Chrome
תצוגת אינטרנט.	האם טוקנים של מצב פרטי (PST) נשמרים במספר תצוגות אינטרנט באותו מכשיר נייד (פרופיל)?	לכל אפליקציה שמשתמשת ב-Webview יהיה אחסון מקומי שונה, כלומר מנפיקי PST לא יכולים להנפיק אסימונים ב-Webview של אפליקציה אחת ולאחר מכן לאפשר מימוש אסימונים באפליקציה נפרדת. אותו הדבר נכון גם לגבי צורות אחרות של נתונים שמאוחסנים באופן מקומי בתצוגות אינטרנט, כמו קובצי cookie. קבצי PST עדיין לא זמינים במלואם ב-WebView. אנחנו צפויים לספק עדכון בנושא הזה עד סוף הרבעון השני.
סוג טוקן חדש	הצעה לסוג חדש של אסימון.	אנחנו מודים לך על ההצעה הזו ועל החקירה המתמשכת של יישומים והתאמות של PST. אנחנו מצפים לקבל מידע נוסף על ההצעה הזו בפגישות הקרובות של קבוצת הקהילה למניעת הונאות ברבעון השני של 2024.
זיהוי משתמשים	איך אפשר למנוע זיהוי של משתמשים על סמך קובצי ה-PST הספציפיים שלהם?	כדי לצמצם את הבעיה הזו, אנחנו מגבילים כרגע את ניסיונות המימוש באתר לשני מנפיקים, גם אם יש אסימונים זמינים מהמנפיק הזה. צריך לספור את המנפיק במסגרת המגבלה גם אם אין אסימונים זמינים, אחרת האתר עלול לעבור על כל המנפיקים עד שיגיע להתאמה חיובית.
הרשמה	למשך כמה זמן יהיה צורך ברישום של PST?	נמשיך לדרוש רישום בעתיד הנראה לעין, כפי שמוסבר בפירוט כאן.
תמיכה בדפדפני Chromium אחרים	האם תהיה תמיכה ברישום מנפיקים של PST בדפדפנים אחרים המבוססים על Chromium דרך מאגר הרישום של מנפיקי PST ב-Chrome?	Chrome מאחזר את ההתחייבויות למפתחות ומפיץ אותן ללקוחות Chrome באמצעות מנגנון שנקרא Component Updater. כאשר דפדפנים אחרים יוסיפו תמיכה מלאה יותר ב-API, הם יצטרכו להגדיר תהליך לקבלת ההתחייבויות למפתחות ללקוח, באמצעות שיטה בסגנון של עדכון רכיב או שיטה אחרת. כאן מוסבר על כך בפירוט.