TikTok Events API : filtrer les données transmises
TikTok Events API : examinez URLs, propriétés et identifiants, bloquez les données interdites et contrôlez les flux serveur avant leur envoi.
- Ce que l’API transmet et ce qu’elle ne décide pas
- Inspecter l’événement entier
- Une fiche d’événement remplie avant le développement
- Hacher une coordonnée ne la rend pas anonyme
- Appliquer les choix jusque dans la file d’attente
- Dédupliquer sans confondre qualité et autorisation
- Recevoir le flux et réagir à une alerte
- Ce qu’il faut retenir
- FAQ
TikTok Events API ne doit recevoir que les événements et les champs dont l’envoi a été défini, justifié et autorisé. Le passage par votre serveur ne remplace ni le consentement éventuellement requis pour la collecte, ni la base légale du traitement, ni le respect des restrictions de TikTok. Un événement accepté techniquement peut rester excessif ou illicite.
La première mesure utile est de construire une liste de données autorisées pour chaque événement. N’envoyez pas l’objet complet d’une commande ou d’un formulaire en comptant sur quelques suppressions après coup. Examinez aussi les files d’attente, les reprises sur erreur et les journaux : ils peuvent prolonger un envoi après un refus ou conserver une copie inutile.
Ce que l’API transmet et ce qu’elle ne décide pas
TikTok présente Events API comme une connexion permettant de partager des données marketing provenant notamment du web, d’applications et de circuits hors ligne. La documentation recommande son association avec le Pixel pour certains usages web. Cette recommandation commerciale n’oblige pas votre entreprise à transmettre tous les signaux disponibles.
Trois décisions doivent rester distinctes : l’événement est-il admissible dans votre traitement ? Les données retenues correspondent-elles au besoin et aux règles applicables ? La configuration technique transmet-elle exactement ce périmètre ? Une réponse favorable à la troisième ne résout pas les deux premières.
Pour une chaîne web comportant lecture ou écriture dans le terminal, l’article 82 de la loi Informatique et Libertés s’applique selon ses conditions et exceptions. Une API serveur ne doit pas servir à poursuivre la collecte publicitaire refusée dans le navigateur. Pour un événement provenant d’un autre circuit, il faut analyser ce circuit concret plutôt que présumer que tout envoi serveur utilise nécessairement un cookie.
Les Art. 5(1), 6(1) et, lorsqu’il est concerné, 9 du RGPD restent applicables aux données personnelles. L’existence de la commande dans votre système ne suffit pas à justifier sa transmission publicitaire.
Inspecter l’événement entier
La documentation TikTok sur les données potentiellement interdites demande de revoir les intégrations Pixel et Events API, notamment les URL, paramètres et noms d’événements ou d’audiences. Elle cite des informations de santé et financières parmi les données problématiques. Les contrôles du fournisseur ne retirent pas la responsabilité de l’annonceur sur ce qu’il transmet.
Il faut donc examiner le sens de l’ensemble. Un événement nommé « achat » peut être accompagné d’un nom de produit révélateur. Une URL apparemment ordinaire peut contenir une adresse électronique ou un identifiant de dossier. Un champ de recherche peut reprendre librement ce qu’une personne vient de saisir.
Renommer un parcours ne suffit pas si les autres éléments permettent encore d’en comprendre la nature. Pour les pages sensibles, la bonne décision peut être l’exclusion complète du flux publicitaire, plutôt qu’un nettoyage cosmétique du libellé.
Les restrictions contractuelles du service et l’Art. 9 du RGPD ne sont pas deux listes identiques. Une donnée peut être interdite par le fournisseur sans relever d’une catégorie particulière de l’Art. 9. À l’inverse, sa présence dans un format accepté ne démontre pas que ses conditions légales de traitement sont réunies.
Une fiche d’événement remplie avant le développement
Prenons une boutique fictive de vases qui prépare une mesure de commandes web. Le projet T08 retient uniquement les commandes dont le parcours autorise le traitement publicitaire défini. La fiche suivante décrit des décisions de données ; elle n’est pas une charge JSON prête à envoyer ni le résultat d’un essai de l’API.
| Élément disponible dans la boutique | Décision proposée pour T08 | Motif |
|---|---|---|
| Type d’action : achat confirmé | Retenu, avec correspondance vers l’événement documenté dans l’intégration | Décrire l’action mesurée |
| Identifiant de l’événement | Référence technique propre à cet événement | Suivre les copies du même événement sans utiliser l’adresse du client comme clé |
| Valeur et devise | Retenues si nécessaires à la mesure choisie | Éviter les propriétés commerciales sans utilité |
| Page de confirmation avec paramètres | Remplacée par le périmètre de page autorisé, sans paramètres personnels | Ne pas envoyer le contenu brut de l’URL |
| Commentaire de livraison | Exclu | Texte libre sans nécessité publicitaire |
| Recherche saisie sur le site | Exclue | Information non nécessaire au périmètre retenu |
| Coordonnées de rapprochement | Examen séparé avant toute activation | Format technique et licéité à établir ensemble |
Le développeur construit le message à partir des seuls champs approuvés. Si le logiciel de commande ajoute demain « commentaire du service client », ce champ n’entre pas automatiquement dans l’envoi.
Le nettoyage des URL doit aussi être défini avant que les données soient copiées dans un journal ou un intermédiaire. Le guide des paramètres UTM traite les informations personnelles cachées dans les liens. Retirer un paramètre seulement dans la dernière requête ne supprime pas les copies précédentes.
Hacher une coordonnée ne la rend pas anonyme
La documentation de rapprochement Events API prévoit notamment des clés telles que l’identifiant de clic, les coordonnées hachées et certains identifiants externes. Elle exige le hachage pour l’adresse électronique, le téléphone et l’identifiant externe lorsqu’ils sont transmis. Elle distingue aussi la configuration de l’adresse IP et de l’agent utilisateur selon Pixel ou Events API.
Ces indications décrivent des possibilités et exigences de format. Elles ne démontrent pas que votre entreprise doit activer toutes les clés. Le besoin de mesure, l’information, le fondement et les choix applicables doivent précéder cette activation.
Un hachage destiné à retrouver la même personne dans une autre base conserve précisément une fonction de rapprochement. Il ne permet donc pas de qualifier automatiquement la donnée d’anonyme. L’Art. 4(1) et (5) du RGPD distingue identification indirecte et pseudonymisation.
TikTok décrit par ailleurs un Advanced Matching automatique capable d’identifier des champs de formulaires sur les pages où le Pixel est installé. Si cette option fait partie de votre montage, examinez-la séparément de votre filtre serveur. Maîtriser un message Events API ne prouve pas que le Pixel n’effectue aucune autre collecte.
Appliquer les choix jusque dans la file d’attente
Dans T08, la transmission publicitaire repose sur un accord couvrant le parcours retenu. L’équipe doit pouvoir relier l’événement au choix applicable et à sa portée. Un champ booléen « consentement = vrai » sans finalité, contexte ou provenance n’est pas une démonstration suffisante.
Le refus doit empêcher l’envoi concerné. Le retrait doit être pris en compte dans les opérations futures, y compris lorsqu’un événement attend encore dans une file ou qu’un connecteur essaie de le renvoyer. Ne considérez pas une erreur réseau comme une autorisation de réexpédier indéfiniment une ancienne copie.
Pour T08, la règle de conception est de réexaminer l’autorisation avant l’expédition effective et de bloquer les éléments devenus incompatibles avec le choix applicable. Cette règle doit être traduite dans le connecteur, pas seulement dans la fenêtre de cookies. Le guide Meta Conversions API expose ce même risque de divergence entre navigateur et serveur, sans présumer que les deux produits ont les mêmes commandes.
Les durées de conservation des événements en attente et des traces doivent être justifiées. Une file publicitaire n’a pas à devenir une archive complète des commandes. Les données nécessaires à la facturation ou au service client suivent leurs propres finalités, dans leurs systèmes adaptés.
Dédupliquer sans confondre qualité et autorisation
Lorsque Pixel et Events API partagent deux copies de la même conversion, TikTok documente une déduplication reposant notamment sur le même événement et le même event_id. La fonction évite le double comptage dans les conditions prévues par sa documentation ; elle ne décide pas si les données pouvaient être envoyées.
Dans T08, deux copies de l’achat témoin doivent porter la même référence d’événement. Deux commandes différentes doivent rester distinguables. Le responsable technique doit donc vérifier le mécanisme qui crée et conserve cette référence lors d’une reprise, sans réutiliser par commodité une clé unique pour tous les achats d’une personne.
La réception comporte deux constats séparés : nombre d’événements comptabilisés et conformité des transmissions. Un événement dédupliqué correctement peut contenir un commentaire interdit. Un seul événement autorisé peut être compté deux fois à cause d’une mauvaise référence. Les remèdes ne sont pas les mêmes.
Recevoir le flux et réagir à une alerte
Préparez des événements de démonstration pour les parcours sans accord, avec accord, après retrait et avec reprise technique. Pour chacun, conservez le résultat attendu, les champs construits, les destinataires et l’observation effectuée. Aucun test réel de compte publicitaire n’est rapporté ici.
Dans le parcours sans accord de T08, l’attendu est l’absence de transmission publicitaire. Dans celui autorisé, l’équipe compare le message avec la fiche de données approuvée. Pour le retrait, elle examine aussi la file et les autres connecteurs. La réception ne repose pas uniquement sur l’absence de notification dans Events Manager.
Si une notification ou un contrôle révèle un champ non admis, bloquez le circuit concerné, identifiez sa source et recherchez les copies déjà transmises. Corrigez la construction du message, puis reprenez les parcours pertinents avant réactivation. Une autre version du formulaire ou du sous-domaine peut appeler le même connecteur : il faut examiner ce périmètre commun.
Le traitement des envois passés est distinct du correctif. Demandez au fournisseur les suites disponibles et évaluez vos obligations selon les données, les destinataires et les circonstances. L’éventuelle qualification de violation et les Art. 33–34 du RGPD dépendent des faits ; toute alerte de politique publicitaire ne constitue pas automatiquement une violation notifiable.
Ce qu’il faut retenir
Filtrez l’événement avant son envoi, y compris ses URL et propriétés. Examinez les clés de rapprochement et les collectes parallèles. Respectez les choix dans les reprises serveur, puis contrôlez séparément l’admissibilité des données et leur déduplication. Une API fonctionnelle ne vaut pas validation juridique.
FAQ
L’API peut-elle remplacer le Pixel pour éviter les cookies ?
Elle peut modifier le circuit technique, mais il faut examiner l’origine des données et toutes les opérations du montage. Retirer le Pixel ne supprime pas nécessairement les accès au terminal ni les traitements personnels. La décision doit porter sur le flux réellement retenu.
Faut-il envoyer toutes les clés proposées pour améliorer le rapprochement ?
Non par principe. La documentation de format ne dispense pas de limiter les données nécessaires et de justifier leur transmission. Une amélioration espérée de la mesure ne suffit pas à autoriser des champs supplémentaires.
Une alerte disparue prouve-t-elle que tout est corrigé ?
Non. Vérifiez les parcours et les messages concernés, puis conservez les résultats. La disparition d’un signal ne prouve ni l’absence d’autres champs problématiques ni le traitement des données déjà envoyées.
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.