Amplitudeがファネルを通してコンバージョンを計算する方法

この記事のテーマ：

• ファネルを使用するコンバージョン計算に慣れる
• ファネル分析とイベントセグメンテーションチャートとの重要な違いを特定する

ユーザーが複数回ステップを完了できるファネルのコンバージョンを計算する場合、Amplitudeは各イベントの最初の発生にひもづけられた値に基づいて、各ユーザーをバケットに入れます。

この最初のタッチがどのように決定されるかは、ファネルで定数関数と分割バイ関数を使用する方法によって異なります。 これらの意味を理解することは、分析から正確な結論を引き出すために不可欠です。

ファーストタッチアトリビューションシナリオ

各ユーザーが見ているランディングページで分類された登録をトラッキングする仮想ファネルを考えてみましょう。 最初のシナリオでは、session_idで定数を保持します。 つまり、Amplitudeがコンバージョンとしてカウントするためには、ユーザーは同じセッションでランディングページを表示し、登録を完了する両方のステップを完了する必要があります。

**シナリオ1：**ホールディング定数関数と分割バイ関数の両方を使用するファネル。

これらのケースでは、Amplitudeは、セッション内の最も早いエントリにコンバージョンをベースにしています。 以下の例を見てみましょう。

• ユーザーはランディングページAを見て、同じセッション内で登録を完了します。 そのユーザーのセッションは、コンバージョンされたものとしてカウントされ、コンバージョンは、ランディングページAに帰属します。
• ユーザーは、同じセッションでランディングページA、次にランディングページBを閲覧しますが、ランディングページBを見た後にのみコンバージョンします。そのユーザーは、最初にランディングページAを見たので、セッション内のコンバージョンは、ランディングページAに帰属します。
• ユーザーは、ランディングページA、その後、異なるセッションでランディングページBを見ます。そのユーザーは、ランディングページAを見たセッションではコンバージョンしません。しかし、同じユーザーは、ランディングページBを見たセッションでコンバージョンします。Amplitudeは、ランディングページAセッションを、コンバージョンされなかったとしてカウントし、ランディングページBセッションをコンバージョンされたものとしてカウントします。

注：セッションIDで定数を保持する場合、チャートは、コンバージョンを含むユーザーセッションの数ではなく、コンバージョンを含むユーザーセッションの数を表示します。

シナリオ2：分割バイ関数を使用するファネルであり、ホールディング定数関数ではありません。

これらのケースでは、Amplitudeは、セッション内の最先のエントリにコンバージョンをベースにしています。

ユーザーは、ファネル（ルックバックウィンドウ内で見た最初のランディングページ）をどのように入力したかによってグループ化され、コンバージョンウィンドウの期間内に最終イベントをトリガーした場合にコンバージョンします。以下の例を見てみましょう。

• ユーザーは、ランディングページAを見て、コンバージョンウィンドウ内で登録を完了します。 そのユーザーカウントは、コンバージョンされたものとしてカウントされ、コンバージョンは、ランディングページAに帰属します。
• ユーザーは、ランディングページA、次にランディングページBを見ます。そのユーザーは、ランディングページAのコンバージョンウィンドウ内で登録を完了します。そのユーザーは、コンバージョンされたものとしてカウントされ、コンバージョンは、ユーザーが最初に見たものであるため、ランディングページAに帰属します。
• ユーザーは、ランディングページA、次にランディングページBを見ますが、コンバージョンしません。そのユーザーは、コンバージョンされていないものとしてカウントされ、これは、最初にそのユーザーを見たため、ランディングページAのパフォーマンスに悪影響を及ぼします。この訪問は、ランディングページBのパフォーマンスにカウントされません。

ファネル分析でユニークユーザーカウントのロジック

ユニークユーザーでカウントする場合、コンバージョンのベースライン条件は、次のとおりです。

• ユーザーは、ファネルに含める資格がある必要があります。つまり、ユーザーセグメンテーションパネルを介して、考慮からフィルタリングすることはできません。セグメンテーションモジュールで設定されたフィルタは、ユーザーが最初のファネルイベントをトリガーした時点でのみ適用されます。
• ユーザーは、指定された時間ウィンドウの間にファネルを入力する必要があります。
• ユーザーは、最終ファネルステップでコンバージョンされたものとしてカウントするために、述べたコンバージョンウィンドウ内でファネルのすべてのステップを完了する必要があります。 そうでなければ、ユーザーは、ファネルでどのくらい進歩したかに基づいてカウントされます。

さらに、Amplitudeがユニークでカウントされている場合、各ユニークユーザーの最も早く、最長のコンバージョンのみをカウントします。

• ここで「最長」とは、Amplitudeが最も完全なコンバージョン、つまりファネル内で最も必要なステップの完了をカウントすることを意味します。
• 「最先」は、複数の場合、Amplitudeが最初のコンバージョンシーケンスを時系列的に考慮することを意味します。

言い換えれば、Amplitudeは、最初にユーザーの「最も完全な」コンバージョンをチェックします。その定義を満たす複数のコンバージョンが見つかった場合、最初のコンバージョンを選択して、コンバージョンが発生したときと同じようにカウントします。

分割バイを使用する場合、Amplitudeはファネルエントリの時点で存在したプロパティに従って、最長/最先のロジックを使用して、ユーザーをバケットし続けます。 上記のシナリオ1で説明されているように、セッションごとに定数を保持して、Amplitudeが同じユーザーセッション内で最長/最先のコンバージョンシーケンスを探すことができます。 そのようにすると、測定単位はユニークユーザーとセッションIDのペアリングに変わります。

ただし、イベント合計でカウントする場合、最先/最長のロジックは適用されません。代わりに、Amplitudeはユーザーあたりの最先/最長のパスではなく、実行または試行されたすべてのコンバージョンパスを考慮します。 パスは、分割されたステップでイベントのプロパティに帰属します。

ファネルとイベントセグメンテーション

ファネルとイベントセグメンテーションチャートは、さまざまなタイプの分析を提供し、そのため
異なる結果を表示できる可能性があります。