كيفية استخدام التحليلات المتقدمة لتقليل التطبيقات منخفضة الجودة وزيادة التحويلات
نشرت: 2022-05-25يشمل المشهد الرقمي سريع التطور جميع أنواع الأعمال من التجارة الإلكترونية والتجزئة إلى شركات التأمين والبنوك. وبما أن الخدمات والمنتجات المصرفية أصبحت أكثر سلعة ، فإنها تهدف إلى تحويل الخدمات إلى تنسيق عبر الإنترنت إلى جانب التحسين الشامل لعمليات الأعمال. مثل أي شركة أخرى قادمة عبر الإنترنت ، ترغب البنوك أيضًا في زيادة عائد الاستثمار إلى أقصى حد وإنشاء خدمات جديدة بشكل أسرع واكتساب ميزة تنافسية. لاستكشاف أعداد هائلة من مجموعات البيانات ، تطبق الأنظمة المصرفية تحليلات متقدمة.
في هذه الحالة ، نصف الحل الذي قدمه فريق OWOX BI لأحد عملاء البنك الذي واجه تحديات في تحسين جودة التنبؤ بالقروض والفحص الفوري للطلبات غير ذات الصلة.
جدول المحتويات
- مهمة
- الحل: إجراء الاختبار
- تحليل النتائج
- الماخذ الرئيسية
مهمة
بالنسبة للبنك ، كان التحدي يتمثل في تحسين جودة تطبيقات قروض العملاء السريعة على الموقع الإلكتروني. يمكن أن يؤدي تحسين الأداء المسبق إلى تقليل عدد طلبات القروض الفاشلة وتقليل العبء على موظفي المكاتب الأمامية.
استخدم البنك نموذجًا مختصرًا يحتوي على 23 حقلاً ، يلزم ملء 19 حقلاً منها. في محاولة لتزويد العملاء برد أقرب ما يمكن إلى القرار الذي تم اتخاذه في القسم غير المتصل بالإنترنت ، كان القرار هو جمع المعلومات المفقودة عبر الإنترنت (توسيع نموذج الطلب إلى 33 حقلاً مع 25 إلزاميًا لملءها). كانت هناك مخاوف من أن الشكل المعقد من شأنه أن يقلل من عدد الاستبيانات. في الوقت نفسه ، كان من المتوقع أن يؤدي الاستبيان الأكثر إفادة من شأنه تحسين جودة التطبيقات وتوفير الوقت للعملاء والموظفين في البنك.
الفرضية: سيقلل نموذج طلب القرض الموسع من معدل التحويل إلى التطبيقات ، ولكنه في نفس الوقت سيزيد من جودة الطلبات.
أسئلة البحث:
- كم سينخفض التحويل إلى التطبيقات؟
- هل ستتحسن جودة طلبات القروض؟
الحل: إجراء الاختبار
تم إجراء اختبار A / B لتطبيقات بطاقات الائتمان من خلال إطلاق تجربة بخيارين للشكل: قصير وطويل. في الشكل المختصر ، كان هناك 23 حقلاً ، 19 منها إلزامي. يحتوي النموذج الموسع على 33 حقلاً ، مع 25 حقلاً مطلوبًا.
استغرق الأمر 65 يومًا لتحقيق حد أدنى من تغيير التحويل القابل للاكتشاف بنسبة 1٪. كان المقياس الرئيسي الذي تم تتبعه هو معدل التحويل إلى التطبيقات لأنه أعلى من التحويل إلى العقود. أتاح تتبع التحويل إلى التطبيقات إكمال الاختبار في وقت أقصر: كلما ارتفع معدل التحويل ، زادت سرعة جمع الجمهور الضروري. كان التركيز على التحويل لتوقيع عقد يعني عدة أشهر من الاختبار. بالنسبة للبنك ، كان هذا طويلاً جدًا.
كان البنك على استعداد للتخلي عن الاستبيان الموسع إذا انخفض عدد بطاقات الائتمان الصادرة. لم يكن الانخفاض في التحويل إلى المبيعات يتجاوز المنفعة الاقتصادية لتقليل العبء على موظفي البنك.
نظرًا لأن التغييرات في النموذج كانت مهمة وأثرت على منطق عملها ، فقد تم استخدام آلية استبدال من جانب الخادم لتنفيذ الاختبار.
تم تحديد إصدار الاستبيان الذي سيتم عرضه على عميل بنك محتمل من خلال برنامج نصي للخادم وتم تحميله بدون تأخيرات مرئية للمستخدم.
تم استخدام Google Optimize لمراقبة البيانات وتقييم التحويل إلى التطبيقات. تم استخدام البيانات الأولية التي تم جمعها في BigQuery باستخدام OWOX BI وبيانات العقد التي تم تحميلها من نظام CRM للبنك لحساب تحويلات العقود. تم تسجيل التطبيقات على موقع الويب على أنها معاملات التجارة الإلكترونية في Google Analytics ، وبالتالي انتهى بها الأمر في BigQuery باستخدام OWOX BI Pipeline.


