生物学と医学では、ご存知のように、人間やその他の高等霊長類に関する多くの実験は現在禁止されています。 しかし、マーケティングおよび製品管理では、これはまだ禁止されていません。 私たちがID Financeで積極的に使用しているもので、バリューオファー、製品機能、インターフェイスなどの多変量テストを実施しています。
当社でのA / Bテストは広く行われており、特にひねくれています。 テストは、弁護士と会計を除き、私たち全員が実施します。 しかし問題は、これらの実験は通常、A / Bテストで通常理解されるものよりもはるかに複雑なことです-ボタンの色の変更、フィールドの移動、ランディングページの再設計-Google AnalyticsやVisual Website Optimizerなどのフレームワークを介して簡単に実行できることです。 私たちのケースでは、カスタマージャーニーの大部分が変化しており、主要なビジネス指標の大部分がそのようなテストをキャッチできます。
その結果、そのようなテストの正しい実施、そして最も重要なことには、それらの結果の正しい要約は、いくつかの啓発されたものにアクセス可能な一種の芸術になりました。 もちろん、これは良くありません。 最終的に、ビジネスアナリストとマネージャーがすべてを正しく行えるように、推奨事項と例を収集することにしました。 実際、ミスは非常に高価です。最良の場合、データ曲線の収集とテストの再開に時間がかかり、最悪の場合、誤ったビジネス上の決定を下す可能性があります。 同時に、会社は成長しており、新しい人が来て、学習曲線をできる限り減らしたいと思っています。
私の意見では、私たちの経験とそれを蓄積するために行った道は、あなたの会社に非常に適用できるでしょう。 特に次の場合：
- あなたは難しい顧客の旅をしています。
- その異なる部分は相互接続されており、多くの場合、主要なメトリックは異なる方向に変化します。
- 複雑な効果を持つ複雑な実験を実施したい場合。
一般化に直行しないようにするために、選択されたケースのシーケンスを最初に案内したいと思います。 私は、明白な明白な結論が真実ではない私たちの実践からそのような例を選択しようとしました。 この方法で問題を調査したので、結論と推奨事項にさらに準備を進めることができます。
サムライユーザーの私たちのやり方
さらなるストーリーのコンテキストを設定するために、クライアントのライフパスの主要な段階を簡単に検討します。
まともなeコマースの慣例であるように、私たちはオンライン（そして時にはオフライン）のチャネルを通じてWebサイトに顧客を引き付け、そこで登録してローン申請書に記入します。 申請書の記入はかなり複雑で責任のあるプロセスであり、クライアントは多くの情報を提供する必要があります。そのため、私たちは彼にローンを与えるかどうかについて十分な情報に基づいた決定を下します。 実際には、アプリケーションの検討とクライアントの検証が次のステップです。 お金の発行後、彼らのリターンのための「資金調達」キャンペーンが始まります。 しかし、ローンの返済に成功した後、クライアントは通常次のことを求めます。プロジェクトの収益は80〜90％の範囲です。
以下の表は、クライアントのライフサイクルの段階のコンテキストで実験するためのいくつかの方向を示しています。
一般に、ローミングする場所があります。 次に、どのレーキを踏むことができるかを見てみましょう。
単純な着陸テストから始めます。
伝統から逸脱することはせず、特定のマーケティングチャネルでランディングページをテストするパフォーマンスのかなり古典的な例を示します。
以下は、まさにこの着陸のための2つのオプションです。 さらに読むことなく、次のステップでどのオプションが最大の変換を与えるかを推測してみてください？
オプションA
オプションB
そして、将来の使用のためにどのオプションを選択しましたか？
秘Theは、これら2つの質問に対する答えが異なることです。 ローンを申請するための目標到達プロセスの手順でコンバージョンの変更を確認すると、これを確認できます。
次のステップへの変換はオプションBの方が高くなります。 この場合、ユーザーに必要なのはボタンを押すことだけです。 それはシンプルで楽しいです：クリック-そしてすでに次のステップで。 しかし、そこでは、将来のクライアントは彼の個人データに関する多くの質問をすでに待っています。 実際、1つのステップで、アプリケーションは終了しません。 その結果、他のすべてのステップで顧客のモチベーションが急速に衰退し、コンバージョンが低下しますが、オプションAでは、借り手は何が起こっているのかをより深く理解しており、最後まで到達するために大きなヒューズを得ました。
したがって、着陸の通過の改善にもかかわらず、残念ながら、エンドツーエンドの変換は改善されていません。 最初の結論に至ります ： 実験の出口での直接的な変換（実際に変更した部分）だけでなく、テストが影響するライフサイクル全体を調べる必要があります。
したくないし、しない
次のケースは、コンバージョンを増やす試みにも関連しています（たとえば、スペイン語のプロジェクト）。
一部の国では、上記のような写真ドキュメントをアップロードするステップがあります。 実験では、最初は申請プロセスの途中にあったこのステップを最後に移動し、オプションにしました。 計算は、クライアントが必要なドキュメントを持っていない可能性があり、後でそれを送信するということです。
その結果、予想どおり、目標到達プロセスのコンバージョンは約x％増加しました。 しかし、同時に、発行されたローンの数は％<x％だけ増加しました。 この違いはどこから来たのですか？ 事実、検証段階でステップをスキップするクライアントも、将来的にも、写真ドキュメントを提供できなかった（したくない）こともあります。 その結果、「承認レベル」と呼ばれる指標が減少しました。これは、要求されたローンの発行数に対する比率です。 1つの部門が目標到達プロセスの変換を担当し、別の部門が承認レベルを担当するという事実により、状況は複雑になります。
前の例と同様に、ここでの主なことは、テストが影響するライフサイクルの部分を決定し、調査するターゲットメトリックを決定することでした。 この場合、テストの効果は次の簡単な方法でモデル化できます。
クレジット=リード*コンバージョン*承認レベル
つまり 発行に対する累積的な効果がプラスであれば、変化があり、そうでなければ変化しません。 そのため、通常は部門間の矛盾を解決します。
固定電話は誰ですか？
そのため、ある時点で、誰もが固定電話を持っているわけではないと思い、フォームなしでフォームをテストすることにしました（以下、ポーランドのプロジェクト）。
問題は、固定電話がクライアントに連絡するのに適したツールであるということです（簡単に捨てることはできません。住所に結び付けられているなど）。 したがって、予想どおり、電話なしのバリエーションでは、ローンの収益率がわずかに低下しました。
コンバージョンは増加しており、コレクションは減少しています。 この状況でどのオプションが優れているかを理解するにはどうすればよいですか？ この質問に答えるためには、ローンのユニットベースの経済を十分詳細にモデル化する必要がありました。
上記の写真には多くの奇妙な数字があり、これのおかげで、私たちは定期的に対処しなければならない複雑さのレベルをよく示していると思いますが、それはフォームのステップの1つから1つのフィールドを削除するような一見些細なことから始まりました。
要するに、 経済効果は、コンバージョンの増加がユニットエコノミーのマーケティングコストのシェアを削減するという事実に要約されます。 少しの計算で、どちらのオプションの方が良いかがわかりました。 これを待つにはほぼ2か月かかりましたが、最初のローンの支払い日以降に収集に関する統計を収集する必要がありました。
忘れられた顧客
昔、カザフスタンのプロジェクトにクライアントを登録する手順の1つは次のようになりました。
私たちは（ちょうどあなたのように）このシートは長すぎると考え、これは道徳的に不安定なクライアントを追い払う可能性があります。 実験の代替オプションは、前のブロックが正常に満たされた後にのみ後続の各ブロックが表示されるインターフェースでした。
期待したほどではありませんでしたが、結果によるコンバージョンが増加し、トラフィックを新しいオプションに完全に切り替えました。 ハッピーエンドのようです、遊びが終わり、カーテンは省略されますが、いいえ。
しばらくして、コンバージョン率が非常に低いユーザーがいることを偶然発見しました。 彼らがそれを整理し始めたとき、これらのユーザーは、じょうごに入っていないように見える奇妙なページを訪れていたことが判明しました。 しかし、ちょっと待って、どこかでこのURLを見たことがあります....
実際のところ、システムは、クライアントがアプリケーションを送信してサイトを離れるすべてのステップをすぐに実行せずに戻って続行したい場合に、前回のステップにまっすぐ進むように機能したということです。 そして私は言わなければならない、そのようなケースがたくさんあります。 実験が行われたとき、制御戦略にいたクライアントの一部は、第2ステップの長いバージョンを習得しませんでした。 その時点でこれらのユーザーはサイトを離れ、実験の「終了」後に戻ってきました。 そして、システムは、以前に実行された実験バリアントに基づいて、それらを再び第2ステップの古いバージョンに送信しました。 しかし、進歩はまだ止まっておらず、すぐに忘れられてサポートされていない古い第2ステップは、バックエンドとの互換性を失い、正常に動作しなくなりました。 貧弱なクライアントはレガシーコードの人質になります。
ここで何が間違っているのでしょうか？ 実験を適切に終了しませんでした。 この場合、テストの終了時に、コントロールグループから勝者グループへのクライアントの移行を保証し、できればレガシーコードを削除する必要がありました。
マテリエル
おそらく、実践から理論へと移行する時です。 テストの構造は次のように表すことができます。
実際、赤はライフサイクルの変化に直接さらされている部分を強調しています。 黄色は、すべての人にとって同じままですが、実験がそれに直接影響する部分です。 したがって、テスト結果について決定を下すには、「赤」部分だけでなく「黄色」部分からも重要なメトリックを分析する必要があります。 残りの旅は始まります。実験の影響は無視できます。 ただし、テストは前提条件を確認するためのテストであるため、すべての基本的な指標も確認する必要があります。 これらのメトリック間の統計的に有意な違いは、次のいずれかを意味する場合があります。
- 実験の影響は考慮していません。要約する際には、このメトリックを考慮する必要があります。
- 実験の設計に誤りがあります（技術的なものである可能性があります-実装中に発生したもので、設計段階で発生した「イデオロギー」である可能性があります）。 このエラーはテスト結果を滑らかにし、偏りはメトリックの違いによって表れますが、違いはありません。 このような悲しい状況では、それでもエラーの影響からデータをクリアできるかどうかを確認する必要があります。たとえば、一部のサブセグメントまたは期間を選択するか、必要なすべてのインジケーターを調べるわけではありません。 うまくいかない場合は、新しいエディションでテストを再起動する必要があります。
まとめると。 実験を正しく設定するには、いくつかの質問に答える必要があります。 もちろん、開始する前に。
- このテストが必要な理由。 改善したいもの。
- 実際、改善とは何か-1つ以上の実験戦略の内容。
- 私たちがテストしている人、すなわち どの顧客セグメントが実験に入るべきか。
- 実験への入り口は、実験戦略が実行されたユーザーのライフパスの瞬間であり、ユーザーの経路は、抜け落ちたオプションに従って分岐します。
- 実験の終了ポイントは人生の瞬間であり、ユーザーはそこから再び同じ実験に参加できます（たとえば、別のオプションを取得できます）。 特別なケースは、「終生」テストで、一度終了したバリアントが実験の終了前にユーザーに割り当てられます。
- 実験の予想される効果、およびこの効果を測定するためにどのような指標を検討するか。
- ポジティブおよびネガティブな状況でのこの効果の評価。
- （非）成功の基準は、メトリックの境界値であり、統計的に有意な交差点で決定を下すことができます。
- このテストが他の人に与える影響、および他の人がこのテストに与える影響。
- テスト期間と必要なサンプルサイズ。
- テストの最後は、システムとすべてのユーザーを新しい現実に移行する方法です。
- テストの一時停止-問題が発生した場合、テストを一時停止して状況を明確にし、修正をロールアウトできますか？
これらの例と技術が、あなたの会社の実験の質を向上させるのに役立つことを願っています。