تكلفة الشحن مطلوبة لإعلانات Shopping والإدراجات المجانية في 30 دولة، وأكثر طريقة آمنة لتوفيرها هي الإعداد على مستوى الحساب في Merchant Center. وعاجلاً أم آجلاً يحتاج أي كتالوج إلى استثناءات: منتجات ثقيلة، أو رسوم إضافية لمنطقة معينة، أو منتج أرخص يقع دون الحد الأدنى للطلب. وبمجرد وضع price واحد داخل السمة [shipping] على مستوى المنتج، تتوقف Google عن قراءة أوقات التسليم والحد الأدنى لقيمة الطلب اللذين ضبطتموهما لذلك الموقع. وقد يبقى المنتج معتمداً بينما لا يعود تقدير التسليم الخاص به مستمداً من الإعدادات التي ضبطتموها.
هذا الدليل موجّه إلى مديري الخلاصات الذين لديهم إعدادات شحن تعمل بالفعل ويحتاجون إلى إضافة استثناءات على مستوى المنتج دون الإخلال بها. وبنهايته ستعرفون الإعدادات التي يستبدلها التجاوز، والسمات الفرعية التي يجب إعادة ذكرها، وكيفية إطلاق التغيير بطريقة لا تؤدي إلى ظهور تحذير شحن غير دقيق على مستوى الكتالوج بأكمله.
ما الذي يستبدله تجاوز الشحن على مستوى المنتج فعلياً
يقرأ Merchant Center بيانات الشحن من مكانين: سياسات الشحن على مستوى الحساب، والسمة [shipping] الموجودة في كل منتج. وتوجيه Google نفسها هو أن تستخدموا إعدادات مستوى الحساب أولاً وأن تعاملوا السمة كحل أخير. والسبب هو الأسبقية. فكما تنص وثائق السمة، فإن إرسال price داخل [shipping] يجعل إعدادات الخدمة على مستوى الحساب لذلك الموقع، بما فيها أوقات التسليم والحد الأدنى لقيمة الطلب، مُتجاهَلة. وعندئذٍ يجب عليكم تحديدها على مستوى المنتج.
وينتج عن ذلك قاعدتان. الأولى: التجاوز ليس تعديلاً إضافياً فوق إعداد الحساب، بل هو يستبدله للموقع المطابق. والثانية: يمكن تكرار السمة حتى 100 مرة لكل منتج، لذلك يحتاج كل بلد ومنطقة وخدمة تشحنون إليها ذلك المنتج إلى صف كامل خاص به.
تغيير أبريل 2026 الذي يجعل الأمر أسهل
أضاف تحديث مواصفات بيانات المنتجات لعام 2026، السارٍ اعتباراً من 14 أبريل 2026، مكافئات على مستوى المنتج لخيارات مستوى الحساب: وقت الإغلاق لمعالجة الطلبات، والحد الأدنى لقيمة الطلب، وتسميات الولاء (loyalty_program_label وloyalty_tier_label) كسمات فرعية للسمة [shipping]. كما أضاف إعلان منفصل بتاريخ 28 أبريل السمة [pickup_cost]. واعتباراً من 30 سبتمبر 2026، في المملكة المتحدة وسويسرا والمنطقة الاقتصادية الأوروبية، يجب على منتجات in_store المفعّلة للاستلام أن تقدّم تكاليف الاستلام والحد الأدنى لقيمة الطلب إذا كان موقعكم الإلكتروني يطبّقها.
الخطوة 1: قرروا أولاً ما إذا كنتم بحاجة إلى تجاوز أصلاً
ابدؤوا بالإجابة الافتراضية، وهي: لا. أبقوا المنتج على شحن مستوى الحساب إذا تحقق أي مما يلي:
- يغطي سعر ثابت واحد أو قاعدة حد أدنى واحدة الكتالوج بأكمله.
- يمكن التعبير عن الاستثناء كمنطقة أو كتسمية شحن في إعدادات Merchant Center.
- الفارق الوحيد هو وقت التسليم، ويمكن ضبطه لكل منتج عبر السمتين المستقلتين
[min_handling_time]و[max_handling_time]دون المساس بالسعر.
لا تلجؤوا إلى التجاوز على مستوى المنتج إلا حين يختلف السعر نفسه من منتج إلى آخر، مثل البضائع الضخمة، أو الأثاث كبير الحجم، أو منتج بسعر شحن ثابت داخل متجر يقدّم شحناً مجانياً.
الخطوة 2: احصروا ما توفّره إعدادات حسابكم حالياً
قبل كتابة أي صف، دوّنوا ما توفّره سياسة مستوى الحساب للمواقع التي ستتجاوزونها. فهذه هي القيم التي سيتعيّن عليكم إعادة ذكرها.
| إعداد مستوى الحساب | يُفقد عندما يحدد صف المنتج price؟ | البديل على مستوى المنتج |
|---|---|---|
| وقت المعالجة (الحد الأدنى/الأقصى بالأيام) | نعم | السمتان الفرعيتان min_handling_time وmax_handling_time، أو السمات المستقلة |
| وقت النقل (الحد الأدنى/الأقصى بالأيام) | نعم | min_transit_time، max_transit_time |
| وقت إغلاق استلام الطلبات | نعم | handling_cutoff_time (HHMM)، handling_cutoff_timezone (IANA) |
| الحد الأدنى لقيمة الطلب | نعم | السمة المستقلة minimum_order_value |
| أسعار أعضاء برامج الولاء | نعم | loyalty_program_label، إضافةً إلى loyalty_tier_label في البرامج متعددة المستويات |
إذا كان تقدير التسليم يظهر للمتسوقين اليوم وتخطّيتم هذا الحصر، فإن التقدير هو ما ستخسرونه. وتوضح وثائق Google أن سرعة الشحن تتطلب ثلاثة عناصر معاً: أقصى وقت للمعالجة، وأقصى وقت للنقل، وسعراً.
الخطوة 3: اكتبوا صفوفاً كاملة لا جزئية
إليكم مثالاً توضيحياً قبل التعديل وبعده لمتجر ألماني. تتضمن سياسة الحساب خدمة Standard بمدة معالجة من يوم إلى يومين ومدة نقل من 3 إلى 5 أيام. هذا مثال أعددناه لتوضيح آلية العمل، وليس بيانات عميل.
قبل. يتجاوز التاجر سعر منتج ضخم فقط:
| id | price | shipping(country:service:price) |
|---|---|---|
| SOFA-204 | 1249.00 EUR | DE:Standard:29.90 EUR |
هذا الصف صالح. وهو أيضاً الصف الذي يسبب المشكلة، لأن أوقات التسليم في سياسة الحساب لم تعد تنطبق على هذا المنتج في ألمانيا.
بعد. يعيد التجاوز نفسه ذكر حقول السرعة:
| id | price | shipping(country:service:price:min_handling_time:max_handling_time:min_transit_time:max_transit_time) |
|---|---|---|
| SOFA-204 | 1249.00 EUR | DE:Standard:29.90 EUR:1:2:3:5 |
لننظر الآن في ملحق رخيص بسعر شحن خاص به ضمن متجر يشترط حداً أدنى للطلب قدره 20 EUR. ولأن سعر المنتج يساوي الحد الأدنى لقيمة الطلب أو يقل عنه، ولأن الصف يتجاوز الشحن، فيجب إعادة ذكر الحد الأدنى أيضاً:
| id | price | shipping(same header as above) | minimum_order_value(country:price) |
|---|---|---|---|
| CAB-017 | 12.90 EUR | DE:Standard:3.90 EUR:1:2:3:5 | DE:20 EUR |
تنص مواصفات الحد الأدنى لقيمة الطلب لدى Google على ضبطه فقط عندما يكون سعر المنتج مساوياً للحد الأدنى أو أقل منه، وعلى أن تطابق العملة عملة price الخاص بالمنتج، وأن تطابق القيمة المرسلة ما يعرضه موقعكم. أما الأريكة بسعر 1249.00 EUR فلا تحتاج إلى minimum_order_value.
الخطوة 4: تعاملوا مع وقت الإغلاق والمناطق الزمنية بعناية
من السهل الوقوع في الخطأ في وقت الإغلاق لأن له صيغتين متداولتين. فصفحة السمات الحالية لدى Google تحدد handling_cutoff_time كسلسلة من أربعة أرقام بصيغة HHMM مثل 1530، مع handling_cutoff_timezone بصيغة IANA مثل Europe/Berlin، وتكون القيمة الافتراضية هي المنطقة الزمنية للوجهة. وتعرض بعض المقالات الخارجية السابقة لتحديث أبريل فروقاً عن UTC مثل +02:00. اتبعوا صفحة Google وتحققوا على بضعة منتجات قبل الإطلاق الكامل.
عندما ينطبق وقت الإغلاق نفسه على عدة صفوف [shipping] لمنتج واحد، استخدموا السمة المستقلة handling_cutoff_time بدلاً من تكراره. وانتبهوا أيضاً إلى قاعدة الأسبقية: إذا أرسلتم أوقات المعالجة كسمات مستقلة وكسمات فرعية داخل [shipping] معاً، فلن تُعتمد سوى السمات الفرعية. وإذا تُرك وقت الإغلاق فارغاً، فإن وثائق وقت التسليم لدى Google تذكر أن القيمة الافتراضية هي 8:00 صباحاً بتوقيت PST، وهو توقيت غير مناسب لمعظم المتاجر الأوروبية أو متاجر منطقة MENA.
الخطوة 5: تحققوا من صيغ العملات وحدود الأسعار
لكل عملة حد أقصى للسمة الفرعية price. وهذه الأرقام مهمة في المنطقة التي تتعامل معها Feedance أكثر من غيرها، لأن الليرة التركية والدرهم الإماراتي والريال السعودي تتشارك حداً أعلى من اليورو أو الدولار:
| العملة | نطاق سعر الشحن المقبول |
|---|---|
| EUR, GBP, USD, CHF | من 0 إلى 1000 |
| TRY, AED, SAR, PLN | من 0 إلى 5000 |
| INR, JPY, RUB | من 0 إلى 100000 |
استخدموا النقطة كفاصل عشري ولا تستخدموا فاصلة للآلاف، فاكتبوا 29.90 EUR وليس 29,90 EUR أبداً. الفاصلة العشرية معيار شائع في كثير من الملفات المصدّرة التركية والأوروبية، لذا تحققوا من الصيغة قبل إرسال العمود إلى Merchant Center. ولا تُدرجوا الرسوم التي تفرضها الجهات الحكومية ضمن تكلفة الشحن.
الخطوة 6: جرّبوا على شريحة واحدة ثم وسّعوا النطاق
أرسلوا الصفوف الجديدة لمجموعة منتجات واحدة، مثل فئة واحدة في بلد واحد، باستخدام مصدر تكميلي بحيث تبقى الخلاصة الرئيسية دون مساس. فالخلاصة التكميلية مصممة لهذا الغرض: فهي تضيف أعمدة إلى المنتجات دون استبدال البيانات الأساسية. انتظروا دورة المعالجة التالية، ثم افتحوا المنتج في Merchant Center وتأكدوا من أن تقدير التسليم ما زال يظهر. وعندها فقط عمّموا النمط على بقية الاستثناءات. ويساعد التحرير القائم على القواعد في أداة الخلاصة على إصلاح الفاصلة إلى نقطة وعلى بناء القيم المفصولة بنقطتين رأسيتين، إذا كان بإمكانه الكتابة في عمود تحددونه.
الخطوة 7: طابقوا مع صفحة الدفع واعرفوا رسالة الفشل
تقارن Google التكلفة في بياناتكم بما يراه المتسوقون عند الدفع. وإذا كانت البيانات أقل، فقد يظهر للحساب هذا التحذير:
Inaccurate shipping costs (due to inconsistent shipping costs between your feed and the checkout pages on your website)
تتمثل خطوات المعالجة لدى Google في مواءمة إعدادات خدمات الشحن أو السمة مع الموقع الإلكتروني، ثم إعادة الإرسال وطلب المراجعة. وتشير Google إلى أن المراجعة قد تستغرق من 24 إلى 48 ساعة بعد تطبيق الإصلاحات، وأنه إذا تعذّر تحديد الأسعار الدقيقة يمكنكم المبالغة في التقدير قليلاً. اجعلوا فحص خمسة منتجات متجاوَزة مقابل سلة تسوق فعلية جزءاً من كل إصدار.
ما لا يغطيه هذا الدليل
لم نتناول [carrier_shipping] الذي يتبع قواعد مشابهة، ولا الشحن للمخزون المحلي بما يتجاوز ملاحظة تكلفة الاستلام، ولا حدود الشحن المجاني التي تعتمد على قيمة السلة لا على المنتج. أما جداول الأسعار المعقدة، مثل شرائح الوزن لكل شركة نقل، فغالباً ما يكون الحفاظ عليها في Merchant Center نفسه أسهل من إدارتها كآلاف الصفوف في الخلاصة. كما لم نجرِ مقارنات معيارية لكيفية كتابة منصات الخلاصات الأخرى مثل Feedonomics وProductsup وChannable وDataFeedWatch للسمات الفرعية المهيكلة، لذلك لا ندّعي شيئاً بشأنها. تأكدوا من أن أداتكم قادرة على إخراج سمات فرعية مفصولة بنقطتين رأسيتين قبل اعتماد أي أسلوب. وقد جرى التحقق من أسماء السمات هنا مقابل صفحات مساعدة Google بتاريخ 18 أكتوبر 2026، وتعدّل Google هذه الصفحات بشكل متكرر.
الأسئلة الشائعة
هل تتجاوز السمة [shipping] إعدادات الشحن في Merchant Center؟
نعم. القيمة في السمة تتجاوز سعر الشحن على مستوى الحساب. كما أن ضبط price يجعل أوقات التسليم والحد الأدنى لقيمة الطلب على مستوى الحساب مُتجاهَلة لذلك الموقع.
كم صفاً للشحن يمكن أن يحتوي عليه المنتج الواحد؟
يمكن تكرار السمة حتى 100 مرة لكل منتج. ويحتاج كل بلد أو منطقة أو مزيج خدمة تشحنون إليه ذلك المنتج إلى صف خاص به.
هل أحتاج إلى minimum_order_value في كل منتج؟
لا. حدّدوه فقط عندما يكون سعر المنتج مساوياً للحد الأدنى لقيمة الطلب أو أقل منه. وإذا كان المنتج يتجاوز الشحن أيضاً، فيجب عليكم تقديم الحد الأدنى صراحةً حتى لو كانت إعدادات الحساب تحدد حداً أدنى.
ما الصيغة التي يستخدمها handling_cutoff_time؟
تحدد صفحة السمات لدى Google سلسلة من أربعة أرقام بصيغة HHMM، مثل 1530. وتقبل السمة الفرعية للمنطقة الزمنية المرتبطة بها اسماً بصيغة IANA، وتكون قيمتها الافتراضية المنطقة الزمنية للوجهة إذا حُذفت.
ماذا يحدث إذا استخدمتُ سمات وقت المعالجة المستقلة والسمات الفرعية للشحن معاً؟
تُستخدم السمات الفرعية داخل [shipping] فقط. أما السمتان المستقلتان [min_handling_time] و[max_handling_time] فهما بديل وليستا إضافة.
ما الحد الأقصى لسعر الشحن الذي يمكنني إرساله بالليرة التركية؟
النطاق الموثّق للعملة TRY هو من 0 إلى 5000، وهو نفسه لـ AED وSAR. استخدموا النقطة كفاصل عشري.
هل ينطبق شرط تكلفة الاستلام خارج أوروبا؟
بحسب إعلان Google، ينطبق شرط 30 سبتمبر 2026 على منتجات in_store المفعّلة للاستلام في المملكة المتحدة وسويسرا ودول المنطقة الاقتصادية الأوروبية.
كم تستغرق المراجعة بعد إصلاح تحذير الشحن غير الدقيق؟
تذكر Google أن المراجعة قد تستغرق من 24 إلى 48 ساعة بعد تطبيق الإصلاحات في بياناتكم وإعداداتكم. لا تطلبوا المراجعة قبل اكتمال معالجة إعادة الإرسال.
الخطوة التالية
إذا كانت التجاوزات لديكم جزءاً من عملية تنظيف أوسع لـ Merchant Center، فإن دليل إعداد خلاصة Google Merchant Center لدينا يغطي السمات المطلوبة وإصلاحات الأخطاء الشائعة، كما يشرح كيف توقفون Google عن تجاوز بيانات السعر والتوفر في خلاصتكم بصمت الطريقة الأخرى التي تغيّر بها Google بياناتكم دون إبلاغكم. ولمعرفة آلية إضافة الأعمدة دون المساس بالخلاصة الرئيسية، راجعوا الخلاصات التكميلية وFeed Rules.
مرّروا خلاصتكم عبر أداة تدقيق خلاصة المنتجات المجانية لمعرفة مواضع الفجوات في اكتمال البيانات وجودتها قبل إضافة تجاوزات الشحن.
تعمل Kardelen Yılmaz في مجال النمو لدى Feedance، حيث تساعد العلامات التجارية في التجارة الإلكترونية والوكالات على تحقيق عائد أكبر من كل منتج تعلن عنه. وتكتب عن جودة خلاصة المنتجات، وحملات Shopping وPerformance Max، وأتمتة المحتوى الإبداعي، وكيف يغيّر التسوق المدعوم بالذكاء الاصطناعي ظهور المنتجات.
LinkedIn
