Un guide pratique de suivi sans cookies

Les formulaires sont à la fois la conversion la plus précieuse et la fuite de données la plus facile : un suivi sans cookies permet de compter les envois sans faire transiter noms, e-mails, téléphones, budgets ou détails de santé par votre outil d'analyse.

Les soumissions de formulaires sont l’une des conversions de sites Web les plus importantes et l’un des endroits les plus faciles à divulguer des données personnelles. Les noms, e-mails, numéros de téléphone, messages, détails de santé, budgets et informations sur l'entreprise transitent souvent par les formulaires. Votre outil d’analyse n’a généralement pas besoin de tout cela.

Le suivi sans cookies signifie mesurer qu'un formulaire a été soumis, de quel formulaire il s'agit et quelle campagne ou page a contribué, sans stocker un identifiant de visiteur persistant ni envoyer de valeurs de champ aux fournisseurs d'analyses.

Ce que vous devez réellement mesurer

Pour la plupart des formulaires de marketing, les questions d'analyse utiles sont :

• Combien de visiteurs ont consulté la page du formulaire ?
• Combien ont commencé le formulaire ?
• Combien l'ont soumis avec succès ?
• Quelle source, campagne ou page de destination a conduit à des soumissions ?
• Quel appareil ou navigateur a un taux d'achèvement inférieur ?
• Quel type de formulaire convertit le mieux ?

Aucune de ces questions ne nécessite de collecter le corps du message, l'adresse e-mail, le nom ou le numéro de téléphone dans les analyses.

Conception d'événements sécurisés

Utilisez des événements tels que :

Event: form_viewed
Properties:
- form_type = demo
- page_template = pricing
 
Événement : form_started
Propriétés :
- form_type = démo
 
Événement : form_submit
Propriétés :
- form_type = démo
- résultat = succès

Pour les soumissions ayant échoué, suivez la catégorie d'erreur, et non la valeur exacte du champ :

Event: form_error
Properties:
- form_type = demo
- error_type = validation_required_field

N'envoyez pas :

• Nom.
• E-mail.
• Téléphone.
• Entreprise.
• Texte du message.
• Recherche de texte libre ou saisie de formulaire.
• Interne CRM ID.
• adresse IP.
• Détails de santé, financiers ou juridiques.

Google avertit les clients Analytics de ne pas envoyer d'informations personnelles identifiables ou d'informations sensibles dans Analytics dans ses guides HIPAA et Google Analytics. Cette règle est utile même si vous utilisez une autre plateforme d’analyse.

Confirmation côté client ou côté serveur

Un événement de clic client-side peut surcompter car les utilisateurs cliquent sur Soumettre même lorsque la validation échoue. Un meilleur signal de conversion est la confirmation server-side : le backend reçoit le formulaire, le valide, le stocke ou l'envoie au bon système, puis enregistre form_submit seulement après succès.

Si le suivi des événements server-side n'est pas disponible, utilisez la page de remerciement comme signal de conversion. C'est moins précis que la confirmation backend, mais mieux que de compter les clics sur les boutons.

Qu'en est-il de Google Tag Manager ?

Google Tag Manager peut détecter les envois de formulaires, mais il peut également commettre des erreurs :

• Il peut se déclencher avant que la validation ne réussisse.
• Il peut capturer les valeurs des champs s'il est mal configuré.
• Il peut envoyer des événements à plusieurs fournisseurs.
• Il peut déclencher des balises avant le consentement.
• Il peut être oublié lorsque les formes changent.

Si vous utilisez GTM, gardez la couche de données propre. Poussez uniquement les champs sécurisés tels que form_type, form_id en tant que slug non identifiant et result. Ne transférez jamais la charge utile du formulaire dans la couche de données.

Les cookies ne sont pas requis pour le suivi de base des conversions de formulaires

Une configuration d'analyse sans cookie peut compter les conversions par page, référent, campagne UTM et contexte global. Vous ne saurez pas que le même navigateur a visité trois fois avant de soumettre, mais vous pouvez toujours répondre à la question opérationnelle : quelles sources et quelles pages produisent des soumissions de formulaires ?

Si vous avez besoin d'une attribution au niveau du prospect, connectez-la dans votre CRM avec une collecte explicite et des notifications appropriées. Ne faites pas passer clandestinement l'identité d'un prospect via l'analyse de sites Web.

Considérations juridiques et de confidentialité

