لماذا ترفض Google Ads وDV360 وAd Manager إعلانات HTML5 المولّدة من خلاصة المنتجات

تحدد Google Ads الحد الأقصى لإعلان العرض HTML5 المرفوع بـ 600 KB و40 ملفًا داخل أرشيف ZIP، وفقًا لـمواصفات إعلانات العرض المرفوعة الصادرة عن Google نفسها. أما Display & Video 360 فيسمح بما يصل إلى 100 ملف، لكنه يحدد الوزن الإجمالي للتنزيل الذي يسحبه المتصفح عند عرض الإعلان بـ 5 MB، ويقيّد الإعلان الواحد بـ 25 ملف تعريف ارتباط (cookie) و100 استدعاء HTTP خارجي، بحسب إرشادات DV360 لإعلانات HTML5. ليست هذه الأرقام سرية، فهي منشورة في صفحات المواصفات الخاصة بكل منصة. ومع ذلك، تتعثر مسارات إنتاج الإعلانات المعتمدة على الخلاصة بها باستمرار، لأن ملف ZIP الذي يجمّعه محرك القوالب من آلاف الـ SKU يختلف تمامًا عن ملف ZIP الذي يبنيه مصمم يدويًا. هذا الدليل موجّه لمن يتولى ضمان جودة الإعلانات (creative QA) في حساب كتالوج: الأسباب المحددة التي تجعل Google Ads وDV360 وGoogle Ad Manager ترفض إعلانات HTML5 المولّدة من بيانات خلاصة المنتجات، والحل لكل سبب، لتكتشفوها قبل أن تكتشفها المنصة.

لماذا يفشل HTML5 المولّد من الخلاصة في المراجعة أكثر من الإعلان المبني يدويًا

يضمّن المصمم الذي يبني لافتة واحدة يدويًا صورة المنتج مباشرة في ملف ZIP، ويكتب clickTag واحدًا، ويتحقق من عدد الملفات مرة واحدة. أما محرك القوالب الذي يولّد اللافتة نفسها لـ 4,000 SKU فيكرر كل قرار 4,000 مرة، والخطأ الذي لا كلفة له عند n=1 يتضاعف على نطاق واسع.

تفسّر أربعة أنماط معظم هذه المشكلات. أولًا، يشير القالب عادةً إلى صور المنتجات عبر عنوان image_link مباشرة من الخلاصة، لأنه الحقل المتوفر أصلًا في الخلاصة، بدل تنزيل الملف وتضمينه، وهو ما يتطلبه تنسيق ZIP. ثانيًا، القالب الذي يمنح كل حالة شارة (متوفر، تخفيض، الأكثر مبيعًا، كمية محدودة) ملف صورة خاصًا بها يضاعف عدد ملفات الأرشيف قبل إضافة أي صورة منتج. ثالثًا، تقليص حجم ملفات البناء (minification) لتسريع التسليم يزيل البيانات الوصفية ويشوّش أسماء المتغيرات، ومنها وسم ad.size الوصفي ومتغير clickTag اللذان تقرؤهما منصات الإعلانات بالاسم الحرفي. رابعًا، تضيف كل أداة في المنظومة، من طبقة أتمتة الإعلانات إلى وسم التحليلات إلى بكسل شبكة الإعلانات نفسها، نصًا برمجيًا أو ملف تعريف ارتباط خاصًا بها، ولا يختبر أحد الإعلان المجمّع مقابل الحد الإجمالي للمنصة إلا بعد أن يكون قد دخل المراجعة.

الحدود التقنية، منصة بمنصة

هذه هي الأرقام التي تُطبَّق فعليًا. وحيث لم تنشر المنصة رقمًا صارمًا، نذكر ذلك بدل التخمين.

المصادر: مواصفات إعلانات العرض المرفوعة في Google Ads، استكشاف أخطاء أصول HTML5 في حملات التطبيقات على Google Ads وإصلاحها، إرشادات DV360 لإعلانات HTML5، إرشادات Google Ad Manager لـ HTML5.

خمسة أسباب للرفض تتكرر في كل المنصات، والحل لكل منها

1. عناوين صور مطلقة بدل الأصول المضمّنة

يسحب القالب image_link مباشرة من الخلاصة ويكتبه في الشيفرة كما هو:

