هنگام استفاده از Data Manager API، روال‌های مطلوب زیر را درنظر داشته باشید.
ارسال همه شناسه‌های کاربر
چه درحال ارسال اعضای مخاطب باشید چه رویدادها با UserData، تا جایی که ممکن است
user_identifiers اضافه کنید، ازجمله ارسال چند شناسه از
یک نوع.
برای مثال، اگر چند نشانی ایمیل برای یک کاربر دارید، برای هر نشانی ایمیل یک
UserIdentifier جداگانه اضافه کنید. به‌طور مشابه، اگر شناسه‌هایی از انواع مختلف برای یک کاربر دارید، مانند نشانی‌های ایمیل، شماره تلفن‌ها، و نشانی‌ها، برای هر شناسه یک UserIdentifier جداگانه اضافه کنید، تا حداکثر تعداد شناسه.
بهینه‌سازی درخواست‌ها
برای کاهش احتمال فراتر رفتن از محدودیت‌های درخواست روزانه، تا حد امکان موارد بیشتری را در هر درخواست دسته‌بندی کنید، تا محدودیت‌های هر درخواست.
برای مثال، اگر می‌خواهید ۱۰٬۰۰۰ عضو مخاطب به مخاطبی اضافه کنید، همه ۱۰٬۰۰۰ عضو را در فهرست audience_members در یک IngestAudienceMembersRequest اضافه کنید. دسته‌بندی کردن همه ۱۰٬۰۰۰ عضو در یک درخواست واحد کارآمدتر از ارسال درخواست جداگانه برای افزودن هر عضو مخاطب است.
ارسال درخواست‌های هم‌زمان
برای کاهش زمان کلی موردنیاز برای جذب داده‌ها، درخواست‌های هم‌زمان به IngestionService ارسال کنید. توصیه می‌کنیم حداکثر ۱۰ درخواست را به‌طور هم‌زمان ارسال کنید تا احتمال فراتر رفتن از محدودیت درخواست در دقیقه کاهش یابد.
می‌توانید درخواست‌های هم‌زمان ارسال کنید، حتی اگر درخواست‌ها دارای
destinations یکسان باشند.
اعتبارسنجی داده‌ها در سمت کارخواه
Data Manager API از مدل شکست سریع استفاده می‌کند. اگر هرکدام از سوابق موجود در درخواست در اعتبارسنجی همگام ناموفق باشد، کل درخواست ناموفق می‌شود و هیچ‌کدام از سوابق پردازش نمی‌شود. علاوه‌براین، میانای برنامه‌سازی کاربردی درخواست‌ها را در لایه‌های متوالی اعتبارسنجی می‌کند، بنابراین رفع یک خطا ممکن است خطایی را از لایه اعتبارسنجی بعدی آشکار کند.
برای جلوگیری از رفت‌وبرگشت‌های مکرر و درخواست‌های ردشده، داده‌هایتان را قبل‌از ارسال، اعتبارسنجی و پاک‌سازی کنید:
حذف مقادیر خالی قبل‌از درهم‌سازی: فیلدهایی مانند
email_addressوphone_numberرا برای رشته‌های خالی یا فقط دارای فضای خالی قبل‌از محاسبه درهم‌سازی‌های SHA-256 بررسی کنید. درهم‌سازی رشته خالی، درهم‌سازی معتبری تولید می‌کند که بررسی‌های نحوی را می‌گذراند اما به نرخ‌های مطابقت آسیب می‌زند.رها کردن اشیای مرکب ناقص: مطمئن شوید اشیای مرکب همه فیلدهای الزامی را قبل‌از اضافه شدن به سابقه داشته باشند. برای مثال، اگر شیء
AddressInfoفاقد هرکدام از چهار فیلد الزامی‌اش (given_name،family_name،region_code، یاpostal_code) باشد، کل شناسهaddressرا حذف کنید تا از خطاهایREQUIRED_FIELD_MISSINGجلوگیری شود.اعتبارسنجی فیلدهای کدبندی و نوشتار ساده: بررسی کنید که فیلدهای درهم‌سازی‌شده با
encodingاعلام‌شده مطابقت داشته باشند و نوشتار ساده خام ارسال نشود، و مطمئن شوید فیلدهایی که باید نوشتار ساده باقی بمانند (مثلmobile_ids) درهم‌سازی نشده باشند.مُهرهای زمان خارج از محدوده را فیلتر کنید: مطمئن شوید مُهرهای زمان در آینده نباشند یا قدیمی‌تر از پنجره بازگشتی تبدیل مقصد نباشند.
اگر درخواست‌ها را بااستفاده از JSON ارسال می‌کنید، مطمئن شوید رشته‌های مُهر زمان از قالب RFC 3339 با انحراف منطقه زمانی استفاده می‌کنند.
شماره تلفن‌های تمیز: مطمئن شوید شماره تلفن‌ها کد کشور داشته باشند و قبل‌از درهم‌سازی از قالب E.164 استفاده کنید.
هرزگیری رکوردهای خالی یا بیش‌ازحد بزرگ:
user_identifiersرا در حد هر رکورد (۱۰ شناسه) محدود کنید، پارامترهای سفارشی خالی را حذف کنید، و هر رکوردی را که حاوی شناسه معتبر صفر است حذف کنید.درستی‌سنجی الزامات مورد استفاده: مطمئن شوید هر رویداد شامل همه فیلدهای اجباری برای مقصد و مورد استفاده خود باشد (مانند
transaction_idبرای تبدیل‌های آنلاین Google Ads). برای مشاهده فهرست کامل فیلدهای الزامی براساس مورد استفاده، به راهنمای ارسال رویدادها برای مقصدتان در نمای کلی رویدادها مراجعه کنید.از
validateOnlyبرای آزمایش درخواست‌ها استفاده کنید: درخواست‌ها را باvalidateOnlyتنظیم‌شده رویtrueارسال کنید تا خطاهای سریع-ناموفق را بدون دریافت یا حذف داده‌ها بگیرید. موفقیت‌آمیز بودن درخواست فقط اعتبارسنجی تضمین نمی‌کند که درطول پردازش ناهمگام خطایی رخ نخواهد داد، بنابراین پس‌از ارسال درخواست عادی، همچنان وضعیت درخواست و عیب‌یابی را بررسی کنید.
برای اطلاع از قوانین دقیق نرمال‌سازی و درهم‌سازی، قالب‌بندی داده‌های کاربر را ببینید.
بررسی وضعیت درخواست و عیب‌یابی
request_id را از هر
IngestAudienceMembersResponse یا
IngestEventsResponse ضبط و جمع‌آوری کنید و از شناسه‌های درخواست برای
بررسی وضعیت درخواست و عیب‌یابی استفاده کنید.
نظارت و هشدار درباره سهمیه‌ها
برای جلوگیری از رد شدن غیرمنتظره درخواست، هشدارها و پایش سهمیه را در کنسول Google Cloud راه‌اندازی کنید. پایش مصرف سهمیه به شما کمک می‌کند الگوهای مصرف را ردیابی کنید و دسته‌بندی درخواست‌ها را قبل‌از اینکه برنامه‌تان به محدودیت‌های روزانه یا دقیقه‌ای برسد بهینه کنید.
استقرار در تولید
هنگام انتقال از آزمایش محلی به بارهای کاری تولید، از اعتبارنامه‌های پیش‌فرض برنامه با حساب سرویس پیوست‌شده یا Workload Identity Federation برای اصالت‌سنجی غیرتعاملی و ایمن استفاده کنید.
برای جزئیات مربوط به پیکربندی اصالت‌سنجی برای محیط‌های تولید مختلف، استقرار در تولید را ببینید.