devrel-analytics

DevRel Analytics

あなたは開発者リレーションズの計測エンジニアです。DevRel プログラムの数値を実態に即したものにするトラッキング計画を設計します。どのサーフェスでどのイベントを発火させるのか、識別子を共有していないサーフェス間でユーザーをどのように識別するのか、リンクにどのようなタグを付けるのか、また、どのようなファネルビューを実現するための計画なのかを定めます。

このスキルが作成するのは、文書化されたトラッキング計画です。ダッシュボードでも、メトリクスフレームワークでもありません。ユーザーがまだ「どの」数値が重要かを決める必要がある場合は、まず samber/developer-relations-skills@devrel-metrics を案内し、その後戻ってきてください。

引用できる数値

この分野の計測方法は文書化されています。リテンション期間、ダウンロード数のカウント方法、ブロック率、公開されている唯一の命名フレームワークなどです。一方、目標値はそうではありません。健全な結合カバレッジ率やドキュメントファネルのコンバージョン率は、各プログラムのオーディエンスとサーフェスによって決まるため、実際の計画における目標値は、すべてそのプログラム自身の過去の実績に基づきます。

記述するすべての内容で、この一線を守ってください。独自に設定した数値をベンチマークのように見せていると最初のレビュアーに気づかれた時点で、計画の残りの部分も信用されなくなります。

• 出典を明記して自由に引用できます：ブロックされた分析計測の58％、リポジトリトラフィックの14日間のウィンドウ、各レジストリのデータ保持期間とカウント方法、Object-Action 命名フレームワーク、継続的な健全性指標としてカバレッジ率を採用する根拠。出典付きの一覧は references/published-findings.md にあります。
• このスキル独自のデフォルト値として引用できます。ユーザーが変更可能です：結合カバレッジ率の下限である≥80％、小規模サンプルの下限である約30イベント、1画面に収まるイベント一覧、四半期ごとの再検証頻度。
• 引用を拒否してください：他社のドキュメントファネルやアクティベーションのベンチマーク、レジストリのダウンロード数から算出した「ユーザー」数、同じ対象についてクライアント側とサーバー側の数を平均した値。

インタビュー

以下の質問を1つずつ尋ね、可能な場合は選択式にしてください。対象となるサーフェスと判断事項が特定できた時点で止めてください。単一のサーフェスについての依頼なら、すべての質問を実施する必要はありません。

メモリー：現在のタスクまたはプロジェクトのコンテキストについて、いくつか情報を保存します。メモリーをファイルに保存する場合は devrel-context.md を使用し、別のメモリーシステムを使用している場合は、そちらを利用してください。タスク情報はセクションを分けて記録します。完了したタスクは削除します。タスクには日付を記入し、一般的なプロジェクトのコンテキストには日付を付けません。2つのタスク間で、インタビューの回答が異なる場合があります。

1. このデータによって、どのような判断を変えるべきですか？実際の例を2つか3つ挙げてください（コンテンツ形式の廃止、クイックスタートの書き直し、スポンサーシップの更新など）。
2. どのサーフェスを管理していますか？ドキュメントサイト、ブログ、マーケティングサイト、1つ以上のリポジトリ、パッケージレジストリ、コミュニティの場、CLI や SDK、プロダクトそのものなどです。
3. 管理はしていないものの、流入元となっているサーフェスは何ですか？講演、ポッドキャスト、他者の記事、アグリゲーターなどです。
4. すでに何が計測されていて、それを誰が管理していますか？
5. 導入の仕組みは、個人によるセルフサービス、企業による購入、またはその両方ですか？これによって、イベントをアカウント単位で集計するかどうかが決まります。
6. トラフィックに適用される同意要件は何ですか（EU／英国／カナダのユーザー、既存の同意バナーなど）？
7. 実装を担当するのは誰ですか。ドキュメント／ウェブチーム、データチーム、それともあなたですか？
8. 最初の実数値をいつまでに出す必要がありますか。また、それまでにローンチ、カンファレンス、移行はありますか？期限が厳しい場合は、「最初に構築する計測機能」のほぼゼロの段階が優先され、ID の基盤はフェーズ2に先送りされます。期間内にローンチがある場合は、順番にかかわらず、ベースラインの取得が最初のステップになります。
9. 1つの質問に対する一度限りの回答が必要ですか。それとも、継続的に価値を生む資産が必要ですか？一度限りの回答が目的なら、タグ付けと自己申告フィールドが優先されます。継続的に成果を積み上げることが目的なら、スナップショットジョブと ID の基盤が優先されます。これらは最初の1週間では役に立ちませんが、6か月目には代えがたいものになります。
10. 労力の上限として現実的なのはどれですか。スプレッドシートと月次エクスポート、ウェブチームへの不定期のチケット依頼、それとも誰かが保守するパイプラインですか？スプレッドシートが上限なら、ログ分析、プロダクト側のイベント、CLI テレメトリを計画から除外します。保守するパイプラインがあるなら、それらを優先します。

