タクソノミーを計画する

タクソノミーによって、どのイベントとプロパティを追跡するか、それらにどのような名前を付けるか、およびそれらがどのような関係性を持つかが定義されます。堅牢なタクソノミーは、分析の一貫性を保ち、データの欠落を防ぎ、後からコストのかかるスキーマの見直しを回避します。このプレイブックでは、ビジネス目標を定義し、主要な指標を分類し、結果として生じるイベントとプロパティを最適化するという、3つのステップを踏んで1つを構築します。

このプレイブックは、手作業で追跡計画を設計したり、既存の計画を監査したりするときに使用してください。 Amplitudeにコードベースからイベントを自動的に提案してもらいたい場合は、代わりにAmplitude Wizard CLIを使用してください。

タクソノミーとは

タクソノミーとは、データの階層的な分類と命名規則のセットです。タクソノミーはイベントとユーザーデータを識別および分類するため、Amplitudeは関連性のある貴重なインサイトを生成できます。Amplitudeでタクソノミーを設定するプロセスは組織によって異なりますが、コアとなるステップは、追跡したいイベントを選択すること、追跡したいイベントプロパティとユーザープロパティを特定すること、そしてそれらに名前を付けることです。

ユーザー、イベント、およびプロパティ

Amplitudeでは、ユーザーに関連付けられたイベントやプロパティの組み合わせを用いて分析が行われます。

ユーザー

ユーザーとは、アプリケーションに関連するアクションを実行したり、アクティビティに従事したりする固有の個人を表します。 Amplitudeは複数の方法を使用して、さまざまなデバイスにわたってユーザーを識別し、調整します。

ログイン前に匿名ユーザーを調整する方法など、Amplitudeがユニークユーザーをどのように追跡しているかを学ぶことができます。

イベント

イベントとは、ユーザーがプロダクト内で実行する個別のアクションまたはアクティビティです。イベントは、アクティブ（ゲームを開始したりカートに追加したりするなど、アプリの操作時）になることも、非アクティブ（ユーザーはプッシュ通知を受信）になることもあります。

イベントに名前を付ける際、Amplitudeは以下を使用した一貫した命名規則を確立することを推奨しています：

一貫した大文字化：AmplitudeではSong Playedとsong playedを2つの個別のイベントとしてキャプチャするため、この命名規則により、複数のチームが同じイベントを送信する場合など、データが乱雑化するのを防ぐことができるようになります。
一貫性のある構文：Song PlayedとPlayed Songもそれぞれ個別のイベントです。たとえば、「[Noun] + [Past-Tense Verb]」の基準を設定することで、すべてのイベントで一貫性を保てるようになります。
一貫性のあるアクター：Message Sentの場合、「ユーザーがメッセージを送信した」のか、それとも「あなたがユーザーにメッセージを送信した」のか？「すべてのイベントがユーザー視点」と設定されていれば、このように迷うことはありません。

デフォルトのイベントでは、「[Noun] + [Past Tense Verb]」でユーザー視点のタイトルケースが適用されます。また、一貫性を保つ限り、独自の規則を確立することもできます。

プロパティ

プロパティとは、イベントやユーザーに関する詳細を定義するのに役立つ属性です。

イベントプロパティは、イベントの特定のインスタンスに固有の詳細を記述する属性です。たとえば、Purchase Completedというイベントの場合、ユーザーの購入内容、注文総額、使用した支払い方法を具体的に記述できます。
ユーザープロパティはユーザーを記述する特性であり、プロパティが変更されるまでユーザーの将来のすべてのイベントに適用されます。 AmplitudeのSDKはデフォルトで複数のユーザープロパティをキャプチャします。また、独自のプロパティを設定してトラッキングすることもできます。

イベントとユーザープロパティの違いについて詳しくはこちらをご覧ください。イベントと同様に、一貫した大文字・小文字の使用による名前付け規則を確立してください。

ステップ1：ビジネス目標を定義する

目標と指標から始めることで、実装にとって最も重要なものに優先順位を付けることができます。例えば：

