Traqio.

Concepts

Déduplication des événements avec Meta et TikTok

Si votre app embarque le SDK Meta ou TikTok à côté de Traqio, la même conversion arrive deux fois au réseau. Un event_id partagé la fait compter une fois.

La déduplication des événements est la façon dont un réseau publicitaire reconnaît que deux événements reçus sont la même conversion. Elle compte quand votre app embarque le SDK du réseau à côté de Traqio — courant pendant une migration : l’achat atteint Meta ou TikTok une fois depuis l’appareil et une fois depuis le serveur de Traqio. Sans event_id partagé, le réseau compte chaque conversion deux fois et optimise sur un signal doublé.

Sur quoi les réseaux font la correspondance#

RéseauMême conversion quand…Fenêtre
Metamême dataset, même nom d’événement, même identifiant d’événement48 heures
TikTokmême source de données, même type d’événement, même identifiant d’événement — le premier l’emporte48 heures

Deux conséquences. L’identifiant n’a besoin d’être unique que par source de données et par nom d’événement : Traqio le limite donc à l’app. Et le nom doit concorder autant que l’identifiant — c’est pourquoi Traqio traduit ses noms d’événements en noms standard des réseaux, ceux-là mêmes que leurs SDK enregistrent.

Rien à faire pour les installations

Meta ne déduplique pas les installations d’app — il garantit déjà une seule installation attribuée par appareil sur 90 jours —, il n’y a donc aucun identifiant d’événement à passer pour une installation.

Quels événements peuvent être dédupliqués#

Événement transmis par TraqioSon event_idVotre app peut-elle le calculer ?
Un achat suivi avec transactionId (SDK React Native, Expo, Capacitor)dérivé de votre app et de l’identifiant de transaction du storeoui — avec la recette ci-dessous
Un achat reçu de RevenueCatdérivé de la même façon, à partir de l’identifiant de transaction du storeoui — le même identifiant
Tout autre événement du SDKun identifiant aléatoire que le SDK génère pour cet événementnon

Envoyez donc les achats depuis les deux émetteurs avec l’identifiant partagé, et chaque autre événement depuis un seul émetteur — via Traqio, ou via le SDK du réseau, pas les deux.

La recette de l’event_id#

event_id = "tq1_" + sha256(canonical).hex()[0:32]

canonical = "tq1|" + productId + "|" + eventName + "|" + seed                         # preferred
canonical = "tq1|" + productId + "|" + eventName + "|" + externalId + "|" + ts
                   + "|" + value + "|" + currency                                 # fallback

Pour un achat, les entrées sont :

  • productId — l’identifiant Traqio de votre app : l’id renvoyé par GET /v1/products, également visible dans la barre d’adresse de la console (/a/<productId>).
  • eventName — purchase, quel que soit le nom sous lequel votre app l’a suivi.
  • seed — le store, deux-points, puis l’identifiant de transaction du store : app_store:2000000812345678, play_store:GPA.1234-5678-9012-34567.

Chaque entrée est débarrassée de ses espaces en début et fin et mise en minuscules avant la concaténation. (La forme de repli est celle qu’utilise Traqio pour les événements qui n’ont aucune clé métier ; votre app n’en a jamais besoin.) Vecteur de référence, pour tester une implémentation :

tq1|com.acme.app|purchase|gpa.1234-5678-9012-34567
  → tq1_4cbaf318d03260b6dc8bd21e33b56d40

Le préfixe tq1_ versionne la recette : une autre recette aurait un autre préfixe et ne redéfinirait jamais celle-ci, si bien que les identifiants déjà calculés par les builds d’app publiés continuent de correspondre.

Passer l’identifiant au SDK du réseau#

Meta#

Les App Events prennent l’identifiant en paramètre nommé event_id — en snake case, écrit à la main. Pas eventID, qui est l’orthographe du Pixel web : sur un événement d’app, il est conservé en silence comme paramètre personnalisé et rien n’est dédupliqué.

// facebook-android-sdk — "event_id" is a literal key: there is no constant for it
val params = Bundle().apply { putString("event_id", traqioEventId) }
AppEventsLogger.newLogger(context).logEvent("fb_mobile_purchase", 9.99, params)

TikTok#

// tiktok-business-android-sdk — the event id is the builder's second argument
TikTokBusinessSdk.trackTTEvent(
  TTBaseEvent.newBuilder("CompletePayment", traqioEventId)
    .addProperty("currency", "EUR")
    .addProperty("value", 9.99)
    .build()
)

Sur le réseau, le SDK TikTok place votre identifiant dans tt_event_id et remplit event_id avec un UUID aléatoire qui lui est propre, utilisé pour ses nouvelles tentatives d’envoi. C’est normal : ne déboguez pas la déduplication en comparant les payloads — comparez l’identifiant que vous avez passé avec celui de Traqio.

Ce que Traqio garantit#

  • Meta et TikTok reçoivent toujours le même identifiant pour le même événement.
  • Un identifiant vide n’est jamais envoyé : un identifiant est dérivé à la place.
  • Une requête renvoyée porte le même identifiant, octet pour octet : les nouvelles tentatives de Traqio ne peuvent donc pas compter en double.
  • Les achats venant de RevenueCat sont indexés sur l’identifiant de transaction du store — la même clé qu’obtient un achat du SDK avec un transactionId — si bien que le même achat venu des deux chemins est aussi un seul événement dans Traqio.

Questions fréquentes#

Ai-je besoin de la déduplication si je n’utilise que Traqio ?
Non. La déduplication compte quand la même conversion atteint Meta ou TikTok depuis deux émetteurs — en général le SDK du réseau dans votre app et la transmission côté serveur de Traqio. Avec Traqio seul, il n’y a qu’un émetteur, et les nouvelles tentatives de Traqio réutilisent le même identifiant d’événement : une nouvelle tentative n’est donc jamais une seconde conversion.
Pendant combien de temps Meta et TikTok dédupliquent-ils ?
48 heures. Deux événements avec la même source de données, le même nom d’événement et le même identifiant d’événement, arrivés à moins de 48 heures d’intervalle, comptent une fois. Le même achat renvoyé trois jours plus tard compte légitimement deux fois — ce n’est pas un bug de déduplication.

Mis à jour le 14 octobre 2026