分析追跡を継続的な共同プロセスに変える方法

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

デジタル製品やサービスを構築する組織がデータを収集することは誰もが知っています。 また、データを収集するだけでは、実際にそれを効果的に使用することにはならないこともわかっています。 強力なツールキットに支えられた優れた追跡計画が整っていたとしても、コラボレーションという 1 つの重要なことに時間を割かなければ、戦略は失敗します。

分析は、データ主導の企業の全員に影響を与えます

製品の新しい機能を構築することを考えてください。 ここでは主に 2 つの考慮事項があります。この機能によってどのような新しいデータ ポイントがもたらされるのか、そしてそれらのデータ ポイントの対象者は誰なのかということです。 本当にデータドリブンな意思決定をしたいのであれば、多かれ少なかれ誰もが顧客データの聴衆になるでしょう.

分析の追跡に関与する主要な利害関係者はすべて、独自のアイデアと専門知識をストーリーにもたらします。これは、ドメインの知識と技術的ノウハウの健全な組み合わせです。 私たちは持っている：

• 幹部/リーダーシップ
• プロダクトマネージャー
• アナリスト/データ チーム
• 開発者

これらの各チームには、独自の異なるタスクと目標がありますが、最終的には同じ追跡計画に基づいて作業します。

ヒント: 料理人が多すぎると悪夢になる可能性があります。この投稿を読んで、追跡計画を誰が所有すべきかについて学んでください。

これらのチームが分析に関して互いにどのように協力するか (すべきか)。

幹部/リーダーシップ

イベント追跡の最も高いレベルのビューを必要とするチームから始めましょう。 新しい機能を構築するとき、エグゼクティブは、この新しい機能の目標が何であるか、および成功を測定するためにどのメトリックが使用されるかを最も気にします.

つまり、リーダーシップの下で働くチームは、質の高い報告を行うための準備を整える必要があります。 優れたリーダーシップ チームは、直感に基づいて会社の将来について重要な決定を下すことを望まないでしょう。

このチームの主な共同行動:

• リーダーシップは、組織全体のコラボレーションを促進するために最大限の努力を払い、データ主導の意思決定の価値を理解する文化を育む必要があります。
• データに基づいた意思決定から生まれた成功を祝いましょう。
• マネージャーが優れた分析追跡を気にかけないのであれば、なぜあなたが気にする必要があるのでしょうか? ‍

プロダクトマネージャー

プロダクト マネージャーは、製品を熟知しており、市場や業界での位置付けを熟知しています。 彼らはこの新機能を出荷する責任があり、そのため、リーダーシップが気にかけている指標を、彼らが追跡したい実際のイベントに変えようとしています. この新機能に関する信頼性の高いレポートを作成するには、最初からイベント トラッキングを組み込む必要があります。

プロダクト マネージャーは多くの分野の専門知識を備えていますが、追跡計画を自分で定義するために必要な技術的スキルを持っていない場合があります。 これは、仕事を成し遂げるために他のチームと協力しなければならないことを意味します。 優れたプロダクト マネージャーは、追跡したいイベントのリストを指示する可能性は低く、そこから完璧なレポートが得られることを期待しています。 代わりに、アナリストや開発者が追跡計画を実装し、レポートを作成するチームであるため、アナリストや開発者と何が可能かについて話し合い、同意する場合があります。

そのため、プロダクト マネージャーはどの指標が重要かを知っていますが、それらを追跡可能なイベントに変換するために他の人に頼る可能性があります。 彼らは、データについて適切な質問をしたり、A/B テストをいつ行うかを決定したり、適切なフィードバック ループを作成したりするのに役立ちます。つまり、以前の決定のパフォーマンスを見て、それらを反復します。

このチームの主な共同行動:

• 追跡されているイベントとその理由についてアナリストと定期的にチェックインし、分類法と命名規則について全員が同じページにいるようにします
• 開発者と協力して、追跡計画のどの変更を実装する必要があるか、インフラストラクチャを考慮してそれらの変更が可能かどうか、および変更にかかる時間を決定します。
• 高品質のレポートで経営陣にフィードバックを提供するようにする

アナリスト

データ アナリストのチームは、レポート作成のための会社の中心的なハブのようなものです。 生データを最初に手に入れるのはおそらく彼らだけです（おそらく唯一の人です）。 データの結合、モデル化、および視覚化に取り組みます。 それらは、データを洞察に変えるのに役立ちます。

アナリスト チームに関する重要な注意事項: アナリスト チームは組織のリソース、つまり、データ関連の何かが必要な場合に「質問する人」と見なされるべきではありません。 この場合、アナリストは、実際に洞察を構築して意味のあるレポートを生成するのではなく、他のチームからの毎日の要求を満たすために自分の能力が占有されていることに気付く可能性があります。

アナリストの共同プロセスの一部は、他のチームが可能な限りセルフサービスできるようにすることです。 この基本的な例は、プロダクト マネージャーやマーケティング担当者と協力して、定義済みのクエリを Tableau などのツールに組み込み、ボタンをクリックするだけで最もよく聞かれる質問に回答できるようにすることです。 製品およびマーケティング チームは、Amplitude のようなセルフサービスのデジタル分析プラットフォームを使用して、独自にグラフを作成し、顧客の行動を分析することもできます。

