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

Clics Meta web to app sans installs dans AppsFlyer : pourquoi ?

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 Ingénierie du signal ; en savoir plus sur moi.

Quand Meta affiche des clics sur le lien et qu’AppsFlyer n’affiche aucun install, soit les installs sont là sous un autre libellé, soit l’enregistrement s’est rompu à une étape entre l’annonce et l’app. AppsFlyer rapporte les installs Meta web to app sous Facebook Ads, pas sous metaweb_int : la première vérification est donc de savoir si vous lisez le bon libellé. La seconde consiste à suivre un seul clic de test, étape par étape, jusqu’à ce qu’il manque un enregistrement. Sur iOS, un réglage change ce que Meta reçoit alors que les rapports agrégés d’AppsFlyer restent les mêmes : avec Advanced Privacy d’AppsFlyer activé, les postbacks des utilisateurs qui n’ont pas accordé l’autorisation ATT ne portent ni ID de clic ni identifiants d’appareil. Un téléphone de test qui a accordé l’autorisation peut réussir le test alors que les postbacks de tous les autres n’ont pas l’ID de clic que Meta utilise pour identifier le clic.

Cet article porte sur les annonces Meta avec le lieu de conversion Website, mesurées avec l’intégration Meta Web d’AppsFlyer (metaweb_int), pour une app installée depuis l’App Store ou Google Play, avec des événements d’essai et d’achat envoyés par le SDK AppsFlyer ou par RevenueCat. J’ai vérifié chaque affirmation sur une plateforme dans la page de l’éditeur le 1er octobre 2026. Les campagnes web qui convertissent sur le site lui-même relèvent d’un autre guide AppsFlyer et restent hors du cadre. Les campagnes de promotion d’app Meta aussi : le cas d’un événement qui arrive chez Meta sans pouvoir servir à l’optimisation est traité dans Événements d’essai et d’achat inéligibles à Meta AEM : pourquoi ?

Que peut vouloir dire “des clics mais pas d’installs” ?

Trois explications sont possibles, et chacune demande un correctif différent.

  1. Une différence de libellé. Le guide d’AppsFlyer Meta Ads: Create web-based campaigns (modifié le 15 septembre 2026) indique que les installs web to app sont rapportés “under the Facebook Ads PID” (sous le PID Facebook Ads) dans les dashboards et les données brutes. Dans les données brutes, le champ original_url conserve pid=metaweb_int, et les rapports de postbacks affichent metaweb_int comme la media source à laquelle le postback a été envoyé.
  2. Deux clics différents. Meta compte le clic sur l’annonce. Dans le parcours landing page d’AppsFlyer, le clic AppsFlyer est enregistré quand l’utilisateur appuie sur le call to action de votre page. Les visiteurs qui partent sans appuyer dessus ne comptent que comme une impression, laquelle ne donne lieu à un install que si vous activez l’attribution view through d’AppsFlyer (lookback jusqu’à 24 heures).
  3. Une vraie rupture. L’ID de clic n’a jamais atteint le lien du store, l’install n’a pas pu être matché, ou l’événement en aval n’a jamais atteint Meta.

Le test ci-dessous permet de les distinguer.

Comment suivre un clic de test à chaque étape ?

Je vérifie un seul chemin de bout en bout avant de lire le moindre chiffre agrégé.

Préparez le test de sorte qu’un enregistrement manquant ne puisse venir que de la configuration :

  • Enregistrez le téléphone comme appareil de test. L’article d’AppsFlyer Registering test devices (modifié le 28 août 2026) indique que la fenêtre de réattribution limite les attributions d’install à une par période de 90 jours : des installs de test répétés sur le même téléphone ne laissent donc aucune trace tant qu’il n’est pas enregistré. Pour un iPhone qui autorisera le tracking, la méthode d’AppsFlyer consiste à l’enregistrer par IDFA.
  • Accordez l’autorisation ATT sur le téléphone de test. Utilisez le téléphone d’un membre de l’équipe, appuyez sur Allow dans la demande ATT de votre app, et acceptez votre bannière de consentement si la landing page en affiche une. D’après l’article d’AppsFlyer Apply Aggregated Advanced Privacy framework (modifié le 11 juin 2026), le trafic web vers une app dont l’utilisateur a autorisé l’ATT obtient des données d’attribution au niveau utilisateur, pour vous comme pour le réseau publicitaire : Advanced Privacy ne limite donc pas ce que ce test montre.
  • Cliquez sur l’annonce comme le ferait un utilisateur. Sur le téléphone, dans Facebook ou Instagram, pas depuis un aperçu sur ordinateur. Si la page s’ouvre dans Safari, n’utilisez pas la navigation privée (Private Browsing) : le bulletin sur Link tracking Privacy (LTP) d’AppsFlyer, de 2023, indique qu’iOS 17 supprime fbclid dans ce mode.
  • Notez l’heure de chaque action, pour retrouver les lignes plus tard.

