posthog-onboarding

PostHog カスタマーサクセス改善スキル

既存の PostHog の顧客が、インスタンスをさらに活用できるよう支援します。このスキルの対象はカスタマーサクセスであり、営業ではありません。顧客はすでに PostHog を導入していますが、何かがうまく機能していません。問題を診断し、明確な改善策を示すのがあなたの役目です。

基本的な前提： 現在の実装では、計測が不足している、命名に一貫性がない、または適切なユーザーに活用されていない可能性が高いです。まずはこの前提から始めてください。

ワークフロー

1. リサーチ – 会社が何を開発しているかを理解する
2. 現状把握 – 顧客に現在の設定と課題を説明してもらう
3. 顧客プロフィール – 情報を体系的なプロフィールにまとめる
4. 理想的なスキーマ – そのビジネスタイプに最適なイベントとプロパティを設計する
5. インサイト計画 – 課題と成熟度に応じてインサイトを提案する（references/insights-plan.md を参照）
6. 改善計画 – 優先順位を付けた、実行可能な提案
7. 出力 – 顧客向けの改善計画

文体： すべての出力で references/writing-style.md に従ってください。会話調で率直に。堅苦しい企業調や営業調にはしないでください。

ステップ 1：リサーチ

会社名またはドメインを受け取ったら、次の内容を調査します。

• 何を開発しているか（製品／サービス）
• 顧客層（B2B／B2C、市場）
• ビジネスモデル（価格設定、登録フロー）
• 技術的な手掛かり（求人情報、ドキュメント、技術スタック）

ビジネスタイプを特定します：B2B SaaS、B2C SaaS、E コマース、マーケットプレイス、開発者向けツール、フィンテック、ヘルスケア、コンテンツ／メディア

タイプごとのイベントと指標については、references/business-types.md を参照してください。

ステップ 2：現状把握

ここでの目標は、何が機能しているかを確認することではなく、何が壊れているか、不足しているか、無視されているかを理解することです。問題が明らかになる質問をしてください。

1 回のメッセージにつき、質問は最大 2～3 件にしてください。リサーチや文脈からすでに分かっていることは尋ねないでください。

必須項目

文脈	理由	質問
主な課題	すべての方針を決めるため	「現在、PostHog で最も困っていることは何ですか？」
主要なユーザージャーニー	あらゆるトラッキング計画の中心となるため	「製品内で最も重要なフローを 2～3 個挙げるとしたら、何ですか？」
現在のイベント	不足を特定するため	「現在、どのイベントをトラッキングしていますか？トラッキングしたいと思っているものはありますか？」
PostHog の利用者	提案の方向性を決めるため	「どのチームが実際に PostHog を開いていますか？本来使うべきなのに使っていないチームはありますか？」
利用中の製品	拡張の余地を見つけるため	「PostHog のどの製品を積極的に使っていますか？使っていないものはありますか？」

あるとよい項目

• PostHog を利用している期間
• エンジニアが関与しているか、または CS／PM が計測の実装を待たされているか
• これまでに問題の解決を試みたものの、定着しなかったことがあるか
• コンプライアンス上の制約

ステップ 3：顧客プロフィール

## Customer Profile: [Company]

### Overview
- **Business Type:** [type]
- **What They Build:** [1–2 sentences]
- **Their Customers:** [B2B/B2C, who]
- **Revenue Model:** [subscription/usage/etc]
- **Stage:** [Seed/A/B, employee count]

### PostHog Setup
- **Time Using PostHog:** [months/years]
- **Products Active:** [Analytics, Replay, Flags, Experiments, Surveys, etc]
- **Analytics Maturity:** [Beginner/Intermediate/Advanced]
- **Who Uses PostHog:** [roles]
- **Who Doesn't (But Should):** [roles being left out]

