Google web to app sans conversions dans AppsFlyer : pourquoi ?

Quand une campagne web Google n’affiche aucune conversion d’app, vérifiez quatre étapes distinctes dans l’ordre et arrêtez-vous à la première qui échoue : le lien de tracking convient à la Final URL, l’annonce est approuvée, AppsFlyer a attribué l’install sous la media source que vous consultez, et Google a accepté l’upload de conversions. Partez du type de campagne et de la Final URL, parce que la destination change la réponse. Si vos annonces envoient les gens directement vers l’App Store ou Google Play, l’upload d’AppsFlyer vers l’Offline Conversion API de Google est la voie qu’AppsFlyer documente, et Google indique que sa propre Web to App Acquisition Measurement n’est pas disponible pour les comptes dont les campagnes web envoient les utilisateurs vers un app store.

Périmètre : les campagnes web Google Ads (tout objectif sauf App promotion) qui font la promotion d’une app iOS ou Android, mesurées via l’intégration Google Ads Web d’AppsFlyer (googleads_int), avec les différences de Singular et d’Adjust signalées. Aucune des pages ci-dessous n’indique de limite régionale. Vérifié le 1er octobre 2026 sur les pages de chaque éditeur. Pour savoir pourquoi choisir cette voie plutôt que les App Campaigns, lisez Les Google Search Ads fonctionnent-elles pour les installs d’app ?. Cet article ne traite que de la mesure.

Que faut-il vérifier en premier ?

Le type de campagne et la Final URL, parce que toutes les autres règles en dépendent. Le guide d’AppsFlyer, Google Ads (AdWords): Create web-based campaigns, s’applique à tous les objectifs Google sauf App promotion et à tous les types de campagne sauf Shopping. Une App Campaign est une intégration différente, donc si c’est ce que vous diffusez, cet article n’est pas le bon.

Lisez ensuite la Final URL de l’annonce. C’est une fiche de store, votre propre page web, ou (par erreur) un lien AppsFlyer, et chaque cas demande un lien de tracking différent.

Quel lien et quelle source de conversions conviennent à votre Final URL ?

Dans le tableau, les règles sur les liens sont celles d’AppsFlyer et les règles de mesure celles de Google.

Gardez les deux sources séparées. L’upload d’AppsFlyer envoie ce qu’AppsFlyer a attribué, rapproché des clics Google par ID de clic. La Web to App Acquisition Measurement de Google, c’est Google qui compte lui-même les installs à partir des first opens importés. Dans un compte dont les campagnes web vont directement vers le store, seule la première est disponible.

De quoi le tracking template a-t-il besoin ?

Le guide d’AppsFlyer liste les éléments, et il suffit qu’un seul manque ou soit erroné pour casser le lien ou l’annonce :

• pid=googleads_int, obligatoire.
• af_siteid, obligatoire, avec la valeur de votre choix.
• c, obligatoire et statique. AppsFlyer indique qu’il n’existe pas de paramètre ValueTrack pour lui, donc saisissez le nom à la main. Mettez l’ID de campagne dans af_c_id={campaignid}, dont AppsFlyer a aussi besoin pour les données de coût, de clics et d’impressions.
• af_force_transparent=true, obligatoire. AppsFlyer indique que Google peut refuser l’annonce sans lui.
• Une redirection vers {lpurl}. La valeur {lpurl} doit utiliser HTTPS, être encodée et se trouver sur un domaine de votre liste d’autorisation de redirections.

AppsFlyer rejette af_dp, af_android_store_csl, af_ios_store_cpp, af_og_title, af_og_description et af_og_image dans cette configuration, et interdit af_base_params_forward et af_param_forwarding parce qu’ils modifient {lpurl}. Pas de paramètres en double, pas de paramètres sans valeur, pas de paramètre ValueTrack que Google laisse vide, et toute valeur définie sous Campaign URL options dans Google Ads doit correspondre au template.

