イベント トラッキングをリリース プロセスの一部にする方法

公開: 2022-12-13

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


新しい機能や製品を構築するとき、分析を最後の最後まで放置するか、完全に忘れてしまうことさえよくあります。 このシナリオはおなじみかもしれません。

  • PM はリリースに取り組んでいます
  • リリースが発生
  • CEO が PM に業績の状況を尋ねる
  • PM: データ チームに聞いてみましょう
  • データ チーム: あなたは私たちを持ち込んだことはありません。この機能に関するデータはありません
  • PM は回答なしで CEO に戻る
  • データチームとPMは取り乱している

このような状況は非常に頻繁に発生する可能性があり、これは誰の責任でもないことを覚えておくことが非常に重要です。 その多くは文化に帰着する可能性があります。

問題の重要な部分として「文化」を指摘するのは簡単に思えるかもしれません。なぜなら、文化は定義が難しいからです。 しかし、組織の価値観や目標が、チーム メンバーの行動に完全に反映されていないことがよくあります。 例えば:

あなたの組織は、ユーザーに最高のサービスを提供するためにデータ駆動型の決定を行うと主張しています。 そのための優れた基盤は堅実なデータ戦略であることは誰もが理解しています。そうでなければ、意思決定を下すための信頼できる洞察を生み出すことはできません。

しかし、実際には、データとインサイトの戦略について (またはそれらを組み合わせて) 会話することはないようです。 タスクは押しのけられて忘れ去られ、信頼できる分析が実現することはめったにありません。

これは、組織の価値観と実際の日常の文化との間にギャップがあるために発生します。このギャップに陥りやすいのです。 多くの場合、チームは、実際にデータをキャプチャするための優れたプラクティスを構築するよりも、データから洞察を得ることに重点を置いています。 優れたデータ文化を維持するのは難しい!

このような文化を構築することは、単なる誇大宣伝や祝賀劇以上のものです。 この投稿では、シンプルで実施可能なプロセスから始めることが、意図したデータ文化を維持するのにどのように役立つかについて、実践的なアドバイスを提供します。 高品質のデータを取得し、それを有用で実用的な洞察に変えて、適切な意思決定につなげることに重点を置いています。

分析をソフトウェア開発ライフサイクルに統合する

エンジニアリング チームが製品の一部を構築する作業に取りかかるとき、彼らはコードを記述し、ブランチ、コミット、テスト、レビュー、マージなどの通常の作業を行います。 これは、全員がビルドについて同じページにいることを確認し、間違いを簡単に修正できるようにするためです。

分析を同じように扱わない理由はありません。 すでになんらかの追跡計画を立てている可能性があります (そうでない場合は、これを開始する方法についてのガイドを用意しています)。実装を開始するには、他のチケットと同様に、Jira チケットに分割することをお勧めします。サブタスク。 どんなに素晴らしい追跡計画も、実行されなければ意味がありません。 次のことを考慮しない限り、重要な洞察を逃し続けるでしょう。

  • 関連する利害関係者やリーダーシップ チームから、分析の追跡が構築中の機能と同じくらい重要であることに同意する必要があります。
  • 追跡計画を実装するタスクは、ビルドの他のすべてのタスクと並んで優先順位を付ける必要があります
  • 追跡がない場合は、ビルドをリリースする準備ができていません

一連の Jira チケットに記載されているからといって、それが実現するとは限らないことは誰もが知っています。 ここで、文化の変化が実際に出てきます。機能が出荷されたという事実だけでなく、機能の成功を祝うことにより、追跡計画がソフトウェア開発ライフサイクルの一部になるようにします。 結局のところ、あなたの会社がデジタル製品を生産しているのであれば、出荷機能がすべてのポイントです。 機能がうまく機能しているのを見てお祝いをしましょう。

機能がどのように実行されているかを理解する唯一の真の方法は、分析を収集することです。追跡計画が最初のビルドから直接実装されていれば、もちろん分析を収集することになります。

分析のコンテキストでの QA に関する注意:適切なツールと文化を使用して追跡計画を実装するのは簡単ですが、これが、Amplitude が CI と統合され、ユニット テスト プラグインを使用して既存のテストに分析カバレッジを追加できる理由です。

分析追跡のための反復可能なプロセスを確立する

git プロセスがうまく機能するもう 1 つの理由は、誰もが一貫してそれに従っているため、会社の文化に自然に組み込まれていることです。 日常のワークフローの一部となる分析追跡に関するプロセスを簡単に構築できます。

