שירות הצבירה מפיק דוחות סיכום של נתוני המרות מפורטים ומדידות של היקף החשיפה מדוחות נצברים גולמיים. לטכנולוגיות הפרסום יש שתי נקודות כניסה ראשיות לנתונים מצטברים בצד הלקוח, כדי להעביר דוחות לשירות הצבירה. הנקודות האלה הן Attribution Reporting API או Private Aggregation API.
סטטוס ההטמעה
- שירות הצבירה עבר עכשיו לזמינות לכלל המשתמשים.
- אפשר להשתמש ב-Aggregation Service עם Attribution Reporting API ו-Private Aggregation API עבור Protected Audience API ו-Shared Storage API.
זמינות
| הצעה | סטטוס |
|---|---|
| תמיכה בשירות צבירה ל-Amazon Web Services (AWS) ב-Attribution Reporting API וב-Private Aggregation API
הסבר |
זמין |
| תמיכה של שירותי הצבירה ל-Google Cloud ב-Attribution Reporting API וב-Private Aggregation API הסבר |
זמין |
| רישום אתרים בשירות צבירה וצבירת מקורות מרובים. ההרשמה של האתר כוללת מיפוי של האתר לחשבונות בענן (AWS או GCP). כדי לצבור כמה מקורות, הם צריכים להיות מאותו אתר.
שאלות נפוצות ב-GitHub מסמכי תיעוד של Site aggregation API |
זמין |
| כדי לאפשר ניסויים ומשוב על פרמטרים שונים, הערך של epsilon בשירות הצבירה יישמר בטווח של עד 64.
שליחת משוב על ARA epsilon שליחת משוב לגבי אפסילון של PAA. |
זמינים. נודיע מראש לסביבה העסקית לפני שהערכים של טווח האפסילון יעודכנו. |
| סינון גמיש יותר לתרומות בתגובה לשאילתות של שירותי צבירת נתונים
הסברים |
זמין |
| תהליך לשחזור התקציב לאחר אסונות (שגיאות, הגדרות שגויות וכו')
הסבר |
זמין מנגנון לבדיקה של אחוז המזהים המשותפים ש-AdTech משחזרת באמצעות שחזור תקציב, ולהשעיית שחזור עתידי של נתונים במקרים של שחזור מוגזם שתוכנן במחצית הראשונה של שנת 2025 |
| Accenture פועלת כאחת מהמתאמים ב-AWS
בלוג למפתחים |
זמין |
| צד עצמאי שפועל כאחד מהרכזים ב-Google Cloud
בלוג למפתחים |
זמין |
| תמיכה של Aggregation Service בדוחות ניפוי באגים מצטברים ב-Attribution Reporting API
הסבר |
זמין |
מונחי מפתח ומושגים מרכזיים
אם אתם שוקלים להשתמש בשירות הצבירה בתהליך העבודה שלכם בתחום טכנולוגיית הפרסום, המונחים והמושגים הבאים יעזרו לכם להבין טוב יותר את היתרונות של תהליך הצבירה החדש הזה לצוות שלכם:
| מונח | תיאור |
|---|---|
| Aggregation Service | שירות שמופעל על ידי טכנולוגיית פרסום, שמטפל בדוחות שניתן לצבור כדי ליצור דוח סיכום. |
| דוחות נצברים |
דוחות נצברים הם דוחות מוצפנים שנשלחים ממכשירים של משתמשים ספציפיים. הדוחות האלה מכילים נתונים לגבי התנהגות והמרות של משתמשים באתרים שונים. ההמרות (שלפעמים נקראים אירועי טריגר של שיוך (Attribution)) והמדדים המשויכים מוגדרים על ידי המפרסם או טכנולוגיית הפרסום. כל דוח מוצפן כדי למנוע מגורמים שונים גישה לנתונים הבסיסיים. מידע נוסף על דוחות נצברים. |
| חשבונאות של דוחות נצברים | ספר חשבון מבוזר שנמצא בשני התאמים, ומעקב אחרי תקציב הפרטיות שהוקצה ואכיפת הכלל 'אין כפילויות'. זהו המנגנון לשמירה על הפרטיות, שנמצא ומופעל בתוך גורמי התיאום, ומבטיח שאף דוח לא יעבור דרך שירות הצבירה מעבר לתקציב הפרטיות שהוקצה. מידע נוסף על שיטות ארגון בקבוצות ועל הקשר שלהן לדוחות שניתן לצבור |
| תקציב חשבונאי לדוחות מצטברים | התייחסויות לתקציב שמבטיחה שהדוחות לא יעובדו יותר מפעם אחת. |
| סביבת הפעלה מהימנה (TEE) |
A trusted execution environment is a special configuration of computer hardware and software that allows external parties to verify the exact versions of software running on the computer. TEEs allow external parties to verify that the software does exactly what the software manufacturer claims it does—nothing more or less. To learn more about TEEs used for the Privacy Sandbox proposals, read the Protected Audience API services explainer and the Aggregation Service explainer. |
| מתאמים |
מתאם הוא ישות שאחראית לניהול מפתחות ולחשבונאות דוחות ניתנת לצבירה. המתאם מנהל רשימת גיבובים של הגדרות שירות שאושרו לצבירה ומגדיר את הגישה למפתחות פענוח. |
| מזהה משותף |
הערך המחושב שכולל את הנתונים הבאים: 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) | אפשר להשתמש בדוחות נצברים כדי לתעד את ההתפלגות של ערכי הצעות המחיר במכרזים. |
תהליך מקצה לקצה
בתרשים הבא מוצג שירות הצבירה בפעולה. נתמקד בתהליך מקצה לקצה, החל מקבלת הדוחות מהאינטרנט והנייד ועד ליצירת דוחות הסיכום בשירות הצבירה.
- אחזור מפתח ציבורי ליצירת דוחות מוצפנים.
- דוחות מוצפנים נצברים שנשלחים לשרתים של פרסום דיגיטלי לצורך איסוף, טרנספורמציה וקיבוץ.
- שרת טכנולוגיית הפרסום אוסף דוחות (בפורמט avro) ושולח אותם לשירות האגרגציה שנפרס. (צריך להשלים את השלב של טכנולוגיית הפרסום).
- אחזור דוחות נצברים לצורך פענוח.
- אחזור מפתחות פענוח מהרכזים.
- שירות Aggregation Service מפענח דוחות לצורך צבירה והוספת רעש.
- בדיקות של שירות חשבונאות של דוחות נצברים אם נותר תקציב פרטיות, כדי להפיק דוח סיכום לדוחות המצטברים הנתונים.
- שולחים דוח סיכום סופי.
בתרשים אפשר לראות את הקשר הכולל של שירות האגרגציה עם ממשקי ה-API העיקריים למדידת לקוחות: Attribution Reporting API, Private Aggregation API והתיאמים.
התהליך מתחיל בממשקי API שונים למדידה, כמו Attribution Reporting API או Private Aggregation API, שמייצרים דוחות מכמה מופעים בדפדפן. Chrome לוקח את המפתח הציבורי משירות אירוח המפתחות במרכז התיאום כדי להצפין את הדוחות לפני שהם נשלחים למקור הדיווח של חברת טכנולוגיית הפרסום. המפתחות הציבוריים מבצעים רוטציה מדי 7 ימים.
אחרי שמקור הדיווח של טכנולוגיית הפרסום יקבל את הדוחות האלה, צריך להגדיר את מקור הדיווח כך שיאסוף וימיר את הדוחות האלה לפורמט Avro, וישלח אותם למכונה של Aggregation Service שנפרסה. כדאי לעיין במאמר בנושא שיטות ארגון בקבוצות.
כשמערכת טכנולוגיית הפרסום מוכנה ליצירת קבוצה, היא יוצרת בקשת קבוצה לשירות המצטבר, שבו הדוחות מפענחים על ידי אחזור מפתחות הפענוח משירות אירוח המפתחות, ולאחר מכן הם נצברים ומתווסף להם רעש כדי ליצור דוח סיכום. חשוב לזכור שההחלטה הזו מותנית בשאלה אם תקציב הפרטיות מספיק כדי להפיק את דוחות הסיכום הסופיים.
נקודת הקצה המקורית לדיווח של חברת טכנולוגיית הפרסום, שבה נאספים הדוחות, מתארחת על ידי חברת טכנולוגיית הפרסום, ושירות הצבירה נפרס בענן של חברת טכנולוגיית הפרסום.
קיבוץ דוחות נצברים
תהליך הדיווח לא יושלם ללא עזרה משרת המקור הייעודי לדיווח. זהו המקור שפלטפורמת ה-AdTech הייתה שולחת בתהליך ההרשמה. הפעולות העיקריות שמקור הדיווח אחראי להן יהיו איסוף, טרנספורמציה וקיבוץ של הדוחות המצטברים שהתקבלו, והכנה שלהם לשליחה לשירות האגרגציה שנפרס של טכנולוגיית הפרסום ב-Google Cloud או ב-Amazon Web Services. מידע נוסף על הכנת דוחות שניתן לצבור
עכשיו, אחרי שהבנתם את הקונספט הכללי, נבחן לעומק את הרכיבים שיוצבו בשירות הצבירה.
רכיבי ענן
שירות הצבירה מורכב מרכיבים שונים של שירותי ענן. קובצי הסקריפטים של Terraform שסופקו והגדירו את כל הרכיבים הדרושים של שירותי ענן.
שירות לקצה הקדמי
שירות ענן מנוהל: פונקציה של Cloud Functions (Google Cloud) / שער API (Amazon Web Services)
Frontend Service הוא שער ללא שרת (serverless), שמשמש כנקודת הכניסה לקריאות ל-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)
'תור המשימות' הוא תור של הודעות שמאחסן בקשות של משימות לשירות הצבירה. שירות Frontend מוסיף הודעות של בקשות משימה לתור, ואז Aggregation Worker צורכת הודעות כדי לעבד את בקשת המשימה.
אחסון בענן
שירות ענן מנוהל: Google Cloud Storage (Google Cloud) או Amazon S3 (שירותי אינטרנט של Amazon) אחסון בענן משמש לאחסון קובצי קלט ופלט שמשמשים את שירות הצבירה (לדוגמה: קובצי דוחות מוצפנים, דוחות סיכום פלט וכו').
מסד נתונים של מטא-נתונים של משימות
שירות מנוהל בענן: Spanner (Google Cloud) או DynamoDB (Amazon Web Services)
מסד נתונים של Job Metadata מאחסן ועוקב אחר הסטטוס של משימות צבירת נתונים. במסד הנתונים מתועדים מטא-נתונים כמו שעת היצירה, השעה המבוקשת, השעה המעודכנת והמצב (לדוגמה: התקבלו, בתהליך, הסתיים וכו'). Aggregation Worker מעדכן את מסד הנתונים של המשימות לפי התקדמות המשימה.
עובד צבירת נתונים
שירות ענן מנוהל: Compute Engine עם Confidential Space (Google Cloud) או Amazon Web Services EC2 עם Nitro Enclave (Amazon Web Services)
קובץ Aggregation Worker מעבד בקשות למשימות שיזומות בקשת משימה בתור המשימה, ומפענח את הקלט המוצפן באמצעות מפתחות שנשלפו מ-Key Generation and Distribution Service (KGDS) ב-Coordinator. כדי לצמצם את זמן האחזור של עיבוד המשימות, מפתחות ההצפנה נשמרים במטמון ב-Aggregation Worker למשך 8 שעות, וניתן להשתמש בהם במשימות שמעובדות על ידי מכונה עובדת זו.
העובד פועל במכונה של Trusted Execution Environment (TEE). כל עובד מטפל רק במשימה אחת בכל פעם. טכנולוגיית הפרסום יכולה להגדיר כמה עובדים לעיבוד משימות במקביל על ידי הגדרת הגדרות התאמה אוטומטית לעומס. באמצעות התאמה אוטומטית, מספר העובדים משתנה באופן דינמי בהתאם למספר ההודעות שנותרו בתור המשימות. באמצעות קובץ הסביבה של Terraform אפשר להגדיר את מספר העובדים המינימלי והמקסימלי להתאמה לעומס (auto-scaling). מידע נוסף על התאמה לעומס (autoscaling) ניתן למצוא בסקריפטים הבאים של terraform. [Amazon Web Services / Google Cloud]
Aggregation Worker קורא לשירות Aggregatable Report Accounting לגבי הנהלת דוחות נצברים. שירות החשבונאות של הדוחות המצטברים יבטיח שמשימות יופעלו רק כל עוד הוא לא חרג ממגבלת הפרטיות של התקציב. (ראו כלל 'ללא כפילויות'). אם התקציב זמין, המערכת יוצרת דוח סיכום שמבוסס על הנתונים שהצטברו עם הרעש. מידע נוסף על דיווח על דוחות שניתן לצבור
הכלי Aggregation Worker מעדכן את המטא-נתונים של המשימות במסד הנתונים של משימות, כולל קודים מתאימים של החזרת משימות ומוני שגיאות של דוחות במקרה של כשלים חלקיים בדוחות. המשתמשים יכולים לאחזר את המצב באמצעות ממשק ה-API לאחזור מצב המשימה (getJob).
תיאור מפורט יותר של שירות צבירת הנתונים זמין בהסברים שלנו.
השלבים הבאים
אחרי שסיפקנו לכם את הנקודות העיקריות של Aggregation Service, הגיע הזמן לפרוס מכונה משלכם של Aggregation Service דרך Google Cloud או Amazon Web Services. אפשר לעיין בקטע 'תחילת העבודה'. אם אתם צריכים מידע נוסף על הפעלת Aggregation Service שנפרס, תוכלו להיכנס לקישור הזה כדי לקרוא מידע נוסף על הפעלת Aggregation Service.
פתרון בעיות
במסמך קודי שגיאה נפוצים והקלות מפורטים תיאורים מפורטים יותר של הודעות השגיאה, מה יכול להיות שגרם לשגיאה שבה נתקלת והשלבים הבאים להקלה על הבעיה.
קבלת תמיכה ושליחת משוב
- אם יש לכם בעיות טכניות, שאלות לגבי המוצר, משוב או בקשות למאפיינים חדשים, אתם יכולים ליצור דיווח על בעיה במאגר שלנו ב-GitHub.
- אם יש לכם שאלות שבהן אתם צריכים לספק מידע רגיש או קנייני לצורך פתרון בעיות, תוכלו לפנות אלינו בכתובת aggregation-service-support@google.com
- כדאי לבדוק בלוח הבקרה של הסטטוס הציבורי כדי לראות אם יש בעיות ידועות.