· 12 min · Samet Durgun · Données des plateformes vérifiées le

AppLovin est-il incrémental pour mon app, et comment le tester ?

Je suis Samet Durgun, fractional Head of UA. Je gère le paid UA pour des apps par abonnement et des jeux mobiles, et j'écris ici ce que je constate dans les comptes que je gère. Cet article fait partie du thème Fractional Head of UA ; en savoir plus sur moi.

AppLovin n’est incrémental pour votre app que dans la mesure où le couper vous ferait perdre des installs et du revenu que vous n’obtiendriez nulle part ailleurs. Aucun chiffre de ROAS dans votre MMP ou dans le dashboard d’AppLovin ne répond à cela, parce que ces chiffres montrent du crédit, pas une cause. Le test qui y répond est un holdout géographique : AppLovin coupé dans des régions appariées et actif partout ailleurs, au même moment, avec des résultats lus dans les données du store et du backend et rapportés en ROAS incrémental avec un intervalle de confiance. Ce qui change la réponse, c’est de pouvoir mesurer le résultat par zone géographique. Les pays fonctionnent pour n’importe quelle app. Pour les États et les zones métropolitaines des États-Unis, il faut que vos données puissent découper les États-Unis ainsi. Sinon, la réponse est que vous ne savez pas encore.

Je traite ici les campagnes d’app AppLovin Ads (iOS et Android) attribuées via un MMP, dans toutes les régions, avec les pages d’AppLovin, Impact, Apple, Google, Meta et Haus vérifiées le 1er octobre 2026. Les pages d’aide d’AppLovin ne portent aucune date de mise à jour, donc considérez la date de vérification comme la seule date.

Je n’ai publié aucun résultat d’incrémentalité sur AppLovin. Ce qui suit est la méthode que j’appliquerais sur un compte, construite à partir de la documentation d’AppLovin elle-même et des outils d’expérimentation publics.

De quoi AppLovin reçoit-il le crédit dans un compte d’app ?

Pour les apps, AppLovin ne décide pas seul de l’attribution. Sa page Set up MMP tracking indique que pour diffuser des campagnes sur AppLovin Ads, vous devez configurer le tracking avec un mobile measurement partner (Adjust, AppsFlyer, Kochava, Tenjin, Singular ou Branch), et que le tracking doit être en place avant la mise en ligne de toute campagne. AppLovin a renommé sa plateforme AppLovin Ads et l’a ouverte à tous les annonceurs le 22 juin 2026 ; Axon reste le nom de son système de recommandation par IA.

Les pages par partenaire détaillent les réglages. La page AppsFlyer d’AppLovin demande des postbacks d’install et d’événements in app pour “All media sources, including organic”, l’attribution view through des installs activée, un lookback click through d’au moins 7 jours et un lookback view through d’au moins 24 heures. Sa page Adjust demande les données de toutes les sources d’attribution, une fenêtre de clic d’au moins 7 jours et une fenêtre d’impression d’au moins 24 heures.

Il ne faut donc pas transposer aux apps l’idée qu’AppLovin ne compte que les clics et serait de ce fait prudent. Elle vient de l’article d’AppLovin de juin 2026, Different numbers, one channel: making sense of AppLovin through a measurement lens, écrit surtout pour les marques e-commerce et grand public, qui dit que le reporting de la plateforme y capture uniquement l’attribution click through.

Une fenêtre view through montre qu’AppLovin a diffusé une publicité sur cet appareil dans la fenêtre qui précède l’install, et que le MMP lui en a donné le crédit. Elle ne montre pas que la publicité a causé l’install. Quelqu’un qui a vu un playable et aurait installé depuis la recherche le soir même est quand même compté. Les postbacks organiques ne veulent pas dire non plus qu’AppLovin reçoit le crédit des utilisateurs organiques. Ils envoient à AppLovin des données sur chaque install et chaque événement, et c’est toujours le MMP qui décide à qui va le crédit.

Le revenu attribué peut aussi être faux avant même que la question de l’incrémentalité se pose. Dans le test de stratégies d’enchères Google Ads à 27K $ que j’ai mené en février 2026, l’événement de revenu du compte envoyait 1 $ au lieu de 0 $ quand une conversion n’avait pas de valeur. Cela gonflait le ROAS rapporté par Google partout, et surtout sur iOS. Avant de tester ce qu’un réseau provoque, je vérifierais donc ce qu’on lui envoie. Les chiffres attribués divergent aussi entre eux quand rien n’est cassé : voyez pourquoi Google Ads, le MMP et SKAN rapportent des conversions iOS différentes pour savoir quels écarts sont normaux.