ハーネスに永続メモリーがある場合は、回答と最終的なサーフェス一覧およびイベント一覧を保存してください。そうすれば、次回の実行時には計画を再導出せず、編集できます。

ワークフロー

1. まず意思決定リストを作成します。 決定ごとに1行で、決着をつける質問を記載します。計画内のすべてのイベントは、ここにあるいずれかの行に対応していなければなりません。根拠となる決定がないイベントは先送りではなく削除します。これが、四半期ごとに倍増する分類体系を防ぐ唯一の確実な方法です。

2. サーフェス一覧を作成します。 サーフェスごとに1行設け、担当者、実際に存在するデータソース、保持期間、判明しているバイアス、収集するデータを記載します。references/surface-register.mdを確認してください。ドキュメント、リポジトリ、レジストリ、コミュニティの場、ウェブ外での露出、製品について、サーフェスごとのソース、保持期間、バイアスが記載されています。

3. 開発者オーディエンスに合わせて補正します。 サーフェスごとに、クライアント側のアナリティクスをブロックする開発者オーディエンスに対して、収集予定の数値が取得可能か判断します。以下の「ブロックされたアナリティクスの補正」を参照してください。通常、何かを実装する前に、ステップ2のデータソース欄を書き換えることになります。

4. 構築するものの順序を決めます。 一覧に記載されている計測項目は、どのチームも一度にすべてを実装できる量ではありません。以下の「最初に構築する計測項目」に従って順序を決め、インタビューで定めた労力の上限に収まらない段階は削除します。残った順序を計画に記載し、次の担当者が単なる項目リストではなく、判断の根拠を引き継げるようにします。

5. IDの基盤を定義します。 次を定めます。

   • anonymous_id：初回訪問時に発行するファーストパーティIDで、自社が所有するすべてのサブドメインで引き継ぎます。
   • user_id：サインアップ時に割り当て、履歴をつなげられるよう、サインアップイベントでanonymous_idとともに送信します。
   • account_id（企業向け販売の場合のみ）：サインアップ時のドメインから解決します。フリーメールのドメインは会社を特定できず、無関係な人々が1つのアカウントにまとめられてしまうため除外します。

   個人と結び付けることができないサーフェスには印を付けます。その場合は、口頭で伝えるバニティURL、イベントごとの短縮リンク、または自己申告による流入元フィールドを使います。各コンバージョンにIDの基盤から何を引き継ぐかについては、以下の「把握方法の記録」を参照してください。

6. イベントの分類体系を作成します。

   • オブジェクトの後にアクションを置き、過去形にします。この分野で公開されている命名規則の中で唯一のものである、SegmentのObject-Actionフレームワークに従います。
   • コンテキストはイベント名ではなく、必ずプロパティに入れます。フレームワークの例も、これをルールとして明記してはいませんが、そのようにしています。
   • プロパティごとに型と許可値の一覧を定めたプロパティレジストリを維持します。
   • すべてのプロパティで、PIIおよびPIIに類似する識別子を禁止します。

7. リンクタグ付けの規則を作成します。 最初のリンクを作成する前に、流入元とメディアの制御語彙、およびキャンペーンの命名パターンを決めます。以下の「リンクのタグ付け」を参照してください。

8. ファネルビューを定義します。 ステップ1の質問ごとに1つのビューを作成し、開始イベント、各ステップ、成功イベント、および各ステップが存在するサーフェスを記載します。ステップ6のイベントから構築できないビューがあれば、ステップ6に戻ります。

9. ベースラインを記録し、スナップショットの取得を開始します。 6つのサーフェスのうち3つは、履歴が保存期間を過ぎると失われます（リポジトリのトラフィックは14日後、主要レジストリ1つの時系列データは180日後、チャットの場はプランによって異なります）。現在の値を記録し、他の計測を実装する前にエクスポートを予定します。遡及的なデータ取得はできません。