Côté Google, About tracking in Google Ads indique que le template et chaque redirection doivent être en HTTPS et effectués côté serveur, et que le bouton Test vérifie que la Final URL avec votre tracking aboutit. About parallel tracking indique que le parallel tracking est obligatoire pour Search, Shopping, Display, Video et Performance Max : l’utilisateur va directement à la Final URL pendant que le template se charge en arrière-plan. AppsFlyer fonde sa règle de redirection {lpurl} précisément là-dessus.

Pourquoi une redirection qui fonctionne ne prouve-t-elle pas que la configuration fonctionne ?

Un clic qui arrive au bon endroit n’a passé que le premier de quatre contrôles. Testez-les séparément, avec un vrai clic sur un téléphone, et notez le premier qui échoue.

1. Validation du lien. Le bouton Test de Google aboutit, et le clic de test apparaît dans AppsFlyer sous la campagne attendue. Une erreur “Tracking call unsuccessful” renvoie au type de lien du tableau.
2. Approbation de l’annonce. La politique Destination requirements de Google refuse un tracking template qui ne mène pas au même contenu que la Final URL, ainsi que les destinations “solely designed to send users elsewhere” (conçues uniquement pour envoyer les utilisateurs ailleurs), ce qui compte si votre landing page ne fait que renvoyer les gens vers le store. About ValueTrack parameters indique que les modifications du template mettent 24 à 48 heures à atteindre les annonces en diffusion, donc testez une fois ce délai écoulé. About tracking in Google Ads indique que les options d’URL définies ou modifiées au niveau de l’annonce, du mot-clé ou du sitelink repassent en examen, alors que celles au niveau du compte, de la campagne ou du groupe d’annonces n’y repassent pas.
3. Attribution par le MMP. L’install apparaît dans AppsFlyer. AppsFlyer l’attribue de façon probabiliste, ou déterministe quand un install referrer est disponible.
4. Acceptation de l’upload. Google a reçu la conversion, l’a rapprochée d’un clic et l’a comptée dans la bonne action de conversion.

Un test de redirection ne dit rien des étapes 3 et 4, et ce sont elles qui sont en cause quand on constate “aucune conversion”.

Où les installs Google web to app apparaissent-ils dans AppsFlyer ?

Pour l’essentiel, pas sous le partenaire que vous avez configuré. AppsFlyer envoie les conversions à Google sous googleads_int, mais ses dashboards et ses données brutes les rapportent sous googleadwords_int, la media source de son intégration Google Ads principale, de sorte que les résultats des campagnes web et des App Campaigns se trouvent dans une seule vue. Le champ original_url des données brutes et les rapports de postbacks conservent googleads_int. Le tableau des caractéristiques de la même page ajoute que les installs peuvent apparaître sous googleads_int et les réengagements sous googleadwords_int lorsqu’une intégration SRN googleadwords_int est active en parallèle. AppsFlyer indique aussi que Google peut revendiquer lui-même certains installs de campagnes web, sous forme d’attributions googleadwords_int autodéclarées, et que cela “may become more common as Google expands support for web campaign install attribution” (pourrait devenir plus fréquent à mesure que Google étend le support de l’attribution d’installs pour les campagnes web). Pour iOS, il renvoie ces campagnes vers le Classic Dashboard et indique que le SKAN Dashboard n’est, dans la plupart des cas, pas pertinent pour elles.

Donc avant de conclure qu’il n’y a aucun install, je filtrerais le dashboard par googleadwords_int et par l’ID de campagne, je vérifierais aussi googleads_int, puis je confirmerais dans les données brutes que original_url contient googleads_int.

Pourquoi AppsFlyer affiche-t-il l’install alors que Google n’affiche rien ?

Alors l’upload échoue, ou arrive là où vous ne regardez pas. Les étapes de configuration et de dépannage d’AppsFlyer donnent les contrôles :

