استراتيجيات تجميع المحتوى

عند تجميع التقارير القابلة للتجميع، من المهم تحسين استراتيجيات التجميع لكي لا يتم تجاوز حدود الخصوصية. في ما يلي بعض الاستراتيجيات المقترَحة لإرسال دفعات من التقارير إلى "خدمة تجميع البيانات".

جمع التقارير

عند جمع التقارير لتضمينها في مجموعة، يُرجى مراعاة ما يلي:

إعادة محاولة تحميل التقارير

ملاحظة: تخضع معايير إعادة المحاولة للتغيير. سيتم تعديل المعلومات الواردة في هذا القسم في هذه الحالة.

على كلّ من منصات الويب وأنظمة التشغيل، ستحاول المنصة إرسال التقرير ثلاث مرات، ولكن إذا لم يتم إرساله بعد المحاولة الثالثة، لن يتم إرساله. يتم الاحتفاظ بالقيمة الأصلية scheduled_report_time بغض النظر عن الوقت الذي يمكن فيه إرسال التقرير. يختلف الجدول الزمني لإعادة المحاولة حسب النظام الأساسي:

• سيرسل متصفّح الويب التقارير عندما يكون متصلاً بالإنترنت. إذا تعذّر إرسال التقرير، سيتم الانتظار لمدة خمس دقائق لإعادة المحاولة للمرة الثانية، ثم 15 دقيقة لإعادة المحاولة للمرة الثالثة. إذا أصبح المتصفّح غير متصل بالإنترنت، ستتم إعادة المحاولة التالية بعد دقيقة واحدة من إعادة الاتصال بالإنترنت. ليس هناك حدّ أقصى للتأخير في إرسال التقارير على الويب، ما يعني أنّه إذا توقّف المتصفّح عن الاتصال بالإنترنت، بغض النظر عن المدة التي انقضت منذ إنشاء التقرير، سيحاول المتصفّح إرسال التقرير عند إعادة الاتصال بالإنترنت وفقًا لسياسة إعادة المحاولة.
• أن يكون لديك هاتف Android متصل بالشبكة بشكل دائم وبالتالي، سيتم تشغيل المهمة لإرسال التقارير مرة واحدة كل ساعة. وهذا يعني أنّه إذا تعذّر إرسال تقرير، ستتم إعادة المحاولة في الساعة التالية، ثم في الساعة التي تليها. إذا لم يكن الجهاز متصلاً بالإنترنت، سيعيد الجهاز محاولة إرسال التقرير مع مهمة إعداد التقارير التالية التي يتم تنفيذها بعد اتصال الجهاز بالشبكة مرة أخرى. الحد الأقصى للتأخير هو 28 يومًا، ما يعني أنّ الجهاز لن يرسل تقريرًا تم إنشاؤه قبل أكثر من 28 يومًا.

الانتظار بشأن التقارير

يُنصح بالانتظار إلى أن تصل التقارير المتأخرة عند جمع التقارير لتجميعها في حِزم. يمكن تحديد التقارير المتأخّرة من خلال مقارنة القيمة scheduled_report_time بتاريخ تلقّي التقرير. سيساعدك الفرق الزمني بين هذين التقريرين في تحديد المدة التي قد تحتاج إلى الانتظار خلالها لتلقّي التقارير المتأخرة. على سبيل المثال، أثناء جمع التقارير المتأخّرة، تحقّق من الحقل scheduled_report_time ولاحظ التأخير الزمني بالساعات عند تلقّي %90 و%95 و% 99 من التقارير. ويمكن استخدام هذه البيانات لتحديد مدة الانتظار قبل إرسال التقارير المتأخرة. يمكن استخدام التقارير المجمّعة الفورية للحدّ من احتمال تأخُّر التقارير.

تعرض الصورة التالية التقارير التي تصل متأخرة ويتم تخزينها في الدفعات المناسبة وفقًا لوقت التقرير المجدوَل. يمثّل Batch T scheduled_report_time، ويمثّل T+X الوقت الذي تم الانتظار فيه لتلقّي التقارير المتأخّرة. ويؤدي ذلك إلى إنشاء تقرير ملخّص يتضمّن معظم التقارير المضمّنة في الدفعة والتي تتوافق مع وقت إعداد التقارير المجدوَل.

محاسبة التقارير القابلة للتجميع

تلتزم "خدمة تجميع البيانات" بقاعدة "عدم التكرار". تفرض هذه القاعدة أن يتم تضمين جميع التقارير القابلة للتجميع التي تتضمّن المعرّف المشترَك نفسه في الحزمة نفسها.

بعد جمع التقارير، يجب تجميعها بطريقة تضمن أن تكون جميع التقارير التي تتضمّن المعرّف المشترك نفسه جزءًا من حزمة واحدة.

إذا سبق أن تمت معالجة تقرير في مجموعة أخرى، يمكن أن تؤدي المعالجة إلى ظهور خطأ بسبب استنفاد ميزانية الخصوصية. يساعد تجميع التقارير بشكل صحيح في منع رفض المجموعات بسبب قاعدة "عدم التكرار".

المعرّف المشترك هو مفتاح يتم إنشاؤه لكل تقرير لتتبُّع محاسبة التقارير القابلة للتجميع. يضمن رقم التعريف المشترك أنّ التقارير التي تتضمّن رقم التعريف المشترك نفسه تساهم في تقرير موجز واحد فقط. وهذا يعني أنّه يجب تضمين جميع التقارير المرتبطة بمعرّف مشترك واحد في حزمة واحدة. على سبيل المثال، إذا كان التقرير "س" والتقرير "ص" يتضمّنان المعرّف المشترك نفسه، يجب تضمينهما في الدفعة نفسها لتجنُّب حذف التقارير بسبب التكرار.

