مشروع ترقية Ads API يحتاج تقويمًا وسجل استخدام، وليس قراءة release notes يوم التعطل.
صفحة deprecation and sunset الرسمية في Google Ads API توضح أن الإصدارات الرئيسية تعيش قرابة 12 شهرًا، وأن v22 الصادر في 15 أكتوبر 2025 له sunset tentatively في أكتوبر 2026، بينما v25 صدر في 22 يوليو 2026 ويمتد إلى أغسطس 2027. هذا يمنح فرق الإعلانات فرصة ترقية منظمة بدل علاج مفاجئ.
لماذا هذا مهم للوكالات؟
لوحة التقارير أو automation قد تستخدم أكثر من service: GoogleAdsService للقراءة، CampaignService للتعديل، ConversionUploadService للقياس، وأحيانًا مكتبات بلغات مختلفة. ترقية endpoint واحد لا تعني أن النظام كله أصبح آمنًا.
Google يوضح أن Cloud Console يعرض الطرق التي استدعاها المشروع مؤخرًا، واسم method يتضمن version وservice. هذه نقطة بداية ممتازة لجرد الاستخدام الحقيقي بدل البحث اليدوي في كل repo.
خطة ترقية صغيرة
ابدأ بجرد آخر 30 يومًا من requests حسب version وservice، ثم صنّفها: قراءة فقط، تعديل، upload conversions، أو reporting. بعد ذلك اختر نسخة target واضحة مثل v25، وراجع minimum client library لكل لغة مستخدمة.
لا تؤجل الاختبارات حتى موعد sunset. جرّب أولًا حساب test أو manager محدود، ثم شغّل reporting comparison بين النسخة القديمة والجديدة للأبعاد المهمة في PMax وDemand Gen حتى لا تكتشف فرق field أو metric بعد النشر.
Checklist
- استخرج versions المستخدمة من Google Cloud Console.
- صنّف كل service حسب read أو mutate أو upload.
- راجع sunset dates قبل ترتيب العمل الشهري.
- حدّث client libraries المتوافقة مع v25.
- اختبر تقارير PMax وDemand Gen قبل التبديل.
- احتفظ بسجل rollback لكل integration مهم.
أين تدخل ok4host؟
ok4host يراجع integrations الخاصة بـ Google Ads API ويحول الترقية إلى تقويم واضح: جرد، اختبار، انتقال، ومراقبة بعد التشغيل.
أسئلة شائعة
هل يجب الترقية بالتسلسل؟ Google يوضح أنك لا تحتاج دائمًا إلى ترقية sequential؛ يمكن الانتقال لإصدار أحدث مناسب.
هل deprecated يعني متعطل؟ لا، لكنه ليس الأحدث وقد لا يحصل على ميزات جديدة.
ما أول فحص؟ قائمة methods الفعلية في Cloud Console.
المصادر
هل integrations الإعلانات عندك لها تقويم ترقية؟
نراجع الإصدارات والطرق المستخدمة ونبني خطة انتقال قبل موعد sunset.
اطلب مراجعة الموقع