عند تجميع التقارير القابلة للتجميع، من المهم تحسين استراتيجيات التجميع حتى لا يتم تجاوز حدود الخصوصية. في ما يلي بعض الاستراتيجيات المقترَحة لإرسال دفعات من التقارير إلى "خدمة التجميع".
جمع التقارير
عند جمع التقارير لتضمينها في مجموعة، يُرجى مراعاة ما يلي:
عمليات إعادة محاولة تحميل التقارير
ملاحظة: تخضع معايير إعادة المحاولة للتغيير. سيتم تعديل المعلومات الواردة في هذا القسم في هذه الحالة.
على كل من منصّتَي الويب ونظام التشغيل، ستحاول المنصّة إرسال التقرير ثلاث مرّات، ولكن إذا تعذّر إرسال
التقرير بعد المحاولة الثالثة، لن يتم إرساله. يتم الاحتفاظ بالقيمة الأصلية
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.