توضّح الصورة التالية مكوّنات shared_info التي يتم تشفيرها معًا لإنشاء معرّف مشترك.

توضّح الصورة التالية كيف يمكن أن يتضمّن تقريران مختلفان رقم تعريف مشتركًا نفسه:

ملاحظة: يتم اقتطاع scheduled_report_time حسب الساعة، ويتم اقتطاع source_registration_time حسب اليوم. بالإضافة إلى ذلك، لا يتم استخدام report_id في إنشاء المعرّف المشترك. قد يتم تعديل مستوى التفاصيل الزمنية في المستقبل.

التقارير المكرّرة ضمن الدُفعات

يحتوي الحقل shared_info في تقرير قابل للتجميع على معرّف فريد عالمي في الحقل report_id، ويُستخدم هذا المعرّف لتحديد التقارير المكرّرة ضمن مجموعة. إذا كان هناك أكثر من تقرير واحد يتضمّن report_id نفسه في مجموعة، سيتم تجميع التقرير الأول فقط، وسيتم اعتبار التقارير الأخرى مكرّرة وسيتم تجاهلها بدون إشعار. وسيستمر التجميع كالمعتاد ولن يتم إرسال أي أخطاء. على الرغم من أنّ ذلك ليس مطلوبًا، يمكن أن تتوقّع تكنولوجيات الإعلان تحقيق بعض التحسينات في الأداء من خلال فلترة التقارير المكرّرة التي تتضمّن أرقام تعريف التقارير نفسها قبل التجميع.

report_id هو معرّف فريد لكل تقرير.

التقارير المكرّرة في جميع الدفعات

يتم تعيين معرّف مشترك لكل تقرير، وهو معرّف يتم إنشاؤه من نقاط البيانات المجمّعة الواردة من الحقل shared_info في التقرير. يمكن أن تتضمّن تقارير متعددة المعرّف المشترك نفسه، ويمكن أن تحتوي كل مجموعة على معرّفات مشتركة متعددة. يجب أن يتم إدراج جميع التقارير التي تحمل المعرّف المشترك نفسه في الدفعة نفسها. إذا انتهى الأمر بتقسيم التقارير التي تتضمّن رقم التعريف المشترك نفسه إلى عدّة دفعات، سيتم قبول الدفعة الأولى فقط، وسيتم رفض الدفعات الأخرى باعتبارها مكرّرة. لمنع حدوث ذلك، يجب إنشاء الدفعات بشكلٍ مناسب.

تعرض الصورة التالية مثالاً على الحالات التي يمكن أن تؤدي فيها التقارير التي تتضمّن المعرّف المشترك نفسه في جميع الدفعات إلى تعذّر الدفعة اللاحقة. في الصورة، يمكنك ملاحظة أنّه يتم تجميع تقريرَين أو أكثر يحملان رقم التعريف المشترك نفسه e679aa في مجموعتَين مختلفتَين، المجموعة 1 والمجموعة 2. بما أنّ ميزانية جميع التقارير التي تتضمّن المعرّف المشترك e679aa يتم استهلاكها أثناء إنشاء تقرير الملخّص الخاص بالدفعة رقم 1، لا يُسمح بالدفعة رقم 2 وتحدث فيها أخطاء.

التقارير المجمّعة

في ما يلي الطرق المقترَحة لتجميع التقارير لتجنُّب التكرار وتحسين احتساب التقارير المجمّعة.

التقسيم إلى مجموعات حسب المعلِن

ملاحظة: لا يُنصح باستخدام هذه الاستراتيجية إلا لتجميع "تقارير تحديد المصدر".

لا تتضمّن Private Aggregation الحقل attribution_destination الذي يمثّل المعلِن. ننصحك بتجميع التقارير حسب المعلِن، أي تضمين التقارير التي تخصّ معلنًا واحدًا في المجموعة نفسها، وذلك لتجنُّب بلوغ الحدّ الأقصى لعدد حسابات التقارير القابلة للتجميع لكل مجموعة. المُعلِن هو حقل يتم أخذه في الاعتبار عند إنشاء المعرّف المشترك، لذا قد تتضمّن التقارير التي تتضمّن المُعلِن نفسه المعرّف المشترك نفسه، ما يتطلّب أن تكون في الدفعة نفسها لتجنُّب حدوث أخطاء.

التقسيم إلى دفعات حسب الوقت

يُنصح بمراعاة وقت التقرير المجدول (shared_info.scheduled_report_time) عند تجميع التقارير. يتم اقتطاع وقت التقرير المجدوَل إلى الساعة في عملية إنشاء المعرّف المشترَك، لذا يجب تجميع التقارير على فترات زمنية لا تقل عن ساعة واحدة، ما يعني أنّه يجب وضع جميع التقارير التي يتضمّنها وقت التقرير المجدوَل في الساعة نفسها في المجموعة نفسها لتجنُّب تضمين تقارير تتضمّن المعرّف المشترَك نفسه في مجموعات متعدّدة، ما سيؤدي إلى حدوث أخطاء في المهمة.

معدّل تكرار الدفعات والضوضاء

يُنصح بمراعاة تأثير التشويش في عدد المرات التي تتم فيها معالجة التقارير القابلة للتجميع. إذا تم تجميع التقارير القابلة للتجميع بشكل متكرّر أكثر، مثلاً، تتم معالجة التقارير مرة واحدة في الساعة، سيتم تضمين عدد أقل من أحداث الإحالات الناجحة وسيكون للتشويش تأثير نسبي أكبر. إذا تم خفض معدّل التكرار وتمت معالجة التقارير مرة واحدة في الأسبوع، سيكون للتشويش تأثير نسبي أقل. لفهم تأثير الضوضاء على الدفعات بشكل أفضل، يمكنك تجربة مختبر الضوضاء.