Parcourez ensuite les étapes dans l’ordre et arrêtez-vous à la première qui échoue.

Étape Ce qui doit exister Où regarder Si cela manque À ouvrir ensuite Résultat observé
1. Destination de l’annonce L’URL de la landing page, ou le lien d’attribution, avec pid=metaweb_int, c, af_c_id et les autres paramètres mappés L’aperçu de l’annonce dans Ads Manager, puis l’URL que le téléphone ouvre réellement Les paramètres d’URL n’ont pas été ajoutés à l’annonce L’étape 2 une fois l’URL correcte URL telle qu’ouverte, heure
2. Clic de tracking fbclid sur l’URL de la landing page et le même fbclid sur le lien sortant vers le store L’URL de la landing page et le lien du call to action sur le téléphone ; les données brutes de clics n’existent que dans Data Locker Le script ne transmet pas les paramètres, ou l’utilisateur n’a jamais appuyé sur le call to action La version de Smart Script et le mapping des paramètres fbclid vu sur les deux liens, oui ou non
3. Premier lancement Un install pour l’appareil de test Données brutes AppsFlyer, installs, filtrées par heure d’install Le SDK n’a pas démarré, ou l’appareil n’était pas enregistré et l’install a été compté comme une réinstallation L’intégration du SDK et la liste des appareils de test Ligne trouvée, heure
4. Install attribué Cet install avec Facebook Ads comme media source et metaweb_int dans original_url La même ligne de données brutes L’install a été enregistré comme organique : le clic n’a pas pu être matché à l’install De nouveau l’étape 2, puis les réglages de confidentialité Media source, original_url
5. Essai L’événement d’essai sur le même utilisateur Données brutes des événements in app d’AppsFlyer ; Customer History de RevenueCat s’il envoie l’événement L’événement n’a jamais été envoyé, ou RevenueCat ne l’a pas envoyé parce que l’attribut $appsflyerId n’était pas défini Le mapping des événements, les attributs client de RevenueCat Nom de l’événement, heure
6. Transaction payée L’événement d’achat avec revenu et devise Les mêmes rapports ; pour les achats sandbox, RevenueCat a besoin d’une clé AppsFlyer dans son champ Sandbox developer key Le revenu n’a pas été envoyé, ou il est envoyé deux fois Quel système envoie le revenu (voir plus bas) Revenu, devise, nombre
7. Livraison des événements au partenaire Des postbacks vers metaweb_int pour l’install et les événements mappés, et les événements dans Meta Le rapport de postbacks AppsFlyer avec metaweb_int ajouté à la main ; Events Manager pour le même pixel Postback non mappé, achat non réglé pour inclure le revenu, ou mauvais pixel La page de l’intégration Meta Web dans AppsFlyer Statut du postback, événement dans Events Manager

L’article d’AppsFlyer Raw data reporting overview (modifié le 11 août 2026) liste les données brutes de clics comme un rapport réservé à Data Locker : sans Data Locker, vous vérifiez donc l’étape 2 sur les liens eux-mêmes. L’article d’AppsFlyer Raw data export page (modifié le 13 août 2026) indique que les PID web comme metaweb_int n’apparaissent pas dans le menu déroulant media source ; pour voir les postbacks web, vous ajoutez le PID à la main. La page d’intégration AppsFlyer de RevenueCat note que la vue Events d’AppsFlyer affiche les événements in app par date d’install de l’utilisateur : un achat fait aujourd’hui par un utilisateur qui a installé l’app la semaine dernière se trouve donc dans la plage de la semaine dernière.

Quel lien l’annonce Meta doit-elle utiliser ?

