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

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

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

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

گزارش تلاش‌های مجدد برای آپلود

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

در هر دو پلتفرم وب و سیستم عامل، یک پلتفرم سه بار برای ارسال گزارش تلاش می‌کند، اما اگر گزارش پس از سومین تلاش ارسال نشود، ارسال نخواهد شد. مقدار اصلی scheduled_report_time صرف نظر از زمانی که گزارش قادر به ارسال است، حفظ می‌شود. جدول زمانی برای تلاش‌های مجدد در هر پلتفرم متفاوت است:

  • یک مرورگر وب زمانی گزارش‌ها را ارسال می‌کند که مرورگر آنلاین باشد. اگر گزارش ارسال نشود، پنج دقیقه برای تلاش مجدد دوم و سپس ۱۵ دقیقه برای تلاش مجدد سوم منتظر می‌ماند. اگر مرورگر آفلاین شود، تلاش مجدد بعدی یک دقیقه پس از آنلاین شدن مجدد خواهد بود. حداکثر تأخیری در ارسال گزارش‌ها در وب وجود ندارد؛ این بدان معناست که اگر مرورگر آفلاین شود، مهم نیست گزارش چند وقت پیش ایجاد شده باشد، به محض اینکه مرورگر دوباره آنلاین شود، سعی می‌کند گزارش را مطابق با سیاست تلاش مجدد ارسال کند.
  • یک تلفن اندروید اتصال شبکه ثابتی دارد. به این ترتیب، کار ارسال گزارش‌ها را هر ساعت یک بار انجام می‌دهد. این بدان معناست که اگر گزارشی ارسال نشود، ساعت بعد و یک ساعت بعد از آن دوباره تلاش می‌شود. اگر دستگاه اتصال نداشته باشد، دستگاه با کار گزارش‌دهی بعدی که پس از اتصال مجدد دستگاه به شبکه اجرا می‌شود، دوباره ارسال گزارش را امتحان می‌کند. حداکثر تأخیر ۲۸ روز است، به این معنی که دستگاه گزارشی را که بیش از ۲۸ روز پیش تولید شده است، ارسال نخواهد کرد.

منتظر گزارش‌ها باشید

توصیه می‌شود هنگام جمع‌آوری گزارش‌ها برای دسته‌بندی، منتظر گزارش‌های دیررس باشید. گزارش‌های دیررس را می‌توان با بررسی مقدار scheduled_report_time در مقابل زمان دریافت گزارش تعیین کرد. اختلاف زمانی بین این گزارش‌ها به تعیین مدت زمانی که ممکن است بخواهید برای گزارش‌های دیررس منتظر بمانید، کمک می‌کند. به عنوان مثال، هنگام جمع‌آوری گزارش‌های با تأخیر، فیلد scheduled_report_time را بررسی کنید و زمان تأخیر را به ساعت در 90٪، 95٪ و 99٪ گزارش‌های دریافتی یادداشت کنید. از این داده‌ها می‌توان برای تعیین مدت زمان انتظار برای گزارش‌های با تأخیر استفاده کرد. از گزارش‌های تجمیعی فوری می‌توان برای کاهش احتمال تأخیر در گزارش‌ها استفاده کرد.

تصویر زیر گزارش‌های دیر رسیدن را نشان می‌دهد که طبق زمان گزارش برنامه‌ریزی‌شده در دسته‌های مناسب ذخیره می‌شوند. دسته T نشان‌دهنده scheduled_report_time و T+X نشان‌دهنده زمان انتظار برای گزارش‌های تأخیردار است. این منجر به یک گزارش خلاصه می‌شود که شامل اکثر گزارش‌هایی است که در دسته‌ای قرار دارند که مطابق با زمان گزارش برنامه‌ریزی‌شده آنهاست.

گزارش‌ها طبق زمان‌بندی گزارش، در دسته‌های مناسب ذخیره می‌شوند.
گزارش‌ها طبق زمان‌بندی گزارش، در دسته‌های مناسب ذخیره می‌شوند.

حسابداری گزارش‌های تجمیعی

