Suivi des conversions sans cookies : formulaires, inscriptions et ventes

Oui. Le suivi de conversions sans cookies enregistre des actions significatives sur votre site sans utiliser de cookies. Vous pouvez compter les envois de formulaires réussis, les inscriptions et les achats, et analyser le contexte disponible pour ces événements. La principale limite est l’attribution : mesurer une action n’équivaut pas à reconnaître la même personne d’un appareil à l’autre ou sur plusieurs semaines.

Ce guide explique comment mettre en place le suivi des conversions avec MetriXs, quoi mesurer, et où se trouvent les limites.

Le suivi de conversions sans cookies enregistre une action sur votre site sous forme d’événement, sans s’appuyer sur des cookies pour identifier le visiteur.

Quand quelqu’un envoie avec succès un formulaire de contact, votre site peut envoyer un événement tel que Lead Submitted. Le système d’analytique enregistre l’événement, avec le contexte approprié : la page et les propriétés non personnelles que vous choisissez d’inclure.

Cela permet de répondre à des questions telles que :

• Combien de demandes de démo notre site a-t-il générées ?
• Quels abonnements les nouveaux clients choisissent-ils ?
• À quel moment les visiteurs abandonnent-ils le checkout ?
• Quelles sources de trafic enregistrées génèrent du chiffre d’affaires ?

Vous n’avez pas besoin d’un profil publicitaire persistant pour compter une inscription réussie.

Cependant, « sans cookies » décrit une caractéristique technique, pas une garantie de confidentialité ou de conformité absolue. Un système peut éviter les cookies et traiter quand même des données personnelles ou utiliser d’autres technologies de suivi. Ce qu’il collecte, comment il identifie les visiteurs et ce qu’il fait des informations comptent tous.

Avant d’ajouter du code, définissez le résultat que vous voulez réellement mesurer.

Un clic sur un bouton n’est pas forcément un lead. Une visite d’une page d’inscription n’est pas une inscription terminée. Entrer dans le tunnel d’achat n’est pas une vente.

Un clic de téléchargement mesure l’intention de télécharger ; il ne prouve pas que le visiteur a reçu ou lu le fichier. De même, une commande terminée et un paiement encaissé ne sont pas toujours la même chose. Choisissez des définitions qui correspondent à votre activité.

Commencez par une conversion principale. Pour une entreprise de services, ce sera peut-être une demande qualifiée. Pour un produit SaaS, une inscription terminée. Pour une boutique en ligne, une commande confirmée.

Vous pourrez ajouter des événements secondaires plus tard.

Ajoutez votre site à MetriXs et copiez le snippet d’installation fourni pour votre site. Suivez le guide d’installation du tracker ou utilisez l’intégration de plateforme appropriée.

Installez le tracker une seule fois. Si un plugin l’ajoute déjà, n’insérez pas aussi le même script manuellement.

Une fois le tracker chargé, votre site peut enregistrer des événements personnalisés via la fonction globale window.metrixs().

Les exemples ci-dessous s’intègrent dans les gestionnaires de succès (callbacks ou promesses) de votre application. Ce sont des appels d’événements, pas des implémentations complètes de formulaire ou de checkout, et ils supposent que le tracker est disponible.

Pour un formulaire de contact, envoyez un événement après que le serveur a confirmé que l’envoi a réussi :

window.metrixs('Lead Submitted', {
  props: {
    form: 'contact',
    location: 'contact_page'
  }
})

Les propriétés décrivent le formulaire, pas la personne qui l’envoie.

Évitez de déclencher cet événement dès que quelqu’un appuie sur le bouton d’envoi. Un clic peut être suivi d’une erreur de validation, d’un échec réseau ou d’une soumission refusée.

La séquence correcte est :

1. Le visiteur envoie le formulaire.
2. Votre application valide et envoie la requête.
3. Votre backend confirme le succès.
4. Votre application enregistre Lead Submitted.

Si vous utilisez un plugin de formulaire, reliez l’événement à son callback de soumission réussie documenté plutôt qu’à un écouteur générique de clic ou de submit.

Gardez le contenu des formulaires hors de l’analytique

N’attachez pas de noms, d’adresses e-mail, de numéros de téléphone ni de contenus de messages à l’événement.

Par exemple, form: 'contact' est un contexte utile. L’adresse e-mail du visiteur n’est pas nécessaire pour compter une demande.

Examinez aussi l’URL de page enregistrée. Des données personnelles peuvent entrer accidentellement dans l’analytique via des chaînes de requête, des liens de confirmation ou des URL contenant des identifiants de compte. MetriXs prend en charge une surcharge d’URL pour les événements personnalisés, mais vos pages vues et vos autres événements capturés automatiquement exigent la même attention.

Votre CRM doit conserver la demande. Votre analytique doit mesurer qu’une demande a eu lieu.

