データタクソノミープレイブック、パート1：はじめに

イベントベースのアナリティクスプラットフォームにデータを送信する前の最も重要なステップは、トラッキングして送信するイベントを特定することです。優れた、よく計画されたインストルメンテーションの重要性は、いくら強調しても強調しすぎることはありません。インストルメンテーションの手を抜くと、イベントの省略、不適切な命名、プロパティの誤用などの問題が分析を不必要に複雑化し、データの値を完全に最大化できなくなる可能性があります。

**注：**この記事は、Amplitudeのデータタクソノミープレイブックシリーズのパート1です。これを終了したら、パート2はこちらから、パート3はこちらからお読みいただくことができます。当社のアカデミーでのタクソノミー設計に関するこのコースも役立つことが分かります。

理解を容易にするため、データタクソノミーの作成に関するこの3部作のプレイブックを作りました。パート1では、データタクソノミーがAmplitudeの使用エクスペリエンスをどのようにガイドし、形づくるかについて、ひいてはユーザーがプロダクトを扱うエクスペリエンスについて、大まかな概要を示します。パート2では、データタクソノミーの重要な2要素であるイベントとプロパティの詳細を見ていきます。最後のパート3では、データタクソノミーをゼロから構築するための業界特有の案をいくつか紹介します。

Amplitudeでアプリケーションのインストルメント化を開始する前に、クイックスタートガイドをお読みいただくことを推奨します。

データ品質に関する注記

イベントをインストルメント化する場合、会社がデータガバナンスルールを設定し、適用することが非常に重要です。これらのルールにより、タクソノミーがクリーンな状態を維持し、組織内の人がAmplitudeを使用し、タクソノミーを理解し、データから有意義な結果を引き出すことができるようになります。

ビジネスルールを作成するときに考慮すべき一般的なこと。

• 新しいデータが目標／ユースケースとKPIに一致することを確かめる
• 一貫したイベント命名法を作成する
• イベント名について、大文字小文字の区別やフォーマットに関する一貫したガイドラインがある
• 長い文字列を読みやすく短縮することを検討する

何よりも、命名法の一貫性を保つことです。例えば、大文字の「送信された注文のチェックアウト」（Checkout Submitted Order）と小文字の「送信された注文のチェックアウト」（Checkout submitted order）の2つのイベントをトラックした場合、別々のイベントとみなされ、自動的に統合することはできません。Amplitudeを使用している他のチームメイトを混乱させることになります。

この動画から、データガバナンスのベストプラクティスについての詳細を学ぶことができます。

ビジネス目標を定義する

あなたのチームどこに向かっていますか？全体的な目標は何ですか？そもそもAmplitudeを使用しているのはなぜですか？あらゆる種類のビジネス目標の達成にAmplitudeは役立ちます。

Amplitudeの顧客が目指す典型的な目標には、次のものがあります。

• プロダクト戦略を設定する
• 買収のROIを改善する
• エンゲージメントをターゲットにする
• コンバージョン最適化
• リテンションとLTVの増加

組織の包括的な目標を特定したら、それに向けて作業を開始する最良の方法は、一連の重要業績評価指標（KPI）を確立することです。これらが、目標の達成に向けた改善のための重点指標です。

ビジネス目標がコンバージョン最適化であるとしましょう。KPIには、次のようなものがあります。

• オンボーディングのコンバージョンを改善する
• チェックアウトのファネルコンバージョンを改善する

データタクソノミーを考える前に、これらを定義することでKPIをトラッキングし、目標を達成に向けた適切なイベントを送信することができます。

ユーザージャーニーを理解する

イベントタクソノミーを作成する際に、プロダクトを通じたエンドユーザージャーニーを忘れてはいけません。タクソノミーでは、分析を次の3つのレベルに分割できます。

• イベントカウンター：日次／月次平均ユーザー、購入総数など
• ファネルとコンバージョン：リテンション率、ファネルコンバージョン、パワーカーブチャート
• 行動分析：アクションが他の指標に与える影響

プロダクトを十分によく理解して、新規ユーザーからパワーユーザーへの典型的なユーザージャーニーがどのようなものかを理解する必要があります。ここでの考え方は、ユーザーがその状態を移行する要因を理解することです。これらの重要な領域で明確に定義されたイベントをトラッキングすると、ユーザーがプロダクトを使う（または妨げる）パターンを分析するのに役立ちます。

プロダクトのクリティカルパスを理解する

すべてのアプリケーションにはクリティカルパスがあります。クリティカルパスは、ユーザーがプロダクトの目的と合うアクションをするシーケンスです。例えば、eコマースのプロダクトのクリティカルパスは、次のようになります。

検索→プロダクトを閲覧→カートに追加→チェックアウト→注文確認

ゲームのプロダクトでは、ユーザーがアプリを開き、登録を呼びかけられ、ゲームのチュートリアルが示されることで、クリティカルパスが開始されるかもしれません。

このオンボーディングプロセスまたはパスを、一連のイベント（「アプリを開く」、「登録 - 個人情報入力」、「登録 - アバター選択」、「登録 - 完了」、「ゲームチュートリアル - 開始」、「ゲームチュートリアル - 閲覧」）に分割できます。

これが完了したら、クリティカルパスとその周辺のフローをよく理解するために必要な、トラッキングのタイプを決定します。例えば、何人が注文したか、チュートリアルを完了したかを知るだけでは十分ではありません。そのクリティカルイベントをトリガーする要因がどのようなものかを知る必要があります。

Amplitudeプロジェクトとデータタクソノミー

Amplitudeでは、プロジェクトとはプロダクトからのすべてのイベントデータが収集される場所です。Amplitudeの組織内に複数のプロジェクトを持つことができます。ただし、Amplitudeの組織には少なくとも2つのプロジェクト：1つのテストプロジェクトと1つの本番プロジェクトがあることが非常に重要です。インストルメンテーションのバグをとらえ、テストデータを本番データから分離するために、本番プロジェクトに送信する前に、常にテストプロジェクトでQAを行う必要があります。

1つのプロジェクトに送信されるすべてのデータは、他のプロジェクトから独立しています。プロジェクトの合計数は、プロダクトとビジネス目標によって異なります。例えば、別々のプラットフォームでユーザーを分析したい場合（ユーザーのすべての動きを見て、iOSデバイスで1つのイベントをトリガーしながら、Webでは別の関連イベントをトリガーした意味を理解したいような場合）は、すべてを1つのプロジェクトでインストルメント化したいと思うでしょう。

**注：**Amplitudeは、現在、すぐに使えるクロスプロジェクト分析をサポートしていません。組織として[ポートフォリオ]アドオンを持っていなければ、すべてのデータはプロジェクト間で分離されます。

ただし、会社が次の場合、

• 複数のプロダクトのデータをトラックしたい
• 別々のプラットフォームで根本的にエクスペリエンスが違う（Webとモバイル）
• 各プラットフォームまたはプロダクトに責任を持つチームが独立している

各サイロ（プロダクト、プラットフォームなど）に複数の個別のプロジェクトを設定する必要があります。これにより、データタクソノミーがクリーンで理解しやすくなります。

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