سرویس تجمیع، قانون «عدم تکرار» را رعایت می‌کند. این قانون ایجاب می‌کند که تمام گزارش‌های تجمیع‌پذیر با شناسه مشترک یکسان، در یک دسته قرار گیرند.

پس از جمع‌آوری گزارش‌ها، آنها باید به گونه‌ای دسته‌بندی شوند که همه گزارش‌های دارای شناسه مشترک یکسان، بخشی از یک دسته باشند.

اگر گزارشی قبلاً در دسته دیگری پردازش شده باشد، این پردازش می‌تواند منجر به خطای اتمام بودجه حریم خصوصی شود. دسته‌بندی صحیح گزارش‌ها به جلوگیری از رد شدن دسته‌ها به دلیل قانون "عدم تکرار" کمک می‌کند.

شناسه مشترک ، کلیدی است که برای هر گزارش ایجاد می‌شود تا حسابداری گزارش‌های تجمیعی را ردیابی کند. شناسه مشترک تضمین می‌کند که گزارش‌هایی با شناسه مشترک یکسان، فقط در یک گزارش خلاصه مشارکت داشته باشند. این بدان معناست که گزارش‌هایی که با هم به یک شناسه مشترک نگاشت می‌شوند، باید همگی در یک دسته واحد گنجانده شوند. به عنوان مثال، اگر گزارش X و گزارش Y هر دو شناسه مشترک یکسانی داشته باشند، باید در یک دسته قرار گیرند تا از حذف گزارش‌ها به دلیل تکرار جلوگیری شود.

تصویر زیر کامپوننت‌های shared_info را نشان می‌دهد که برای تولید یک شناسه مشترک با هم هش شده‌اند.

نمایش کامپوننت‌های shared_info که برای تولید یک شناسه مشترک با هم هش شده‌اند.
نمایش کامپوننت‌های shared_info که برای تولید یک شناسه مشترک با هم هش شده‌اند.

تصویر زیر نشان می‌دهد که چگونه دو گزارش مختلف می‌توانند شناسه مشترک یکسانی داشته باشند:

نشان می‌دهد که چگونه دو گزارش مختلف می‌توانند شناسه مشترک یکسانی داشته باشند.
نشان می‌دهد که چگونه دو گزارش مختلف می‌توانند شناسه مشترک یکسانی داشته باشند.

نکته: scheduled_report_time بر اساس ساعت و source_registration_time بر اساس روز خلاصه می‌شود. علاوه بر این، report_id در ایجاد شناسه مشترک استفاده نمی‌شود. جزئیات زمانی ممکن است در آینده به‌روزرسانی شود.

گزارش‌های تکراری در داخل دسته‌ها

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

report_id برای هر گزارش منحصر به فرد است.

گزارش‌های تکراری در بین دسته‌ها

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

تصویر زیر مثالی را نشان می‌دهد که در آن گزارش‌هایی با شناسه مشترک یکسان در بین دسته‌ها می‌توانند باعث از کار افتادن دسته بعدی شوند. در تصویر، می‌توانید ببینید که دو یا چند گزارش با شناسه مشترک یکسان e679aa در دسته‌های مختلف شماره ۱ و ۲ دسته‌بندی شده‌اند. از آنجایی که بودجه همه گزارش‌ها با شناسه مشترک e679aa در طول تولید گزارش خلاصه دسته ۱ مصرف می‌شود، دسته ۲ مجاز نیست و با خطا از کار می‌افتد.

نمایش مثالی که در آن گزارش‌هایی با شناسه مشترک یکسان در بین دسته‌ها می‌توانند باعث خرابی دسته بعدی شوند.
نمایش مثالی که در آن گزارش‌هایی با شناسه مشترک یکسان در بین دسته‌ها می‌توانند باعث خرابی دسته بعدی شوند.

گزارش‌های دسته‌ای

در ادامه روش‌های توصیه‌شده برای دسته‌بندی گزارش‌ها به منظور جلوگیری از تکرار و بهینه‌سازی حسابداری گزارش‌های تجمیعی ارائه شده است.

دسته‌ای بر اساس تبلیغ‌کننده

توجه: این استراتژی فقط برای تجمیع گزارش‌های انتسابی توصیه می‌شود.

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

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

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

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

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