Le guide d’AppsFlyer nomme les options par destination :

  • Landing page : une page avec OneLink Smart Script ou un Smart Banner. AppsFlyer la recommande quand l’app est sur plusieurs plateformes, ou quand vous voulez que la page explique le produit ou collecte des données. Le Smart Banner ne construit que des liens OneLink ; Smart Script peut aussi construire des liens à plateforme unique pour d’autres stores.
  • Directement vers le store : un lien d’attribution AppsFlyer, OneLink, à plateforme unique ou multiplateforme. AppsFlyer ajoute un avertissement : “Sometimes, the use of AF attribution links may lead to errors” (l’usage des liens d’attribution AF peut parfois conduire à des erreurs). Il suggère de demander à Meta, ou d’utiliser plutôt une landing page.

Dans Ads Manager, la campagne utilise le lieu de conversion Website avec le même ID de pixel que celui saisi dans AppsFlyer. Dans la section Tracking, AppsFlyer indique de ne pas choisir App Events, “otherwise Meta will claim those conversions using the SRN API” (sinon Meta revendiquera ces conversions via la SRN API). Si AppsFlyer n’affiche aucun clic, aucune impression ni aucun coût pour la campagne web, son guide indique que le lien a besoin de af_c_id et que le compte publicitaire doit être connecté dans l’intégration Facebook Ads.

Que doit-il arriver à fbclid ?

Meta l’ajoute et AppsFlyer le transporte. La page développeur de Meta ClickID and the fbp and fbc Parameters décrit l’ID de clic comme un paramètre généré par Meta, transmis avec l’URL quand quelqu’un clique sur une annonce, et avertit que la valeur est sensible à la casse. AppsFlyer indique que Meta ajoute fbclid automatiquement à l’URL de destination.

Sur une landing page, l’article d’AppsFlyer Set up Smart Script to convert web visitors (modifié le 2 septembre 2026) indique que Smart Script transmet fbclid tout seul à l’URL sortante à partir de la version 2.8.1. Pour la version 2.8.0 et les versions antérieures, le guide Meta web indique de le mapper à la main. Pour voir la valeur dans les données brutes, mappez-le aussi sur l’un des paramètres af_sub1 à af_sub5. Le guide Meta web qualifie fbclid d’essentiel pour envoyer les postbacks d’événements in app à Meta, et c’est pourquoi l’étape 2 du tableau vérifie la valeur sur les deux liens.

Pourquoi les installs apparaissent-ils sous Facebook Ads et non sous metaweb_int ?

C’est voulu. Le guide Meta web indique que les événements partent vers Meta sous metaweb_int mais apparaissent sous Facebook Ads dans les dashboards Overview et Activity et dans le champ media_source des données brutes et des rapports d’API. Pour séparer les campagnes web des campagnes d’app, AppsFlyer suggère un préfixe ou un suffixe web dans le nom de la campagne ; pour confirmer un install, lisez son original_url.

Que change l’étape Advanced Privacy, et qui en décide ?

Le guide Meta web d’AppsFlyer inclut, comme étape de configuration, “Turn off Advanced Privacy (if you are setting an iOS app integration).” Son article Aggregated Advanced Privacy explique ce que fait le réglage. Quand il est activé, les partenaires ne reçoivent que des détails de campagne agrégés pour les utilisateurs d’iOS 14.5 et versions ultérieures qui n’ont pas accordé l’autorisation ATT. Parmi les données au niveau utilisateur qu’ils ne reçoivent pas figurent l’ID AppsFlyer, le customer user ID, l’ID de clic, l’IDFA, l’IDFV, le user agent et l’adresse IP. Le guide Meta web indique que Meta utilise fbclid pour identifier le clic précis : un postback qui en est dépourvu perd donc ce rattachement. L’article Aggregated Advanced Privacy indique aussi qu’un réseau publicitaire sans intégration Advanced Privacy ne reçoit aucun postback pour les utilisateurs qui n’ont pas consenti, et que l’interrupteur d’un partenaire ne peut être désactivé qu’une fois l’interrupteur Aggregated Advanced Privacy au niveau de l’app désactivé.

