PDP-005: اعرض تاريخ التوصيل المتوقع في صفحة المنتج

تاريخ التوصيل المتوقع في صفحة المنتج هو تاريخ وصول محدد، مثل «يصل الخميس 14 مارس»، يُعرض بجانب زر «أضف إلى السلة» قبل أن يلتزم المتسوّق بأي شيء. في تدقيقات UXFix هذه هي القاعدة PDP-005، وهي قاعدة عالية التأثير في مرحلة اتخاذ القرار، يتحقق منها زاحفنا في شجرة DOM بعد عرض الصفحة. المتاجر التي تعرض سرعة الشحن فقط مثل «3-5 أيام عمل»، أو تُخفي التاريخ خلف نموذج إدخال الرمز البريدي، لا تنجح في هذه القاعدة.

ما الذي تفحصه PDP-005 ولماذا تقع في مرحلة اتخاذ القرار

PDP-005 هي واحدة من 115 قاعدة في كتاب قواعدنا. تعريفها جملة واحدة: تعرض صفحة تفاصيل المنتج تاريخ توصيل أو وصول متوقعًا لخيار الشحن الافتراضي، ظاهرًا دون أي تفاعل. وهي مصنّفة بتأثير عالٍ، ومرحلة اتخاذ القرار، وطريقة كشف عبر dom.

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

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

القائمة الكاملة لما نفحصه، وكيفية تصنيف القواعد الـ114 الأخرى، موجودة في جميع قواعد تجربة إتمام الشراء الـ115 التي ندقّق وفقها.

كيف نقيّمها: فشل، جزئي، ونجاح

نقيّم PDP-005 على ثلاث درجات. المعايير ثابتة بحيث يصل مدقّقان، أو مدقّق ونص برمجي، إلى الحكم نفسه على الصفحة نفسها.

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

بعض الحالات الحدّية التي يُسأل عنها كثيرًا، وكيف تُقيّم:

• «شحن مجاني» بدون تاريخ هي فشل في PDP-005. التكلفة قاعدة منفصلة. هذه القاعدة تتعلق بالوقت.
• «اطلب خلال 2 ساعة و14 دقيقة للتوصيل غدًا» هي نجاح، لأن «غدًا» تُحلّ إلى تاريخ والعدّ التنازلي مرتبط بموعد نهائي حقيقي. وتتحول إلى فشل إذا أُعيد تعيين العدّ التنازلي عند تحديث الصفحة، وهو ما نختبره.
• نطاق تاريخ مثل «يصل من 12 إلى 14 مارس» ينجح. نطاق مثل «يصل خلال 5 إلى 15 يومًا» جزئي. الفرق هو ما إذا كان المتسوّق مضطرًا لحساب أي شيء.
• التاريخ الذي يظهر فقط للمستخدمين المسجّلي الدخول هو جزئي. فمعظم زوار صفحة المنتج ليسوا مسجّلي الدخول.
• التاريخ الذي يظهر في شريط «أضف إلى السلة» الثابت عند التمرير، ولكن ليس في نافذة العرض الأولى، هو جزئي. فالمتسوّق الذي يقرر مبكرًا لا يراه أبدًا.

كيف يبدو تاريخ التوصيل المتوقع الناجح في صفحة منتج حقيقية؟

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

فشل

لقطة الشاشة: صفحة منتج لأدوات منزلية. السعر، وعيّنات الألوان، ومحدد الكمية، وزر «أضف إلى السلة» أسود. تحت الزر ثلاثة أسطر: «شحن مجاني للطلبات فوق 75$»، «إرجاع سهل»، «إتمام شراء آمن». لا تاريخ، ولا مدة.

التعليق: تحتوي DOM على السلسلة «شحن مجاني للطلبات فوق 75$» ولا شيء يُحلّل كوقت. صفحة سياسة الشحن، على بُعد نقرتَين، تقول إن معظم الطلبات تصل خلال 3-7 أيام عمل. محلّلنا لا يغادر صفحة المنتج أبدًا، ولا المتسوّق أيضًا قبل أن يقرر.

جزئي

لقطة الشاشة: صفحة منتج ملابس. تحت محدد المقاس سطر رمادي يقول «التوصيل العادي: 3-5 أيام عمل». وفي الأسفل، داخل أكورديون مغلق بعنوان «التوصيل والإرجاع»، نموذج يطلب الرمز البريدي «للتحقق من تاريخ التوصيل».

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

