لشبونةنحن في Web Summit، الجناح A1-33.عرض التفاصيل
Feedance
مقال

منع Google من تجاوز بيانات السعر والتوافر في خلاصة منتجاتكم بصمت

قد تعيد Google كتابة السعر والتوافر وحالة المنتج في خلاصتكم بصمت عبر التحديثات التلقائية للعناصر. تعرّفوا على كيفية التدقيق والتحكم فيها.

Kardelen YılmazKardelen Yılmaz
قراءة في 9 دقيقة
Abstract illustration of two data streams representing feed and channel price data converging

يمكن لـ Google Merchant Center إعادة كتابة أربعة حقول في خلاصة المنتجات التي ترسلونها دون الرجوع إليكم: السعر، وسعر التخفيض، والتوافر، وحالة المنتج. ويسحب القيم البديلة مباشرةً من ترميز البيانات المنظمة في صفحات منتجاتكم، ويفعل ذلك افتراضيًا في كل حساب Merchant Center جديد (support.google.com/merchants/answer/15623993). وإذا كانت صفحة المنتج بطيئة التحديث، أو مخزّنة مؤقتًا عبر CDN، أو خاطئة ببساطة، فستظل Google تثق بها أكثر من خلاصتكم. هذا الدليل موجّه لكل من يدير حملات Shopping المدفوعة أو القوائم المجانية ولاحظ أن السعر أو حالة المخزون أو حالة المنتج في Google لا تطابق ما أرسله، ويشرح كيف تعرفون أي قوائمكم تتأثر بذلك، وكيف تثبّتون الحقول المهمة.

ما الذي تغيّره «التحديثات التلقائية للعناصر» فعلًا

تسمي Google هذه الميزة التحديثات التلقائية للعناصر (automatic item updates)، وهي اعتبارًا من سبتمبر 2025 موجودة في Merchant Center ضمن Products & store > Products > Automations، حيث يحصل كل إجراء آلي على مفتاح تشغيل/إيقاف خاص به وتقدير مبسّط لأثره (support.google.com/merchants/answer/15623993). وهناك ثلاثة تحديثات فرعية مفعّلة افتراضيًا لكل حساب: تحديثات السعر، وتحديثات التوافر، وتحديثات حالة المنتج. أما التحديثان الآخران فاختياريان ويجب تشغيلهما عمدًا: تحديثات الشحن وتحسينات الصور (support.google.com/merchants/answer/3246284).

شرح Google لآلية العمل مباشر: «نقرأ تلقائيًا ترميز البيانات المنظمة في متجركم الإلكتروني باستخدام أدوات استخراج البيانات المتقدمة لدينا، ونسحب بيانات المنتج مباشرةً من HTML الخاص بكم إلى Merchant Center». والمثال التطبيقي الذي تقدمه Google في مركز المساعدة يستحق التكرار حرفيًا، لأنه يوضح مدى صغر الفارق الذي يكفي لإطلاق إعادة الكتابة: إذا كان آخر تحميل للخلاصة يسعّر منتجًا بـ 4 GBP، بينما تعرضه صفحة المنتج الحية بـ 3 GBP، فإن Google تحدّث الإعلان الحي أو القائمة المجانية إلى 3 GBP، لا إلى 4 GBP التي أرسلتموها.

يعتمد التوافر مطابقةً أكثر مرونة من السعر. تنص وثائق Google على أن «in_stock وpreorder وbackorder تُعدّ جميعها متوافقة مع in_stock» لأغراض هذا الإجراء الآلي، لذلك فإن صفحة تعرض «backorder» لفترة وجيزة لن تؤدي بالضرورة إلى تصحيح، لكن صفحة تعرض «out of stock» مقابل خلاصة تقول «in stock» ستؤدي إليه.

لماذا توجد هذه الميزة، ولماذا ليست سيئة بالضرورة

