フローイベントとは、複数のイベントが順番に発生することを条件にイベントを発生させる機能です。
機能の詳細はこちらの記事をご確認ください。

本記事ではフローイベントを使ったユースケースを紹介します。

（注意） 本機能は開発途中のβ版の機能です。
今後、機能の内容・仕様が大幅に変わったり、機能自体の提供を終了する可能性があります。
機能自体が終了する場合にはあらかじめアナウンス致しますが、使用される際はご注意ください。

Case1: 行動ファネルのイベント化

サイト内行動にはステップが存在することが多くあります。
ステップの最後までたどり着いている・途中で離脱（ドロップ）している、という行動をそれぞれイベント化することで、仮説立てしたステップが実際にどの程度/どのようなユーザーに起きていたのか把握することができます。

このケースは想定している課題が実際に起きているのか、その課題のボリューム（インパクト度合い）を検証する目的等で活用できます。

例）記事コンテンツから該当商品を見てカートへ遷移するイベント

行動の流れを設定するときにどのイベントを使うのか？を想定しながら組むと設定がしやすくなります。
このケースではすべて閲覧イベントで組むことができるので、以下のように設定します。

【フロー条件】

  1. 閲覧イベント （詳細条件： EC Topページを閲覧）
  2. 閲覧イベント （詳細条件： 該当記事ページを閲覧）
  3. 閲覧イベント （詳細条件： 該当商品詳細ページを閲覧）
  4. 閲覧イベント （詳細条件： カートページを閲覧）

【NG条件】
なし

※カートイベントは現在フローイベントの条件にまだ設定ができないため、閲覧イベントを利用しています。

例）記事コンテンツを見て商品詳細へは遷移せずに離脱するイベント

「記事コンテンツを見て商品詳細へは遷移せずに離脱する」という流れは閲覧イベントと離脱(※)イベントに分解して、以下のように設定します。

【フロー条件】

  1. 閲覧イベント （詳細条件： EC Topページを閲覧）
  2. 閲覧イベント （詳細条件： 該当記事ページを閲覧）
  3. 離席イベント

【NG条件】

  1. 閲覧イベント　（詳細条件： 該当商品詳細ページを閲覧）

NG条件に該当商品詳細の閲覧イベントを設定することで、「該当商品詳細ページには遷移していない」という状況を明確に設定することができます。

Case2: 課題感が強い行動のイベント化

サイト内には、課題として取り組みたいユーザー行動がいくつかあると思います。
困った状況に陥っている、うまくサイトが使えていないといった行動をイベント化することで、該当の課題にぶつかっているユーザーを把握することができます。

このケースは課題が実際に起きてる数を明確にしたり、課題前後のユーザー行動を確認することで、課題に対してどのように取り組むべきか考察する材料として活用できます。

例）検索を繰り返すものの検索結果0件が連続しているイベント

「検索を何度か行うが、検索結果0件が連続する」という流れは検索イベントと閲覧イベントに分解して、以下のように設定します。

【フロー条件】

  1. 検索イベント
  2. 閲覧イベント （詳細条件： 検索結果0件ページを閲覧）
  3. 検索イベント
  4. 閲覧イベント （詳細条件： 検索結果0件ページを閲覧）
  5. 検索イベント
  6. 閲覧イベント （詳細条件： 検索結果0件ページを閲覧）

【NG条件】
なし

Case3: 理想的な行動の流れのイベント化

ある施策を行うことでユーザーにたどって欲しいフローやカスタマージャーニーで規定した所謂ゴールデンルートなど、理想としているサイト内行動が幾つかあるかと思います。
その行動をイベント化することで、理想的な流れでサイトを利用しているユーザーがどの程度いるのか、そのユーザーは具体的にどんな顧客なのかを把握することにつながります。

このケースは特定の機能や施策利用時に想定通りの行動をしている利用者のボリューム把握、その条件に合致するための前後行動やユーザーの条件深堀りなどの目的で活用できます。

例）TOPページからランキングを見て商品を購入するイベント

閲覧イベントと購入イベントに分解して、以下のように設定します。

【フロー条件】

  1. 閲覧イベント （詳細条件： Topページを閲覧）
  2. 閲覧イベント （詳細条件： 商品ランキングページを閲覧）
  3. 閲覧イベント （詳細条件： 商品詳細ページを閲覧）
  4. 購入イベント

【NG条件】
なし

4の購入イベントの詳細条件で、例えば商品カテゴリや商品ブランド、価格などを指定することでより厳密な条件を入れ込むことも可能です。

Case4: 接客表示後の行動をイベント化

サイト内の回遊や特定ページ遷移を訴求する接客サービスを作成したときに、実際に接客されたユーザーが訴求した行動を取ってくれたのか気になることはありませんか。
接客→A行動と2つの点だけであれば、A行動を該当接客サービスのゴールとして設定することで賄える場合もありますが、接客後の複数の行動を規定したい場合や、行動の流れ自体をイベント化しておきたい場合などに活用できます。

このケースは接客したユーザーのその後の行動を詳細に把握することが主な目的となります。

例）シーズン特集紹介の接客から特集を見て商品ページへ遷移するイベント

「接客後の行動」であるため、接客を見ただけのパターンと接客をクリックしたパターン、それぞれで以下のように設定します。

接客サービスを見ただけのパターン

【フロー条件】

  1. 接客サービスを表示イベント （詳細条件： 該当接客サービス名/アクション名がxxに等しい）
  2. 閲覧イベント （詳細条件： シーズン特集ページを閲覧）
  3. 閲覧イベント （詳細条件： 商品詳細ページを閲覧）

【NG条件】

  1. 接客サービスをクリックイベント （詳細条件： 該当接客サービス名/アクション名がxxに等しい）

接客サービスをクリックしたパターン

【フロー条件】

  1. 接客サービスをクリックイベント （詳細条件： 該当接客サービス名/アクション名がxxに等しい）
  2. 閲覧イベント （詳細条件： シーズン特集ページを閲覧）
  3. 閲覧イベント （詳細条件： 商品詳細ページを閲覧）

【NG条件】
なし

Case5: 熟読を繰り返す行動をイベント化

「同じ行動を繰り返す」という行為のなかには、混乱して何度も同じことを行ってしまうネガティブなパターンと、しっかり記事を読み回遊してまた読み...という(メディア観点では特に)ポジティブなパターンが存在します。
ここでは後者のポジティブなパターンを例に取って紹介します。

このケースは読了イベントと合わせて使うことで、本当にアクティブなユーザーの数の把握や、そのようなユーザーがどのような流れで記事を読んでいるかを詳細に把握するなどの目的で活用できます。

例）何度も記事を読了するイベント

「複数の記事の読了」は閲覧イベントと読了イベントに分解して、以下のように設定します。

【フロー条件】

  1. 閲覧イベント （詳細条件： 記事ページを閲覧）
  2. 読了イベント
  3. 閲覧イベント （詳細条件： 記事ページを閲覧）
  4. 読了イベント
  5. 閲覧イベント （詳細条件： 記事ページを閲覧）
  6. 読了イベント

【NG条件】
なし

関連ドキュメント