نجاح

لقطة الشاشة: صفحة منتج إلكترونيات. مباشرة تحت زر «أضف إلى السلة»، سطر واحد مع أيقونة شاحنة: «توصيل مجاني، يصل الخميس 14 مارس». وبجانبه رابط صغير «إلى 94103» يفتح محرر الرمز البريدي. لا شيء مطويّ.

التعليق: عقدة النص «يصل الخميس 14 مارس» موجودة في نافذة العرض الأولى، على بُعد 48px تحت الزر. تحمل الصفحة أيضًا Offer مع shippingDetails تطابق قيمة deliveryTime فيه الادعاء الظاهر. يُستنتج الرمز البريدي من عنوان IP عند التحميل الأول، ويمكن للمتسوّق تصحيحه، لكنه غير مضطر إلى ذلك أبدًا.

لماذا ينتمي التاريخ إلى صفحة المنتج، وليس إتمام الشراء فقط

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

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

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

بيانات تدقيقنا تتوافق مع هذا. عبر 312 صفحة منتج دقّقتها UXFix في الربعَين الأخيرَين، 41% منها لم تعرض أي تاريخ أو مدة في نافذة العرض الأولى، و34% أخرى عرضت مدة فقط. ربع الصفحات فقط نجح في PDP-005 مباشرة. وبالنظر إلى أن الشحن كثيرًا ما يكون من بين الأمور الثلاثة أو الاثنين التي يتحقق منها المتسوّق قبل الشراء، فهذا قدر كبير من العوائق السهلة الإصلاح.

ما الذي يقرأه وكلاء التسوّق بالذكاء الاصطناعي في DOM متجرك

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

لهذا السبب PDP-005 فحص dom وليس فحصًا بصريًا. ثلاثة أمور تجعل تاريخك مقروءًا لوكيل:

• أن يكون عقدة نص حقيقية، لا نصًا مضمّنًا في صورة أو مرسومًا على canvas.
• أن يكون حاضرًا في العرض الأولي أو بعده بقليل، لا بعد إرسال نموذج أو نقرة فقط.
• أن يكون مكررًا في البيانات المهيكلة، بحيث يحصل الوكيل الذي يقرأ JSON-LD أولًا على نفس إجابة الوكيل الذي يقرأ النص الظاهر.

نوع OfferShippingDetails من Schema.org هو الطريقة المعيارية للتعبير عن النقطة الثالثة. وتوثّق Google كيفية قراءتها لهذا الترميز في دليل البيانات المهيكلة لقوائم التجار. مثال بسيط يطابق لقطة شاشة النجاح أعلاه:

{
  "@context": "https://schema.org",
  "@type": "Offer",
  "price": "129.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock",
  "shippingDetails": {
    "@type": "OfferShippingDetails",
    "shippingRate": { "@type": "MonetaryAmount", "value": "0", "currency": "USD" },
    "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
    "deliveryTime": {
      "@type": "ShippingDeliveryTime",
      "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
      "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 3, "unitCode": "DAY" }
    }
  }
}

لاحظ أن الترميز يعبّر عن نوافذ المعالجة والنقل، لا عن تاريخ على التقويم. لا بأس بذلك. فالوكلاء يمكنهم حساب تاريخ منه. ما لا يمكنهم فعله هو حساب أي شيء من حقل فارغ، أو من تاريخ ظاهر يناقض الترميز. في التدقيقات نُعلّم عدم التطابق بين الاثنين كمشكلة منفصلة، لأن الوكيل الذي يرى «يصل الخميس» في النص ونافذة نقل خمسة أيام في JSON-LD يضطر لاختيار أحدهما، وقد يختار الأسوأ.

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

كيف تصل إلى النجاح في متجرك هذا الأسبوع

معظم المتاجر التي تفشل في PDP-005 تملك البيانات بالفعل. فأسعار شركات الشحن وجداول النقل التي تشغّل إتمام الشراء يمكنها تشغيل صفحة المنتج أيضًا. العمل في معظمه توصيل للبيانات وتحديد للموضع.