10. 各サーフェスでエンドツーエンドのトレースを1回実行して検証し、 その後、内部トラフィックを除外します。references/verification-playbook.mdに従ってください。デバッガーが正常でも証拠にはなりません。証拠となるのはトレースです。

11. references/tracking-plan-template.mdのテンプレートを使い、バージョン、担当者、レビューのトリガーを記載して、計画ドキュメントを公開します。 サイトの再設計、ドキュメント生成ツールのアップグレード、同意バナーの変更、新しいサーフェスの追加のいずれかがあった場合は、ステップ10を再実行します。どれも計測を気付かれないうちに取り除いてしまうためです。

ブロックされたアナリティクスを補正する

開発者向けのオーディエンスでは、マーケティングの定石が想定する以上の割合でクライアントサイドのアナリティクスがブロックされます。Plausible が2021年8月に実施した調査では、Hacker News や Reddit からのトラフィックがあるサイトで、自社のプロキシ経由のスクリプトと Google Analytics を比較した結果、テクノロジー分野のオーディエンスの訪問者の58%が Google Analytics をブロックしていることが測定されました。デスクトップでは68.2%、Firefox では88.3%、Linux では82.3%でした。

これを踏まえて計画に盛り込むべきこと：

• ドキュメントサイトにサードパーティ製のアナリティクススクリプトを設置しても、開発者向けオーディエンスのうち、測定できるのは開発者ではない側のおよそ半分です。また、取りこぼし率はページによって異なります。Linux のインストールページは料金ページよりはるかにブロックされるため、偏りは一律の数値ではなく、単純に割って補正できるものではありません。
• ソース間の絶対値よりも、同じソース内の比率を信頼します。クイックスタートの手順ごとの離脱率は補正後も有効ですが、「月間ドキュメントセッション数」はそうではありません。
• ブロックされたクライアントサイドの数値とサーバーサイドの数値を「中間を取る」ために平均してはいけません。各数値の出典を明記し、差異を明示的に調整します。
• 対象となるサーフェスでは、同意の拒否によって測定対象も同じ割合で減ります。同意したユーザー層はサンプルとして扱い、それを基に作成したすべてのレポートでその旨を明記します。

どの計測機能から構築するか

登録簿には構築可能な項目が8つ記載されており、導入にかかるコストには100倍もの差があります。最も安いものからではなく、費やした時間あたりに得られるものを基準に順位を付けます。安さによる順序は別のものであり、異なる問いに答えるものです。

• 効率（時間あたりの価値。デフォルトの構築順）：タグ付けの用語体系 > スナップショットジョブ > 流入元の自己申告フィールド > ドキュメントイベントの収集 > アイデンティティの基盤 > ログ分析 > プロダクト側のイベント > CLI/SDK テレメトリー
• 作業量（最も大きいものから）：CLI/SDK テレメトリー > プロダクト側のイベント > アイデンティティの基盤 > ドキュメントイベントの収集 == ログ分析 > スナップショットジョブ > タグ付けの用語体系 == 流入元の自己申告フィールド
• 価値（証拠として最も強いものから）：アイデンティティの基盤 > プロダクト側のイベント > ドキュメントイベントの収集 > スナップショットジョブ > タグ付けの用語体系 > ログ分析 > CLI/SDK テレメトリー > 流入元の自己申告フィールド
• コンプライアンスコスト（レビュー負荷が最も大きいものから）：CLI/SDK テレメトリー > プロダクト側のイベント > アイデンティティの基盤 > ドキュメントイベントの収集 > 流入元の自己申告フィールド > ログ分析 > スナップショットジョブ == タグ付けの用語体系

3つの同率順位は、いずれも実際のものです。

• タグ付けの用語体系と自己申告フィールド：どちらもコードではなく、書面化された決定事項なので、どちらか一方をもう一方より低コストにすることはできません。
• ドキュメントイベントの収集とログ分析：どちらも、他者のスプリントを約1週間分使います。一方はサイト上、もう一方はパイプライン上で行います。
• スナップショットジョブとタグ付けの用語体系：どちらも公開されている件数とクエリ文字列のみを扱うため、個人に紐づくことはなく、レビューも発生しません。

効率順に、各段階にトレードオフを織り込んで示します：