Sous GDPR, le contenu du formulaire est une donnée personnelle lorsqu'il identifie ou concerne une personne. Selon le formulaire, ils peuvent également inclure des données de catégories spéciales. Sous le CCPA, les données du formulaire peuvent être des informations personnelles et, dans certains cas, des informations personnelles sensibles. Sous HIPAA, les formulaires de soins de santé peuvent impliquer PHI lorsqu'ils sont utilisés par des entités réglementées.

La conception d'analyse la plus sûre est la minimisation des données : comptez l'événement, conservez la charge utile dans le système qui en a besoin et évitez la divulgation d'analyses.

Liste de contrôle de mise en œuvre

1. Inventoriez tous les formulaires et leurs destinations.
2. Définissez les valeurs form_type : démo, contact, newsletter, support, devis.
3. Décidez quel événement marque le succès.
4. Supprimez les valeurs de champ des événements d'analyse et des push de couche de données.
5. Supprimez les paramètres de requête personnels de la page de remerciement URLs.
6. Testez le rejet du consentement à l’analyse, le cas échéant.
7. Vérifiez qu'aucune relecture de session ou aucun outil de carte thermique n'enregistre les entrées saisies.
8. Comparez le nombre de conversions analytiques avec les enregistrements du formulaire backend.
9. Documentez le flux dans votre avis de confidentialité.

Erreurs courantes

• Comptabilisation des clics sur le bouton Soumettre en tant que conversions.
• Envoi d'adresses e-mail comme étiquettes d'événements.
• Enregistrement des soumissions ayant échoué en tant que prospects.
• Installation du replay de session sur les pages de formulaire.
• Mise des réponses du formulaire dans les paramètres URL.
• Autoriser plusieurs pixels publicitaires à se déclencher sur des formulaires sensibles.
• Conserver les journaux de formulaires pour toujours.

L'analyse des formulaires devrait améliorer l'entonnoir sans rendre les visiteurs plus exposés. Comptez la conversion. Protégez le contenu.

Les journaux du serveur ne sont pas automatiquement plus sûrs

Certaines équipes suppriment les analyses client-side, puis conservent pour toujours des journaux de serveur détaillés. Cela peut toujours créer un risque pour la vie privée. Les journaux du serveur contiennent des adresses IP, des agents utilisateurs, des URLs complets, des chaînes de requête et des horodatages. Si vous utilisez des journaux pour la validation de la conversion de formulaire, réduisez les champs, restreignez l'accès et définissez la conservation.

Réconcilier avec les systèmes d'entreprise

L'analyse ne doit pas être la source de vérité pour les prospects. Comparez le nombre total de formulaires soumis avec CRM ou les enregistrements de la boîte de réception chaque semaine. Si l'analyse indique 120 soumissions et que le CRM en a 83, enquêtez sur le filtrage du spam, les échecs de validation, les soumissions en double, les scripts bloqués et les erreurs backend. Le suivi sécurisé de la confidentialité doit toujours être opérationnel QA.

La règle directrice est la séparation. Analytics compte l'événement. CRM ou le support gère le contenu. Les journaux de sécurité protègent le système. Mélanger ces emplois crée une exposition inutile.

Cette séparation facilite également les audits, car chaque système a un objectif clair et un ensemble de données plus restreint.

Suivi des formulaires QA Liste de contrôle

Testez chaque formulaire du point de vue du visiteur et du point de vue du backend. Confirmez que l'analyse ne compte que les soumissions réussies, ne stocke jamais les valeurs des champs, supprime les paramètres de requête personnels et reste désactivée lorsque le consentement applicable est refusé.

Effectuez ensuite un rapprochement hebdomadaire avec le système qui reçoit réellement le prospect. Si Analytics et CRM ne sont pas d'accord, étudiez les échecs de validation, le filtrage du spam, les soumissions en double, les scripts bloqués et les erreurs backend avant de modifier les dépenses de campagne.

Questions fréquentes

Que signifie vraiment le suivi sans cookies ?

Le suivi sans cookies signifie mesurer qu'un formulaire a été envoyé, quel formulaire c'était et quelle campagne ou page y a contribué. Cela se fait sans stocker d'identifiant persistant du visiteur ni envoyer les valeurs des champs aux outils d'analyse. Vous savez toujours quelles sources et quelles pages génèrent des soumissions. Ce que vous perdez, c'est de savoir que le même visiteur est revenu trois fois avant de convertir.