1. اختر منطقة افتراضية. استخدم تحديد الموقع عبر IP، أو عنوانًا أُدخل سابقًا، أو أكبر منطقة شحن لديك. اعرض التاريخ لتلك المنطقة عند التحميل الأول، وضع لها تسمية، مثل «إلى 94103» أو «إلى المملكة المتحدة».
2. احسب التاريخ، لا المدة. خذ وقت المعالجة، وجدول النقل لشركة الشحن لتلك المنطقة، وساعة الموعد النهائي، وأيام عدم الشحن، وحوّلها إلى تاريخ على التقويم في الخادم. أعد التاريخ كنص.
3. ضعه ضمن 300px من زر «أضف إلى السلة»، في نافذة العرض الأولى بعرض 375px وكذلك على سطح المكتب. إذا كان زرك ثابتًا على الجوال، فالتاريخ ينتمي إلى الكتلة الثابتة التي يراها المتسوّق قبل التمرير، لا إلى الشريط الثابت فقط.

هذه الخطوات الثلاث توصلك إلى النجاح. وثلاث أخرى تُبقي التاريخ موثوقًا للمتسوّقين والوكلاء.

4. اجعل المنطقة قابلة للتعديل بخطوة واحدة. رابط صغير يفتح حقل رمز بريدي مضمّنًا يكفي. لا تُلزم المتسوّق باستخدامه.
5. أصدر ترميز OfferShippingDetails مطابقًا من نفس عملية الحساب.
6. تعامل مع الحالات التي لا تعرف فيها. منتجات الطلب المسبق يجب أن تقول «يُشحن من 2 أبريل». المنتجات المصنوعة حسب الطلب يجب أن تقول «يصل من 20 إلى 24 مارس» بنطاق أوسع بدلًا من لا شيء. المنتجات غير المتوفرة قاعدة منفصلة لها إصلاحها الخاص.

مصيدتان في التنفيذ تتكرران في التدقيقات. الأولى هي المنطقة الزمنية. المتسوّق في سيدني الذي يطلب في التاسعة صباحًا بتوقيته المحلي يرى «اطلب قبل الساعة 3 مساءً اليوم» محسوبة على ساعة مستودع في الولايات المتحدة ويحصل على تاريخ خاطئ بيوم. احسب المواعيد النهائية بتوقيت المستودع لكن اعرض التاريخ الناتج بتوقيت المتسوّق.

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

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

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

ما الذي يُعدّ تقديرًا للتوصيل في صفحة المنتج؟

تقدير التوصيل هو بيان بموعد وصول المنتج إلى المتسوّق، معبّرًا عنه بتاريخ على التقويم أو نطاق تاريخ ضيق، ظاهر في صفحة المنتج قبل أي تفاعل. «يصل الخميس 14 مارس» يُعدّ تقديرًا. «يُشحن خلال 2-4 أيام عمل» سرعة شحن، لا تقدير توصيل، ويحصل على تقييم جزئي. رابط إلى صفحة سياسة الشحن لا يُحسب على الإطلاق.

هل تكفي سرعة الشحن، أم أحتاج إلى تاريخ محدد؟

تحتاج إلى تاريخ. سرعة الشحن تجعل المتسوّق يجري حسابات بأيام العمل والمواعيد النهائية وعطلات نهاية الأسبوع، ومعظمهم يقرّبون إلى الأعلى. تدرج أبحاث Baymard عن التخلي «التوصيل كان بطيئًا جدًا» كسبب لـ23% من حالات التخلي، والمتسوّقون يحكمون على السرعة مقارنةً بالتاريخ الذي يحتاجونه، لا بعدد الأيام. نطاق تاريخ ضيق مقبول عندما لا تستطيع شركة الشحن فعلًا الالتزام بيوم واحد.

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

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

كيف تكشف UXFix قاعدة PDP-005 تلقائيًا؟

يعرض زاحفنا صفحة المنتج في متصفح بلا واجهة بعرض سطح المكتب والجوال، وينتظر خمول الشبكة، ثم يفحص عقد النص الظاهرة في نافذة العرض الأولى بحثًا عن أنماط التاريخ والمدة ويقيس مسافتها من عنصر «أضف إلى السلة». كما يحلّل أي Offer في JSON-LD بحثًا عن shippingDetails ويقارن الاثنين. التاريخ الظاهر ضمن النطاق ينجح، والمدة أو التاريخ المخفي جزئي، وعدم وجود أي شيء على الإطلاق فشل.