Que signifie un pourcentage d’incrémentalité ?

Cela dépend du dénominateur, et deux chiffres très différents reçoivent le même nom.

  • Lift par rapport à une base de référence : le pourcentage dont les régions traitées dépassent ce que le groupe témoin prédit pour elles. La base est ce qui se serait passé sans AppLovin.
  • Part incrémentale du revenu attribué : le pourcentage du revenu crédité à AppLovin qui n’aurait pas existé sans lui. La base est le revenu attribué.

Aucun des deux n’est un chiffre de coût. Un chiffre de lift ne dit rien de l’efficacité tant que vous n’avez pas divisé le revenu incrémental par la dépense qui l’a produit. Le chiffre que je rapporterais est le ROAS incrémental, le revenu incrémental divisé par la dépense AppLovin dans les régions traitées, accompagné du ROAS attribué pour les mêmes régions et les mêmes dates. L’incrémental peut aussi ressortir au-dessus de l’attribué : dans un compte que j’ai étudié, les jours avec 100 installs Meta payants de plus sur iOS affichaient environ 28 installs organiques de plus dans le MMP, signe que l’attribution peut aussi sous-estimer le payant.

Avant d’agir sur le chiffre de lift de qui que ce soit, je voudrais savoir quel résultat a été mesuré, combien a été dépensé, combien de temps le test a duré et quelle est la largeur de l’intervalle.

Pourquoi couper puis relancer AppLovin ne répond-il pas à la question ?

Les semaines changent aussi. Couper AppLovin en mars et le relancer en avril compare deux mois différents : la saisonnalité, un événement live ops, une mise en avant sur le store, un test de prix et des changements sur Meta ou Google se retrouvent tous dans la même comparaison, et la dépense payante déborde sur des installs organiques ultérieurs. Chez Google, la page Intro to analysis de Meridian estime le contrefactuel par une régression temporelle. Elle demande des séries temporelles sur une période de prétest et sur la période de test, avec le design et l’affectation des zones géographiques fixés avant le test. Le groupe témoin doit tourner en même temps que le traitement.

Comment est-ce que je concevrais un holdout géographique pour AppLovin ?

Choisissez une unité géographique que vous pouvez à la fois cibler et mesurer. La Campaign Management API d’AppLovin permet de cibler par country_code. Pour les États-Unis uniquement, elle accepte aussi region_codes (les États) ou metro_names (les zones métropolitaines), qui ne peuvent pas être combinés. Je n’ai trouvé aucun champ d’exclusion géographique, donc une région de holdout est simplement une région que vous ne ciblez pas.

Acceptez que le test aille quelque temps à l’encontre des conseils de scaling d’AppLovin. Scale your campaign recommande de sélectionner tous les pays que vous prenez en charge avec un seul budget mondial, et un budget permettant au moins 15 à 20 conversions par jour sur l’ensemble de la campagne. Un holdout retire des régions exprès, donc les régions traitées ont toujours besoin d’assez de budget pour ce volume de conversions.

Dimensionnez le test avant de dépenser. La GeoLift Methodology open source de Meta combine un contrôle synthétique augmenté pour l’estimation et un contrôle synthétique généralisé pour l’inférence, et ses calculateurs de puissance suggèrent la durée du test, l’investissement, le nombre de marchés et lesquels choisir. Pour les tests qu’AppLovin mène avec des marques, son article sur la mesure indique que les holdouts représentent généralement 20 à 50 % de la couverture géographique, sont conçus pour une puissance statistique d’au moins 90 %, et que les campagnes doivent avoir quitté la phase d’apprentissage et diffuser de façon stable avant le début d’un test. Ce sont des chiffres pour des marques, pas une règle pour les apps, mais l’exigence de puissance se transpose.

Ne changez rien d’autre. Laissez l’objectif, la cible et les créatifs d’AppLovin inchangés, et ne reconstruisez pas les campagnes pendant le test : l’API ne définit goal_type et roas_day_target qu’à la création. Les budgets des autres canaux, les prix, les promotions et le live ops doivent rester identiques dans les régions traitées et les régions témoins, ou au moins évoluer ensemble.

