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

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

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

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

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

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

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

מילון מונחים של ראשי תיבות

ARA

Attribution Reporting API

CHIPS

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

DSP

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

FedCM

ניהול פרטי כניסה מאוחדים

FPS

קבוצות של צד ראשון

IAB

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

IdP

ספק זהויות

IETF

כוח המשימה של הנדסת אינטרנט

IP

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

openRTB

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

הארכה

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

ממשק API של PAT

Protected Audience API (לשעבר FLEDGE)

PatCG

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

RP

מסיבת נאמנות

RWS

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

SSP (פלטפורמה בצד המכירה)

פלטפורמה בצד האספקה

TEE

סביבת ביצוע מהימנה

UA

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

UA-CH

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

W3C

ארגון האינטרנט העולמי

WIPB

עיוורון IP של רצון טוב

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

נושא משוב	סיכום	התגובה של Chrome
ניהול	התעניינות בתקופת התגובה הגלויה לכולם לגבי עדכוני פיקוח בארגז החול לפרטיות.	אנחנו פתוחים לקבלת משוב סביר מבעלי עניין לגבי כל התפתחויות משמעותיות בנוגע לארגז החול לפרטיות, כולל הניהול העתידי של ארגז החול לפרטיות.
בדיקה	שלבי בדיקה נוספים של 3PCD, בנוסף לבדיקה הנוכחית שמתבצעת באמצעות Chrome ל-1%.	אנחנו לא מתכוונים להציע בדיקות שמתבצעת באמצעות Chrome מעבר לאחוז הנוכחי של 1% מהתנועה הנוכחית ב-Chrome שמופעלת מאז תחילת ינואר.
מהאתר לאפליקציה	מודל 3PCD בניידים לא צריך להתרחש לפני שתושג יכולת פעולה הדדית מלאה בין האינטרנט לאפליקציה.	אנחנו מסכימים שמומלץ לתמוך ביכולת הפעולה ההדדית באפליקציות ובאתר. השקנו את מדידת השיוך (Attribution) באתרים ובאפליקציות. אנחנו בוחנים פתרונות טירגוט מהאתר לאפליקציה. עם זאת, אנחנו לא מתכננים לעכב עיבוד של תלת-ממד באינטרנט לנייד. אין לנו יעד של כיסוי של 100% בסיום של 3PCD. אנחנו מצפים שהתאימות ב-Android למדידות באפליקציות ובאינטרנט תהיה גבוהה במידה סבירה בגרסת 3PCD ותגבר עם הזמן ככל שהמשתמשים מעדכנים את הטלפונים שלהם.
תפקיד הדפדפן	נראה ש-Chrome מקבל את התפקיד של שרת מודעות או SSP.	Chrome לא מקבל את התפקיד של שרת מודעות או SSP. באמצעות PA API, Chrome מספק מאגר תגים לשרתי מודעות, SSP, פלטפורמות DSP וטכנולוגיות אחרות של מודעות, כדי ליצור לוגיקה משלהם לבידינג ולציון.
הדרכה לתרחיש לדוגמה	הדרכה ברורה יותר לגבי תרחישי השימוש שנתמכים על ידי ממשקי ה-API של ארגז החול לפרטיות.	בתחילת הפרויקט של ארגז החול לפרטיות, מסמכי התיעוד למפתחים התמקדו בעיקר בעידוד המפתחים להשתתף בתהליכי הדיון והמשוב של כל ההצעות. המשמעות היא שהתוכן התבסס בדרך כלל על הבנת המוטיבציה והמושגים שמאחורי הפרויקט, ולאחר מכן פרטים על הפיתוחים המוקדמים והבדיקות של כל הצעה. הדבר היה יעיל בבניית שיתוף פעולה אמיתי בסביבה העסקית בפיתוח ההצעות. אבל ככל שממשקי ה-API התקדמו עד הזמינות לכלל המשתמשים, התפתח קהל חדש של מפתחים שעוסקים בעיקר בממשקי ה-API של IAB במקום לתרום לפיתוח שלהם. לאחרונה עדכנו את התכונה 'שימוש ב-sandbox.google.com'. הגישה מבוססת-התרחישים לדוגמה אל התיעוד היא משהו שנמשיך הלאה.
סביבת פיתוח מקומית	איך אנחנו ממשיכים לפתח ולבדוק את הקצה העורפי שלנו באופן מקומי ב-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 לפני סיום ה- Standstill.
תרחיש לדוגמה לא נתמך	בשלב זה, מקרי שימוש ב-DSP בשירות עצמי אינם נלקחים בחשבון.	יש מספר ספקי DSP בשירות עצמי שמספקים באופן קבוע משוב ציבורי על ממשקי ה-API. חלק מספקי הפלטפורמות האלה שמספקים משוב ציבורי באופן קבוע רשמו את עצמם גם כבודקים. בנוסף, Chrome מתעניין באופן פעיל בנושאי DSP טיפוסיים בשירות עצמי, כמו מודעות וידאו ושרתי מודעות של צד שלישי. הקריאות השבועיות האחרונות ל-PA API עוסקות בנושאים האלה.
גרסת מקור לניסיון	בקשה ל-OT עבור אתרים שרוצים להגדיל את נפח החשיפה ולבדוק כיסוי אגרסיבי יותר ל-3PCD.	ב-Chrome אנחנו מפתחים כרגע OT של צד ראשון, שיאפשר למקורות להצטרף להתנהגות של ביטול הדרגתי של 3PC. במקורות ברמה העליונה שנרשמו לתקופת הניסיון הזו ולפריסת אסימונים, יהיו 3 מחשבים חסומים כאילו הופעלה הגנת מעקב במכשיר של המשתמש. ה-OT הזה יספק לאתרים הזדמנות רבת ערך לבצע בדיקות נרחבות יותר של חלופות לטווח ארוך ל-3PC, לפני הסגירה ההדרגתית של ה-3PC, שתתקיים בסופו של דבר לאחר ההתייעצות עם ה-CMA. אנחנו עדיין עובדים על לוח הזמנים להשקת ה-OT.
דוח של IAB Tech Lab	משוב על ארגז החול לפרטיות שהתקבל מהדוח של IAB Tech Lab.	כאן ענינו בפירוט על הדוח של IAB Tech Lab. אישרנו גם את העובדה ש "הדוח מעלה שאלות לגבי מסמכים מקוטעים, דרישות מסחריות, ביקורות של צד שלישי, אישורים בתחום, יכולת התאמה, שקיפות ושליטה עתידית, אשר נעבוד עם הסביבה העסקית ונעדכן את השאלות הנפוצות שלנו בהתאם". אנחנו מטפלים במסמכים מקוטעים קודם לכן. אנחנו מטפלים בדרישות המסחריות בקטע 'אחריות על נתונים' כאן, וחלק ממוצרי Google Ads שיתפו את הגישות שלהם. אנחנו מטפלים בביקורות של צדדים שלישיים בכפוף ל-"Algorithm Integrity אומת" כאן. בכל הנוגע להכרה, אנחנו מצפים שהגופים האלה ימשיכו למכור מוצרים, כולל שימוש בטכנולוגיות, במקום בטכנולוגיות בעצמם. בכל מה שקשור ליכולת התאמה, אנחנו ממשיכים להיות פתוחים לנתונים ממפתחים שמעידים על בעיות. בכל הקשור לשקיפות ולניהול, אנחנו ממשיכים לפתח פתוח ב-GitHub ובפורומים כמו W3C תוך כדי שיתוף פעולה עם ה-CMA בכפוף להתחייבויות.
כניסה באמצעות חשבון Google	כניסות באמצעות חשבון Google יובילו לאפשרות של Google להשתמש בנתוני התחברות עם אמצעי זיהוי שונים, בניגוד להתחייבויות.	הכניסה באמצעות חשבון Google לא מאפשרת ל-Google להשתמש בנתונים שסותרים את ההתחייבויות.
תאימות	מהן התוכניות לתמיכה בממשקי ה-API של ארגז החול לפרטיות ובתאימות להעברה או לאחור?	לאחר ש-Chrome יושק בזמינות לכלל המשתמשים, אנחנו שואפים להמשיך לתמוך בתכונה הזו. כמובן שלא תמיד אפשר לשמור על תאימות לאחור. במקרים כאלה יש לנו תהליך ברור להוצאה משימוש והסרה של תכונות קיימות, שמתוארות כאן. אנחנו צופים שנמשיך להוסיף עוד תכונות לממשקי ה-API של ארגז החול לפרטיות במשך הזמן, בתגובה למשוב על תרחישים לדוגמה שמשפרים את הביצועים שלהם. במקרים כאלה אנחנו נוטים לכלול שיטה כלשהי לזיהוי תכונות, כדי שטכנולוגיית מודעות שמעוניין להתנסות בתכונה חדשה יכולה לשאול ישירות את הדפדפן אם התכונה נתמכת. עדיף לבקש ממפתחים לבדוק מספר גרסה מסוים של Chrome, כי ייתכן שחלק מהתכונות לא יושקו לכל משתמשי Chrome בו-זמנית. לדוגמה, תכונת זיהוי התכונות שלנו עבור PA API זמינה כאן.
הטמעת שרתים	במקום להשתמש בשילוב עם ההטמעה שלו, על Chrome לציין את דרכי ההתנהגות שהטמעה מספקת של שרת אותות מהימנים, שרת צבירה וכל רכיב נדרש אחר שאינו דפדפן חייב לעמוד בהן. כך תתאפשר חדשנות במסגרת גבולות מקובלים של פרטיות.	אנחנו מעריכים ומקדמים את הרצון לחדשנות מצד גורמים חיצוניים. בכל ממשקי ה-API והשירותים, אנחנו שואפים לספק טכנולוגיות פרסום גמישות בהטמעת הפונקציונליות שלהן. לדוגמה, אנחנו מאפשרים לטכנולוגיות פרסום להשתמש במידע עסקי סודי במהלך עיצוב לוגיקת בידינג למכירות פומביות. בנוסף, אנחנו כל הזמן משתמשים במשוב שאנחנו מקבלים מטכנולוגיות פרסום, ואם יש הצדקה, משלבים אותו בעיצובים שלנו. כדי לאפשר לאחרים להריץ קוד משלהם בסביבות ביצוע מהימנות, בארגז החול לפרטיות יצטרכו לבדוק את הקוד (וכל שינוי אחר) כדי לוודא שהוא עומד באחריות לפרטיות. לשם כך נדרש מאמצים רבים מצוות ארגז החול לפרטיות. לכן אנחנו רוצים להבין אילו יתרונות בעלי העניין רוצים להשיג, ושאנחנו לא יכולים להשיג היום.
היוריסטיקה	מהן התוכניות לטווח הארוך לגבי היוריסטיקה?	בהתאם למה שדפדפנים אחרים ציינו, בכוונתנו להפסיק בסופו של דבר את ההיריסטיקה הזו, מאחר שפתרונות חלופיים ייעשו בשימוש נרחב, בכפוף לניתוח היתכנות נוסף. שיתפנו את זה כאן.
נפח הבדיקה	נפח תנועה שונה כשמשווים בין מאפיינים שונים.	לניסוי ה-1% יש קריטריונים להחרגה שגורמים להבדלים בכשירות להשתתף בניסוי, בין אוכלוסיות שונות של לקוחות Chrome. לדוגמה, הניסוי לא כולל משתמשי Chrome Enterprise, ולכן בסופי שבוע צפוי שנתח התנועה הכולל בתוויות ניסוי יהיה גבוה יותר. אנחנו צפויים לראות אחוזים שונים של התנועה בפלחי נתונים שונים (כמו מיקום גיאוגרפי, תאריך ופלטפורמה), וזה תואם למה שאנחנו רואים בנתוני Chrome.
הפעלה מחדש ידנית של מחשבים 3	האם אתרים יוכלו לדעת כמה משתמשים (%) הפעילו מחדש באופן ידני קובצי cookie לאחר אכיפה של 3PCD?	אם המשתמשים ייתקלו בשיבושים, המשתמשים יוכלו להפעיל מחדש גישת 3PC ברמת האתר דרך 'עקיפת משתמשים'. ניתן להפעיל מחדש מחשבים 3PC גם באמצעים אחרים, כמו Storage Access API. קיימים אמצעים טכניים, כמו hasStorageAccess(), שמאפשרים לאתרים לזהות אם מחשבי 3PC מופעלים או מושבתים. עם זאת, Chrome לא יאפשר לאתרים לדעת מהן הסיבות להפעלה מחדש.
חסימת מעקב	למשך כמה זמן התכונה 'חסימת מעקב' בממשק המשתמש תהיה זמינה ב-Chrome?	ממשק המשתמש של חסימת המעקב בסרגל הכתובות צפוי להישאר לאחר ההוצאה משימוש של 3PC.
(דווח גם ברבעונים קודמים) תמיכה בדפדפנים שונים	ספקים אחרים של דפדפנים משתמשים בממשקי ה-API של ארגז החול לפרטיות.	ספקים אחרים של דפדפנים, כמו Apple, Mozilla ו-Microsoft, משתתפים באופן פעיל בפורומים ציבוריים שבהם דנים בעקרונות הפרטיות ובגישות שמבוססות על הדפדפן. אנו מקבלים עידוד מדיונים שיתופיים בפורומים כמו פגישת TPAC השנתית של W3C והפורומים המתמשכים של W3C PATCG, שבהם אנחנו רואים סימנים של התכנסות. לדוגמה, לאחרונה הכרזנו על תוכנית Microsoft Edge שמטרה למקסם את התאימות התחבירית ל-PA API ול-ARA, וגם להציע תכונות נוספות למפתחים.
אפשרות חלופית להטמעות לא תואמות בפוסט 3PCD	יש לספק קטעי ה-hook ל-API כדי לזהות אם iframe או הטמעה של צד שלישי עומדים בדרישות של 3PCD או לא.	אנחנו דנים בבקשה כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
בדיקה	בקשה לסימונים נוספים במופעים מנוהלים של Chrome שמשביתה באופן זמני את התנהגויות ההתאמה האישית.	אנחנו שוקלים את הבקשה הזו עבור מכונות מנוהלות של Chrome, ונשמח לקבל נתונים נוספים מהמערכת האקולוגית אם סימון כזה יכול לעזור.