Appliquez le même principe à la création de compte :

window.metrixs('Signup Completed', {
  props: {
    plan: 'free',
    signup_location: 'pricing_page'
  }
})

Déclenchez l’événement après la création réussie du compte, pas à l’ouverture du formulaire d’inscription.

Gardez des valeurs de propriétés cohérentes. Si vous utilisez free, basic et pro comme noms de plans, utilisez exactement ces valeurs partout. Mélanger Pro, pro-plan et premium rend la répartition plus difficile à interpréter.

Dans MetriXs, les événements définis par l’utilisateur apparaissent dans la carte Custom Events. Dépliez un événement pour voir ses répartitions par propriété. Cela permet de comparer, par exemple, les inscriptions enregistrées par plan.

Consultez la documentation des événements personnalisés pour les options disponibles.

Un écran de confirmation peut apparaître plusieurs fois. Les utilisateurs rafraîchissent les pages, les applications réessaient des requêtes, et les prestataires de paiement peuvent livrer le même webhook à répétition.

Votre implémentation doit émettre la conversion une fois par action métier réussie. Ne partez pas du principe que recharger une page de remerciement représente une nouvelle conversion.

Pour les intégrations backend, utilisez vos registres métier existants et la gestion d’idempotence pour éviter les traitements répétés. Si les intégrations navigateur et backend signalent la même action, définissez comment éviter les doublons avant d’activer les deux.

Le suivi commerce de MetriXs utilise trois noms d’événements définis :

Activez Commerce pour votre site sous Settings → Sites.

Envoyez ensuite chaque événement au point correspondant de votre tunnel d’achat. Par exemple, quand un client entre dans le checkout avec un panier de 79 € :

window.metrixs('checkout_started', {
  props: {
    total: 79,
    currency: 'EUR'
  }
})

Quand les informations de paiement sont envoyées :

window.metrixs('payment_submitted', {
  props: {}
})

Quand la commande est confirmée :

window.metrixs('order_completed', {
  props: {
    total: 79,
    currency: 'EUR'
  }
})

Le montant ci-dessus est donné à titre indicatif. En production, utilisez le montant total réel de la commande confirmée ainsi que sa devise.

Ces événements alimentent le chiffre d’affaires, la valeur moyenne des commandes et le tunnel d’achat du tableau de bord commerce. Vous pouvez aussi inclure les propriétés produit documentées pour remplir les rapports par produit.

Avec des flux de paiement comme les checkouts hébergés, un client ayant réglé sa commande peut ne jamais revenir sur votre page de remerciement.

MetriXs prend en charge l’envoi d’événements commerce depuis votre backend. Pour les conversions dépendantes du paiement, un webhook vérifié du prestataire de paiement peut être un déclencheur plus fiable qu’une redirection navigateur.

Gardez les identifiants d’API sur le serveur, authentifiez les requêtes webhook et gérez les livraisons en double.

Il y a une distinction importante ici : enregistrer une commande de manière fiable ne préserve pas automatiquement l’attribution du visiteur d’origine. Une requête backend ne contient pas intrinsèquement le contexte de source de trafic du navigateur. Vérifiez ce que votre intégration transmet et prend en charge avant d’attendre que les rapports au niveau des sources correspondent aux conversions enregistrées par le navigateur.

Voir le guide d’intégration commerce pour l’API côté serveur et le format des événements.

Le suivi du checkout Shopify fonctionne séparément du thème de la vitrine.

L’intégration Shopify de MetriXs utilise un web pixel pour les événements de checkout. Comme documenté pour cette intégration, les événements de checkout sur les marchés de l’UE et du Royaume-Uni sont soumis au cadre de consentement de Shopify. Les événements de checkout enregistrés ne peuvent donc représenter que les visiteurs consentants.

Une implémentation sans cookies ne contourne pas les exigences de consentement des plateformes. Voir le guide de configuration Shopify pour la distinction entre suivi de la vitrine et du checkout.

Une fois les événements reçus, regardez au-delà du total.

Supposons qu’une boutique enregistre ceci sur une période :

Ces chiffres sont des exemples, pas des résultats de clients de MetriXs.

La valeur moyenne des commandes est :

1 975 € ÷ 25 commandes = 79 €

La formule de calcul du taux de conversion e-commerce dans MetriXs est :

Événements de commande terminée ÷ visiteurs uniques × 100

Pour cet exemple :

25 ÷ 1 000 × 100 = 2,5 %

C’est un taux de commandes par visiteur. Cela ne signifie pas forcément que 2,5 % des personnes distinctes ont acheté : un visiteur peut passer plusieurs commandes, et l’identification des visiteurs a ses propres limites de mesure.

Pour les événements personnalisés, faites la même distinction. Trente événements d’envoi de formulaire ne signifient pas automatiquement trente leads uniques.