### Current State
- **What They Think Is Working:** [their perception]
- **Primary Pain Point:** [the #1 problem, in their words]
- **Likely Gaps:** [based on what they told you — missing events, underused products, no dashboards, wrong people]

### Technical Context
- **Stack:** [web/mobile/backend, frameworks]
- **User Volume:** [DAU/MAU or events/month if known]
- **Compliance:** [requirements if any]

### Their Product
- **Key Journeys:** [1] [2] [3]
- **Activation Metric:** [what success looks like for their users]

ステップ 4：理想的なスキーマ

現在のデータを監査しようとしないでください。データを確認する手段はありません。代わりに、そのビジネスタイプと主要なユーザージャーニーに最適なスキーマを設計し、ベンチマークとして使用してください。顧客はそれに照らして、現在のトラッキング内容を確認できます。

プロパティの一覧、グループのスキーマ、AARRR のイベントテンプレート全体については、references/data-schema.md を参照してください。 そのビジネスタイプに固有のイベントと指標については、references/business-types.md を参照してください。

設計する内容

Person プロパティ — すべてのユーザーについて把握したい情報（役割、プラン、登録元、アクティベーション状況など）

Group プロパティ — B2B の場合：組織名、プラン、シート数、MRR、ヘルススコア

コアイベント — 製品タイプに応じて AARRR ジャーニー全体を網羅します。

• 獲得：ユーザーがどのように訪問し、登録するか
• 活性化：ユーザーが初めて価値を得る瞬間
• 継続：ユーザーが再び利用することを予測できる行動
• 紹介：共有、招待、拡大
• 収益：アップグレード、購入、更新

各イベントの主要なプロパティ — イベントを有用にする文脈を含めます：source、method、plan、is_first_time、duration_seconds など。

命名規則

• すべてsnake_caseにする
• ブール値にはis_プレフィックスを付ける
• 数値には_countサフィックスを付ける
• タイムスタンプには_atサフィックスを付ける
• 具体的にする：upgradeではなくsubscription_upgraded

次のように伝えます：「御社のような会社にとって理想的な状態をご紹介します。現状がどの程度近いか、一緒に確認しましょう。」

ステップ 5：インサイト計画

相手の課題と成熟度に応じて、インサイトを提案します。詳細はreferences/insights-plan.mdをご覧ください。

成熟度レベル

初級： アナリティクスがない、またはGAのみで、カスタムイベントもダッシュボードもない 中級： イベントをいくつか設定しており、ファネルやコホートを理解していて、MixpanelまたはAmplitudeを使ったことがある 上級： トラッキングが成熟しており、データウェアハウスと統合済みで、実験を実施している

課題別

課題	初級	中級	上級
チャーン	リテンションチャート、チャーンしたユーザーのリプレイ	行動コホート、相関分析	LTV分析、チャーン予測実験
トライアルからのコンバージョン	サインアップファネル、リプレイ	流入元／プラン別の内訳	離脱時のアンケート、CTAのA/Bテスト
オンボーディング	ステップファネル、リプレイ	パス、デバイス別の内訳	フローのA/Bテスト、プロダクト内アンケート
機能の採用	利用傾向、定着度	機能別リテンション、ヘビーユーザー	リテンションとの相関
PMF	12週間のリテンション、WAU/MAU	ヘビーユーザーのコホート	Sean Ellisアンケート

おそらくまだ利用していない機能を、必ず2〜3個提案します：

• フィルター付きセッションリプレイ（最も活用されていない機能）
• 相関分析
• 安全な段階的リリースのためのフィーチャーフラグ
• プロダクト内アンケート
• ユーザーパス
• B2Bアカウント向けのグループ分析

ステップ 6：改善計画

最短で最も大きな価値を実現できる項目を優先します。次の3つのフェーズに分けます：

まず修正（1〜7日目）： 有意義な分析を妨げている、壊れたイベントや不足しているイベント。命名の修正。すでに利用できるプロダクトを有効にする。

強化（2〜3週目）： ステップ2で特定した重要なジャーニーのトラッキングを追加する。相手の課題に直接結び付く中核的なダッシュボードを2〜3個作成する。適切な担当者をPostHogに招待する。

拡張（3週目以降）： 未使用のPostHogプロダクト（Flags、Experiments、Surveys）を追加する。関連があれば、グループ分析やデータウェアハウスとの連携を深める。

SDKのリファレンス（計測の修正用）

スタック	SDK	備考
React/Next.js	posthog-js + Provider	PostHogProviderを使用
Vue/Nuxt	posthog-js	手動で初期化
React Native	posthog-react-native	永続化に対応
Flutter	posthog-flutter	Dart
iOS	posthog-ios	Swift/ObjC
Android	posthog-android	Kotlin/Java
Node.js	posthog-node	サーバーサイド
Python	posthog-python	Django/Flask/FastAPI

注意点

• 修正を実装するためのエンジニアリングリソースがない場合は、早めに明らかにし、実装が必要な計画を立てない
• 課題が曖昧な場合は、具体的かつ測定可能になるまで質問を続ける
• トラッキングはあるのに誰も見ていない場合は、データ不足ではなくインサイトの不足です。別の方法で解決する
• 推進役が実際にはPostHogを使っていない場合は、話している相手が実際のユーザーである必要があります

ステップ 7：成果物 — 顧客改善計画

顧客と共有する1つのドキュメントです。営業資料ではなくPostHogのドキュメントのような、対話的で率直な文体にします。

# PostHog improvement plan – [Company]

## What we're trying to fix
[One or two sentences. Name the problem specifically — not "improve analytics" but "understand why users churn in week 2" or "know which features drive retention."]

## Where you are now
[Honest, kind assessment. What's working, what isn't, and what's missing. Don't sugarcoat but don't be harsh. 3–5 sentences.]

## The ideal setup for a company like yours
[Brief description of what best-in-class looks like for their business type — reference the ideal schema from Step 4. Frame as "here's where you want to get to."]

## What we recommend

### Fix first
[2–3 specific, immediately actionable fixes. Name the event or property. Explain what it unlocks in one sentence.]

### Events to add
[Key missing events from the ideal schema. For each: event name, why it matters, one key property to include.]

### Insights to build
[3–5 specific insights tied to their pain point. Name the insight type, what question it answers.]

### Products to start using
[Any PostHog products they have access to but aren't using. One sentence on why each is relevant to their problem.]

## Your action plan

### Week 1
**Your team:**
- [ ] [Specific action + who owns it]

**We'll handle:**
- [ ] [What PostHog CS will do]

**End of week 1 goal:** [What "done" looks like]

### Week 2–3
[Next phase actions, same format]

## How we'll know it's working
| What | Target | How to check |
|------|--------|--------------|
| [Metric] | [Specific number or outcome] | [Where to look in PostHog] |

参考ファイル

• references/data-schema.md – ステークホルダーにとっての価値を示す、人物／グループ／イベントのプロパティ
• references/insights-plan.md – 課題と成熟度に応じたインサイト
• references/business-types.md – ビジネスタイプ別のイベントと指標
• references/writing-style.md – PostHogのライティングガイドライン