トラッキングプランを実際に所有するのは誰ですか?

公開: 2022-12-22

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

「データはチームスポーツです」は、私たちが強く信じており、Amplitude でよく話していることです。分析追跡計画も例外ではありません。追跡計画 (およびその計装) は本質的に共同作業です。関連するチームが集まったときに最も効果的です。

新機能リリースの例を見てみましょう。製品チームは、この新機能の目標と指標を定義しており、これらの指標を測定するために必要なイベントトラッキングを把握しています。 iOS、Android、および Web 開発チームは、コード内のこれらのイベントをインストルメント化 (および理想的にはテスト) する責任があり、何が実現可能かについて意見を持っています。アナリストまたは分析エンジニアは、データのモデル化を担当し、その構造に注意を払います。また、レポートの作成と複数のツールでのデータの分析を担当するチームが複数ある場合があります。要するに、データ主導の企業では、分析にはほぼ全員が関与します。

この例は、分析追跡が実際にいかに複雑であるかを示しています。また、適切なイベントを定義してキャプチャし、それらを正確に実装して、データコンシューマーがデータを簡単に探索できるようにする際のコラボレーションの重要性も示しています。とはいえ、非常に多くの人が関与しているため、分析追跡は簡単にホットポテトになります.

誰もが所有している場合、それは誰にも所有されていません

多くの利害関係者が関与するため、追跡計画は明確な所有者なしで共同責任になることがよくあります。そして、責任の共有には説明責任がほとんどありません。

私たちは、分析追跡に関するプロセスを (再) 作成したいと考えている多くの企業と話をしてきました。通常、スプレッドシートまたは Confluence または Notion ページを中心に展開します。ほとんどが手動であり、追跡計画をコードで強制する方法はありませんが、最初は役に立ち、チームはイベント追跡についてもっと考える必要があります。

ただし、数か月後、Notion ページまたは Google スプレッドシートは時代遅れになります。最新リリースの追跡は Jira ストーリーにのみ記載されており、他のいくつかの機能リリースについては、追跡が実装されているかどうかが不明です。追跡計画を最新の状態に保つ責任を負っている人は誰もいません。

では、これをどのように改善し、分析トラッキングを所有するのに最も適しているのは誰でしょうか?

分析を最前線の中心に置くことから始めます

所有権の問題に飛び込む前に、分析追跡の成功に必要な基盤について言及する必要があります。イベント追跡は重要であり、それがなければ、暗闇の中に取り残されてしまいます. 現実には、ほとんどのチームにとって分析は後付けです。以下は、常に目にする例です。

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

分析がすべてのリリースの不可欠な部分にならない場合、これは何度も何度も発生し、追跡計画が本当に洗練されていて最新のように見えるかどうかは問題ではありません. すべての利害関係者 (およびリーダーシップチーム) から、分析追跡が機能自体と同じくらい重要であることに同意する必要があります。 追跡なし、リリースなし。

関連するチームに力を与えるには、明確な説明責任、時間、およびリソースが必要です。次に、イベントトラッキングと成功指標を Jira チケットレベルに埋め込む必要があります (これは、トラッキングコードが残りのコードと共に出荷された場合にのみ行われます)。

データと製品の専門家への 400 件以上のインタビューから学んだこと

2 年間で、400 人を超えるプロダクトマネージャー、データチーム、エンジニアにインタビューしました。私たちはいくつかのことを見てきました。

もちろん、追跡計画とそれに関連するプロセスは、ビジネス、チーム構造、および垂直方向に固有のものです (それがおそらく、正しく行うのが非常に難しい理由です)。 e コマース企業の追跡計画は、B2B SaaS 企業の追跡計画とは大きく異なります。彼らはさまざまな利害関係者を巻き込み、まったく別の現実を解決します。最も一般的には、これまで見てきたことを会社の規模で分類できます。

スタートアップ

小規模な会社の場合、追跡に関するプロセスは通常その場しのぎです。関与する人が非常に少なく、複雑さを管理しやすくするのは当然のことです。ほとんどの場合、製品の責任者または成長の責任者が、会社のジャーニーのこの段階で所有権を取得します。

中小企業

中規模の企業では、プロセスは通常、データ/分析の責任者になります。現在、より多くの利害関係者が関与しており、複雑さが容易に問題になる可能性があります。この段階では、損害を制限するために所有権が明確に必要であり、通常、それはデータチームの誰かに委ねられます。

企業

大企業では、追跡計画を最終的に所有するのは通常、製品分析の責任者です。 e コマース企業の場合、e コマースの責任者になることがよくあります。多くの場合、彼らは計画を維持したり、プロセスを実施したりする実際の日常的な人物ではなく、責任を負うのはチーム内の誰かです。

これらのタイプのセットアップからさまざまな程度の成功を見てきました。では、何が最も効果的だと思いますか?

機能: 製品チームが最終的な所有者

これが私たちが知っていることです。製品チームが最終的な所有者として行動するときに、最良の所有権プロセスが発生します。 プロダクトマネージャーが主な推進役となり、分析の追跡がすべての機能リリースの一部であることを確認する必要があります。 チームの規模に応じて、これは 1 人以上のプロダクトマネージャーまたは専任のプロダクトアナリストになる可能性があります。彼らは、その役割と OKR の一環として、分析追跡の責任を負う必要があります。

