گزارش بهترین شیوه ها

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

ذخیره و استفاده مجدد از گزارش‌ها

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

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

گزارش‌های موردی یا یک‌باره می‌توانند منابع را هدر دهند زیرا به‌صورت جداگانه اجرا می‌شوند و ممکن است روی یک مجموعه داده ناقص اجرا شوند. گزارش‌های زمان‌بندی‌شده بهترین استفاده را از منابع گزارش‌دهی می‌کنند زیرا به‌صورت انبوه اجرا می‌شوند و تضمین می‌شود که تا زمانی که داده‌های روز قبل پردازش نشده‌اند، اجرا نشوند. برای جزئیات بیشتر به فیلدهای زمان‌بندی موجود مراجعه کنید.

هنگام نمونه‌برداری برای وضعیت گزارش، از backoff نمایی استفاده کنید

پیش‌بینی مدت زمان اجرای یک گزارش امکان‌پذیر نیست. مدت زمان می‌تواند از چند ثانیه تا چند ساعت متغیر باشد که به عوامل زیادی از جمله محدوده تاریخ و میزان داده‌هایی که باید پردازش شوند، بستگی دارد. همچنین هیچ همبستگی بین زمان اجرای گزارش و تعداد ردیف‌های برگردانده شده در گزارش وجود ندارد. بنابراین، باید مرتباً وضعیت یک گزارش در حال اجرا را بررسی کنید تا مشخص شود چه زمانی به پایان رسیده است. این فرآیندی است که به عنوان "polling" شناخته می‌شود.

اگرچه نظرسنجی ضروری است، اما یک پیاده‌سازی ناکارآمد ممکن است هنگام مواجهه با یک گزارش طولانی مدت، سهمیه شما را به سرعت تمام کند. بنابراین توصیه می‌شود از backoff نمایی برای محدود کردن تلاش‌های مجدد و حفظ سهمیه استفاده کنید.

دانلودهای چند قسمتی را انجام دهید

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

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

شناسه‌های جستجوی پولی قدیمی

شناسه‌های جستجوی پولی قدیمی مانند شناسه‌های کمپین جستجوی پولی می‌توانند در گزارش‌های سطح رویداد CM360 و گزارش‌های استخراج‌شده از طریق API CM360 ظاهر شوند. نمونه‌ای از گزارش سطح رویداد، گزارشی است که حاوی متغیرهای سفارشی Floodlight است. برای مشتریانی که از API CM360 استفاده می‌کنند، سرویس نقشه‌برداری شناسه تبلیغات جستجو ۳۶۰ می‌تواند به آنها در تبدیل فضاهای شناسه قدیمی به جدید کمک کند.

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

استفاده مسئولانه از ویژگی گزارش‌دهی Campaign Manager 360 از طریق سه سهمیه استفاده در کل محصول زیر اعمال می‌شود:

  1. گزارش‌های موردی اجرا شده (در هر روز)

    تعداد گزارش‌های موردی که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند در یک دوره ۲۴ ساعته اجرا کند را محدود می‌کند. برای ماندن در سهمیه:

    • کاهش گزارش‌های تکراری
    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  2. گزارش‌های برنامه‌ریزی‌شده فعال

    تعداد گزارش‌هایی را که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند به طور فعال در یک زمان معین برنامه‌ریزی کند، محدود می‌کند. برای ماندن در سهمیه تعیین شده:

    • کاهش گزارش‌های تکراری
    • گزارش‌های زمان‌بندی‌شده‌ی غیرضروری را غیرفعال کنید.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  3. گزارش‌های همزمان

    تعداد گزارش‌هایی را که یک حساب CM / یک پروفایل کاربر CM می‌تواند همزمان اجرا کند، محدود می‌کند. برای ماندن در سهمیه:

    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
    • منطق backoff را پیاده‌سازی کنید.

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

،

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

ذخیره و استفاده مجدد از گزارش‌ها

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

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