الغرض المعلن هو منع حالات الرفض الناتجة عن بيانات خلاصة قديمة: «إذا تعذّر على أدوات الاستخراج تحديد معلومات السعر أو التوافر أو حالة المنتج، فستتعرض منتجاتكم للرفض على مستوى المنتج» (support.google.com/merchants/answer/3246284). بعبارة أخرى، بنت Google هذه الميزة كشبكة أمان للتجار الذين تتأخر خلاصاتهم عن متاجرهم. وبالنسبة لمتجر يمتلك ترميز schema.org Product موثوقًا وخلاصة نادرة التحديث، فإنها تقلّل حالات الرفض فعلًا.

المشكلة في الافتراض المضمّن فيها: أن الصفحة الحية دائمًا أحدث وأدق من الخلاصة. وهذا الافتراض ينهار في عدة حالات نراها كثيرًا في تدقيقات الخلاصات:

  • يستخدم المتجر CDN أو تخزينًا مؤقتًا للصفحة الكاملة يتأخر من 15 إلى 60 دقيقة عن تغيير السعر، فتلتقط عملية الزحف من Google السعر القديم.
  • أُعدّت البيانات المنظمة في الموقع مرة واحدة قبل سنوات ولم تُحدَّث عند إطلاق محرك تسعير جديد أو وحدة عروض ترويجية، فهي تعرض سعر التخفيض الخاص بالشهر الماضي.
  • يقدّم متجر مخصص لمنطقة أو عملة بيانات منظمة تختلف عن تلك التي تزحف إليها Google لذلك السوق.
  • تكون الخلاصة متحفظة عمدًا أكثر من الموقع، كأن تُبقي منتجًا «in stock» خلال فترة احتياطية محددة ريثما تُسوّى أعداد المستودع.

في كل حالة من هذه الحالات، تجعل التحديثات التلقائية للعناصر Google تعرض رقمًا خاطئًا في الإعلان، وتفعل ذلك بصمت. لا يصلكم أي بريد إلكتروني. والأثر الوحيد هو بند في تشخيصات Merchant Center، تحت مشكلة تحمل بالضبط إحدى التسميات «Automatic updates: Mismatched price» أو «Automatic updates: Mismatched availability» أو «Automatic updates: Mismatched condition». وهذا نمط إخفاق مختلف عن حالات تعليق الحساب التي تناولناها في دليلنا للتعافي من تعليق التضليل (misrepresentation): لا شيء هنا يؤدي إلى تعليق حسابكم، لكنه يعني أن الإعلان الذي ينقر عليه عميلكم قد لا يعكس العرض الذي قصدتم تقديمه.

مثال عملي

الخلاصة المرسلة: price: 1299.00 TRY، availability: in stock
صفحة المنتج الحية (خلف تخزين مؤقت عبر CDN لمدة 40 دقيقة بعد تخفيض سعر في عرض خاطف): تعرض البيانات المنظمة 1199.00 TRY
يقرأ زاحف Google الصفحة المخزّنة مؤقتًا، ويضع علامة «Automatic updates: Mismatched price»، ويعيد نشر القائمة بسعر 1199.00 TRY — وهو سعر لم يرسله التاجر قط ولم تسمح به شروط العرض لتلك القناة.

كانت الخلاصة صحيحة. أما تصحيح Google فكان هو الخطأ، وبدا في تبويب التشخيصات مطابقًا تمامًا لحالة كانت فيها الخلاصة قديمة فعلًا.