あなたやチームは何を目指して取り組んでいますか？
最適化しようとしているメトリックは何ですか?
データを使ってどのような質問に答えたいですか？

Amplitudeのお客様が追求する一般的な目標には次のものがあります。

新規獲得ROIの向上。
プロダクトにおける「アハ・モーメント」を見つけること。
コンバージョンの最適化。
ユーザーのリテンションとLTVの向上

組織の包括的な目標を特定したら、それらを個々の指標に分類することが容易になり、追跡計画が望む結果を反映していることを確認できます。

たとえば、あなたがEコマースアプリを持っていて、購入を増やしたいとします。これを行うには、次の方法があります。

購入フローを通じてユーザーのコンバージョン率を向上させます。
複数の購入を行うユーザーの数を増やすこと。
アプリを訪れるユーザーの数を増やすこと。

これらのそれぞれは、目標を達成するための入力メトリックになり得ます。これらの入力指標に優先順位を付ければ、最も重要な質問に最初に答えられるようになります。最も重要な指標を計画して計測し、あとで繰り返し追加するという反復的なアプローチを検討してください。

ステップ2：主な指標を分類する

最終的な目標を知り、その目標を達成する方法について仮説を立てたら、これらの入力指標をさらに細分化します。ユーザーはどのような重要なパスをたどっていますか？また、ユーザーはこれらの各指標にどのように関与していますか？これらの各パスにとって不可欠なアクションは何ですか？

まず、購入フローを通じてユーザーのコンバージョン率を上げることから始めたいとします。購入フローにおいて、ユーザーとアプリ間での重要なやり取りとは何か？これらの例は次のとおりです。

検索完了: ユーザーは購入するアイテムを検索しました。
表示されたプロダクトの詳細: ユーザーはアイテムの詳細を表示しました。
プロダクト追加: ユーザーが購入注文にアイテムを追加しました。
注文確認済み：購入を行う前に、ユーザーは注文アイテムを確認しました。
注文完了: ユーザーが購入を行い、注文を完了しました。

これらのそれぞれについて、各ステップに関わるさまざまな要因について考えてください。例えば：

検索を使用する際、ユーザーはどのような用語を検索しましたか?
ユーザーがアイテムを表示したとき、購入アイテムのProduct IDは何だったか？

役立つテクニックの1つは、各アクションに関連するオブジェクトについて考え、それらのアクションの属性を各イベントに含めることです。たとえば、システム内のアイテムには ID、カテゴリ、価格などがあり、これらのすべてのプロパティはアイテムに関連するイベントに追加できます。

ステップ3：イベントとプロパティを最適化する

計画を最終的に最適化する時期が来ました。次の質問を自問します。

同様のアクションに対する複数のイベントがありますか？

ユーザーアクションが2つあり、2つの別々のイベントとしてキャプチャすることも、2つの異なるケースを区別するプロパティを持つ単一のイベントとしてキャプチャすることもできます。

たとえば、支払い方法が重要な要素であるとみなされているとします。実装すべきなのは：

Order Completedを、Payment Methodプロパティ（Credit CardまたはApple Payをキャプチャ）を有する単独イベントとして実装する、または
Credit Card Order CompletedとApple Pay Order Completedにイベントを分ける

次の要因を考慮してください。

まずは主要な指標から始めましょう。この場合、購入方法は重要ですが、重要なメトリックは購入フローのコンバージョンです。ファネルに単一のOrder Completedイベントを含めると、購入フローのコンバージョン全体を確認するのが簡単です。
イベントはスケーラブルですか？この例では、PayPalを新しい支払い方法として導入するとどうなりますか？全体的なコンバージョン率を測定するチャートはすべて更新する必要があります。また、インタラクションのために3つのイベントを使用している場合、1つで十分です。
ジャーニーでこれらを別々に識別するか？その場合、単独のOrder Completedイベントで問題ないでしょう。一方で、すべてのイベントをPage Clickedにしてしまうと、これらの一連の一般的なイベントはユーザーフローの確認にあまり役立たないでしょう。

