لماذا يتخلّى وكلاء التسوّق بالذكاء الاصطناعي عن إتمام الشراء في متجرك
يتخلّى وكلاء التسوّق بالذكاء الاصطناعي عن إتمام الشراء لأن مسار المتجر مبني على افتراض أن إنسانًا هو من يقوده: جدران CAPTCHA، وحقول نماذج تعتمد على JavaScript فقط، وإلزام إنشاء حساب، وسلال تفقد حالتها خلال دقائق. في تدقيق UXFix لـ 200 متجر، يفشل معظمها في ثلاثة على الأقل من الفحوصات العشرة التي تحدد ما إذا كان الوكيل المستقل قادرًا على إتمام عملية شراء. وتتكرر هذه الإخفاقات في صفحة المنتج والسلة وإتمام الشراء، في متجر بعد آخر.
العوائق العشرة الصامتة التي توقف إتمام الشراء لدى وكيل الذكاء الاصطناعي
بنينا دليل قواعد التدقيق لدينا حول ما يُعطّل الجلسة فعليًا، لا حول ما يبدو معطلًا لشخص يتصفح الصفحة. الوكيل لا ينزعج ولا يرتبك كما يفعل الإنسان. فإما أن يجد مسارًا قابلًا للقراءة آليًا عبر التدفق، أو تنتهي الجلسة عند تلك النقطة. وهذه هي الأنماط العشرة الأكثر تكرارًا في صفحة المنتج والسلة وإتمام الشراء.
- جدران CAPTCHA أو كشف الروبوتات الموضوعة قبل إتمام الشراء أو أثناءه، دون بديل يمكن الوصول إليه.
- إلزام إنشاء حساب دون مسار شراء كضيف.
- حقول نماذج تُعرض عبر JavaScript بلا name أو id أو label يمكن للوكيل تحليله.
- رموز جلسة تنتهي في أقل من 5 دقائق، ما يُنهي عمليات إتمام الشراء متعددة الخطوات.
- حالة السلة تُعاد إلى الصفر عند تحديث الصفحة أو عند فتح تبويب جديد.
- حقول العنوان أو الدفع التي تقبل الإدخال عبر أحداث الفأرة فقط، لا عبر لوحة المفاتيح أو الإدخال البرمجي.
- إتمام شراء متعدد الخطوات بلا رابط ثابت لكل خطوة، فلا يستطيع الوكيل استئناف العملية من منتصفها.
- رسائل خطأ تُعرض بتغيير اللون فقط، دون نص يمكن للوكيل قراءته.
- إطارات دفع (iframe) بلا اسم يمكن الوصول إليه، فلا يستطيع الوكيل تمييز الحقول عن بعضها.
- غياب حالة تأكيد ثابتة، أي أن الطلب المكتمل لا يمكن التحقق منه لاحقًا.
كل واحدة من هذه النقاط تبدو صغيرة بمفردها. خذ العائق رقم 3، حقول النماذج المعروضة عبر JavaScript. يرى الإنسان مربع نص ويكتب فيه دون تفكير. أما الوكيل الذي يحلّل الـ DOM فيرى عنصر div مع معالج نقر بلا خاصية name أو id أو label، ولا يجد ما يربط القيمة به. الحقل موجود بصريًا وغير موجود بنيويًا، وهذه بالضبط الفجوة التي لا يستطيع الوكيل تجاوزها.
أما العائق رقم 5، إعادة ضبط حالة السلة عند التحديث، فنرصده باستمرار لأنه غير مرئي في معظم الاختبارات البشرية. نادرًا ما يُحدّث المتسوّق الصفحة في منتصف إتمام الشراء، فلا يلاحظ صاحب المتجر الخلل. أما الوكيل، الذي قد يوقف الجلسة مؤقتًا للتأكد من تفصيل أو مقارنة سعر في تبويب آخر، فيصطدم به في كل مرة. تحليلنا المرتبط حول أخطاء ترك إتمام الشراء على الجوال يتناول فئة مشابهة من المشكلات لدى المتسوّقين على اتصالات جوال غير مستقرة، والحل عادةً هو نفسه: أبقِ حالة الجلسة حيّة لمدة أطول مما تظن أنك تحتاج.
أي واحد من هذه العوائق العشرة قادر على إنهاء الجلسة بمفرده. واجتماع اثنين أو ثلاثة منها، وهو أمر شائع، يجعل إتمام الشراء غير قابل للوصول عمليًا لأي جهة ليست إنسانًا يملك فأرة وصبرًا كافيًا للالتفاف حول نموذج مربك.
لماذا يتخلّى وكلاء التسوّق بالذكاء الاصطناعي عن إتمام الشراء أكثر من البشر؟
المتسوّق البشري الذي يواجه CAPTCHA أو حقلًا مربكًا يتوقف عادةً، وينظر حوله، ثم يحاول من جديد. أما الوكيل فليس لديه بديل بصري ولا حلقة صبر مدمجة. فإما أن يجد مسارًا منظمًا ومُعنونًا عبر النموذج، أو يتوقف.
هذا هو الفارق الجوهري. أبحاث تجربة المستخدم الموجّهة للبشر من Baymard وNN/g أمضت عقدين في توثيق احتكاك يكلّف تحويلات لكنه نادرًا ما يوقف شخصًا مصمّمًا تمامًا. خطوة غامضة لتكلفة الشحن، رسالة خطأ غير واضحة، نموذج بطيء على الجوال؛ كلها تخفض معدلات الإكمال دون أن تُنهي الجلسة بالضرورة. أما احتكاك الوكلاء فثنائي: إما أن تكتمل الجلسة أو لا، ولا توجد درجة جزئية لإتمام شراء "مزعج فقط".
هذا التفاوت مهم عند ترتيب أولويات الإصلاح. المتجر الذي يخسر تحويلات بشرية بسبب تصميم مزدحم ينزف ببطء. أما المتجر الذي يضع CAPTCHA في خطوة الدفع فهو لا يخسر حركة الوكلاء تدريجيًا، بل يخسرها كلها، في كل مرة. وتحليلنا لـقواعد ترك الدفع عند إتمام الشراء التي تؤثر في المتسوّقين البشر مادة مكمّلة مفيدة هنا، لأن عدة قواعد منها، إذا قُرئت من زاوية أخرى، تتحول إلى نقاط توقف تام للوكيل بدل أن تكون احتكاكًا خفيفًا للإنسان.
لهذا يمكن لمتجر أن يحقق نتيجة معقولة في مقاييس قابلية الاستخدام البشرية ومع ذلك يفشل في كل فحوصات الجاهزية للوكلاء تقريبًا. أدلة القواعد تتقاطع، لكنها ليست الدليل نفسه، والتعامل معها كأنها متبادلة هو ما يجعل المتاجر تتفاجأ حين لا يصل طلب مدفوع بوكيل أبدًا.
هل يستطيع ChatGPT فعليًا إتمام عملية شراء من متجرك؟
أحيانًا، والأمر يعتمد كليًا على أي من العوائق العشرة أعلاه موجود. الوكيل المرتبط بمساعد تسوّق سيحاول قراءة صفحة المنتج، وإضافة المنتج إلى السلة، وتعبئة حقول إتمام الشراء باستخدام البنية نفسها القابلة للوصول التي يعتمد عليها قارئ الشاشة. وهذه نقطة تستحق التأمل: النظافة التقنية نفسها التي تجعل الصفحة قابلة للاستخدام بالتقنيات المساعدة هي في معظم الحالات ما يجعلها قابلة للاستخدام من قِبل وكيل.
إذا كانت نماذجك تحتوي على تسميات صحيحة، وسلتك تبقى محفوظة طوال الجلسة، ولا يوجد تسجيل دخول إلزامي أو CAPTCHA، فيمكن إتمام الشراء. وإذا غاب أي من ذلك، يتوقف الوكيل عادةً عند الخطوة التي يقع فيها العائق تمامًا ويُبلغ بأنه لم يستطع الإنهاء. ونرى هذا النمط بثبات كافٍ في تدقيقاتنا حتى صار من أكثر المؤشرات موثوقية للتنبؤ بنجاح الوكيل أو فشله، بل أكثر موثوقية من سرعة الصفحة الإجمالية أو إتقان التصميم.
الدفع هو المرحلة التي يظهر فيها ذلك بأوضح صورة. العائق رقم 9، إطار الدفع بلا تسمية، شائع لأن مزودي الدفع غالبًا ما يُضمّنون أداتهم الخاصة ببنية داخلية لا يتحكم بها التاجر مباشرة. وإذا لم تُظهر تلك الأداة اسمًا يمكن الوصول إليه لكل حقل، فسيرى الوكيل أن هناك قسم دفع دون أن يستطيع تحديد أي مربع هو رقم البطاقة وأيها تاريخ الانتهاء. مقالنا حول قواعد ترك الدفع عند إتمام الشراء يستعرض النسخة البشرية من الإخفاق نفسه، حيث لا يثق المتسوّقون بمربع دفع لا يستطيعون قراءته بوضوح.
إرشادات الوصولية من W3C مؤشر بديل مفيد هنا، لأن النموذج المبني وفق معايير WCAG يكون في الغالب نموذجًا يستطيع الوكيل تحليله أيضًا. ومراجعة متجرك وفق إرشادات مبادرة وصولية الويب ستكشف حصة كبيرة من هذه المشكلات حتى لو لم تفكر في وكلاء الذكاء الاصطناعي مطلقًا. ويجدر أيضًا التحقق مما إذا كان الوكيل قادرًا على العثور على صفحات منتجاتك أصلًا قبل أن يصل إلى إتمام الشراء، وهي مشكلة منفصلة نتناولها في قائمة التحقق من قابلية الزحف لوكلاء الذكاء الاصطناعي.
مثال تطبيقي: كيف يتحول عائق واحد إلى ثلاثة إخفاقات
من المفيد تتبّع إخفاق واحد من بدايته إلى نهايته، لأن العوائق نادرًا ما تظهر منفردة. تخيّل متجر ملابس متوسط الحجم بإتمام شراء قياسي من ثلاث خطوات: الشحن، وطريقة التوصيل، والدفع.
الخطوة الأولى تبدو سليمة. نموذج الشحن يحتوي على حقول مُعنونة، ويملأ الوكيل الاسم والعنوان والبريد الإلكتروني دون مشكلة. الخطوة الثانية هي حيث يسوء الأمر. خيارات طريقة التوصيل مصممة كبطاقات قابلة للنقر بلا حقل اختيار (radio) أساسي، مجرد عناصر div مع معالجات onclick مُنسّقة لتبدو كأزرار. الإنسان ينقر البطاقة التي يريدها. أما الوكيل فلا سبيل لديه لاختيار خيار غير معروض كعنصر نموذج حقيقي.
خيارات التوصيل عبارة عن عناصر div مُنسّقة بمعالجات نقر، دون إظهار name أو value أو حالة الاختيار في الـ DOM.
خيارات التوصيل عبارة عن حقول radio أصلية بتسميات ظاهرة، مع أي تنسيق يتطلبه نظام التصميم.
يتوقف الوكيل هنا، لكن الإخفاق لا يبقى محصورًا في الخطوة الثانية. فلأن رمز جلسة المتجر ينتهي بعد أربع دقائق، وهو العائق رقم 4 في قائمتنا، تكون الجلسة قد انتهت أصلًا بحلول محاولة إعادة المحاولة أو المسار البديل. وما بدأ كعنصر واحد بلا تسمية يتحول إلى فشل جلسة كاملة، ولا يصل الطلب إلى خطوة الدفع إطلاقًا. هذا هو النمط الذي نقصده حين نقول إن اجتماع عائقين أو ثلاثة يجعل إتمام الشراء غير قابل للوصول عمليًا. كان إصلاح بنية طريقة التوصيل وحده كافيًا، لكن نافذة الجلسة القصيرة حوّلت توقفًا قابلًا للتعافي إلى طريق مسدود.
ما الذي تتطلبه الجاهزية للتجارة الوكيلية فعليًا
الجاهزية للتجارة الوكيلية ليست منصة جديدة ولا إضافة برمجية. إنها إتمام شراء لا يفترض وجود فأرة، ولا يفترض الصبر، ولا يفترض أن المتسوّق سينشئ حسابًا قبل الشراء.
- وفّر مسار شراء كضيف بلا اشتراط إنشاء حساب.
- استخدم حقول نماذج HTML القياسية بخصائص name وlabel صحيحة.
- أبقِ حالة السلة والجلسة حيّة لمدة 30 دقيقة على الأقل.
- تضع CAPTCHA أمام إتمام الشراء دون بديل يمكن الوصول إليه.
- تعرض الحقول الأساسية بعد اكتمال حركة JavaScript فقط.
- تُفرغ السلة عند فتح المتسوّق تبويبًا جديدًا.
يستحق إلزام إنشاء الحساب ذكرًا خاصًا لأنه العائق الأكثر احتمالًا أن يكون قرارًا تجاريًا متعمدًا لا خطأً عارضًا. بعض المتاجر تشترط الحساب لبناء قائمة تسويقية أو للحد من الاحتيال، وهذه مقايضة مشروعة. لكن يجدر اتخاذها بوعي كامل: فهو أيضًا العائق ذو التكلفة الأوضح قياسًا، بمتوسط ارتفاع 11% في إتمام الشراء عند إزالته خلال محاكاة التدقيق، وفق بياناتنا أعلاه. وقد كتبنا معالجة أطول لسبب تخلّي المتسوّقين عن إتمام الشراء عند إنشاء الحساب إن أردت الأرقام المتعلقة بالجانب البشري من القرار نفسه.
كثير من بقية هذه القائمة يتقاطع مع أساسيات أداء الويب والوصولية التي يغطيها web.dev، والتي يجدر التعامل معها كقائمة تحقق حتى لو كانت حركة الوكلاء حصة صغيرة من زياراتك اليوم. ولا شيء من ذلك يتطلب إعادة بناء إتمام الشراء من الصفر. الأمر أقرب إلى مراجعة نظافة تقنية: تسمية الحقول بشكل صحيح، وتمديد مهلة الجلسة، والتأكد من وجود عنصر نموذج حقيقي تحت كل معالج نقر.
كيف يرتبط هذا بمعدل التحويل البشري لديك
من المغري التعامل مع الجاهزية للوكلاء كمشروع منفصل عن عملك الأساسي على التحويل، شيء تؤجله حتى تكبر حركة الوكلاء. لكن عمليًا، معظم الإصلاحات أعلاه تفيد المتسوّقين البشر أيضًا، خصوصًا على الجوال، حيث تُنتج الاتصالات غير المستقرة والنقرات العرضية النوع نفسه من عدم استقرار الجلسة الذي يواجهه الوكيل بوتيرة أبطأ.
السلة التي تصمد أمام التحديث تفيد المتسوّق الذي يضغط زر الرجوع بالخطأ على هاتفه بقدر ما تفيد الوكيل. وخيار الشراء كضيف يحذف خطوة عن شخص مستعجل، ويزيل نقطة توقف تام عن الوكيل تمامًا. وإذا كنت تدقّق صفحة المنتج لأي من الفئتين، فدليلنا حول لماذا يغادر المتسوّقون صفحة المنتج دون شراء يغطي عدة مشكلات بنيوية تظهر في أنماط الإخفاق البشرية والوكيلية معًا، من محددات الخيارات غير الواضحة إلى غياب معلومات المخزون.
الخلاصة العملية هي التعامل مع هذا كقائمة أعمال واحدة لا اثنتين. عالج العوائق العشرة الواردة في هذا المقال ضمن عملك المعتاد على نظافة إتمام الشراء، وستحصل على ارتفاع صغير وقابل للقياس في الإكمال البشري، وعلى إتمام شراء قابل للوصول فعليًا من الحصة المتنامية من الحركة التي ليست بشرًا أصلًا.
أسئلة تُطرح علينا
هل يستطيع ChatGPT فعليًا الشراء من متجري؟
نعم، إذا كان إتمام الشراء لديك خاليًا من عائق تام مثل جدار CAPTCHA أو إلزام إنشاء حساب أو حقول تعتمد على JavaScript فقط بلا تسميات يمكن الوصول إليها. في تدقيقات UXFix، المتاجر التي تجتاز 8 على الأقل من فحوصاتنا العشرة لإتمام الشراء بالوكلاء تُكمل عمليات الشراء المدفوعة بالوكلاء بشكل موثوق. أما المتاجر التي تفشل في 3 أو أكثر، وهو وصف 68% من الـ 200 متجر في مجموعة التدقيق لدينا، فلا تنجح تقريبًا أبدًا.
ما هي الجاهزية للتجارة الوكيلية؟
هي مدى قدرة وكيل تسوّق مستقل على التنقل في صفحة المنتج والسلة وإتمام الشراء وإكمالها دون تدخل بشري. وتشمل بنية نماذج قابلة للوصول، وحالة جلسة ثابتة، وتوفر الشراء كضيف، وغياب آليات حجب الروبوتات مثل CAPTCHA. وهي وثيقة الصلة بمعايير وصولية الويب التقليدية من W3C دون أن تكون مطابقة لها.
هل أحتاج إلى واجهة برمجية (API) كي يتمكن وكلاء الذكاء الاصطناعي من إتمام الشراء في متجري؟
لا. معظم وكلاء التسوّق الحاليين يتفاعلون مع الواجهة نفسها التي يستخدمها الإنسان، فيقرؤون الصفحة المعروضة ويملؤون حقول النماذج القياسية. وقد تفيد واجهة برمجية مخصصة للتجارة لاحقًا مع حركة وكلاء كبيرة، لكن العوائق العشرة في هذا المقال هي ما يوقف الوكلاء اليوم، بغض النظر عن وجود واجهة برمجية من عدمه.
لماذا لا يستطيع Copilot أو غيره من المساعدين الشراء من متجري الإلكتروني؟
عادةً بسبب عائق تقني محدد وليس بسبب عدم توافق عام. تحقق أولًا من وجود CAPTCHA في إتمام الشراء، ومن إلزام تسجيل الدخول، ومما إذا كانت سلتك تصمد أمام تحديث الصفحة. هذه الثلاثة تمثّل الحصة الأكبر من الإخفاقات التي نرصدها في الـ 200 متجر ضمن مجموعة التدقيق لدينا.
هل أعالج عوائق الوكلاء قبل مشكلات تجربة المستخدم البشرية أم بعدها؟
تعامل معها كمشروع واحد بدل الاختيار بينها. معظم العوائق العشرة، مثل حقول النماذج بلا تسميات ومهل الجلسة القصيرة وإلزام إنشاء الحساب، تسبب احتكاكًا بشريًا قابلًا للقياس إلى جانب إخفاقات الوكلاء، فمعالجتها تخدم الفئتين معًا. وحيث تتباعد الأولويتان فعلًا، كوجود CAPTCHA أُضيف تحديدًا لمنع الاحتيال، اتخذ القرار بوعي لا بشكل تلقائي، ووازن بين خفض الاحتيال والخسارة الكاملة لحركة إتمام الشراء المدفوعة بالوكلاء.