Indicateurs d'app mobile pour les marques Shopify : que mesurer au-delà des installations

Au-delà des installations, une marque Shopify devrait mesurer si son app mobile change le comportement des clients : la part du chiffre d'affaires réalisée par l'app, l'activation jusqu'au premier achat, le réachat, la contribution du push, la demande sur le catalogue et la santé de l'expérience. App Store Connect et Google Play Console mesurent bien l'acquisition et les téléchargements, mais pas les commandes Shopify, où se trouvent ces réponses.

Les installations, les sessions et les ouvertures de notifications push peuvent sembler bonnes alors que les résultats commerciaux restent faibles. Utilisez un second tableau de bord avec les données de la plateforme et du commerce.

Ce guide couvre les indicateurs qui montrent si l'app remplit son rôle de canal de vente.

Il couvre aussi le problème que presque toutes les marques rencontrent avant d'arriver aux indicateurs : l'outil. Si votre plateforme d'app ne vous donne pas de tableau de bord commerce, vous vous rabattez sur Google Analytics 4 et sur les deux consoles des boutiques. Cette combinaison rapporte bien l'activité dans l'app. Elle ne rapporte pas l'état de vos commandes Shopify, et c'est là que se trouve la réponse.

Utilisez-le avec les guides de plateforme : App Store Connect Analytics pour les marques Shopify couvre l'acquisition et l'engagement sur iOS, et Google Play Console Analytics pour les marques Shopify couvre l'équivalent Android.

Le bon modèle de mesure

Ne surveillez pas un tas d'indicateurs isolés. Utilisez une chaîne qui montre si les clients avancent :

Portée -> Installation -> Première session utile -> Navigation
-> Panier -> Achat -> Réachat -> Valeur à long terme
   (la connexion et l'autorisation de notifications sont des
    étapes du parcours, pas des passages obligés avant de naviguer)

Un tableau de bord qui ne rapporte que les installations, les sessions ou les ouvertures de notifications push peut sembler bon alors que les clients bloquent avant d'acheter. La connexion et l'autorisation de notifications ne sont pas obligatoires pour tous les acheteurs. Beaucoup d'apps de retail permettent de naviguer et d'acheter en tant qu'invité. Traitez-les comme des étapes à mesurer, pas comme des passages à imposer. Le tableau de bord doit couvrir six fonctions :

La suite de ce guide reprend ces six fonctions une par une, puis ajoute un rythme de revue et une courte liste des chiffres qui trompent. Mais avant tout cela, une règle.

Définissez chaque indicateur avant de le comparer

Beaucoup de tableaux de bord définissent mal leurs indicateurs. « Taux de conversion de l'app », « chiffre d'affaires par client de l'app », « taux de réachat », « chiffre d'affaires attribué » et « valeur à long terme » admettent chacun plusieurs calculs valables mais différents. Sans définitions, vous comparez des choses différentes et vous tirez la mauvaise conclusion.

Donc, pour chaque indicateur du tableau de bord, notez huit choses :

1. Numérateur : exactement ce que vous comptez.
2. Dénominateur : exactement ce par quoi vous divisez.
3. Règle d'identité du client : appareil, compte ou client identifié.
4. Fenêtre d'attribution : la durée pendant laquelle un contact reçoit le mérite d'un résultat.
5. Règle de canal : l'app seule, ou tous les canaux qu'un client utilise.
6. Fuseau horaire : le fuseau utilisé par le chiffre, et s'il correspond à celui du système auquel vous le comparez.
7. Traitement des remboursements et des retours : brut, ou net des annulations et des retours.
8. Responsable : la seule personne qui répond du chiffre et de son seuil.

Et une règle ferme qui en découle : ne comparez pas un indicateur de l'app à un indicateur du site tant que leurs définitions ne correspondent pas. L'erreur classique paraît anodine. Une équipe divise les commandes de l'app par les utilisateurs connectés de l'app, divise les commandes du site par toutes les sessions Shopify, et annonce que l'app convertit 5 fois mieux. C'est faux. Ce sont deux fractions différentes avec deux dénominateurs différents, et l'écart tient surtout à la définition, pas à la performance. Corrigez d'abord les dénominateurs, comparez ensuite.

Voici à quoi ressemble un indicateur bien défini en pratique. Quatre lignes pour commencer, dans le format que chaque indicateur de votre tableau de bord devrait finir par suivre :

Remarquez que les quatre dépendent des données Shopify, pas de la seule app. C'est bien l'idée : dans une marque de commerce, le système de référence pour l'argent est Shopify, et le tableau de bord de l'app y puise ses chiffres.

Si Google Analytics 4 est votre seul tableau de bord d'app

Google Analytics 4 est un outil d'événements et de publics. Ce n'est pas la source de vérité pour l'argent, et cinq de ses comportements documentés méritent d'être connus avant de bâtir sur lui le tableau de bord commerce d'une app.