تم إرسال أرقام المعاملات إلى نظام CRM الخاص بالبنك. عند تحميل البيانات من CRM إلى Google BigQuery ، تم استخدام رقم المعاملة كمفتاح لدمج البيانات. استنادًا إلى أرقام المعاملات ، يمكن أن تُنسب جميع مراحل الطلب إلى الجلسة التي تم فيها استلام الطلب.
الميزة الرئيسية لهذا النهج هي عدم وجود تعويض زمني للعقود والطلبات: تُعزى الاتفاقية إلى اليوم الذي تم فيه استلام الطلب.
تحليل النتائج
وفقًا لـ Google Optimize ، كان من المتوقع أن ينخفض معدل تحويل نموذج الطلب الموسع بنسبة 1 ٪.
بناءً على بيانات الاختبار ، يبدو أن الاختبار لم ينجح. وحيث إنه للوصول إلى نتيجة نهائية ، احتاج الفريق إلى معرفة كيفية تحويل التطبيقات التجريبية إلى عقود. تطلب هذا وقتًا إضافيًا ، حيث يمكن أن يمر ما يصل إلى 60 يومًا بين تقديم الطلب وإبرام العقد.
أظهرت البيانات النهائية تحسنًا ملحوظًا في جودة التطبيقات. ارتفع معدل التحويل من التطبيق إلى العقد بنسبة 0.52٪ ، بينما زاد التحويل النهائي من الزيارة إلى العقد بنسبة 0.02٪. كان العملاء الذين أكملوا نموذجًا موسعًا أكثر عرضة لتلقي بطاقة ائتمان.

- التحويل إلى تطبيقات - تطبيقات مواقع الويب / جلسات تجريبية
- التحويل من تطبيق إلى عقد - عقود / طلبات مبرمة من الموقع
- التحويل إلى عقد - عقود مبرمة / دورات تجريبية
تجدر الإشارة إلى أن الهدف لم يكن زيادة معدل التحويل ولكن الحفاظ عليه أثناء تقديم نموذج طلب معقد. كانت هناك حاجة للاختبار للتحكم في ارتفاع السقوط.
اتضح أنه إذا قمت بتقييم النتائج بالاعتماد على التطبيقات فقط ، فإن معدل التحويل ينخفض. ولكن بفضل التحليلات المتقدمة ، كان من الممكن تتبع هذا التحويل إلى العقود ليس فقط لم ينخفض بل نما بشكل طفيف.
الماخذ الرئيسية
بناءً على اختبار A / B الذي تم إجراؤه ، أضاف البنك حقولاً إلى نموذج الطلب ، مما أدى إلى تعقيدها عمداً. كان من الممكن تأكيد فرضية البنك بأن التحويل إلى التطبيقات سوف ينخفض ولكن جودة التطبيقات ستزداد. تم تأكيد ذلك من خلال جمع البيانات الأولية باستخدام OWOX BI Pipeline ودمج تلك البيانات مع بيانات العقد في Google BigQuery.
- استبعد النموذج الجديد العملاء المحتملين غير المهتمين: انخفض التحويل إلى التطبيقات بنسبة 1.1٪.
- تحسنت عملية التقديم المسبق وتحسنت جودة التطبيقات: زاد التحويل من التطبيق إلى العقد بنسبة 0.52٪ ، وزاد التحويل النهائي إلى عقد من الرصاص بنسبة 0.02٪.
- بفضل النموذج الموسع ، تتم معالجة المعلومات المطلوبة للمصرف لاتخاذ قرار بالفعل في مرحلة تقديم الطلبات عبر الإنترنت. تم تقليل العبء على موظفي الفرع ، وخفضت تكاليف البنك أيضًا.
بشكل عام ، أثر تغيير نموذج الطلب بشكل كبير على معدل التحويل. أظهر الاختبار أنه عند زيادة عدد الحقول ، لا يتم تقديم الطلبات منخفضة الجودة بشكل أساسي ، مما لا يؤثر على التحويل النهائي إلى عقد. هذا يعني أن البنك لا يخسر أي شيء. علاوة على ذلك ، يزيد الشكل الطويل من معدل الموافقة النهائية. من المهم ألا ينخفض عدد العقود عندما أصبح النموذج أكثر تعقيدًا.