گزارش‌های موردی یا یک‌باره می‌توانند منابع را هدر دهند زیرا به‌صورت جداگانه اجرا می‌شوند و ممکن است روی یک مجموعه داده ناقص اجرا شوند. گزارش‌های زمان‌بندی‌شده بهترین استفاده را از منابع گزارش‌دهی می‌کنند زیرا به‌صورت انبوه اجرا می‌شوند و تضمین می‌شود که تا زمانی که داده‌های روز قبل پردازش نشده‌اند، اجرا نشوند. برای جزئیات بیشتر به فیلدهای زمان‌بندی موجود مراجعه کنید.

هنگام نمونه‌برداری برای وضعیت گزارش، از backoff نمایی استفاده کنید

پیش‌بینی مدت زمان اجرای یک گزارش امکان‌پذیر نیست. مدت زمان می‌تواند از چند ثانیه تا چند ساعت متغیر باشد که به عوامل زیادی از جمله محدوده تاریخ و میزان داده‌هایی که باید پردازش شوند، بستگی دارد. همچنین هیچ همبستگی بین زمان اجرای گزارش و تعداد ردیف‌های برگردانده شده در گزارش وجود ندارد. بنابراین، باید مرتباً وضعیت یک گزارش در حال اجرا را بررسی کنید تا مشخص شود چه زمانی به پایان رسیده است. این فرآیندی است که به عنوان "polling" شناخته می‌شود.

اگرچه نظرسنجی ضروری است، اما یک پیاده‌سازی ناکارآمد ممکن است هنگام مواجهه با یک گزارش طولانی مدت، سهمیه شما را به سرعت تمام کند. بنابراین توصیه می‌شود از backoff نمایی برای محدود کردن تلاش‌های مجدد و حفظ سهمیه استفاده کنید.

دانلودهای چند قسمتی را انجام دهید

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

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

شناسه‌های جستجوی پولی قدیمی

شناسه‌های جستجوی پولی قدیمی مانند شناسه‌های کمپین جستجوی پولی می‌توانند در گزارش‌های سطح رویداد CM360 و گزارش‌های استخراج‌شده از طریق API CM360 ظاهر شوند. نمونه‌ای از گزارش سطح رویداد، گزارشی است که حاوی متغیرهای سفارشی Floodlight است. برای مشتریانی که از API CM360 استفاده می‌کنند، سرویس نقشه‌برداری شناسه تبلیغات جستجو ۳۶۰ می‌تواند به آنها در تبدیل فضاهای شناسه قدیمی به جدید کمک کند.

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

استفاده مسئولانه از ویژگی گزارش‌دهی Campaign Manager 360 از طریق سه سهمیه استفاده در کل محصول زیر اعمال می‌شود:

  1. گزارش‌های موردی اجرا شده (در هر روز)

    تعداد گزارش‌های موردی که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند در یک دوره ۲۴ ساعته اجرا کند را محدود می‌کند. برای ماندن در سهمیه:

    • کاهش گزارش‌های تکراری
    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  2. گزارش‌های برنامه‌ریزی‌شده فعال

    تعداد گزارش‌هایی را که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند به طور فعال در یک زمان معین برنامه‌ریزی کند، محدود می‌کند. برای ماندن در سهمیه تعیین شده:

    • کاهش گزارش‌های تکراری
    • گزارش‌های زمان‌بندی‌شده‌ی غیرضروری را غیرفعال کنید.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  3. گزارش‌های همزمان

    تعداد گزارش‌هایی را که یک حساب CM / یک پروفایل کاربر CM می‌تواند همزمان اجرا کند، محدود می‌کند. برای ماندن در سهمیه:

    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
    • منطق backoff را پیاده‌سازی کنید.

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

،

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

ذخیره و استفاده مجدد از گزارش‌ها

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

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