Il ne sait rien d'un remboursement Shopify si vous ne le lui envoyez pas. Google Analytics 4 n'enregistre un remboursement que si votre app envoie un événement refund portant le transaction_id correspondant (mesure de l'ecommerce dans Google Analytics 4). L'état des commandes Shopify, les annulations et les retours ne remontent pas d'eux-mêmes. Le chiffre net des retours, celui que réclame toute discussion financière, est donc quelque chose que vous devez construire et maintenir.

Les données au niveau de l'événement expirent, et l'offre payante n'y remédie qu'en partie. Sur une propriété standard, vous pouvez conserver les données utilisateur et événement pendant 2 mois ou 14 mois. Analytics 360 ajoute 26, 38 et 50 mois, mais pour les données événement seulement. La conservation des données utilisateur reste plafonnée à 14 mois sur les deux offres, et les données d'âge, de genre et d'intérêts sont toujours gardées 2 mois, quel que soit votre réglage. Il y a en plus un plancher que vous ne maîtrisez pas : quand une propriété standard devient Grande, ou qu'une propriété 360 devient XL, la conservation des données événement passe automatiquement à 2 mois, et les données de plus de 2 mois deviennent inaccessibles et sont supprimées définitivement (conservation des données dans Google Analytics 4). Lire une cohorte d'une année sur l'autre est donc une fonction 360, et même sur 360 ce n'est pas garanti.

Les rapports à forte cardinalité se condensent dans une ligne « (autre) ». Dès qu'un tableau dépasse sa limite de lignes, Google Analytics 4 affiche les valeurs de dimension les plus fréquentes et condense le reste dans une seule ligne « (autre) ». La recommandation de Google est de traiter comme dimension à cardinalité élevée toute dimension comptant plus de 500 valeurs, et elle précise clairement que ces 500 sont une recommandation et non une limite : les limites réelles de lignes varient selon le type de propriété, selon le rapport et selon la complexité de la requête, par exemple avec des dimensions secondaires et des filtres (la ligne « (autre) » dans Google Analytics 4). L'identifiant produit et le terme de recherche sont précisément les dimensions dont une marque de commerce a besoin, et précisément celles qui comptent des milliers de valeurs.

Les grandes requêtes sont échantillonnées, ce qui est encore une autre limite. L'échantillonnage n'est pas le même mécanisme que la ligne « (autre) », et il vaut mieux ne pas les confondre. L'échantillonnage se déclenche quand le nombre d'événements derrière un rapport, une exploration ou une requête dépasse le quota de votre propriété. Ce quota est de 10 millions d'événements sur une propriété standard, et jusqu'à 1 milliard sur Analytics 360, qui démarre à 100 millions d'événements par requête (échantillonnage des données dans Google Analytics 4). Google extrapole ensuite l'échantillon vers un chiffre correct en tendance. Cela convient pour une tendance de trafic. Cela ne convient pas pour rapprocher le chiffre d'affaires de Shopify, car vous ne pouvez pas relier une estimation extrapolée à un ensemble précis de commandes.

Certaines lignes vous sont masquées. Google Analytics 4 applique des seuils et masque des lignes quand un rapport contient des données démographiques ou de termes de recherche et que le nombre d'utilisateurs est trop faible (seuils de données dans Google Analytics 4). Élargir la plage de dates peut les faire revenir, ce qui est l'inverse de ce dont une revue quotidienne de semaine de lancement a besoin.

Il existe une porte de sortie, pour les marques assez grandes pour s'en servir. Google Analytics 4 exporte les données d'événement brutes vers BigQuery, et ce qui y arrive vous appartient. Comme vous interrogez ensuite vos propres tables, la ligne « (autre) », les quotas d'échantillonnage et les seuils cessent de s'appliquer, et le réglage de conservation de Google Analytics 4 cesse de régir ce que vous avez déjà exporté. Ce sont des limites des surfaces de reporting de Google Analytics 4, pas des limites sur les données exportées. L'export quotidien est plafonné à 1 million d'événements par jour sur une propriété standard et à 20 milliards sur 360, et une option en streaming supprime le plafond de volume contre des frais au gigaoctet (export de Google Analytics 4 vers BigQuery). La contrepartie, c'est que vous gérez désormais un entrepôt de données : coûts de stockage et de requête, SQL, et quelqu'un pour joindre les événements Google Analytics 4 aux commandes Shopify et tenir ces jointures à jour quand l'un des deux côtés change. La plupart des marques Shopify ne devraient pas s'y engager. Si vous avez déjà une équipe data, c'est la bonne façon de faire répondre Google Analytics 4 à des questions de commerce.

Rien de tout cela ne fait de Google Analytics 4 un mauvais outil. Cela l'écarte simplement comme unique source de vérité du chiffre d'affaires. Utilisez-le pour ce qu'il fait bien : l'analyse de l'acquisition, des campagnes et des publics. Lisez la couche commerciale dans Shopify et dans un tableau de bord d'app bâti sur les données de commandes Shopify, pour que les remboursements, les remises, le type de client et le réachat arrivent déjà rapprochés au lieu d'être reconstruits à partir d'événements.

Le même test s'applique à tout outil qu'on vous propose. Posez-lui trois questions. Lit-il l'état des commandes Shopify, remboursements et annulations compris ? Peut-il rapporter une cohorte un an plus tard ? Définit-il ses propres indicateurs, ou laisse-t-il chaque analyste les définir ? Un outil qui échoue aux trois est un rapport de trafic, pas un tableau de bord commerce.

Le tableau de bord minimal

Commencez par ces huit. Ils couvrent les six fonctions et montrent si l'app fonctionne, avant que vous n'ajoutiez un modèle plus complet :

1. Part du chiffre d'affaires de l'app (chiffre d'affaires de l'app / chiffre d'affaires en ligne total)
2. Taux de conversion de l'app (avec un dénominateur défini et comparable à celui du site)
3. Taux d'activation au premier achat (de la nouvelle installation à la première commande)
4. Taux de réachat client à 30 jours (deuxième commande, tous canaux)
5. Fidélisation J30 (les nouveaux utilisateurs de l'app reviennent-ils)
6. Taux d'autorisation et taux de désabonnement des notifications push (à lire toujours ensemble)
7. Taux de réussite du paiement (le point de rupture où l'intention d'achat est la plus forte)
8. Sessions sans plantage (la base de tout le reste)

Tout ce qui suit dans les cinq sections ci-dessous sert à approfondir quand l'un de ces huit chiffres soulève une question. Une marque plus petite devrait commencer là et résister à l'envie d'instrumenter trente indicateurs que personne ne relit.

1. Indicateurs commerciaux : la vue de direction

Ils se placent en haut du tableau de bord, mais se lisent par cohortes, pas seulement en totaux quotidiens :

• Part du chiffre d'affaires de l'app : la part du chiffre d'affaires en ligne total qui passe par l'app.
• Taux de conversion de l'app : les commandes divisées par un dénominateur clairement défini de sessions app ou d'acheteurs qualifiés (voir le tableau de définitions ci-dessus ; c'est l'indicateur le plus souvent gonflé par une comparaison mal posée avec le site).
• Panier moyen : celui de l'app comparé à celui de la boutique en ligne et du site mobile, sur des définitions équivalentes.
• Chiffre d'affaires par client de l'app : meilleur que le chiffre d'affaires par installation, car il ne récompense pas une base d'installations large et peu qualifiée. Mais il ne règle pas le biais de sélection : un petit groupe de clients fidèles à forte valeur peut le rendre superbe. Lisez-le toujours avec la taille de la cohorte, le taux de réachat et une comparaison sur cohortes appariées ou groupe témoin quand la décision exige une affirmation causale.
• Deux taux de réachat, pas un seul. Ils répondent à des questions différentes, et les fusionner masque la réponse aux deux :
• Taux de réachat client : les clients acquis ou activés par l'app qui rachètent par n'importe quel canal. Cela vous dit si l'app a changé le comportement du client.
• Taux de réachat sur le canal app : les clients qui rachètent précisément dans l'app. Cela vous dit si l'app devient un canal de vente durable.
• Fusionnés en un seul chiffre, les deux taux se masquent l'un l'autre. Le changement de canal peut faire paraître l'app plus faible qu'elle n'est, et une vue centrée sur l'app peut cacher que les clients rachètent volontiers ailleurs. Suivez les deux.
• Chiffre d'affaires ou valeur à long terme par cohorte à 30, 60 et 90 jours : ce que dépensent ensuite les clients acquis ou activés sur une période. Définissez le périmètre explicitement : cette « valeur » inclut-elle tous les achats Shopify ultérieurs, tous canaux confondus, ou seulement les commandes attribuées à l'app ? Ce sont deux questions différentes, et le chiffre ne veut rien dire tant que vous n'avez pas dit laquelle vous traitez.
• Taux d'autorisation marketing par email et SMS au paiement : la part des paiements dans l'app où le client a accepté le marketing par email ou par SMS. L'app fait grandir les listes sur lesquelles repose tout votre programme de fidélisation, et c'est une valeur commerciale même sur une période où le panier moyen stagne.
• Poids des remises dans les ventes, et performance par code de remise : la valeur remisée divisée par les ventes brutes, plus ce que chaque code vous a coûté et le nombre de commandes concernées. Un canal app qui grandit grâce aux codes de remise est un dossier économique différent d'un canal qui grandit à plein tarif, et c'est la façon la plus rapide de voir lequel vous avez. C'est aussi la première donnée de la question de marge qui suit.
• Marge sur coûts variables de la commande, quand elle est disponible : le chiffre d'affaires de la commande après remise, coût produit, participation aux frais de livraison, frais de paiement et retours. Appelez-la marge sur coûts variables de la commande, et non « bénéfice du canal app », car un vrai bénéfice de canal doit aussi porter les commissions des boutiques d'applications, le développement et la maintenance, l'acquisition payante, les outils de CRM et de notifications push, le coût des remises promotionnelles et le support. Nommez les coûts que vous avez réellement inclus, pour que personne ne lise une marge comme un bénéfice complet.

Un avertissement mérite d'être posé avant que quiconque ne célèbre un avantage de l'app sur le panier moyen ou la valeur à long terme : le public d'une app se sélectionne souvent lui-même. Cette comparaison porte sur des clients qui ont choisi d'installer l'app, et qui sont souvent déjà plus fidèles et plus décidés à acheter que les visiteurs du site mobile. Un avantage de l'app est donc une observation réelle sur l'activité, pas la preuve que l'app en est la seule cause. Quand une décision exige une preuve causale, utilisez des cohortes appariées, des groupes témoins ou des déploiements contrôlés. Cette même discipline d'incrémentalité sépare un dossier économique défendable d'un dossier fondé sur l'espoir, ce que nous traitons dans le guide du retour sur investissement d'une app mobile Shopify.

Shopify désigne d'ailleurs les ventes de réachat, la fidélisation des clients et la valeur à long terme comme les mesures centrales de la fidélité, et elles appartiennent à cette couche même si votre plateforme d'app aide à les afficher (Shopify sur les indicateurs de client fidèle).

Quand les revoir : chaque semaine pour la tendance, chaque mois pour le chiffre d'affaires et la marge par cohorte, chaque trimestre pour la question stratégique de savoir si l'app justifie son investissement.

2. Indicateurs d'activation : là où se gagne ou se perd l'essentiel de la valeur

Une installation est une possibilité, pas un résultat. Le premier travail consiste à trouver le comportement le plus précoce qui annonce un client de valeur. Dans une app de retail typique, le parcours d'activation central passe par l'intention d'achat, la connexion et l'autorisation de notifications se plaçant à côté comme des étapes facultatives plutôt que des passages obligés :

Première ouverture -> marché choisi -> produit consulté -> ajout au panier
-> paiement commencé -> première commande
   étapes facultatives (à mesurer, pas à forcer) :
   connexion effectuée, autorisation de notifications accordée

Un invité peut consulter des produits, les ajouter au panier et souvent acheter sans jamais se connecter. Forcer la connexion ou une demande d'autorisation avant d'avoir montré la valeur vous coûte en général plus de clients que cela n'en apporte. Mesurez donc la connexion et l'autorisation de notifications push comme des étapes, et étudiez où elles aident, mais ne les modélisez pas comme des passages obligés pour tous. Suivez le taux d'achèvement et le délai de chaque étape, et segmentez l'entonnoir par plateforme, version de l'app, campagne, pays, client nouveau ou fidèle et point d'entrée. Les mesures d'activation prioritaires sont les suivantes :

• Taux d'installation vers première ouverture
• Taux de première ouverture vers connexion
• Taux d'autorisation pour les notifications push
• Taux de vue produit lors de la première session
• Taux d'ajout au panier
• Taux de démarrage du paiement
• Taux d'installation (ou de première ouverture) vers premier achat
• Délai médian jusqu'au premier achat

Deux chiffres d'abandon se confondent facilement, et ils ne décrivent pas la même perte. L'abandon de panier est la part des sessions qui ont ajouté quelque chose au panier et n'ont jamais atteint le paiement. L'abandon de paiement est la part des paiements commencés qui n'ont jamais été terminés. Le premier couvre une étape que le second ne peut pas voir, si bien qu'une marque qui ne regarde que l'abandon de paiement ignore la plus grosse fuite. Rapportez les deux, et dites toujours duquel vous parlez.

N'optimisez pas tous les événements précoces de la même façon. Choisissez-en un ou deux à la fois assez fréquents pour être diagnostiqués et réellement prédictifs du premier achat. Pour certaines marques, c'est la connexion ; pour d'autres, consulter un produit ou l'ajouter au panier. L'idée est de choisir votre moment d'activation délibérément, plutôt que de courir après chaque geste.

Pour que cela fonctionne, vos événements ont besoin d'une taxonomie de commerce cohérente. La référence ecommerce de Firebase, par exemple, définit des événements standards comme view_item, add_to_cart, begin_checkout et purchase, et adopter un schéma de ce type garde l'entonnoir comparable d'une plateforme et d'une version à l'autre (référence des événements ecommerce de Firebase).

Quand les revoir : chaque jour pendant la semaine du lancement et après une version majeure, deux fois par semaine le premier mois, chaque semaine une fois le parcours d'activation stabilisé. Le guide des 90 premiers jours explique ce qu'il faut attendre de cet entonnoir au début.

3. Engagement et fidélisation : mesurez le retour des clients, pas le temps d'écran

En ecommerce, plus de temps d'écran n'est pas automatiquement bon. Une personne qui a besoin de six sessions pour terminer un paiement simple est agacée, pas engagée. Mesurez donc le retour des clients :

• Utilisateurs actifs hebdomadaires et mensuels
• Sessions par utilisateur actif
• Jours actifs par client
• Fidélisation J1, J7 et J30 : si les utilisateurs de l'app reviennent après la première utilisation
• Taux de réactivation : utilisateurs inactifs qui reviennent après une relance de l'app, du produit ou du CRM
• Taux de réachat et délai entre commandes
• Sessions et clients nouveaux face aux récurrents, lus ensemble pour voir si la croissance vient de nouvelles arrivées ou d'une habitude de retour
• Désinstallations, perte d'utilisateurs ou public installé inactif
• Public inactif mais joignable : appareils vus pour la dernière fois il y a plus de 30, 60 ou 90 jours qui autorisent encore les notifications. Les désinstallations vivent dans les consoles des boutiques, mais une installation inactive que vous pouvez encore joindre est un segment sur lequel agir cette semaine

Les vrais gains sont dans les cohortes. Comparez les clients par semaine de première ouverture, semaine de premier achat, source d'acquisition, version de l'app, pays, statut dans le programme de fidélité et autorisation de notifications. Cela révèle si une nouvelle version, une incitation au lancement ou un programme de notifications a produit un groupe de clients réellement plus sain, plutôt qu'un pic global sans lendemain. Construire ce retour de façon délibérée, c'est tout le sujet du guide de croissance de l'app.

Il y a de bonnes raisons de prendre la première session au sérieux. Dans l'étude comparative d'Amplitude de 2025, 69 % des entreprises de son groupe de tête pour l'activation en première semaine figuraient aussi parmi les meilleures pour la fidélisation à trois mois. C'est une association issue d'une étude de fournisseur, pas une preuve de causalité, et le rapport le présente ainsi, mais c'est une bonne raison de mesurer l'activation comme un indicateur de fidélisation (résumé de l'étude ecommerce d'Amplitude).

Quand les revoir : chaque semaine les utilisateurs actifs, la fréquence des sessions et la réactivation, chaque mois la fidélisation J30, chaque trimestre les cohortes de réachat et de valeur à long terme.

4. Indicateurs des notifications push : mesurez à la fois le chiffre d'affaires et l'autorisation du client

Les notifications push méritent leur propre tableau de bord, car elles peuvent être l'un des leviers de fidélisation les plus forts de l'app et l'un des moyens les plus rapides de lasser le client. Suivez toute la chaîne :

Public éligible de l'app -> public autorisé -> envoyées -> distribuées
-> ouvertes -> session dans l'app -> action produit ou panier -> achat

Les indicateurs principaux :

• Taux d'autorisation pour les notifications push : destinations joignables divisées par les destinations éligibles
• Public joignable : les appareils actifs et autorisés, pas toutes les installations historiques. Notez que cela se compte en général par appareil et non par personne : un client avec un iPhone et un iPad est un client mais deux destinations joignables, donc ne lisez pas le « public joignable » comme un nombre de personnes.
• Taux de distribution : distribuées divisées par envoyées. Traitez-le comme propre à chaque prestataire et à chaque plateforme, pas comme un accusé de réception exact. Le sens de « distribuée » et la fiabilité de sa remontée diffèrent entre iOS (APNs) et Android (FCM), donc ne comparez pas les taux de distribution d'une plateforme à l'autre comme s'ils mesuraient la même chose.
• Taux d'ouverture directe : appuis divisés par notifications distribuées
• Taux de sessions influencées : les sessions app après un envoi, comparées au comportement de référence. C'est une mesure d'attribution indicative, pas causale. Une hausse par rapport à la référence est un signal, mais pour affirmer que la notification a causé ces sessions, il vous faut un groupe témoin ou un scénario alternatif crédible, car les personnes qui ont donné leur autorisation et sont actives auraient de toute façon ouvert l'app dans une certaine proportion.
• Taux de conversion des notifications push : les destinataires qui accomplissent l'action visée
• Chiffre d'affaires attribué : avec une fenêtre d'attribution définie à l'avance
• Taux de désabonnement, taux de désinstallation et fréquence des campagnes : les garde-fous de la santé du canal
• Tout ce qui précède, séparé par type de contenu. Les notifications de commande et de livraison ne se comportent pas comme les envois marketing : public différent, attentes différentes, taux de distribution et d'ouverture différents. Mélangez-les dans un seul chiffre et vous obtenez un taux d'ouverture qui ne décrit ni l'un ni l'autre. Séparez-les avant de fixer un seuil unique.

La règle qui garde les notifications push honnêtes : associez toujours un signal positif à un signal négatif. Une campagne peut faire monter les ouvertures et les commandes tout en faisant monter les désabonnements, et ce n'est pas une réussite nette.

Une autre règle d'attribution vaut pour toute la chaîne d'outils : n'additionnez jamais le chiffre d'affaires attribué aux notifications push, à l'email, au SMS, aux médias payants et à l'attribution de l'app. Une même commande peut être revendiquée par plusieurs canaux à la fois, donc additionner leurs chiffres d'affaires attribués compte deux fois et peut facilement dépasser votre chiffre d'affaires réel. Choisissez un modèle d'attribution, ou présentez séparément et clairement ce que revendique chaque canal.

Les recommandations de Braze aboutissent à un tableau de bord comparable et citent l'autorisation, la distribution, l'ouverture et le clic, la conversion, le chiffre d'affaires et le désabonnement comme les mesures essentielles (guide des indicateurs push de Braze). C'est une liste utile, même si, en tant que guide d'un fournisseur, elle sert de référence de définitions et non de preuve indépendante. Pour la stratégie derrière ces chiffres, voir le guide des notifications push et de la fidélisation. Si Klaviyo est votre plateforme de cycle de vie, le guide des notifications push Klaviyo explique quels événements de l'app envoyer et comment garder l'attribution des messages Klaviyo distincte du registre des commandes Shopify.

Quand les revoir : juste après les envois importants, chaque semaine par type de campagne et par segment, chaque mois l'autorisation, les désabonnements et l'effet à long terme sur les clients fidélisés.

5. Merchandising et demande : ce que l'app vous dit du catalogue

Une session dans l'app est un flux de signaux d'intention, et presque aucune marque ne les lit. Ces mesures transforment le comportement dans l'app en décisions de merchandising :

• Vues produit, ajouts au panier et taux de vue à panier, par produit. Un produit avec beaucoup de vues et un faible taux de vue à panier a un problème de prix, d'image, de description ou de stock, pas un problème de trafic.
• Demande en liste de souhaits. Ajouts en liste de souhaits par produit, et le taux rapporté aux vues. C'est une intention déclarée sans achat derrière, ce qui en fait une liste de réassort et une liste de campagne.
• Portée par produit. Sessions distinctes et clients distincts qui ont vu un produit, pas seulement le nombre de vues. Cela distingue un acheteur obsédé d'un intérêt large.
• Taux de recherches sans résultat, et les recherches derrière ce taux. La part des recherches qui ne renvoient rien, groupée par terme. Lues comme une liste, ces recherches sont la demande que votre catalogue, le nom de vos produits ou les synonymes de votre moteur ne servent pas. Certaines sont des produits à référencer. Beaucoup sont des produits que vous vendez déjà sous un nom que vos clients n'emploient pas.
• Recherches par session. Des recherches par session qui montent avec un catalogue stable signifient en général que la navigation échoue, pas que les clients sont plus engagés.
• Produits et variantes les plus abandonnés. Valeur et quantité laissées dans le panier, par produit et par variante. Si une seule variante domine la liste, c'est d'ordinaire un problème de stock, de taille ou de frais de livraison, pas de demande.
• Prix moyen d'ajout au panier face au panier moyen. Quand les deux s'écartent, c'est votre vente croisée ou votre politique de remises qui a changé. Trouvez laquelle.
• Performance des drops et des lancements exclusifs à l'app. Pour chaque drop ou contenu shoppable : impressions, taux de clic, vues produit, ajouts au panier, ajouts en liste de souhaits, sessions distinctes qui ont interagi, et les ventes et unités attribuées derrière. Lisez-le par drop et par format. Cela répond à la question de savoir si un lancement exclusif à l'app a créé de la demande ou n'a fait que déplacer une demande qui arrivait de toute façon, la même question d'incrémentalité que partout ailleurs dans ce guide. Une précaution : une session qui a interagi avec deux drops compte pour les deux, donc le chiffre d'affaires par drop ne totalise pas le chiffre d'affaires global.

C'est la couche où un tableau de bord d'app se rentabilise le plus vite, car chaque point de cette liste devient une décision que quelqu'un peut prendre cette semaine : réassortir, renommer, changer le prix, refaire la photo ou ajouter un synonyme.

Quand les revoir : chaque semaine les recherches sans résultat et les produits abandonnés, chaque mois le taux de vue à panier et la demande en liste de souhaits par catégorie, et avant chaque campagne ou sortie de produit.

6. Santé de l'expérience : les indicateurs qui protègent la conversion

Une app peut avoir un merchandising et une communication excellents et échouer quand même là où l'intention d'achat est la plus forte : la connexion, le paiement, le chargement d'un produit ou l'arrivée depuis un deep link. Ce sont les signaux à mettre sous alerte, mais d'abord un avertissement : personne ne les possède tous. La connexion, le paiement, l'encaissement, le catalogue, l'identité et la distribution des notifications se répartissent entre l'app, Shopify, vos prestataires de paiement, votre plateforme d'emailing et vos outils de supervision. Pour chaque signal, décidez donc quel système fait foi et qui est alerté, sinon l'alerte sonne dans le vide :

Un signal mérite d'être nommé, car il est peu coûteux à surveiller et presque personne ne le surveille : les paiements par panier. Divisez les paiements commencés par le nombre de paniers distincts derrière eux. Au-dessus de 1, les clients redémarrent le paiement sur le même panier, ce qui pointe d'ordinaire vers une étape d'encaissement ou de livraison qui échoue, et non vers un acheteur qui a changé d'avis. Regardez à côté l'abandon de paiement séparé par passerelle de paiement, et une passerelle cassée apparaît en une journée au lieu d'apparaître dans une baisse mensuelle du chiffre d'affaires.

Ce ne sont pas seulement des indicateurs techniques. Un deep link qui ouvre l'écran d'accueil au lieu du produit promis, une boucle de connexion après une notification ou un gel sous Android pendant le paiement sont des fuites directes dans l'entonnoir de vente. Android définit un blocage (ANR) comme une app qui ne répond pas à temps à un événement de saisie, et ceux que l'utilisateur perçoit en interagissant font le plus de dégâts, car ils surviennent pendant que le client essaie activement d'agir (recommandations d'Android sur les ANR).

Quand les revoir : alertes continues sur les pannes graves, chaque jour après une version, revue hebdomadaire de la tendance, analyse mensuelle des versions et des appareils.

7. Analytique des boutiques d'applications : la part que seuls Apple et Google peuvent vous dire

Gardez les chiffres d'Apple et de Google dans le tableau de bord, et placez-les sous les données de commerce. Lisez cette section comme la liste des chiffres qu'aucune plateforme d'app ne peut vous fournir, car ni l'une ni l'autre des boutiques ne publie d'API pour l'essentiel. L'accès, vous l'avez déjà en tant que titulaire du compte développeur, donc servez-vous-en :

• Les impressions en boutique et les visiteurs de la fiche
• La conversion de la page produit et de la fiche
• Les premiers téléchargements et les retéléchargements
• Le parcours de l'installation à la première ouverture
• Les désinstallations, la perte d'utilisateurs et le public installé
• La source d'acquisition avant installation et la performance des campagnes
• Les avis et les notes en boutique
• Les signaux de plantage, de qualité et de fidélisation de la boutique
• Les tests de fiche et la performance des fiches personnalisées

Un de ces points demande une nuance. Les consoles possèdent la source de l'installation. Votre app possède la source de la session qui suit cette installation, via les paramètres de campagne et les référents, donc traitez la source avant installation et la source après installation comme deux mesures distinctes et non comme un seul chiffre.

Les indicateurs d'usage d'App Analytics d'Apple incluent les sessions, les appareils actifs, les plantages et les suppressions, mais reposent sur les utilisateurs qui ont accepté de partager leurs données (définitions des indicateurs d'Apple). Google Play Console propose des vues d'acquisition, de public installé, de perte d'utilisateurs, de conversion, de qualité et de comparaison avec des apps similaires (documentation des statistiques Google Play).

Elles sont précieuses pour diagnostiquer la découverte, la conversion en boutique et la santé technique. Elles ne doivent pas faire foi pour le chiffre d'affaires, le panier moyen, le réachat ou la valeur à long terme d'une boutique Shopify de produits physiques. Ces données n'entrent jamais dans les consoles des boutiques, car les commandes de produits physiques sont encaissées via Shopify, pas via la facturation d'Apple ou de Google.

Rythme de revue recommandé

Sans rythme de revue, les indicateurs deviennent des chiffres sur lesquels personne n'agit. Voici une base de travail :

Les lignes d'avant-lancement et de semaine de lancement méritent leur propre préparation ; la liste de contrôle du lancement couvre le plan des événements et le rapprochement qui rendent le reste de ce tableau fiable.

Ne vous laissez pas tromper

N'acceptez pas un chiffre flatteur sans le vérifier :

• Les installations ne sont pas des clients.
• Les sessions ne sont pas de la satisfaction.
• Les ouvertures de notifications ne sont pas du chiffre d'affaires.
• Le chiffre d'affaires attribué n'est pas forcément du chiffre d'affaires incrémental.
• Un panier moyen plus élevé dans l'app ne prouve pas que l'app en soit la cause.
• Une console de boutique ne connaît pas votre chiffre d'affaires Shopify sur les produits physiques.
• Un outil d'événements n'est pas la source de vérité pour l'argent.
• Une recherche sans résultat est une vente perdue qu'aucun taux de conversion ne vous montrera.
• Un tableau de bord global de l'app peut cacher une mauvaise version, un pays, un appareil, un segment ou une source d'acquisition.
• Un indicateur sans responsable, sans seuil et sans action à suivre est une décoration.

Ce dernier point est la discipline qui soutient tous les autres. La meilleure version d'un tableau de bord d'app n'est pas « les 25 indicateurs à suivre ». C'est : quel indicateur répond à quelle question, qui en répond, et quand l'équipe doit agir. Tout le reste est de l'activité, pas du résultat.

Le rôle de NAPPS

NAPPS est une plateforme de création d'apps mobiles natives pour les marques Shopify et Shopify Plus, et notre rôle dans ce modèle est celui de la plateforme : construire l'app que les consoles des boutiques mesurent en haut de l'entonnoir, et fournir la vue commerce qu'elles ne peuvent pas donner.

Si NAPPS peut fournir cette vue, c'est grâce à la façon dont l'app est construite. Une app NAPPS est réellement native (SwiftUI sur iOS, Jetpack Compose sur Android) et elle est raccordée à votre boutique comme un canal de vente Shopify, le paiement passant par Shopify. Les commandes et le chiffre d'affaires de l'app arrivent donc dans les rapports de Shopify, à côté de votre boutique en ligne, et les indicateurs commerciaux de la section 1, part du chiffre d'affaires, conversion, panier moyen et réachat, sont de simples comparaisons entre canaux de vente Shopify, et non quelque chose à reconstruire. (La possibilité de relier clairement chaque indicateur à un seul client dépend de votre connexion, de votre résolution d'identité et de votre configuration de reporting.)

