追跡計画を作成する方法は？

公開: 2022-06-08

データ追跡計画（通常は単に追跡計画と呼ばれます）は、イベントデータの信頼できる情報源として機能するドキュメントです。これは、顧客がやり取りするときに収集するデータに関連するすべての情報を含む生きたドキュメントです。あなたの製品で。

このガイドでは、追跡計画を作成するプロセスとベストプラクティスについて説明し、作成に多くの反復と100時間以上を要した追跡計画テンプレートを提供します。

追跡計画を作成する利点

実際には、追跡計画は、次のいずれかを実行するたびに更新されます。

新しいイベント、イベントプロパティ、またはエンティティプロパティを収集します
イベントの名前を変更する
プロパティの名前またはデータ型を変更します
イベントやプロパティの追跡を停止します

追跡計画に含まれていないデータは追跡しないでください。追跡計画の定期的な監査を実施することで、以下に示すようなコストのかかるミスを防ぐことができます。

データの冗長性：同じデータを複数回収集する
データの不正確さ：一貫性のない、または不正確なデータの収集
データの混乱：冗長なデータと不正確なデータの組み合わせ

重要な問題を回避することに加えて、最新の追跡計画を維持することには多くの利点があります。 3つの主要なものを以下で説明します。

実装のしやすさ

データの収集は継続的な取り組みであり、さまざまなチームが新しいタスクを定期的に調整して実行する必要があります。

追跡計画は、追跡する必要のあるデータのリポジトリを維持するだけでなく、データの送信元（データソース）、データの送信先（データの宛先）、および誰が誰であるかを指定します。実装を担当します。

複数の利害関係者と協力する場合、特に1人以上の人が各イベントまたはプロパティの追跡を承認する必要がある場合は、各イベントまたはプロパティの目的に言及することで、実装プロセスを迅速化できます。

クイックリファレンス

実装後、さまざまなチームが宛先間でデータを消費および利用し始めます。これは、追跡されたデータが送信されるツールとシステムです。更新された追跡計画により、これらのチームは各イベントまたはプロパティの意味と目的を知ることができ、そのデータの分析と操作が容易になります。

たとえば、製品チームがファネル分析を実行したい場合、ツールで利用可能になったイベントに基づいて、誰かが製品分析ツール内にファネルを作成する必要があります。

同様に、成長チームが特定のユーザーセグメントを対象とした新しいメールの実験を実行したい場合は、追跡計画を参照して、エンゲージメントツールで利用可能なイベントとユーザープロパティに基づいてセグメントを簡単に設定できます。

知識の伝達

重要性は高いものの、知識の伝達は通常、ほとんどの企業にとって、特にイベント追跡の設定の初期段階では後付けです。

ただし、適切で更新された追跡計画を維持することにより、企業はプロジェクトの引き継ぎや従業員のオンボーディングに伴う多くの課題を回避できます。

新しいチームメンバーがイベント追跡に関して実装されたすべてのことを理解できるようにすることで、新しいチームメンバーと既存のチームメンバーの間で数週間、場合によっては数か月（追跡されるデータの量によっては）を節約できます。

追跡計画を作成するためのベストプラクティス

追跡計画の内容については十分に述べられています。それでは、追跡計画がどのようになるかに焦点を当てましょう。

究極の追跡計画テンプレート

以下の追跡計画テンプレートは、ほぼすべての業界に適合するように多くの調査と反復を行った後に作成されたGoogleスプレッドシートのスプレッドシートです。また、いくつかのサンプルイベントとプロパティが付属しており、すぐに始めることができます。

ここでテンプレートのコピーを作成してください（スプレッドシートをコピーするにはGoogleアカウントが必要です）。

テンプレートには、説明と用語集が含まれています。さまざまなタブに移動したら、[イベント]および[イベントのプロパティ]というラベルの付いたタブに移動して開始します。

以下の最初の3つのステップはすべてのタイプの製品に適用され、4番目のステップはB2BSaaS製品の場合のようにアカウントレベルのアクティビティを追跡する必要がある製品にのみ適用されます。

イベント
イベントのプロパティ
ユーザープロパティ
組織のプロパティ

以下は、独自の追跡計画を作成するための段階的なプロセスです。続行する前に、追跡計画テンプレートが別のウィンドウで開いていることを確認してください。すぐに飛び込みましょう。

イベント

先に進む前に、ユーザーとその製品の使用法についての非常に重要な質問をリストアップすることを強くお勧めします。理想的には、非常に重要な質問は、ユーザーの行動と、ユーザーがアクティベーションイベントにたどり着くまでの経路を理解することに焦点を当てる必要があります。

まだ読んでいない場合は、このガイドを確認してください。このガイドでは、質問の書き込みについて詳しく説明し、追跡するイベントと収集するデータを決定するのに役立ちます。