• Les événements sont mappés. Les installs sont le seul postback automatique. Tout autre événement a besoin d’une action de conversion Google créée comme import de clics, dont la valeur ctid est collée dans le mapping d’événements d’AppsFlyer. Une nouvelle action de conversion s’affiche comme Inactive tant qu’aucune donnée n’arrive.
• Count est réglé sur Every. AppsFlyer indique que l’action de conversion doit utiliser Every, pas One, pour accepter les uploads gbraid et wbraid.
• Les ID de clic survivent. Google ajoute gclid pour Android et pour les utilisateurs iOS qui consentent, et gbraid et wbraid pour les utilisateurs iOS qui n’ont pas consenti. Sur une landing page, l’URL sortante du bouton doit porter l’un d’eux, sinon le postback ne peut pas être enregistré. Pour les voir dans les données brutes, associez aussi chacun à son propre paramètre af_sub.
• Le jeton fonctionne. Le scope OAuth https://www.googleapis.com/auth/adwords, Sign in with Google effectué dans AppsFlyer, et l’ID du compte manager (MCC) dans les deux champs Customer ID quand plus d’un compte Google Ads diffuse l’app. Une erreur “Missing token” signifie que cette étape n’est pas faite.
• Comptes d’agence. Si une agence gère la campagne, les intégrations googleads_int de l’annonceur et de l’agence doivent toutes deux être actives, et l’agence doit se connecter avec Google, sinon le postback échoue.
• Le plan. AppsFlyer indique que googleads_int n’est disponible que sur ses plans Growth et Enterprise, pas sur Zero ni Welcome.
• Réglage de confidentialité iOS. La configuration d’AppsFlyer demande aux apps iOS de désactiver Advanced Privacy pour ce partenaire. Sa page Apply Aggregated Advanced Privacy framework indique que tant que l’interrupteur Aggregated Advanced Privacy au niveau de l’app ou l’interrupteur Advanced Privacy d’un partenaire est activé, des identifiants comme les ID de clic, l’IDFV, le user agent et l’IP des utilisateurs iOS 14.5+ sans consentement ATT ne sont pas disponibles pour les partenaires, et que l’interrupteur du partenaire ne peut être modifié qu’une fois celui de l’app désactivé. Elle demande aussi aux annonceurs de travailler avec des conseillers juridiques sur la façon dont Apple définit le tracking avant de désactiver le réglage au niveau de l’app. La page User Privacy and Data Use d’Apple dit que vous “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). C’est au propriétaire de l’app et à son conseil juridique en matière de confidentialité de décider de ce réglage avant le test.

Dans Google Ads, ouvrez l’action de conversion nommée dans le mapping, parce que la colonne Conversions peut l’omettre. La page About primary and secondary conversion actions de Google indique que les actions secondaires sont rapportées dans All conversions et ne sont pas utilisées pour les enchères, sauf si elles figurent dans un objectif personnalisé.

Une fois l’upload accepté, ce n’est pas fini pour autant. Lors d’un test sur une Google App Campaign que j’ai mené en février et mars 2026, mesuré dans AppsFlyer, l’événement de revenu envoyait 1 $ au lieu de 0 $ quand il n’y avait pas de valeur. Google a reçu ces valeurs, et le ROAS qu’il rapportait était gonflé partout, surtout sur iOS, où les volumes de conversions étaient plus faibles. C’était une App Campaign, pas une campagne web, mais la leçon vaut ici aussi : vérifiez les valeurs que Google a reçues en plus du nombre. J’ai détaillé la suite de ce test dans quelle stratégie d’enchères Google Ads est la plus performante pour les apps.

En quoi la mesure web to app propre à Google est-elle différente ?

C’est Google qui compte les installs sans l’upload de votre MMP. La page About Web to App Acquisition Measurement de Google indique :

• Elle couvre les campagnes Search, Performance Max, Shopping, Hotel, Video et Demand Gen, sur Android et iOS, et n’est pas disponible pour les comptes ayant des campagnes web qui envoient les utilisateurs vers un app store.
• Les installs indirects exigent que les événements first open des deux plateformes soient importés dans le compte qui contient les campagnes web, et apparaissent dans All conv. La colonne Web to app first conv. exige aussi que des actions in app soient importées et que les enchères ciblent l’une d’elles comme action principale.
• L’Integrated Conversion Measurement s’est étendu à l’acquisition web to app via la mesure on device, ce qui, selon Google, améliore l’attribution des installs iOS sur l’inventaire Search et Shopping de vos campagnes web chez les partenaires d’attribution tiers. Les inventaires Video et Display sont décrits comme à venir.
• Une conversion est attribuée à une seule campagne, sans double reporting entre les App Campaigns et les campagnes web, et Google indique que la même logique s’étend au reporting des partenaires.