NAPPS inclut un tableau de bord analytique bâti sur ces données de commandes, organisé au plus près des six fonctions de ce guide :

Deux choses dans cette liste comptent plus que la liste elle-même.

Les chiffres des notifications push portent une fenêtre d'attribution déclarée : les destinataires, dans les 12 heures qui suivent l'envoi. Elle est volontairement plus étroite que le crédit qu'une plateforme d'emailing ou une régie publicitaire réclamera pour la même commande. Une fenêtre étroite et nommée est un chiffre que vous pouvez mettre dans un rapport sans le gonfler, et elle vous tient à la règle de la section 4 : ne cumulez pas le chiffre d'affaires attribué de plusieurs canaux.

Les définitions viennent avec les indicateurs. L'achèvement du paiement (l'indicateur « terminé » de Shopify) et le parcours du paiement à la commande (la session a-t-elle passé commande) sont rapportés comme deux mesures distinctes, car ils répondent à deux questions différentes. L'abandon de panier et l'abandon de paiement sont séparés de la même façon. La portée des notifications est rapportée par appareil, et c'est écrit, car un client avec un téléphone et une tablette est un client et deux destinations joignables. C'est l'exercice des huit définitions du début de ce guide, fait une fois et de façon centralisée, au lieu d'une fois par analyste.