Faites durer le test plus longtemps que la fenêtre d’optimisation. Setting up your app campaign d’AppLovin propose des cibles Day 7 et Day 28 et indique que les fenêtres plus longues “generally target highest value users” (ciblent généralement les utilisateurs à la plus forte valeur). Si la campagne optimise sur Day 28, les cohortes installées pendant le test doivent atteindre le même âge dans les deux groupes avant que je lise le revenu.

Question Ce qui y répond D’où viennent les chiffres Ce que cela ne peut pas vous dire
De quoi AppLovin a-t-il reçu le crédit ? L’attribution du MMP, avec des fenêtres de clic d’au moins 7 jours et des fenêtres view through d’au moins 24 heures Rapports du MMP Si ces utilisateurs seraient venus de toute façon
Quel partenaire a touché la commande ? Incrementality % d’Impact Le modèle d’attribution d’Impact Rien de causal ; il n’a pas de groupe témoin
Qu’est-ce qu’AppLovin a causé ? Holdout géographique, lift et ROAS incrémental avec un intervalle Consoles des stores par territoire, revenu du backend Les effets dans des régions ou des périodes hors du test
Comment AppLovin se compare-t-il dans le mix au fil du temps ? MMM calibré par des expériences Séries temporelles de dépense et de résultat La cause, sauf si une expérience l’ancre

D’où viennent les données de résultat ?

Pas du dashboard d’AppLovin, et pas des seuls installs attribués par le MMP, puisque ce sont ces chiffres que le test met à l’épreuve. App Store Connect Analytics vous permet de filtrer les métriques d’app par territoire, qu’Apple détermine d’après l’adresse de facturation du client. La page View app statistics de Google Play propose country/region, le pays ou la région de l’utilisateur, comme dimension. Le revenu vient de votre backend d’abonnements ou de votre propre grand livre, découpé de la même façon.

Aucune des deux consoles de store ne liste les États américains : un test par État ou par zone métropolitaine exige donc des données de résultat qui enregistrent l’État. Je le confirmerais avant de choisir le design, car c’est ce qui décide si l’on peut découper les États-Unis.

Comment lire le résultat ?

Je rapporterais quatre chiffres : les installs incrémentaux, le revenu incrémental, le ROAS incrémental et son intervalle de confiance, avec le ROAS attribué pour les mêmes régions et les mêmes dates. L’analyse de Meridian présente ses résultats sous la même forme : lift, lift en pourcentage, intervalles de confiance, valeurs p et conversions incrémentales par dollar, qu’elle assimile au ROAS incrémental quand le résultat est le revenu.

Un résultat non significatif est en général non concluant, pas nul : l’intervalle montre quelle taille d’effet le test aurait pu manquer. Si l’intervalle est large, l’étape suivante est un test plus long ou plus grand, pas un verdict. S’il est serré, j’utiliserais le ratio entre ROAS incrémental et ROAS attribué comme facteur provisoire sur les cibles d’AppLovin, pour ces régions et cette période seulement. L’article d’AppLovin sur la mesure décrit un test d’incrémentalité comme une expérience ponctuelle où la taille du holdout, le niveau de budget, la durée du test, la composition géographique et la stabilité des campagnes interagissent, donc je referais le test dès que l’un de ces éléments change.

Où se placent le MMM et les études de lift ?

Le MMM aide à condition qu’une expérience l’ancre. La page Calibrate treatment priors de Meridian indique que les expériences et les MMM ont souvent des estimands différents : le contrefactuel du MMM est une dépense nulle, alors que certaines expériences mesurent par rapport à une dépense réduite, dans une fenêtre, une région et une configuration précises. Elle indique qu’il n’existe pas de formule unique pour traduire une expérience en prior, et son CalibrationBuilder ajoute de l’incertitude aux expériences plus anciennes et ajuste selon l’échelle de dépense. Un MMM sans expérience derrière lui donne une estimation de l’effet d’AppLovin, pas un test de cet effet.

Les résultats de lift publiés sur AppLovin que j’ai trouvés concernent des marques. L’article de Haus Is AppLovin More Than a Hype Channel? Lessons From Haus Incrementality Tests couvre des holdouts géographiques de janvier 2025 à mars 2026. Les annonceurs y sont des marques DTC et omnicanales : le contexte est utile, mais il dit peu de choses des apps ou des jeux. Si un réseau propose de mener un test de lift pour vous, demandez le design, la source des résultats et l’intervalle avant le début du test. L’équipe d’un réseau ne voit que ce réseau, ce qui explique aussi pourquoi elle ne peut pas trancher pour l’ensemble du mix ; qui doit piloter l’UA d’un jeu mobile après le soft launch traite ce point.

