追跡するイベントを決定する方法は？

公開: 2022-05-20

これは、顧客データに関する5部構成のシリーズの第5部です。 これがパート1、2、3 、および4です。

質問をすることから始めます。

追跡するイベントと収集するデータを決定するには、ユーザーとその製品の使用法についての質問をリストアップする必要があります。

質問をリストアップし始めると、知りたいことがたくさんあることに気付くでしょう。質問はより多くの質問を生みます、そしてそれが起こるとき、あなたはおそらく一度にすべての答えを得たいと思うでしょう。このプロセスがほとんどの人にどのように感じさせるかのために、これらの質問を燃える質問と呼びましょう。

あなたがそのように感じないのなら、あなたはおそらく多くを知りたがっていないか、あなたの仮定に強い確信を持っていません。ただし、それで質問をするのを妨げないでください。答えを見つけたときに、嬉しい驚きや完全に失望する可能性があります。

データを視覚化できれば、データについて質問するのははるかに簡単ですが、最初に燃えている質問をせずにレポートを作成したりデータを視覚化したりすると、逆効果になる可能性もあります。

燃える質問

「過去7日間に何人のユーザーがサインアップしたか」のように、質問を燃やすのは簡単です。または、「過去7日間にSaaS業界の何人のユーザーがサインアップし、別のユーザーを組織に招待したか」などの複雑なものです。

質問を燃やすことを考えるとき、それは以下の行動をリストアップし始めるのを助けます：

アハモーメントに到達するためにユーザーが実行しなければならないアクション（アクティベーションイベント）
ユーザーがアカウントを購入またはアップグレードする準備ができていることを示すアクション
ユーザーのエンゲージメントを促進し、ユーザーを維持するアクション
ユーザーが製品から十分な価値を引き出していないことを示すアクション
ユーザーを混乱させる可能性のあるアクション

また、製品の経験に疑問を投げかけ、コア製品について熟考する良い機会でもあります。次の質問は、ほとんどのハイテク製品に当てはまります。

価値を評価する時間、またはユーザーがahaの瞬間に到達するのにかかる時間はどれくらいですか？
サインアップ後にユーザーがたどるさまざまなパスは何ですか？
ユーザージャーニーの摩擦点は何ですか？
アクティブユーザーが最もよく使用する機能は何ですか？
有料ユーザーが最も使用しない機能は何ですか？
無料ユーザーから有料ユーザーへの変換につながる機能は何ですか？

イベントとイベントプロパティ

非常に重要な質問のリストができたら（5から10の間で開始するのが適切です）、最も重要なステップであるイベントとイベントプロパティの定義に進むことができます。

ここから、最終的にデータ追跡計画の作成を開始します。

コアイベントに加えて、特定のイベントが発生したときに収集したいさまざまなデータについても考え始める必要があります。このガイドには、このプロセスについて考える方法のコンテキストを提供する、いくつかの一般的なイベントと関連するプロパティの例が含まれています。

追跡計画の作成を開始する前に知っておく必要のある事項が、以下にいくつかあります。

クリック、ビュー、およびプロセス

製品内で発生するクリック、ビュー、およびプロセスの違いに注意することは非常に重要です。クリックされたすべてのボタン、表示されたページ、または完了したプロセスは、固有のイベントとして追跡できます。

また、場合によっては、イベントは、ページビュー、ボタンクリック、またはプロセス完了の3つのいずれかとして追跡できます。

架空のサインアップフローを使用して詳しく見てみましょう。

まず、ユーザーはホームページのサインアップここで、実行されたイベントは、ボタンクリック（ホームのサインアップボタン）またはページビュー（サインアップページ）のいずれかとして追跡できます。

次に、ユーザーは登録フォームに記入し、送信すべてがうまくいけば、提出物はデータベースに到達し、新しい行が作成されます。

ここで、実行されたイベントは、ボタンクリック（送信ボタン）、ページビュー（ありがとうページ）、またはプロセス完了（データベースの新しい行）として追跡できます。

したがって、イベントの追跡方法はユースケースによって完全に異なり、場合によっては、ボタンのクリックとページビューまたはプロセスの完了を同時に追跡することが理にかなっていることもあります。

and sign up とはいえ、ユーザーの行動を理解することが目的の場合は、ユーザーの行動が複数回追跡されないようにすることで、イベントの冗長性を回避する必要があります（サインアップボタンがクリックされ、サインアップ表示されたページ

.ページビューを追跡するには、ただし、一意のページごとにページビューを追跡する場合は、イベントリストが途方もなく長くなります。

ページごとに個別のイベントを定義する代わりに、次のように、イベントプロパティを使用してページ表示と呼ばれる一般的なイベントを指定できます。
ボタンがクリックされました
ページビューと同様に、ボタンのクリックも、次のような関連プロパティを持つButtonClickedなどの一般的なイベントを介して追跡する必要があります。
プロセスが完了しました
プロセスは、データが（特定のテーブルに）書き込まれるか、（テーブルから）取得されるデータベースとの相互作用の結果として発生します。相互作用が失敗すると、プロセスは失敗します。
したがって、プロセスの完了を追跡することは、データベースとの対話の完了に依存するイベントを追跡するための最も信頼できる方法です。

あまりにも一般的なシナリオは次のとおりです。
サインアップフォームに入力した後、ユーザーが送信ボタンをクリックすると、 「パスワードには特殊文字が含まれている必要があります」などの検証エラーが表示されます。 ここで、ユーザーはボタンがクリックされたイベントを実行しましたが、実際にはサインアッププロセスを完了しませんでした。
同様に、ユーザーが送信ボタンをクリックしてもサーバー側のエラーが発生した場合、プロセスは失敗し、ユーザーデータはデータベースに到達しません。そのため、ユーザーがサインアップフォームを正常に送信したにもかかわらず、サインアッププロセスは不完全なままでした。
したがって、イベントが発生したときに完了する必要があるプロセス全体（またはデータベースの相互作用）について考えることが重要です。

さらに、ユーザーが製品にサインアップしたが、電子メールアドレスを確認していないかどうかも知る必要があります。これを行う1つの方法は、ユーザーがサインアップ後にログインするかどうかを確認することです（これは、電子メールが確認された後にのみ発生します）。ただし、電子メールを確認してもログインしないユーザーがいる可能性があります。
したがって、より適切なアプローチは、サインアップ（サインアッププロセスが完了）とこれにより、登録したがメールを確認しなかった人の数もわかり、1〜2日後に確認メールを再送信できるようになります。
クライアント側とサーバー側のイベント
データベースの相互作用（またはバックエンドプロセス）に依存しないクリックやビューなどのイベントは、基本的にクライアント側のイベントです。

クライアント側のイベントは、クライアント（またはユーザーのデバイス）でのみ発生し、フロントエンドイベントとも呼ばれます。
一方、バックエンドプロセスに依存するイベントは、サーバー側イベントと呼ばれます。名前が示すように、データベースの相互作用が正常に完了すると、サーバー側のイベントがサーバー上で発生します。
サーバー側のイベントは、バックエンドイベントとも呼ばれます。
クライアント側とサーバー側のイベントの違いを知ることは、2つのタイプのイベントが通常、組織内の異なる人々によって実装されるため、インストルメンテーションプロセスに役立ちます。
フルスタックの開発者が両方のタイプのイベントの実装を担当している場合でも、追跡計画でイベントソースを指定すると常に役立ちます。

イベント追跡の次のステップ
これで、顧客データに関する5部構成のシリーズの終わりになります。今日からイベントの追跡を開始するには、無料のAmplitudeアカウントを使用してください。