Données client hachées
Aussi appelé : hachage, hachage SHA-256, correspondance avancée, paramètres client
Les données client hachées sont les détails client attachés à un événement après passage dans une fonction à sens unique, en général SHA-256, pour que la plateforme publicitaire reçoive une chaîne de longueur fixe plutôt que l'email ou le téléphone lui-même. La plateforme hache ses propres fiches de la même façon et compare les deux chaînes.
Pourquoi hacher si la plateforme peut quand même rapprocher ?
Rapprocher et lire sont deux choses différentes. La plateforme peut constater que deux empreintes sont identiques sans qu'on lui ait remis l'adresse qui les a produites, et rien de lisible ne traverse le réseau ni ne s'écrit dans un journal. Cela réduit ce qu'une fuite sur le trajet exposerait.
Pourquoi la normalisation décide-t-elle si le hachage fonctionne ?
Parce que le hachage est exact. "Jane@Example.com " et "jane@example.com" produisent des empreintes totalement différentes, donc un espace de trop ou une majuscule est une correspondance perdue en silence. Les détails doivent être mis en minuscules, détourés, et les téléphones au format international avant hachage, à chaque fois et des deux côtés.
Une donnée hachée reste-t-elle une donnée personnelle ?
Traitez-la comme telle. Un hachage n'est ni un chiffrement ni une anonymisation : la même entrée donne toujours la même sortie, donc une empreinte identifie encore une personne pour qui détient la fiche correspondante. Cela réduit l'exposition, cela ne retire pas l'obligation de la manipuler avec soin.
Sources
- Meta exige que les paramètres client comme l'email et le téléphone soient normalisés puis hachés en SHA-256 avant d'être envoyés à la Conversions API.Meta for Developers
- wesaw normalise et hache sur ses propres serveurs et jamais dans le navigateur, et attache quatorze paramètres de correspondance par achat là où une configuration par défaut en attache quatre.wesaw, boutique de test
Dernière révision :