


L'attribution mobile repose sur un MMP (Mobile Measurement Partner) qui suit la donnée du clic publicitaire jusqu'au postback renvoyé à la régie. Il enregistre le clic, récupère l'installation via le SDK ou le store, arbitre entre les réseaux qui revendiquent la conversion, puis renvoie l'événement à Meta ou Google pour nourrir leur algorithme.
Quand un utilisateur clique sur une pub Instagram, télécharge votre application et fait un achat trois jours plus tard, comment Meta sait-il que cet achat vient de sa campagne ? Et surtout, comment pouvez-vous vous assurer que les chiffres présentés par la régie sont exacts ? La réponse s'appelle le MMP (Mobile Measurement Partner). Si vous avez déjà lu notre guide complet des MMP, vous savez qu'ils permettent de mesurer et d'attribuer les installations entre vos différents canaux.
Dans cet article, nous allons suivre le trajet exact de la donnée. Du clic initial de l'utilisateur jusqu'au moment où la plateforme publicitaire reçoit l'information de conversion pour optimiser ses campagnes. C'est la compréhension de ce parcours qui détermine si votre mesure est fiable et si vos décisions budgétaires reposent sur une base solide.
Quand vous investissez sur plusieurs canaux d'acquisition (Meta, Google Ads, TikTok, Snapchat), chaque plateforme vous envoie son propre rapport de performance. Naturellement, chacune s'attribue les conversions générées par ses campagnes. Ces plateformes sont des Self-Attributing Networks (SAN) : elles mesurent leurs résultats à partir de leurs propres données internes.
Le problème survient quand un utilisateur interagit avec plusieurs plateformes avant d'installer votre application. Si vous additionnez les rapports, vous obtenez souvent plusieurs installations revendiquées pour un seul téléchargement réel. Chaque média applique ses propres règles pour s'attribuer le mérite.

