アナリティクス トラッキングを作成または進化させる際に従うべきベスト プラクティス

編集者注: この記事は、もともと 2021 年 1 月 10 日に Iteratively ブログで公開されたものです。

追跡計画は生きた文書であり (または Amplitude のようなツールで使用できます)、通常、追跡するイベントとプロパティ、それらが何を意味し、どこで追跡されるかについて概説します。 これは、分析のための信頼できる唯一の情報源を成文化するのに役立ち、製品のコード ベースで分析追跡 (またはスキーマ) を計測するために必要な詳細を開発者に提供します。

そして、なぜあなたはそれが必要なのですか？ 追跡計画がなければ、製品でどのイベントをキャプチャしているのか、またそれらが何を意味するのかを知ることは非常に困難です。 また、取得したデータがソース (iOS、Android、Web、バックエンドなど) 全体で一貫していることを確認し、データの消費者が Amplitude などのツールで、またはデータ ウェアハウスで直接、分析のためにどのデータを探索できるかを理解できるようにします。 .

追跡計画に加えて、分析追跡を定義、計測、検証する方法に関するプロセスも必要です。 このプロセスには、通常、製品マネージャー、データ アナリスト、および開発者が関与します。

この投稿では、あなたとあなたのチームが確実に成功し、追跡計画とプロセスのメリットを享受して、分析を次のレベルに引き上げることができるようにする方法をいくつか探ります。

目標と指標から始める

メトリクスの概要を説明することから始めて、そのメトリクスについて適切にレポートするために必要なイベントを特定することが重要です。 目標、メトリクス、イベントの間にリンクがなければ、ビジネスにとって重要なイベントを見逃す一方で、実際には必要のない無秩序な追跡計画とデータになってしまう可能性が高くなります.

また、インストルメンテーションのイベントに優先順位を付けるのにも役立ちます。また、プロダクト マネージャーやデータ アナリストが、新しい機能の目標や成功の指標だけでなく、それを測定するために製品で必要な実際の追跡にどのように変換するかについて考えるようになることを願っています。

イベントとユーザーのプロパティを忘れないでください

プロパティは、イベントまたはユーザーに関連付けられたすべての詳細を取得できる場所です。 それらは、イベントまたはユーザーに関するコンテキストを記述し、アナリストがグループ化、フィルター処理、およびコホートできるようにします。

プロパティには、イベント固有 (購入イベントに関連する収益額など) とユーザー固有 (ユーザーに関する人口統計情報など) の 2 種類があります。 ほとんどのイベントとユーザーには複数のプロパティが関連付けられているため、イベントと同様に、必要なものだけをキャプチャし、小さく始めることをお勧めします。

一貫性を確立し、シンプルに保つ

データ品質の問題の主な原因は、一貫性のない命名規則です。 あるチームがイベントを「Song Played」としてキャプチャし、別のチームが同じイベントを「Song_Played」としてキャプチャしている場合があります。 これにより、アナリストは多くのデータを変更したり、さらに悪いことに不完全なレポートを作成したりします。

イベントとプロパティの命名規則に同意し、分析追跡の定義と計測に関係するすべての人に明確になるようにします (または、Amplitude などのツールを使用して簡単に適用します)。

命名規則に加えて、イベントのフレームワーク (「オブジェクト-アクション」など) を決定します。 最初にオブジェクト (「曲」など) を選択し、次にそのオブジェクトに対してユーザーが実行するアクション (「再生済み」、「一時停止」など) を定義して、「再生済みの曲」や「一時停止中の曲」などのイベントを作成します。 最後に、時制について合意します (例: 「Song Played」または「Song Play」)。

イベントをキャプチャする場所を決定する

分析の追跡に関しては選択肢があり、ビジネスと分析のニーズに合った最適な組み合わせを決定するには、長所と短所を理解することが重要です。 多くの企業は、クライアント側のイベントのみをキャプチャし、サーバー側のイベント キャプチャを利用しないという制限を設けています。

サーバーでイベントを収集する方が信頼性が高いため、ミッション クリティカルなイベントを常にサーバーでキャプチャすることをお勧めします。 サーバー側の追跡は、ユーザーに関する情報 (IP アドレス、ユーザー エージェント、リファラー、UTM パラメーターなど) へのアクセスが少ないため多少制限されますが、信頼性と回復力ははるかに高くなります。

