Un guide pratique de suivi sans cookies

Ce guide explique suivi sans cookies de manière pratique, avec un accent sur les décisions d'analytics respectueuses de la vie privée.

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 savez peut-être 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 peuvent contenir 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.