Ce réglage n’est pas un interrupteur à basculer pour dépanner. AppsFlyer dit lui-même de travailler avec vos conseillers juridiques et vos autres conseillers professionnels sur la façon dont Apple définit le tracking avant de désactiver le framework. La page d’Apple User Privacy and Data Use indique qu’il faut l’autorisation ATT pour tracker, et que “you may not derive data from a device for the purpose of uniquely identifying it” (vous ne pouvez pas dériver des données d’un appareil dans le but de l’identifier de façon unique), quels que soient vos réglages. AppsFlyer ajoute que même avec le framework désactivé, les données au niveau utilisateur ne peuvent pas servir à identifier un appareil de façon unique. Le propriétaire de l’app décide avec son conseil juridique en matière de confidentialité, et le plan de mesure suit cette décision. Le téléphone de test ci-dessus, avec l’autorisation ATT accordée, vous permet de vérifier la configuration sans toucher au réglage.

Les postbacks vers Meta sont-ils configurés comme AppsFlyer le documente ?

Le postback d’install est automatique ; tout le reste se mappe à la main. D’après le guide Meta web d’AppsFlyer :

  • L’intégration a besoin de l’ID du pixel et d’un jeton d’accès, et l’interrupteur du partenaire doit rester activé.
  • Les installs sont le seul postback automatique par défaut. L’essai et l’achat ont besoin d’un mapping vers un événement Meta ou vers CUSTOM.
  • Un postback d’achat doit inclure “Values and revenue”. Tout autre choix fait échouer le postback.
  • “This partner only” envoie les événements attribués à Meta ; “All media sources, including organic” envoie aussi les événements attribués à d’autres partenaires et à l’organique. C’est un réglage de postback : il change ce que Meta reçoit, pas le fait qu’AppsFlyer attribue ou non un install à Meta.
  • Les événements envoyés en server to server vers metaweb_int doivent porter ua et ip. Le SDK les ajoute ; c’est à votre serveur de le faire.
  • Les postbacks pour ce qu’AppsFlyer appelle “re-engagement” ne sont pas pris en charge sur cette intégration.

Côté Meta, la page développeur Using the API indique que les événements peuvent être vérifiés dans Events Manager dans les 20 minutes suivant l’envoi, là où la source de données affiche les événements bruts, matchés et attribués.

SKAdNetwork peut-il voir ces installs ?

Pas pour une annonce cliquée dans l’app Facebook ou Instagram. La page d’Apple Signing and providing ads liste les annonces web attribuables, “where the ad network presents an ad on a Safari web page” (où le réseau publicitaire présente une annonce sur une page web Safari), à partir de SKAdNetwork 4. La page de Google Understanding iOS App campaign measurement and reporting décrit une observabilité web to app “only on Safari browsers” (uniquement sur les navigateurs Safari) et présente Chrome et Firefox comme non pris en charge par SKAdNetwork. Une annonce dans l’app Facebook ou Instagram n’est pas sur une page web Safari, et le guide Meta web d’AppsFlyer ne mentionne pas SKAdNetwork. N’attendez pas de SKAN qu’il explique un install manquant ici.

Et si RevenueCat envoie l’essai et l’achat ?

Alors un seul système doit envoyer le revenu à AppsFlyer. La page AppsFlyer de RevenueCat demande de “remove all client-side tracking of revenue” (supprimer tout suivi de revenu côté client), parce que suivre aussi les achats avec le SDK AppsFlyer “can lead to double counting of revenue” (peut conduire à un double comptage du revenu). Elle liste aussi l’attribut $appsflyerId comme requis, indique que RevenueCat n’envoie des événements à AppsFlyer que lorsque les attributs requis sont définis, et avertit que sans l’ID AppsFlyer certains événements peuvent ne pas être livrés, ce qui se traduit par une étape 5 ou 6 manquante.

Pour les achats faits sur le web via Stripe, Paddle ou RevenueCat Billing, le réglage de RevenueCat qui route les événements du web store envoie chaque achat à une seule API AppsFlyer (Mobile S2S par défaut, ou Web S2S), et la page indique que “a purchase is never sent through both APIs” (un achat n’est jamais envoyé par les deux API). Si un achat web apparaît quand même deux fois, cherchez un suivi des achats qui tourne encore dans l’app ou un autre émetteur en dehors de RevenueCat. La page indique aussi qu’AppsFlyer prévoit de retirer People-Based Attribution d’ici la fin de 2026 : c’est un plan annoncé, pas un changement déjà intervenu. Ma façon de comparer Meta, RevenueCat et un MMP quand leurs chiffres divergent est dans Meta contre RevenueCat contre Adjust : quel chiffre croire ?

Que ne faut-il pas conclure d’un seul test ?

Un test réussi prouve que le chemin fonctionne pour un utilisateur qui a accordé l’autorisation ATT sur un téléphone, pas le taux de matching pour tous les autres. Un test en échec ne montre pas quel réglage est en cause tant que vous n’avez pas changé une seule chose et relancé le test. Aucune page d’éditeur que j’ai consultée ne documente un réglage unique comme le correctif des installs web to app manquants, et plusieurs changements à la fois masquent celui qui a compté. Notez chaque fois l’étape, le changement et le nouveau résultat observé.

Où ce traçage s’inscrit-il dans mon travail ?

Ce traçage fait partie du signal engineering : s’assurer que l’événement sur lequel la plateforme publicitaire optimise est celui que l’entreprise compte, et qu’il arrive. Si vous ne savez pas si la mesure explique les mauvais résultats d’une campagne Meta web, c’est dans le growth audit que je le vérifie, et il peut être réservé seul. Le côté Google du web to app, où les ID de clic et les uploads de conversions fonctionnent différemment, est dans Google web to app sans conversions dans AppsFlyer : pourquoi ? Pourquoi une équipe enverrait du trafic Google Search vers une app de cette façon est dans Les Google Search Ads fonctionnent-elles pour les installs d’app ?

Sources

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

Questions fréquentes

Pourquoi mes installs Meta web to app n'apparaissent-ils pas sous metaweb_int dans AppsFlyer ?

AppsFlyer les rapporte sous Facebook Ads. Son guide des campagnes Meta web indique que les attributions web to app apparaissent sous Facebook Ads dans les dashboards Overview et Activity et dans le champ media_source des données brutes, tandis que le champ original_url conserve pid=metaweb_int et que les rapports de postbacks affichent metaweb_int. Un dashboard filtré sur metaweb_int peut sembler vide alors que les installs sont là.

Une annonce Meta web to app doit-elle mener à une landing page ou directement à l'App Store ?

AppsFlyer prend en charge les deux. Il recommande une landing page avec Smart Script ou Smart Banner quand l'app est sur plusieurs plateformes ou quand vous voulez que la page explique le produit ou collecte des données, et des liens d'attribution OneLink, à plateforme unique ou multiplateforme, pour envoyer les utilisateurs directement au store. Il avertit aussi que les liens d'attribution peuvent conduire à des erreurs et nomme la landing page comme solution de repli.

Faut-il désactiver Advanced Privacy pour les campagnes Meta web sur iOS ?

L'étape de configuration d'AppsFlyer dit de le désactiver pour une intégration d'app iOS. Quand il est activé, AppsFlyer ne transmet pas aux partenaires les données au niveau utilisateur comme l'ID de clic, l'IDFV, le user agent et l'adresse IP pour les utilisateurs d'iOS 14.5 et versions ultérieures qui n'ont pas accordé l'autorisation ATT. Le modifier ou non est une décision de confidentialité et une décision juridique pour le propriétaire de l'app, pas une étape de dépannage, et Apple interdit dans tous les cas de dériver des données d'un appareil pour l'identifier.

SKAdNetwork peut-il mesurer les installs venus d'annonces Meta web ?

Seulement dans un cas très limité. Apple documente les annonces web attribuables pour les annonces qu'un réseau publicitaire signe et affiche sur une page web Safari, à partir de SKAdNetwork 4. La page de Google sur la mesure iOS indique que Chrome et Firefox ne sont pas pris en charge par SKAdNetwork. Le guide Meta web d'AppsFlyer ne mentionne pas SKAdNetwork, donc n'attendez pas de SKAdNetwork qu'il comble l'écart.

Pourquoi un achat web to app apparaît-il deux fois dans le revenu AppsFlyer ?

Cherchez un second émetteur. RevenueCat demande de supprimer tout suivi de revenu côté client quand son intégration AppsFlyer est activée, parce que suivre aussi les achats avec le SDK AppsFlyer peut conduire à un double comptage du revenu. Pour les achats de web store, il indique qu'un achat n'est jamais envoyé par ses deux API AppsFlyer : cherchez donc un suivi des achats qui tourne encore dans l'app ou un autre émetteur en dehors de RevenueCat.