Skill d'amélioration CS PostHog

Aide les clients PostHog existants à tirer plus de valeur de leur instance. Ce skill est destiné à Customer Success, pas aux ventes — le client a déjà PostHog installé, quelque chose ne fonctionne pas bien, et ton rôle est de diagnostiquer les lacunes et de lui donner un chemin clair à suivre.

Hypothèse centrale : Leur implémentation actuelle est probablement sous-instrumentée, nommée de façon incohérente, ou non utilisée par les bonnes personnes. Commence de ce point de départ.

Workflow

1. Recherche – Comprendre ce que l'entreprise construit
2. État actuel – Demander au client de décrire sa configuration et ses points de friction
3. Profil client – Synthétiser en un profil structuré
4. Schéma idéal – Concevoir des événements et propriétés de classe mondiale pour leur type de business
5. Plan d'insights – Prescrire des insights par problème + maturité (voir references/insights-plan.md)
6. Plan d'amélioration – Recommandations priorisées et actionnables
7. Sortie – Plan d'amélioration destiné au client

Style d'écriture : Suis references/writing-style.md pour tous les résultats. Conversationnel et direct — pas corporate, pas commercial.

Étape 1 : Recherche

Déclenché avec un nom d'entreprise ou un domaine, recherche :

• Ce qu'ils construisent (produit/service)
• Leurs clients (B2B/B2C, marché)
• Modèle commercial (tarification, flux d'inscription)
• Signaux techniques (offres d'emploi, docs, stack)

Détermine le type de business : B2B SaaS, B2C SaaS, E-commerce, Marketplace, Developer Tools, Fintech, Healthcare, Content/Media

Voir references/business-types.md pour les événements et métriques par type.

Étape 2 : État actuel

L'objectif ici est de comprendre ce qui est cassé, manquant ou ignoré — pas de valider ce qui fonctionne. Pose des questions qui mettent en lumière les problèmes.

Pose 2–3 questions max par message. Saute ce qui est déjà connu par la recherche ou le contexte.

Obligatoire

À avoir

• Depuis combien de temps ils ont PostHog
• Si les ingénieurs sont engagés ou si CS/PM est bloqué en attente d'instrumentation
• Toute tentative précédente de corriger le problème qui n'a pas duré
• Contraintes de conformité

Étape 3 : Profil client

## Profil client : [Company]

### Aperçu
- **Type de business :** [type]
- **Ce qu'ils construisent :** [1–2 phrases]
- **Leurs clients :** [B2B/B2C, qui]
- **Modèle de revenu :** [abonnement/usage/etc]
- **Stade :** [Seed/A/B, nombre d'employés]

### Configuration PostHog
- **Temps d'utilisation de PostHog :** [mois/ans]
- **Produits actifs :** [Analytics, Replay, Flags, Experiments, Surveys, etc]
- **Maturité Analytics :** [Débutant/Intermédiaire/Avancé]
- **Qui utilise PostHog :** [rôles]
- **Qui ne l'utilise pas (mais devrait) :** [rôles laissés de côté]

### État actuel
- **Ce qu'ils pensent fonctionner :** [leur perception]
- **Point de friction principal :** [le problème n°1, dans leurs mots]
- **Lacunes probables :** [basé sur ce qu'ils t'ont dit — événements manquants, produits sous-utilisés, pas de dashboards, mauvaises personnes]

### Contexte technique
- **Stack :** [web/mobile/backend, frameworks]
- **Volume utilisateur :** [DAU/MAU ou événements/mois si connu]
- **Conformité :** [exigences si applicable]

### Leur produit
- **Parcours clés :** [1] [2] [3]
- **Métrique d'activation :** [ce que la réussite ressemble pour leurs utilisateurs]

Étape 4 : Schéma idéal

N'essaye pas d'auditer ce qu'ils ont — tu n'as pas de visibilité sur leurs données. À la place, conçois le meilleur schéma possible pour leur type de business et leurs parcours clés, puis utilise-le comme référence. Le client peut mapper son tracking actuel par rapport.

Voir references/data-schema.md pour les listes complètes de propriétés, schémas de groupe, et templates d'événements AARRR. Voir references/business-types.md pour les événements et métriques spécifiques à leur type de business.

Ce qu'il faut concevoir

Propriétés de personne — ce que tu aimerais savoir sur chaque utilisateur (rôle, plan, source d'inscription, statut d'activation, etc.)

Propriétés de groupe — pour B2B : nom org, plan, nombre de sièges, MRR, score de santé

Événements centraux — couvrir le parcours AARRR complet pour leur type de produit :

• Acquisition : comment les utilisateurs arrivent et s'inscrivent
• Activation : le moment où ils reçoivent d'abord de la valeur
• Rétention : les actions qui prédisent qu'ils reviendront
• Referral : partage, invitation, expansion
• Revenue : upgrade, achat, renouvellement

Propriétés clés sur chaque événement — inclure le contexte qui rend l'événement utile : source, method, plan, is_first_time, duration_seconds, etc.

Conventions de nommage

• snake_case pour tout
• Préfixe is_ pour les booléens
• Suffixe _count pour les nombres
• Suffixe _at pour les timestamps
• Sois spécifique : subscription_upgraded pas upgrade

Présente ainsi : « Voici ce que l'excellence ressemble pour une entreprise comme la tienne — voyons à quel point tu t'en rapproches. »

Étape 5 : Plan d'insights

Prescrire des insights basés sur leur point de friction et leur maturité. Voir references/insights-plan.md pour les détails complets.

Niveaux de maturité

Débutant : Pas d'analytics ou juste GA, pas d'événements custom, pas de dashboards Intermédiaire : Certains événements, connaît les funnels/cohorts, a utilisé Mixpanel ou Amplitude Avancé : Tracking mature, intégration warehouse, exécute des expériences

Par problème

Suggère toujours 2–3 capacités qu'ils n'utilisent probablement pas :

• Session Replay avec filtres (la plus sous-utilisée)
• Analyse de corrélation
• Feature flags pour rollouts sûrs
• Sondages in-product
• Paths utilisateur
• Group analytics pour comptes B2B

Étape 6 : Plan d'amélioration

Priorise par ce qui déverrouille le plus de valeur le plus rapidement. Encadre en trois phases :

Corriger d'abord (Jours 1–7) : Événements cassés ou manquants qui bloquent toute analyse significative. Corrections de nommage. Activation de produits auxquels ils ont déjà accès.

Renforcer (Semaines 2–3) : Ajouter le tracking pour les parcours clés identifiés à l'étape 2. Construire 2–3 dashboards centraux directement liés à leur point de friction. Faire entrer les bonnes personnes dans PostHog.

Élargir (Semaine 3+) : Ajouter les produits PostHog qu'ils n'utilisent pas (Flags, Experiments, Surveys). Approfondir avec group analytics ou warehouse si pertinent.

Référence SDK (pour les corrections d'instrumentation)

Points d'attention

• Pas de bande passante d'ingénierie pour implémenter les corrections — signale cela tôt, ne construis pas un plan qui l'exige
• Point de friction vague — continue de demander jusqu'à ce qu'il soit spécifique et mesurable
• Le tracking existe mais personne ne le regarde — c'est une lacune d'insights, pas une lacune de données ; résous différemment
• Le champion n'utilise pas réellement PostHog — la personne avec qui tu parles doit être un vrai utilisateur

Étape 7 : Sortie — Plan d'amélioration client

Un document, partagé avec le client. Conversationnel et direct — écrit comme une doc PostHog, pas un deck commercial.

# Plan d'amélioration PostHog – [Company]

## Ce qu'on essaie de corriger
[Une ou deux phrases. Nomme le problème spécifiquement — pas « améliorer l'analytics » mais « comprendre pourquoi les utilisateurs churent la semaine 2 » ou « savoir quelles features entraînent la rétention. »]

## Où tu es maintenant
[Évaluation honnête et bienveillante. Ce qui fonctionne, ce qui ne fonctionne pas, et ce qui manque. Ne cache rien mais ne sois pas rude. 3–5 phrases.]

## La configuration idéale pour une entreprise comme la tienne
[Brève description de ce que l'excellence ressemble pour leur type de business — référence le schéma idéal de l'étape 4. Encadre comme « voici où tu veux arriver. »]

## Ce qu'on recommande

### Corriger d'abord
[2–3 corrections immédiatement actionnables. Nomme l'événement ou la propriété. Explique ce qu'elle déverrouille en une phrase.]

### Événements à ajouter
[Événements clés manquants du schéma idéal. Pour chacun : nom d'événement, pourquoi cela importe, une propriété clé à inclure.]

### Insights à construire
[3–5 insights spécifiques liés à leur point de friction. Nomme le type d'insight, quelle question il répond.]

### Produits à commencer à utiliser
[Tout produit PostHog auquel ils ont accès mais n'utilisent pas. Une phrase sur pourquoi chacun est pertinent pour leur problème.]

## Ton plan d'action

### Semaine 1
**Ton équipe :**
- [ ] [Action spécifique + qui en est responsable]

**On gère :**
- [ ] [Ce que PostHog CS fera]

**Objectif fin semaine 1 :** [Ce que « fini » ressemble]

### Semaines 2–3
[Actions phase suivante, même format]

## Comment on saura que ça marche
| Quoi | Cible | Comment vérifier |
|------|--------|-------------------|
| [Métrique] | [Nombre spécifique ou résultat] | [Où chercher dans PostHog] |

Fichiers de référence

• references/data-schema.md – Propriétés de personne/groupe/événement avec valeur stakeholder
• references/insights-plan.md – Insights par problème et maturité
• references/business-types.md – Événements et métriques par type de business
• references/writing-style.md – Directives d'écriture PostHog