שירות צבירה

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

סטטוס ההטמעה

• Aggregation Service זמין עכשיו לכלל המשתמשים.
• אפשר להשתמש ב-Aggregation Service עם Attribution Reporting API ו-Private Aggregation API עבור Protected Audience API ו-Shared Storage API.

זמינות

הצעה	סטטוס
ניהול מלא בעננים שונים (גם שירות אירוח מפתחות של צדדים מרובים וגם שירות תקציב פרטיות)	חציון שני של שנת 2025
שירות תקציב לפרטיות בעננים שונים הסבר	זמין
תמיכה בשירות צבירה ל-Amazon Web Services‏ (AWS) ב-Attribution Reporting API וב-Private Aggregation API הסבר	זמין
תמיכה בשירות צבירה ב-Google Cloud ב-Attribution Reporting API וב-Private Aggregation API הסבר	זמין
הרשמה של אתרים ל-Aggregation Service וצבירה ממקורות מרובים. ההרשמה של האתר כוללת מיפוי של האתר לחשבונות בענן (AWS או GCP). כדי לצבור נתונים ממקורות מרובים, הם צריכים להיות מאותו אתר. שאלות נפוצות ב-GitHub מסמכי תיעוד של Site aggregation API	זמין
הערך של epsilon בשירות הצבירה יישמר כטווח של עד 64, כדי לאפשר ניסויים ומשוב על פרמטרים שונים. שליחת משוב על ARA epsilon שליחת משוב על 'הוספת רכיב נוסף לאתר'	זמינים. נודיע מראש לסביבה העסקית לפני שערכים של טווח האפסילון יעודכנו.
סינון גמיש יותר של תרומות לשאילתות של Aggregation Service הסבר	זמין
תהליך לשחזור התקציב לאחר אסונות (שגיאות, הגדרות שגויות וכו') הסבר	זמין מנגנון לבדיקה של אחוז המזהים המשותפים ש-AdTech משחזרת באמצעות שחזור תקציב, ולהשעיית שחזור עתידי של נתונים במקרים של שחזור מוגזם שתוכנן במחצית הראשונה של שנת 2025
Accenture פועלת כאחד מהרכזים ב-AWS בלוג למפתחים	זמין
צד עצמאי שפועל כאחד מהרכזים ב-Google Cloud בלוג למפתחים	זמין
תמיכה ב-Aggregation Service בדוחות ניפוי באגים מצטברים ב-Attribution Reporting API הסבר	זמין

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

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

מונח	תיאור
Aggregation Service	שירות שמופעל על ידי טכנולוגיית פרסום, שמטפל בדוחות שניתן לצבור כדי ליצור דוח סיכום.
דוחות נצברים	דוחות נצברים הם דוחות מוצפנים שנשלחים ממכשירים של משתמשים ספציפיים. הדוחות האלה מכילים נתונים לגבי התנהגות והמרות של משתמשים באתרים שונים. ההמרות (שלפעמים נקראים אירועי טריגר של שיוך (Attribution)) והמדדים המשויכים מוגדרים על ידי המפרסם או טכנולוגיית הפרסום. כל דוח מוצפן כדי למנוע מגורמים שונים גישה לנתונים הבסיסיים. מידע נוסף על דוחות נצברים.
חשבונאות של דוחות נצברים	ספר חשבון מבוזר שנמצא בשני התאמים, ומעקב אחרי תקציב הפרטיות שהוקצה ואכיפת הכלל 'אין כפילויות'. זהו המנגנון לשמירה על הפרטיות, שנמצא ומופעל בתוך גורמי התיאום, ומבטיח שאף דוח לא יעבור דרך שירות הצבירה מעבר לתקציב הפרטיות שהוקצה. מידע נוסף על שיטות ארגון בקבוצות ועל הקשר שלהן לדוחות שניתן לצבור
תקציב חשבונאי לדוחות מצטברים	התייחסויות לתקציב שמבטיחה שהדוחות לא יעובדו יותר מפעם אחת.
סביבת הפעלה מהימנה (TEE)	סביבת מחשוב אמינה היא תצורה מיוחדת של חומרה ותוכנה במחשב, שמאפשרת לגורמים חיצוניים לאמת את הגרסאות המדויקות של התוכנות שפועלות במחשב. TEEs מאפשרת לגורמים חיצוניים לוודא שהתוכנה עושה בדיוק את מה יצרן תוכנה טוען שהוא נכון - לא יותר או פחות. לקבלת מידע נוסף על מכשירי TEE שמשמשים להצעות של ארגז החול לפרטיות, אפשר לקרוא את הסבר על שירותי Protected Audience API והסבר על שירות הצבירה.
מתאמים	מתאם הוא ישות שאחראית לניהול מפתחות ולחשבונאות דוחות ניתנת לצבירה. המתאם מנהל רשימת גיבובים של הגדרות שירות שאושרו לצבירה ומגדיר את הגישה למפתחות פענוח.
מזהה משותף	הערך המחושב שכולל את הנתונים הבאים: shared_info, reporting_origin, destination_site (זמין רק ב-Attribution Reporting API), source_registration-time (זמין רק ל-Attribution Reporting API), scheduled_report_time, version. כלומר, כמה דוחות שייכים לאותו מזהה משותף אם יש להם מאפיינים זהים לאלה של השדה shared_info. יש לכך תפקיד חשוב בחשבונאות של דוחות נצברים. מידע נוסף על שרתי Trusted
דוח סיכום	דוח סיכום הוא סוג הדוח Attribution Reporting API ו-Private Aggregation API. סיכום כולל נתוני משתמשים נצברים, ויכול לכלול נתוני המרות מפורטים, יחד עם רעשי רקע. דוחות סיכום מורכבים מדוחות מצטברים. דוחות סיכום מאפשרים גמישות רבה יותר ומודל נתונים עשיר יותר מאשר הדוחות ברמת האירוע, במיוחד בתרחישים מסוימים, כמו ערכי המרות.
מקור הדיווח	מקור הדיווח הוא הישות שמקבלת דוחות נצברים. במילים אחרות, טכנולוגיית הפרסום שנקרא 'Attribution Reporting API'. דוחות נצברים נשלחים מאת מכשירים של משתמשים לכתובת URL ידועה שמשויכת לדיווח המקור. צריך לציין את מקור הדיווח הזה במהלך הרישום.
תרומה	דוחות נצברים עשויים להכיל מספר שרירותי של מעברים נגדיים. לדוגמה, דוח עשוי להכיל את מספר המוצרים שבהם משתמש צפה באתר של מפרסם. סכום העליות בכל הדוחות המצטברים שקשורים לאירוע מקור אחד לא יכול לחרוג מהמגבלה הנתונה, 'L1=2^16'. מידע נוסף זמין בהסבר על הדוחות המצטברים.
רעש וקלול	כמות מסוימת של רעש סטטיסטי מתווספת לדוחות הסיכום כחלק מתהליך הצבירה, וגם משמשת לשמירה על הפרטיות ולהבטחת שהדוחות הסופיים יסופקו עם נתוני מדידה אנונימיים. מידע נוסף על מנגנון רעשי תוספת, שמבוסס על התפלגות Laplace
הצהרה	אימות (attestation) הוא מנגנון לאימות זהות התוכנה, בדרך כלל באמצעות טביעות אצבע קריפטוגרפיות או חתימות. בהצעה של שירות הצבירה, האימות תואם לקוד שפועל בשירות הצבירה המופעל על-ידי טכנולוגיות פרסום לבין קוד הקוד הפתוח. מידע נוסף על אימות

מידע נוסף על הרקע של שירות הצבירה זמין במאמר ההסבר וברשימת התנאים המלאה.

תרחישים לדוגמה לצבירה

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

תרחיש לדוגמה	נקודת כניסה	תיאור
אופטימיזציה של הבידינג	Attribution Reporting API (Chrome ו-Android)	שימוש בדוחות מצטברים כדי להטמיע אותות המרה לצורכי אופטימיזציה של הבידינג.
מדידה בפלטפורמות שונות	Attribution Reporting API (Chrome ו-Android)	בעזרת יכולות המדידה באתרים ובאפליקציות תוכלו לקבל תמונה ברורה יותר של הביצועים ב-Chrome וב-Android.
דיווח על המרות	Attribution Reporting API (Chrome ו-Android)	יצירת דוחות המרות מצטברים בהתאמה לצורכי הקמפיינים של הלקוחות (כולל דוחות על המרות מסוג 'המרות מסוג 'קליק להמרה'' ודוחות על המרות מסוג 'קליק להצגת מודעה').
מדידת פוטנציאל החשיפה של הקמפיין	Shared Storage API ו-Private Aggregation API‏ (ב-Chrome)	שימוש במשתני צפיות במודעות באתרים שונים כדי למדוד את פוטנציאל החשיפה של הקמפיין.
דיווח על מאפיינים דמוגרפיים	Shared Storage API ו-Private Aggregation API‏ (ב-Chrome)	שימוש בנתונים על צפיות במודעות באתרים שונים ובמידע דמוגרפי כדי למדוד את פוטנציאל החשיפה לפי מאפיינים דמוגרפיים.
ניתוח נתיבי המרות	Shared Storage API ו-Private Aggregation API‏ (ב-Chrome)	אחסון משתני המרות וצפיות במודעות באתרים שונים כדי לבצע ניתוח מצטבר של נתיבי ההמרות.
התחזקות המותג ועלייה בהמרות	Shared Storage API ו-Private Aggregation API‏ (ב-Chrome)	דיווח על קבוצות ניסוי/בקרה ועל נתוני סקרים כדי למדוד את התחזקות המותג ואת העלייה המצטברת בנפח המכירות.
ניפוי באגים במכרזים	Protected Audience API ו-Private Aggregation API‏ (ב-Chrome)	שימוש בדוחות צבירה לניפוי באגים.
חלוקת הצעות המחיר	Protected Audience API ו-Private Aggregation API‏ (ב-Chrome)	שימוש בדוחות מצטברים כדי לתעד את ההתפלגות של ערכי הצעות המחיר במכרזים.

תהליך מקצה לקצה

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

1. אחזור מפתח ציבורי ליצירת דוחות מוצפנים.
2. דוחות מוצפנים שניתן לצבור אותם, שנשלחים לשרתים של טכנולוגיות פרסום כדי שנוכל לאסוף אותם, לבצע בהם טרנספורמציה ולקבץ אותם בקבוצות.
3. שרת טכנולוגיית הפרסום אוסף דוחות (בפורמט avro) ושולח אותם לשירות האגרגציה שנפרס. (השלמת הטופס צריכה להתבצע על ידי חברת טכנולוגיית הפרסום).
4. אחזור דוחות מצטברים לצורך פענוח.
5. אחזור מפתחות פענוח מהרכזים.
6. שירות Aggregation Service מפענח דוחות לצורך צבירה והוספת רעש.
7. שירות החשבונאות של דוחות שניתנים לצבירה בודק אם נשאר תקציב פרטיות כדי ליצור דוח סיכום של הדוחות הנתונים שניתנים לצבירה.
8. שולחים את דוח הסיכום הסופי.

בתרשים אפשר לראות את הקשר הכולל של שירות הצבירה עם ממשקי ה-API העיקריים למדידת לקוחות: Attribution Reporting API,‏ Private Aggregation API והתיאמים.

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

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

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

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

קיבוץ דוחות שניתן לצבור

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

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

רכיבי Cloud

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

שירות קצה קדמי

שירות מנוהל בענן: Cloud Function‏ (Google Cloud) או API Gateway‏ (Amazon Web Services)

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

יש שני ממשקי API ב-Frontend Service:

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

מאמרי העזרה של Aggregation Service API

Job Queue

שירות מנוהל בענן: Pub/Sub‏ (Google Cloud) או Amazon SQS‏ (Amazon Web Services)

Job Queue הוא תור הודעות שמאחסן בקשות עבודה ל-Aggregation Service. Frontend Service מוסיפה את ההודעות של בקשות העבודה לתור, ולאחר מכן Aggregation Worker משתמשת בהן כדי לעבד את בקשת העבודה.

אחסון בענן

שירות מנוהל בענן: Google Cloud Storage‏ (Google Cloud) או Amazon S3‏ (Amazon Web Services) אחסון בענן משמש לאחסון קובצי קלט ופלט ששירות האגרגציה משתמש בהם (דוגמאות: קובצי דוחות מוצפנים, דוחות סיכום של פלט וכו').

מסד נתונים של מטא-נתונים של משימות

שירות מנוהל בענן: Spanner‏ (Google Cloud) או DynamoDB‏ (Amazon Web Services)

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

Aggregation Worker

שירות מנוהל בענן: Compute Engine עם Confidential space‏ (Google Cloud) או Amazon Web Services EC2 עם Nitro Enclave‏ (Amazon Web Services)

Aggregation Worker מעבד בקשות עבודה שהתקבלו מבקשת עבודה בJob Queue, ומפענח את הקלט המוצפן באמצעות מפתחות שאוחזרו מ-Key Generation and Distribution Service (KGDS) ב-Coordinators. כדי לצמצם את זמן האחזור של עיבוד המשימות, מפתחות ההצפנה נשמרים במטמון ב-Aggregation Worker למשך 8 שעות, וניתן להשתמש בהם במשימות שמעובדות על ידי מכונה עובדת זו.

העובד פועל במכונה של Trusted Execution Environment (TEE). כל עובד מטפל רק במשימה אחת בכל פעם. טכנולוגיית הפרסום יכולה להגדיר כמה עובדים לעיבוד משימות במקביל על ידי הגדרת הגדרות התאמה אוטומטית לעומס. באמצעות התאמה אוטומטית, מספר העובדים משתנה באופן דינמי בהתאם למספר ההודעות שנותרו בתור המשימות. אפשר להגדיר את המספר המינימלי והמקסימלי של עובדים להתאמה אוטומטית בקובץ הסביבה של Terraform. מידע נוסף על התאמה אוטומטית של קיבולת זמין בסקריפטים הבאים של terraform. [Amazon Web Services / Google Cloud]

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

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

תיאור מפורט יותר של שירות הצבירה זמין במאמר ההסבר שלנו.

השלבים הבאים

אחרי שסיפקנו לכם את הנקודות העיקריות של Aggregation Service, הגיע הזמן לפרוס מכונה משלכם של Aggregation Service דרך Google Cloud או Amazon Web Services. אפשר לעיין בקטע 'תחילת העבודה'. אם אתם צריכים מידע נוסף על הפעלת Aggregation Service שנפרס, תוכלו לעבור לקישור הזה כדי לקרוא מידע נוסף על הפעלת Aggregation Service.

פתרון בעיות

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

קבלת תמיכה ושליחת משוב

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