イベントを一覧表示するときに、製品に関する追加の質問が発生する可能性があることにも注意してください。たとえば、イベントをクリックとして追跡するか、プロセスの完了として追跡するかがわからない場合があります。

そのような質問が発生した場合は、必ずディスカッションというラベルの付いたシートの下の追跡計画にリストしてください。そうすることで、最初からイベントとプロパティを定義するための最も適切な方法についてチームと話し合うことを忘れないでください。。

イベントを一覧表示します

[イベントとイベントのプロパティ]で、質問に答えるために追跡する必要のあるコアイベントを一覧表示します。

このシートには、 SignedUpとProjectCreated今のところ、プロパティを無視して、イベントだけに注目してください。

たとえば、これら2つのイベントは、 「新規ユーザーの何パーセントがプロジェクトを作成したか」という質問に答えることができます。すべてのイベントにはタイムスタンプが付いているため、ドリルダウンして過去7日間などの特定の期間のデータのみをフェッチできます。

上記の例では、 Project Createdがアクティベーションイベントであり、アクティベーションイベントを実行できるようになるには、最初にサインアップする必要があります（ Signed Upイベントを実行します）。

この例を念頭に置いて、アクティベーションイベントに焦点を当て、アクティベーションポイントに到達するためにユーザーが実行する必要のある主要なイベントをリストアップします。ユーザージャーニーについて何かを教えてくれる重要なイベントだけをリストアップするようにしてください。

実行中のアクティベーションイベント（例ではプロジェクトが作成されている）につながるすべてのクリックなど、あまりにも多くのイベントを一覧表示すると、実装期間が長くなり、圧倒される多くの不要なイベントが発生します。

ベストプラクティス：ユーザーの行動とアクティベーションへのパスを理解するのに役立ついくつかの重要なイベントをリストすることから始めます。当面は他のすべてを無視します。

何を追跡するかについてのアイデアがまだ必要な場合は、eコマース、フィンテック、ストリーミングメディア、印刷メディア、およびB2BSaaSの推奨分類法が記載されたAmplitudeの実装ガイドを確認してください。製品が別の業界に属している場合でも、これらまたは他の業界固有の分類法からインスピレーションを得ることができます。

ソースと所有者を追加します

イベントが追跡されているソースに言及することは非常に役立ちます。そうすることで、所有者、つまりそのイベントの実装の責任者を簡単に割り当てることができます。

追跡計画テンプレートでわかるように、サインアップは、サインアップフォームが正常に送信されるとすぐにクライアントで行われるため、クライアント側のイベントです。

一方、 Project Createdは、サーバー上で実行されるプロセスの完了に依存するサーバー側のイベントです。何らかの理由でプロセスが失敗した場合、ユーザーがプロジェクトを作成するためのすべての手順を完了したとしても、イベントが実行されない可能性があります。

イベントをクライアント側で追跡するかサーバー側で追跡するかは、製品のアーキテクチャと使用するテクノロジに完全に依存します。追跡計画でイベントを指定するには、エンジニアリングチームの支援が必要になる場合があります。

さらに、製品に接続されている外部システムで発生するイベントを追跡することもできます。たとえば、作成されたイベントSupport Ticketを追跡する場合、Zendeskなどのサードパーティのチケットツールを使用すると、イベントが発生した場所であるZendeskがデータのソースになります。