قائمة تشخيص: هل يحدث هذا لكم؟

  1. افتحوا Products & store > Products > Diagnostics وصفّوا النتائج للمشكلات التي تحتوي على «Automatic updates». تعرض كل مشكلة عدد العناصر المتأثرة وعيّنة من معرّفات العروض المتأثرة.
  2. افتحوا Products & store > Products > Automations وتحققوا مما إذا كانت تحديثات السعر والتوافر وحالة المنتج مفعّلة (وهي كذلك افتراضيًا ما لم يكن أحدهم قد أوقفها).
  3. اختاروا ثلاثة معرّفات عروض مُعلَّم عليها وقارنوا ثلاث قيم جنبًا إلى جنب: القيمة المرسلة في خلاصتكم، والقيمة الحية حاليًا في إعلان Shopping أو القائمة المجانية، والقيمة في بيانات schema.org/Product أو Product المنظمة في متجركم (اعرضوا مصدر الصفحة، أو استخدموا Rich Results Test من Google) وقت الفحص.
  4. إذا كان الإعلان الحي يطابق البيانات المنظمة ولا يطابق خلاصتكم، وكانت البيانات المنظمة خاطئة، فالسبب الجذري في موقعكم لا في خلاصتكم. إصلاح البيانات المنظمة (أو تأخر تخزينها المؤقت) يصلح الإعلان دون المساس بأي إعداد في Merchant Center.
  5. إذا انتقلتم من Content API for Shopping إلى Merchant API هذا العام، فأعيدوا فحص كل مفاتيح التحسينات التلقائية. بلغت Content API for Shopping نهاية عمرها في 18 أغسطس 2026، مع بدء أخطاء طلبات تدريجية في 1 سبتمبر 2026 لكل من لا يزال يستدعيها (developers.google.com/merchant/api/latest-updates، الصفحة محدّثة حتى 24 سبتمبر 2026). تقع التحديثات التلقائية للعناصر الآن ضمن مورد مخصص باسم automaticImprovements في Merchant API، والانتقال المتسرّع طريقة شائعة لإعادة هذه المفاتيح بصمت إلى قيمها الافتراضية.

إيقافها كليًا أو حقلًا بحقل

في واجهة Merchant Center، انتقلوا إلى Products & store > Products > Automations، وافتحوا الإجراء الآلي الذي تريدون تغييره، وانقروا View details، واستخدموا المفتاح لتشغيل ذلك التحديث المحدد أو إيقافه. ويعمل ذلك مع تحديثات السعر والتوافر وحالة المنتج والشحن. أما تحسينات الصور وتحسينات الشحن فيمكن إدارتها بهذه الطريقة في الواجهة أيضًا، لكن اثنين من عناصر التحكم متاحان عبر API فقط.

ومن يتصل عبر Merchant API يتحكم في السلوك نفسه بحقول منطقية (boolean) صريحة في مورد automaticImprovements الخاص بالحساب (developers.google.com/merchant/api/guides/automatic-improvements/overview):

التحديث الفرعيالوضع الافتراضيمفتاح واجهة Merchant Centerحقل Merchant API
تحديثات السعرمفعّلنعمallowPriceUpdates
تحديثات التوافرمفعّلنعمallowAvailabilityUpdates
تحديثات التوافر الصارمةمتوقفلاallowStrictAvailabilityUpdates
تحديثات حالة المنتجمفعّلنعمallowConditionUpdates
تحسينات الصور التلقائيةمتوقفنعمallowAutomaticImageImprovements
تحسينات الشحن التلقائيةمتوقفلاallowShippingImprovements

توضح وثائق Merchant API صراحةً أن تحديث هذا المورد هو استبدال كامل للمكوّن بأكمله، وليس تعديلًا جزئيًا: أرسلوا الحقول الستة كلها مع كل تحديث، لا الحقل الذي أردتم تغييره فقط، وإلا فإنكم تخاطرون بإعادة الحقول الأخرى إلى قيمها الافتراضية (developers.google.com/merchant/api/guides/automatic-improvements/overview).

تحديد ما ينبغي إيقافه فعلًا

إيقاف كل شيء ليس بالضرورة القرار الصحيح، فهو يزيل شبكة الأمان ضد حالات الرفض التي بُنيت الميزة لمنعها. والأنسب هو النظر لكل سمة على حدة:

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

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