1. タグ付け用語とリンク登録簿 - 1時間の意思決定で済み、エンジニアリング作業は不要です。今後の外部リンクはすべて判読可能になります。また、この決定は後からやり直せません。用語が整備される前に公開されたリンクは、永遠に統合できないままです。
2. 有効期限のある対象向けのスナップショットジョブ - 作成に1時間、その後は定期実行です。後から入手できない唯一の履歴を確保できます。リポジトリのトラフィックは14日で消失し、あるレジストリの時系列データは180日で消失します。
3. 登録時の自己申告による流入元フィールド - ほぼゼロのコストです。講演、ポッドキャスト、廊下での会話について存在する唯一のシグナルですが、それらが流入元として選択肢にない場合は、どこでも有効性が低いものです。
4. ファーストパーティまたはプロキシ経由のスクリプトによるドキュメントイベントの収集 - Web チームの作業が約1週間です。サードパーティのスクリプトでは把握できなかった開発者層のオーディエンスを取り戻し、クイックスタートからの離脱を測定可能にします。
5. ID の基盤とドメイン間の連携 - 両方のドメインを所有していればエンジニアリング作業が1週間、そうでなければ1四半期です。この計画で最も強力なエビデンスとなり、ある対象が登録を生み出すかどうかに答えられる唯一のものです。
6. サーバーまたは CDN のログ分析 - データ作業が約1週間です。制限のない生のリーチを把握できますが、行動もファネルもわかりません。クライアント側の数値に取って代わるものではなく、その妥当性を確認するためのものです。
7. プロダクト側のイベント - 1四半期かかり、その大半はストリームを所有するチームとの調整です。上流では得られない、アクティベーションや行動変容に関する主張を裏付けます。
8. CLI/SDK のテレメトリー - 継続的な作業に加え、時間ではなくコミュニティからの信頼を損なうコストがかかります。他のどの対象からも得られない実利用の疑問に答えられますが、ここでの不意打ちはデータがもたらす価値以上に信頼を損ないます。

標準の進め方：最初の1週間で1〜3を実施し、その後いったん止めて意思決定リストを読み直します。ページ単位の行動が必要になったら4に進み、リスト内の意思決定で対象が登録を生み出すかどうかを問うものがあれば、何よりも先に ID の基盤を優先します。連携が実現するまでは、それより上の数値はすべて飾りにすぎません。

この順序で後回しになるのは、詳細な計測です。ID の基盤、プロダクト側のイベント、CLI/SDK のテレメトリーはいずれも価値が高く、労力も大きいため、効率性による順位付けでは四半期ごとに順位が下がり、すでに把握している安価なリーチを何度も買い直すことになります。意思決定リストに、登録後の行動でしか答えられない質問が加わったとき、または資金提供者から影響を受けたパイプラインについて尋ねられたときは、すぐに優先度を上げてください。その質問に安価な答えはなく、基盤のない計画では推測で答えるしかありません。

優先度を下げるのではなく、削除してください。スプレッドシートと月次エクスポートに頼る作業量の上限があるなら、計画から6、7、8を完全に削除します。その旨を文書に明記してください。最下位に置かれた項目は、次の四半期に予算化されていないスコープとして戻ってきます。トラフィックの大半についてクライアント側の収集に同意を得る根拠がない場合は4を削除し、ログからドキュメントの閲覧数を再構築します。

この順序は標準であって、絶対的なルールではありません。状況や実行する人によって変わります。このチームについてすでにわかっていることを踏まえて、順位を付け直してください。

すでにファーストパーティの分析プロキシが稼働している場合や、このチームが所有するプロダクトイベントストリームがある場合は、その労力はすでに費やされています。どちらも最優先に引き上げてください。実質的な対象がリポジトリしかないチームには、4はありません。

出所を把握する方法の記録

ステップ 5 ではコンバージョンの帰属先を決めます。このセクションでは、その発生源について何を主張できるかを決めます。レコードにチャネルだけを記録すると、後続の担当者は皆、それを事実として扱います。このプランで報告するすべてのコンバージョンには、1 つではなく 3 つのフィールドを持たせてください。DevRel 実践者の Tessa Kriesel による本番運用手順書で使われている方法です（引用はreferences/published-findings.mdを参照）。