新しいプロセスを導入する際の最大の敵は、賛同を得られないことです。 「これが現在の分析方法です」とだけ言って、全員が参加することを期待することはできません。 私たちは常に、分析の追跡は協力的であると主張してきました。 追跡計画をまとめるときは、関連するすべてのチームが計画の策定に関与する必要があります。

つまり、新しいプロセスを考え出す際には、製品チーム、データ/アナリスト チーム、エンジニアリング チームなど、すべての主要な利害関係者を巻き込む必要があります。 これらのチームの独自の専門知識は、次の決定に役立ちます。

  • ビジネスの目標は何か
  • これらの目標が達成されているかどうかを判断するために使用する指標
  • イベントに使用する命名規則、およびその他の分類法。 (たとえば、'songPlayed' または 'song_played' ですか? これについての詳細は、ベスト プラクティスに関する記事を参照してください)

これらのプロセスについて一緒に合意することは、組織全体の賛同を得て、それを文化の一部にするための優れた第一歩です。 追跡計画を作成したら、誰がその所有権を取得するかを特定することが重要です。「全員」に任せてもうまくいきません。 責任を負い、それを前進させるには、その人が必要です。

これらのプロセスを他のプロセスの上に追加するのではなく、それらをこのような繰り返し可能なプロセスを組織文化に組み込みたい場合は、チームがワークフローに採用しやすいようにします。 チーム メンバーが、新しいプロセスに対応するために確立されたワークフローを中断したいと思うことはまずありません。 代わりに、これらのプロセスが既存のプロセスにシームレスに適合する方法を確認してください。 たとえば、Amplitude を使用すると、コマンドライン インターフェイスを使用してこれを非常に簡単に行うことができます。これにより、開発者は、好みの環境を離れることなく、トラッキング プランを簡単かつ正確に計測できます。

トラッキングの目標をビジネスの目標に合わせる

アジャイル製品を構築している場合 (たとえば、構築、測定、学習フレームワークを使用)、決定を下すためにデータを使用することは間違いありません。 ただし、次の方向性を決定するときは、データから始めるのではなく、質問から始めてください。

まず、何を達成しようとしていますか? 新しい機能をまとめようとしていますか、それとも実験を実行しようとしていますか? 今四半期に一連の具体的な目標を設定しているかもしれません。 それが何であれ、データあなたのために何をすることができるかについて考えないようにしてください. 代わりに、適切な質問をする文化を構築し、それらの質問に答えるデータがあるかどうかを確認してください。 したがって、次のようなことを考えてください。

  • 概説した目標または実験の成功指標
  • これらの指標を把握するために追跡する必要があるイベント
  • 既存のインサイトに基づいてすでに実行したアクションは何ですか? それらは機能しましたか?

収集しているデータでこれらの質問に答えることができない場合は、追跡計画を微調整する必要があることを意味します. より多くのデータが常に答えであるとは限りませんが、正確なデータは間違いなく答えです。

優れたデータ カルチャーを構築するには、データ自体ではなく、データの使用方法が差別化要因であることをチームが理解できるようにする必要があります。 自然な好奇心を奨励し、内部の洞察に基づいて意思決定を行うことの影響を祝い始めます。

優れたデータと分析の文化は継続的なプロセスです

一夜にして文化を築くことはできません。 新しいプロセスの価値を実証し、その結果得られた勝利を祝うことで、望ましい文化の成長を可能にします。 「あったらいいな」という理由でデータを収集するのではなく、直感やアイデアをセンスチェックするためにデータを使用するという態度を育むようにしてください。

チーム全体でイベントの追跡を常に念頭に置いておくことは、最初は複雑である必要はありません。 おそらく、10 個以上の質問から始める必要はありません。 これらを突き止め、チーム間で繰り返し、そこから作業を進めます。 最初からすべての不測の事態に合わせて最適化する必要はありません。

このブログ投稿で概説されているアドバイスは、出発点に過ぎません。 これで良いリズムに乗ると、確立したプロセスがチームの第二の性質であることに気付くでしょう。 コードを書く場合と同様に、追跡分析はより標準化され、監査可能な方法になります。

Amplitude を使用すると、このプロセスが非常に簡単になります。追跡計画は、チームのワークフローにシームレスに統合される動的ドキュメントとして存在します。 会社で Amplitude を試すことに興味がある場合は、今すぐアカウントを作成するか、当社のチームでデモを予約して詳細を確認してください。

セルフサービスのデモ