Un prompt peut-il remplacer Amplitude ?

Construis un outil d’analytics d’événements borné, mono-produit — pas une plateforme d’analytics généraliste. Utilise un SDK navigateur léger (un petit snippet JS) qui envoie des événements personnalisés nommés avec des propriétés arbitraires vers ton propre point d’ingestion. Utilise ClickHouse (vraiment bien adapté ici — le stockage columnaire rend les requêtes de funnel et de rétention rapides même à volume modéré) ou Postgres si tu préfères garder une seule base de données, avec Next.js/TypeScript pour l’API d’ingestion et le tableau de bord. Ingère les événements de façon idempotente (déduplique par un identifiant d’événement généré côté client) et filtre le trafic de bots évident par motif de user-agent ; ne fais pas de fingerprinting d’appareil au-delà d’un identifiant anonyme first-party basé sur cookie. Construis trois vues de tableau de bord à partir de la table brute d’événements : un constructeur de funnel (choisis une séquence ordonnée de noms d’événements, vois la conversion entre chaque étape), un graphique de rétention (pourcentage d’une cohorte qui revient au jour N), et un découpage simple par propriété d’événement (par exemple, compte d’événements d’achat groupés par une propriété de plan). Ajoute un export brut des événements et un point de suppression de données pour un identifiant anonyme donné, pour que ce soit vraiment respectueux de la vie privée plutôt qu’une simple surveillance à plus petite échelle. Ne construis pas de graphe d’identité entre appareils, de relecture de session, ni de couche BI/entrepôt généraliste — c’est hors périmètre ; ceci suit les événements d’un produit pour une équipe, rien de plus large. Nécessite un hébergement et une base de données (ClickHouse ou Postgres) ; aucune clé API externe requise.