הרשמה ואימות

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

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

נושאים

נושא משוב	סיכום	התגובה של Chrome
(דווח גם ברבעונים קודמים) ציר הזמן ומסמכי התיעוד של המסווג	צריכה להיות מנגנון כלשהו לבדיקה של הסיווג, או לפחות שקיפות נוספת לגבי האופן שבו מצב הסיווג קובע קטגוריות.	התגובה שלנו לא השתנתה לעומת הרבעונים הקודמים: "סיווג שגוי של אתרים עשוי להפוך את אות הנושאים פחות שימושי כאות באופן כללי, אבל האתרים הספציפיים שמסווגים באופן שגוי לא נפגעו יותר ולא פחות מבכל אתר אחר. הסיבה לכך היא שמידע תלוי-הקשר של אתר יהיה תמיד זמין במכרזים באתר שלו, שמספקים מידע דומה לגבי הנושא הנכון, גם במקרה של סיווג שגוי. נשמח לקבל משוב על הנושא כאן."
Google Ad Manager	Google Ad Manager כבר מוטמע ברוב האתרים, והוא יכלול מידע הרבה יותר רחב על נושאי משתמשים מאשר המתחרים שמופיעים בפחות אתרים.	מטרת התצפית היא להבטיח ש-Topics API לא יגרום לשיתוף נתוני משתמשים עם יותר ישויות בהשוואה לטכנולוגיות שה-API מחליף (כולל 3PC). פתרונות אחרים בתחום, כמו Prebid, עובדים עם 10,000 אתרים ומאפשרים למשתתפים בשוק להתקשר ל-Topics API באמצעות הטכנולוגיה שלהם. יתרה מכך, כדאי לציין שלמגבלה של עד 5 נושאים מובילים בשבוע עשויה להיות השפעה שווה, מפני שהמשתתפים הנוכחיים בשוק, שיכולים לקבל מידע על נושאים מקבילים יותר מ-5 נושאים באמצעות שלושה מחשבים, יוגבלו ל-5.
(דווח גם ברבעונים קודמים) שימושיות לסוגים שונים של בעלי עניין	חששות לגבי הערך שנוצר וההפצה של אותו אתרים, בהתאם לרמת התנועה שהם מקבלים או למידת הספציפיות של התוכן באתרים.	אנחנו מכירים בכך שיש סיכוי גבוה יותר שאתרים ספציפיים יתרמו נושאים מפורטים יותר מאשר דומיינים בעלי עניין כללי. עם זאת, לא כל האתרים המתמחים תורמים נושאים בעלי ערך מסחרי. בנוסף, הדינמיקה הזו משקפת את המצב הקיים ובלתי תלויה לחלוטין בסיום התמיכה במכשירי 3PC ב-Chrome. בנוסף, בסביבה הנוכחית, אתרים מסוימים מספקים ערך גבוה יותר מאתרים אחרים, במערכות רלוונטיות של מודעות שמבוססות על 3PC. בנוסף, נושאים באתרים מתמחים יכולים להועיל זה לזה מכיוון שמפרסמים מגוונים יכולים להפעיל קמפיינים בקבוצות מגוונות של נושאים, ולוגיקת הבידינג יכולה לספק ערך במגוון רחב של נושאים.
שמות מארחים לעומת כתובות URL מלאות	האם הסיווג שמבוסס על שמות מארחים של אתרים מספיק יעיל, והאם זה מפחית את הסיכון לפרטיות בהשוואה לכתובות URL מלאות?	שקלנו להשתמש בכתובות URL או בכותרות דפים בנוסף לשמות מארחים, והגענו למסקנה שהסיכונים הפוטנציאליים לפרטיות ולאבטחה של המשתמשים יקבלו עדיפות על פני היתרונות האלה. דוגמאות לסיכוני פרטיות משתמשים: סיווג של מידע רגיש שכלול בכתובת ה-URL או בכותרת הדף לפי הנושאים של המשתמשים.
נושאים כאות	בקשה להדרכה לגבי שילוב של Topics עם אותות אחרים, ולגבי אותות נוספים שיכולים לעזור.	פתרונות פרסום דיגיטלי יכולים להשיג את התוצאות הטובות ביותר באמצעות שילוב של כל הכלים הזמינים, כמו למידת מכונה ואותות ללא פגיעה בפרטיות מממשקי 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 בנושא ארגז החול לפרטיות.
הגבלת מקור זהה לבעלים של IG ולכתובת ה-URL הלוגית של הבידינג	עם דרישה לאותו מקור, נקודות הקצה של בעל IG יאלצו לעבור דרך אותו מאזן עומסים, דבר שעלול להוביל לדחייה של הפניות אוטומטיות.	דרישת המקור הזהה לטעינת סקריפט היא הגנה חשובה על האבטחה. כאן יש פרטים על הפתרון המוצע שמאזן בין המשוב על הסביבה העסקית לבין שיקולים אחרים.
מכירה פומבית פרטית עם מגרשים מרובים	יש הרבה מקום לאפשר מכרזים פרטיים עם מספר משבצות פנויות במסגרת גבולות הפרטיות, על ידי שימוש ברעשים ובשילוב הדוק יותר עם שיטות העבודה הנוכחיות של המודעות.	אנחנו מביאים בחשבון את המשוב הזה ובודקים את הבקשה להשתתפות במכרז עם כמה תגים, ביחס לסיכוני המורכבות והפרטיות המשויכים לתכונה הזו. דנו בבעיה הזו לעומק במהלך שיחה מטעם PA API Web Incubator Community Group (WICG) כאן.
מוכרים ברמה עליונה	המבנה הנוכחי של ה-PA API מספק לכל אתר מכירה ברמה העליונה יותר נתונים והבנה של הערך היחסי של החשיפות, בהשוואה לבעלי אתרים או לאתרי מכירה של רכיבים.	במכרז עם כמה אתרי מכירה, לכל אתר מכירה תוגש הצעת המחיר הכי טובה. בנוסף, למדנו מהמערכת האקולוגית שבעלי אתרים ירצו לשקול ביקוש במכירה ישירה לצד הצעות המחיר הטובות ביותר של כל אתר מכירה שאיתו הם עובדים. כדי להחליט איזו מודעה להציג, צריך לבדוק את כל ההזדמנויות הפוטנציאליות למונטיזציה. מצב כזה שבו גורם מסוים נחוץ לראות את כל האפשרויות כדי לבחור מודעה להצגה, קודם ל-PA API. PA API נועד לתמוך במכרזים עם כמה אתרי מכירה, וברצון של בעלי התוכן הדיגיטלי לשקול את הצעת המחיר הטובה ביותר של כל אתר מכירה לצד קמפיין פרסום שמיועד למכירה ישירה, במקרים שבהם האפשרות השנייה רלוונטית. המשמעות היא שצריך להיות מנגנון לבחירה מבין ההזדמנויות האלה למונטיזציה, כפי שיש כיום. לא היינו סבורים שהדפדפן צריך לבחור איזו מודעה להציג. לכן, הקונספט של אתר מכירה ברמה העליונה הכרחי כדי לבחור מודעה מנצחת מתוך אפשרויות רבות. ההיגיון ברמה העליונה של בית העסק צריך להיות מסוגל לשקול את הצעות המחיר הטובות ביותר של כל אתר מכירה שבעל האתר בוחר לעבוד איתו. ההיגיון שעומד מאחורי בית העסק עשוי לספק מידע על הקמפיינים של בעל התוכן הדיגיטלי למכירה ישירה שבהם המידע זמין. ניתן להביא בחשבון את כל המידע הזה במסגרת הלוגיקה ברמה העליונה של בחירת מודעות. פירוש הדבר הוא שהלוגיקה ברמה העליונה מתייחסת להצעות המחיר הטובות ביותר מהמכרז של PA API, ובמקרים הרלוונטיים גם לאפשרויות של מודעות במכירה ישירה מבעל התוכן הדיגיטלי כדי לקבוע מנצחת. Google Ad Manager מפרט בדוח הזה את ההטמעה של PA API כמוכר ברמה העליונה, לפי הנושא 'גישה למידע'.
הפרדת מודעות תחרותית	בקשה להפרדת מודעות תחרותית, למשל מניעת הצגה של מודעות ממותגים מתחרים זה לצד זה.	לא ידוע לנו דרך שמאפשרת להבטיח הפרדה תחרותית בסביבה העסקית הנוכחית של פרסום דיגיטלי, שכולל הצעות מחיר ומרובות אתרי מכירה. עם זאת, PA API מאפשר למוכרים לאחזר אותות נוספים בזמן אמת על סמך שילוב של כתובת URL לעיבוד ושם מארח (שמייצגים את הדומיין של בעל התוכן הדיגיטלי) שניתן להשתמש בהם במהלך ScoreAd() לצורך חישוב קריאייטיבים. אתרי מכירה יכולים להשתמש בהגדרה הזו כדי למנוע הצגה של מודעות של מותגים מתחרים זה לצד זה, בהנחה שבעלי התוכן הדיגיטלי רוצים לאכוף את הכלל הזה.
מידע מוגבל	PA API מצמצם את המידע הזמין לבעלי תוכן דיגיטלי, כמו ערך המודעה, שם הקונה הרכיב, שם המפרסם, כתובת דף הנחיתה, גודל הקריאייטיב, זמן התגובה ושיעור הצעות המחיר.	הצענו כמה פתרונות פוטנציאליים כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח ברמת האירוע	בעלי תוכן דיגיטלי לא יכולים לקבל מספיק מידע על המודעה שהוצגה אחרי ההוצאה משימוש של PA API לדיווח ברמת האירוע.	אנחנו מודעים לתרחישים השונים לדוגמה שבהם אנחנו חייבים להמשיך לתמוך, לאחר שנוציא משימוש את הדיווח ברמת האירוע. לכן, טירגטנו את התאריך של השבתת הדיווח ברמת האירוע כך שיהיה לא מוקדם יותר משנת 2026. בפרק הזמן הזה אנחנו מזמינים אתכם להשתתף בצורה פעילה תוך שיתוף פעולה עם הסביבה העסקית בנתיבים ארוכי טווח קדימה, שעשויים לכלול רעיונות חדשים להשגת מידע תוך שמירה על הפרטיות.
SSP מרובים	הערך המוסף של פלטפורמות SSP מרובות יהיה נמוך מדי לבעלי אתרים.	אנחנו לא חושבים שהטענה הזו נכונה, ונשמח לקבל משוב נוסף מהסביבה העסקית כדי להבין את הנימוקים לטענה הזו.
פעילויות איסוף	אי אפשר לבצע פעילויות איסוף עם PA API.	קיבלנו משוב על היכולת של מפיצים להשתמש ב-PA API כדי להפוך את פרטי הקהל שלהם לקונים באינטרנט (תוסף קהל חלופי). אנחנו מאמינים שהדבר אפשרי כיום באמצעות פונקציונליות ההאצלה של מודעות בהתאמה אישית (PA) יחד עם הסכמים עסקיים. במקביל, אנחנו שוקלים באופן יזום אם נוכל להתאים בצורה טובה יותר לתרחישים כאלה, ובאיזה אופן.
ביטול הצטרפות של הקונה	ביטול ההסכמה של הקונה המוגדר כברירת מחדל עשוי לגרום לתוצאות נמוכות יותר במכרזים של רכיבים.	בין אם המפרסם מגדיר מכירה פומבית יחידה או מכרז של מודעות PA עם אתרי מכירה מרובים, המפיץ חייב לציין במפורש קונים בשדה תחום ענייןGroupBuyers ב-AuctionConfig. הערה כזו מבוססת על משוב מהמערכת, כך שלמפיצים יש הסכמים חוזיים עם חלק מהקונים ולא עם אחרים, לכן תידרש שליטה מפורשת על הקונים שייכללו במכרז. נשמח לדיון נוסף ב-GitHub.
הצגת מודעות	לא ניתן לבצע סינון מראש לפי adsize ו-adSlotSize.	אנחנו פועלים להוספת היכולת הזו. פרטים נוספים זמינים כאן.
תמיכה בטירגוט IG שלילי	ממשק API לתמיכה בטירגוט IG שלילי: הצגת מודעות רק אם המשתמש לא שייך ל-IG.	בעיה זו ב-GitHub הציעה דרך חלופית להטמעת מיקוד שלילי, שבה הדפדפן מורה ישירות לשרת המודעות אילו כללי טירגוט שלילי צריכים לחול על בקשה ספציפית להצגת מודעה. למרות שהגישה הזו נראית אטרקטיבית, כל הגרסאות של הרעיון הזה מסתברות כדי לאפשר לשרת לזהות את המשתמש באופן ייחודי.
חוק השירותים הדיגיטליים (DSA)	איך בעלי תוכן דיגיטלי יכולים להשתמש ב-Fenced Frames גם כדי למנוע רינדור של תשובות שמכילות מידע בכפוף ל-Digital Services Act (חוק השירותים הדיגיטליים)?	כמו בכל טכנולוגיה חדשה, כל חברה אחראית לוודא שהשימוש שלה בארגז החול לפרטיות נעשה בהתאם לחוק. Google לא יכולה לספק לאחרים ייעוץ משפטי. פרסמנו מסמכים טכניים מקיפים לכל ממשק API, שאמורים לספק את הבסיס לעריכת בדיקות משפטיות נדרשות. אין צורך להשתמש ב-Fenced Frames לפני שנת 2026, כדי לאפשר לבעלי עניין זמן נוסף להבטיח שהשימוש שלהם בטכנולוגיה הזו מתבצע בהתאם לכל החוקים הרלוונטיים.
מאמרי עזרה	האם ה-UpdateAdInterestGroups() זמני?	עוד לא הודענו על תוכניות להוצאה משימוש של updateAdInterestGroup. בעתיד, יכול להיות שנחיל אמצעי הגנה על פרטיות דומים כפי שדיברנו עליהם, לגבי מנגנוני עדכון אחרים של IG, למשל שימוש בכתובת IP, וגם הוספת השהיה לפני שהעדכון מתבצע.
תמיכה במטא-נתונים ובלוגיקה בצד הקונה עבור שירותים שאינם DSP	בקשה לדרך לפעולה כשרת proxy עבור DSP.	אנחנו מודעים למשוב הזה שמגיעים מפלחים שאינם DSP ושוקלים את הבקשה. נשמח לקבל משוב נוסף מהסביבה העסקית.
דיווח	צריך לבקש להוסיף תכונת handler בהתאמה אישית לקטגוריה / ערך של אותות בדוחות של צבירה פרטית.	אנחנו מודעים לכך, והבקשה הזו לתכונה נמצאת בתור לבדיקה נוספת. נשמח לקבל משוב נוסף מהסביבה העסקית כאן.
מאמרי עזרה	האם יש קישור שבו אפשר להציג את כל כותרות התגובות שצריכים להגדיר על ידי המפרסם והדומיין של הבעלים (המואצל)?	אנחנו מתכננים עדכונים במסמכים שיבהירו את העניין, ונשמח לקבל משוב נוסף מהסביבה העסקית.
בידינג במספר מגדלים	בקשה להסבר על תהליך העבודה (הדרכה והסקת מסקנות) באמצעות ארכיטקטורה או דיאגרמת בלוק לגבי חיזוי הגישה של ריבוי מגדלים בהקשר של PA API.	תודה על המשוב. יש לנו כמה מצגות בנושא, ואנחנו צופים שנספק מסמכים נוספים בנושא.
טירגוט שלילי	היכולת של ארגז החול לפרטיות להגן על קהלים רגישים ועל קטינים מפני מודעות בלתי הולמות, למשל הימורים.	PA API לא מתייחס לתוכן המודעות שמוצגות. השליטה הזו שולטת במפתחים של טכנולוגיות פרסום שמשתמשים במודעות בהתאמה אישית (PA). באופן כללי, בעלי התוכן הדיגיטלי וספקי טכנולוגיות הפרסום שלהם יכולים לחסום קריאייטיבים של מודעות במכרזים של Protected Audience באמצעות מידע לפי הקשר מהדף ובאמצעות קבוצות כללים לבעלי תוכן דיגיטלי. הדבר משקף את האופן שבו אנו מבינים את הגישה של המערכת האקולוגית לאתגרים האלו כיום. עבור הקונים, הפונקציונליות של טירגוט מסוג IG שלילי עשויה להיות שימושית גם עבור תרחישים מסוימים של תאימות.
עיצוב API	Google דוחה את הבקשה ורוצה שטכנולוגיות פרסום ישתמשו בפונקציה של בידינג אוניברסלי, וכך להאריך את זמן האחזור, במקום להשתמש בכתובות BiddingLogicURL שונות ב-IG שונים, מה שמותר לעשות.	במהלך הדיונים שלנו על זמן האחזור במכרז, הדגשנו ששימוש חוזר באותו סקריפט בכל ה-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 בקבוצת משנה של תנועת גולשים, לשמש כזרוע בקרה של בדיקת A/B.
למידת מכונה	לבעלי תוכן דיגיטלי נדרשת שליטה רבה יותר על השימוש שמוצע ב-GAM ללמידת מכונה.	התשובה סופקה על ידי Google Ad Manager: בינואר 2024 השקנו אמצעי בקרה שמאפשר לבעלי תוכן דיגיטלי להשבית את ויסות הנתונים (throttle) של למידת מכונה, ולהפעיל מכרזים של PA API עם מפיצים שאינם של Google בכל התנועה שלהם. ניתן למצוא פרטים נוספים על אמצעי הבקרה הזה במרכז העזרה שלנו.
(דווח גם ברבעונים קודמים) מכרזים ברמה עליונה	יכולת להשתמש בשרת המודעות של Google לבעלי תוכן דיגיטלי בלי לתת ל-GAM גם שליטה במכרז של PA API ברמה העליונה.	התשובה סופקה על ידי Google Ad Manager: בגלל הסיבות שמפורטות בדוח של Google לרבעון 3 של שנת 2023, התוכניות של GAM לשילוב PA API לא כוללות תמיכה בבעלי תוכן דיגיטלי שמשתמשים ב-GAM כשרת המודעות של בעלי תוכן דיגיטלי, ללא שליטה במכרז ברמה העליונה.
גישה למידע	ל-GAM יש גישה למידע חשוב ממתחרים, כולל מחירי מכרזים לפי הקשר, אותות שקונים סיפקו לפלטפורמות SSP עבור המכרז של PA API ופרמטרים של הגדרה מפלטפורמות SSP.	התגובה סופקה על ידי Google Ad Manager: כבר שנים רבות שמרנו על הוגנות במכרזים במשך שנים, כולל הבטחה שלנו לכך ששום מחיר ממקורות פרסום לא מובטחים של בעל תוכן דיגיטלי, כולל מחירים של פריטים לא מובטחים, לא ישותף עם קונה אחר לפני שהוא יגיש הצעת מחיר במכרז. לאחר מכן אישרנו מחדש את ההתחייבויות שלנו לרשות התחרות הצרפתית. במכרזים של PA API, אנחנו מתכוונים לשמור על ההבטחה שלנו ולא לשתף את הצעת המחיר של אף משתתף במכרז עם אף משתתף אחר במכרז לפני השלמת המכרז במכרזים עם כמה אתרי מכירה. לשם הבהרה, לא נשתף את המחיר של המכרז לפי ההקשר בשום מכירה פומבית שהיא, כולל המכירה שלנו, כפי בעדכון הזה. בנוסף, אנחנו לא משתמשים במידע על הגדרות המכרז של הרכיבים, כולל אותות שהקונים סיפקו ל-SSP, כחלק מהמכרז שלנו. למעשה, יתקבלו בברכה שינויים ב-PA API, שיאפשרו למפיצים של רכיבים לציין את הגדרות המכרז של הרכיבים באופן שמעורפל מגרסת המוכר ברמה העליונה.
מכירות פומביות של רכיבים	כמכרז ברמה העליונה, GAM הוא זה שקובע אילו פלטפורמות SSP יפעילו מכרזים של רכיבים עבור כל הזדמנות להצגת מודעה.	התשובה סופקה על ידי Google Ad Manager: כשרת מודעות של בעלי תוכן דיגיטלי, GAM מציע ממשק API פשוט עבור SSP, שבעלי תוכן דיגיטלי עשויים לעבוד איתו כדי לציין את הגדרות המכרז של הרכיבים באמצעות Google Publisher Tag (GPT). כאן ניתן למצוא פרטים נוספים. אם 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 כדי לאפשר לפלטפורמות SSP לקבוע מגבלות על זמן האחזור DSP וגם לבצע שיפורים שעשויים לקצר את זמן האחזור. לאחרונה עדכנו את המדריך לשיטות מומלצות לזמן אחזור, שכולל מידע נוסף על היתרונות של התכונות האלה. כמו כן, אנו ממשיכים לפתח שיפורים חדשים בזמן האחזור, שאת חלקם ניתן לראות כאן.
(דווח גם ברבעונים הקודמים) רינדור וידאו	תמיכה בעיבוד וידאו באמצעות PA API ו-Fenced Frames.	בינואר פרסמנו הדגמה של האופן שבו סרטון In-stream יכול לפעול במכרז של מודעות בהתאמה אישית, עם פרטים נוספים על גישות חלופיות. אנחנו גם רואים ששחקנים בסביבה העסקית מתחילים להציע איך עיבוד הווידאו פועל עבור שותפים שמשתלבים איתם, כמו ההצעות של GAM בנושא בניית כתובות URL תואמות לסרטונים או תהליך E2E המלא. בנוסף, אנחנו מקשיבים למשוב לגבי שינויים שאנחנו יכולים לעשות בסביבה העסקית כדי להגביר את האימוץ, ושינוי אחד כזה מפורט ב-GitHub. אנחנו ממשיכים להיות מעורבים באופן פעיל בסביבה העסקית כדי לזהות מכשולים אחרים שנתקלים בהם ולטפל בהם.
(דווח גם ברבעונים הקודמים) מדיניות טיפול בנתונים	מהי מדיניות הטיפול בנתונים של IGs / PA API?	בתכנון של PA API, כל הנתונים שמאוחסנים ב-IG, או לגבי אילו אנשים נמצאים ב-IG, (i) נשארים במכשיר או (ii) מעובדים בשירותי הבידינג והמכרז (B&A) שפועלים בתוך סביבת ביצוע מהימנה (TEE). בשני המקרים, גורמים אחרים לא יכולים לקרוא את הנתונים או להשתמש בהם בכל דרך אחרת מלבד לצורך הגשת הצעות מחיר במכרז. שיפורים מסוימים בתחום הפרטיות ש-Chrome בוחן אכן כרוכים באינטראקציה עם שרת k-anonymity המנוהל על ידי Google. האינטראקציה הזו תוכננה בקפידה כדי להימנע משיתוף מידע על משתמשים, ולהריץ בסביבת TEE כדי להבטיח שוויון מידע בסביבה העסקית של המודעות. Google התחייבה להשתמש ב-CMA כדי לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא יפריע לתחרות על ידי מתן עדיפות לעסק של Google, ויביא בחשבון את ההשפעה על התחרות בפרסום בדיגיטל ועל בעלי תוכן דיגיטלי ומפרסמים. אנחנו ממשיכים לעבוד בשיתוף פעולה הדוק עם ה-CMA כדי להבטיח שהעבודה שלנו עומדת בהתחייבויות האלה.
(דווח גם ברבעונים הקודמים) כל משך החיים של IG	בקשה להארכת החיים של IG מ-30 ל-90 יום.	שינוי כזה מחייב הערכה קפדנית, ושקלל את היתרונות לתעשייה מול ההשפעה על משתמשי Chrome ובעלי עניין אחרים. אנחנו בוחנים את הבקשה ושולחים משוב נוסף כאן.
(דווח גם ברבעונים הקודמים) modelingSignals	צריך לבקש שדה חדש בנוסף ל-ModelSignals, שאפשר לקודד רק מידע על תצוגה וקליקים.	הגבנו למשוב הזה עם הצעה נגדית כאן. אנחנו מעורבים באופן פעיל בתעשייה כדי להבין את הדעות שלהם לגבי ההצעה שלנו, וכיום אנחנו שוקלים את היתרונות לתעשייה מול ההשפעה על משתמשי Chrome ובעלי עניין אחרים.
ביטים נוספים ב-reportWin()	יש לספק ב-ReportWin() ביטים נוספים מהמגבלה הנוכחית של 12 לפני 3PCD.	אנחנו בוחנים כרגע שיטות שיתמכו בתרחיש לדוגמה הזה. התהליך נמשך זמן מה, כי אנחנו גם מחפשים גישות שיעזרו לנו להבטיח שיש לנו תוכנית לשמירה על הפרטיות לטווח הארוך.
עיצוב מכירה פומבית	בקשות למכרז יחיד שמחזירה כתובות URL לעיבוד עם הציון התואם שלהן.	לקחנו בחשבון את האפשרות לשתף כמה כתובות URL לעיבוד, ואת הציון שלהן, ממכרז יחיד של מודעות בהתאמה אישית, אבל לא יישמנו אותן בגלל בעיות שקשורות לפרטיות. אנחנו מבינים את הרצון למנוע את הצגת אותה מודעה מספר פעמים בדף אחד בפני המשתמש, ומקדמים בברכה דיון נוסף ב-GitHub.
reportWin	לתעד שדות שרירותיים בפונקציה reportWin() .	זה כבר קורה היום, במהלך תקופת הבדיקה. אחרי ש-Chrome יפסיק את התמיכה במחשבי 3PC, גרסת forDebuggingOnly של ה-API תועבר כדי להפעיל ניפוי באגים מצומצם. ניתן להגדיר זאת כאן.
מפיצים שמוכרים רכיבים	צריך להפעיל מנגנון עצמאי לספירת החשיפות ואירועים אחרים שלו, ולא להיות תלוי רק בדוחות של טכנולוגיות הפרסום.	הבקשה הזו לתכונה נמצאת בתור לבדיקה נוספת. אנחנו לא צופים שנטפל בבעיה הזו במהלך תקופת הבדיקה שמתבצעת באמצעות Chrome.
חיוב לפי עלות לקליק	הטמעת חיוב לפי עלות לקליק ב-PA API.	אנחנו בוחנים את הבקשה כאן, ובשלב הזה אנחנו רואים אותה בתור בקשה לקבלת הצעות להטמעת התכונה בממשק הנוכחי של ה-API.
browserSignals	צריך להוסיף את destinationBidInSellerCurrency לדיווח על מפרט BrowserSignals בשביל בית העסק.	אנחנו בוחנים את הבקשה ושולחים משוב נוסף כאן.
תמיכה במטא-נתונים של צד הקנייה ובבעלות לוגית לספקים שאינם פלטפורמות DSP	העיצוב הנוכחי של ה-API עשוי להוביל לשינוי משמעותי בקמפיינים של טירגוט מחדש ברמת המוצר, במקרים שבהם הקמפיינים עשויים להידרש לפלטפורמות שמספקות גם פלטפורמות DSP וגם ספקי DCO.	אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף כאן .
תמיכה במטא-נתונים של צד הקנייה ובבעלות לוגית לספקים שאינם פלטפורמות DSP	שתף דוגמאות שבהן ה-DSP אינו הבעלים של IG.	אנחנו מבינים שאנשים שאינם מגישי הצעות מחיר רוצים להשתמש בפונקציונליות מסוימת של IG, אבל לא באחרות. אנחנו בוחנים באופן פעיל את האפשרויות לטיפול בתרחישים כאלה, ונשמח לקבל משוב נוסף כאן.
פקדים לזמן קצוב	בעלי האתרים אמורים להיות מסוגלים להכתיב את מספר ה-IG שיכולות להשתתף בניסוי, ואת הזמן הקצוב לתפוגה ברמה העליונה / הזמן הקצוב לתפוגה באופן גלובלי.	ברור לנו שיש צורך בבקרה משופרת של זמן קצוב לתפוגה ובחשיפה בין אתר המכירה ברמה העליונה לבין אתר המכירה של הרכיבים, ואנחנו שוקלים את הבקשה הזו.
גודל מודעה מרובה	תמיכה ב-PA API בתרחישים לדוגמה של Multi Ad size.	אנחנו שוקלים את הבקשה הזו, ונשמח לקבל משוב נוסף מהסביבה העסקית.
מאמרי עזרה	האם יש רשימה של מאפייני IG שכפופים ל-k-anon?	ענינו על השאלה הזו כאן.
ניפוי באגים	יכולות משופרות לניפוי באגים ב-PA API.	אנחנו מכירים בחשיבות של כלים חזקים לניפוי באגים עבור מפתחים שעובדים עם PA API. אנחנו מחויבים לשפר את חוויית המפתחים על ידי בחינת דרכים לשילוב טוב יותר של אחזורי קבצים עם הסיומת .well-known עם הכלים למפתחים. המטרה שלנו היא לספק יותר יכולות חשיפה ופתרון בעיות בסביבת הפיתוח. כאן מוסבר בהרחבה על הבעיה הזו, ונשמח לקבל משוב נוסף.
Labels (תוויות)	האם כל המשתמשים בתוויות הטיפול במצב B הפעילו את ממשקי ה-API של ארגז החול לפרטיות?	ההקצאות של קבוצות ניסויים ב-Chrome נקבעות באופן אקראי ובלתי תלויות בהגדרות Chrome שהוגדרו על ידי המשתמש. ממשקי ה-API האלה עשויים להיות זמינים למשתמשים בקבוצות טיפול מסוימות (למשל, treatment_1.*), אבל ניתן לשנות או להשבית את הפונקציונליות שלהם דרך הגדרות Chrome. קבוצת אמצעי בקרה במצב B: ההכללה בקבוצה הזו משביתה באופן מהותי את ממשקי ה-API למדידה ולרלוונטיות של ארגז החול לפרטיות, והמשתמשים לא יכולים לבטל את ההגדרה הזו בהגדרות Chrome.
שימוש ב-API	האם הקריאה reportWin() ועיבוד המודעה מתרחשים במקביל או בזה אחר זה?	reportWin() מופעל ישירות לאחר השלמת runAdAuction(). במקביל, תהליך עיבוד המודעות עשוי להתחיל כשתוצאת המכרז ממוקמת בתוך iframe או Fenced Frame. אחרי שהפעולה של reportWin() הסתיימה והמודעה תתחיל בעיבוד, יתבצע אחזור של כתובות ה-URL שצוינו ל-sendReportTo() .
(דווח גם ברבעונים הקודמים) תמיכה בבדיקת A/B	בקשת תמיכה בבדיקות A/B של PA API.	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף.
עיצוב התנועה	ההצעה של Google לנהל את קבלת ההחלטות הדרושה דרך שרת מפתחות אימות (KV) אינה מועילה, כי המפיצים לא יכולים ליצור אינטראקציה עם הקצה העורפי שלהם, דבר שמאתגר את עיצוב התנועה.	כפי שצוין בבעיה ב-GitHub, אם תחשוף אם פלטפורמות DSP מסוימות יש IGs, ייתכן שיהיו בעיות ביצירת טביעת אצבע של משתמשים. הצענו חלופות אחרות בנושא ואנחנו פתוחים להצעות נוספות.
עיצוב התנועה	מנגנוני שמירה במטמון מוסיפים שכבה משמעותית של מורכבות, ומונעים מפלטפורמות DSP לדעת את הצורה האמיתית של התנועה שעליה הם יגישו הצעות מחיר.	מנגנון השמירה במטמון פשוט הוצע כהצעה. טכנולוגיות הפרסום יכולות לבחור להשתמש בהצעות שעונות על הצרכים שלהם, ונשמח לדיון נוסף כאן.
Labels (תוויות)	Chrome צריך לשתף את התווית כפרמטר בבקשות שנשלחות לשרתים מהימנים של קונים ומפיצים.	נראה שזו בקשה סבירה, כי נראה שהיא תואמת באופן כללי ליעד של שימוש אחראי בנתוני IG. עם זאת, אנחנו שוקלים את הבקשה, לאחר בדיקה פנימית, ונספק עדכונים ציבוריים בנושא הזה עם התקדמות הדיונים.
שימוש ב-API	הבהרת ההגדרה המפורשת של קבוצת 'control_1' במסמך 'הנחיות נוספות של CMA לצדדים שלישיים בנושא בדיקה'. באופן ספציפי, יש חשש ששינוי בניסוח יפורש בטעות כשינוי שמחייב החרגה של כל ממשקי ה-API של ארגז החול לפרטיות מ-control_1.	הבענו את הדעות שלנו בנושא הזה בשרשור הזה ב-GitHub. עם זאת, אין לנו אפשרות לדבר בשם ה-CMA, ואנחנו ממליצים להעלות בעיות בנוגע לפרשנות של הנחיות הבדיקה ישירות מול ה-CMA.
שימוש ב-API	האם Chrome יאפשר קריאה ל-joinAdInterestGroup() בדף ריק, תוך הפניה למשאב אחר?	אם משתמש מבקר באתר מסוים, בעלי האתר יכולים להעניק גישה ל-joinAdInterestGroup לצד שלישי. הענקת הרשאות גישה זו מאפשרת לצד שלישי לבנות IG בלי להוסיף שום סוג של הפניה אוטומטית דרך דף ריק. נשמח לקבל משוב על סיבות ספציפיות לבניית IG באמצע הפניה אוטומטית, במקום להשתמש במנגנון הענקת הגישה המיועד.
שימוש ב-API	לבורסות אמורה להיות אפשרות לכתוב IG בדפים שבבעלות בעלי האתרים שאיתם הן פועלות, ואז להן להאציל את ההרשאה להגיש הצעות מחיר ב-IG לכל קונה או DSP נתון.	קיבלנו את המשוב ואנחנו בודקים אם יש תמיכה בבקשה הזו. נשמח לקבל משוב נוסף מהסביבה העסקית.
שימוש ב-API	אין התראה על אובדן ניפוי באגים אם אף אחד לא זוכה במכרז של PA API.	הפונקציות reportWin ו-reportResults של Chrome מיועדות לדיווח על זכיות ברמת האירוע במערכת 'מכרז בנושא פרטיות' (PA). במקרים שבהם כל הצעות המחיר נדחות במהלך מכרז של מודעות בהתאמה אישית, הפונקציות האלה לא צפויות להיות מופעלות כי לא נקבעה מנצחת. עדכון שבוצע לאחרונה ב-Chrome עשוי להסביר אי-התאמות שבהן כתובות URL שמועברות אל forDebuggingOnly.reportAdAuctionLoss() לא מופיעות בחלונית DevTools Network. אנחנו ממליצים לאמת את הפונקציונליות הזו באמצעות build של ערוץ Canary או של גרסת הפיתוח של Chrome.
שימוש ב-API	האם הערך של adCost שמוחזר מ-createBid יכול להיות שלילי (הוא כבר מעוגל ל-2 בייטים)?	AdCost הוא העלות של קליק או המרה של המפרסם שמועברת מ-generateBid() אל reportWin(). הערך הזה יכול להיות Null או Double. המערכת תתעלם מערכים שליליים ולא תעביר אותם. הערך יעוגל באופן סטוכסטי לאחר המעבר.
שיפור API	האם אפשר להשתמש בשרתי הפעלה מהימנים ומוצפנים כדי לטפל בטירגוט / בקבוצות בעלות מאפיינים משותפים / בשיוך (Attribution) ובמכרזים במקום בדפדפן Chrome?	מומלץ לבדוק את האפשרויות והרכיבים מבוססי-TEE ב-PA API (למשל, שרתי KV ו-B&A Services) וכן את הרכיבים מבוססי ה-TEE של דוחות שיוך (Attribution) וצבירה פרטית (למשל, שירות צבירה) שעונים על השאלה הזו.
שיפור API	האם תגובת המכרז של ארגז החול לפרטיות יכולה להיות תגובה להצעת מחיר (כמו בידינג ב-header) ולא תגובה למודעה (כמו תגי מודעות)?	שינוי כזה משנה מהיסוד את מאפייני הפרטיות של ה-PA API, לכן אנחנו לא מביאים בחשבון אותו.
אמצעי בקרה לבעלי תוכן דיגיטלי	האם בעלי תוכן דיגיטלי יכולים לחסום קריאייטיבים של PA API בדפים שלהם?	יש ב-Chrome הצעה לסריקה של קריאייטיב בזמן אמת שעדיין לא זמינה לבדיקה. למרות שהאפשרות הזו עדיין לא זמינה, שמנו לב שרוב פלטפורמות ה-SSP יצרו פתרונות שמאפשרים זאת.
שימוש ב-API	מהי מגבלת הגודל של perBuyerSignals?	בצורתו הקלאסית, perBuyerSignals אין מגבלות גודל מובנות ב-Chrome. האילוצים העיקריים הם שהנתונים נשארים ניתנים להקראה ל-JSON ולא גורמים לצריכת זיכרון מוגזמת. עם זאת, חשוב לציין ש- perBuyerSignals גדולים ומורכבים מאוד עלולים להשפיע לרעה על הביצועים. קיימת שיטה חלופית להעברה של perBuyerSignals דרך ה-directFromSellerSignalsHeaderAdSlot הגישה הזו מעבירה את perBuyerSignals בתוך כותרת, בכפוף למגבלת גודל מקסימלית של 10kb לכל תגובת הכותרת. בנוסף, שרתים ספציפיים עשויים להטיל מגבלות משלהם על גודל הכותרת המקסימלי.
מאמרי עזרה	יש לשנות את התיעוד ב-callenrollAdBeacon מתוך generateBid.	עדכנו את המסמכים האלה ב-17 בפברואר.
שימוש ב-API	איך reportEvent בוחר את כתובת ה-URL הנכונה של החיישן מתוך מספר אפשרויות רשומות?	לכל מכרז נוצרת הגדרה נפרדת, וכתוצאה מכך נוצרת מפת דיווח נפרדת. מכרזים נפרדים (והמסגרות שנובעות מהם) נפרדות לחלוטין זו מזו ולא מתבצעות חלוקה של הנתונים ביניהן. הסבר בנושא 'דיווח על מודעות מסוג Fenced Frames' כולל פרטים נוספים בנושא.
ממשק המשתמש של Chrome	מוסיפים מסנן בכרטיסייה 'Application -> 'קבוצות של תחומי עניין' של 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 ממוקם אפס או מספר שלילי כלשהו פירושו שהמודעה המתאימה לא כשירה לזכות במכרז. ניתן להשתמש במנגנון זה, למשל, כדי לסנן מודעות שממוקדות לפי קבוצות תחומי עניין שאינן חורגות ממועמד בעל מיקוד לפי הקשר. למרות שערך ברמה העליונה LevelWinningBid בעל ערך של אפס יכול להצביע על כך שמכרז לפי הקשר ניצח, מפרט ה-PA API מכיר בכך שגורמים אחרים עשויים לתרום לתוצאה הזו.
מצב A/B Testing	הבהרה לגבי בחירת תנועה למצב ב' ומצב א', והנחיות לביטול הסכמה.	הקריטריונים להכללה עבור מצב א' ומצב ב' זהים. המטרה היא להשתמש בקבוצות שמייצגות את התנועה הרגילה ב-Chrome, כל עוד הן תומכות בממשקי ה-API של ארגז החול לפרטיות ובשיטת התיוג, כי חלק מהגדרות הלקוח לא תואמות. לצורך הניסוי, חשוב להשוות רק תנועה שמסומנת בתווית תנועה אחרת שמסומנת בתווית. התכונה 'הגנה על מעקב' מופעלת אצל משתמשים במצב ב', ולכן הם מקבלים התראה לגבי התכונה הזו.
שיפור API	האם אפשר לכלול את הפרמטר 'lifetimeM' כנכס ישיר בקריאה ל-joinAdInterestGroup או לנהל אותו כארגומנט נפרד?	אנחנו שוקלים בקפידה משוב מקהילת פיתוח האתרים לגבי הפונקציונליות שלjoinAdInterestGroup במסגרת הצעת ה-PA API. נקודת דיון מרכזית מתמקדת בשיטה האופטימלית לניהול משך החיים של IG. אנחנו מעריכים את היתרונות של טיעון נפרד לפרמטר "lifetimeMs", מכיוון שהוא מקדם גמישות ויכולת התאמה לשיפורים פוטנציאליים עתידיים במפרט. כאן אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	פוטנציאל לעלייה בשיעורים שליליים שקריים במסגרת PA API עקב התנגשויות עם מזהי דפדפן עם אנטרופיה נמוכה.	צוות Chrome מעורב באופן פעיל בצמצום המתמשך של מסגרת ה-PA API. אנחנו מעריכים את הדיון על שיעור שלילי שעלול להיות כוזב בגלל התנגשויות בין מזהי הדפדפן. אנחנו מעריכים את המשוב הזה בקפידה, ונפעל להבטיח שהניתוחים המעודכנים משקפים באופן מקיף את כל הגורמים הרלוונטיים. המחויבות שלנו היא לפתרון שישיג את התוצאות הרצויות של פרטיות תוך שמירה על דיוק ואמינות. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	האם מזהה דפדפן עם אנטרופיה נמוכה הכרחי כדי למנוע מלקוחות לשלוח שוב ושוב בקשות 'הצטרפות' עבור אותו אובייקט במערכת של k-anonymity?	אנחנו מכירים ומעריכים את הדיון המתמשך בנוגע לשימוש במזהי דפדפנים בהטמעה של מערכות אנונימיות. אנחנו מבינים את החששות שהועלו לגבי ההשלכות הפוטנציאליות על פרטיות של מזהים כאלה. אמנם בהטמעה הראשונית שלנו נעשה שימוש במזהה אנטרופיה נמוך כמנגנון למניעת ניצול לרעה, אבל אנחנו בוחנים באופן פעיל טכניקות חלופיות, כמו אסימוני ספירה אנונימיים, שמתעדפים את פרטיות המשתמשים תוך שמירה על תקינות המערכת. אנחנו מחויבים למצוא פתרונות שמאזנים בין שימוש אחראי בנתונים לבין אמצעי הגנה חזקים על פרטיות, ואנחנו מעודדים שיח מתמשך עם קהילת המחקר. אנחנו דנים בנושא כאן ונשמח לקבל משוב נוסף.
שימוש ב-API	האם טכנולוגיית AMP (Accelerated Mobile Pages) תומכת ב-PA API.	בשלב זה, דפי AMP לא תומכים ב-PA API במקור. נשמח לקבל משוב נוסף מהסביבה העסקית אם התמיכה ב-AMP נמצאת בראש סדר העדיפויות.
שיפור API	כדאי להסיר את הסוג מבדיקות האנונימיות.	אנחנו שוקלים בקפידה את המשוב בנוגע לאופטימיזציה פוטנציאלית של מבני בקשות של k-anonymity. כדי לייעל את התהליך, אנחנו מבינים את ההצעה לאחד פרמטרים ולאחד סוגים באופן פוטנציאלי. המטרה שלנו היא להבטיח יעילות ותחזוקה, ואנחנו שוקלים את כל האפשרויות בזמן שאנחנו ממשיכים לפתח את פתרונות הפרטיות שלנו. כאן אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	בקשה למנגנון למשתמשים פחות טכניים כדי להציג ולנהל בקלות את ה-IG שאליו הם שייכים, כולל אמצעי בקרה אפשריים ברמת האתר לביטול ההסכמה.	אנחנו מכירים בחשיבות של מתן כלים ידידותיים למשתמש להבנה וניהול של IG. שקלנו בקפידה שיטות שונות וגילינו שזיהוי IG על ידי האתר שאליו צורפו מאפשר ליצור את האיזון הטוב ביותר בין בהירות והגנה על הפרטיות. נכון לעכשיו, הניהול הגלובלי של IG נמצא בהגדרות של Chrome. אנחנו מחפשים כל הזמן דרכים לשפר את חוויית המשתמש באזור זה. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
בטיחות API	האם PA API חשוף לדליפות פרטיות דרך אינטראקציות עם מודעות קריאייטיב, גם בהקשר של Fenced Frames?	אנחנו מודעים לאפשרות של דליפת מידע דרך אינטראקציות מתוחכמות עם מודעות. אנחנו בוחנים באופן פעיל את האינטראקציה בין Fenced Frames, PA API ווקטורי תקיפה פוטנציאליים. הפחתת סיכוני הפרטיות נמצאת בראש סדר העדיפויות שלנו, ואנחנו מחויבים לפיתוח פתרונות חזקים שמאזנים בין החדשנות לבין ההגנה על המשתמשים. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
זמן אחזור	האם ברירת המחדל של הזמן הקצוב לתפוגה של 50 אלפיות השנייה היא ערך מציאותי ללוגיקת הבידינג של הקונה?	אנחנו מודעים לחששות שהועלו לגבי אפשרות לחוסר עקביות בין המפרט לבין התזמון של בקשות הרשת בנוגע ללוגיקת הבידינג. אנחנו בודקים באופן פעיל את המפרטים כדי להבטיח שהם מדויקים, ובוחנים את הגדרות ברירת המחדל האופטימליות של הזמן הקצוב לתפוגה כדי לאזן בין הביצועים וההיתכנות. כאן אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף.
מאמרי עזרה	דליפת תזמון פוטנציאלית במפרט שבעזרתה אתר יכול להסיק אם מודעה נכשלה בסף k-אנונימיות, ואת ההשלכות האפשריות על מעקב באתרים שונים.	אנחנו מזהים את הבעיה שנוצרה בנוגע לדליפה אפשרית של תזמון. אימתנו אי-התאמה במפרט ונוקטים צעדים כדי להבטיח שסטטוס 'k-אנונימיות' של מודעות ייקבע לפני המכרז כדי למנוע הדלפות כאלה. אנחנו מתייחסים לחששות האלה ברצינות, ונעדכן את המפרט כך שישקף את השינויים האלה. כאן אנחנו דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	דרכים להטמעת רשימת חסימה של SSP בתוך PA API.	אנחנו מכירים בצורך של מנגנונים לניהול הגבלות על מודעות על ידי SSP. מומלץ לבחון פתרונות שנותנים עדיפות להערכה במכשיר ולנצל את המטא-נתונים הקיימים של המודעות כדי להגן על פרטיות המשתמשים, ובמקביל לאפשר גמישות. אנחנו מחויבים לעבודה עם מפתחים כדי לזהות גישות אופטימליות ב-PA API. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	האם מישהו יכול להורות לדפדפן שלו להתחזות ל-PA API באופן שאתרים לא יכולים לזהות?	אנחנו מכירים בכך שבאופן הנוכחי, ניתן יהיה לזהות אתרים שאפשר לבטל את ההסכמה ל-PA API. אנחנו עובדים באופן פעיל על תכונות כמו 'הצעות מחיר נוספות' ו'טירגוט שלילי', יחד עם עיבוד של Fenced Frames, כדי לשפר את הפרטיות וכדי לספק אפשרויות ביטול הסכמה שלא ניתן לזהות. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
מצב A/B Testing	התנועה במרכזי הנתונים מתיימרים להיות טיפול 1.1.	צוות Chrome אישר עם צוות GAM שהתנועה הזו מסוננת עכשיו מהניסוי. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	יעילות והגינות של הטמעתinterestGroupBuyers ב-PA API.	אנחנו מכירים בדיון המתמשך על היעילות וההוגנות של השדה "interestGroupBuyers" במכרזים של PA API. אנחנו מכירים בהבדלים בין יעילות, פרטיות והוגנות בשוק. אמנם מפיצים צריכים לנהל את הקשרים העסקיים עם הקונים, אך אנחנו בוחנים דרכים לשיפור תהליך ההתאמה. אלה יכולות לכלול התאמות דינמיות שמבוססות על נתונים בזמן אמת ועל מודלים היברידיים. אנחנו ממשיכים להיות מחויבים למצוא פתרונות ששומרים על פרטיות המשתמשים ותומכים בסביבת פרסום תחרותית. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	בעיות אפשריות בזיכרון ובהירות של ממשק המשתמש שקשורות ל-IG ב-Chrome.	אנחנו מבינים את החששות שהועלו לגבי הצגת IG בכלי הפיתוח. בעוד שהתצוגה הנוכחית משקפת את כל אירועי ה-IG לצורך מעקב היסטורי, אנחנו מכירים בחשיבות של מתן תמונה ברורה יותר לגבי המצב הנוכחי של IG מאוחסנים. נבדוק אופטימיזציות ושיפורים אפשריים בממשק המשתמש כדי לשפר את תובנות המפתח. ההטמעה של IG נועדה למנוע דליפות זיכרון, אך אנחנו עוקבים באופן קבוע אחר השימוש במשאבים ומשפרים אותו. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
מאמרי עזרה	המפרסם המקורי נתקל בשגיאה במהלך ניסיון להשתמש בגדלים של מודעות בעלות שם ישירות בשדה "sizeGroup" בפונקציה "joinAdInterestGroup". הם רוצים לדעת אם זו התנהגות מכוונת.	בעזרת הפונקציה 'joinAdInterestGroup', אנחנו מזהים את הערך של ייעול תצורת המודעות. אנחנו פועלים לטיפול במגבלה הזו ומתכננים להפעיל את הפונקציונליות הזו בעדכונים עתידיים. שיפור זה תואם למחויבות שלנו לספק למפתחים כלים גמישים ויעילים לניהול מודעות. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
תווית בדיקה בסיוע Chrome	לבקש נתונים ישירים לגבי מצב א' לעומת מצב ב' ותוויות מדויקות ב- sendReportTo, כדי שנוכל לעקוב אחר הניסוי באופן עקבי.	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף
מאמרי עזרה	האם שם הדומיין של המפיץ נכלל בבקשות שנשלחות לשרת המהימן של המפיץ, למטרות אימות?	אנחנו מאשרים שהשמטה הראשונית של פרמטר שם המארח ממסמכי התיעוד של Protected Audience KV Server API. אנחנו רוצים להבטיח למפתחים ששם הדומיין של המפיץ נכלל באופן אוטומטי בבקשות לשרת המהימן של המפיץ. הפונקציונליות הזו חיונית לתהליכי אימות יעילים של מודעות. עדכנו את המסמכים כדי לטפל בפיקוח הזה, ונמשיך לתת עדיפות לבהירות ולשקיפות של קהילת המפתחים. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	שיטות אפשריות להכללת השם IG בקריאות למעקב אחר חשיפות של מודעות למטרות דיווח.	אנחנו מחויבים לאזן בין הצורך במנגנוני דיווח חזקים לבין העיקרון הבסיסי של פרטיות המשתמשים. ההכללה של שמות IG במעקב חשיפות של מודעות כפופה לאמצעי הגנה מסוג k-anonymity שנועדו למנוע את הזיהוי של אנשים. נמשיך לבחון פתרונות דיווח חדשניים במסגרת אילוצי פרטיות אלו. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
תכונת API	בקשה לאפשר לשרת המהימן של הקונה לקבל כותרות HTTP של רמזים ללקוח.	אנחנו עוקבים אחרי הבקשה הזו לתכונה כאן.
שימוש ב-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	לרכז את הדיווח על פעילות הבידינג בכל ה-IG של DSP תוך שמירה על פרטיות המשתמשים.	פרטיות המשתמשים נמצאת בראש סדר העדיפויות שלנו במהלך התכנון של PA API. דיווח ישיר על אירועים נפרדים לבידינג לא מעשי עקב סיכוני מעקב באתרים שונים, אבל אנחנו מציעים מנגנונים כמו 'אחסון משותף' ו'צבירה פרטית'. הם מאפשרים לספקי DSP לקבל תובנות מצטברות לגבי פעילות הבידינג, באופן ששומר על פרטיות המשתמשים.
שימוש ב-API	האחזור מ- sendReportTo() ב- reportResult() מתבצע רק 94% מהזמן ביחס לרישום אחזור אצל forDebuggingOnly.reportAdAuctionWin().	התזמון של שתי כתובות ה-URL לא זהה, אבל ייתכן שהאחזור של שתי כתובות ה-URL בו-זמנית. במקרים מסוימים, ה-worklet של מוכר הרכיב נמחק וצריך לטעון אותו מחדש כדי להריץ את הפונקציה reportResult() . עם זאת, הזמן שלוקח לאחזור לוגיקת הציון או הזמן שנדרש לטעינת ה-worklet מחדש לא משפיעים על הזמן הקצוב לתפוגה של 50 אלפיות השנייה עבור reportResult(). חשוב לזכור ש-Chrome ישתמש בכותרות שמירה במטמון כדי להגדיר את התנהגות האחזור במקרים שבהם צריך לטעון מחדש את ה-worklet. מידע נוסף על השלבים במכרז של מודעות בהתאמה אישית (PA) זמין כאן.
אנונימיות-K	בקשה לאישור שהשם של קבוצת תחומי העניין לא משפיע על האנונימיות של k להצגת מודעות.	כדי שקריאייטיב ייחשב כ-k-אנונימי, הצירוף של כתובת ה-URL של הבעלים של ה-IG, כתובת ה-URL של סקריפט הבידינג, כתובת ה-URL של הקריאייטיב וגודל המודעה חייבים לעמוד בסף שצוין (k) במהלך תקופת זמן קודמת (w). סטטוס k-anonymity מתעדכן מדי פעם (p).
ממשק המשתמש של Chrome	הצעה לספק את סוג "החשיפה הפנימית" שהרבה מסגרות (frameworks) של MVC, של ORM וכו' מציעות. למשל, מתחילים ברישום פשוט של אירועים פנימיים נבחרים לחלונית חדשה בקטע 'כלים למפתחים' --> הקטע 'אפליקציה' -->	אנחנו דנים בהצעה כאן ונשמח לקבל משוב נוסף.
ממשק המשתמש של Chrome	בהצטרפות ל-IG בכלי פיתוח לא מוצגים רכיבים שקשורים לעדיפות.	טיפלנו בבעיה כאן.
שיפור API	עדיף לאפשר לשרת מודעות הקריאייטיב לעקוב אחר האירועים שלו. האם ניתן להגדיר רשימה של דומיינים מורשים למעקב?	שיתפנו הצעה כאן ונשמח לקבל משוב נוסף מהסביבה העסקית.
בקשת תכונה ל-API	האם ניתן להרחיב את PA API כך שיתמוך בעסקאות מדיה שאינן RTB ולתחזק תרחישים קריטיים של שימוש, כגון הצגת מודעות ו'כלי אופטימיזציית נתונים (DCO)'?	כאן אנחנו דנים בנושא, ונשמח לקבל משוב נוסף.
הזמן הקצוב לתפוגה של מכרז של בעל תוכן דיגיטלי	בעלי תוכן דיגיטלי צריכים לשלוט במשך המכרז כדי למנוע אובדן חשיפות, במיוחד בהגדרות של בידינג לכותרת שבהן המודעות נבחרות ברצף.	אנחנו מכירים בחשיבות של מתן שליטה פרטנית על פרקי הזמן הקצובים לתפוגה של מכרזים של מודעות. אנחנו בוחנים באופן פעיל איך להטמיע מנגנון גלובלי של זמן קצוב לתפוגה של מכרז, שעשוי להיות בתוך האובייקט "auctionConfig", תוך שקלול מקרי הקצה. מטרת התכונה הזו היא לבצע אופטימיזציה לשיעורי מילוי ההופעות עבור בעלי אתרים, ואנחנו נמשיך לשתף פעולה עם הקהילה כדי למצוא את הפתרון הטוב ביותר. כאן אנחנו דנים בנושא, ונשמח לקבל משוב נוסף.
שיפור API	העיצוב הנוכחי של IGs ב-PA API מוביל לגדלים גדולים של מטא-נתונים עקב כתובות URL ארוכות לעיבוד. הבודקים מעוניינים בדרך לדחוס את כתובות ה-URL האלה כדי לשפר את היעילות.	אנחנו מכירים בחשיבות של אופטימיזציה של גודל המטא-נתונים של IG, במיוחד במכרזים של מודעות עם חשיבות ליעילות. אנחנו מאמינים שפתרון מבוסס-תבנית לדחיסת כתובות אתר מציע פוטנציאל משמעותי. אנחנו נבדוק בקפידה את עיצובי התבניות המוצעים ונוודא שכל פתרון מוטמע כולל מנגנונים יעילים למניעת ניצול לרעה, כדי לשמור על יציבות הדפדפן. שיתוף הפעולה עם קהילת תקני האינטרנט כדי לפתח את הגישה האופטימלית, מתוך מחשבה על שיקולים אלה, נשאר בעדיפות עליונה. כאן אנחנו דנים בנושא, ונשמח לקבל משוב נוסף.
שימוש ב-API	בודקים שמטפלים בפורמטים של מודעות מותאמות רוצים לבצע אופטימיזציה של תהליך המכרז של ארגז החול לפרטיות באמצעות אחזור של כמה תוצאות של מודעות בשיחה אחת, כדי להפחית את העומס על הרשת ולשפר את מהירות עיבוד המודעות.	אנחנו מבינים את החששות לגבי הביצועים שהועלו בנוגע לעיבוד של מודעות מותאמות בארגז החול לפרטיות. אנחנו מחויבים למצוא איזון בין יעילות לאמצעי הגנה חזקים על פרטיות המשתמשים. החזרה של מספר מודעות עם ציונים מלאים פוגעת בפרטיות, אבל אנחנו בוחנים באופן פעיל דרכים לאופטימיזציה של תהליך המכרז. אנחנו מחויבים לשיפור התמיכה של PA API בפורמטים של מודעות מותאמות, ובוחנים מנגנונים חלופיים לשיפור היעילות במסגרת אילוצי פרטיות מחמירים של ארגז החול לפרטיות. כאן אנחנו דנים בנושא, ונשמח לקבל משוב נוסף.
שימוש ב-API	גמישות באופן שבו הצעות המחיר למודעות מדורגות וממוינות בתוך ארגז החול לפרטיות, במיוחד כדי לייצג רמות עדיפות או כללים של שוק פרטי.	אנחנו מבינים את הצורך בשליטה מדויקת על דירוג המודעות ועל מיון המודעות בארגז החול לפרטיות, במיוחד בתרחישים מורכבים של בידינג. אנחנו מכירים בפתרונות שהוצעו באמצעות ttup ופונקציות מתמטיות כדי להשיג ניקוד רב-ממדי בלי לפגוע בפרטיות המשתמש. הגישות האלה עשויות אמנם להוסיף מורכבות למפתחים, אבל הן מספקות את יכולת ההבעה הנדרשת. אנחנו מחויבים לבדוק דרכים לייעל את התהליכים האלה, אולי באמצעות פונקציות או הנחיות מסייעות, כדי להבטיח שימוש אופטימלי בתכונות של ארגז החול לפרטיות ללוגיקה מתקדמת של מכרז. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
reportEvent()	להוסיף אירוע שמור חדש (למשל, משׂואת רשת (beacon) אוטומטית) שהופעל על ידי הדפדפן לאחר אתחול מסגרת עם קריאייטיב של מודעה.	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף.
adCost	מאפשר פירוט של adCost.	כל ערך של עלות הוא הזדמנות לשלוח כמות מוגבלת של מידע מחוץ למכרז. אם תאפשר רשימה שלמה של N של העלויות האלה, תוכל לשלוח מזהה משתמש שלם וכך לאפשר מעקב חוצה-אתרים. אנחנו דנים בנושא כאן ונשמח לקבל משוב נוסף.
resolveToConfig	האם צריך לעבור בירושה ל-resolveToConfig מהרמה העליונה ולחשוף אותו ב-browserSignals?	אנחנו דנים בבקשה הזו כאן ונשמח לקבל משוב נוסף.
כלים משופרים	האם יש משהו שדומה ל-chrome://topics-internals אבל ל-PA API?	אין שום דבר שזה בדיוק אותו הדבר. עם זאת, יש כלים נרחבים למפתחים של PA API.
Labels (תוויות)	האם Chrome יכול להשתמש בתוויות כדי לזהות את קהל ה-20% k-anon?	אנחנו שוקלים את הבקשה הזו, ונשמח לקבל משוב נוסף מהסביבה העסקית.
מאמרי עזרה	האם סביבות עבודה של מכרזים של ארגז חול לפרטיות יהפכו לסוגי worklet רגילים?	בגלל דרישות פרטיות ואבטחה ייחודיות, ה-worklets האלה שונים בצורה משמעותית מסוגי worklet הרגילים של הדפדפן, ולכן אנחנו לא צופים שהם יהפכו בקרוב לסוגי worklet רגילים במפרט ה-HTML. אנחנו מחויבים לשפר את משאבי המפתחים שלנו עם הסברים ברורים לגבי סביבת ההטמעה והביצוע של worklet של מכרזים, כדי שהמידע הזה יהיה נגיש יותר למשתתפי ארגז החול לפרטיות. דיברנו על הנושא כאן.
שרת Turn-Your-Own-Server (BYOS) Key-Value (KV)	הצדדים יוכלו ללמוד כמה IG (מאותו בעלים) שהצטרפו אליהם באמצעות שאילתות של שירותי KV בהגדרת שירות BYOS KV.	זה לא יהיה אפשרי יותר כששרתי KV פועלים בסביבת TEE ונוכל להבטיח שהם עומדים בדרישות של מודל האמון שפורסם.
userBiddingSignals	מעדכנים חלק מקטע "userBiddingSignals" תוך שמירה על חלק אחר.	זה כבר אפשרי ללא צורך בשינויים ב-API.
שימוש ב-API	הטמעת מכסת תדירות ב-IG מרובים בארגז החול לפרטיות, אולי באמצעות שרת KV או בנתוני "prevWinsMs" שעברו שינוי.	אנחנו מבינים את הרצון שלנו להשתמש ביכולות מתקדמות של מכסת תדירות במסגרת ארגז החול לפרטיות. אנחנו מכירים בכך שההגבלות הנוכחיות על שיתוף נתונים בין IG עלולות להציב אתגרים במהלך יישום האסטרטגיות האלה. למרות ששרת ה-KV מספק מנגנון פוטנציאלי עם אמצעי הגנה הולמים על הפרטיות, אנחנו ממליצים למפתחים לבדוק פתרונות במסגרת מודל IG יחיד. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.
שימוש ב-API	אתרי מכירה של רכיבים (אלה שמשתתפים במכרזים בתוך ארגז החול לפרטיות) צריכים לעיין במידע על הזמן הקצוב לתפוגה של מכרזים ברמה העליונה כדי לבצע אופטימיזציה של ההגדרות האישיות שלהם ולמנוע עיכובים מיותרים.	ברור לנו שיש צורך בתיאום משופר בין אתרי מכירה ברמה העליונה לבין אתרי מכירה של רכיבים בארגז החול לפרטיות. אנחנו בודקים כרגע את האפשרות להוסיף מנגנונים חדשים של זמן קצוב לתפוגה, כולל זמן קצוב לתפוגה של כל המכרז, ובוחנים דרכים להחיל את הזמן הקצוב לתפוגה ברמה העליונה במכרזים של רכיבים. המטרה שלנו היא לשפר את היעילות ואת יכולת החיזוי לכל המשתתפים בתהליך המכרז של ארגז החול לפרטיות. כאן דנים בנושא הזה ונשמח לקבל משוב נוסף.