گزارش‌های موردی یا یک‌باره می‌توانند منابع را هدر دهند زیرا به‌صورت جداگانه اجرا می‌شوند و ممکن است روی یک مجموعه داده ناقص اجرا شوند. گزارش‌های زمان‌بندی‌شده بهترین استفاده را از منابع گزارش‌دهی می‌کنند زیرا به‌صورت انبوه اجرا می‌شوند و تضمین می‌شود که تا زمانی که داده‌های روز قبل پردازش نشده‌اند، اجرا نشوند. برای جزئیات بیشتر به فیلدهای زمان‌بندی موجود مراجعه کنید.

هنگام نمونه‌برداری برای وضعیت گزارش، از backoff نمایی استفاده کنید

پیش‌بینی مدت زمان اجرای یک گزارش امکان‌پذیر نیست. مدت زمان می‌تواند از چند ثانیه تا چند ساعت متغیر باشد که به عوامل زیادی از جمله محدوده تاریخ و میزان داده‌هایی که باید پردازش شوند، بستگی دارد. همچنین هیچ همبستگی بین زمان اجرای گزارش و تعداد ردیف‌های برگردانده شده در گزارش وجود ندارد. بنابراین، باید مرتباً وضعیت یک گزارش در حال اجرا را بررسی کنید تا مشخص شود چه زمانی به پایان رسیده است. این فرآیندی است که به عنوان "polling" شناخته می‌شود.

اگرچه نظرسنجی ضروری است، اما یک پیاده‌سازی ناکارآمد ممکن است هنگام مواجهه با یک گزارش طولانی مدت، سهمیه شما را به سرعت تمام کند. بنابراین توصیه می‌شود از backoff نمایی برای محدود کردن تلاش‌های مجدد و حفظ سهمیه استفاده کنید.

دانلودهای چند قسمتی را انجام دهید

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

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

شناسه‌های جستجوی پولی قدیمی

شناسه‌های جستجوی پولی قدیمی مانند شناسه‌های کمپین جستجوی پولی می‌توانند در گزارش‌های سطح رویداد CM360 و گزارش‌های استخراج‌شده از طریق API CM360 ظاهر شوند. نمونه‌ای از گزارش سطح رویداد، گزارشی است که حاوی متغیرهای سفارشی Floodlight است. برای مشتریانی که از API CM360 استفاده می‌کنند، سرویس نقشه‌برداری شناسه تبلیغات جستجو ۳۶۰ می‌تواند به آنها در تبدیل فضاهای شناسه قدیمی به جدید کمک کند.

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

استفاده مسئولانه از ویژگی گزارش‌دهی Campaign Manager 360 از طریق سه سهمیه استفاده در کل محصول زیر اعمال می‌شود:

  1. گزارش‌های موردی اجرا شده (در هر روز)

    تعداد گزارش‌های موردی که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند در یک دوره ۲۴ ساعته اجرا کند را محدود می‌کند. برای ماندن در سهمیه:

    • کاهش گزارش‌های تکراری
    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  2. گزارش‌های برنامه‌ریزی‌شده فعال

    تعداد گزارش‌هایی را که یک حساب کاربری CM / یک پروفایل کاربری CM می‌تواند به طور فعال در یک زمان معین برنامه‌ریزی کند، محدود می‌کند. برای ماندن در سهمیه تعیین شده:

    • کاهش گزارش‌های تکراری
    • گزارش‌های زمان‌بندی‌شده‌ی غیرضروری را غیرفعال کنید.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
  3. گزارش‌های همزمان

    تعداد گزارش‌هایی را که یک حساب CM / یک پروفایل کاربر CM می‌تواند همزمان اجرا کند، محدود می‌کند. برای ماندن در سهمیه:

    • گزارش‌هایی را برنامه‌ریزی کنید که به‌طور منظم اجرا شوند.
    • اسکریپت‌های API غیرضروری را غیرفعال کنید.
    • منطق backoff را پیاده‌سازی کنید.

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