C'est pour cela que le MMP existe. Il agit comme un tiers de confiance entre votre application et les réseaux publicitaires. Il impose une logique de mesure unique à l'ensemble de vos canaux. En utilisant un modèle d'attribution commun (souvent le dernier clic avant l'installation), le MMP détermine quelle source reçoit réellement le crédit de la conversion. En pratique, lors d'une installation, le MMP interroge les SAN. Chaque plateforme consulte ses données et lève la main si elle reconnaît l'utilisateur. Le MMP confronte ensuite ces différentes revendications, tranche selon ses règles et attribue l'installation à un seul canal.
Vous obtenez ainsi une vérité commune. Sans cet outil, chaque plateforme raconte sa propre version de l'histoire et il devient impossible de les départager. Pour comprendre comment le MMP arrive à faire ce lien exact entre une publicité et une installation, il faut remonter quelques secondes plus tôt. Au moment précis où l'utilisateur clique sur la publicité.
Derrière la publicité se cache un lien. Pour la majorité des réseaux, il s'agit d'un lien de tracking généré par le MMP. Ce lien transporte les paramètres de votre campagne (le nom du réseau, le groupe d'annonces, le visuel). Quand l'utilisateur clique, sa requête passe par les serveurs du MMP avant de le rediriger vers le store d'applications.
Sur Android, le store participe activement au trajet. Quand le lien redirige vers Google Play, les paramètres de la campagne s'ajoutent à l'URL. Google Play stocke ces informations pendant l'installation. Au tout premier lancement de l'application, le SDK du MMP interroge le store et récupère ces données. Le MMP relie alors l'installation à la campagne de façon certaine. C'est l'une des méthodes d'attribution les plus fiables du marché, et elle fonctionne même quand le téléchargement ne suit pas immédiatement le clic.
Sur iOS, ce mécanisme n'existe pas. Au premier lancement, le SDK envoie simplement les informations du téléphone aux serveurs du MMP. L'outil tente de raccrocher ces données à un clic récent. Si rien ne correspond, il essaie de déduire l'origine par un rapprochement probabiliste. Nous détaillons les contraintes d'Apple dans la section 4.
Il existe une exception importante avec Meta, Google Ads ou TikTok. Ces réseaux ne laissent pas le clic passer par un lien du MMP. Ils enregistrent le clic et gardent la donnée chez eux. Le MMP intervient seulement après le téléchargement : il interroge chaque plateforme avec l'identifiant du téléphone, et chaque réseau répond alors pour revendiquer ou non l'installation. C'est la méthode du « claim-and-confirm ». Concrètement, les deux environnements ne se ressemblent pas :
Peu importe la route empruntée. Le MMP possède maintenant toutes les informations pour attribuer l'installation à la bonne source.
L'utilisateur a cliqué et téléchargé l'application. Il l'ouvre pour la première fois. Pour capter cet instant précis et le relier à la publicité initiale, le MMP s'appuie sur son SDK : une petite boîte à outils que les développeurs glissent dans le code de l'application au moment de sa création. Dès le premier lancement, le SDK collecte les informations de base du téléphone, comme le modèle ou l'identifiant publicitaire si l'utilisateur a donné son accord, et les transmet au MMP pour signaler la nouvelle installation. Le MMP compare alors avec l'historique des clics récents sur vos publicités. Trois règles encadrent ce rapprochement.
La mission du SDK continue bien après l'installation. Il signale au MMP les actions clés de votre choix, comme une inscription ou un achat, et le MMP rattache chaque événement à la campagne d'origine. Vous savez ainsi si votre investissement a réellement rapporté. Un point de vigilance s'impose sur la configuration de ces actions : chaque réseau publicitaire parle sa propre langue. Votre événement d'achat doit donc être traduit dans le terme exact attendu par Meta ou Google. Ce travail de correspondance s'appelle le mapping.
C'est d'ailleurs ici que l'optimisation entre en jeu. Quand le MMP attribue un achat à une campagne, il renvoie automatiquement l'information à la plateforme publicitaire via un signal appelé postback. Ce retour de données nourrit l'algorithme du média : il lui indique le profil exact de l'acheteur pour l'aider à cibler des clients similaires. Sans ce postback, vos réseaux publicitaires tournent à l'aveugle et l'optimisation de vos campagnes devient impossible.
Pour rattacher une installation à une publicité, le MMP s'appuie sur un identifiant unique propre à chaque smartphone. Sur Android, on l'appelle le GAID. Sur iOS, c'est l'IDFA. Ce numéro permet de reconnaître un même appareil entre le moment du clic et l'ouverture de l'application, et le rapprochement est direct et fiable.
Mais ce système a volé en éclats chez Apple.
Depuis 2021, la marque impose un double niveau de consentement. L'utilisateur doit d'abord accepter la classique bannière RGPD. Il doit ensuite valider une seconde fenêtre spécifique à Apple appelée l'ATT, qui lui demande s'il autorise l'application à suivre son activité.
Sans ce double feu vert, l'identifiant publicitaire reste bloqué : le MMP perd son point de repère et le rapprochement avec le clic devient impossible. Ce blocage massif n'existe pas sur Android, avec son consentement unique.
Pour compenser, Apple a imposé sa propre solution de mesure appelée SKAN. Le principe change puisqu'Apple se place au milieu et devient le seul arbitre. Le système constate l'installation et transmet l'information au réseau publicitaire avec une donnée volontairement appauvrie. Il n'y a plus aucune identité et l'envoi subit un délai de plusieurs heures. Ce cadre évolue aujourd'hui avec AdAttributionKit, le framework présenté par Apple à la WWDC 2024 pour succéder à SKAN. Il conserve les mécanismes de confidentialité mais y ajoute la mesure du re-engagement, des fenêtres d'attribution configurables et un support des boutiques d'applications tierces.
À noter que cette transition avance à des vitesses très inégales selon les régies. SKAdNetwork 4 reste la version opérationnelle de référence, et l'adoption d'AdAttributionKit varie d'un réseau à l'autre. Concrètement, vous ne débranchez rien : vous configurez AdAttributionKit en plus, et vous gardez SKAN comme socle.
Sur iOS, l'annonceur troque donc la précision contre la confidentialité. La mesure du MMP reste utile pour valider de grandes tendances d'acquisition, elle ne permet simplement plus l'analyse fine et immédiate possible sur Android. Le fonctionnement des identifiants de clic est détaillé dans notre article sur Gclid, Gbraid et Wbraid.
La question revient souvent chez les entreprises déjà équipées côté data. Elles utilisent une Customer Data Platform, la CDP. Cet outil rassemble l'historique complet d'un utilisateur : ses achats, son comportement dans l'application, ses informations de contact. La CDP sait d'ailleurs envoyer ces données aux plateformes publicitaires. L'ajout d'un MMP semble alors redondant. Pourtant, ces deux outils ne répondent pas du tout à la même question.
La CDP se concentre sur l'identité de l'utilisateur. Elle sait qu'un profil précis appartient au segment des acheteurs fidèles. Elle connaît son panier moyen et son historique de navigation. Mais elle ignore totalement le point de départ de son parcours d'achat : elle ne sait pas s'il a cliqué sur une annonce TikTok ou s'il a cherché l'application de lui-même.
Le MMP se concentre uniquement sur la provenance de cet utilisateur. Sa mission consiste à relier une installation à la bonne campagne publicitaire en arbitrant entre les différents réseaux. Les attributs socio-démographiques du client ne font pas partie de son périmètre. Une CDP qui envoie seule ses données à Meta travaille donc à l'aveugle : elle transmet un volume de conversions sans pouvoir isoler celles générées par la publicité. Le problème d'attribution évoqué dans la première section reste entier.
Ces deux outils sont en réalité strictement complémentaires. Le MMP identifie la source d'acquisition, la CDP enrichit ensuite le profil. Les annonceurs les plus matures déploient les deux systèmes en appliquant une règle stricte : il faut parfaitement coordonner les flux pour éviter d'envoyer la même conversion en double aux régies. Si le sujet vous intéresse, on détaille le fonctionnement d'une CDP comme Segment dans un autre article.
Un MMP mal configuré ne donne aucun avertissement. Il tourne et affiche des chiffres en apparence crédibles. Le problème se découvre généralement des mois plus tard, en constatant un coût d'acquisition totalement incohérent.
Voici les trois points critiques à sécuriser avant le lancement, à commencer par votre plan de marquage mobile.
Du clic jusqu'au postback, le trajet de vos données mobiles ne s'improvise pas. L'objectif du MMP n'est pas d'empiler de la donnée, mais de remettre de l'ordre dans vos performances. Il arbitre, déduplique et renvoie les bonnes informations pour optimiser vos budgets.
Si vous ne devez retenir qu'une chose : la qualité de votre attribution mobile ne dépend pas de l'outil que vous choisissez, mais de la rigueur de sa configuration. Un plan de marquage cadré, un mapping vérifié régie par régie, une déduplication tenue au cordeau. C'est là que se joue l'écart entre des chiffres crédibles et des chiffres justes.
Vous vous demandez comment intégrer un MMP proprement, ou comment le faire cohabiter avec votre stack data actuelle sans créer une usine à gaz ? Discutez avec un expert Smart Bees.
Parce que Meta est un Self-Attributing Network : il applique ses propres règles et se crédite les conversions qu'il reconnaît. Le MMP, lui, arbitre entre tous les canaux avec un modèle unique et n'attribue l'installation qu'à une seule source. Un écart est donc normal et attendu. C'est son ampleur, et sa stabilité dans le temps, qu'il faut surveiller.
Sept jours après le clic est la valeur la plus répandue, mais ce n'est pas une règle figée : la fenêtre se paramètre par réseau et par type d'engagement (clic, vue, re-engagement). Une fenêtre trop large gonfle artificiellement les installations attribuées au payant. Alignez-la sur votre cycle de décision réel, pas sur le réglage par défaut.
Les deux, en parallèle. SKAdNetwork reste opérationnel et AdAttributionKit est conçu pour l'étendre puis lui succéder, les deux frameworks étant interopérables. L'adoption d'AdAttributionKit reste inégale selon les régies, donc on ne débranche pas SKAN. On configure AdAttributionKit en plus, et on garde SKAN comme socle.
Non, et l'inverse non plus. Le MMP identifie la source d'acquisition, la CDP enrichit le profil et l'historique. Une CDP qui envoie seule ses conversions à Meta transmet du volume sans savoir ce qui vient de la publicité. Les deux se complètent, à condition de coordonner les flux pour ne pas envoyer deux fois la même conversion.
C'est le seul cas où la question mérite d'être posée. Avec un canal unique, le besoin d'arbitrage disparaît et le rapport de la régie suffit souvent au démarrage. Dès que vous ouvrez un deuxième canal, ou que vous voulez mesurer vos installations organiques proprement, le MMP redevient nécessaire. Le brancher après coup coûte plus cher que de le prévoir dès le départ.

30 minutes avec un des associés. On regarde votre configuration MMP, vos fenêtres d'attribution et vos postbacks, et on vous dit franchement ce qui fausse vos chiffres.