Quelles données personnelles doivent rester hors des événements d'analyse de formulaire ?

Gardez le nom, l'email, le téléphone, l'entreprise, le texte du message, les champs de saisie libre, les identifiants CRM internes, les adresses IP et les détails de santé, de finance ou juridiques hors de l'analytique. N'envoyez que des propriétés non identifiantes comme form_type, form_id sous forme de slug, et result. Le guide de Google sur HIPAA et Google Analytics déconseille d'envoyer des informations personnelles identifiables ou sensibles à Analytics.

Pourquoi un événement de clic côté client surestime-t-il les soumissions de formulaire ?

Un clic sur le bouton d'envoi se déclenche même quand le formulaire échoue à la validation, donc l'événement de clic compte des tentatives plutôt que des réussites. La confirmation côté serveur n'enregistre form_submitted qu'après que le backend a validé et stocké le formulaire. Cet écart explique pourquoi le suivi basé sur les clics gonfle les chiffres de conversion.

Une page de remerciement suffit-elle comme signal de conversion ?

L'affichage d'une page de remerciement fonctionne quand la confirmation côté serveur n'est pas disponible, et vaut mieux que de compter uniquement les clics d'envoi. Elle reste moins précise qu'un événement côté serveur, car des visiteurs peuvent atterrir sur cette page sans soumission validée derrière. Utilisez-la comme solution de repli, pas par défaut.

Que peut-il se passer de travers avec Google Tag Manager sur une page de formulaire ?

GTM peut se déclencher avant que la validation réussisse, capturer des valeurs de champs s'il est mal configuré, envoyer des événements à plusieurs fournisseurs, déclencher des tags avant le consentement, ou simplement être oublié quand le formulaire change. Limiter le data layer à des champs sûrs comme form_type, un form_id non identifiant, et result évite la plupart de ces problèmes. Le contenu du formulaire ne doit jamais atteindre le data layer.

Les soumissions de formulaire sont-elles considérées comme des données personnelles sous le RGPD ?

Sous le RGPD, le contenu d'un formulaire est une donnée personnelle dès qu'il identifie une personne ou s'y rapporte, et selon le formulaire il peut inclure des données de catégorie particulière. La CCPA traite les données de formulaire comme des informations personnelles, parfois sensibles. HIPAA peut classer les données de formulaires de santé comme PHI quand une entité réglementée est impliquée.

Que faire si les chiffres de conversion de l'analytique et du CRM ne correspondent pas ?

Comparez chaque semaine les compteurs agrégés de form_submitted avec les registres du CRM ou de la boîte de réception. Si l'analytique indique 120 soumissions et que le CRM en a 83, vérifiez le filtrage anti-spam, les échecs de validation, les soumissions en double, les scripts bloqués et les erreurs backend avant de toucher au budget des campagnes. Un suivi respectueux de la vie privée a quand même besoin de ce contrôle opérationnel.

Les journaux du serveur sont-ils automatiquement plus sûrs que l'analytique côté client ?

Non, les journaux du serveur peuvent porter le même risque sous une autre forme, car ils contiennent souvent des adresses IP, des user agents, des URLs complètes, des chaînes de requête et des horodatages. Retirer l'analytique côté client sans contrôler la rétention des journaux ne fait que déplacer l'exposition. Réduisez les champs enregistrés, restreignez l'accès et fixez une durée de rétention.

Comment répartir les responsabilités entre analytique, CRM et journaux ?

L'analytique devrait compter l'événement, le CRM ou le système de support devrait gérer le contenu, et les journaux de sécurité devraient protéger le système. Mélanger ces rôles crée une exposition qu'une séparation claire évite. Cette séparation facilite aussi les audits, car chaque système a un objectif clair et un ensemble de données plus restreint.

Quelle est la façon la plus sûre de concevoir des événements de suivi de formulaire ?

Utilisez des événements comme form_viewed, form_started et form_submitted avec des propriétés limitées à form_type, page_template et result, et suivez les soumissions échouées par catégorie d'erreur plutôt que par la valeur du champ en cause. Vous obtenez ainsi les données d'entonnoir dont le marketing a besoin, combien ont vu, commencé et envoyé, sans collecter le texte du message, l'email, le nom ou le téléphone. La minimisation des données est la règle de conception qui guide tout cela.