À qui cela s'adresse

Skomi pour les produits SaaS

Une société SaaS mesure deux choses qu'on achète d'ordinaire séparément : un site vitrine qui doit convertir, et un produit qui doit retenir. Skomi couvre les deux depuis un script et une facture, pour ce qui est de la mesure au niveau de la page, qui est la part à lire attentivement ci-dessous.

Ce que vous obtenez

Le site vitrine et le produit connecté sur le même script. Pages d'essai, documentation, tarifs et l'application elle-même remontent dans un seul compte : le chemin d'un article de blog à un compte activé est un seul entonnoir plutôt que deux outils recousus à la main.

Pas de bandeau de consentement sur le site vitrine. Rien n'est stocké sur l'appareil du visiteur : la page qui doit convertir n'est donc pas la page qui demande d'abord la permission. Pour un produit dont l'argumentaire repose sur la confiance, cela vaut plus que l'analytics.

Des entonnoirs, et des cohortes avec une réserve. Les parcours montrent où un tunnel d'inscription ou d'accueil perd des gens, étape par étape, et cela fonctionne quel que soit votre réglage d'identité. Les cohortes de rétention regroupent selon la toute première fois qu'un visiteur a été vu, et non la première fois dans la période. Mais lisez la section suivante avant de vous y fier, parce que ce que « le même visiteur la semaine prochaine » signifie dépend d'un réglage que la plupart des gens laissent tranquille.

Heatmaps et enregistrements à l'intérieur du produit. L'écran d'accueil où tout le monde cale n'est en général pas celui que vous auriez deviné. Les saisies sont toujours masquées dans les enregistrements, ce qui compte davantage ici que sur une page vitrine.

Un widget de feedback que vous pouvez poser sur un seul écran. Demandez sur la page où est le doute, plutôt que d'envoyer un questionnaire par e-mail une semaine plus tard.

Rendre compte sans distribuer d'identifiants. Un tableau de bord partagé est un lien sans compte derrière, ce qui permet à un fondateur de montrer des chiffres à un investisseur ou à un conseil sans ajouter de sièges.

Ce que Skomi ne fera pas pour vous

Skomi ne détermine pas de lui-même qui est qui. L'identité est dérivée sur le serveur à partir d'un sel quotidien remplacé : quelqu'un qui revient la semaine prochaine est compté comme un nouveau visiteur, pas le même. L'exception est celle que vous choisissez : activez Identify signed-in users dans les réglages Analytics du site, et votre produit peut appeler skomi.identify() avec son propre identifiant pour une personne connectée. Cet identifiant suit la personne d'un jour à l'autre et d'un appareil à l'autre, ne stocke rien sur son appareil, et permet de filtrer le tableau de bord, la liste des visites et les parcours sur ce qu'a fait ce client précis. Il reste désactivé tant que vous ne l'activez pas, il refuse tout ce qui ressemble à une adresse e-mail, et c'est à vous d'en informer vos utilisateurs. Il ajoute un filtre, pas un modèle de comptes : il n'y a pas de dimension entreprise, pas de liste de vos utilisateurs et pas d'attributs qui leur soient rattachés. Un identity.mode par site réglé sur device est un choix distinct. Il remet un identifiant stable sur l'appareil et fait que la rétention signifie ce que vous attendez, au prix de stocker quelque chose sur l'appareil, ce qui ramène la question du consentement avec. C'est un vrai compromis et il vous revient.

Pas de feature flags, pas d'expérimentations, pas d'A/B testing. Les suites d'analytics produit regroupent tout cela et Skomi n'en a rien. Si votre feuille de route dépend de livrer des variantes et d'en lire la différence, vous ferez tourner autre chose à côté.

Pas de CRM, pas d'e-mails, pas de fiches utilisateurs. Skomi mesure et restitue. Au-delà d'un identifiant que vous choisissez d'envoyer, il ne détient rien sur vos clients : il ne peut donc pas segmenter par forfait, déclencher un e-mail de cycle de vie, ni vous dire quels comptes se sont tus.

Pas d'authentification unique pour votre propre équipe. Les gens avec qui vous travaillez se connectent avec leur propre e-mail et mot de passe, ou avec Google, Microsoft ou GitHub, et l'accès s'accorde par site ou par application plutôt que par groupe d'annuaire.

Enregistrer un produit connecté devrait être une décision, pas une valeur par défaut. Les saisies sont masquées et vous pouvez échantillonner plutôt que tout capturer, mais vous filmez tout de même des écrans portant des données clients. Faites-le délibérément, dites-le dans votre politique de confidentialité, et décidez de la quantité de texte de page qu'un enregistrement peut montrer.

Le configurer comme vous travaillez

Un script sur les deux, site vitrine et application. Ils peuvent être un seul site dans Skomi ou deux : un si vous voulez tout l'entonnoir dans une vue unique, deux si les équipes qui les regardent sont différentes. Le guide de l'extrait couvre les deux cas.

Balisez chaque campagne de la même façon pour que le côté acquisition soit lisible. Il y a une convention qu'il vaut mieux adopter avant la première campagne plutôt qu'après la dixième.

Faites de l'inscription un objectif, et de la première action réelle un second objectif. L'écart entre les deux est l'activation, et c'est le chiffre qui manque à la plupart des tableaux de bord SaaS.

Activez les enregistrements par échantillonnage, pas pour tout le monde. Un échantillon suffit pour voir où l'accueil cale, et personne n'a besoin que chaque session du produit soit filmée.

Sachez combien de temps les enregistrements sont conservés. La durée vient de votre forfait, pas d'un réglage par site, et sur chaque forfait les enregistrements sont conservés moins longtemps que l'analytics. La page tarifs indique la fenêtre de chacun.

Un script, ou un SDK. Les mêmes rapports dans les deux cas.

Créez un compte, enregistrez un site, et activez ce dont vous avez besoin.