Suggérer des imports de données

Cette skill aide à identifier quand les données dont l'utilisateur a besoin se trouvent en dehors de PostHog et les guide vers leur import via l'entrepôt de données. L'insight clé est de reconnaître le manque — puis de le connecter au bon type de source.

Ce que PostHog collecte nativement

PostHog collecte les événements d'analyse produit, les persons, les sessions et les groupes via ses SDKs. Des produits supplémentaires sont disponibles mais doivent être activés : session replay, feature flags, expériences, sondages, web analytics, error tracking, LLM analytics, conversations, logs, revenue analytics, workflows, destinations CDP et batch exports. PostHog ne collecte pas les données métier externes comme les paiements, les abonnements, les enregistrements CRM, les tickets de support d'autres systèmes ou les tables de base de données de production — ces données doivent être importées via l'entrepôt de données.

Quand utiliser cette skill

• Une requête HogQL échoue parce qu'une table n'existe pas
• L'utilisateur pose des questions sur des données d'un système externe (Stripe, Hubspot, Salesforce, etc.)
• L'utilisateur veut corréler l'analytics PostHog avec des données métier (revenus, tickets de support, enregistrements CRM, etc.)
• L'utilisateur demande « comment importer mes données X dans PostHog ? »
• L'analyse nécessite de joindre les événements PostHog avec des données externes
• L'utilisateur demande comment exporter les données PostHog pour les comparer ailleurs (dans un Google Sheet, un entrepôt externe, etc.)

Workflow

1. Comprendre les données manquantes

Écoutez les signaux indiquant que l'utilisateur a besoin de données externes :

• Il mentionne un outil ou un système spécifique (Stripe, Hubspot, Zendesk, sa base de données de production, etc.)
• Une requête référence une table qui n'existe pas dans PostHog
• Il veut analyser quelque chose que PostHog ne suit pas nativement (revenus, tickets de support, deals CRM, etc.)

Si une requête a échoué, vérifiez l'erreur — si c'est « table not found » ou similaire, les données doivent probablement être importées.

2. Vérifier ce qui est déjà connecté

Appelez posthog:external-data-sources-list pour voir les sources existantes. Les données sont peut-être déjà importées mais l'utilisateur ne connaît pas le nom de la table ou le préfixe.

Si une source existe pour le système dont il parle, appelez posthog:external-data-schemas-list pour afficher les tables disponibles. Les données s'y trouvent peut-être sous un nom ou un préfixe différent.

Appelez aussi posthog:read-data-warehouse-schema pour voir toutes les tables interrogeables — les données sont peut-être déjà disponibles en tant que vue ou table jointe.

3. Identifier le bon type de source

Si les données ne sont pas encore importées, appelez posthog:external-data-sources-wizard pour voir les types de sources disponibles. Faites correspondre le besoin de l'utilisateur à une source :

Patterns courants :

4. Suggérer l'import

Présentez la recommandation de façon concise :

• Quel type de source connecter
• Quelles tables deviendraient disponibles
• Comment cela permet l'analyse qu'ils veulent

Exemple : « Vos données Stripe ne sont pas encore dans PostHog. Si vous connectez une source Stripe, vous obtiendrez des tables comme charges, subscriptions et customers que vous pouvez joindre avec les événements PostHog pour analyser le revenu par comportement utilisateur. »

5. Proposer de configurer la source

Si l'utilisateur veut continuer, déléguez à la skill setting-up-a-data-warehouse-source — elle couvre tout le workflow en trois étapes (wizard → db-schema → create), la sélection du type de sync, l'enregistrement des webhooks et les conseils de préfixe. Ne dupliquez pas ce workflow ici.

6. Montrer ce qui est possible après l'import

Une fois connectée, aidez l'utilisateur à écrire sa première requête joignant les données PostHog avec les données importées. Utilisez posthog:execute-sql pour démontrer.

Patterns de jointure courants :

• Joindre les clients Stripe avec les persons PostHog sur l'email : SELECT * FROM stripe_customers sc JOIN persons p ON sc.email = p.properties.$email
• Joindre les deals CRM avec les événements : corréler l'usage produit avec les résultats commerciaux
• Joindre les tickets de support avec les session recordings : trouver les recordings des utilisateurs qui ont créé des tickets

Points importants

• Ne devinez pas les noms de table. Vérifiez toujours posthog:read-data-warehouse-schema et posthog:external-data-schemas-list avant de dire que les données n'existent pas.
• Vérifiez les préfixes. Les tables importées ont souvent un préfixe (ex. stripe_charges et non charges). L'utilisateur pourrait ne pas connaître le préfixe.
• Les sources OAuth nécessitent l'UI. Certaines sources (Google Ads, Meta Ads, Hubspot avec OAuth) nécessitent des flux OAuth basés sur navigateur. Vous ne pouvez pas les compléter via MCP — dirigez l'utilisateur vers l'UI PostHog à /data-warehouse/new.
• Tous les systèmes ne sont pas supportés. Si le système de l'utilisateur n'est pas dans la liste du wizard, suggérez d'utiliser Postgres/MySQL comme passerelle s'ils peuvent exporter vers une base de données, ou mentionnez que des sources personnalisées peuvent être demandées.

Outils associés

• posthog:external-data-sources-list : Vérifier les connexions de sources existantes
• posthog:external-data-schemas-list : Vérifier les tables déjà importées
• posthog:read-data-warehouse-schema : Voir toutes les tables interrogeables y compris les vues
• posthog:external-data-sources-wizard : Obtenir les types de sources disponibles
• posthog:execute-sql : Exécuter les requêtes pour démontrer ce qui est possible

Skills associées

• setting-up-a-data-warehouse-source : Workflow complet de création de source — déléguez ici une fois que l'utilisateur décide de connecter une source