Comment mettre en place un bon tracking d'attribution : le systeme complet, couche par couche

Une boîte qui dépense sérieusement en publicité a presque toujours le même problème. Meta annonce un ROAS de 5. Google en revendique un autre. TikTok un troisième. Et quand le dirigeant additionne les trois dashboards, il obtient plus de ventes que la boutique n'en a jamais encaissé. La donnée est partout, et pourtant personne dans la boîte ne sait quel chiffre est vrai.

Ce n'est pas un problème d'outil. C'est un problème d'architecture. Un bon tracking n'est pas un logiciel qu'on installe, c'est une pile de couches qu'on monte dans le bon ordre, de la fondation jusqu'à la mesure stratégique. Chaque couche règle un problème précis, et chacune ne tient que si celle du dessous est propre. Cet article est le plan de cette pile. À la fin, vous saurez exactement quoi brancher, dans quel ordre, et pourquoi.

Au menu :

• Le squelette d'un système de vente, pour situer le vôtre en trente secondes.
• Les cinq systèmes de vente les plus courants, et pourquoi le vôtre fait décrocher l'attribution.
• La fondation que 90% des boîtes bâclent, et pourquoi tout s'effondre dessus.
• Pourquoi votre pixel est devenu à moitié aveugle depuis 2021.
• La déduplication pixel plus CAPI expliquée exactement, l'erreur que presque tout le monde fait.
• Comment renvoyer aux plateformes vos ventes Stripe réellement encaissées.
• La couche stratégique, MMM et incrémentalité, et l'écart chiffré entre le ROAS déclaré et la vérité causale.

Le squelette d'un système de vente : les 3 points de collecte

Avant de parler pixel, CAPI ou UTM, il faut voir le squelette. Tout système de vente, du e-commerce au high ticket, fait passer un prospect par trois points de collecte. À chaque point, une information doit être captée puis transmise au suivant. Si un seul maillon perd le fil, tout ce qui suit devient un chiffre orphelin.

Le point d'entrée, c'est la source du clic : organique, publicité, email. Ce qui compte ici, c'est le marqueur qui dit d'où vient la personne, porté par vos UTM et par les identifiants de clic que les plateformes collent à l'URL (fbclid pour Meta, gclid pour Google, ttclid pour TikTok).

Le point de collecte intermédiaire, c'est là où le prospect laisse une trace : landing page, formulaire, prise de rendez-vous. Le pixel se déclenche et, surtout, doit conserver le marqueur d'entrée pour l'attacher au lead. Le server-side, via la Conversions API, sécurise cet envoi quand le navigateur bloque le pixel.

Le point de collecte final, c'est la vente : commande Shopify, paiement Stripe, deal gagné dans le CRM. Cette vente doit repartir vers votre système de mesure et être rapprochée du marqueur d'origine. C'est ce rapprochement, et lui seul, qui relie un euro encaissé à la pub qui l'a déclenché.

La règle tient en une phrase : le marqueur doit survivre aux trois points. La plupart des outils d'attribution ne cassent pas. C'est la chaîne qui est trouée quelque part, et l'outil ne peut relier que ce que le funnel lui laisse relier.

Reconnaissez votre système : 5 funnels, un seul squelette

Votre système ressemble à l'un de ces cinq. Le squelette ne change pas ; seule la longueur de la chaîne change, et avec elle le nombre d'endroits où le marqueur peut se perdre.

• E-commerce : chaîne courte, du clic au paiement Shopify en quelques minutes. Risque faible par vente, mais le volume amplifie la moindre fuite.
• High ticket : chaîne longue et humaine. VSL, rendez-vous, call, closing dans le CRM. Des jours entre le clic et la vente, autant d'occasions de perdre le marqueur.
• Lead gen B2B et agence : le formulaire capte le lead, le CRM porte le pipeline. Tout se joue sur le passage du marqueur du formulaire au CRM.
• SaaS et abonnement : signup ou essai, puis paiement récurrent Stripe souvent des semaines plus tard. Le délai est l'ennemi numéro un du marqueur.
• Info-produit : webinaire ou tunnel, paiement, upsell. Les changements de domaine entre les pages cassent souvent la continuité.

