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éseau | Même conversion quand… | Fenêtre |
|---|---|---|
| Meta | même dataset, même nom d’événement, même identifiant d’événement | 48 heures |
| TikTok | même source de données, même type d’événement, même identifiant d’événement — le premier l’emporte | 48 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
Quels événements peuvent être dédupliqués#
| Événement transmis par Traqio | Son event_id | Votre 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 store | oui — avec la recette ci-dessous |
| Un achat reçu de RevenueCat | dérivé de la même façon, à partir de l’identifiant de transaction du store | oui — le même identifiant |
| Tout autre événement du SDK | un identifiant aléatoire que le SDK génère pour cet événement | non |
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 # fallbackPour un achat, les entrées sont :
productId— l’identifiant Traqio de votre app : l’idrenvoyé 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_4cbaf318d03260b6dc8bd21e33b56d40Le 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)// facebook-ios-sdk
AppEvents.shared.logEvent(
.purchased,
parameters: [AppEvents.ParameterName(rawValue: "event_id"): traqioEventId]
)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()
)// tiktok-business-ios-sdk
let event = TikTokBaseEvent(eventName: "CompletePayment", eventId: traqioEventId)
TikTokBusiness.trackTTEvent(event)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.