<img src="https://cdn.example.com/feed/sku-4471-a.jpg">

يعيد مدقق أصول HTML5 لدى Google خطأً محددًا لهذه الحالة في حزم الإعلانات البينية لحملات التطبيقات: «يحاول إعلان HTML5 الخاص بك الإشارة إلى أصل خارج ملف ‎.ZIP. لا يُسمح إلا بالإشارات إلى الملفات الداخلية.» وتنطبق القاعدة نفسها، بنص خطأ أقل وضوحًا، على إعلانات العرض القياسية وعلى DV360.

الحل: أثناء البناء، نزّلوا الملف الذي يشير إليه عنوان image_link، وأعيدوا ترميزه داخل ZIP تحت مسار نسبي، ثم أشيروا إلى هذا المسار بدلًا منه:

<img src="assets/sku-4471-a.jpg">

2. تضخم عدد الملفات بسبب أصول الشارات والأيقونات لكل نسخة

قالب بست حالات للشارات عبر ثمانية مقاسات إعلانية يعني 48 ملفًا قبل إضافة أي صورة منتج، أي أكثر من حد الـ 40 ملفًا في إعلانات العرض القياسية على Google Ads. وفي كتالوج يضم مئات العروض الترويجية النشطة، يُعد هذا السبب الأكثر شيوعًا لفشل تصدير دفعة كاملة بينما اجتاز القالب نفسه فحص الجودة على مجموعة اختبار من خمسة منتجات.

الحل: ادمجوا حالات الشارات في spritesheet واحد أو في <symbol> SVG مضمّن يُستدعى عبر فئة CSS، ليبقى عدد الملفات ثابتًا مهما بلغ عدد حالات الشارات أو المقاسات في الحملة.

3. وسم ad.size الوصفي مفقود أو محذوف

كثيرًا ما تحذف خطوات التقليص (minification)، المصممة للسرعة لا للامتثال لمتطلبات تقنية الإعلانات، محتوى <head> أو تعيد ترتيبه، بما في ذلك الوسم الوصفي للأبعاد الذي تقرؤه المنصات بالاسم الحرفي. ونص خطأ المدقق في Google Ads لهذه الحالة هو: «إعلان HTML5 الخاص بك يفتقر إلى ملف ‎.HTML أساسي. تتضمن ملفات ‎.HTML الأساسية وسم حجم الإعلان.» ويتطلب Google Ad Manager المعلومة نفسها على الصيغة <meta name="ad.size" content="width=300,height=250">.

الحل: نفّذوا فحص الوسم الوصفي بعد التقليص لا قبله، وأضيفوه كبوابة آلية في مسار التصدير بدل الاكتفاء بفحص يدوي عشوائي.

4. clickTag مكتوب ثابتًا في الكود، أو مفقود، أو مقلَّص حتى يتعذر التعرف عليه

يحوّل أداة التقليص معالج نقر مقروءًا إلى شيء مثل var a=b(3). وتنص إرشادات DV360 صراحةً على أن وسم النقر «ينبغي أن يكون سهل القراءة على خادم الإعلانات»، وتوجّه الفرق إلى عدم تمريره عبر أداة تقليص الشيفرة؛ أما Ad Manager فيتطلب المتغير نفسه، مُعلنًا تمامًا باسم clickTag، في الـ head.

الحل: أعلنوه مرة واحدة، دون تقليص، واستثنوا هذا السطر وحده من مرحلة التقليص: var clickTag = "https://example.com/product/4471";. ولا تكتبوا عنوان الوجهة ثابتًا في أي موضع آخر من الشيفرة، فـ Ad Manager لا يستطيع نسب النقرات التي لا يراها عبر هذا المتغير.

5. تجاوز حد ملفات تعريف الارتباط واستدعاءات HTTP بسبب تراكم أدوات التتبع

يحدد DV360 الإعلان الواحد بحد صارم قدره 25 ملف تعريف ارتباط و100 استدعاء HTTP خارجي. وكل وسم على حدة، سواء كان بكسل إعادة استهداف أو طلب خط ويب أو استدعاء GA4 أو مقطع التتبع الخاص بمنصة أتمتة الإعلانات، متوافق بمفرده. لكنها مجتمعةً في إعلان واحد مجمّع غير متوافقة، ولا يظهر التجاوز إلا عندما يختبر أحدهم الحزمة النهائية لا القالب.

