導入 成熟した製品では、ユーザー当たりの収益や注文数などの主要なビジネスメトリクスに統計的に重要な影響を及ぼすことはしばしば困難である。ほとんどの変更は、ユーザの旅のフィンネルまたは個々の段階のポイント改善に焦点を当てており、そのような変更のビジネスメトリクスへの影響は通常騒音に失われます。 しかしながら、時々、我々は、トップレベルの指標のダイナミクスに沿って動作しないフィンネルメトリクスに気付きます。 さらに、いくつかのテストでは、実施された変更の前の段階での変換は、統計的に重要な方法で変化することがあります。 たとえば、ユーザーが注文を作成し、異なる実行者からオファーを受信し、適切なオファーを選択し、タスクが完了するのを待つサービスを検討します。 たとえば、最高のオファーを強調する新しい機能を開発し、顧客とプロデューサーの一致が発生した場合のオーダーの割合を増やすことが期待されます。 実験の過程で、私たちは、以下を見ることができます: 
 
 
 
 成功したオーダーの割合が減ります。 オーダーの総数と完成したオーダーの総数が増加しています。 少なくとも1件のオファーを受け取ったオーダーの割合は減少する。 このようなパターンは、ユーザーが以前の段階に戻り、例えば注文を再投稿する能力がある場合に発生する可能性があります。 私たちの実験で同様のパターンを発見しました. inDrive では、乗客は自分の価格を提案し、ドライバーからオファーを受け、最も適切なものを選択することができます. 多くのユーザーは積極的に交渉機能を使用し、より良い価格を得ようとすると、注文条件を変更し、再度作成することができます. これは実際に旅行が行われる前に一連の注文につながります. 当社の乗客履行チームは、注文の作成から旅の完了まで、ユーザーの旅の責任を負い、この記事では、これらの行動パターンをどのように調査し、それらに基づいて、テスト結果をより解釈可能にする新しい指標を導入したかを説明します。 この記事は、複雑で非線形のユーザートラベルを持つ製品で働く製品アナリストや製品マネージャーにとって有用であり、メトリック解釈では、行動パターンや繰り返しのユーザーアクションを考慮に入れる必要がある。 Key Metrics and Funnel Metricsとは? 当社の製品では、フンネルは、乗客が注文を作成し、ドライバーからオファーを受け取り、適切なものを選択し、ドライバーが到着するのを待って、その後、旅を開始し、完了します。 私たちは、不確実性を減らすために、ドライバーを探している間に、ユーザにパフォーマンスバーを表示します。私たちは、パフォーマンスバーで、ユーザはより頻繁にドライバーのオファーを待つことになり、結果としてより多くの旅行をすることを期待します。 このようなテストのターゲットメトリクスとして、オーダー作成からオファーを受信するまでの変換を選択することは論理的です。 テストの結果、我々は見る: 
 
 
 
 
 乗車数: ↑ (統計的に重要な増加ではない) オーダー数: ↑ ↑ (統計的に有意な増加) CR from order to bid: ↓↓ (統計的に有意な減少) 実施率: ↓↓ (統計的に有意な減少) 私たちは、乗車数がわずかに増加し、注文数が統計的に重要な増加をみていますが、同時に、オーダー作成からオファーを受け取るまでの変換率が減少し、成功した旅行の割合が減少しました。 ユーザーはオーダーを作成した後だけ機能と相互作用するので、最初に見ると、作成されたオーダーの数に影響を与えることはできませんでした。テストグループがより頻繁にオーダーを作成する傾向があるユーザーを含むことがあった場合、オーダーの数の増加はフィンネル指標を歪曲し、走行におけるポジティブなダイナミクスを説明することができます。 しかし、より深い分析では、これはランダム化の問題ではなかったことが明らかになりました。進捗バーが現れた後、ドライバーのオファーを長時間待つ傾向にある一部のユーザーは、注文を早めにキャンセルし、再び旅行を試みました。 その結果、再注文者数が最も増加した(統計的に有意な増加)。 Reorders は Key と Funnel Metrics にどのように影響しますか? オーダーを作成した後、ユーザーは異なる段階でダウンロードすることができます:ドライバーからオファーを受け取らなかった場合、オファー価格が適切でなかった場合、またはドライバーが到着するのに時間がかかりすぎた場合、後で。 予想される線形ユーザーフローの代わりに、繰り返しのサイクルを観察します - ユーザーは同じシナリオを何度も繰り返そうとします。 繰り返しの試みの効率性を分析すると、その成功率がしばしば大幅に低いことに気付きました. ユーザーが頻繁に再注文を開始する場合、これは実際の変更に先立つすべての段階に影響を及ぼします. 同時に、いくつかのシナリオ(たとえば、出発する代わりにユーザーに再試行を奨励する場合)では、トップレベルのビジネスメトリクスにポジティブな影響を観察することができます. レコードの崩壊 私たちの目標は、ユーザーの意図(個々の試みではなく)がより頻繁に旅行に終わり始めたかどうかを理解することです。 チームとの議論の後、我々は、2つのオーダーが旅行をするための1つの意図として考慮されるために次の特性を持たなければならないと結論付けました。 
 
 
 
 両方の注文のピックアップおよびダウンポイントは、大幅に異なるべきではありません。 注文作成の時間は近い(短い間隔で注文する)。 以前の注文は、旅行で完了したものではありません。 残りの課題は、限界値を定義することだった──「間に近い」と「小さなルート変更」と見なすべきことでした。 我々はこれを見つけた: 
 
 
 
 
 リオーダーの場合、ユーザーは目的地(ポイントB)を変えることはめったにありません。 ピックアップポイント(ポイントA)は頻繁に変化しますが、ほとんどの場合、わずかに - 元の位置から約50メートルです。 ほとんどのリオーダーは最初の10〜20分以内に起こります。 その後、500メートルの範囲内でポイントAとBを固定し、X分以内にどの割合のリオーダーが行われているかを確認しようとしました。 
 
 初期の削減は私たちに良く合った:それらは再注文の90%以上をカバーし、さらに値上げはカバー割合にほとんど影響を与えません。 ユーザーが連続して3つ以上のオーダーを作成する場合、崩壊は順序的に実行されます:最初に、最初と2つ目のオーダーがチェックされ、合併され、次に2つ目と3つ目、そしてその他 - 時間と場所の近さの条件が満たされている限り。 代替 代替アプローチとして、モバイルセッション識別子を使用して単一の意図内の注文をグループ化することを検討しました。 しかし、このオプションは2つの理由で信頼性が低いことが判明しました。 
 
 
 セッションは中断されるか、例えば、ユーザーが注文をすると、その後旅行を行い、すぐに新しいセッションを作成して完了する場合、セッションの限界は実際の行動と一致しません。 モバイルアナリティクスデータはバックエンドデータよりも正確で、イベントタイムとそのオーダーは遅延または紛失で記録することができます。 その結果、旅行意図の定義の基盤としてセッション識別子を使用しないことを決定しました。 新メトリック その結果、私たちは新しいエンティティを作成し、ユニークな識別子を作成するためのルールを定義しました。 このエンティティに基づいて、いくつかの誘導メトリックを構築しました: 
 
 
 Aggregated funnel - 再注文に関連する歪みなしに変換を評価し、テスト結果をより解釈可能にすることを可能にします。 最初の、第二の、およびその後の試みのトンネル - ユーザーが繰り返し試行し、その成功の確率を高めることを刺激するアクションを理解するのに役立ちます。 さて、先ほど議論したテストに戻り、さまざまなアプローチで得られた値を比較しましょう。 
 
 
 
 
 
 
 
 
 
 
 
 Metric 
 Classic Funnel 
 Aggregated Funnel 
 Interpretation 
 
 
 
 
 
 Rides 
 ↑ (not statistically significant growth) 
 Same counting 
 No change 
 
 
 
 
 
 Orders 
 ↑↑ (statistically significant growth) 
 ~0 (not statistically significant) 
 The number of intentions hardly changed — the growth in orders is explained by reorders 
 
 
 
 
 
 Done rate 
 ↓↓ (statistically significant drop) 
 ↑ (not statistically significant growth) 
 The shares of successful orders and successful intentions move in different directions 
 
 
 
 
 
 Order → bid 
 ↓↓ (statistically significant drop) 
 ↓ (not statistically significant drop) 
 Within an intention, users began to receive bids less often; the effect is close to statistical significance 乗り物 ↑ (非統計的に重要な成長率) 同じ数値 変更なし 命令 ↑↑(統計的に有意な増加) 0(統計的に重要ではない) 意図の数はほとんど変わりません - オーダーの増加はリオーダーによって説明されます。 ドンレート ↓↓(統計的に有意な減少) ↑ (非統計的に重要な成長率) 成功したオーダーと成功した意図の割合は、さまざまな方向に動く。 オーダーBid ↓↓(統計的に有意な減少) ↓(統計的に重要な減少ではない) 意図的に、ユーザーはより頻繁にオファーを受けるようになり、その効果は統計的意義に近い。 「オーダー→オファー」の変換が下がっている間に、合計済みの割合が増加している理由を説明するために、ユーザーがどのようにリオーダーを実行するかを調べてみました。 行動が2つのパターンに分かれていることが判明しました: 
 
 
 いくつかのユーザーは、オファーを待つことなく、より速く検索を中止し始めました。 反対に、別のグループは再注文時に値段を増やし始め、そのような注文は受け入れ後にキャンセルされることが少なかった。 追加の観察: 
 
 
 CR to price increase after reorder: ↑↑ (統計的に有意な成長) アグレグレート オファー → 完了: ↑↑ (統計的に有意な成長) 結論 時には、製品とのユーザーの相互作用は、古典的なフィンネルメトリクスによって完全に説明できないことがあります。観察された結果は矛盾しているように見える可能性があり、そのような場合、顧客の行動パターンを反映するメトリクスを使用することが重要であり、当社の場合のように、現実をより正確に記述する新しい実体を作成することが重要です。

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

このオーディオは、ストーリーの元の言語で制作されています。

Nonlinear User Journeys Measurement: Rethinking Funnels Metrics in A/B Testing(非線形ユーザーの旅の測定:A/BテストにおけるFunnelsメトリックの再考)

About Author

コメント

ラベル

この記事は

Related Stories

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps