Meta Ads pour applications mobiles : la structure de campagne qui scale en 2026

Depuis six mois, je pilote une campagne Meta pour une application mobile B2C. Pas une grosse boîte, pas un unicorn non plus : une éditeur lambda avec un bon produit et un budget modéré. C'est un terrain parfait pour comprendre ce qui marche vraiment en 2026, quand Apple a tué l'IDFA sur iOS 17.4+, qu'Android Privacy Sandbox commence à réduire les ciblages, et que SKAdNetwork 5 force tout le monde à réécrire sa structure. Pas de façade de cas client miracle, pas de chiffres gonflés. Juste ce qui fonctionne actuellement. Je partage ma structure et les erreurs que je vois répéter chez les nouveaux clients.

Le changement de paradigme tracking en 2026 : IDFA, AAID, SKAdNetwork 5

Trois ans après iOS 14.5, nous sommes enfin arrivés au point d'inflexion. L'IDFA, l'identifiant unique qui permettait de pister chaque utilisateur iPhone depuis l'app jusqu'à Meta, n'a jamais complètement disparu. Mais iOS 17.4 marque son dépréciation effective. Meta peut toujours l'utiliser sur les consentements ATT (AppTrackingTransparency) explicites, mais le taux de consentement n'a jamais dépassé les 15-25 % en fonction des secteurs. Pour les 75-85 % restants, c'est le brouillard.

Android fait la même chose avec AAID (Android Advertising ID), progressivement remplacé par Privacy Sandbox. Google prévoyait de désactiver AAID d'ici 2025, puis l'a repoussé. Maintenant le calendrier est 2026-2027. La transition n'est jamais instantanée, ce qui veut dire que durant les trois prochaines années, on gère deux mondes en parallèle. D'un côté, les vieux appareils avec AAID. De l'autre, les nouveaux avec Privacy Sandbox qui donne des cohorts de users, pas des IDs individuels. C'est chaotique, et c'est la normale.

SKAdNetwork 5 (le framework d'Apple pour l'attribution sans IDFA) force la refonte complète de la méthodologie. SKAdNetwork ne revient plus un ID utilisateur, ni même un liste d'événements complets. Il revient une fenêtre d'attribution agrégée avec un délai de 24-48 heures. "Cet utilisateur a probablement installé l'app à cause de cette campagne Meta". C'est le signal. Reste de l'histoire : à deviner.

Conséquence directe : les structures de campagne que j'ai menées en 2022-2024 ne fonctionnent plus. L'empilement des fenêtres d'attribution courtes (1h, 3h, 7j) est remplacé par une logique plus large de cohort d'install et de feedback événementiel lissé. Plus de précision chirurgicale. Davantage de résilience statistique.

SDK Meta + AEM (Aggregated Event Measurement) : checklist d'implémentation

Première étape concrète : l'implémentation SDK Meta dans l'app (iOS et Android) doit être irréprochable. Le SDK doit tracker les événements clés en server-side si possible, via l'API de conversion côté serveur (CAPI).

Ma checklist pour les clients app mobile :

• SDK version actuelle. Meta met à jour son SDK tous les trimestres. Rester à jour n'est pas optionnel, c'est la base.
• Événement d'installation mappé. L'événement "InstallApp" ou "AppInstall" doit être le premier événement fiable. Pour les apps natives, c'est automatique. Pour les apps Flutter ou React Native, il faut vérifier.
• Événements de valeur trackés. Inscription, premier achat, souscription, consultation clé. Minimum trois événements au-delà de l'install. Maximum sept. Au-delà, c'est du bruit.
• SKAdNetwork 5 activé explicitement dans Info.plist (iOS). Sans cela, SKAdNetwork 4 reste le standard, et vous ratez les derniers signaux de conversion.
• Aggregated Event Measurement (AEM) configuré. AEM est le mécanisme de Apple qui envoie les signaux SKAdNetwork de manière agrégée et délayée. Chaque événement métier doit être mappé sur une conversion value qui reflète la hiérarchie de valeur en backend.
• Domain verification pour CAPI. Si vous utilisez CAPI en serveur-side, Meta doit vérifier votre domaine. Ce point est souvent oublié et crée des pertes de données silencieuses.

J'ai vu deux clients récemment qui n'avaient SKAdNetwork 5 que partiellement configuré. Le résultat : une moitié des installs iOS était invisible à Meta. D'où une sous-optimisation grave et un ROAS mesuré faussement optimiste.

Architecture de compte : une campagne = une fenêtre d'attribution

Ici je me sépare volontairement du template "une campagne par plateforme" (Ads Manager, Ads Manager mobile, etc.) qui était courant jusqu'à 2024. Maintenant, mon approche :

Une campagne Meta = une fenêtre d'attribution claire et testée. Par exemple :

• Campagne "App Install - 7 jours" (optimisation sur installs avec feedback d'événement 7j)
• Campagne "App Install - Post-Install Value (PIV)" (optimisation sur événement au-delà de l'install)
• Campagne "Retention - Rengagement 14j" (reactivation des users dormants avec SKAdNetwork 5 en fallback)
• Campagne "Lookalike - Tier 1 (0-1%)" (similaires de meilleurs convertisseurs)

Cette séparation force la clarté mentale : chaque campagne doit répondre à une seule question d'attribution. Si vous mélangez "install rapide" et "install avec première session de qualité", l'algorithme Meta oscille et ne converge jamais. En les séparant, chacune peut se calibrer.

Budget. Je demande systématiquement au client de commencer avec au moins 3 % du ROAS estimé en budget quotidien. Example : si l'app installe actuellement 100 users par jour organiquement, et que vous ciblez un ROAS 2.5x, le budget d'apprentissage devrait être ~30 euros/jour minimum pour 10 jours. Meta a besoin de cette "masse d'apprentissage" pour calibrer SKAdNetwork.

Naming convention que j'utilise (et pourquoi)

Le naming a l'air trivial. Il n'est pas. Une campagne mal nommée est une campagne mal gérée. Ma convention :

[OBJECTIVE]_[GEO]_[AUDIENCE]_[WINDOW]_[CREATIVE_ANGLE]

Example : APP_INSTALL_FR_LOOKALIKE_1PCT_7D_PROMO_V2

OBJECTIVE : APP_INSTALL, APP_ENGAGEMENT, RETENTION, GROWTH.

GEO : FR (France), EU (EU hors FR), INTL (tous pays), ou code pays exact (GB, DE, IT).

AUDIENCE : LOOKALIKE (lookalike d'une audience personnalisée), LOOKALIKE_1PCT (exact 1%), LOOKALIKE_2PCT (1-2%), COLD_INTEREST (intérêts "froids"), LOOKALIKE_SUBS (lookalike d'abonnés).

WINDOW : La fenêtre d'attribution. 7D (7 jours), 14D, 1H (optimisation ultra-rapide, rare), PIV (post-install event).

CREATIVE_ANGLE : PROMO (réduction), BENEFIT (bénéfice produit), SOCIAL (preuve sociale), USP (unique selling proposition).

VERSION : _V1, _V2, _PAUSE (campagne en repos pour observer les résidus).

Pourquoi ce naming ? Quand vous avez 30 campagnes et que vous explorez un problème en 6 minutes, vous lis le nom et sais immédiatement la logique sans clicker. Aussi, si vous devez passer le compte à quelqu'un d'autre (agence, freelance), la structure se lit seule.

Audiences : l'art du Lookalike post-cookie

En 2026, les lookalikes restent la base. Mais leur qualité a baissé légèrement depuis qu'Apple et Google ont dégradé les identifiants. Meta ne peut plus pister aussi finement qui vient d'installer votre app, donc les seedlists (listes de seed pour créer le lookalike) deviennent critique.

Ma hiérarchie d'audiences :

1. Lookalike 0-1% (seedlist 1000+ users) : Vos meilleurs convertisseurs des 30 derniers jours. L'app doit tracker un événement "high_value_user" ou "premium_subscriber" pour isoler clairement. Audience : ~500k-1M en France, très serrée, très pertinente. Remplissage : 7-15 jours.
2. Lookalike 1-2% : Tier 2. Budget 30-40% du tier 1. Remplissage similaire.
3. Lookalike multi-événements : Nouvelles depuis 2025. Au lieu d'une seedlist "high_value", Meta accepte une seedlist multi-événements (installs + première session + premier achat + etc.). La pondération est ajustée par Meta. J'utilise ça en palliatif quand la seedlist de tier 1 est trop petite (<300 users).
4. Audience personnalisée + lookalike : Créer une audience personalisée "Website Visitors" ou "Email Subscriber" en dehors d'app, puis un lookalike dessus. Rarement pertinent pour app mobile pure, mais utile si vous avez un site web fort.
5. Cold Interests (fallback) : Si les lookalikes sont épuisées (rare en France, moins rare en petits pays), viser des intérêts "froids" liés au vertical de l'app (jeux, productivité, etc.). Performance : ~3x plus cher pour 50% moins de qualité. À éviter si possible.

Un piège courant : mettre une seedlist trop petite (<100 users) en lookalike. Meta la dilue dans du bruit et vous générez des installs non-qualifiés. Mieux vaut 5 lookalikes solides qu'une vingtaine de seedlists faibles.

Créatifs : 6 ratios à tester systématiquement

L'aspect créatif n'est jamais le point de levier principal en app install, mais il peut être le point de ciseau : un créatif mauvais peut tuer une bonne campagne. Ma rule :

Tester trois ratios d'images/vidéos à minima : 1:1 (square), 4:5 (portrait), 16:9 (paysage). Dédoubler en vidéo courte (3-6 sec) et image statique.

Résultat : 6 créatifs de base. Pour chacun :

• Image 1:1 statique (avec headline, pas d'overlay video play button)
• Image 4:5 statique (priorité Stories, Reels feed)
• Image 16:9 statique (moins utilisée, mais test complet)
• Video 3sec 1:1 (hook en 1 seconde maximum)
• Video 6sec 4:5 (setup + benefit + CTA)
• Video 6sec 16:9 (tests rares, données faibles)

Les trois qui performent au-dessus de la médiane deviennent permanents. Les trois faibles sont archivées après 10 jours minimum (laissez Meta une chance de sortir de la phase d'apprentissage).

Un truisme : en mobile app install, la vidéo courte (hook immédiat) bat les images statiques en général. Mais toujours deux-trois clients testent "juste une belle image" et perdent 40% de ROAS vs vidéo. La video, c'est l'habitat naturel de Mobile.

Budget alloué : la règle des 70/20/10 pour scaler sans tuer le ROAS

Un client arrive avec 5000 euros par mois. Comment les dispatche-je ?

Règle 70/20/10.

• 70% (~3500€) sur les campagnes consolidées de tier 1. Les lookalikes 0-1%, les audiences qui ont prouvé un ROAS >= 2.5x sur 14 jours minimum. C'est ici qu'on maximise le volume.
• 20% (~1000€) sur l'expansion. Lookalikes 1-2%, intérêts nouveaux, géographies adjacentes. Tests quantifiés mais non-core.
• 10% (~500€) sur l'expérimentation. Nouvelles audiences, creative angles exotiques, nouvelle géographie, test de fenêtre d'attribution inédite. Cette part génère 30-40% de perte court-terme mais détecte les prochains gains. Impératif.

Si vous ne faites pas l'expérimentation, vous stagnez. Mais si vous la sur-ponderez, vous coulez le ROAS global. 70/20/10 est simple et robuste.

Scaling progressif : je n'augmente jamais les budgets de >20% par semaine, même si le ROAS crie au-dessus de 3x. Pourquoi ? Parce que Meta réattribue le budget et l'algorithme se réajuste. Si vous doublé en trois jours, vous générez du chaos. Montez 10-20%, observez 7 jours, puis ajustez.

Mode "Cost Cap" vs "Bid Cap" en 2026

Meta offre trois stratégies d'enchères pour app install : Lowest Cost (méthodologie classique), Cost Cap, et Bid Cap. En 2026, mon stance :

Cost Cap (objectif : installer 100 users en dépensant au maximum 15€ par install) demeure le levier principal. C'est contre-intuitif pour qui vient du Google Ads (où on vise un CPA), mais c'est le langage de Meta. Cost Cap crée une "barrière de prix" : Meta dépense si et seulement si l'install projete un coût <= cap. Cela force une discipline d'enchère.

Mes seuils de Cost Cap selon vertical :

• Gaming casual, libre-à-jouer : 1-3€ par install. Optimisation sur engagement d'après 7j.
• Productivité, finance, B2B : 5-12€ par install. Optimisation sur premier achat ou inscription.
• E-commerce, retail : 8-20€ par install. Optimisation sur premier achat, valeur panier.

Bid Cap (vous dites "je veux enchérir max 10€ par impression") est moins utilisée en app install. Je la réserve pour du remarketing strict ou de la rétention sur audience serrée. C'est trop volatil pour l'install.

Lowest Cost (Meta dépense ce qu'il faut, quand il faut) : je l'utilise seulement en phase d'apprentissage ultra-rapide ou quand le client accepte un ROAS 1.5-2x pour du volume pur. Sinon, trop chaotique.

Mon dashboard de monitoring quotidien

Chaque matin, 30 minutes. Les chiffres à regarder :

1. Installs jour N-1 vs semaine N-7 à même jour. Progression ou plateau ?
2. Cost per Install (CPI) vs budget moyen. Drift >15% ? Algorithme se rééquilibre ou audience saturée ?
3. Impressions vs Clicks (CTR). Si CTR baisse >20% une jour, c'est créatif fatigue ou changement d'algorithme Meta.
4. Breakdown par campagne. Quelle campagne drivé la majeure partie des installs ? C'est censé être le tier 1 (70% du budget). Si le 10% expérimental dépasse, il faut promouvoir.
5. ROAS projeté 7 jours. Meta donne une estimation de ROAS "par installs en attente de feedback d'événement". Elle est bruitée, mais utile pour détecter une dégradation lente.
6. Taux de déploiement (Delivery). La campagne peut-elle dépenser son budget quotidien ? Si Delivery <50%, c'est trop serré. Si >90%, c'est un potentiel de scalage.

Je fais ça dans un dashboard d'export CSV qui consolide Ads Manager + backend (installs, événements post-install). Les KPIs sont comparés à une baseline établie semaine 1.

Une erreur que j'ai vue chez trois nouveaux clients

Symptôme : campagne qui installe bien (300 installs/jour), mais les événements post-install ne remontent pas à Meta. Résultat : Meta croit que tous les installs sont de qualité zéro et réduit les enchères. ROAS réel = 2.5x, ROAS mesuré = 0.8x.

Cause n°1 (chez 2 clients) : SDK Meta mal lié au système d'analytics backend. L'app track l'événement (ex : "first_purchase") en Firebase ou Amplitude, mais le SDK Meta n'en sait rien. Il faut un bridging server-side.

Cause n°2 (chez 1 client) : Domain verification manquante pour CAPI. Meta envoie des signaux d'événement, l'endpoint les reçoit, mais Meta n'a jamais validé le domaine. Donc Meta les ignore silencieusement en sécurité.

Cause n°3 (chez tous) : Pas de test du SKAdNetwork sur iOS. Ils testaient sur Android en priorité (plus de données, AAID encore actif), et ignoraient iOS. Puis iOS 17.4 arrivent et "surprise, on voit rien". Leçon : testez SKAdNetwork dès jour 1, même si c'est peu de signal au départ.

Correction rapide : audit CAPI et server-side tracking de bout en bout. Une demi-journée. Cela change tout.

Conclusion : où aller maintenant

En 2026, piloter une campagne Meta pour app mobile demande moins de virtuosité créative qu'en 2022, mais beaucoup plus de structuration méthodique. L'IDFA est mort, les signal SKAdNetwork sont délayés, et vous ne saurez jamais avec certitude où vient réellement chaque install. Acceptez l'incertitude. Construisez une structure qui fonctionne malgré.

Les points clés :

• SKAdNetwork 5 + AEM configuré avant jour 1.
• Une campagne = une fenêtre d'attribution claire.
• Naming impeccable pour la gouvernance.
• Lookalikes solides, seedlists >500 users.
• Six créatifs testés (trois ratios, deux formats).
• Allocation 70/20/10 (core / expansion / test).
• Cost Cap rigoureux par vertical.
• Monitoring quotidien, dashboards consolidés.
• Vérifier CAPI + server-side dès le début.

Si vous pilotez une app mobile et que votre structure est floue, ou que vous lancez une nouvelle campagne, ces principes vous mettront en avance de 80% des comptes que je vois.

📖 Sources : Pratique quotidienne sur campagnes app mobile Meta 2025-2026. Méthodologies croisées avec documentation Meta Ads Center, SKAdNetwork 5 (Apple), Privacy Sandbox roadmap (Google), et retours de terrain agences partenaires.