MMP et web analytics : réconcilier app, web et paid
La fragmentation de mesure n’est plus un problème de reporting, mais de pilotage budgétaire
Les équipes growth qui opèrent à la fois une application mobile, un site web et des campagnes paid media se retrouvent souvent avec trois vérités concurrentes. Le MMP, mobile measurement partner, outil spécialisé dans l’attribution et la mesure des campagnes d’acquisition mobile, crédite une campagne d’installation. La web analytics, mesure comportementale des parcours sur site web via des outils comme GA4, Piano, Matomo ou Adobe Analytics, attribue la conversion à une session web. La plateforme média, Meta, Google Ads, TikTok, Apple Search Ads, DSP ou réseau d’affiliation, revendique une performance supérieure via ses propres fenêtres d’attribution. Le problème n’est pas seulement que les chiffres divergent. Le problème est que chaque divergence peut déplacer des budgets vers le mauvais canal, le mauvais device ou la mauvaise étape du funnel.
Le funnel, entonnoir de conversion allant de l’acquisition à l’activation, puis à la rétention, au revenu et à l’expansion, n’est plus linéaire. Un utilisateur découvre une marque via une impression programmatique mobile, clique sur une annonce paid social, consulte le site sur desktop, installe l’application trois jours plus tard, crée un compte via Apple Sign-In, achète dans l’app, puis revient sur le web pour gérer son abonnement. Dans ce parcours, le MMP voit surtout l’installation, les événements in-app et les campagnes mobile. L’outil web analytics voit les sessions web, les sources de trafic, les pages consultées et les conversions web. Les plateformes paid voient leurs propres clics, impressions et conversions modélisées. Sans architecture commune, le marketing arbitre sur une mosaïque incohérente.
Cette incohérence devient coûteuse lorsque les volumes augmentent. Prenons une application retail générant 80 000 installations mensuelles, 1,8 million de sessions web et 600 000 euros de dépenses paid. Le MMP attribue 42 % des nouveaux acheteurs à des campagnes app install. La web analytics attribue 55 % du revenu aux canaux web, notamment SEO, SEA brand et email. Les plateformes publicitaires déclarent un ROAS, return on ad spend, ratio entre revenu attribué et dépenses publicitaires, moyen de 4,8. Le data warehouse, après déduplication utilisateur, observe un ROAS incrémental proche de 2,7 sur certaines campagnes de retargeting. Si l’entreprise scale sur la base du ROAS plateforme, elle risque de surpayer des conversions déjà captées par le web ou par la base CRM.
Réconcilier MMP, web analytics et paid ne consiste donc pas à trouver un chiffre unique qui aurait raison contre les autres. C’est construire un système de décision où chaque source a un rôle explicite : attribution opérationnelle, analyse comportementale, optimisation média, consolidation financière et mesure incrémentale. La question centrale n’est pas quel outil dit vrai, mais quel outil répond à quelle décision avec quel niveau de biais acceptable.
Comprendre les périmètres : le MMP mesure l’acquisition mobile, la web analytics mesure le parcours, les plateformes optimisent leur propre rendement
Le MMP est historiquement conçu pour résoudre un problème mobile : attribuer une installation ou un événement in-app à une source média malgré la complexité des stores, des SDK et des deep links. Un SDK, software development kit, bibliothèque logicielle intégrée dans l’application pour collecter des événements et communiquer avec des plateformes tierces, permet au MMP de recevoir des données comme install, first open, registration, purchase, subscription ou churn. Le MMP gère aussi les liens d’attribution, les fenêtres de clic ou d’impression, la déduplication entre réseaux, les postbacks vers les partenaires média et, de plus en plus, les contraintes de confidentialité comme SKAN, StoreKit Ad Network, framework d’attribution agrégée d’Apple pour iOS.
La web analytics répond à une autre logique. Elle suit les sessions, pages vues, événements web, sources de trafic, paramètres UTM, conversions, parcours, entonnoirs et segments d’audience. Elle permet d’analyser la qualité d’une landing page, le taux de conversion par device, les abandons de checkout, les interactions avec le contenu et les revenus web. Elle est souvent plus riche pour comprendre l’expérience utilisateur sur site, mais moins robuste pour attribuer une installation app ou un achat in-app à une campagne mobile lorsque l’utilisateur bascule entre navigateur, store et application.
Les plateformes paid ajoutent une troisième couche. Une DSP, demand-side platform, plateforme permettant d’acheter automatiquement des impressions publicitaires sur différents inventaires, optimise en RTB, real-time bidding, enchères publicitaires en temps réel impression par impression, selon ses propres signaux. Google Ads, Meta, TikTok ou une DSP programmatique voient les impressions, clics, conversions déclarées, signaux serveur, audiences et modèles propriétaires. Leur objectif n’est pas de produire une comptabilité neutre. Leur objectif est d’optimiser la diffusion et de démontrer la valeur de leur inventaire. Cette valeur peut être réelle, mais elle est souvent surestimée si elle est lue sans déduplication intercanal ni test incrémental.
Une erreur fréquente consiste à comparer directement les trois environnements comme s’ils mesuraient le même objet. Le MMP peut attribuer une installation à une campagne mobile après un clic valide dans une fenêtre de sept jours. La web analytics peut attribuer l’achat web au dernier clic non-direct dans une fenêtre de trente jours. La plateforme média peut compter une conversion post-view après une impression vue dans les vingt-quatre heures. Les trois chiffres peuvent être techniquement corrects selon leurs règles, tout en étant incompatibles pour piloter le budget.
La réconciliation commence donc par une cartographie des périmètres. Quels événements sont collectés sur le web ? Quels événements sont collectés dans l’app ? Quels événements sont renvoyés aux plateformes ? Quelle identité est disponible : cookie, user_id, device ID, email hashé, IDFA, GAID, identifiant CRM ? Quelles fenêtres d’attribution sont appliquées ? Quels canaux peuvent se chevaucher ? Sans cet inventaire, les écarts de reporting deviennent des débats politiques entre équipes acquisition, CRM, produit et finance.
Mettre en place une taxonomie commune : événements, UTM, deep links et identifiants
La première condition opérationnelle est la taxonomie. Une taxonomie de tracking définit la nomenclature des événements, paramètres, sources, campagnes, contenus, audiences et identifiants utilisés par les outils. Sans taxonomie commune, le même événement peut apparaître sous trois noms différents : purchase dans le MMP, transaction dans la web analytics, conversion_value dans la plateforme paid. À l’inverse, un même nom peut recouvrir des réalités différentes : signup peut désigner une création de compte, une inscription newsletter ou un démarrage d’essai gratuit. La réconciliation devient alors impossible sans retraitement manuel.
Une architecture mature définit d’abord les événements métier, puis les traduit dans chaque outil. Par exemple : account_created, app_install, trial_started, subscription_started, first_purchase, repeat_purchase, add_to_cart, checkout_started, payment_failed, store_locator_used, coupon_redeemed. Chaque événement doit avoir une définition stricte : déclencheur, plateforme concernée, propriétés obligatoires, valeur monétaire, devise, horodatage, identifiant utilisateur, identifiant session, identifiant campagne et règles de déduplication. Un first_purchase ne doit pas être déclenché deux fois si l’utilisateur paie sur web puis ouvre l’app. Un subscription_started doit distinguer essai gratuit, paiement immédiat, renouvellement et upgrade.
Les UTM, paramètres ajoutés aux URL pour identifier source, medium, campaign, content et term, restent essentiels sur le web. Mais ils doivent être alignés avec les conventions du MMP et des plateformes paid. Une campagne Meta app install ne devrait pas apparaître comme facebook_paid dans l’outil web, Meta Ads dans le MMP et paid_social dans le data warehouse sans table de correspondance. Le minimum viable est une nomenclature en cinq dimensions : source, canal, objectif, marché, créa ou audience. Exemple : source = meta, channel = paid_social, objective = app_install, market = fr, campaign = q2_activation_lal_highvalue.
Les deep links et deferred deep links jouent un rôle central dans les parcours app-web. Un deep link ouvre directement une section de l’application si elle est installée. Un deferred deep link permet, après installation, d’orienter l’utilisateur vers le contenu initialement cliqué. Pour une marque e-commerce, un clic sur une annonce produit doit idéalement conduire vers la fiche produit dans l’app après installation, pas vers la home. Le MMP peut gérer cette continuité, mais seulement si les paramètres campagne et contenu sont conservés entre clic, store, install et first open. Une rupture à ce niveau dégrade à la fois l’expérience utilisateur et l’attribution.
L’identité est le point le plus sensible. Les environnements mobile et web disposent rarement d’un identifiant unique universel. Les cookies tiers disparaissent, l’IDFA sur iOS est conditionné au consentement ATT, App Tracking Transparency, mécanisme Apple demandant l’autorisation de suivi inter-apps, et les utilisateurs naviguent entre devices. La solution la plus robuste consiste à créer un user_id propriétaire lorsque l’utilisateur s’authentifie, puis à le propager vers le MMP, la web analytics, le CRM et le data warehouse dans le respect du consentement. Avant login, l’identité reste probabiliste ou fragmentée. Après login, elle devient beaucoup plus exploitable pour l’analyse de cohortes, la LTV, lifetime value, valeur économique cumulée d’un utilisateur, et la déduplication.
Construire une couche de vérité dans le data warehouse, sans effacer les outils métiers
La tentation est forte de demander au MMP ou à la web analytics de devenir la source de vérité globale. C’est rarement une bonne idée. Le MMP est excellent pour l’attribution mobile opérationnelle, les postbacks, la fraude mobile, SKAN et les campagnes app. La web analytics est excellente pour l’analyse du parcours web, les contenus, la performance des landing pages et les entonnoirs web. Mais la réconciliation app-web-paid exige souvent un niveau de consolidation que seul un data warehouse, entrepôt de données centralisant des informations issues de plusieurs systèmes, peut fournir proprement.
Le data warehouse doit recevoir au minimum cinq flux : événements web, événements app, coûts média, données CRM ou transactionnelles, et données d’attribution MMP. Les coûts média doivent être importés au niveau campagne, ad set, ad, pays, device et date lorsque c’est possible. Les événements doivent être horodatés avec une granularité suffisante et reliés à des identifiants stables : user_id, anonymous_id, device_id, order_id, subscription_id, campaign_id. Les revenus doivent venir du système transactionnel ou billing, pas uniquement des événements déclarés par les outils marketing, afin d’éviter les écarts liés aux remboursements, taxes, renouvellements, annulations ou paiements échoués.
Une fois les flux centralisés, l’équipe peut construire une table d’événements unifiée. Chaque ligne représente une action utilisateur, avec des propriétés normalisées : plateforme, événement, utilisateur, session, compte, source attribuée, campagne, montant, devise, timestamp, consentement, pays, device, version app. Une table de coûts média séparée permet ensuite de calculer le CPA, coût par acquisition ou par action selon le contexte, et le ROAS de manière cohérente. Une table de mapping relie les noms de campagnes entre plateformes, MMP et web analytics.
Cette couche ne remplace pas les outils métiers. Elle sert à trancher les décisions de niveau budget et performance globale. Le MMP reste utile pour optimiser les campagnes app et renvoyer les bons signaux aux réseaux. La web analytics reste utile pour diagnostiquer une chute de conversion sur checkout web. Les plateformes paid restent utiles pour l’optimisation algorithmique quotidienne. Le warehouse sert à répondre à des questions transversales : combien de nouveaux clients nets avons-nous acquis ? Quel canal génère la meilleure LTV à 90 jours ? Quelle part du revenu app provient de parcours initiés sur web ? Quel est le coût complet par acheteur incrémental ?
Exemple concret : une scale-up de livraison alimentaire observe que ses campagnes app install affichent un CPA install de 3,20 euros et un CPA premier achat de 18 euros dans le MMP. Le reporting web indique pourtant que 37 % des nouveaux acheteurs ont visité le site avant d’installer l’app. Après consolidation warehouse, l’équipe découvre que les campagnes paid search brand captent une partie importante de la demande créée par le paid social mobile. Le CPA par nouveau client net passe de 18 à 26 euros lorsque l’on déduplique les utilisateurs déjà exposés et les clients réactivés. La conclusion n’est pas de couper le paid social, mais de modifier la lecture : il génère de la demande haut de funnel, tandis que le search brand la capture. Les budgets doivent être arbitrés sur contribution incrémentale, pas sur last click.
Choisir un modèle d’attribution adapté : opérationnel, analytique et incrémental
L’attribution, méthode qui assigne une conversion ou une part de revenu à un ou plusieurs points de contact marketing, ne doit pas être un dogme unique. Dans un environnement app-web-paid, il faut distinguer trois usages. L’attribution opérationnelle sert à optimiser les campagnes dans les plateformes. L’attribution analytique sert à comprendre les parcours et à répartir la contribution entre canaux. L’attribution incrémentale sert à estimer ce qui se serait passé sans l’action marketing.
Le last click, qui attribue 100 % de la conversion au dernier clic, est simple et lisible, mais il survalorise les canaux de capture comme brand search, retargeting, email de relance ou comparateurs. Le first click valorise la découverte, mais ignore la maturation. Les modèles linéaires ou position-based distribuent le crédit, mais restent conventionnels. Les modèles data-driven peuvent être plus fins, mais ils dépendent de la qualité des données, du volume, des règles de confidentialité et des hypothèses algorithmiques. Aucun modèle d’attribution n’est une mesure pure de causalité.
Dans le mobile, la situation est encore plus contrainte. Sur iOS, SKAN limite la granularité, introduit des délais et agrège les conversions. Les signaux post-install peuvent être partiels. Sur Android, les identifiants restent plus exploitables, mais les évolutions Privacy Sandbox réduisent progressivement certaines capacités. Les MMP utilisent donc une combinaison de méthodes : déterministe lorsque l’identifiant est disponible, agrégée avec SKAN, parfois probabiliste lorsque les règles le permettent, et modélisée pour combler les trous. L’équipe marketing doit comprendre ces mécanismes avant de comparer iOS et Android ou app et web.
Une bonne pratique consiste à maintenir deux lectures en parallèle. La première est l’attribution de gestion, utilisée au quotidien avec des règles stables : fenêtres définies, hiérarchie des canaux, déduplication, exclusion des clients existants si l’objectif est l’acquisition, distinction entre install, registration et purchase. La seconde est l’incrémentalité, mesurée via holdouts, groupes volontairement non exposés servant de témoins, geo-tests, tests d’audience ou expérimentations par canal. La première permet d’opérer. La seconde permet de décider si l’investissement crée réellement de la valeur additionnelle.
Supposons une campagne de retargeting app-web dépensant 50 000 euros par mois. Les plateformes revendiquent 260 000 euros de revenu, soit un ROAS de 5,2. Le MMP attribue 190 000 euros d’événements in-app. La web analytics attribue 140 000 euros de ventes web assistées. Un holdout de 10 % montre que les utilisateurs exposés achètent 8,4 % de plus que les non exposés, à profil comparable. Le revenu incrémental estimé est alors de 72 000 euros, soit un ROAS incrémental de 1,44. La campagne peut rester rentable si elle améliore la rétention de clients à forte marge, mais elle ne doit pas être scalée comme si son ROAS réel était 5,2.
Le choix du modèle doit aussi dépendre de l’étape AARRR. Dans le framework AARRR, acquisition, activation, retention, referral, revenue, chaque étape appelle des métriques différentes. Une campagne d’acquisition app doit être jugée sur nouveaux utilisateurs qualifiés, activation et LTV. Une campagne d’activation doit mesurer la progression vers une première valeur : compte créé, onboarding terminé, premier panier, première réservation. Une campagne de rétention doit mesurer uplift de fréquence, churn évité ou revenu net additionnel. Utiliser le même modèle d’attribution pour toutes ces étapes conduit à optimiser des conversions faciles plutôt que des comportements créateurs de valeur.
Renvoyer les bons signaux aux plateformes paid : optimisation algorithmique et qualité des conversions
Réconcilier la mesure ne sert pas seulement au reporting. Cela améliore aussi l’apprentissage des plateformes paid. Les algorithmes d’achat média optimisent ce que les annonceurs leur envoient. Si une équipe renvoie aux plateformes tous les installs, tous les leads ou tous les achats sans distinguer qualité, valeur et nouveauté, l’algorithme optimise vers le volume le moins cher, pas vers la valeur économique. C’est particulièrement critique lorsque le CPA semble bas mais que la LTV est faible.
Le premier arbitrage concerne l’événement d’optimisation. Optimiser une campagne app sur install maximise souvent le volume, mais peut attirer des utilisateurs peu engagés. Optimiser sur registration améliore le signal, mais réduit le volume d’apprentissage. Optimiser sur first_purchase, subscription_started ou value event rapproche l’algorithme de la valeur, mais peut être trop rare pour sortir de la phase d’apprentissage. Une règle pragmatique consiste à viser au moins 50 conversions par semaine et par ad set ou ensemble d’annonces pour un apprentissage stable, même si ce seuil varie selon les plateformes et les stratégies d’enchères.
Le deuxième arbitrage concerne la valeur renvoyée. Toutes les conversions ne se valent pas. Un achat unique de 12 euros avec remise de bienvenue n’a pas la même valeur qu’un abonnement annuel de 180 euros ou qu’un client récurrent. Les plateformes permettent souvent d’envoyer une conversion value ou un événement de valeur. Encore faut-il que cette valeur soit correctement calculée : revenu net, marge, panier hors taxes, probabilité de rétention, LTV prédite à 30 ou 90 jours. Une application d’abonnement peut par exemple envoyer un score de qualité après sept jours : onboarding complété, nombre de sessions, usage d’une fonctionnalité clé, paiement validé. Ce signal peut mieux prédire la LTV qu’un simple trial_started.
Le troisième arbitrage concerne la déduplication et les exclusions. Si les clients existants sont inclus dans les audiences d’acquisition et que leurs achats sont renvoyés comme nouveaux revenus, les plateformes optimisent vers des utilisateurs déjà acquis. Le CPA baisse artificiellement, le ROAS augmente, mais la croissance nette stagne. Il faut donc distinguer acquisition, réactivation et rétention dans les événements et audiences. Un purchase_new_customer ne doit pas être mélangé avec un purchase_existing_customer si le budget est dédié à l’acquisition.
La qualité des signaux dépend aussi des intégrations server-side. Le tracking côté serveur, envoi d’événements depuis le serveur de l’annonceur vers les plateformes ou outils analytics, réduit certaines pertes liées aux bloqueurs, navigateurs et restrictions cookies. Il permet de transmettre des événements plus fiables, enrichis et contrôlés. Mais il introduit des risques : doublons entre client-side et server-side, consentement mal propagé, latence, mapping incomplet, sur-attribution si les événements sont envoyés à trop de plateformes sans règle claire. Une intégration server-side doit être auditée comme un système financier : identifiants, horodatage, déduplication, consentement et journalisation.
Diagnostiquer les écarts : une méthode de réconciliation en six contrôles
Lorsque les chiffres divergent, la mauvaise réaction est de chercher immédiatement un coupable. La bonne réaction est de suivre une méthode de diagnostic. Les écarts entre MMP, web analytics et paid sont normaux. Ce qui compte est de savoir s’ils sont explicables, stables et compatibles avec les décisions prises.
Premier contrôle : les fenêtres d’attribution. Une plateforme peut compter une conversion sept jours après clic et un jour après impression, le MMP sept jours après clic uniquement, la web analytics trente jours en last non-direct click. Harmoniser temporairement les fenêtres permet d’estimer la part de l’écart liée aux règles de temps.
Deuxième contrôle : la définition de conversion. Install, first open, account_created et first_purchase ne doivent pas être comparés comme des équivalents. Dans beaucoup d’apps, 100 000 installs peuvent produire 62 000 first opens, 28 000 créations de compte et 7 000 premiers achats. Un écart de reporting peut simplement venir d’une confusion entre événement technique et événement business.
Troisième contrôle : la déduplication utilisateur. Un utilisateur peut convertir sur web et app, ou cliquer sur plusieurs canaux avant conversion. Sans order_id, subscription_id ou user_id partagé, le même revenu peut être compté plusieurs fois. Le ratio de doublons doit être mesuré régulièrement, notamment sur les périodes promotionnelles et les campagnes omnicanales.
Quatrième contrôle : la couverture du consentement et des identifiants. Sur iOS, une baisse du taux d’opt-in ATT peut réduire la mesure déterministe. Sur le web, les navigateurs, consent banners et bloqueurs affectent les cookies et pixels. Si 35 % des utilisateurs refusent le tracking analytics mais autorisent certains événements transactionnels, les volumes de sessions et de revenus ne seront pas alignés.
Cinquième contrôle : les coûts média. Les coûts doivent inclure spend net, frais plateforme, frais agence, frais tracking, taxes éventuelles et remises si l’on calcule une rentabilité réelle. Un CPA calculé avec les seuls coûts média bruts ne répond pas à la même question qu’un CAC, customer acquisition cost, coût complet d’acquisition client incluant marketing, outils et effort commercial.
Sixième contrôle : la timezone et la devise. Cela semble basique, mais les écarts de date et de change créent des anomalies importantes sur des volumes internationaux. Une campagne lancée à 23 h UTC peut être comptabilisée sur deux jours différents selon les outils. Un achat en livre sterling converti au taux transactionnel ne correspond pas toujours au taux moyen utilisé dans le reporting marketing.
Cette méthode évite de transformer chaque écart en crise. Elle permet de classer les divergences en trois catégories : écarts attendus liés aux règles d’attribution, écarts techniques à corriger, écarts économiques nécessitant une nouvelle mesure. Les premiers doivent être documentés. Les seconds doivent être corrigés. Les troisièmes doivent être testés via incrémentalité ou analyse de cohortes.
Conclusion : réconcilier pour décider, pas pour produire un dashboard plus élégant
La réconciliation entre MMP, web analytics et paid n’est pas un projet de propreté analytique. C’est un levier de performance. Elle permet d’éviter trois erreurs coûteuses : surinvestir dans des canaux qui capturent une demande existante, sous-investir dans des canaux qui créent de la demande mais sont mal crédités, et optimiser les plateformes sur des conversions faciles plutôt que sur des utilisateurs rentables.
Une méthode actionnable peut se résumer en huit décisions. Premièrement, définir le rôle de chaque outil : MMP pour l’attribution mobile opérationnelle, web analytics pour l’analyse des parcours web, plateformes paid pour l’optimisation média, warehouse pour la consolidation économique. Deuxièmement, créer une taxonomie commune des événements, campagnes, UTM, deep links et identifiants. Troisièmement, propager un user_id propriétaire dès que l’authentification le permet, avec consentement et règles de confidentialité explicites. Quatrièmement, centraliser événements, coûts, revenus et attributions dans une couche warehouse auditable. Cinquièmement, distinguer attribution de gestion et mesure incrémentale afin de ne pas confondre corrélation et causalité. Sixièmement, renvoyer aux plateformes des signaux de qualité, pas seulement des volumes de conversions. Septièmement, diagnostiquer les écarts via fenêtres, définitions, déduplication, consentement, coûts et timezones. Huitièmement, piloter les budgets sur nouveaux clients nets, LTV, marge et ROAS incrémental plutôt que sur les seuls chiffres déclarés par les plateformes.
Le bon système ne supprime pas toutes les divergences. Il les rend explicables et décisionnables. Un MMP, une web analytics et une plateforme paid ne raconteront jamais exactement la même histoire, parce qu’ils n’observent pas le même monde et ne servent pas le même objectif. La maturité consiste à orchestrer ces points de vue au lieu de les empiler. Pour une équipe growth, la question finale n’est pas de savoir si l’app, le web ou le paid gagne l’attribution. Elle est de savoir quelle combinaison de parcours, canaux et signaux crée le plus de revenu incrémental au coût marginal le plus acceptable.