プロパティ定義はイベント全体で一貫していますか？

イベントプロパティは各イベントに固有ですが、タクソノミー全体で一貫して定義してください。たとえば、あるイベントではアイテムの種類を表し、別のイベントでは支払いの種類を表すことができるTypeプロパティにするのではなく、Item TypeとPayment Typeでプロパティを分けることを検討します。

お客様のプロパティは該当するすべてのイベントで収集されていますか

イベントプロパティの典型的なユースケースの1つは、ファネルコンバージョンにカウントされるために一定を保持する必要がある値をトラッキングすることです。たとえば、ユーザーが詳細を表示した後にカートに追加する頻度を知りたいとします。

ステップ1： Product Details Viewed
ステップ2： Product Added

ここでは、ユーザーが同じプロダクトでイベントをトリガーした場合にのみ、ファネルを通じてコンバージョンしたとみなされます。これを維持するには、イベントプロパティProduct IDに実装し、ファネルでこの値が一定に保たれるようにする必要があります。定数保持機能が機能するためには、ファネル内のすべてのイベントにそのプロパティが必要です。

ステップ1： Product Details Viewed
- Product ID = 3345
ステップ2： Product Added
- Product ID = 3345
- quantity = 1

この例では、ユーザーがアイテムを表示した後にカートに追加する頻度を把握できます。 Product IDがない場合、任意のアイテムを表示した後、ユーザーがこれらをカートに追加する頻度を分析することになります。

AI支援型タクソノミー計画

AmplitudeのMCPプラグインには、タクソノミー設計とイベント計測において最も時間のかかる部分を自動化するスキルが含まれています。Amplitude MCP Marketplaceからプラグインをインストールすると、Claude Code、Cursor、またはMCP互換エディタの6つのスキルすべてがロック解除されます。

タクソノミーとガバナンスのスキル

スキル	その機能
`amplitude:taxonomy`	命名規則、プロパティ基準、スコアリングフレームワーク、廃止手順、AI対応準備ガイダンスに関する信頼できる情報源となります。追跡計画を作成または監査する際に使用します。
`amplitude:discover-analytics-patterns`	既存のアナリティクスコールパターンや SDK インポートを求めてコードベースをスキャンし、命名規則を明らかにします。既存のものと一致させるために、新しいインスツルメンテーションを実装する前にこのコマンドを実行してください。

自動実装パイプライン

amplitude:add-analytics-instrumentationを単一のエントリポイントとして使用します。指定のPR、ブランチ、ファイル、機能説明に対してフルパイプラインをエンドツーエンドで実行し、エンジニアリングに提供できる具体的な実装プランを出力します。

内部的には、次の 3 つのサブスキルが順次実行されます。

amplitude:diff-intake: PR または branch diff を読み取り、どのファイルが変更されたか、どのユーザー向けサーフェスが変更の影響を受けるか、および全体的なアナリティクス範囲について、構造化されたサマリーを生成します。
amplitude:discover-event-surfaces: この要約に基づいて、ビジネス成果、ユーザージャーニー、機能の成功、およびフリクションごとに整理された候補イベントの優先順位付きリストを生成します。
amplitude:instrument-events: 候補イベントが指定された場合、コード内の正確な挿入ポイント、推奨イベント名、説明、カテゴリ、AmplitudeのAI対応ガイドラインを満たすプロパティを出力します。

これらのスキルはオープンTargetです：GitHub上のAmplitude MCP Marketplace。

次のステップ

新しい機能を追加したり、プロダクト分析を繰り返したりする際には、このプレイブックの手順を参照してください。Amplitude Dataは、プロダクト内で直接、またはCSVファイルをインポートすることで、プランを作成および反復処理する方法を提供します。

より具体的な例については、以下の業界固有のベストプラクティスガイドを参照してください。サンプルのユースケース、ビジネス上の質問、タクソノミーに関する推奨事項、および補足的なダッシュボードについて説明しています。各ガイドは、これらの分野の特定のニーズに対応しています。

これは役に立ちましたか？