الحل: مرّروا التتبع عبر حاوية واحدة لإدارة الوسوم لكل إعلان بدل إضافة البكسلات واحدًا واحدًا، وحمّلوا الخطوط محليًا بدل طلبها خارجيًا، واختبروا العدد على تصدير فعلي مُعرَض لا على القالب، لأن الاختبار على مستوى القالب يقلل من العدد الحقيقي.

قائمة فحص ما قبل الإطلاق لدفعة من إعلانات HTML5 المولّدة من الخلاصة

• كل إشارة إلى أصل في الشيفرة نسبية إلى جذر ZIP، وليست عنوانًا مطلقًا يعود إلى CDN الخاص بالخلاصة.
• يُفحص عدد الملفات على ملف ZIP المجمَّع الخاص بالمنتج، لا على القالب، ويكون أقل من حد المنصة المستهدفة.
• وسم ad.size الوصفي (أو ما يعادله في DV360/Ad Manager) موجود وغير مقلَّص بعد خطوة البناء، لا قبلها فقط.
• متغير clickTag مُعلن مرة واحدة، دون تقليص، وهو وجهة النقر الوحيدة في الملف.
• يُختبر العدد الإجمالي لملفات تعريف الارتباط واستدعاءات HTTP الخارجية على الإعلان المُعرَض، مقابل حد DV360 البالغ 25/100، لا بالتقدير لكل وسم.
• يُقاس وزن التنزيل الإجمالي من بداية باردة وبعد الضغط، مقابل الحد الفعلي للمنصة: 600 KB لإعلانات العرض القياسية في Google Ads، و5 MB إجمالًا لـ DV360.

ما لا يغطيه هذا الدليل

هذه طبقة امتثال تقني، لا استراتيجية إبداعية كاملة. وهي لا تغطي إعلانات الكتالوج الديناميكية على وسائل التواصل الاجتماعي والإعلانات الأصيلة (native) — مواضع Meta وInstagram وإعلانات كتالوج TikTok — المبنية من الخلاصة نفسها، لأنها تعمل بأصول الصور والفيديو عبر مدير إعلانات الكتالوج الخاص بالمنصة، لا عبر رفع ZIP بصيغة HTML5. ولهذه المهمة تحديدًا، تُعد الأدوات المصممة لهذا الغرض أنسب فعلًا من مسار HTML5 عام: فـ Confect مبنية خصيصًا حول قوالب إعلانات الكتالوج في Meta وGoogle مع مزامنة المنتجات كل ساعة، وHunch مبنية حول الإعلانات الديناميكية للتواصل الاجتماعي والفيديو، بما في ذلك النسخ المخصصة محليًا بدقة عالية. ولا تنتج أي منهما لافتات عرض HTML5 وفق مواصفات IAB، وهذه هي الفجوة التي يعالجها هذا الدليل، لكنهما تستحقان التقييم وفق معاييرهما الخاصة في مجال عملهما.

كما لا يغطي هذا الدليل اختبار الإعلانات أو قياس الأداء — فمعرفة ما إذا كان قالب ما يحقق تحويلات أكثر من آخر تخصص مستقل عن اجتياز المراجعة التقنية — ولا يحل محل مراجعة سياسة المحتوى لدى المنصة. إصلاح كل بند في قائمة الفحص أعلاه يمنع الرفض التقني، لكنه لا يُجيز إعلانًا ينتهك سياسة الإعلانات في المنصة لأسباب جوهرية.

الأسئلة الشائعة

ما الحد الأقصى لحجم ملف إعلان العرض HTML5 في Google Ads؟

بالنسبة لإعلانات العرض المرفوعة القياسية، يجب ألا يتجاوز ملف ZIP حجم 600 KB وألا يحتوي على أكثر من 40 ملفًا. أما أصول HTML5 البينية في حملات التطبيقات فتتبع مواصفات منفصلة: حتى 5.2 MB و512 ملفًا، ولكن بالمقاسين 320×480 أو 480×320 فقط.

لماذا يقيس DV360 وزن التنزيل الإجمالي بدل حجم ZIP؟