Google indique aussi qu’il a commencé à revendiquer et à rapporter les first opens d’app générés par l’inventaire Search et Shopping dans les campagnes Search, Performance Max et Shopping. Pour Google, ce changement et l’extension de l’ICM expliquent pourquoi les installs attribués aux campagnes web peuvent augmenter chez votre partenaire d’attribution sans aucun changement de vos liens. Dans AppsFlyer, les installs que Google revendique arrivent comme des attributions googleadwords_int autodéclarées, pas via votre upload googleads_int. Ce dont l’ICM et la mesure on device ont besoin dans l’app, MMP par MMP, se trouve dans mon guide de configuration pour les App Campaigns iOS.

Est-ce que cela fonctionne de la même façon sur Singular ou Adjust ?

Non, et les différences comptent pour iOS.

Le guide Google Ads Web - Web to App Campaigns de Singular place le lien Singular dans le tracking template avec l’URL du store comme Final URL (ou votre propre site qui exécute son Web SDK), exige _global_redirect={lpurl} dans le lien, faute de quoi l’annonce est rejetée, et indique que le deep linking doit être désactivé. Sa FAQ indique que l’upload offline transmet gclid automatiquement et liste gbraid et wbraid comme à venir, et elle cite les limites de l’Offline Conversions API : conversions par clic uniquement, sans modélisation. L’intégration exige aussi que les enhanced conversions for leads soient activées dans Google Ads. Son récapitulatif d’intégration marque le view through et le réengagement comme non pris en charge. Donc, d’après la page de Singular elle-même, les clics iOS sans consentement, qui portent gbraid ou wbraid au lieu de gclid, n’ont pas encore d’ID de clic qu’il puisse envoyer.

La page Extend your Google Ads setup beyond app campaigns d’Adjust indique que Google Ads n’accepte pas les liens universels ni les liens de marque d’Adjust comme tracking template, que modifier le lien Adjust peut le faire rejeter, et que Google Ads pourrait ne pas revendiquer l’attribution pour certains utilisateurs dans les campagnes web to app.

Quelle place cela occupe-t-il dans mon travail ?

Faire revenir dans Google les conversions d’app d’une campagne web relève du signal engineering : les enchères ne peuvent optimiser que sur les conversions qu’elles reçoivent. L’ordre découle des règles ci-dessus : fixez la Final URL, faites correspondre le type de lien de tracking à celle-ci, passez les quatre contrôles, et ne lisez la performance qu’une fois l’upload accepté. Pour savoir si la mesure freine le compte, le growth audit la vérifie, et il se réserve seul. La comparaison de cette voie avec les App Campaigns est dans pourquoi une App Campaign Google dépense sur YouTube. Le même diagnostic pour Meta est dans pourquoi Meta web to app affiche des clics mais aucun install dans AppsFlyer.

Sources

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

• AppsFlyer : Google Ads (AdWords): Create web-based campaigns, modifié le 15 septembre 2026.
• AppsFlyer : Apply Aggregated Advanced Privacy framework, modifié le 11 juin 2026.
• Google Ads Help : About Web to App Acquisition Measurement, sans date de page.
• Google Ads Help : About primary and secondary conversion actions, sans date de page.
• Google Ads Help : About tracking in Google Ads, sans date de page.
• Google Ads Help : About parallel tracking, sans date de page.
• Google Ads Help : About ValueTrack parameters, sans date de page.
• Advertising Policies Help : Destination requirements, sans date de page.
• Singular : Google Ads Web - Web to App Campaigns, modifié le 24 août 2026.
• Adjust Help Center : Extend your Google Ads setup beyond app campaigns, sans date de page.
• Apple Developer : User Privacy and Data Use, sans date de page.