クライアント側の追跡は、より豊富な情報を可能にし、イベントがどのように発生したかのコンテキストが必要なイベントをキャプチャする必要がある場所です (たとえば、最初のページ ビューの場合、UTM パラメータとリファラーをキャプチャして、訪問がどこから来たかを理解する必要があります)。 . ただし、ITP や ETP などの広告ブロッカーやブラウザーの制限により、クライアント側の追跡が制限される可能性があるため、豊富さと信頼性の最適な組み合わせを見つける必要があることに注意してください.

開発環境と本番環境を分けておく

これは単純明快ですが、企業が開発環境から分析の宛先にデータを送信しているのを今でも目にします。 運用データを汚さず、環境を分離してください。

追跡計画を実施する

多くのチームは、分析追跡を後付けとして扱い、他のコードと同じプラクティスを適用していません。 これは当然、ダウンストリームで修正しなければならない分析バグ、またはさらに悪いことに、まったく発見されない分析バグにつながります。 多くのチームがそのようにしてデータに対する信頼を失っているのを見てきました。信頼が失われると、元に戻すのは困難です!

それを軽減するには、分析追跡を検証して実施することが重要です。 仕様に従ってデータを検証するさまざまな方法を概説する包括的なガイドを作成しました。

要約すると、追跡を実施するにはいくつかの方法があり、それらは通常 2 つのカテゴリのいずれかに分類されます: 事後対応型または事前対応型のアプローチで、追跡計画または分析スキーマをクライアント、パイプライン、および送信先で実施できます (通常はデータ ウェアハウスまたは分析の宛先)。 ソースで品質の問題に対処することを常にお勧めします。つまり、インストルメンテーションが最初に仕様と一致することを確認し、ユニット テストと CI/CD の一部としてそれを検証します。

所有者を割り当てる

追跡計画の明確な所有者を持つことが重要です。 追跡計画を最新の状態に保つには、説明責任が必要です。 別のブログ投稿では、その所有者となる可能性のある人物と、分析追跡に関するプロセスを構築する方法について詳しく説明します。

テイクアウト？ 製品チームが追跡計画の所有者になるのが最適であると考えており、新しい製品のリリースごとにイベント追跡が確実に行われるように、分析追跡の明確なプロセスを用意することをお勧めします。 これは、イベント追跡の明確なプロセスを定義し、適切なツールとトレーニングを提供して製品チームに責任を持たせることを意味します。

すべてを文書化する

最新のドキュメントの重要性はいくら強調してもしすぎることはありません。 それがなければ、分析の追跡は簡単に面倒になり、チームはリリース プロセスの一部として追跡を含めることを忘れ始め、データを信頼できないという負のスパイラルが始まります。

手動の文書化は面倒で忘れがちですが、少なくとも次のことを文書化することを強くお勧めします。

• 分析追跡ガイドライン:イベントの分類とフレームワーク、新しいイベントを定義する方法、誰が何を担当するか、関連リソースへのリンクなど、プロセス全体の概要。
• 追跡計画:イベントとプロパティの実際のリスト (説明を含む)。いつから、誰が所有者であるかを追跡します。
• インストルメンテーション プロセス: 新しいイベントを確実に実装する方法に関するプロセス ドキュメントを、Jira チケット レベル、インストルメンテーション、テスト、検証などに関する要件に至るまで含めます。

多くの企業は、Google スプレッドシート、Notion、または Confluence ページを使用してこれらのドキュメントを管理しています。 Amplitude のデータ ガバナンス機能を使用すると、それがすべて自動的に行われ、会社全体が分析に関して確実に同期されます。

振幅のベスト プラクティスを理解する

Amplitude は、データ チーム、プロダクト マネージャー、およびエンジニアが、分析追跡の定義、計測、検証、およびコラボレーションを支援します。 一貫性のないイベント名や追跡の欠落から生じるデータ品質の問題を積極的に解決し、追跡の進化を管理するためのワークフローを提供します。

チームが分析トラッキングを最初から正しく行えるようにすることで、チームがすぐに使用できる高品質のデータを確実に取得できるようにします。 会社で Amplitude を試すことに興味がある場合は、今すぐアカウントを作成するか、当社のチームでデモを予約して詳細を確認してください。