لأن ملف ZIP قد يتفكك إلى مجموعة ملفات أكبر بكثير عندما يعرضه المتصفح. يحدد DV360 الوزن الفعلي الذي يحمّله متصفح الزائر عند عرض الإعلان بـ 5 MB، وهو مؤشر أدق للأثر الفعلي على زمن التحميل من حجم الأرشيف المضغوط.

هل يمكن لإعلان HTML5 مولّد من الخلاصة أن يشير إلى خطوط أو صور خارجية؟

عمومًا لا. تسمح إعلانات العرض القياسية في Google Ads بالإشارات الخارجية إلى Google Fonts وقائمة قصيرة من المكتبات المستضافة لدى Google (CreateJS وGSAP وjQuery) فقط؛ وكل ما عدا ذلك، بما في ذلك كل صور المنتجات، يجب تضمينه في ZIP بمسار نسبي.

لماذا يجتاز إعلان HTML5 الاختبار المحلي ويفشل في مراجعة المنصة؟

يجري الاختبار المحلي عادةً على المصدر قبل التقليص وقبل الضغط، لا على ملف ZIP الفعلي الذي يُرفع. وقد يحذف التقليص وسم ad.size أو يشوّه متغير clickTag بعد أن اجتاز الاختبار المحلي، لذا يجب تنفيذ الفحوص على ناتج البناء النهائي.

هل ينطبق حد الـ 40 ملفًا على كل منتج أم على كل حملة؟

على كل ملف ZIP للإعلان منفردًا. فالتصدير الدفعي الذي يولّد ملف ZIP لكل SKU يحتاج إلى أن يكون كل ملف منها، على حدة، تحت الحد — فالحد لا يُحتسب كمتوسط على إجمالي عدد ملفات الحملة.

ما الفرق بين مواصفات HTML5 لحملات التطبيقات ومواصفات HTML5 لإعلانات العرض القياسية؟

هما مواصفتان منفصلتان بحدود مختلفة، وتستهدفان مخزونًا إعلانيًا مختلفًا. فإعلانات العرض المرفوعة القياسية محدودة بـ 600 KB و40 ملفًا مع أبعاد مرنة؛ بينما تسمح إعلانات HTML5 البينية لحملات التطبيقات بما يصل إلى 5.2 MB و512 ملفًا، لكن بمقاسين ثابتين فقط (عمودي/أفقي). وتطبيق افتراضات مواصفة على سطح إعلاني تحكمه الأخرى مصدر شائع لرفض الحزم.

هل تنطبق قواعد الملفات وclickTag هذه على إعلانات الفيديو المولّدة من الخلاصة نفسها؟

لا — فأصول الفيديو تتبع مواصفات إعلانات الفيديو الخاصة بكل منصة (الترميز والمدة ونسبة العرض إلى الارتفاع)، لا قواعد ZIP لـ HTML5 الواردة في هذا الدليل. ويحتاج المسار المعتمد على الخلاصة الذي ينتج مخرجات فيديو وHTML5 معًا إلى جولة فحص جودة منفصلة لكل منهما.

كيف أختبر عدد ملفات تعريف الارتباط واستدعاءات HTTP قبل الرفع إلى DV360؟

اعرضوا الإعلان المجمّع في متصفح مع فتح أدوات المطورين، وحمّلوه في علامة تبويب معزولة، ثم عدّوا ملفات تعريف الارتباط المضبوطة والطلبات المُرسلة فعليًا من لوحة الشبكة. أما اختبار القالب بمعزل عن ذلك، قبل حقن وسوم التتبع أثناء البناء، فسيقلل من عدّ كليهما.

إذا لم تكن صيانة طبقة الامتثال هذه يدويًا استخدامًا جيدًا لوقت فريقكم، فاطلعوا على كيف يولّد Creative Suite من Feedance إعلانات جاهزة للقنوات مباشرة من خلاصة منتجاتكم — صور ثابتة وفيديو ولافتات HTML5 — إلى جانب إثراء الخلاصة لبيانات المنتجات الأساسية. وقد استخدمت Karaca نهج «من الخلاصة إلى الإعلان» نفسه لإنتاج 10,000 إعلان بهوية العلامة لموسم الجمعة البيضاء في ساعتين. تواصلوا معنا لمناقشة كتالوجكم ومعدل الرفض الحالي لديكم.