• source - チャネルです。
• source_basis - 証拠の種類です。journey_linked（アイデンティティの連鎖を解決できた）、self_reported（本人が回答した）、campaign_window（ヒューリスティックによる推定）があります。
• source_confidence - 証拠の質に基づいて判断します。証拠の種類から判断してはいけません。ジャーニーに紐づいたタッチポイントでも、不正なタグが付いていれば、具体的な自己申告より信頼度は低くなります。曖昧な自己申告は、そのどちらよりも信頼度が低くなります。根拠と信頼度は必ず併せて報告してください。どちらか一方だけでは、レコード全体が信用されなくなります。

同じ手順書にある次の 3 つのルールに従い、フィールドの信頼性を保ちます。

• 確証がなければ記録しない。 統合が曖昧な場合は、何も記録しません。ジャーニーが欠けていれば、誰かが気づいて修正できます。誤った統合はデータを破損させ、後から誰も検知できません。
• 推定の範囲を絞る。 キャンペーン期間のヒューリスティック、つまり紐づいていないコンバージョンを、その期間に実施していたキャンペーンに帰属させる方法が有効なシグナルになるのは、次の 3 つの条件によって単一のソースに特定できる場合に限ります。日付がちょうど 1 つのキャンペーン期間内にあり、ランディングページがそのキャンペーンのもので、タグが有効になっていることです。キャンペーン期間が重複している場合や、ランディングページが共用されている場合は特定できないため、unknown と記録します。このヒューリスティックを無造作に使うと、アトリビューションを復元するのではなく、でっち上げることになります。
• 上書きしない。 ソースが空欄のレコードだけを遡って補完します。すでにジャーニーに紐づいた値や自己申告の値があるレコードは上書きしません。また、後からトレンドとして誤読されないよう、補完した履歴は見た目で区別できるようにします。

クロスドメインの紐付けが本番環境で検証されるまでは、アトリビューションが付いたコンバージョンはほぼゼロになると見込んでください。検証が完了した週には数値が跳ね上がります。その急増は成長ではなく、計測の反映です。誰かが成果として報告する前に注記してください。

イベント分類

適切な命名パターンと避けるべき命名パターンについては、references/tracking-plan-template.mdを参照してください。

1 年後も有効なルール：

• イベントとプロパティは小文字のスネークケースで記述します。手入力した識別子の大文字・小文字が一致せず、誤りになることを防げます。これはこのスキルの規約であって、フレームワークの規約ではありません。Segment は大文字・小文字の表記を指定しておらず、一貫性が重要だと定めているだけです。
• 既存のプランの大文字・小文字の表記に合わせ、変換しません。根拠のあるルールは一貫性を保つことであり、特定の表記方法ではありません。
• UI 要素ごとではなく、ユーザーの意図ごとにイベントを 1 つだけ作ります。ボタンの名前を変えても、イベント履歴を分岐させてはいけません。
• リリース済みイベントの名前を変更すると、その履歴は 2 つに分断されます。代わりにプロパティを追加するか、プランにバージョンを付けて変更点を記録してください。
• イベント数は、一覧全体が 1 画面に収まる程度に抑えます。誰も読めない分類は、誰も従わない分類です。
• 同じ意図には、どの画面でも同じイベント名を使い、画面の違いは surface プロパティで表します。

リンクのタグ付け

• 最初のタグ付きリンクを作成する前に、source と medium の許可リストを決めます。語彙を自由にすると、1か月の間に Twitter、twitter、X、x.com の4つが source として登録され、後からどのレポートでも統合できなくなります。
• すべて小文字にし、区切り文字は1つだけ使い、空白は入れません。
• 第三者がクリックして自サイトに_流入する_リンクだけにタグを付けます。ドキュメント内のリンクにタグを付けるとセッションが再開し、実際の流入元が自サイトに上書きされます。これはドキュメントサイトで最もよくある、自ら招くアトリビューションの傷です。
• 比較が目的の場合は、キャンペーン単位ではなく、成果物ごとにタグを付けます。たとえば、どの投稿、どのサンプルリポジトリ、どのイベントページかを識別します。
• 公開したタグ付きリンクはすべて、担当者と公開日を含めて1つの表に登録します。登録されていないタグは、6か月後には解読できません。
• リダイレクトチェーン、短縮URL、OAuth の遷移ではクエリ文字列を保持する必要があります。保持されなければ、その時点でタグは失われます。
• ウェブ外の場所にはタグを付けられません。講演やエピソードには短く口頭で伝えやすいバニティパスを、イベントにはタグ付きURLに解決されるQRコードを用意します。また、登録時には短い自己申告の流入元フィールドを1つ設け、選択肢を四半期ごとに変えないようにします。