Pourquoi « les outils d'attribution ne marchent pas » (le vrai coupable)

Un cas qu'on voit sans arrêt. Un SaaS explose après un passage sur le podcast Legend : l'audience afflue, l'équipe ouvre grand les budgets pub. Sur le papier, la croissance est là. Dans les faits, personne ne sait quelle campagne rapporte, parce que le marqueur du clic ne survit pas jusqu'à l'abonnement Stripe encaissé des semaines plus tard. Bilan : près de 200 000 euros engloutis en publicité avant que quiconque réalise qu'on pilotait à l'aveugle. Le problème n'était pas l'outil. C'était la chaîne, trouée entre le signup et le paiement récurrent.

C'est le quotidien de milliers de boîtes. Un système bricolé au fil des années, des outils empilés, et une frustration : l'attribution ne marche pas. Mais on demande à l'outil un tour de magie sans lui donner les cartes. Un logiciel d'attribution ne devine rien ; il relie ce que la chaîne lui transmet.

D'où le renversement le plus rentable de tout cet article : il est presque toujours plus simple d'ajuster légèrement votre funnel pour qu'il colle à l'attribution que d'attendre de l'attribution qu'elle rattrape un funnel troué. Un paramètre conservé ici, un champ ajouté là, un domaine unifié, et le marqueur survit. C'est ce que les couches suivantes vont vous apprendre à faire, une par une.

De la chaîne aux 7 couches : acheminer, puis vérifier

Vous tenez le squelette. Reste à savoir ce qu'un système en fait, concrètement. Deux jobs, pas un, et les confondre est l'erreur qui ruine le plus de stacks.

La première, c'est acheminer le signal : capter les événements sur votre site et les faire remonter aux plateformes pour qu'elles optimisent. Le pixel, la Conversions API, le server-side, tout ça sert à ça. C'est de la plomberie. Ça déplace la donnée, ça ne la juge pas.

La seconde, c'est vérifier, de façon indépendante, ce que ces plateformes prétendent. Rapprocher leurs déclarations de ce que vous avez réellement encaissé, dédupliquer entre canaux, et mesurer ce que la pub a vraiment causé. C'est de la comptabilité et de la science, pas de la plomberie.

Le piège classique, c'est de croire qu'améliorer la première couche améliore la seconde. Brancher la CAPI récupère plus d'événements, mais ces événements restent notés par la partie qui vend les pubs. La CAPI répare ce que la plateforme voit, pas ce qui marche vraiment. Gardez cette distinction en tête : les couches 1 à 4 acheminent le signal, les couches 5 à 7 le vérifient.

Couche 1 : nomenclature et UTMs, la fondation que tout le monde bâcle

Tout commence par la façon dont vous nommez les choses. Les paramètres UTM sont cinq bouts de texte ajoutés à vos liens que votre analytics lit pour savoir d'où vient un visiteur : utm_source (la plateforme, par exemple meta ou google), utm_medium (le type de canal, cpc, social, email), utm_campaign (la campagne), et deux optionnels, utm_content (pour distinguer deux créas) et utm_term (à l'origine le mot-clé, aujourd'hui souvent l'audience).

Ça paraît trivial, et c'est pourtant là que 90% des systèmes se cassent, en silence. Trois règles évitent le chaos. D'abord, tout en minuscules, sans exception, parce que votre analytics est sensible à la casse et que Google et google deviennent deux sources différentes qui fragmentent vos rapports. Ensuite, des tirets entre les mots plutôt que des espaces ou des tirets bas, pour ne pas voir apparaître des %20 dans vos données. Enfin, une seule taxonomie documentée, un tableur qui fige le vocabulaire autorisé et que toute l'équipe respecte, idéalement via un générateur d'UTM qui n'accepte que les valeurs validées.

