استراتژی بچینگ، استراتژی بچینگ، استراتژی بچینگ، استراتژی بچینگ

هنگام جمع‌آوری گزارش‌های انبوه، مهم است که استراتژی‌های دسته‌بندی را بهینه کنید تا از محدودیت‌های حریم خصوصی فراتر نرود. در زیر چند استراتژی توصیه شده برای ارسال دسته‌ای از گزارش‌ها به سرویس تجمع آورده شده است.

جمع آوری گزارش

هنگام جمع آوری گزارش ها برای گنجاندن در یک دسته، موارد زیر را در نظر داشته باشید:

گزارش بارگذاری مجدد

توجه: معیارهای امتحان مجدد ممکن است تغییر کنند. در این صورت اطلاعات این بخش به روز می شود.

در هر دو پلتفرم وب و سیستم عامل، یک پلتفرم سعی می کند گزارش را سه بار ارسال کند، اما اگر گزارش پس از تلاش سوم ارسال نشد، ارسال نمی شود. مقدار اولیه 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 Reporting توصیه می شود.

Private Aggregation فیلد attribution_destination که تبلیغ‌کننده است ندارد. توصیه می‌شود که دسته‌ای براساس آگهی‌دهنده باشد، به این معنی که گزارش‌های متعلق به یک تبلیغ‌کننده را در همان دسته گنجانده شود تا از رسیدن به حد مجاز حساب گزارش جمع‌آوری برای هر دسته جلوگیری شود. آگهی‌دهنده فیلدی است که در تولید شناسه مشترک در نظر گرفته می‌شود، بنابراین گزارش‌هایی که با همان تبلیغ‌کننده دارند می‌توانند شناسه مشترک یکسانی نیز داشته باشند، که برای جلوگیری از خطا، باید در یک دسته باشند.

دسته بر اساس زمان

توصیه می‌شود هنگام دسته‌بندی، زمان گزارش برنامه‌ریزی شده ( shared_info.scheduled_report_time ) را در نظر بگیرید. زمان گزارش برنامه‌ریزی‌شده به ساعت در تولید شناسه مشترک کوتاه می‌شود، بنابراین حداقل گزارش‌ها باید در فواصل یک ساعتی دسته‌بندی شوند، به این معنی که همه گزارش‌ها با زمان گزارش برنامه‌ریزی‌شده در یک ساعت باید در یک دسته ارائه شوند تا از داشتن گزارش‌هایی با اشتراک‌گذاری یکسان جلوگیری شود. شناسه در چندین دسته، که منجر به خطاهای شغلی می شود.

فرکانس دسته ای و نویز

توصیه می شود تأثیر نویز را بر تعداد دفعات پردازش گزارش های جمع آوری در نظر بگیرید. اگر گزارش‌های جمع‌آوری‌شده بیشتر دسته‌بندی شوند - برای مثال، گزارش‌ها یک بار پردازش می‌شوند که رویدادهای تبدیل کمتری در ساعت گنجانده شود و نویز تأثیر نسبی بیشتری خواهد داشت. اگر فرکانس کاهش یابد و گزارش ها یک بار در هفته پردازش شوند، نویز تاثیر نسبی کمتری خواهد داشت. برای درک بهتر تأثیر نویز بر روی دسته‌ها، با آزمایشگاه نویز آزمایش کنید.