هذا الدليل خاص بـ Google Merchant Center. فلدى Meta Commerce Manager وTikTok Shop سلوكهما الخاص في مطابقة الكتالوج، ولا شيء منه موثّق في المكان نفسه أو محكوم بالمفاتيح نفسها؛ تعاملوا مع كل قناة كتدقيق قائم بذاته. كما لا يغطي آلية «autofeeds» المنفصلة من Google، حيث تبني Google خلاصة كاملة من الزحف إلى موقعكم دون أي إرسال على الإطلاق — وهي ميزة مختلفة لمشكلة مختلفة (غياب الخلاصة تمامًا، لا تجاوزًا جزئيًا لخلاصة قائمة) وتستحق تدقيقًا خاصًا بها.

وإذا كان السبب الجذري بيانات منظمة معطوبة أو مفقودة في موقعكم، لا إعدادًا صارمًا من Google، فلا مفتاح في Merchant Center يعالج ذلك؛ يجب إصلاح الترميز نفسه، وRich Results Test من Google هو أسرع وسيلة لرؤية ما يقرؤه زاحفها فعليًا. وتوفر أدوات مراقبة الخلاصات مثل Channable وDataFeedWatch عرض تشخيص مشابهًا لعدم التطابق قناةً بقناة؛ والفارق الحقيقي هو ما إذا كانت حلقة الإصلاح، من رصد عدم التطابق إلى التصحيح وإعادة نشر الخلاصة، تتم في المكان نفسه الذي تديرون فيه الخلاصة، وهذا تفضيل في سير العمل أكثر منه قيدًا تقنيًا في أي أداة بعينها. أما أخطاء GTIN والمعرّفات فهي فئة مرتبطة لكنها منفصلة من حالات الرفض، نتناولها في دليلنا لأخطاء GTIN.

أين تأتي Feedance

تتعامل Feedance مع خلاصتكم المُثرَاة بوصفها المصدر الوحيد للحقيقة الذي يُدفع إلى كل قناة من قنواتها المتصلة التي تتجاوز 200 قناة عبر تكامل Google Merchant Center، وبذلك يظهر تجاوز Google كعدم تطابق مرئي مع ذلك المصدر بدلًا من أن يختفي في تبويب في Merchant Center لا يفحصه أحد يوميًا. أما مراقبة الخلاصة فهي ما يكشف الانحراف أصلًا؛ وقرارات المفاتيح الواردة أعلاه تبقى لكم في واجهة Google نفسها. وتختلف وتيرة تحديث الخلاصة بحسب الخطة (تزامن Essentials يوميًا؛ وتزامن Business كل ساعة)، وهذا مهم هنا لأن خلاصة لا تتحدث إلا مرة واحدة يوميًا تمنح التحديثات التلقائية للعناصر يومًا كاملًا من الفجوة لتملأه ببيانات مأخوذة من زحف الصفحات قبل أن يصحّحها إرسالكم التالي.

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

ما هي التحديثات التلقائية للعناصر في Google Merchant Center؟

هي ميزة من Google، مفعّلة افتراضيًا، تقرأ البيانات المنظمة من صفحات منتجاتكم وتستخدمها لاستبدال بيانات السعر والتوافر وحالة المنتج، و(اختياريًا) بيانات الشحن والصور، التي أرسلتموها في خلاصتكم، كلما وجد زاحف Google عدم تطابق.

ما السمات التي يمكن لـ Google تغييرها دون أن ترسل خلاصتي قيمة جديدة؟

السعر وسعر التخفيض والتوافر وحالة المنتج افتراضيًا. أما تقديرات سرعة الشحن وتحسينات الصور فهي إجراءات آلية فرعية منفصلة، متوقفة افتراضيًا ويجب تفعيلها عمدًا.

هل سيؤدي تشغيل هذه الميزة إلى إصلاح جميع حالات الرفض في Merchant Center؟

لا. فهي تعالج فقط حالات الرفض الناتجة عن عدم التطابق بين خلاصتكم وصفحتكم الحية في السمات الأربع المشمولة. أما أخطاء GTIN ومخالفات السياسات ومشكلات التضليل (misrepresentation) فلا علاقة لها بها وتحتاج إلى إصلاحاتها الخاصة.