しかし、前述したように、データはチームスポーツであり、チームが集まってイベントの命名や分類法などを定義することをお勧めします。エンジニアとデータチームは、日常業務にも影響を与えるため、重要な視点を持つことになります。製品チームは執行者であり、最終的な所有者ですが、サイロで作業したり、適切な利害関係者を関与させずに重要な決定を下したりしてはなりません。

関連するすべての利害関係者を代表する諮問委員会を設置することは、私たちが協力してきた企業にとってうまく機能しています。すべての決定が諮問委員会に委ねられるわけではありませんが、最初は諮問委員会が推進役となり、分類法とプロセスを定義し、時間の経過とともに発生する重大な変更の数に応じて定期的に会議を行う必要があります。

製品チームがこれをうまく所有するには、明確なプロセスが整っている必要があります。

すべてのユーザーストーリーの一部として、定性的指標と定量的指標の両方について明確な成功基準を用意します。 これらは PM が定義し、データチームまたはアナリストと協議する必要があります。
追跡がありませんか？ ビルドに失敗します。 完了の概念は、すべてのリリースの一部として分析追跡を含めるように進化する必要があります。これは、発売直前にリリースをブロックするという意味ではなく、最初から追跡の考慮事項を含むプロセスを実装することを意味します。
コラボレーションが重要です。 PM がイベントトラッキングの仕様を所有しますが、データチームまたはアナリストが介入して、トラッキング対象の詳細を定義できるようにする必要があります。

プロダクトマネージャーに責任を持たせる権限を与える

一部の PM にとって、追跡計画を所有することは彼らにとって自然なことです。彼らはコントロールを望み、経験を持っています。また、必要なときに助けを求めることを恐れません。しかし、それはすべての PM にとって自然なことではありません。

まず、文化の変化が必要です。出荷されたという事実ではなく、新しい機能や製品のリリースのパフォーマンスと成功を祝いましょう。驚いたことに、多くの人にとって、製品が機能しているかどうかではなく、依然として出荷が賞賛されています.

では、製品チームが追跡計画を所有できるようにするにはどうすればよいでしょうか? これは完全なリストではありませんが、人々が始めるための場所になることを願っています:

定期的なトレーニング: イベントトラッキングを正しく行うことは、科学であると同時に芸術でもあります (つまり、簡単ではありません)。 トレーニングは、ランチ & ラーニングスタイル、ワークショップ、または 1 対 1 のセッションです (将来の雇用のためにセッションを記録することを忘れないでください)。
オフィスアワー: データチームが他のチームのために定期的なオフィスアワーを主催し、データチームの専門知識と知識を活用することで大きな成功を収めています。チームが「サポートデスクスタイル」の会議にならないように、議題や具体的な質問を準備しておきましょう。
明確なプロセスとチェックポイント:定義されたプロセスの重要性はいくら強調してもしすぎることはありません。 ソフトウェア開発におけるコードレビューやマージリクエストと同じように、誰もが知っていて、理解し、従う明確なプロセスがあることを確認し、品質を確保するための定期的なレビューポイントを含めます。
アナリストを組み込む : もちろん、これは常にオプションであるとは限りませんが、成功しているチームでは、データアナリストを製品チームにパートタイムまたはフルタイムで組み込み、分析の追跡を担当し、PM のデータ探索と分析を支援しています。
セルフサービス分析: PM や組織内の他の全員がデータセットを簡単に探索し、質問への回答を迅速に取得できるようにすることがベストプラクティスであると考えています。 Amplitude はその点で優れており、会社全体で高レベルのデータリテラシーを保証します。

注意: 優れた PM は SQL を知る必要はありません

とにかく自分でデータを探索できないのに、なぜイベントトラッキングを気にする必要があるのでしょうか。上記の最後の点をさらに詳しく説明すると、すべてのレポートとデータ分析を担当する中央データチームを持つ企業を見てきました。これには長所がありますが、私たちの経験からすると、PM などを制限する可能性があり、分析の追跡やデータの品質をあまり気にしなくなります。

PM や他のユーザーに Redash やその他の SQL ベースのツールへのアクセスを許可することは、PM にセルフサービスを提供することと同じではないことに注意してください。 PM が SQL を知っている (または学習する) ことを期待しないでください。それは彼らの仕事ではありません。代わりに、使いやすい UI と、ツールとデータセットに沿った多くのトレーニングを提供して、彼らに力を与えてください。もちろん、SQL の知識には明らかな利点があり、会社全体 (製品、マーケティング、顧客の成功などを考えてください) の才能を見つけたり訓練したりできれば、それを機能させることができますが、明らかな欠点と制限があります。

PM がセルフサービスで対応できる場合、たとえば最近のリリースからデータを探索する可能性が高くなります。彼らはデータを探索するとき、その品質、豊富さ、可用性に関心を持つ可能性が高くなります。エンパワーメントの文化を築き、分析追跡に関する堅固なプロセスを構築すれば、幸せな PM、幸せなアナリスト、幸せなデータチーム、さらには幸せな開発者を手に入れることができます。

振幅はあなたを助けるためにここにいます

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

製品マネージャーが追跡計画の所有権を取得し、チーム間のコラボレーションをレベルアップできるようにします。 会社で Amplitude を試すことに興味がある場合は、今すぐアカウントを作成するか、当社のチームでデモを予約して詳細を確認してください。

トラッキング プランを実際に所有するのは誰ですか?