GA4 : supprimer des données envoyées par erreur
Données personnelles envoyées à GA4 : arrêtez la source, délimitez les paramètres concernés et vérifiez les demandes de suppression et les copies.
Vous découvrez des emails dans une dimension GA4. Modifier la balise évite de nouveaux envois, mais ne supprime pas les valeurs déjà reçues. Organisez deux actions distinctes : arrêter la collecte fautive et traiter son historique avec un périmètre documenté.
Arrêter et comprendre la source
Repérez la propriété, le flux, les événements, paramètres et dates concernés. Recherchez la même donnée dans l’URL, le titre, les événements personnalisés et les exports. Évitez de diffuser davantage l’incident en joignant un fichier complet aux échanges internes.
Google rappelle les restrictions sur les données permettant l’identification. Le guide de la recherche interne GA4 décrit l’une des sources fréquentes de texte libre.
Choisir le mécanisme adapté
La documentation officielle des demandes de suppression décrit plusieurs périmètres possibles selon les paramètres, événements et périodes. Lisez la portée de l’option retenue avant validation : une suppression trop large peut retirer des informations utiles, tandis qu’une sélection trop étroite laisse des copies.
| Élément du dossier | Information utile |
|---|---|
| Source corrigée | Balise, formulaire ou import concerné |
| Période | Début connu, fin et incertitudes |
| Valeurs ou paramètres | Périmètre effectivement visé |
| Demande | Identifiant, date et statut suivi |
| Contrôle | Résultat attendu et vérification après traitement |
| Copies | Exports, entrepôts, rapports et autres destinataires |
La documentation exclut certains paramètres de ce mécanisme, dont search_term. Ne promettez donc pas leur effacement par une demande standard. Examinez les autres procédures documentées, notamment pour les données associées à un identifiant utilisateur, et sollicitez l’assistance du fournisseur si le périmètre ne correspond pas au mécanisme disponible.
Distinguer suppression et prévention
Les outils de rédaction ou masquage avant envoi ne constituent pas nécessairement une purge rétroactive. La documentation Google sur la rédaction de données précise le périmètre et les limites de cette fonction. Examinez notamment les autres voies d’envoi, dont les imports et échanges serveur.
Le guide des UTM aide à éliminer le problème à sa source. Vérifiez la correction avec des valeurs fictives, sans renvoyer de données réelles pour confirmer la détection.
Examiner les autres obligations
La présence d’informations non prévues peut nécessiter une analyse de sécurité, de confidentialité et de licéité. Évaluez si les conditions des Art. 33(1) et 34(1) sont réunies : RGPD. Tout envoi erroné ne déclenche pas automatiquement les mêmes notifications ; documentez l’analyse du risque.
Les journaux serveur peuvent contenir les mêmes valeurs. Fermez le dossier seulement lorsque les flux, demandes de suppression et copies identifiées ont reçu le traitement prévu.
Ce qu’il faut retenir
- Arrêtez la source avant de traiter l’historique.
- Définissez précisément paramètres, périodes et copies.
- Suivez l’exécution et l’analyse de risque associée.
FAQ
Modifier une dimension personnalisée efface-t-il les données ?
Ne le supposez pas. Vérifiez les mécanismes de suppression documentés et leur effet réel sur les données déjà stockées.
Une demande de suppression prouve-t-elle que tout est effacé ?
Elle prouve une démarche. Il faut suivre son statut, son périmètre et les copies qui ne dépendent pas de ce mécanisme.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.