כשמקבצים דוחות מצטברים, חשוב לבצע אופטימיזציה של אסטרטגיות הקיבוץ כדי לא לחרוג ממגבלות הפרטיות. ריכזנו כאן כמה אסטרטגיות מומלצות לשליחת חבילות של דוחות ל-Aggregation Service.
איסוף דוחות
כשמכינים דוחות להוספה לחבילה, חשוב לזכור את הנקודות הבאות:
ניסיונות חוזרים להעלאת דוחות
הערה: יכול להיות שיהיו שינויים בקריטריונים לניסיון חוזר. במקרה כזה, המידע בקטע הזה יעודכן.
גם בפלטפורמות האינטרנט וגם בפלטפורמות של מערכות ההפעלה, הפלטפורמה תנסה לשלוח את הדוח שלוש פעמים, אבל אם הדוח לא יישלח אחרי הניסיון השלישי, הוא לא יישלח. הערך המקורי scheduled_report_time נשמר לא משנה מתי אפשר לשלוח את הדוח. ציר הזמן לניסיונות חוזרים שונה בכל פלטפורמה:
- דפדפן אינטרנט ישלח דוחות כשהדפדפן יהיה אונליין. אם שליחת הדוח נכשלת, המערכת ממתינה חמש דקות לניסיון השני, ואז 15 דקות לניסיון השלישי. אם הדפדפן עובר למצב אופליין, הניסיון הבא יתבצע דקה אחרי שהוא יחזור למצב אונליין. אין עיכוב מקסימלי בשליחת דוחות באינטרנט. כלומר, אם הדפדפן עובר למצב אופליין, לא משנה לפני כמה זמן הדוח נוצר, ברגע שהדפדפן יחזור למצב אונליין, הוא ינסה לשלוח את הדוח בהתאם למדיניות הניסיון החוזר.
- טלפון Android עם חיבור רציף לרשת. לכן, המערכת תריץ את העבודה כדי לשלוח דוחות פעם בשעה. כלומר, אם שליחת הדוח תיכשל, המערכת תנסה לשלוח אותו שוב בשעה הבאה, ושוב בשעה שאחריה. אם אין למכשיר חיבור, הוא ינסה לשלוח את הדוח שוב עם משימת הדיווח הבאה שתפעל אחרי שהמכשיר יתחבר שוב לרשת. הזמן המקסימלי שחלף מהקליק להמרה הוא 28 ימים, כלומר המכשיר לא ישלח דוח שנוצר לפני יותר מ-28 ימים.
המתנה לדוחות
מומלץ להמתין לדוחות שמגיעים באיחור כשמקבצים דוחות. כדי לדעת אם הדוח התקבל באיחור, בודקים את הערך scheduled_report_time לעומת מועד קבלת הדוח. ההבדל בזמן בין הדוחות האלה יעזור לכם להחליט כמה זמן כדאי לחכות עד שהדוחות יגיעו. לדוגמה, כשמצטברים נתונים בדוחות עם עיכוב, כדאי לבדוק את השדה scheduled_report_time ולשים לב לעיכוב בזמן בשעות כש-90%, 95% ו-99% מהדוחות מתקבלים. אפשר להשתמש בנתונים האלה כדי לקבוע כמה זמן צריך לחכות לדוחות שמגיעים באיחור.
אפשר להשתמש בדוחות נצברים מיידיים כדי להקטין את הסיכוי לעיכובים בדוחות.
בתרשים הבא אפשר לראות דוחות שמגיעים באיחור ומאוחסנים באצוות המתאימות בהתאם לזמן המתוזמן של הדוח. Batch T מייצג scheduled_report_time, ו-T+X מייצג את זמן ההמתנה לדוחות מושהים. התוצאה היא דוח סיכום שכולל את רוב הדוחות שנכללים באוסף, בהתאם לזמן המתוזמן של הדוח.
התחשבות בדוחות שניתן לצבור
Aggregation Service שומר על כלל 'ללא כפילויות'. הכלל הזה מחייב שכל הדוחות שניתן לצבור עם אותו מזהה משותף ייכללו באותו קובץ.
אחרי איסוף הדוחות, צריך לאגד אותם כך שכל הדוחות עם אותו מזהה משותף יהיו חלק מאותו אצווה.
אם דוח כבר עבר עיבוד באצווה אחרת, העיבוד יכול להוביל לשגיאה של מיצוי מכסת הפרטיות. הפקת דוחות באצווה בצורה נכונה עוזרת למנוע דחייה של אצוות בגלל הכלל 'ללא כפילויות'.
מזהה משותף הוא מפתח שנוצר לכל דוח כדי לעקוב אחרי נתוני חשבונאות שניתנים לצבירה. המזהה המשותף מבטיח שדוחות עם אותו מזהה משותף יתרמו רק לדוח סיכום אחד. כלומר, כל הדוחות שמתמפים יחד למזהה משותף אחד צריכים להיכלל באותו קובץ. לדוגמה, אם לדוח X ולדוח Y יש אותו מזהה משותף, צריך לכלול אותם באותה קבוצת קבצים כדי למנוע השמטה של דוחות בגלל כפילות.
בתמונה הבאה מוצגים הרכיבים של shared_info שעוברים גיבוב יחד כדי ליצור מזהה משותף.
בתמונה הבאה אפשר לראות איך יכול להיות לשני דוחות שונים אותו מזהה משותף:
הערה: הערך של scheduled_report_time נחתך לפי שעה, והערך של source_registration_time נחתך לפי יום. בנוסף, לא נעשה שימוש ב-report_id ביצירת מזהה משותף. יכול להיות שבעתיד נעדכן את רמת הפירוט של הזמן.
דוחות כפולים באותו אצווה
השדה shared_info בדוח שניתן לצבירה מכיל UUID בשדה report_id, שמשמש לזיהוי דוחות כפולים באותו אצווה. אם יש יותר מדוח אחד עם אותו report_id באותו אצווה, רק הדוח הראשון יצורף לסיכום, והדוחות האחרים ייחשבו ככפולים ויוסרו ללא הודעה. הסיכום ימשיך כרגיל ולא יישלחו שגיאות.
למרות שזה לא נדרש, טכנולוגיות פרסום יכולות לצפות לשיפור מסוים בביצועים אם הן יסננו את הדוחות הכפולים עם מזהי דוחות זהים לפני הצבירה.
המספר report_id ייחודי לכל דוח.
דוחות כפולים בין קבוצות
לכל דוח מוקצה מזהה משותף, שהוא מזהה שנוצר מנקודות נתונים משולבות שמגיעות מהשדה shared_info של הדוח. יכול להיות שלכמה דוחות יהיה אותו מזהה משותף, וכל חבילה יכולה להכיל כמה מזהים משותפים. כל הדוחות עם אותו מזהה משותף צריכים להיכלל באותו אצווה. אם דוחות עם אותו מזהה משותף יגיעו לכמה קבוצות, רק הקבוצה הראשונה תתקבל והקבוצות האחרות יידחו ככפילויות. כדי למנוע את זה, צריך ליצור את החבילות בצורה נכונה.
בתמונה הבאה מוצגת דוגמה שבה דוחות עם אותו מזהה משותף בכמה קבוצות יכולים לגרום לכך שהקבוצה האחרונה תיכשל. בתמונה אפשר לראות ששני דוחות או יותר עם אותו מזהה משותף
e679aa נכללים באותו אצווה, אצווה מספר 1 ואצווה מספר 2. התקציב של כל הדוחות עם מזהה משותף e679aa נוצל במהלך יצירת דוח הסיכום של קבוצה מספר 1, ולכן לא ניתן ליצור את קבוצה מספר 2 והפעולה נכשלת עם שגיאה.
דוחות באצווה
ריכזנו כאן כמה דרכים מומלצות ליצירת דוחות באצווה כדי למנוע כפילויות ולבצע אופטימיזציה של הנהלת החשבונות של דוחות מצטברים.
חבילה לפי מפרסם
הערה: מומלץ להשתמש בשיטה הזו רק לצורך צבירה של נתוני דיווח שיוך.
ל-Private Aggregation אין שדה attribution_destination, שהוא המפרסם. מומלץ להשתמש באפשרות 'אצווה' לפי מפרסם, כלומר לכלול באותה אצווה דוחות ששייכים למפרסם יחיד, כדי לא לחרוג ממגבלת החשבון של דוחות שניתן לצבור לכל אצווה. השדה 'מפרסם' נלקח בחשבון בתהליך יצירת המזהה המשותף, ולכן דוחות עם אותו מפרסם יכולים לכלול גם את אותו מזהה משותף. במקרה כזה, הדוחות צריכים להיות באותו אצווה כדי למנוע שגיאות.
מקבץ לפי זמן
מומלץ להתייחס לזמן של הדוח המתוזמן (shared_info.scheduled_report_time) כשמבצעים אצווה. השעה של הדוח המתוזמן מעוגלת לשעה הקרובה ביותר ביצירת המזהה המשותף, ולכן מומלץ לפחות לאגד את הדוחות במרווחי שעה. כלומר, כל הדוחות עם השעה של הדוח המתוזמן באותה שעה צריכים להיכלל באותו אגד כדי למנוע מצב שבו דוחות עם אותו מזהה משותף יופיעו בכמה אגדים, מה שיוביל לשגיאות בעבודות.
תדירות של עיבוד באצווה ורעשי רקע
מומלץ לקחת בחשבון את ההשפעה של רעשי רקע על התדירות שבה מתבצע עיבוד של דוחות מצטברים. אם דוחות שאפשר לצבור נשלחים בתדירות גבוהה יותר – למשל, אם הדוחות מעובדים פעם בשעה – ייכללו פחות אירועי המרה וההשפעה היחסית של הרעש תהיה גדולה יותר. אם התדירות תרד והדוחות יעברו עיבוד פעם בשבוע, ההשפעה היחסית של הרעש תהיה קטנה יותר. כדי להבין טוב יותר את ההשפעה של רעשים על אצוות, כדאי להתנסות ב-Noise Lab.