Un piège technique mérite d'être connu. Ne taguez jamais manuellement vos URLs finales Google Ads avec des UTMs. Google utilise son propre mécanisme, l'auto-tagging, qui ajoute un identifiant gclid au lien. Ajouter vos UTMs par-dessus peut écraser ce gclid et casser l'import de conversions entre Google Ads et votre analytics. Laissez l'auto-tagging faire son travail sur Google, et réservez les UTMs manuels aux canaux qui n'en ont pas, comme l'email, le social organique ou les partenaires. Une convention de nommage de campagne parlante par-dessus, du type plateforme-objectif-audience, rend vos rapports lisibles sans effort. Cette discipline de nommage est le socle de tout ce qui suit, et elle recoupe le premier des trois niveaux d'attribution qu'une boîte doit gravir.

Couche 2 : le pixel, et pourquoi le navigateur est devenu aveugle

Le pixel est un bout de JavaScript qui se charge dans le navigateur du visiteur. Au chargement d'une page il déclenche un événement de base, le PageView, puis des événements standard quand l'utilisateur agit : ViewContent, AddToCart, InitiateCheckout, Purchase avec la valeur et la devise. Il lit et pose des cookies first-party, et transmet ces événements à la plateforme depuis le navigateur.

Le problème, c'est que ce canal s'est érodé, et il faut comprendre pourquoi pour saisir tout le reste. Quatre forces l'ont rendu partiellement aveugle. La plus connue est l'App Tracking Transparency d'Apple, arrivée avec iOS 14.5 le 26 avril 2021 : quand un utilisateur clique une pub Meta dans l'app iOS et refuse le suivi, le lien entre l'exposition à la pub et la conversion sur votre site est coupé. La deuxième est la protection anti-tracking de Safari, qui plafonne à sept jours la durée de vie des cookies posés en JavaScript, si bien que les identifiants expirent vite. La troisième, ce sont les bloqueurs de pub, qui empêchent purement et simplement le script de se charger ou d'émettre. La quatrième, le consentement : un utilisateur qui refuse les cookies bloque le pixel.

Le résultat net, c'est que le pixel sous-compte et sous-associe systématiquement. On ne connaît pas de taux de perte universel et fiable, alors méfiez-vous des chiffres ronds que citent les vendeurs. Ce qui compte, c'est le principe : le navigateur seul ne suffit plus, et c'est exactement pour ça qu'existe la couche serveur. Nous avons détaillé cette bascule dans notre article sur le server-side face au pixel.

Couche 3 : les connexions plateformes et les identifiants de clic

Les plateformes connaissent votre dépense nativement, puisque c'est leur facturation. Ce qu'elles ne voient pas, ce sont vos conversions, qui se produisent chez vous. Pour faire le lien, chaque plateforme marque chaque clic d'un identifiant qu'elle pourra ensuite rapprocher d'une conversion que vous lui renvoyez.

Chez Google, l'auto-tagging ajoute un gclid à l'URL d'atterrissage, stocké dans un cookie first-party, que Google relit au moment de la conversion pour rattacher le clic exact. Le gclid est sensible à la casse, et sur iOS où il n'est pas disponible, Google utilise gbraid et wbraid. Chez Meta, trois identifiants comptent : le fbclid ajouté à l'URL au clic, le cookie _fbp qui identifie le navigateur de chaque visiteur, et le cookie _fbc construit à partir du fbclid. Ce _fbc ne doit jamais être haché ni fabriqué : on ne le crée qu'à partir d'un vrai fbclid.

Ces identifiants permettent une association déterministe entre votre conversion et le clic d'origine, bien plus fiable que la modélisation probabilistique à laquelle la plateforme recourt quand ils manquent. C'est aussi à cette couche que se joue une source majeure de confusion : chaque plateforme applique sa propre fenêtre d'attribution.

