L'architecture de mesure
Le site est généré avec Astro : le tracking est donc écrit dans le code de l'application, pas injecté par un conteneur de tags fragile. Chaque donnée est émise nativement vers GA4, avec une nomenclature documentée.
- Propriété GA4 native :
content_grouppour regrouper les pages par type de contenu, sans regex à maintenir. - CMP Tarteaucitron : les services tiers sont bloqués tant que le visiteur n'a pas donné son accord.
- Consent Mode v2 : l'état de consentement pilote GA4 ; les signaux sans cookie alimentent la modélisation des données manquantes.
- Événements
click_store: un événement personnalisé à chaque clic vers l'App Store ou Google Play, avec le store ciblé et l'emplacement du clic.
// 1. Consent Mode v2 : tout est refusé tant que la CMP n'a pas répondu
gtag('consent', 'default', {
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
wait_for_update: 500,
});
// 2. Événement personnalisé émis par le code, pas par du scraping du DOM
gtag('event', 'click_store', {
store: 'google', // google | apple
click_placement: 'navbar', // navbar, homepage, article_full...
link_text: 'Get it on Google Play',
});Extrait simplifié et illustratif.
Résultats sur 30 jours
Période mesurée : du 11 octobre au 9 novembre 2026. Variations par rapport à la période précédente.
3 322
Utilisateurs actifs
+173,4 %
105
Utilisateurs envoyés vers un store
+75,0 %
531
Premières ouvertures de l'app
+314,8 %
3,16 %
Taux utilisateur → store
Le dashboard Looker Studio
Le rapport est organisé en cinq pages. Chacune répond à une question précise et partage les mêmes filtres : appareil, source du premier contact, langue et période.
1. Vue d'ensemble : acquisition et clics vers les stores
Des scorecards résument les utilisateurs actifs (3 322), les utilisateurs envoyés vers un store (105) et les premières ouvertures de l'app (531), chacune avec sa variation. La courbe superpose utilisateurs actifs et clics store pour repérer les pics, et un graphique en anneau répartit les clics entre Google (50,5 %) et Apple (49,5 %).

2. Contenus : quelles pages convertissent vers le store
Un tableau croise chaque page d'atterrissage avec ses utilisateurs, ses clics store, son taux de clic et sa durée d'engagement. Il montre par exemple que la page d'accueil convertit à 23,02 % (49 clics pour 127 utilisateurs), contre 0,4 % à 5 % pour les articles de blog. La durée moyenne atteint 1 min 17 s, et un camembert indique l'origine géographique du trafic, avec l'Amérique du Nord en tête (37,4 %).

3. Emplacements : où les clics ont lieu
Grâce au paramètre d'emplacement de l'événement personnalisé, un histogramme classe les clics par zone du site : la navbar concentre l'essentiel (près de 90 clics), devant la page d'accueil, le bouton de bannière d'app et les deux formats d'encart d'article. Un tableau détaille l'URL et le texte de chaque lien cliqué (« Download », « Get it on Google Play », « Laden »), ce qui permet aussi de vérifier les versions traduites.

4. Cibles : App Store contre Google Play
Cette page recoupe l'événement personnalisé click_store (133 key events : 72 vers Google, 61 vers Apple) avec les clics sortants natifs par domaine (194 clics : 106 vers apps.apple.com, 88 vers play.google.com) et par URL complète. Les paramètres de campagne présents dans les liens permettent de relier chaque clic à sa source.

5. Application : de l'onboarding à l'abonnement
La dernière page suit l'entonnoir côté application : profil d'onboarding (341), chargement (317), affichages du paywall (767), démarrages d'essai (6) et revenu (871 CHF). Elle ventile ensuite les acheteurs par produit (halal_monthly à 71,4 %), par pays et par jour de la semaine, pour relier l'acquisition web à la monétisation.

Ce que ce chantier apporte
Un seul rapport relie désormais le contenu éditorial, le clic vers le store et la conversion dans l'application, sur des données collectées nativement et conformes au RGPD. Les décisions éditoriales et produit s'appuient sur un signal, pas sur une estimation.