שירותי קהלים מוגנים

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

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

Attribution Reporting (וממשקי API אחרים)

נושא משוב	סיכום	התגובה של Chrome
אופטימיזציה ידנית של קמפיינים	ב-ARA אין תמיכה באופטימיזציה ידנית של קמפיין.	דיברנו על התרחיש הזה עם טכנולוגיות הפרסום וראינו דרכים שבהן אפשר להשתמש ב-ARA כדי לתמוך באופטימיזציה ידנית של קמפיינים. פיתחנו את ARA באופן שמאפשר התאמה אישית של טכנולוגיות פרסום וגמישות כדי לפתור מגוון תרחישים לדוגמה של פרסום דיגיטלי. קיבלתי כמה הצעות באמצעות שימוש בהגדרות גמישות שונות ברמת האירוע ושימוש בדוחות ברמת האירוע עם דוחות סיכום כדי להפחית את ההשפעה של רעש, ולהשיג את צורכי האופטימיזציה הידניות והאוטומטיות שלהם. אנחנו פתוחים לקבלת משוב נוסף לגבי הסביבה העסקית בנוגע להתאמה אישית ולגמישות של הגדרות ARA.
סוג המרה	Google מאפשרת רק שמונה סוגי המרות, וזו מגבלה.	הטמענו את רוב הדיווח הגמיש ברמת האירוע, מה שמאפשר לטכנולוגיות הפרסום גמישות נוספת מבחינת מספר החלונות לדיווח, מספר דוחות השיוך (Attribution) ונתוני הטריגרים שאפשר להשתמש בהם. טכנולוגיות הפרסום יכולות לבחור הגדרה שמאפשרת למדוד עד 32 סוגי המרות שונים.
מגבלת אירועים בדוח אגרגטיבי	מפרסמים קטנים יותר עם תקציב מוגבל לא יכולים להגדיר לפחות 20 אירועי המרה לכל דוח ניתן לצבור.	לא נדרש מספר מינימלי של אירועי המרה לכל דוח נצבר. בנוסף, יש כמה החלטות בנוגע לעיצוב שאפשר לקבל כדי לבצע אופטימיזציה של דוחות מצטברים למפרסמים קטנים. למשל, שינוי המבנה או המאפיינים של המפתח שאחריהם מתבצע מעקב, בדיקת רמות שונות של אפסילון, בדיקת תדירויות קיבוץ ארוכות יותר ובדיקת הקצאות שונות של תקציבים בין יעדי מדידה. כמו כן, ניתן להשתמש בדוחות קטנים יותר ברמת המודעה כדי לשלב דוחות סיכום ברמת האירוע, וכן לבצע בדיקות מסכמות ברמת המפתח.
נתונים בזמן אמת	היעדר נתונים בזמן אמת מפלטפורמות DSP (למשל, על קליקים, ביקורים והמרות), שספקי DSP משתמשים בהן כדי להתאים את אסטרטגיית הצעת המחיר ולשפר את יעילות הקמפיין, מנוגדים למחויבות לתחזק את הפונקציונליות הקיימת.	גם עם ARA, קליקים וסשנים נותרים בזמן אמת, וההמרות תמיד מתבצעות לאחר מעשה, גם במחשבים עם 3PC.
שדות חסרים	חסרות דרישות בשדה 'השקה של אירוע גמיש מלא': i) בשדה 'מטבע' ובשדה 'מזהה הזמנה' / 'מזהה עסקה'.	אנחנו לא מתכננים לתמוך בשדה 'מטבע' או בשדה 'מזהה הזמנה' / 'מזהה עסקה' כחלק מרמת האירוע הגמישה המלאה, כי כבר יש דרכים לעשות זאת באמצעות הדיווח הנוכחי ברמת האירוע. אנחנו פתוחים לקבלת משוב נוסף לגבי השדות האלה, ונשקול מחדש אם יש תרחישים לדוגמה נוספים שמחייבים את השדות האלה. הדרכים שבהן אפשר להשתמש בעיצוב הנוכחי של ARA כדי למדוד מידע על סוגי המטבע ומזהי ההזמנות: 1. על סמך המשוב, המטבע נקבע לפי המיקום הגיאוגרפי של המשתמש, ואפשר להוסיף אותו כחלק מה-source_event_id כדי לקבוע באיזה מטבע נעשה שימוש. 2. על סמך המשוב שקיבלנו, השדה של מזהה ההזמנה נדרש כדי להבטיח שהמרות וערכים לא ייספרו בטעות בטעות. אפשר לעשות זאת באמצעות מפתחות לביטול כפילויות.
תקציב פרטיות	תקציב הפרטיות של ARA מגביל את היכולת לבצע מדידה בכמה מאפיינים	העיצוב של ARA מאפשר לטכנולוגיות פרסום להתאים אישית את ההגדרות האישיות של ARA כדי לכסות מגוון של תרחישי שיוך. הטכנולוגיות הקיימות של מודעות עיצוב של ARA יצטרכו לחשוב על הבחנה בין המאפיינים שהכי קריטיים למדידה לבין ההשפעה של רעש על הנתונים. הוספת רעש לנתונים, בהתאם לרמת הפירוט של המאפיינים שנמדדים, היא חיונית לשמירה על הפרטיות. אנחנו פתוחים לקבלת משוב נוסף על הסביבה העסקית בנוגע ליכולת לבצע מדידה במאפיינים שונים, אבל עלינו להבין תרחישים ספציפיים לדוגמה שדורשים את המדידה הזו.
עדכון המפרט	לדברי Google, היא עברה מחלונות קבועים לדיווח על אירועים גמישים, אבל הדבר לא השתקף במפרטים הטכניים של Google, שכרגע יש להם חלון זמן מינימלי של שעה אחת.	נכון לעכשיו, דיווח גמיש ברמת האירוע מאפשר לטכנולוגיות פרסום לשנות את מספר דוחות השיוך לכל אירוע מקור, את החלקים של נתוני ההפעלה ואת המספר/האורך של חלונות הדיווח. ל-ARA עדיין יש חלון דיווח של שעה אחת לפחות לדוחות ברמת האירוע. חלון הדיווח הזה חיוני כדי לשמור על הפרטיות ולצמצם את ההתקפות של סוגים מסוימים של מתקפות שחזור ההיסטוריה. דוחות הסיכום מספקים מידע מצטבר, ולכן טכנולוגיות פרסום יכולות להביע הסכמה לקבלת דוחות נצברים באופן מיידי וללא עיכובים, בהתאם לתרחישי השימוש שלהם.
עיצוב API	חשש שצמצום המידע בדוחות ההמרות והוספת רעשי רקע עלולים להשפיע על המערכת האקולוגית יותר מאשר על Google.	Google התחייבה ל-CMA כדי לתכנן וליישם את ההצעות של ארגז החול לפרטיות באופן שלא יגרום לשיבוש התחרות על ידי העדפה עצמית של העסק של Google, ותוך התחשבות בהשפעה על התחרות בפרסום בדיגיטל ועל בעלי תוכן דיגיטלי ומפרסמים בכל הגדלים.
תיקון ייחוס	ARA לא מאפשר לספק הטכנולוגיה לשלוט בשיוך הנכון ולאמת אותו.	יש הרבה פתרונות ב-ARA שמאפשרים אימות: 1. טכנולוגיות פרסום יכולות לוודא שהתנהגות ARA תואמת את הציפיות שלהן: – הקוד בצד הלקוח של ARA הוא קוד פתוח. – הקוד בצד השרת של ARA הוא גם קוד פתוח, והמתאמים מוודאים שרק גרסאות מותרות של שירות צבירה יכולות לפענח ולעבד דוחות מצטברים. 2. Chrome סיפק לטכנולוגיות של מודעות ספריית סימולציות כדי לאמת את התנהגות השיוך (Attribution). כך טכנולוגיית המודעות יכולה לבדוק איך ARA מבצע שיוך בסביבה מדומה. 3. ARA תומך במספר אותות של ניפוי באגים שעוזרים לבדוק אם התרחש או לא, ומדוע לא התרחש עיבוד צפוי.
(דווח גם ברבעונים הקודמים) רעש	משוב על כך שרמת ה"רעש" גבוהה מדי ושמשפיעה על יעילות הדיווח.	שוחחנו עם טכנאי פרסום עם המשוב הזה, ומצאנו דרכים שבהן ניתן להתאים אישית את ARA כך שיתאימו יותר לתרחישי השימוש שלהם, גם עם רעש. יש לנו מסמכי תיעוד למפתחים שכוללים את רוב ההחלטות בנושא עיצוב והתאמות אישיות שעליהן שוחחנו עם טכנולוגיות הפרסום. ARA תוכנן באופן שמאפשר לטכנולוגיות של מודעות להתאים אישית את ההגדרות של ARA כדי לכסות תרחישי שיוך שונים. אבל טכנולוגיות הפרסום יצטרכו לחשוב על הבחנה בין המאפיינים שהכי קריטיים למדידה לבין השפעת הרעש על הנתונים שלהם. אנחנו פתוחים לקבלת משוב נוסף על הסביבה העסקית בנוגע להשפעה של רעש, ויכול לספק הנחיות נוספות לגבי רכיבי ARA שבהם אפשר להשתמש כדי לשנות את השפעת הרעש.
שיוך (Attribution) חוצה-דומיינים	איך עוקבים אחרי שיוך (Attribution) בכמה דומיינים?	טכנולוגיות הפרסום יכולות להפנות אוטומטית לכתובות URL שונות של דיווח כדי לפתור את הבעיה הזו. אנחנו פתוחים לקבלת משוב נוסף על הסביבה העסקית בנוגע להיבט העיצוב הזה של ARA.
שיפור API	משנים באופן קבוע את גורם קנה המידה שמשמש לרישום שיוך לדוחות סיכום של ARA.	בהמשך לשיחה שלנו ב-GitHub, נראה שטיפול בגורמים מרובים של התאמה לעומס (scaling) בשירות צבירה (Aggregation) ככל הנראה יגרום להוספה של כמות גדולה יותר של רעש לדוחות סיכום בהשוואה לפונקציונליות הנוכחית. אנחנו פתוחים למשוב נוסף לגבי הצורך בגורמים למדידת התאמה כחלק מדוחות נצברים, אבל רוצים לציין את הפשרה הפוטנציאלית בהגברת הרעש. אנחנו גם בודקים אם תכונות אחרות של ARA בעתיד יעזרו לפתור גם את התרחיש הזה.
שימוש ב-API	הזדמנות לאחד את האופן שבו אירועי שיוך משותפים עם כל המשתתפים. אפשרות זו מועילה ל-SSP, ל-DSP וכו'.	אנחנו מתכננים לסנכרן עם טכנולוגיות הפרסום כדי להבין טוב יותר את המשוב שקיבלנו ואת המגבלות שחלות עליו.
בדיקת נפח התנועה	האם תנועת הבדיקה במצב B יציבה בכל Chrome?	ההכללה בקבוצת ניסוי לא מושפעת מהגדרות Chrome (ללא קשר להגדרות אלה).
מאמרי עזרה	תמיכה ב-ARA לפיקסלים.	פרסמנו מידע שמסביר איך לתמוך בתרחיש לדוגמה הזה, ונשמח לקבל משוב נוסף מהסביבה העסקית.
שימוש ב-API	יכול להיות שלא יתבצע שיוך של ARA למקור הנכון של אתרי מכירה מצד שלישי בפלטפורמות מסחר אלקטרוני אם ההמרה לא בוצעה לפני המגע האחרון.	חברות יכולות להשתמש במסננים כדי למנוע שיוך שגוי (כלומר לא יופק דוח המרות). בנוסף, כדי לעזור בתרחיש לדוגמה הזה, אנחנו עובדים על הצעה לסינון לפני שיוך.
תמיכה בדפדפן	האם יש תמיכה ב-ARA בדפדפנים שונים?	אנחנו מזמינים דפדפנים אחרים לאמץ את ממשקי ה-API של ארגז החול לפרטיות, וממשיכים להקדיש זמן לדיון בגישה שלנו במסגרת העבודה הפתוחה ב-W3C. ציינו במפורש את יכולת הפעולה ההדדית כמטרה לספק את ARA והעיצוב של ARA צריך להיות תלוי דפדפנים, עם ערכים גמישים שהוגדרו על ידי ספקים עבור ספקים עם עמדות פרטיות שונות. דפדפנים אחרים בוחרים לספק סביבה עסקית חלופית של פרטיות, שבעזרתה ניתן לספק שירותים שונים לשמירה על פרטיות המשתמשים. אנחנו מעודדים את Microsoft Edge ציינו שהוא יתמוך ב-ARA.
שימוש ב-API	מהו סוג המקור הצפוי להרשמות של מקורות ARA ל-registerAdBeacon/reportEvent (ולNavigation_start/commit automatic beacons)?	תלוי אם איתות Bluetooth הוא אוטומטי או ידני: - שמור.* (כלומר, אירועים אוטומטיים) יהיו מסוג מקור הניווט. - אירועים שהופעלו ידנית כך שיהיו מסוג 'מקור האירוע'.
שימוש ב-API	האם המגבלה המקסימלית של 20 דוחות נצברים לכל מקור היא לכל אירוע מקור? האם המגבלה היא גלובלית או יומית? האם יש לכם כוונה להגדיל את המגבלה?	המגבלה של 20 דוחות נצברים לכל מקור היא מגבלה גלובלית, שלפיה אפשר ליצור 20 דוחות נצברים לכל מקור. המגבלה נקבעת על ידי הדפדפן ולא ניתן להגדיר אותה. מטרת המגבלה הזו היא למנוע ניצול לרעה של ההגנה על דוחות שיוך אמיתיים עם דוחות ריקים. דיברנו על הנושא כאן.
שימוש ב-API	תמיכה בשיווק באימייל באמצעות ARA.	נכון לעכשיו אין תמיכה ישירה עבור התרחיש הזה ב-ARA (אם אין לכם שליטה באתר אירוח האימייל). אנחנו דנים בנושא כאן ונשמח לקבל משוב נוסף.
Epsilon	מתי ייקבע הערך של אפסילון עבור ה-API המצטבר?	לטכנולוגיות פרסום אפשר להגדיר את הערך הנוכחי של אפסילון עד לסף שנקבע מראש, כפי שהוגדר על ידי ארגז החול לפרטיות (כרגע 64). מומלץ לבדוק ערכי אפסילון שונים ולזהות נקודות הטיה לתרחישים לדוגמה שונים ולתת משוב. נקפיד להודיע מראש לטכנולוגיות הפרסום לפני כל שינוי בטווח הערכים של אפסילון.
שיפור API	לתמוך בתרחיש לדוגמה שבו המפרסם יכול להוסיף מזהה לשדה trigger_data לצורך התאמה לנתונים חיצוניים של ניהול קשרי לקוחות (CRM), כדי לאפשר למפרסמים לאמת את איכות ההמרות.	אנחנו דנים בבקשה, ונשמח לקבל משוב נוסף כאן.
שימוש ב-API	איך לטפל בכתובות URL להפניה אוטומטית ככתובות יעד.	טכנולוגיות פרסום יכולות לבצע אחת מהפעולות הבאות: 1. מוסיפים את כתובת היעד הסופית בשדה היעד. 2. בשדה יעד אפשר להזין עד 3 כתובות URL, מה שמאפשר להזין כמה כתובות URL בשדה. שתי האפשרויות מחייבות לדעת מהי כתובת היעד הסופית. דיברנו על הנושא כאן .

Aggregation Service

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

Private Aggregation API

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

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

הפחתה של סוכן המשתמש/רמזים ללקוח של סוכן משתמש

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

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

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

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

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

תקציב פרטיות

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

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

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

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

ממשק API של Fenced Frames

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

Shared Storage API

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

CHIPS

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

FedCM

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

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

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

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