كيف تستخدم الذكاء الاصطناعي لاكتشاف نقاط التعثر في إتمام طلبات الشراء ؟

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

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

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

1. حدّد رحلة الشراء التي تريد تحليلها

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

تستخدم وثائق تقرير رحلة الدفع في Google Analytics أربعة أحداث : بدء إتمام الطلب ، وإضافة معلومات الشحن ، وإضافة معلومات الدفع ، والشراء . ويعرض التقرير المستخدمين الذين بدأوا من الخطوة الأولى وتقدموا عبر المسار ، ويتطلب إعداد أحداث التجارة الإلكترونية اللازمة لجمع البيانات .

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

في مثالنا نتابع مسارًا عاديًا من أربع مراحل متتابعة : بدء الطلب ، وإرسال بيانات الشحن ، وإرسال معلومات الدفع ، ثم تسجيل طلب مدفوع مؤكد في نظام المتجر .

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

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

2. افحص جودة السجلات قبل تحليل السلات المتروكة

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

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

راجع ثلاث نقاط قبل الاعتماد على الملف :

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

نفترض في المثال اكتمال 24 ساعة متابعة لكل محاولة من وقت بدايتها ، ونحسب كل مرحلة مرة واحدة لكل محاولة . هذه نافذة تعليمية اخترناها للقياس ، وليست قاعدة ثابتة لكل متجر .

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

3. احسب أين يحدث أكبر انخفاض بين المراحل

تتضمن بيانات المثال 500 محاولة بدأت إتمام الطلب . أرسلت 400 محاولة بيانات الشحن ، وأرسلت 240 معلومات الدفع ، وانتهت 180 بطلبات مدفوعة مؤكدة . نفترض سلامة تسجيل الأحداث ومطابقة المرحلة الأخيرة مع نظام الطلبات ، وأن جميع المحاولات تتبع المسار نفسه .

لحساب نسبة عدم الانتقال بين مرحلتين ، استخدم :

نسبة عدم الانتقال = (عدد المحاولات في المرحلة السابقة − عدد المحاولات في المرحلة التالية) ÷ عدد المحاولات في المرحلة السابقة × 100 . 

وبتطبيقها على المثال :

• من البداية إلى إرسال بيانات الشحن : لم تنتقل 100 محاولة من أصل 500 ، أي 20% .
• من إرسال بيانات الشحن إلى إرسال معلومات الدفع : لم تنتقل 160 محاولة من أصل 400 ، أي 40% .
• من إرسال معلومات الدفع إلى الطلب المؤكد : لم تكتمل 60 محاولة من أصل 240 ، أي 25% .

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

أما نسبة إتمام الشراء من بداية المسار فهي 180 ÷ 500 × 100 = 36% . ولا يجوز جمع نسب عدم الانتقال الثلاث ؛ لأن لكل واحدة مقامًا مختلفًا .

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

4. قارن الأجهزة قبل تعميم المشكلة على المتجر

قد تخفي النتيجة الإجمالية اختلافًا مهمًا بين مجموعتين . في مثالنا ، بدأت 300 محاولة على الهاتف و200 على الحاسوب ، ونفترض عدم انتقال المحاولة بين أجهزة مختلفة .

بلغت مرحلة إرسال الشحن 240 محاولة على الهاتف و160 على الحاسوب . انتقلت منها إلى إرسال معلومات الدفع 120 محاولة على كل جهاز .

إذن ، نسبة الانتقال من الشحن إلى معلومات الدفع هي 50% على الهاتف مقابل 75% على الحاسوب ، رغم تطابق عدد المحاولات التي بلغت المرحلة التالية .

وبعد إرسال معلومات الدفع ، اكتمل 84 طلبًا من أصل 120 على الهاتف ، مقابل 96 من أصل 120 على الحاسوب ؛ أي 70% و80% على الترتيب .

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

يمكنك تقسيم البيانات لاحقًا بحسب المتصفح أو إصدار الصفحة عندما يتوافر حجم مناسب من المحاولات . تجنب تحويل كل مجموعة صغيرة إلى استنتاج مستقل ؛ اعرض عدد المحاولات بجانب النسبة حتى تظل المقارنة مفهومة .

5. وجّه الذكاء الاصطناعي لإنتاج خطة فحص محددة

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

استخدم الأمر التالي بعد إرفاق بيانات منزوعة التفاصيل غير الضرورية :

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

افحص أولًا التكرار والمراحل الناقصة والتسلسل الزمني . إذا وجدت بيانات لا تسمح بمقارنة سليمة ، حدّدها قبل حساب النسب .

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

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

استخدم أداة حساب قابلة للمراجعة إن كانت متاحة . وإلا أعطني الصيغ المطلوبة دون الادعاء بأن الحسابات نُفّذت أو روجعت .

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

6. تحقّق من السبب : عطل فعلي أم مشكلة في القياس ؟

ابدأ بالحالات التي توقف تسجيلها عند المرحلة التي حددتها . طابق رمز المحاولة مع السجل التشغيلي ، وابحث عن رسالة خطأ أو طلب مكتمل أو استفسار دعم يوضح ما حدث .

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

هذا المثال يبيّن أهمية المطابقة قبل اقتراح إعادة المحاولة أو تفسير كل نقص في التقرير بوصفه خسارة عميل .

استخدم الأدلة بهذه الحدود :

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

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

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

7. اختبر تعديلًا واحدًا وراقب النتيجة المناسبة

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

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

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

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

لا تحدد نسبة تحسن مضمونة ، ولا تعتبر إرسال تذكير بالسلة علاجًا لعطل يمنع العميل من الشراء . اختر الإجراء بناءً على المشكلة المثبتة .

8. الخلاصة

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

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

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