Ces fenêtres différentes expliquent une bonne partie des chiffres qui ne collent pas d'un dashboard à l'autre, un sujet qu'on creuse dans le guide de déduplication des conversions.

Couche 4 : le server-side et la Conversions API

Voici la couche qui répare l'érosion du pixel. Au lieu d'émettre l'événement depuis le navigateur, votre serveur l'envoie directement à la plateforme, de serveur à serveur. Parce qu'il ne tourne pas dans le navigateur, il contourne les bloqueurs de pub, le plafond de cookies de Safari, et une bonne partie de la perte liée à l'ATT.

La recommandation officielle de Meta est d'envoyer le même événement des deux côtés à la fois, par le pixel et par la Conversions API. Cette redondance maximise le taux d'association. Mais elle crée un risque évident : compter deux fois la même vente. C'est là qu'intervient la déduplication, et il faut la comprendre exactement, parce que c'est l'erreur la plus fréquente du métier.

La dédup se fait sur deux choses : un event_id unique que vous générez pour chaque action et que vous envoyez identique depuis le pixel et depuis la CAPI, et le event_name. Si Meta reçoit deux événements avec le même event_id et le même event_name dans une fenêtre de 48 heures, il les traite comme une seule action et n'en garde qu'une. L'event_id doit correspondre au caractère près, et un event_name mal orthographié, Purchase contre purchase, casse la dédup et double le comptage. Point crucial que presque tout le monde se trompe : les identifiants fbp et fbc ne servent pas à la déduplication. Ils servent au matching, c'est-à-dire à relier l'événement à un utilisateur et à un clic. La dédup, elle, se fait uniquement sur event_id plus event_name. Une mauvaise installation server-side est pire que pas d'installation du tout, parce qu'elle échoue en silence.

Un indicateur pratique à surveiller sur cette couche est l'Event Match Quality de Meta, une note de 1 à 10 qui mesure la qualité de l'association entre vos événements et des comptes Meta. Le server-side la relève mécaniquement en transportant des identifiants plus riches au moment du checkout. Mais gardez la tête froide : c'est un proxy du taux d'association, pas une garantie de performance ni de vérité.

Les autres plateformes suivent la même logique. Google propose les Enhanced Conversions, qui envoient des données first-party hachées en SHA-256 au moment de la conversion, et l'import de conversions hors ligne. Pour les parcours de lead et de vente longue, Google recommande désormais les Enhanced Conversions for Leads, qui capturent les données hachées à la soumission du formulaire puis rattachent la vente signée en aval sans avoir à stocker le gclid. À noter pour les nouveaux montages : à partir du 15 juin 2026, ces imports migrent vers la Data Manager API de Google et ne passeront plus par l'ancienne API. TikTok a son Events API, avec la même dédup sur event_id plus event_name en 48 heures. Et le Consent Mode de Google gère le consentement en modélisant les conversions perdues quand l'utilisateur refuse. Un dernier point d'honnêteté, développé dans notre article sur les conversions hors ligne : récupérer plus d'événements n'est pas la même chose que mesurer l'incrémental. Le server-side remonte plus de conversions, mais certaines auraient eu lieu de toute façon.

Couche 5 : la vérité du revenu, depuis Stripe et le CRM

Le pixel enregistre une valeur de Purchase au moment du checkout. Mais cette valeur, c'est une intention d'achat, pas du cash encaissé. Le vrai revenu vit ailleurs : dans Stripe et dans votre CRM. Des essais qui se transforment, des abonnements qui se renouvellent, des paiements échelonnés, des paiements qui échouent puis réussissent, des remboursements, des impayés. Renvoyer aux plateformes le revenu réellement encaissé, et non la valeur affichée au checkout, change la donne, parce que leurs algorithmes d'enchères se mettent alors à optimiser pour la vraie valeur.