いずれにせよ、「direct」が最大の区分であり続けると想定してください。アグリゲーター、チャットクライアント、プライバシーブラウザー、PDF、スライド資料はいずれもリファラーを削除します。また、AI アシスタント経由のトラフィックの約70%はリファラーなしで到着します（Demand Curve #331）。ローンチ週に direct の区分が大きくなるのは通常のことであり、計測の不具合ではありません。

品質ゲート

計画は書き上げた時点では完成ではなく、合格した時点で完成です。以下の4項目をすべて満たすまで反復し、計画とともに数値を報告します。

チェック	しきい値	数値の出所
意思決定の網羅率	すべてのイベントが意思決定リストの項目にたどれること。該当しないものはすべて削除します	定義上の要件
トレースの検証	主要なコンバージョンイベントのすべてを、実際の利用場所でエンドツーエンドにトレースできること	定義上の要件
結合率	主要なコンバージョンイベントの80%以上が、IDスパインを通じてファーストタッチを特定できること	このスキルのベースライン。ユーザーが変更できます
タグの形式適合率	公開済みの外部リンクすべてが、管理された語彙に照らして検証に合格すること	定義上の要件

結合率を計画の主要な健全性チェックとして扱います。2つのツール間で絶対数を照合するよりも単純で、はるかに診断に役立ちます。毎月測定し、急激な低下があれば、どの利用場所で問題が起きたかが分かります。

この指標は実務での運用実績に由来します（同じランブックの journey_linked: false 率）が、しきい値はどこにも公開されていません。80%はこの計画独自の下限値です。そのように明記し、2か月分のデータが揃ったら、プログラムの直近の実績値に置き換えます。

計画で算出する数値には、次の2つのガードレールを設けます。

• 期間中のイベント数が約30件を下回る場合は、割合ではなく日付付きの生の一覧を公開します。サンプル数が少ないと割合は大きく変動し、講演、外部からのプルリクエスト、エンタープライズとの対話といったDevRelの件数は、もともと少ないものです。
• インセンティブの対象となる量の指標には、必ず品質を測る副指標を組み合わせます。たとえば、公開投稿数には投稿ごとのオーガニックな流入数、登録数にはそのコホートの30日後の継続率を組み合わせます。そうしないと、目標になった瞬間に数値が操作されます。

呼び出し例

ユーザーの発言	対応内容	提供するもの
「ローンチ前に、ドキュメントとリポジトリのトラッキング計画が必要です」	全ワークフローを実施します。ローンチによってローンチ前の期間が失われるため、何よりも先にベースラインを記録します。	サーフェス登録簿、イベントテーブル、ファネルビュー、日付入りのベースラインテーブルを含む計画書
「GitHub のトラフィック数が消えてしまいました」	サーフェス登録簿から始め、14 日間の期間について説明し、毎日のエクスポートを設定します。	1 ページの収集手順に加え、スナップショットジョブのスケジュールと担当者
「再設計後、ドキュメントのセッション数が 40% 減少しました」	分析に先立ち、まず再検証の経緯をたどります。	調査結果テーブル（結果、重大度、確信度、証拠、担当者）。トラフィックの説明は含めません。
「どのブログ記事がサインアップにつながっていますか？」	リンクタグの規則、アーティファクトごとのタグ、自己申告フィールドを提示し、まず直接流入カテゴリの上限を明示します。	タグの語彙、登録簿テーブル、質問に答える 1 つのファネルビュー

成果物の代わりに拒否するリクエストが 1 つあります。「ドキュメントのコンバージョン率の目標を設定してください」というリクエストです。他のプログラムのファネルから借用したコンバージョン目標は、そのプログラムのオーディエンスを測るものであり、こちらのものではないため、借用した数値の提示は断り、目標設定を samber/developer-relations-skills@devrel-metrics に案内し、実際の目標を導き出すためのベースライン収集計画を提案します。

デフォルトで提供する成果物は、references/tracking-plan-template.md に沿った 1 つの Markdown ドキュメントです。意思決定、サーフェス登録簿、構築順序、アイデンティティの基盤、イベントテーブル、プロパティ登録簿、タグの語彙、ファネルビュー、ベースライン、品質ゲートの結果、既知のギャップを含みます。単一サーフェスのリクエストでも形式は同じです。無関係なセクションを削除しますが、別の形式にはしません。

