Comment utiliser des analyses avancées pour réduire les applications de mauvaise qualité et augmenter les conversions

Le paysage numérique en évolution rapide englobe toutes sortes d'activités, du commerce électronique et de la vente au détail aux compagnies d'assurance et aux banques. Et à mesure que les services et produits bancaires deviennent de plus en plus banalisés, ils visent à transformer les services en un format en ligne tout en optimisant globalement les processus commerciaux. Comme toute autre entreprise qui se lance en ligne, les banques souhaitent également maximiser leur retour sur investissement, créer de nouveaux services plus rapidement et acquérir un avantage concurrentiel. Pour explorer un nombre énorme d'ensembles de données, les systèmes bancaires appliquent des analyses avancées.

Dans ce cas, nous décrivons la solution fournie par l'équipe OWOX BI pour l'un de nos clients bancaires qui avait des difficultés à améliorer la qualité des prévisions de prêt et à éliminer immédiatement les demandes non pertinentes.

Pour la banque, le défi consistait à améliorer la qualité des demandes de prêt client rapides sur le site Web. Une meilleure préscoration peut réduire le nombre de demandes de prêt échouées et alléger la charge des employés du front office.

La banque a utilisé un formulaire raccourci avec 23 champs, dont 19 sont obligatoires à remplir. Afin d'apporter aux clients une réponse la plus proche possible de la décision prise dans le service hors ligne, il a été décidé de collecter les informations manquantes en ligne (élargir le formulaire de candidature à 33 champs dont 25 obligatoires à remplir). On craignait qu'un formulaire compliqué réduise le nombre de questionnaires. Dans le même temps, on s'attendait à ce qu'un questionnaire plus informatif améliore la qualité des candidatures et fasse gagner du temps aux clients et aux employés de la banque.

Hypothèse : Un formulaire de demande de prêt élargi réduira le taux de conversion en demandes, mais en même temps augmentera la qualité des demandes.

Questions de recherche:

• De combien la conversion en applications diminuera-t-elle ?
• La qualité des demandes de prêt va-t-elle s'améliorer ?

Le test A/B des applications de carte de crédit a été réalisé en lançant une expérimentation avec deux options de formulaire : court et long. Dans le formulaire abrégé, il y avait 23 champs, dont 19 étaient obligatoires. Le formulaire étendu comportait 33 champs, dont 25 obligatoires.

Il a fallu 65 jours pour obtenir un changement de conversion minimum détectable de 1 %. La principale mesure suivie était le taux de conversion en candidatures, car il est supérieur à la conversion en contrats. Le suivi de la conversion vers les applications a permis de réaliser le test dans un délai plus court : plus le taux de conversion est élevé, plus l'audience nécessaire est collectée rapidement. Se concentrer sur la conversion à la signature d'un contrat aurait signifié plusieurs mois de test. Pour la banque, c'était trop long.

La banque était prête à abandonner le questionnaire élargi si le nombre de cartes de crédit émises diminuait. La diminution de la conversion en ventes ne devait pas dépasser le bénéfice économique de la réduction de la charge des employés de banque.

Étant donné que les modifications apportées au formulaire étaient importantes et affectaient la logique de son travail, un mécanisme de remplacement côté serveur a été utilisé pour mettre en œuvre le test.

La version du questionnaire à afficher à un client potentiel de la banque a été déterminée par un script serveur et chargée sans délai visible pour l'utilisateur.

Google Optimize a été utilisé pour surveiller les données et évaluer la conversion en applications. Les données brutes collectées dans BigQuery à l'aide d'OWOX BI et les données contractuelles importées depuis le système CRM de la banque ont été utilisées pour calculer les conversions contractuelles. Les applications sur le site Web ont été enregistrées en tant que transactions de commerce électronique Google Analytics et se sont donc retrouvées dans BigQuery à l'aide d'OWOX BI Pipeline.

Les numéros de transaction ont été envoyés au système CRM de la banque. Lors du téléchargement des données du CRM vers Google BigQuery, le numéro de transaction a été utilisé comme clé pour fusionner les données. Sur la base des numéros de transaction, toutes les étapes d'une demande pourraient être attribuées à la session au cours de laquelle la demande a été reçue.

Le principal avantage de cette approche est l'absence de décalage horaire des contrats et des candidatures : l'accord est attribué au jour de réception de la candidature.

Selon Google Optimize, le taux de conversion du formulaire de candidature étendu devait diminuer de 1 %.

Sur la base des données de test, il semble que le test ait échoué. Alors que pour parvenir à une conclusion définitive, l'équipe avait besoin de voir comment les demandes expérimentales étaient converties en contrats. Cela a nécessité un délai supplémentaire, car jusqu'à 60 jours peuvent s'écouler entre la soumission d'une candidature et la conclusion du contrat.

Les données finales ont montré une amélioration notable de la qualité des candidatures. La conversion de l'application au contrat a augmenté de 0,52 %, tandis que la conversion finale de la visite au contrat a augmenté de 0,02 %. Les clients qui ont rempli un formulaire étendu étaient plus susceptibles de recevoir une carte de crédit.

• Conversion en applications — applications de site Web/sessions pilotes
• Conversion de candidature en contrat — contrats conclus/candidature depuis le site Internet
• Conversion en contrat — contrats conclus/sessions pilotes

Il convient de rappeler que l'objectif n'était pas d'augmenter le taux de conversion mais de le maintenir tout en introduisant un formulaire de demande compliqué. Des tests ont été nécessaires pour contrôler la hauteur de chute.

Il s'est avéré que si vous évaluez les résultats en vous basant uniquement sur les candidatures, le taux de conversion chute. Mais grâce à des analyses avancées, il a été possible de suivre que la conversion en contrats non seulement n'a pas diminué, mais a légèrement augmenté.

Sur la base des tests A/B effectués, la banque a ajouté des champs au formulaire de candidature, le compliquant délibérément. Il a été possible de confirmer l'hypothèse de la banque selon laquelle la conversion aux applications serait réduite mais la qualité des applications augmenterait. Cela a été confirmé en collectant des données brutes à l'aide d'OWOX BI Pipeline et en fusionnant ces données avec des données contractuelles dans Google BigQuery.

• Le nouveau formulaire a éliminé les clients potentiellement non intéressés : la conversion des candidatures a diminué de 1,1 %.
• Le processus de pré-notation s'est amélioré et la qualité des candidatures s'est améliorée : la conversion de candidature en contrat a augmenté de 0,52 % et la conversion finale en contrat de prospect a augmenté de 0,02 %.
• Grâce au formulaire élargi, les informations nécessaires à la prise de décision de la banque sont déjà traitées au stade de la demande en ligne. La charge de travail des employés des succursales a été réduite, et les coûts de la banque ont également été réduits.

Dans l'ensemble, le changement de formulaire de demande a considérablement affecté le taux de conversion. Le test a montré que lorsque le nombre de champs augmente, la plupart des candidatures de faible qualité ne sont pas soumises, ce qui n'affecte pas la conversion finale en contrat. Cela signifie que la banque ne perd rien. De plus, un long formulaire augmente le taux d'approbation final. Il est important que le nombre de contrats n'ait pas diminué lorsque le formulaire a été rendu plus complexe.