La mécanique tient en quatre gestes. D'abord, capter les clés d'association au moment du checkout et les stocker durablement : le fbc et le fbp, le gclid, et l'email haché, dans les métadonnées Stripe du client et dans le CRM. C'est le pivot de tout, parce que vous ne pourrez rapprocher un paiement Stripe futur d'une pub que si vous avez conservé ces clés au moment de l'acquisition. Ensuite, écouter les webhooks Stripe qui signalent l'argent réel : checkout.session.completed, invoice.paid à chaque échéance, charge.refunded pour les remboursements. Puis, à chaque webhook, pousser une conversion serveur vers Meta et Google avec la valeur réellement encaissée et l'horodatage du vrai paiement. Enfin, gérer les remboursements en renvoyant des ajustements de conversion, ce qui permet de reprendre au ROAS déclaré l'argent qui a été rendu.

C'est aussi ici que se distinguent deux chiffres qu'il faut toujours afficher côte à côte : la valeur signée du deal, utile pour prévoir, et le cash réellement encaissé, qui est la réalité. Un deal à 6 000 euros en six fois se lit 6 000 dans la plupart des outils dès la signature, alors que seuls 1 000 ont touché la banque. La même prudence vaut pour la valeur vie client. Prenez deux clients : l'un a signé 4 500 euros payés en trois fois, tous reçus, l'autre 3 000 euros en six fois, dont deux échéances encaissées. La LTV promise est de 7 500 euros, la LTV réalisée de 5 500. Sur une acquisition Meta à 800 euros, cela donne 9,4 de ROAS promis contre 6,9 de ROAS réel. Piloter sur le premier chiffre, c'est scaler sur de l'argent qui n'est pas encore en banque. C'est tout l'objet de notre article sur les paiements échelonnés. Soyez honnête sur la difficulté : les clés d'association ont une durée de vie limitée, et une vente encaissée 60 ou 90 jours après le clic tombe souvent hors des fenêtres d'attribution, même avec un matching parfait. Le revenu à paiement long est structurellement sous-crédité par les plateformes, et c'est précisément pour ça que la couche suivante existe.

Couche 6 : la réconciliation, votre source de vérité indépendante

Nous entrons dans la deuxième couche du modèle, celle qui vérifie au lieu d'acheminer. Le principe est simple : votre source de vérité, ce ne sont pas les plateformes, c'est votre CRM et votre compte en banque.

Le besoin saute aux yeux avec un exemple. Une seule vente à 500 euros dans votre CRM peut être revendiquée en même temps par Meta dans sa fenêtre de vue, par Google dans sa fenêtre de clic de 30 jours, et par TikTok. Chacune la compte pour elle, et vous vous retrouvez avec 1 500 euros déclarés pour 500 euros encaissés, un ROAS divisé par trois. Ce n'est pas un bug, c'est le modèle économique des plateformes : chacune note sa propre copie et ignore les autres. À l'échelle d'un budget de 10 000 euros, Meta peut déclarer 25 000 euros, Google 18 000 et TikTok 12 000, soit 55 000 euros affichés pour peut-être 25 000 euros réellement encaissés.

Aucune plateforme ne peut résoudre ça, parce qu'aucune ne connaît les déclarations des autres. Seule une source indépendante le peut, et cette source, c'est le revenu encaissé dans votre CRM. Réconcilier, c'est repartir de chaque vente réelle, la rattacher à la campagne qui l'a sourcée, et dédupliquer entre les canaux pour qu'une commande reste une commande. C'est aussi à ce niveau qu'on choisit un modèle d'attribution pour répartir le crédit entre les points de contact, parmi les neuf modèles classiques, du dernier clic au data-driven. Le résultat, c'est l'écart entre le ROAS que la plateforme revendique et le ROAS calculé sur le cash, le seul sur lequel on pilote un budget sans se mentir.

Couche 7 : MMM et incrémentalité, la mesure stratégique

Les six premières couches vous donnent un chiffre fidèle à votre compte en banque, au jour le jour. La septième répond à une question que même la réconciliation ne tranche pas : qu'est-ce que la pub a réellement causé ? Une vente réconciliée reste une vente qui a peut-être eu lieu de toute façon.

