لماذا تخطئ وكلاء التسوّق بالذكاء الاصطناعي في قراءة أسعارك؟

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

لماذا يعرض وكيل التسوّق بالذكاء الاصطناعي سعرًا خاطئًا

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

نرى أنماط الفشل الخمسة نفسها في كل تدقيق تقريبًا:

1. الإجماليات المحسوبة في جهة العميل. يُحقن السعر عبر JavaScript بعد تحميل الصفحة الأولي، فيعود طلب الوكيل بنص بديل أو بفراغ أو بـ "$0.00".
2. ترميز تخفيض غامض. يظهر السعر الأصلي المشطوب بجوار سعر التخفيض دون أي تسمية تميّز بينهما، فلا يستطيع الوكيل تحديد الرقم الصحيح.
3. schema ناقص أو غائب. غياب Offer.price، أو وجود سعر بلا priceCurrency، يدفع الوكيل إلى التخمين من النص الظاهر.

أما الاثنان الآخران فمشكلتا تنسيق تبدوان سليمتين للإنسان لكنهما تعنيان شيئًا مختلفًا للسكربت:

4. أسعار الباقات والشرائح. يجتمع سعر الوحدة وسعر العبوة وسعر الاشتراك في DOM معًا، فيلتقط الوكيل أول رقم يصادفه بدلًا من الرقم المطابق للمنتج المطلوب.
5. تعارض رموز العملات. استخدام علامة $ مجرّدة للدولار الأمريكي والكندي معًا، أو £ للجنيه الإسترليني وقوائم الجنيه المصري القديمة، دون رمز ISO يزيل الالتباس.

تعارض العملات يستحق نظرة أقرب، لأنه نمط الفشل الذي يلاحظه أصحاب المتاجر في آخر المطاف. فالمتجر الذي يبيع بالدولار الأمريكي والكندي ويستخدم $ مجرّدة في كل مكان لا يمنح الوكيل أي وسيلة لمعرفة العملة التي ينتمي إليها السعر.

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

ويكفي أيٌّ من هذه المشكلات لجعل الوكيل يذكر سعرًا خاطئًا لمتسوّق لن يزور صفحتك أصلًا للتحقق بنفسه.

كيف يقرأ وكلاء الذكاء الاصطناعي السعر فعليًا؟

يتبع معظم وكلاء التسوّق ترتيبًا صارمًا في الأفضلية. يتحققون أولًا من البيانات المنظّمة schema.org لأنها صريحة ومقروءة آليًا بحكم تصميمها. وإذا كانت غائبة أو ناقصة، يعودون إلى النص الظاهر في DOM المعروض، وبعض الوكلاء فقط ينفّذ JavaScript قبل قراءة ذلك DOM.

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

وهذا مهم لأن السعر الذي يبدو واضحًا تمامًا للإنسان، معروضًا بخط عريض أعلى الصفحة، قد لا يكون موجودًا بعد في الكود الذي يستلمه الوكيل. وإرشادات Google بشأن البيانات المنظّمة للمنتجات صريحة في أن السعر والعملة والتوفر يجب أن تكون حقولًا منفصلة ومحدّدة النوع، لا مجرد نص ظاهر. ونوع schema.org Offer موجود تحديدًا كي لا يُستنتج السعر من التنسيق.

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

أنماط الفشل الخمسة الأكثر ظهورًا في عمليات التدقيق

عبر المتاجر التي مرّت على تدقيق UXFix المكوّن من 115 قاعدة، تتجمّع أخطاء قراءة السعر حول عدد صغير من الأسباب الجذرية. والأرقام أدناه من مجموعة التدقيق الخاصة بنا، وليست ادعاءً بشأن أي متجر بعينه.

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

لا يصف أيٌّ من هذه الأرقام متجرًا واحدًا بعينه، بل يصف نمطًا عبر المتاجر في مجموعة التدقيق لدينا، ويتكرر النمط بغضّ النظر عن المنصة، سواء كان المتجر يعمل على سلة مستضافة أو بنية تجارة headless أو تطوير مخصص. والقاسم المشترك واحد دائمًا: الرقم الذي يستطيع السكربت استخراجه من أول طلب لا يطابق الرقم الذي يدفعه المتسوّق في النهاية.

كيف تنسّق الأسعار ليقرأها الوكلاء بشكل صحيح

الحل في الغالب تعديل في الترميز، لا إعادة تصميم. وهناك ثلاثة أمور تفوق غيرها أهمية: أن يكون السعر موجودًا في استجابة HTML الأولى، وأن يكون محدّد النوع بشكل صحيح في schema، وأن يكون التمييز بين سعر التخفيض والسعر الأصلي واضحًا لمن يقرأ الكود لا البكسل.

