כשמקבצים דוחות שאפשר לצבור, חשוב לבצע אופטימיזציה של שיטות הקיבוץ כדי שלא תחרגו מהמגבלות של מדיניות הפרטיות. ריכזנו כאן כמה שיטות מומלצות לשליחת קבוצות של דוחות לשירות הצבירה.
איסוף דוחות
כשאוספים דוחות להוספה בכמות גדולה, חשוב לזכור את הדברים הבאים:
דיווח על ניסיונות העלאה חוזרים
הערה: הקריטריונים לניסיון חוזר עשויים להשתנות. המידע בקטע הזה יתעדכן במקרה כזה.
גם בפלטפורמות האינטרנט וגם בפלטפורמות של מערכות ההפעלה, הפלטפורמה תנסה לשלוח את הדוח שלוש פעמים, אבל אם הדוח לא יישלח אחרי הניסיון השלישי, הוא לא יישלח. הערך המקורי של scheduled_report_time נשמר גם אם אפשר לשלוח את הדוח. לוח הזמנים לניסיונות חוזרים משתנה בהתאם לפלטפורמה:
- דפדפן אינטרנט ישלח דוחות כשהדפדפן מחובר לאינטרנט. אם הדיווח לא נשלח, המערכת תמתין חמש דקות לפני הניסיון השני, ולאחר מכן 15 דקות לפני הניסיון השלישי. אם הדפדפן עובר למצב אופליין, הניסיון החוזר הבא יתבצע דקה אחת אחרי שהוא חוזר לאינטרנט. אין עיכוב מקסימלי בשליחת דוחות באינטרנט. כלומר, אם הדפדפן עובר למצב אופליין, ולא משנה כמה זמן עבר הדוח נוצר, כשהדפדפן יחזור לאינטרנט, הוא ינסה לשלוח את הדוח בהתאם למדיניות הניסיונות החוזרים.
- טלפון Android עם חיבור יציב לרשת. לכן, הוא יפעיל את המשימה לשליחת דוחות פעם בשעה. כלומר, אם שליחת דוח מסוים נכשלת, המערכת תנסה שוב בשעה הבאה, ואז שוב בשעה שאחרי כן. אם למכשיר אין חיבור, המכשיר ינסה לשלוח את הדוח שוב עם משימת הדיווח הבאה שתבוצע אחרי שהמכשיר יתחבר שוב לרשת. העיכוב המקסימלי הוא 28 ימים, כלומר המכשיר לא ישלח דוח שנוצר לפני יותר מ-28 ימים.
המתנה לדוחות
מומלץ להמתין לדוחות שמגיעים באיחור כשאוספים דוחות לצורך קיבוץ. כדי לבדוק אם דוחות מסוימים הגיעו באיחור, אפשר להשוות את הערך של scheduled_report_time לתאריך שבו הדוח התקבל. ההבדל בין זמני ההגעה של הדוחות האלה יעזור לכם לקבוע כמה זמן כדאי להמתין לדוחות שמגיעים באיחור. לדוגמה, ככל שהדוחות המאחרים נאספים, כדאי לבדוק את השדה scheduled_report_time ולרשום את עיכוב הזמן בשעות כש-90%, 95% ו-99% מהדוחות מתקבלים. הנתונים האלה יכולים לשמש כדי לקבוע כמה זמן צריך להמתין עד שיתקבלו דוחות מאוחרים.
אפשר להשתמש בדוחות מסכמים מיידיים כדי לצמצם את הסיכוי לדוחות עם עיכוב.
בתרשים הבא מוצגים דוחות שמגיעים באיחור, שמאוחסנים בקבוצות המתאימות בהתאם למועד המדויק שבו הם אמורים להגיע. זמן האצווה T מייצג את scheduled_report_time, ו-T+X מייצג את זמן ההמתנה לדוחות שהועברו באיחור. התוצאה היא דוח סיכום שכולל את רוב הדוחות שכלולים באצווה, בהתאם למועד המדויק שבו הם מתוזמנים.
דיווח על דוחות עם נתונים מצטברים
שירות הצבירה שומר על כלל 'ללא כפילויות'. הכלל הזה אוכף את הכלל שכל הדוחות שאפשר לצבור עם אותו מזהה משותף חייבים להיכלל באותו אצווה.
אחרי איסוף הדוחות, צריך לקבץ אותם כך שכל הדוחות עם אותו מזהה משותף יהיו חלק מקבוצה אחת.
אם דוח כבר עבר עיבוד בקבוצה אחרת, העיבוד עשוי לגרום לשגיאה מסוג 'תקציב הפרטיות נגמר'. יצירת קבוצות של דוחות בצורה נכונה תעזור למנוע דחיית קבוצות בגלל הכלל 'ללא כפילויות'.
מזהה משותף הוא מפתח שנוצר לכל דוח כדי לעקוב אחרי צבירה של נתונים בדוחות. בעזרת המזהה המשותף אפשר לוודא שדוחות עם אותו מזהה משותף תורמים רק לדוח סיכום אחד. כלומר, כל הדוחות שממופים למזהה משותף אחד צריכים להיכלל יחד בקבוצה אחת. לדוגמה, אם לדוח 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 לא מורשית ונכשלת עם הודעת שגיאה.
דוחות אצווה
ריכזנו כאן כמה שיטות מומלצות ליצירת קבוצות של דוחות כדי למנוע כפילויות ולבצע אופטימיזציה של הדיווח על דוחות מצטברים.
יצירת קבוצות לפי מפרסם
הערה: מומלץ להשתמש בשיטה הזו רק לצורך צבירת נתונים בדיווח על שיוך (Attribution).
במסגרת 'צבירה פרטית' אין שדה attribution_destination, שהוא המפרסם. מומלץ לקבץ באצווה לפי מפרסם. כלומר, לכלול דוחות ששייכים למפרסם אחד באותה קבוצה, כדי לא להגיע למגבלת החשבון של הדוחות המצטברים לכל קבוצה. השדה 'מפרסם' נלקח בחשבון ביצירת המזהה המשותף, כך שדוחות עם אותו מפרסם יכולים לכלול גם את אותו מזהה משותף. כדי למנוע שגיאות, הדוחות האלה צריכים להופיע באותו אצווה.
אצווה לפי זמן
מומלץ להביא בחשבון את מועד השליחה המתוזמן של הדוח (shared_info.scheduled_report_time) כשמקבצים את הבקשות. השעה של הדוח המתוזמן מקוצרת לשעה בזמן היצירה של המזהה המשותף, לכן צריך לקבץ את הדוחות לפחות במרווחי זמן של שעה. כלומר, כל הדוחות עם שעת הדוח המתוזמנת באותה שעה צריכים להיכלל באותו אשכול כדי למנוע דוחות עם אותו מזהה משותף בכמה אשכולות, דבר שיגרום לשגיאות בעבודה.
תדר ורעש באצווה
מומלץ להביא בחשבון את ההשפעה של רעש על תדירות העיבוד של דוחות שאפשר לצבור. אם דוחות נצברים מקובצים בתדירות גבוהה יותר, למשל, הדוחות מעובדים פעם אחת לפחות בשעה שאירועי המרה ייכללו, ולרעש תהיה השפעה יחסית גדולה יותר. אם התדירות תופחת והדוחות יעברו עיבוד פעם בשבוע, ההשפעה היחסית של הרעש תהיה קטנה יותר. כדי להבין טוב יותר את ההשפעה של רעש על קבוצות, כדאי להתנסות בNoise Lab.