כשמקבצים דוחות שאפשר לצבור, חשוב לבצע אופטימיזציה של אסטרטגיות הקיבוץ כדי לא לחרוג מהמגבלות של מדיניות הפרטיות. ריכזנו כאן כמה שיטות מומלצות לשליחת קבוצות של דוחות לשירות האגרגציה.
איסוף דוחות
כשאוספים דוחות שרוצים לכלול בקבוצה, חשוב לזכור את הנקודות הבאות:
דיווח על ניסיונות העלאה חוזרים
הערה: הקריטריונים לניסיון חוזר עשויים להשתנות. המידע בקטע הזה יתעדכן במקרה כזה.
גם בפלטפורמות האינטרנט וגם בפלטפורמות של מערכות ההפעלה, הפלטפורמה תנסה לשלוח את הדוח שלוש פעמים, אבל אם הדוח לא יישלח אחרי הניסיון השלישי, הוא לא יישלח. הערך המקורי של 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.