שירות הצבירה יוצר דוחות סיכום של נתוני המרות מפורטים ומדידות של פוטנציאל החשיפה מדוחות גולמיים שניתן לצבור. לטכנולוגיות הפרסום יש שתי נקודות כניסה ראשיות לנתונים מצטברים בצד הלקוח, כדי להעביר דוחות לשירות הצבירה. הנקודות האלה הן Attribution Reporting API או Private Aggregation API.
סטטוס ההטמעה
- Aggregation Service זמין עכשיו לכלל המשתמשים.
- אפשר להשתמש ב-Aggregation Service עם Attribution Reporting API ו-Private Aggregation API עבור Protected Audience API ו-Shared Storage API.
זמינות
| Proposal | Status |
|---|---|
| Aggregation Service support for Amazon Web Services (AWS) across Attribution Reporting API, Private Aggregation API
Explainer |
Available |
| Aggregation Service support for Google Cloud across Attribution Reporting API, Private Aggregation API Explainer |
Available |
| Aggregation Service site enrollment and multi-origin aggregation. Site enrollment includes mapping of a site to cloud accounts (AWS, or GCP). To aggregate multiple origins, they must be of the same site.
FAQs on GitHub Site aggregation API documentation |
Available |
| The Aggregation Service's epsilon value will be kept as a range of up to 64, to facilitate experimentation and feedback on different parameters.
Submit ARA epsilon feedback. Submit PAA epsilon feedback. |
Available. We will provide advanced notice to the ecosystem before the epsilon range values are updated. |
| More flexible contribution filtering for Aggregation Service queries
Explainer |
Available |
| Process for budget recovery post-disasters (errors, misconfigurations, and so on)
Explainer |
Available Mechanism to review the percentage of shared IDs recovered by an ad tech using budget recovery and suspend future recoveries for excessive recoveries planned for H1 2025 |
| Accenture operating as one of the Coordinators on AWS
Developer Blog |
Available |
| Independent party operating as one of the Coordinators on Google Cloud
Developer blog |
Available |
| Aggregation Service support for Aggregate Debug Reporting on Attribution Reporting API
Explainer |
Available |
מונחים ומושגים מרכזיים
אם אתם שוקלים להשתמש בשירות הצבירה בתהליך העבודה שלכם בתחום טכנולוגיית הפרסום, המונחים והמושגים הבאים יעזרו לכם להבין טוב יותר את היתרונות של תהליך הצבירה החדש הזה לצוות שלכם:
| Term | Description |
|---|---|
| Aggregation Service | An ad tech-operated service that processes aggregatable reports to create a summary report. |
| Aggregatable Reports |
דוחות נצברים הם דוחות מוצפנים שנשלחים ממכשירים של משתמשים ספציפיים. הדוחות האלה מכילים נתונים לגבי התנהגות והמרות של משתמשים באתרים שונים. ההמרות (שלפעמים נקראים אירועי טריגר של שיוך (Attribution)) והמדדים המשויכים מוגדרים על ידי המפרסם או טכנולוגיית הפרסום. כל דוח מוצפן כדי למנוע מגורמים שונים גישה לנתונים הבסיסיים. Learn more about aggregatable reports. |
| Aggregatable Report Accounting | A distributed ledger located in both coordinators that tracks allocated privacy budget and enforces the 'No Duplicates' rule. This is the privacy preserving mechanism, located and run within coordinators, that ensures that no report passes through Aggregation Service beyond the allocated privacy budget. Read more on batching strategies on how it relates to aggregatable reports. |
| Aggregatable Report Accounting Budget | References to the budget that ensures reports are not processed more than once. |
| Trusted Execution Environment (TEE) |
סביבת מחשוב אמינה היא תצורה מיוחדת של חומרה ותוכנה במחשב, שמאפשרת לגורמים חיצוניים לאמת את הגרסאות המדויקות של התוכנות שפועלות במחשב. TEEs מאפשרת לגורמים חיצוניים לוודא שהתוכנה עושה בדיוק את מה יצרן תוכנה טוען שהוא נכון - לא יותר או פחות. לקבלת מידע נוסף על מכשירי TEE שמשמשים להצעות של ארגז החול לפרטיות, אפשר לקרוא את הסבר על שירותי Protected Audience API והסבר על שירות הצבירה. |
| Coordinators |
מתאם הוא ישות שאחראית לניהול מפתחות ולחשבונאות דוחות ניתנת לצבירה. המתאם מנהל רשימת גיבובים של הגדרות שירות שאושרו לצבירה ומגדיר את הגישה למפתחות פענוח. |
| Shared ID |
Computed value that consists of: shared_info, reporting_origin, destination_site (available for Attribution Reporting API only), source_registration-time (available for Attribution Reporting API only), scheduled_report_time, version.
This means that multiple reports belong to the same shared ID should they share the same attributes of the shared_info field. This plays an important role within Aggregatable Report Accounting.
Read more about Trusted Servers.
|
| Summary Report |
דוח סיכום הוא סוג הדוח Attribution Reporting API ו-Private Aggregation API. סיכום כולל נתוני משתמשים נצברים, ויכול לכלול נתוני המרות מפורטים, יחד עם רעשי רקע. דוחות סיכום מורכבים מדוחות מצטברים. דוחות סיכום מאפשרים גמישות רבה יותר ומודל נתונים עשיר יותר מאשר הדוחות ברמת האירוע, במיוחד בתרחישים מסוימים, כמו ערכי המרות. |
| Reporting Origin |
מקור הדיווח הוא הישות שמקבלת דוחות נצברים. במילים אחרות, טכנולוגיית הפרסום שנקרא 'Attribution Reporting API'. דוחות נצברים נשלחים מאת מכשירים של משתמשים לכתובת URL ידועה שמשויכת לדיווח המקור. צריך לציין את מקור הדיווח הזה במהלך הרישום. |
| Contribution Bonding | Aggregatable reports may contain an arbitrary number of counter increments. For example, a report may contain a count of products that a user has viewed on an advertiser's site. The sum of increments in all aggregatable reports related to a single source event must not exceed a given limit, `L1=2^16`. Learn more in the aggregatable reports explainer. |
| Noise & Scaling | A certain amount of statistical noise is added to summary reports as a part of the aggregation process that also functions to preserve privacy and ensure the final reports provide anonymized measurement information. Read more about additive noise mechanism, which is drawn from Laplace distribution. |
| Attestation |
אימות (attestation) הוא מנגנון לאימות זהות התוכנה, בדרך כלל באמצעות טביעות אצבע קריפטוגרפיות או חתימות. בהצעה של שירות הצבירה, האימות תואם לקוד שפועל בשירות הצבירה המופעל על-ידי טכנולוגיות פרסום לבין קוד הקוד הפתוח. Read more about 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 בפעולה. נתמקד בתהליך מקצה לקצה, החל מקבלת הדוחות מהאינטרנט והנייד ועד ליצירת דוחות הסיכום בשירות הצבירה.
- אחזור מפתח ציבורי ליצירת דוחות מוצפנים.
- דוחות מוצפנים שניתן לצבור אותם, שנשלחים לשרתים של טכנולוגיות פרסום כדי שנוכל לאסוף אותם, לבצע בהם טרנספורמציה ולקבץ אותם בקבוצות.
- שרת טכנולוגיית הפרסום אוסף דוחות (בפורמט avro) ושולח אותם לשירות האגרגציה שנפרס. (השלמת הטופס צריכה להתבצע על ידי חברת טכנולוגיית הפרסום).
- אחזור דוחות מצטברים לצורך פענוח.
- אחזור מפתחות פענוח מהרכזים.
- שירות Aggregation Service מפענח דוחות לצורך צבירה והוספת רעש.
- שירות החשבונאות של דוחות שניתנים לצבירה בודק אם נשאר תקציב פרטיות כדי ליצור דוח סיכום של הדוחות הנתונים שניתנים לצבירה.
- שולחים את דוח הסיכום הסופי.
בתרשים אפשר לראות את הקשר הכולל של שירות הצבירה עם ממשקי ה-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, אתם יכולים להשתמש בטופס הזה כדי לבקש תמיכה טכנית בפתרון בעיות.
- כדאי לבדוק במרכז הבקרה הציבורי לסטטוסים אם יש בעיות ידועות.