عند تجميع التقارير القابلة للتجميع، من المهم تحسين استراتيجيات التجميع حتى لا يتم تجاوز حدود الخصوصية. في ما يلي بعض الاستراتيجيات المقترَحة لإرسال مجموعات من التقارير إلى "خدمة التجميع".
جمع التقارير
عند جمع التقارير لتضمينها في مجموعة، يُرجى مراعاة ما يلي:
الإبلاغ عن محاولات التحميل
ملاحظة: تخضع معايير إعادة المحاولة للتغيير. سيتم تعديل المعلومات الواردة في هذا القسم في هذه الحالة.
على كل من منصّت الويب ونظام التشغيل، ستحاول المنصّة إرسال التقرير ثلاث مرّات، ولكن إذا تعذّر إرسال
التقرير بعد المحاولة الثالثة، لن يتم إرساله. يتم الاحتفاظ بالقيمة الأصلية
scheduled_report_time بغض النظر عن وقت إرسال التقرير. يختلف المخطط الزمني لعمليات إعادة المحاولة حسب النظام الأساسي:
- سيرسل متصفّح الويب التقارير عندما يكون متصلاً بالإنترنت. إذا تعذّر إرسال التقرير، سيتم الانتظار لمدة خمس دقائق لإعادة المحاولة الثانية، ثم 15 دقيقة للمحاولة الثالثة. إذا انقطع اتصال المتصفح بالإنترنت، سيتم إجراء المحاولة التالية بعد دقيقة واحدة من إعادة الاتصال بالإنترنت. ليس هناك حدّ أقصى للتأخير في إرسال التقارير على الويب، ويعني ذلك أنّه إذا انقطع اتصال المتصفّح بالإنترنت، بغض النظر عن الوقت الذي مرّت على إنشاء التقرير، سيحاول بعد معاودة الاتصال بالإنترنت إرسال التقرير وفقًا لسياسة إعادة المحاولة.
- هاتف Android متصل بالشبكة بشكلٍ ثابت وبناءً على ذلك، سيتم تنفيذ المهمة لإرسال التقارير مرة واحدة في الساعة. وهذا يعني أنّه إذا تعذّر إرسال تقرير، ستتم إعادة المحاولة في الساعة التالية، ثم مرة أخرى في الساعة التي تليها. إذا لم يكن الجهاز متصلاً بالشبكة، سيعيد الجهاز محاولة إرسال التقرير مع مهمة إعداد التقارير التالية التي يتم تشغيلها بعد اتصال الجهاز بالشبكة. الحد الأقصى للتأخير هو 28 يومًا، ما يعني أنّ الجهاز لن يرسل تقريرًا تم إنشاؤه قبل أكثر من 28 يومًا.
انتظار التقارير
ننصحك بانتظار تلقّي التقارير المتأخّرة عند جمع التقارير للتجميع. ويمكن تحديد التقارير المتأخرة من خلال التحقّق من قيمة scheduled_report_time مقابل وقت تلقّي التقرير. سيساعد الفارق الزمني بين تلك التقارير في تحديد المدة التي يمكنك التفكير خلالها في انتظار وصول التقارير المتأخرة. على سبيل المثال، عند جمع التقارير المتأخرة، راجِع
الحقل scheduled_report_time ولاحظ التأخير الزمني بالساعات، إذ يتم تلقّي %90 و%95 و99 من التقارير. ويمكن استخدام هذه البيانات لتحديد مدة الانتظار للتقارير التي تصل متأخرة.
يمكن استخدام التقارير المجمّعة الفورية
لتقليل احتمال تأخّر التقارير.
يعرض المخطّط البصري التالي التقارير المتأخرة التي يتم تخزينها في الدفعات المناسبة وفقًا
لوقت إعداد التقارير المُجدوَل. يمثّل "الدفعة T" scheduled_report_time، ويمثّل "T+X" الوقت الذي تم الانتظاره
للتقارير المتأخرة. يؤدّي ذلك إلى إنشاء تقرير تلخيصي يتضمّن معظم التقارير التي يتم
تضمينها في الحزمة والتي تتوافق مع وقت إعداد التقارير المُجدوَل.
إعداد التقارير القابلة للتجميع
تحافظ "خدمة تجميع البيانات" على قاعدة "عدم السماح بنسخ مكرّرة". تفرض هذه القاعدة تضمين جميع التقارير القابلة للتجميع التي تحمل المعرّف المشترَك نفسه في الحزمة نفسها.
بعد جمع التقارير، يجب تجميعها بطريقة تجعل كل التقارير التي تتضمّن المعرّف المشترَك نفسه جزءًا من حزمة واحدة.
إذا سبق أن تمت معالجة تقرير في دفعة أخرى، يمكن أن تؤدي المعالجة إلى ظهور خطأ بسبب استنفاد ميزانية الخصوصية. يساعد تجميع التقارير بشكل صحيح في منع رفض الدفعات بسبب قاعدة "ما مِن نُسخ طبق الأصل".
رقم التعريف المشترَك: هو مفتاح يتم إنشاؤه لكل تقرير لتتبُّع محاسبة التقارير القابلة للتجميع. يضمن المعرّف المشترَك أنّ التقارير التي تتضمّن المعرّف المشترَك نفسه تساهم في تقرير تلخيصي واحد فقط. وهذا يعني أنّه يجب تضمين كل التقارير التي ترتبط بمعرّف مشترَك واحد في حزمة واحدة. على سبيل المثال، إذا كان التقرير "س" والتقرير "ص" يتضمّنان المعرّف المشترَك نفسه، يجب تضمينهما في الدفعة نفسها لتجنّب حذف التقارير بسبب تكرارها.
توضِّح الصورة التالية مكوّنات 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_destination، وهو المعلِن. ننصح
بإنشاء الحِزم حسب المعلِن، أي تضمين التقارير التي تخصّ معلِنًا واحدًا في
الحزمة نفسها، لتجنُّب بلوغ الحدّ الأقصى المسموح به لحساب التقارير القابلة للتجميع لكلّ حزمة. ويُعدّ المعلن حقلاً يُعتبر حقلاً يتم أخذه في الاعتبار عند إنشاء المعرّف المشترك، وبالتالي يمكن أن تتضمّن التقارير مع المعلن نفسه المعرّف المشترك نفسه، ما يتطلّب أن يكونا في الدفعة نفسها لتجنّب حدوث أخطاء.
تجميع التقارير حسب الوقت
ننصحك بالانتباه إلى وقت إعداد التقرير المُجدوَل
(shared_info.scheduled_report_time) عند تجميع التقارير. يتم اقتطاع وقت التقرير المجدوَل إلى الساعة
في عملية إنشاء المعرّف المشترَك، لذا يجب تجميع التقارير على الأقل على فترات ساعة، ما يعني أنّه
يجب تضمين جميع التقارير التي لها وقت تقرير مجدوَل خلال الساعة نفسها في الحزمة نفسها لتجنُّب
توفّر تقارير بالمعرّف المشترَك نفسه في حِزم متعددة، ما سيؤدي إلى حدوث أخطاء في المهام.
معدّل تكرار الدفعات والضوضاء
ننصح بالتفكير في تأثير الضوضاء في عدد مرات معالجة التقارير القابلة للتجميع. في حال تجميع التقارير القابلة للتجميع بشكل متكرر، على سبيل المثال، تتم معالجة التقارير بعد تضمين أحداث إحالات ناجحة أقل بساعة، وسيكون للتشويش تأثير نسبي أكبر. إذا انخفض التكرار وتمت معالجة التقارير مرة في الأسبوع، فسيكون للتشويش تأثير نسبي أقل. لفهم تأثير الضوضاء على الدفعات بشكل أفضل، جرِّب Noise Lab.