هل يمكنني إيقاف التحديثات التلقائية للعناصر كليًا؟

نعم، لكل سمة على حدة، إما في Merchant Center ضمن Products & store > Products > Automations، أو عبر الحقول المنطقية الأربعة المتعلقة بالتحديثات في مورد automaticImprovements في Merchant API إذا كنتم تديرون حسابكم عبر API.

هل يؤثر هذا أيضًا على كتالوج Meta أو TikTok Shop؟

لا. هذه الآلية تخص Google وحدها. فلدى Meta Commerce Manager وTikTok Shop سلوكهما الخاص الموثّق بشكل منفصل لمطابقة الكتالوج، وهو ما لا تغطيه هذه المقالة.

انتقلتُ من Content API for Shopping إلى Merchant API هذا العام. هل ينبغي أن أعيد فحص أي شيء؟

نعم. تقع التحديثات التلقائية للعناصر الآن ضمن مورد مخصص باسم automaticImprovements في Merchant API، وبما أن تحديثات هذا المورد تستبدل مجموعة الحقول كلها دفعة واحدة، فإن سكربت انتقال متسرّعًا عدّل حقلًا واحدًا فقط قد يعيد الحقول الأخرى بصمت إلى قيمها الافتراضية.

كيف أعرف ما إذا كانت Google قد غيّرت قائمتي بالفعل؟

افحصوا Products & store > Products > Diagnostics بحثًا عن المشكلات المسمّاة «Automatic updates: Mismatched price» أو «Mismatched availability» أو «Mismatched condition». يعرض كل بند عيّنة من معرّفات العروض المتأثرة لتتمكنوا من مقارنة قيمة الخلاصة بالقيمة الحية مباشرةً.

هل ينبغي على كل تاجر إبقاء هذه الميزة متوقفة؟

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

هل تدير Feedance هذا الإعداد نيابةً عني؟

تدير Feedance خلاصتكم المُثرَاة بوصفها المصدر الذي يُدفع إلى Google وأكثر من 200 قناة أخرى؛ أما مفتاح التحديثات التلقائية للعناصر نفسه فهو إعداد في حساب Google Merchant Center تتحكمون به مباشرةً في واجهة Google أو API الخاص بها، وليس شيئًا يمكن لمنصة خلاصات تشغيله نيابةً عنكم.

ما الفرق بين التحديثات التلقائية للعناصر وautofeeds؟

تصحح التحديثات التلقائية للعناصر سمات محددة في خلاصة أرسلتموها بالفعل. أما Autofeeds فهي آلية منفصلة من Google تبني خلاصة من الصفر عبر الزحف إلى موقعكم حين لا تكون قد أرسلتم أي خلاصة على الإطلاق. وهما تحلّان مشكلتين مختلفتين وتُضبطان بشكل منفصل.

أجروا تدقيقًا مجانيًا لخلاصة المنتجات لمعرفة أين انحرفت القيم التي أرسلتموها عن بيانات قنواتكم الحية.

هل تريد رأيًا آخر في خلاصتك؟ سنراجعها معك ونوضح أين توجد الثغرات قبل الإرسال التالي.
احصل على تدقيق مجاني
Kardelen Yılmaz
بقلم
Kardelen Yılmaz

تعمل Kardelen Yılmaz في مجال النمو لدى Feedance، حيث تساعد العلامات التجارية في التجارة الإلكترونية والوكالات على تحقيق عائد أكبر من كل منتج تعلن عنه. وتكتب عن جودة خلاصة المنتجات، وحملات Shopping وPerformance Max، وأتمتة المحتوى الإبداعي، وكيف يغيّر التسوق المدعوم بالذكاء الاصطناعي ظهور المنتجات.

LinkedIn

اكتشف أي
المنتجات تحقق الأرباح.

اربط خلاصتك وGA4. نعرض Product Score و4T وPrice War وBroken Size على كتالوجك أنت.