Deux méthodes complémentaires vivent ici. Le marketing mix modeling estime la contribution de chaque canal à partir de deux chiffres que vous possédez, la dépense et le revenu, sur des totaux agrégés, sans jamais toucher un identifiant individuel. Il est donc immunisé contre l'ATT et la perte de cookies, ce qui explique pourquoi Meta et Google ont open-sourcé leurs propres outils de MMM, Robyn et Meridian, juste après 2021. Nous l'expliquons de fond en comble dans notre guide du marketing mix modeling. L'incrémentalité, elle, est l'arbitre causal : en comparant un groupe exposé à un groupe témoin délibérément non exposé, un test d'incrémentalité mesure le lift réel, les ventes que la pub a effectivement créées.

L'écart entre ce que l'attribution déclare et ce que l'incrémentalité mesure est énorme, et il est documenté. Dans une étude de référence menée sur quinze expériences randomisées chez Facebook, les auteurs montrent que dans la moitié des cas l'attribution se trompe d'un facteur trois, et dans un cas extrême estime un effet de 1 306 pour cent là où l'expérience n'en mesure que 2,4 (Gordon et al., 2019). L'attribution surestime toujours dans le même sens, et le pire se joue en bas de funnel, sur le retargeting. La leçon pratique : les stacks les mieux pilotées font tourner l'attribution au quotidien, le MMM pour arbitrer le budget par trimestre, et un test d'incrémentalité régulier pour garder l'ensemble honnête.

L'architecture de référence

Mises bout à bout, ces couches forment une boucle fermée. La dépense part vers les plateformes, le clic est marqué, votre site capte l'événement via le pixel et le serveur avec un event_id partagé, le revenu réel est encaissé dans Stripe et le CRM, tout est réconcilié en un chiffre unique, puis les conversions encaissées sont renvoyées aux plateformes pour qu'elles optimisent sur du vrai cash. C'est ce cycle qui transforme des données éparpillées en clarté.

Deux idées suffisent à ne jamais se perdre dans ce schéma. La première, les couches 1 à 4 acheminent le signal, les couches 5 à 7 le vérifient. La seconde, chaque plateforme note sa propre copie, donc le seul juge impartial est votre revenu encaissé. Une boîte qui tient ces deux idées cesse d'additionner des dashboards qui se contredisent et commence à piloter sur un chiffre qu'elle peut défendre.

Les erreurs qui cassent tout, en une checklist

La plupart des systèmes ne tombent pas en panne bruyamment, ils dérivent en silence. Voici les fautes qui reviennent le plus. Un event_name incohérent entre le pixel et la CAPI, qui double le comptage. Un event_id non partagé, qui empêche toute dédup. Des UTMs posés à la main sur Google Ads, qui écrasent le gclid. Des clés d'association jamais stockées à l'acquisition, qui rendent impossible tout rapprochement du revenu Stripe plus tard. Des dashboards qu'on additionne comme si les plateformes ne se recouvraient pas. Et l'absence totale de test d'incrémentalité, qui laisse croire à un ROAS que la pub n'a pas produit. Chacune de ces erreurs est invisible tant qu'on ne va pas voir le cash.

Où la clarté arrive vraiment

Monter cette pile à la main est parfaitement possible, et beaucoup d'équipes techniques le font. Cela demande un container server-side, une discipline sans faille sur les event_id, un stockage durable des clés d'association, une logique de webhooks Stripe, une couche de réconciliation qui déduplique entre canaux, et de quoi faire tourner du MMM. C'est un projet d'ingénierie continu, pas une case à cocher.