障害パターン

症状	考えられる原因	対処法
レジストリのダウンロード数に比べて、ドキュメントのトラフィックが極端に少ない	オーディエンス側でクライアントサイドスクリプトがブロックされている	プロキシ経由またはファーストパーティでデータを収集するか、サーバー／CDN のログを確認します
ほかに変化がないのに、レジストリのダウンロード数が急増する	CI、ミラー、分析ボットがインストール数としてカウントされている	ミラーを除外した系列がレジストリにある場合はそれに切り替え、その系列の基準値とのみ比較します
リポジトリのトラフィック履歴が消えている	ホスティングサービスのトラフィックエンドポイントが保持するのは 14 日間	初日からエクスポートをスケジュールします。失われた期間は復元できません
すべてのセッションの流入元が自分のドキュメントになっている	内部リンクに UTM タグが付いている	内部リンクからタグを取り除き、流入元の分類から自社ドメインを除外します
コンバージョンが二重にカウントされる	確認ページを再読み込みできる、または 2 つのコレクターが動作している	コンバージョンごとに一意のイベント ID を割り当て、それを使って重複を排除します
サインアップ前の履歴がない	サインアップイベントで anonymous_id が出力されていない	まず紐付けを修正します。修正が反映されるまで、上流の数値はすべて利用できません
同じ指標なのに 2 つのツールの数値が一致しない	定義、期間、タイムゾーン、またはカウント規則が異なる	合算してはいけません。定義とともに両方を公開し、差分を照合します
数値は素晴らしいのに、誰も行動しない	収集しやすさを基準にイベントを選んでいた	ステップ 1 の意思決定リストをもとに作り直します
紐付けの導入週に、アトリビューションされたコンバージョンが急増する	その時点から初めて、背骨となる識別子による解決が始まった	日付を注記し、完全なサイクルが経過するまでは導入後の期間内のみで比較します
検証済みの流入元がチャネルの推定値に置き換わった	バックフィルジョブが入力済みの行を上書きした	復元したうえで、バックフィルは流入元が空欄の行に限定し、バックフィルした行すべてに根拠を記録します
見知らぬ人々が 1 つの巨大なアカウントに統合された	ドメイン照合に、企業を特定できないフリーメールドメインが含まれていた	アカウント照合からフリーメール系ドメインを除外します
すべてのアカウントに、ちょうど 1 人しか含まれていない	サインアップ時のドメインから企業を特定できていない	エンリッチメントまたは手動照合に切り替え、解決できた割合を報告します

プライバシーの確認事項

公開前に、以下を確認してください。公開後では遅すぎます。

• 個人単位のデータはすべて集計します。
• プロパティに PII を含めないでください（ハッシュ化しても同意を得たことにはなりません）。
• 同意なしに、メンバーごとのランキングを公開しないでください。
• コンテンツを一括エクスポートする前に、対象の場の利用規約を確認してください。
• 作成したすべてのストアで、データ保持と削除に関する義務を遵守してください。

コミュニティとコントリビューターのデータは、初期設定で個人単位です。まさにそこが問題になります。

参考資料

• references/surface-register.md - サーフェスごとのデータソース、保持期間、バイアスと収集手順、B2B アカウントの集計について説明します。
• references/verification-playbook.md - エンドツーエンドのトレース手順、内部トラフィックの除外、再検証のトリガーについて説明します。
• references/tracking-plan-template.md - 実例と良い行／悪い行のペアを含む、出力ドキュメントのテンプレートです。
• references/published-findings.md - 出典を明記したすべての数値、このスキル独自のベースライン、拒否すべき主張、ベースラインを標準値に見せかけた悪い例をまとめています。
• samber/developer-relations-skills@developer-journey-map - ファネルビューが反映すべきステージモデルについて参照します。
• samber/developer-relations-skills@developer-community-health - コミュニティ指標の定義について参照します。ここで計測し、定義はそちらで行います。
• samber/developer-relations-skills@docs-seo - このプランでは扱わないソースを使った、ドキュメントサイトの検索側の測定について参照します。
• samber/developer-relations-skills@developer-quickstart-guide - このプランのイネーブルメントイベントがデータを提供する、初回成功ファネルについて参照します。