إليك شكل الترميز الصحيح عمليًا، باستخدام سعر التخفيض $61 نفسه من المثال أعلاه:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example Product",
  "offers": {
    "@type": "Offer",
    "price": "61.00",
    "priceCurrency": "USD",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock"
  }
}

السعر المرجعي، أي $89 المشطوب، لا مكان له في Offer.price إطلاقًا. وإذا أردت إظهاره للوكلاء ومحركات البحث، فإن PriceSpecification يتيح لك تسجيل سعر مقارنة بشكل منفصل، بحيث يصبح الخصم صريحًا بدل أن يُفهم ضمنًا من نمط الشطب. ويستحق الاستخدام إن كانت منصتك تدعمه، بدلًا من ترك سعر "كان" نصًا غير منظّم بجوار سعر "الآن".

وثمة تفصيل يستحق الإشارة: الوكلاء لا ينتظرون بشكل موثوق الرسوم المتحركة، ولا خصومات المؤقّت التنازلي، ولا سكربتات "ينخفض السعر داخل السلة". فإذا كان السعر الحقيقي لا يظهر إلا بعد أن يضيف العميل المنتج إلى السلة، فاذكر سعر السلة في schema، لا سعر ما قبل الخصم، وإلا فتوقّع أن ينقل الوكيل الرقم الخاطئ.

أسعار الباقات والاشتراكات والمتاجر متعددة العملات

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

الخيط المشترك بين الحالات الست أن الوكيل لا يملك وسيلة لاستنتاج المقصود من التخطيط. فالإنسان الذي يقرأ "3 بـ $45" يفهم العرض فورًا. أما المحلّل الذي يقرأ الكلمات الثلاث نفسها فيحتاج إلى ربط الـ $45 صراحةً بالكمية 3 في البيانات الأساسية، وإلا فسيبلّغ أن $45 هو سعر الوحدة الواحدة.

وتسعير الخيارات يوقع متاجر يبدو ترميزها نظيفًا فيما عدا ذلك. فعقدة Product واحدة مع Offer واحد وسعر $40 تبدو صحيحة إلى أن يسأل متسوّق وكيلًا عن المقاس الذي يكلّف فعليًا $52.

إذا كانت خياراتك مصمّمة كـ ProductGroup مع إدخالات Offer مستقلة لكل hasVariant، فسيتمكن الوكيل من تحديد الـ SKU الصحيح. أما إذا كانت مصمّمة كمنتج واحد بقائمة منسدلة تغيّر سعر DOM عبر JavaScript، فسيذكر الوكيل السعر الذي حُمّل أولًا، وهو غالبًا أرخص الخيارات، وهذا هو الرقم الذي يكرّره للمتسوّق بغضّ النظر عمّا سأل عنه فعلًا.

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

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

أسئلة تصلنا كثيرًا

هل يستطيع ChatGPT قراءة أسعار التخفيض بشكل صحيح؟

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

هل يجب أن يكون السعر ضمن ترميز schema؟

ليس إلزاميًا، لكنه ينبغي أن يكون كذلك. فالوكلاء الذين يتحققون أولًا من بيانات Offer في schema.org سيحصلون على سعر وعملة دقيقين ومحدّدَي النوع دون تخمين. وبدون ذلك يعودون إلى أي نص ظاهر في DOM، وهو أرجح بكثير أن يتضمن تنسيقًا غامضًا، أو أرقامًا مرشّحة متعددة، أو سعرًا لم يكتمل تحميله بعد.

لماذا يظهر سعري فارغًا لوكلاء الذكاء الاصطناعي؟

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

هل يؤثر اختيار الخيار، كالمقاس أو اللون، على دقة السعر أيضًا؟

نعم، وهو من الحالات الحدّية الأكثر شيوعًا لدينا. فإذا كانت صفحة المنتج تستخدم Offer واحدًا لجميع الخيارات وتحدّث السعر الظاهر عبر JavaScript بناءً على القائمة المنسدلة، فسيجد الوكيل الذي يقرأ schema الأولي السعر الموجود عند التحميل، وهو غالبًا الخيار الأساسي أو الأرخص. وتنظيم الخيارات كـ ProductGroup مع Offer مستقل لكل SKU يعالج ذلك من جذوره.

هل ينبغي أن يعرض schema أسعارًا شاملة الضريبة أم غير شاملة؟

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

هل يؤثر هذا على نتائج Google Shopping أيضًا، لا على الوكلاء الحواريين فقط؟

نعم. إرشادات Google للبيانات المنظّمة للمنتجات تنطبق على واجهتي التسوّق والبحث معًا، وحقلا Offer.price وpriceCurrency اللذان يعالجان أخطاء الوكلاء هما ما يستخدمه Shopping Graph من Google للتحقق من القوائم. وعدم تطابق السعر بين schema وإتمام الشراء قد يؤدي إلى حجب القائمة بالكامل، لا إلى ذكر سعر خاطئ فحسب.