ベストプラクティス：インストルメンテーションの第2フェーズで、外部ソースからデータを取り込みます。
イベントのプロパティ
いくつかのイベントを追加した後にイベントプロパティを定義することは、イベントについて考えることから、すべてのイベントに関連付ける必要があるプロパティについて考えることへと精神的に切り替えることができるため、従うべきより良いプロセスです。
すべてのイベントのプロパティを追加します
一度に1つのイベントに取り組み、イベントに関するより多くのコンテキストを提供するプロパティについて考えます。
ユーザーがサインアップイベントを実行するのは（アカウントの作成時に）1回だけであり、これが一意の識別子user_idが生成されるときであることに注意してください。グループプロパティが製品に適用できる場合、ユーザーが新しいアカウントにサインアップすると、グループ識別子organization_idも生成されます。ユーザーが既存の組織に参加するように招待された場合、そのユーザーの新しいorganization_idは生成されません。
システムで生成された識別子に加えて、 Signed Upは、そのイベントが発生したときにユーザーから収集されるすべての情報（first_name、last_name、emailなど）のプロパティを保持します。
プロパティuser_typeは、有機的にサインアップした人と、既存のアカウントに招待された人（Invited）または誰かから紹介されて自分のアカウントを作成した人（Referred）を区別するのに役立ちます。
興味深いメモ：したがって、これらのプロパティはユーザープロパティとしても機能し、 [ユーザープロパティ]シートの下に追加されます。
Project Createdなどの他のイベントは複数回実行でき、イベントに関連付けられているプロパティは、そのイベントの1回の発生に関するコンテキストを提供するプロパティにのみ制限する必要があります。
プロジェクトID （project_id）とタイムスタンプ（project_created_at）に加えて、プロパティproject_nameとproject_user_countは、プロジェクトが作成されるたびに（プロジェクトが作成されたイベントが実行される）追加情報を提供します。
さらに、誰がイベントを実行したかを知るために、 user_idをすべてのイベントに関連付ける必要があります。製品がアカウントレベルのアクティビティを追跡する必要がある場合は、 organization_idなどのグループ識別子もすべてのイベントに関連付ける必要があります。
データ型と期待値を指定します
このガイドでは、すべてのプロパティのデータ型を指定することの重要性について簡単に説明しました。そうすることは、計測プロセスに大いに役立ち、データの一貫性を維持するための重要なステップです。
プロパティの期待値を指定することは、実装を担当する人にとっても非常に役立ちます。また、プロパティに事前定義された値が含まれていると想定される場合に、全員が同じページにいることができます。
データ型がenumまたはarrayのプロパティでは、常に期待値を指定する必要があります。正確な値（ user_typeの場合）または特定の値のリストへの参照（countryの場合）のいずれかです。
目的地に言及する
宛先という用語は、追跡されたデータを送信するツールとシステムを指します。データは、データが消費または処理される宛先にのみ送信する必要があり、すべてのデータをスイート内のすべてのツールに送信する必要はないことを覚えておくことが重要です。
個人を特定できる情報（PII）は、悪用された場合に悪用される可能性があり、名前や電子メールなどのPIIが必要なツール（イベントベースのメッセージングに使用されるエンゲージメントツール）にのみ送信する必要があるため、細心の注意を払って処理する必要があります。（アプリ内またはメール）確かにこの情報が必要です。
したがって、ベストプラクティスは、ほとんどのプロパティが同じ宛先に送信される場合でも、すべてのプロパティのすべての宛先に言及することです。
ユーザープロパティ
ご存知かもしれませんが、ユーザープロパティには、ユーザーに関するさまざまな詳細と特性が格納されているため、ユーザーを識別し、それらのプロパティに基づいてセグメント化できます。
また、前述のように、サインアップ時にユーザーから収集されたデータは、基本的にユーザーの特性を含み、現在の状態を反映するユーザー属性であるため、ユーザープロパティとして追加されます。
これらのプロパティの一部は修正されたままですが、その他のプロパティは変更される可能性があります。ユーザーがファイル内の名前または登録されている電子メールアドレスを変更すると、それぞれのプロパティが新しい値で更新されます。
メールが変更されると、プロパティis_email_verifiedの値がfalseに変わり、新しいメールが確認されると、 is_email_verifiedがtrueに戻ることに注意してください。
所属する業界や職務など、調査を通じてユーザーから収集されたその他の情報も、ユーザープロパティとして保存されます。これらの情報は、分析とアクティブ化の目的でユーザーセグメントを作成するのに役立ちます。
先に進み、すべてのユーザープロパティ、それらのデータ型、期待値、および宛先を[ユーザープロパティ]というラベルの付いたシートにリストします。
組織のプロパティ
組織のプロパティまたはグループのプロパティは、アカウントレベルでユーザーアクティビティを追跡する必要がある製品にのみ適用されます。
ユーザープロパティと同様に、組織プロパティには組織またはアカウントに関する詳細が格納されます。特定のユーザーに関連付けられておらず、ユーザーが属するアカウントに関するコンテキストを提供するデータはすべて、組織のプロパティとして保存されます。
ご存知かもしれませんが、グループプロパティは、ユーザーが複数のユーザーを持つアカウントまたは組織の一部であるB2BSaaS製品で一般的です。アカウント名（organization_name）とそのサブスクリプションプラン（subscription_plan_name）は、ほとんどのビジネスに適用できる共通のグループプロパティです。
ただし、製品によっては、ユーザーではなく、アカウントまたは組織に関連付けられているプロパティがさらに多くなる場合があります。プロパティをユーザープロパティにするか組織プロパティにするかを決定するときは、これをよく考えて、エンジニアリングチームを巻き込む必要があります。
確実にわかったら、先に進んで、すべての組織のプロパティ、それらのデータ型、期待値、および宛先を[組織（グループ）のプロパティ]というラベルの付いたシートにリストします。
これで、追跡計画の最初のバージョンの準備が整いました。先に進み、チームメートと共有してコラボレーションを開始してください。
追跡を開始する
カスタマーデータプラットフォーム、製品分析ツール、またはカスタマーエンゲージメントツールの実装を検討している場合、最初のステップは追跡計画を作成することです。
そして、そのプロセスがどのように見えるかがわかったので、顧客データインフラストラクチャに大きな影響を与える準備が整いました。
とはいえ、Amplitudeのデータガバナンス機能を使用して追跡作業をさらに一歩進め、各イベントが正確に計測されるスマート追跡計画を作成できます。今日からAmplitudeを無料で始めましょう。
ハッピートラッキング！