C'est exactement le travail que Metrikia opérationnalise, sur la couche 2 du modèle, celle de la vérification. Il connecte votre dépense et votre revenu encaissé, rapproche chaque vente réelle de sa source, déduplique entre les canaux, et pose par-dessus une couche d'analyse IA, Diana, qui lit ces données réconciliées et fait ressortir ce qui a changé et pourquoi. Il ne remplace pas le pixel ni la CAPI, la couche d'acheminement du signal reste chez les plateformes. Il apporte ce que les plateformes ne peuvent pas donner : un chiffre unique, ancré au cash réellement mis en banque, sur tous les canaux. Si vous hésitez entre les outils qui existent pour cette couche, nous les avons tous passés en revue dans notre comparatif honnête des outils d'attribution.

Questions fréquentes

Par où commencer si mon tracking est un chaos ? Par le bas de la pile, toujours. Nettoyez d'abord la nomenclature et les UTMs, parce qu'aucune couche au-dessus ne tient sur une fondation sale. Ensuite, vérifiez que votre pixel et votre CAPI partagent bien un event_id par événement, pour arrêter le double comptage. Ce sont les deux réglages qui débloquent le plus de clarté pour le moins d'effort.

Ai-je besoin du server-side, ou le pixel suffit-il ? Le pixel seul sous-compte depuis iOS 14.5, les bloqueurs de pub et les limites de cookies de Safari. Le server-side récupère une partie de ce signal perdu et améliore le taux d'association. Mais rappelez-vous qu'il achemine mieux le signal sans le rendre plus vrai : il faut la couche de réconciliation par-dessus pour savoir ce que vous avez réellement encaissé.

Comment renvoyer mes ventes Stripe aux plateformes ? En stockant les clés d'association (fbc, fbp, gclid, email haché) au moment du checkout, puis en écoutant les webhooks Stripe pour pousser une conversion serveur à chaque paiement réel, avec la vraie valeur encaissée. Les remboursements se gèrent par des ajustements de conversion. La vraie difficulté n'est pas technique, elle est de fenêtre : une vente encaissée trop tard tombe hors de la fenêtre d'attribution de la plateforme.

Pourquoi mes trois dashboards annoncent-ils plus de ventes que ma banque ? Parce que chaque plateforme note sa propre copie sur sa propre fenêtre, et qu'aucune ne connaît les déclarations des autres. La même vente est comptée par Meta, Google et TikTok à la fois. Le seul moyen de la compter une fois est de repartir du revenu encaissé dans votre CRM et de dédupliquer entre les canaux.

Le MMM et l'incrémentalité, c'est pour les grosses boîtes uniquement ? Le MMM demande de l'historique et un budget significatif, donc il devient pertinent à une certaine échelle. L'incrémentalité, en revanche, est accessible plus tôt : un test geo-lift, qui compare des régions exposées à des régions témoins, se met en place sans identifiant individuel et répond à la seule question qui compte vraiment, ce que la pub a réellement causé.

Références

Apple. (2021). App Tracking Transparency [Documentation développeur]. https://developer.apple.com/documentation/apptrackingtransparency

Google. (s.d.). À propos de l'auto-tagging. Google Ads Help. https://support.google.com/google-ads/answer/3095550

Google. (s.d.). À propos des conversions optimisées (Enhanced Conversions). Google Ads Help. https://support.google.com/google-ads/answer/9888656

Google. (s.d.). Importer des conversions hors ligne avec le GCLID. Google Ads Help. https://support.google.com/google-ads/answer/7012522

Gordon, B. R., Zettelmeyer, F., Bhargava, N., & Chapsky, D. (2019). A comparison of approaches to advertising measurement: Evidence from big field experiments at Facebook. Marketing Science, 38(2), 193-225. https://doi.org/10.1287/mksc.2018.1135

Meta for Developers. (s.d.). Conversions API. https://developers.facebook.com/docs/marketing-api/conversions-api/

Meta for Developers. (s.d.). Handling duplicate pixel and server events. https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events/

Meta for Developers. (s.d.). fbp and fbc parameters. https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc

TikTok for Business. (s.d.). About Events API. https://ads.tiktok.com/help/article/events-api

À propos de l'auteur : Baptiste Noel, cofondateur de Metrikia. MSc en neurosciences cliniques et MSc en haute performance.