Pourquoi l’Incrementality % d’Impact est-il du crédit modélisé, pas du lift ?

La question se pose quand un canal de partenaires ou d’affiliation côtoie AppLovin et revendique les mêmes utilisateurs. L’Incrementality FAQ d’Impact définit Incrementality % comme le crédit fractionnel total du modèle divisé par le total des commandes auxquelles le partenaire a participé. Le modèle est un “U-Shaped Time Decay Attribution Model” avec une décroissance temporelle de 7 jours, qui pondère le plus les premières et les dernières interactions. La même page dit qu’un Incrementality % élevé signifie que le partenaire apporte “real additional value” (une vraie valeur additionnelle).

Le score décrit seulement la position d’un partenaire dans les parcours qu’Impact a vus, pas ce qui se serait passé sans lui. L’Incrementality by Partner Report répartit les rôles en % Introduce, % Influence, % Close et % Solo, définit Adjusted CPA comme le coût total des actions divisé par les actions incrémentales et Adjusted ROAS comme le revenu incrémental divisé par le coût total des actions, et recommande au moins 30 jours de données. Ces entrées incrémentales sont le crédit modélisé, donc les chiffres ajustés sont modélisés eux aussi. La page Incrementality Dashboard Explained indique que la fonctionnalité exige des éditions ou des add ons spécifiques. La même logique de holdout répond à la question causale pour un partenaire.

Où ce test s’inscrit-il dans mon travail ?

Pour un jeu qui achète sur AppLovin en plus de Meta, l’acquisition d’utilisateurs pour jeux mobiles explique comment les deux s’articulent. Le growth audit lit ce qu’on envoie à chaque réseau et dit quand l’attribution ne peut pas trancher une question, par exemple celle de savoir si AppLovin était incrémental, et qu’il faut d’abord passer par un test. Vous pouvez le réserver seul, quel que soit votre niveau de dépense.

Sources

Toutes vérifiées le 1er octobre 2026.

Questions fréquentes

AppLovin compte-t-il les installs view through pour les campagnes d'app ?

Pour les campagnes d'app, l'attribution passe par votre MMP, et les pages de configuration d'AppLovin demandent des fenêtres view through. Sa page AppsFlyer demande que l'attribution view through des installs soit activée, avec un lookback view through d'au moins 24 heures à côté d'un lookback click through d'au moins 7 jours, et sa page Adjust demande une fenêtre d'impression d'au moins 24 heures. L'affirmation selon laquelle AppLovin ne rapporte que les clics vient de son article de juin 2026 sur la mesure, écrit surtout pour les marques e-commerce et grand public, et décrit le reporting d'AppLovin dans sa propre plateforme.

Couper AppLovin puis le relancer prouve-t-il qu'il est incrémental ou non ?

Pas à lui seul. Une comparaison avant et après mélange le canal avec tout ce qui a changé pendant ces semaines : la saisonnalité, les événements live ops, les mises en avant sur le store, les autres canaux et l'effet différé des dépenses antérieures. Ce qui sépare AppLovin du calendrier, c'est un holdout géographique : des régions sans AppLovin mesurées pendant les mêmes semaines que des régions avec AppLovin, face à un modèle ajusté sur les semaines qui précèdent le test.

Le MMM peut-il me dire si AppLovin fonctionne pour mon app ?

Il peut appuyer la réponse, pas la trancher. La documentation Meridian de Google décrit les expériences d'incrémentalité comme peut-être la base la plus solide pour fixer les priors du modèle, et avertit que les expériences et le MMM définissent souvent le ROI différemment : le contrefactuel du MMM est une dépense nulle, alors qu'un test peut comparer à une dépense réduite, dans sa propre fenêtre de temps, ses régions et ses réglages de campagne. Un modèle sans expérience derrière lui est une estimation de l'effet d'AppLovin, pas une preuve.

L'Incrementality % d'Impact est-il un résultat de test de lift ?

Non. Impact le définit comme le crédit fractionnel total de son modèle d'attribution en U avec décroissance temporelle, divisé par le total des commandes auxquelles le partenaire a participé, le premier et le dernier contact pesant le plus. Il décrit la place d'un partenaire dans le parcours de conversion. Il ne compare pas les utilisateurs exposés à un groupe témoin, donc il ne peut pas vous dire ce qui se serait passé sans le partenaire.