- alice@fernwood.co identifiée · terminée 4:32
- anon-7f3a2c anonyme · expirée 1:08
- theo@fernwood.co identifiée · terminée 2:47
Données d'exemple
Analytics · Replay · Flags
Voyez ce que font vos utilisateurs. Regardez la session. Basculez le flag.
Votre stack analytics, intégré — pas greffé après coup. Analytics produit, relecture de session, feature flags et analytics web s'exécutent en quatre SDKs first-party, 1,9 à 6,6 Ko gzippés, une seule balise script chacun. Et parce qu'ils écrivent sur la même colonne vertébrale que votre revenu et vos retours, chaque événement arrive déjà relié au compte client dont il provient.
Pas de tag manager. Pas d'échantillonnage. Pas de fournisseur supplémentaire.
Chaque angle sur l'usage
Chaque lecture de la façon dont votre produit est utilisé
Analytics produit et web, first-party — capturées par votre propre SDK et reliées à la 360. Cliquez pour explorer les angles.
Analytics produit, first-party
- Événements, fonctionnalités et utilisateurs actifs depuis votre propre SDK
- Capture automatique des écrans en SPA — les paths fonctionnent sans code par route
- Par compte, relié à la 360
Données d'exemple
Funnels, pondérés par le revenu
- Chaque étape porte le MRR des comptes qu'elle contient
- Les dollars bloqués à chaque abandon, pas seulement le %
Rétention nette en dollars
- Basculez les cohortes entre utilisateurs et MRR retenu
- Le revenu qui est resté — sensible à la devise
Analytics web, en profondeur
- Pages vues, sources et campagnes UTM
- Core Web Vitals + capture automatique des clics sans balisage
- Respect de la vie privée, capture first-party
Qui, où, sur quoi
- Répartition géo, appareil, navigateur et langue
- Résolue à l'ingestion à partir de signaux first-party
Là où ils cliquent vraiment
- Heatmaps de clics par page
- Les zones mortes et les vrais CTA, rendus visibles
Analytics produit
Chaque événement arrive en sachant qui l'a envoyé.
Appelez identify() une fois, et les événements arrêtent d'être du bruit anonyme. Le même visiteur est une seule personne avant et après l'inscription — ses pages vues avant authentification et ses événements produit après authentification se réunissent sur la colonne vertébrale, rattachés au compte de l'entreprise à laquelle il appartient.
-
Événements identifiés
identify() relie les événements à de vrais utilisateurs ; les sessions anonymes se recollent à la même personne une fois connectée. Aucun code de liaison d'identité de votre côté.
-
Capture automatique sans balisage
La capture automatique universelle des clics (façon Heap) et le suivi des écrans en SPA sont actifs par défaut — les changements de route et les clics deviennent des événements sans code par élément ou par route. Désactivable par surface.
-
Tendances, funnels et paths
Tendances d'événements par fonctionnalité et par cohorte, plus funnels, rétention et product paths sur les 30 derniers jours — juste à côté du revenu que ces utilisateurs représentent.
-
Ingestion avec des garanties strictes
Ingestion par lots : jusqu'à 50 événements / 32 Ko par lot, dédupliqués par ID d'événement ; une file localStorage rejoue tout ce qu'un départ de page aurait perdu, si bien que la fin d'une session chargée n'est jamais perdue.
Funnels · Rétention · Résultats
Les dollars derrière les pourcentages.
Chaque étape de funnel et chaque cohorte de rétention porte le MRR en direct des comptes qui la composent — parce que comportement et revenu ne sont séparés que par deux sauts sur une seule fiche, pas par deux outils recollés par un export nocturne. Alors « où perdons-nous de l'argent ? » devient une requête, pas un projet d'un trimestre.
-
Les funnels, en dollars
Chaque étape affiche le MRR des comptes distincts qu'elle contient — 48 000 € entrés → 12 000 € convertis, 31 000 € de MRR bloqués à l'abandon. Les dollars se réconcilient avec votre chiffre d'affaires global : mêmes comptes, même filtre.
-
Rétention nette en dollars
Les cohortes basculent entre rétention en nombre d'utilisateurs et rétention en MRR, pour voir le revenu qui est resté — pas seulement les logos. Sensible à la devise ; jamais de mélange entre € et $.
-
Product paths et Sankey
Les vrais parcours que les utilisateurs suivent dans le produit — points de bifurcation et impasses, tracés à partir de vos propres événements, pas d'une estimation par échantillon.
-
« Cette fonctionnalité a-t-elle marché ? »
Livrez une fonctionnalité, et sa carte de tâche répond d'elle-même : adoption parmi les comptes actifs, le MRR qui a adopté, et le gain de rétention par rapport aux non-adoptants — un verdict (ça marche, mitigé, ou aucun signal), pas un tableau de bord qu'il faut aller lire.
Votre IA peut poser les mêmes questions pondérées par le revenu via MCP — analyze_funnel, get_retention, analyze_paths.
Relecture de session
Quand quelque chose casse, regardez-le casser.
Un utilisateur dit « l'export n'a pas fonctionné » — ouvrez sa session et regardez exactement ce qu'il a vu. Des enregistrements au niveau du DOM de vraies sessions, listées de la plus récente à la plus ancienne, utilisateurs identifiés et visiteurs anonymes confondus.
- ✓Le SDK principal reste à 6,6 Ko gzippés — l'enregistreur de relecture est un chunk séparé d'environ 57 Ko gz, chargé uniquement quand vous appelez
init({ replay: true }). Désactivez la relecture, et vos visiteurs ne paient jamais ces octets. - ✓Chaque session porte son cycle de vie — début, fin, durée — et les chunks sont dédupliqués à l'envoi, si bien qu'une connexion instable ne corrompt jamais un enregistrement.
- ✓Les sessions identifiées montrent qui c'était ; les anonymes reçoivent un ID de session stable que vous pouvez rapprocher après leur inscription.
Feature flags
Livrez derrière un flag. Coupez-le en un clic.
Créez des flags avec des règles de ciblage et des déploiements progressifs en pourcentage, basculez-les en direct depuis le dashboard, et lisez-les dans votre app avec un seul appel SDK — pas de fournisseur de flags séparé, pas de bundle supplémentaire.
-
Un ciblage évalué côté client
Le SDK évalue les flags selon les attributs de l'utilisateur — plan, rôle, tout ce que vous passez — si bien qu'un flag peut être actif pour une cohorte et désactivé pour tous les autres.
-
Des événements d'exposition, automatiquement
La première fois qu'un flag est lu, le SDK émet un événement d'exposition. Vous ne savez pas seulement qu'un flag était actif — vous savez exactement qui a vraiment vu la variante.
-
Le bouton d'arrêt d'urgence, c'est le dashboard
Déploiement à 0 %, 50 %, 100 % — et un seul bouton retire une fonctionnalité défaillante de la production. Les flags sont intégrés au SDK d'analytics produit de 6,6 Ko, et la dernière valeur est mise en cache pour que l'UI conditionnée par un flag ne clignote jamais au premier rendu.
Déjà sur LaunchDarkly ou Statsig ? Les deux connecteurs sont en direct — répliquez ces flags et expériences sur la colonne vertébrale pour la visibilité de l'équipe.
Analytics web
Les chiffres du site marketing, sans cookies.
Un seul script de 5,8 Ko sur votre site marketing capture les pages vues, les sources de trafic, les pages les plus visitées, les clics sortants, les 404, les événements personnalisés, les Core Web Vitals (LCP, CLS, INP, TTFB) et la capture automatique des clics sans balisage. Pas de cookies — les profils visiteurs anonymes viennent d'empreintes d'appareil hachées qui tournent chaque jour.
- ✓Pages vues, référents et pages les plus visitées — sans tag manager et sans échantillonnage.
- ✓Les 404 et les clics sortants sont suivis d'office, si bien que les liens cassés se signalent eux-mêmes.
- ✓Le visiteur qui a lu votre page tarifs est la même fiche que l'utilisateur qui s'est inscrit — la colonne vertébrale relie son avant et son après.
<script
src="https://platform.aioproductos.com/sdk/productos.js"
data-product-key="pk_live_e_…"
></script>C'est toute l'installation. L'init sans code lit les attributs data-* — pas de snippet, pas d'objet de configuration. 5,8 Ko gzippés, mesurés.
Les SDKs
Quatre SDKs. 1,9 à 6,6 Ko. Une balise script chacun.
Des tailles réelles, mesurées, gzippées — votre vitesse de page ne nous remarquera pas. Chaque SDK vit dans son propre espace de noms global, si bien que les quatre tournent sur la même page sans collision.
- Analytics web Pages vues, sources, clics sortants, 404, Core Web Vitals et capture automatique des clics sans balisage.
5,8 Ko - Analytics produit Événements identifiés, capture automatique des écrans en SPA et feature flags ; la relecture de session et les guides in-app se chargent en chunks séparés à la demande.
6,6 Ko - Chat support Une bulle de chat dont les fils deviennent du feedback produit sur la colonne vertébrale.
5,9 Ko - Prise de rendez-vous Des pages de réservation qui font atterrir les rendez-vous sur la fiche client.
1,9 Ko
Tous servis depuis platform.aioproductos.com/sdk — une URL stable par SDK, auto-init via les attributs data-*, ingestion par lots dédupliquée par ID d'événement.
Pourquoi nous plutôt qu'un outil isolé
Relié au compte à l'instant où c'est écrit.
Les outils d'analytics isolés vous forcent à exporter, rapprocher et espérer. Ici, le rapprocheur d'identité relie les utilisateurs à leur compte entreprise par domaine e-mail — alice@fernwood.co atterrit automatiquement sur le compte Fernwood — et chaque ligne d'événement porte le compte et l'end-user auxquels elle appartient.
-
Relié à l'écriture, pas à la requête
Les IDs de compte et d'end-user sont écrits sur chaque événement dès son ingestion. « Les événements de ce compte, ces 30 derniers jours » est une simple recherche indexée — pas une jointure en éventail.
-
Une piste d'audit, pas de la magie
Chaque correspondance d'identité est enregistrée dans une carte d'identité que vous pouvez consulter — automatique par domaine e-mail, manuelle quand vous taguez quelqu'un vous-même.
-
L'usage juste à côté du revenu
La cohorte qui utilise une fonctionnalité et le revenu qu'elle paie se trouvent sur la même fiche — si bien que « cette fonctionnalité vaut-elle encore la peine ? » devient une recherche, pas un projet de recherche.
Limite honnête : les événements portent leur compte dès la première écriture ; les panneaux d'usage dans la 360 client s'allument à mesure que la jointure de chaque connecteur arrive.
Confidentialité
Le respect de la vie privée par défaut, pas une option.
Une analytics que vous pouvez exécuter en UE sans spirale de revue juridique. Les SDKs arrivent respectueux d'office.
- ✓DNT et GPC respectés à l'init — un navigateur qui dit « ne pas suivre » n'est pas suivi. Aucun flag de contournement n'existe.
- ✓Un seul opt-out fait taire tout — un simple appel optOut() active un flag que chaque SDK ProductOS sur la page respecte. Tout le suivi s'arrête, silencieusement.
- ✓Région EU ou US à l'ingestion — choisie à l'inscription, imposée par clé d'ingestion sur chaque endpoint d'événement. Vos données atterrissent où vous l'avez dit.
- —Web uniquement en v1. Les SDKs mobile et serveur sont sur la feuille de route, pas encore livrés. Si votre produit est une app native, nous ne sommes pas encore votre solution analytics.
- —La rétention nette en dollars est corrélationnelle, pas figée dans le temps. La rétention et le gain de résultat par fonctionnalité comparent les adoptants aux non-adoptants sur le MRR en direct ; nous ne figeons pas encore l'historique du MRR par compte, si bien que l'expansion sur place n'est pas isolée.
Accès anticipé
Déposez une balise script. Voyez vos utilisateurs sur la colonne vertébrale.
Nous intégrons des partenaires design en ce moment. Connectez votre site en quelques minutes et regardez les pages vues, les sessions et les flags atterrir reliés à de vrais comptes clients.
FAQ
Questions, réponses
Qu'est-ce qui est inclus dans le module analytics ?
Quatre capacités first-party sur une seule colonne vertébrale : analytics produit avec événements identifiés, relecture de session, feature flags avec ciblage et événements d'exposition, et analytics web sans cookies. Chacune est une seule balise script, et chaque événement se relie au compte client à l'écriture.
Les scripts de suivi sont-ils lourds ?
Légers — les quatre SDKs web font 1,9–6,6 Ko gzippés, une seule balise script chacun. Ils sont first-party, donc aucune balise tierce ne freine votre vitesse de page.
L'analytics web est-elle sans cookies et respectueuse de la vie privée ?
Oui — l'analytics web fonctionne sans cookies, et les SDKs respectent Do Not Track et Global Privacy Control avec un seul opt-out. Vous choisissez aussi la région des données, UE ou US, imposée à l'ingestion.
Où vivent les données analytics ?
Sur votre propre colonne vertébrale AIOProductOS, reliée au compte client correspondant à l'écriture — jamais regroupée avec les données d'autres entreprises ni revendue. C'est le même chemin de données first-party qu'obtient un client payant.
Les données sont-elles rattachées aux fiches clients, ou isolées ?
Rattachées. Chaque événement — produit, relecture, exposition de flag, page vue — se relie au compte client à l'écriture, si bien que l'analytics vit sur la même colonne vertébrale que le feedback, le revenu et le travail plutôt que dans un outil séparé.
Avez-vous des funnels et de la rétention ?
Oui — et ils sont pondérés par le revenu. Chaque étape de funnel et chaque cohorte de rétention porte le MRR en direct des comptes qui la composent, si bien que vous voyez les dollars bloqués à un abandon ou retenus dans une cohorte, pas seulement le pourcentage. Les product paths et une vue Sankey sont là aussi, et les trois sont appelables par votre IA via MCP (analyze_funnel, get_retention, analyze_paths).
Dois-je taguer chaque événement à la main ?
Non. L'analytics web inclut d'office la capture automatique des clics sans balisage et les Core Web Vitals, et l'analytics produit capture automatiquement les changements d'écran en SPA par défaut — si bien que les paths et les funnels fonctionnent sans code par route ou par élément. Vous pouvez toujours envoyer des événements explicites où vous voulez de la précision, et désactiver la capture automatique par surface.