Les chiffres du checkout soulèvent aussi une question pertinente : pourquoi enregistre-t-on moins de paiements initiés que de débuts de commande ? Examinez les frais de port, les options de paiement, les erreurs de formulaire et l’implémentation des événements elle-même avant de supposer un problème d’expérience utilisateur.

L’analytique sans cookies peut signaler le contexte de source de trafic et de campagne quand cette information est disponible et associée à l’activité enregistrée.

Pour les sites avec commerce activé, MetriXs documente les répartitions de revenus par source, campagne et page d’atterrissage.

Utilisez des paramètres UTM cohérents pour les liens que vous contrôlez. Un lien de newsletter pourrait ressembler à :

https://example.com/demo?utm_source=newsletter&utm_medium=email&utm_campaign=autumn_launch

Les libellés de campagne doivent décrire la campagne, pas identifier des destinataires individuels. Évitez les adresses e-mail, les identifiants clients ou d’autres identifiants personnels dans les valeurs UTM.

Pour la découverte par IA, les référents reconnus d’assistants comme ChatGPT ou Perplexity apportent aussi des informations utiles sur les sources. Mais chaque clic ne porte pas un référent exploitable, et un rapport de référents IA ne montre pas chaque mention de votre entreprise dans une réponse d’IA.

L’attribution décrit le parcours observable. Ce n’est pas un enregistrement complet de tout ce qui a influencé le client.

Quelqu’un peut lire votre newsletter sur son téléphone, revenir directement sur un ordinateur portable deux jours plus tard et acheter. Sans identifiant multi-appareils persistant, ces interactions ne peuvent pas être simplement supposées appartenir à la même personne.

MetriXs décrit son identification des visiteurs comme un hachage à rotation quotidienne. C’est un modèle de mesure différent d’un identifiant visiteur persistant conservé pendant des mois. N’interprétez pas les comptages de visiteurs comme une liste durable de personnes individuelles d’une période de reporting à l’autre.

L’analytique sans cookies reste aussi soumise au blocage de scripts, aux échecs réseau, aux restrictions des navigateurs et aux erreurs d’implémentation. Supprimer les cookies ne rend pas la mesure sans perte.

Non. Ils résolvent des problèmes différents.

L’analytique sans cookies mesure l’activité du site sans s’appuyer sur des cookies.

Le Google Consent Mode ajuste le comportement des balises Google selon l’état de consentement communiqué par votre site.

Google documente deux approches. Le Consent Mode de base bloque les tags Google jusqu’à ce que le consentement soit accordé. Le Consent Mode avancé peut envoyer des mesures sans cookies pendant que le consentement est refusé, en prenant en charge la modélisation le cas échéant.

Cela ne rend pas le Consent Mode équivalent à un outil d’analytique sans cookies indépendant. Il ne vous décharge pas non plus de la responsabilité de configurer correctement le consentement.

De même, une inscription enregistrée dans MetriXs ne devient pas automatiquement une conversion Google Ads ou un signal d’optimisation Meta. Les intégrations aux plateformes publicitaires, l’attribution et les exigences de consentement demandent une réflexion distincte.

Voir la documentation du Consent Mode de Google pour la distinction.

Il n’y a pas de réponse universelle fondée sur la seule absence de cookies.

Les règles applicables peuvent couvrir d’autres formes de stockage ou d’accès sur l’appareil, et les obligations du RGPD peuvent s’appliquer quand des données personnelles sont traitées. Les exemptions pour mesure d’audience dépendent aussi de la juridiction, de la finalité et de la configuration.

L’autorité française (la CNIL) explique par exemple que certains outils de mesure d’audience peuvent être exemptés de consentement sous des conditions strictes, et rappelle que les règles nationales varient. Voir ses recommandations sur la mesure d’audience.

Une mise en œuvre responsable minimise les données collectées, évite les informations personnelles dans les propriétés d’événements et les URL, documente le traitement et respecte les exigences de consentement applicables.

Votre site peut aussi avoir besoin d’un mécanisme de consentement pour les tags publicitaires, les services intégrés ou d’autres technologies, même si votre configuration analytique n’en exige pas.

Des outils différents peuvent produire des totaux différents sans que l’un soit défectueux.

Les raisons courantes incluent des déclencheurs d’événements différents, des états de consentement, des fuseaux horaires de reporting, des définitions de visiteur, des fenêtres d’attribution et la gestion des doublons. L’analytique navigateur peut aussi manquer des commandes finalisées sans retour réussi sur votre site.

Comparez ce qui est comparable : même période, même définition d’achèvement, et même traitement des remboursements, annulations, taxes et frais de port.

Votre système de commandes backend doit rester la source de vérité des enregistrements opérationnels. L’analytique vous aide à comprendre l’acquisition enregistrée et le comportement sur le site ; elle ne remplace pas votre comptabilité.