Les progressive web apps occupent une place croissante dans les stratégies mobiles des annonceurs. Cette approche permet de proposer une expérience proche d’une application native (installation sur l’écran d’accueil, fonctionnement hors ligne, notifications push) tout en conservant la souplesse de déploiement du web et l’indépendance vis-à-vis des stores. Beaucoup d’éditeurs choisissent cette voie pour éviter les contraintes éditoriales d’Apple et Google ou pour mutualiser leur base de code entre web et mobile. Cette dualité technique soulève des questions de mesure spécifiques, car une PWA installée se comporte tantôt comme un site web, tantôt comme une application embarquée, avec des conséquences directes sur le tracking. Chez Propuls’Lead, nous accompagnons régulièrement des annonceurs qui déploient des PWA et veulent en mesurer la performance réelle. Cet article propose une méthode pour brancher une mesure fiable et la transformer en arbitrages opérationnels exploitables.
Comprendre les spécificités techniques d’une PWA installée
Une progressive web app reste fondamentalement un site web, servi via HTTPS, mais enrichi de capacités spécifiques qui le rapprochent d’une application native. Le service worker, script JavaScript exécuté en arrière-plan par le navigateur, gère le cache, la synchronisation hors ligne et les notifications push. Le manifeste web (manifest.json) déclare les métadonnées qui permettent l’installation sur l’écran d’accueil. Une fois installée, la PWA s’ouvre dans une fenêtre dédiée sans la barre d’adresse du navigateur, ce qui crée pour l’utilisateur une impression d’application native cohérente.
Cette dualité a des conséquences directes sur la mesure. Les scripts analytiques classiques fonctionnent globalement comme sur un site web standard, mais avec des subtilités. Les utilisateurs qui ont installé la PWA sur leur écran d’accueil sont identifiés différemment de ceux qui visitent le site dans un navigateur classique, car l’origine de la session change (display: standalone dans le manifeste). Le service worker peut intercepter les requêtes et modifier le comportement attendu, ce qui complique la lecture si on n’en tient pas compte. Les notifications push, qui sont un canal d’engagement majeur des PWA, demandent une instrumentation dédiée pour être correctement attribuées aux conversions qu’elles génèrent.
Comprendre ces subtilités avant de déployer évite plusieurs pièges classiques. Le premier consiste à confondre les visites au site web classique et les sessions PWA installée, ce qui mélange deux populations aux comportements différents. Le deuxième consiste à ne pas instrumenter le service worker, ce qui rend invisibles les usages hors ligne et les notifications push. Notre article sur le tracking de l’attribution mobile approfondit le contexte d’attribution multicouche dans lequel s’inscrit la mesure PWA et les arbitrages média qu’il impose.
Distinguer dans la mesure les utilisateurs web classiques et les utilisateurs PWA installée
La distinction analytique entre visiteurs web classiques et utilisateurs PWA installée est l’un des chantiers structurants d’un dispositif de mesure mature. Les deux populations partagent le même code mais ne se comportent pas de la même façon. Un utilisateur qui a installé la PWA sur son écran d’accueil revient plus souvent, génère une session moyenne plus longue et convertit mieux, mais représente souvent une minorité du trafic total. Sans distinction explicite, ces dynamiques restent invisibles dans les rapports agrégés et les arbitrages se font à l’aveugle.
Plusieurs techniques permettent cette distinction. La détection du mode d’affichage via JavaScript (window.matchMedia(‘(display-mode: standalone)’)) renvoie une information fiable sur le contexte d’ouverture de la session. Cette information peut ensuite être propagée comme dimension personnalisée dans l’outil analytique, ce qui ouvre la possibilité de toutes les segmentations utiles. Une autre approche consiste à utiliser un paramètre UTM spécifique dans la définition du manifeste, pour que toute session lancée depuis l’icône installée soit étiquetée à la source. Ces deux approches se combinent et offrent une lecture robuste de la performance par mode d’usage.
Cette distinction alimente ensuite des décisions concrètes. Si le taux d’installation est élevé et que les utilisateurs PWA convertissent mieux, investir dans la promotion de l’installation devient un levier de croissance prioritaire. Si l’installation reste rare malgré des invitations explicites, la PWA n’apporte peut-être pas la valeur perçue suffisante pour justifier l’effort, et l’investissement doit être réorienté. Notre article sur le tracking des comportements mobiles détaille les méthodes d’instrumentation côté smartphone applicables aux PWA comme aux sites web mobiles classiques.
Instrumenter le service worker et les notifications push
Le service worker est le composant le plus spécifique d’une PWA et celui qui demande l’instrumentation la plus soignée. Sans mesure dédiée, toutes les interactions hors ligne, les chargements depuis le cache et les déclenchements de notifications push restent invisibles dans les rapports analytiques. Cette zone d’ombre peut représenter une part substantielle de l’usage réel, surtout pour les PWA centrées sur des contenus consultés en mobilité. Pour les éditeurs qui ont investi dans une PWA précisément pour ces usages hors ligne, l’absence de mesure fausse complètement la lecture du succès du dispositif.
L’instrumentation passe par plusieurs mécanismes. Le service worker peut envoyer ses propres événements analytiques via fetch vers une endpoint de collecte, en respectant les limitations imposées par certains navigateurs aux requêtes hors connexion (mise en queue puis envoi à la reconnexion). Les notifications push, qu’elles soient ouvertes ou rejetées, peuvent être trackées via les événements notificationclick et notificationclose du service worker. Le déclenchement d’une mise à jour de cache peut également remonter, ce qui aide à comprendre les schémas d’usage. La méthodologie PROPULSE que nous appliquons chez Propuls’Lead intègre systématiquement cette couche service worker dans la conception du dispositif de mesure PWA.
Plusieurs précautions opérationnelles méritent d’être prises. La première consiste à respecter les exigences de consentement RGPD pour les notifications push, qui s’appliquent strictement même dans un contexte PWA. La deuxième consiste à éviter une instrumentation trop bavarde qui dégraderait les performances perçues du service worker, censé fluidifier l’expérience et non l’alourdir. La troisième consiste à tester soigneusement le comportement de l’instrumentation en mode hors ligne, car les comportements de file d’attente diffèrent selon les navigateurs et peuvent produire des artefacts dans les rapports si on ne les anticipe pas. Notre article sur le tracking de la rentabilité par campagne détaille la mécanique d’arbitrage budgétaire applicable aux conversions remontées par ces dispositifs.
Brancher la mesure PWA aux arbitrages média et produit concrets
Une fois la mesure PWA harmonisée et le service worker correctement instrumenté, les données collectées alimentent des arbitrages concrets pris chaque semaine par les équipes média et produit. Côté média, la mesure éclaire la performance des campagnes qui orientent vers la PWA plutôt que vers une application native, et permet de comparer les coûts d’acquisition entre les deux dispositifs. Cette comparaison guide les arbitrages d’investissement futurs, car une PWA qui produit des utilisateurs récurrents à un coût d’acquisition compétitif peut justifier de revoir entièrement la stratégie applicative.
Côté produit, la mesure renseigne sur l’efficacité réelle des parcours PWA, sur la valeur générée par les notifications push et sur les points de friction qui freinent l’installation. L’analyse des sessions par mode d’affichage révèle souvent des écarts importants de comportement entre web classique et PWA installée, ce qui invite à concevoir des expériences différenciées plutôt qu’à appliquer le même design partout. Notre article sur le tracking du taux de complétion des formulaires approfondit la mécanique de mesure étape par étape applicable aux tunnels PWA, où la conversion finale peut se produire en ligne ou hors ligne avec synchronisation différée.
Plusieurs pièges méritent d’être anticipés en équipe. Le premier consiste à présenter la mesure PWA sans souligner ses limites, alors que la zone hors ligne reste un terrain où les chiffres dépendent fortement de la qualité de l’instrumentation. Le deuxième tient à la tentation de comparer brutalement les chiffres PWA et les chiffres application native, alors que les périmètres mesurés ne sont pas équivalents et que les cohortes diffèrent. Une présentation honnête de ces nuances en comité évite des décisions hâtives. Pour brancher cette lecture PWA à la cartographie des parcours, voir aussi notre article sur le tracking des parcours multi-appareils qui éclaire la lecture des étapes clés. Propuls’Lead accompagne cette mise en place avec un parti pris pragmatique hérité de 15 ans d’expérience, 500 clients accompagnés et plus de 2 000 tunnels construits : produire rapidement une lecture suffisamment fiable pour décider, plutôt que viser une perfection théorique inatteignable sur PWA. Une fois ce socle posé, les arbitrages mobile regagnent en clarté et la PWA cesse d’être un terrain de mesure incertain pour devenir un canal de croissance pilotable avec sérénité.