Et la part honnête. Trois choses de ce guide ne sont pas à nous de rapporter, et vous devriez vous méfier de toute plateforme qui prétend le contraire :

• Les installations, le parcours de l'installation à la première ouverture et les désinstallations vivent dans App Store Connect et Google Play Console. Aucune des deux boutiques n'offre d'API pour elles, donc vous les lisez là-bas, dans des comptes qui sont déjà les vôtres.
• Les courbes de fidélisation fondées sur l'installation, celles de type J1, J7 et J30, sont une mesure des consoles des boutiques et de l'analytique produit. Nos cohortes sont bâties sur les commandes et les clients, ce qui répond bien à la question commerciale et n'est pas le même chiffre.
• Les sessions sans plantage, les ANR et le temps de chargement des écrans appartiennent à vos outils de plantage et de performance, et aux rapports de qualité des consoles.

Le montage qui fonctionne compte donc trois surfaces, pas une : les consoles des boutiques au-dessus de l'installation, le tableau de bord de l'app et Shopify en dessous, et un outil de plantage sous tout le reste.

C'est ainsi que les clients de NAPPS peuvent suivre des chiffres que les consoles des boutiques ne montreront jamais. Le taux de conversion de l'app est en général environ 5 à 6 fois supérieur à celui du site, et environ 4,7 fois supérieur à celui du site mobile (c'est une affirmation forte, à lire avec la note de méthodologie). Le panier moyen est supérieur de 5 % à 38 % dans l'app, et la dépense par client est supérieure d'environ 47 %.

Méthodologie : à partir de données de clients NAPPS comparant le canal app à la boutique en ligne. Les résultats varient selon la marque, la période, la composition du public et l'attribution ; le public d'une app se sélectionne lui-même, donc ces comparaisons décrivent des différences observées et n'établissent pas de causalité. C'est le même avertissement de sélection que celui signalé dans la section des indicateurs commerciaux.

Zippy, la plus grande marque de mode enfantine du Portugal, en est l'exemple le plus clair : sur les sept premiers mois après le lancement, environ 34 % en moyenne de son chiffre d'affaires en ligne total est passé par l'app, et son app convertit environ 370 % mieux que le site mobile (même méthodologie et mêmes réserves). Son canal de notifications push affiche un taux d'ouverture moyen de 21 % sur des campagnes segmentées envoyées à un public qui a donné son autorisation, et non sur des envois promotionnels quotidiens : c'est exactement le type de résultat de public engagé que la section 4 sert à mesurer.

Utilisez les consoles des boutiques pour la découverte et la conversion de la fiche. Utilisez Shopify et votre canal app pour les indicateurs commerciaux, d'activation, de fidélisation, de merchandising et de santé de l'expérience qui décident si l'app fonctionne.

En résumé

Les boutiques d'applications vous disent si les gens peuvent trouver et installer votre app. Elles ne peuvent pas vous dire si l'app rend l'entreprise plus solide, car elles ne voient jamais une commande Shopify. C'est le travail d'un second tableau de bord, côté commerce, construit autour de six questions : l'app est-elle un canal de vente significatif, les nouveaux utilisateurs atteignent-ils vite la valeur, devient-elle une habitude, les notifications push font-elles revenir les clients sans abîmer leur confiance, le catalogue répond-il à la demande que les clients expriment, et l'app fonctionne-t-elle quand l'intention d'achat est la plus forte ? Un outil d'événements comme Google Analytics 4 peut aider sur l'acquisition et les publics, mais il ne détient pas l'état de vos commandes Shopify, donc il ne peut pas répondre à la première question de cette liste. Suivez la chaîne qui va de la portée à la valeur à long terme, donnez à chaque indicateur un responsable et un seuil, et examinez les chiffres flatteurs avec soin. Une plateforme d'app doit vous aider à mieux gérer un canal de commerce, pas à afficher un plus gros nombre de téléchargements.

Si vous voulez une app dont le chiffre d'affaires apparaît comme un vrai canal Shopify, mesurable comme ce guide le décrit, nous vous expliquons comment NAPPS s'y prend.