このチームの主な共同行動:

• プロダクト マネージャーと協力して、データの背後にいる人々について理解を深める: エンド ユーザーについてあまり知らなくても抽象的なデータを扱うことができますが、このデータが重要である理由をより深く理解していれば、より効果的になります。
• データについて尋ねるのに最も役立つ質問は何か、他のチームが追跡したいものは何かについて、やりがいのある会話を促進する (たとえば、チームが必要以上のデータを収集するよう求めている場合に、いつプッシュバックするかを知る)

開発者

もちろん、実際に製品を構築しているのは開発者であり、追跡計画を実装しています。 技術的に言えば、ソフトウェア エンジニアは、自分が従事している業界やエンド ユーザーの行動について多くのことを知っている必要はありません。 これは一律に当てはまるわけではなく、開発者は分析を気にしないという思い込みにつながっています。

実際には、システム化されたコラボレーション プロセスが整っていない場合、エンジニアリング チームは有意義な方法で分析に乗り出すのに苦労する可能性があります。 新しい機能を構築するときに、追跡するイベントのスプレッドシートを受け取ると、ワークフローが大幅に中断されるため、イライラすることがあります。 IDE、スプレッドシート、Jira チケットの間を行き来するのは面倒で、エラーや不一致が非常に簡単に発生します。

優れた開発者は、自分が構築した製品がどのように機能するかを気にする可能性がはるかに高く、製品が実際にどのように機能するかを誰よりもよく知っているため、追跡計画を最も効果的な方法で実装するのに最適です。

このチームの主な共同行動:

• 製品マネージャーが、製品のインフラストラクチャの制限、追跡が適切な時期と場所、および実装にかかる時間を確実に理解するようにする
• アナリストと緊密に連携してデータと分析のパイプラインを構築し、すべてが意図したとおりに進んでいることを確認する
• イベントを効果的に追跡するには、後付けではなく、最初から追跡機能を機能に組み込む時間が必要であることを他のすべてのチームが理解できるようにします。

分析追跡に関するコラボレーションの促進

チームが分析追跡でどのように協力できるかについてこのように広く理解することで、コラボレーション プロセスの開発を開始しやすくなるはずです。 全員が同じ製品の構築と保守に取り組んでいる場合、チーム間のコミュニケーションが非常に重要になることは明らかです。

製品のバックエンドにおける重要な設計ポイントとして、分析について考え始めます。 これは、機能を出荷した後に追加するだけのものではなく、SDLC の不可欠な部分です。

多くの企業、特にテクノロジー業界では、Jira、Slack、そしてもちろん Amplitude などのコラボレーションおよび知識共有ツールの使用にすでに慣れています。 組織でより強力なコラボレーション プロセスを採用することに情熱を傾けている場合は、積極的にケースを作成することをお勧めします。 多くの場合、新しいプロセスへの同意を得ることが最も難しい部分です。

車輪を再発明する必要はありません。 すでに機能している既存のプロセスを適用します。

多くの場合、新しいプロセスの採用 (分析に関する効果的なコラボレーションなど) は、テクノロジーとはほとんど関係なく、すべてが文化と関係があります。 分析に関して言えば、知識は 1 人の人やチームに存在するわけではありません。データを最大限に活用するには、全員が協力する必要があります。

要点がわからない限り、誰も新しいプロセスを採用しないことに注意することが重要です (それがどんなに優れていても)。 実際には、新しいプロセスに全社的な同意を得る優れた方法は、既存の他のプロセスと比較して、そのプロセスの価値を実証することです。 いくつかの例:

GitHub:ソフトウェアを構築しているほぼすべての人/企業/組織が GitHub を使用していると言っても過言ではないと思います。 これは非常にエレガントですが、ハードコーディングされたプロセスです。記述されたすべてのコードは、ブランチ、コミット、およびマージの対象となります。 したがって、Github は実際にはツールというよりもプロセスに似ています。誰もが使用しなければ機能しません。

Figma:シームレスなチーム間のコラボレーションを完全に実証するツール。 Figma を使用すると、製品デザイナーは、すべての要素がどのように組み合わされているかを明確に示すプロトタイプを開発者に引き渡すことができます。 ヒント: Figma で Amplitude Event Planner を使用します。

Amplitude はコラボレーションを支援します

Amplitude のデータ ガバナンス機能は、分析用の GitHub と考えると便利です。 Amplitude は、技術的能力に関係なく、すべての主要な利害関係者が関与できるイベント計画に関する透過的で監査可能なプロセスを促進します。

最適なプロセスとは、気付かないプロセスです。当社には開発者向けのツールが用意されているため、誰のワークフローも中断されず、エンジニアはタイプ セーフでオープンソースの SDK、CLI、および CI/CD を使用して分析追跡を簡単かつ正確に実装できます。統合。

Amplitude は何よりもまず共同プラットフォームであり、分析のための信頼できる信頼できる情報源を強化します。 これは、データを消費する人が、データを信頼できることを知っていることを意味します。 新しいコラボレーション プロセスに大きな賛同を得た場合、Amplitude は確かにそれをサポートする役割を果たします。 無料のデモをリクエストして、今すぐ探索を開始してください。