高度な分析を使用して低品質のアプリケーションを減らし、コンバージョンを増やす方法

急速に進化するデジタル環境には、eコマースや小売から保険会社や銀行まであらゆる種類のビジネスが含まれます。 また、銀行サービスと商品のコモディティ化が進むにつれて、ビジネスプロセスを全体的に最適化するとともに、サービスをオンライン形式に変換することを目指しています。 オンラインになっている他の企業と同様に、銀行もROIを最大化し、新しいサービスをより迅速に作成し、競争力を獲得したいと考えています。 膨大な数のデータセットを探索するために、銀行システムは高度な分析を適用します。

この場合、ローン予測の品質の向上と無関係なアプリケーションの即時スクリーニングに課題を抱えていた銀行クライアントの1つに対してOWOXBIチームが提供するソリューションについて説明します。

銀行にとっての課題は、ウェブサイトでの迅速な顧客ローン申し込みの品質を向上させることでした。 事前スコアリングの改善により、失敗したローン申請の数を減らし、フロントオフィスの従業員の負担を減らすことができます。

銀行は23のフィールドを持つ短縮フォームを使用し、そのうち19のフィールドに入力する必要があります。 オフライン部門での決定に可能な限り近い応答をクライアントに提供するために、不足している情報をオンラインで収集することを決定しました（申請フォームを33フィールドに拡張し、25フィールドに入力する必要があります）。 複雑なフォームではアンケートの数が減るのではないかという懸念がありました。 同時に、より有益なアンケートにより、アプリケーションの品質が向上し、銀行の顧客と従業員の時間を節約できることが期待されていました。

仮説：拡張されたローン申請書は、申請への変換率を低下させますが、同時に申請の質を向上させます。

研究の質問：

• アプリケーションへの変換はどのくらい減少しますか？
• ローン申請の質は向上しますか？

クレジットカードアプリケーションのA/Bテストは、短い形式と長い形式の2つのオプションを使用して実験を開始することによって実施されました。 短い形式では、23のフィールドがあり、そのうち19は必須でした。 拡張フォームには33のフィールドがあり、25が必須です。

1％の最小検出可能変換変化を達成するのに65日かかりました。 追跡された主な指標は、契約への変換よりも高いため、アプリケーションへの変換率でした。 アプリケーションへの変換を追跡することで、テストをより短時間で完了することができました。変換率が高いほど、必要なオーディエンスがより早く収集されます。 契約への転換に集中することは、数ヶ月のテストを意味するでしょう。 銀行にとって、これは長すぎました。

発行されたクレジットカードの数が減少した場合、銀行は拡大された質問票を放棄する準備ができていました。 売上高への転換の減少は、銀行員の負担を軽減するという経済的利益を超えることはありませんでした。

フォームの変更は重要であり、その作業のロジックに影響を与えたため、サーバー側の置換メカニズムを使用してテストを実装しました。

潜在的な銀行の顧客に表示する質問票のバージョンは、サーバースクリプトによって決定され、ユーザーに目に見える遅延なしに読み込まれました。

Google Optimizeは、データを監視し、アプリケーションへの変換を評価するために使用されました。 OWOX BIを使用してBigQueryで収集された生データと、銀行のCRMシステムからアップロードされた契約データを使用して、契約のコンバージョンが計算されました。 ウェブサイト上のアプリケーションは、Google Analyticsのeコマーストランザクションとして記録されたため、OWOXBIPipelineを使用してBigQueryに保存されました。

取引番号は銀行のCRMシステムに送信されました。 CRMからGoogleBigQueryにデータをアップロードするとき、トランザクション番号はデータをマージするためのキーとして使用されました。 トランザクション番号に基づいて、アプリケーションのすべての段階は、アプリケーションが受信されたセッションに起因する可能性があります。

このアプローチの主な利点は、契約と申請の時間オフセットがないことです。契約は、申請を受け取った日に起因します。

Google Optimizeによると、拡張申請フォームのコンバージョン率は1％減少すると予想されていました。

テストデータに基づくと、テストは失敗したように見えました。 最終的な結論に達するために、チームは実験的なアプリケーションがどのように契約に変換されたかを確認する必要がありました。 申請書の提出から契約の締結までに最大60日かかる可能性があるため、これには追加の時間が必要でした。

最終的なデータは、アプリケーションの品質の顕著な改善を示しました。 アプリケーションから契約への変換は0.52％増加し、訪問から契約への最終的な変換は0.02％増加しました。 拡張フォームに記入した顧客は、クレジットカードを受け取る可能性が高くなりました。

• アプリケーションへの変換—Webサイトアプリケーション/パイロットセッション
• アプリケーションから契約への変換—ウェブサイトからの契約/アプリケーションの締結
• 契約への変換—締結された契約/パイロットセッション

目標はコンバージョン率を上げることではなく、複雑な申請フォームを導入しながらそれを維持することであったことを繰り返しておく価値があります。 落下の高さを制御するためにテストが必要でした。

アプリケーションのみに基づいて結果を評価すると、コンバージョン率が低下することがわかりました。 しかし、高度な分析のおかげで、契約への変換が低下しなかっただけでなく、わずかに増加したことを追跡することができました。

実施されたA/Bテストに基づいて、銀行は申請書にフィールドを追加し、意図的に複雑にしました。 アプリケーションへの変換は減少するが、アプリケーションの品質は向上するという銀行の仮説を確認することができました。 OWOX BI Pipelineを使用して生データを収集し、そのデータをGoogleBigQueryの契約データとマージすることで確認されました。

• 新しいフォームは、潜在的に関心のない顧客を選別しました。アプリケーションへの変換は1.1％減少しました。
• 事前スコアリングプロセスが改善され、アプリケーションの品質が向上しました。アプリケーションから契約への変換が0.52％増加し、リードから契約への最終的な変換が0.02％増加しました。
• 拡張されたフォームのおかげで、銀行が決定を下すために必要な情報は、オンライン申請段階ですでに処理されています。 支店の従業員の負担が軽減され、銀行のコストも削減されました。

全体として、申請書の変更はコンバージョン率に大きく影響しました。 テストでは、フィールドの数が増えると、主に低品質のアプリケーションが提出されないことが示されました。これは、契約への最終的な変換には影響しません。 これは、銀行が何も失うことがないことを意味します。 さらに、長い形式の場合、最終承認率が高くなります。 フォームがより複雑になったときに契約の数が減少しないことが重要です。