Les notifications push Klaviyo pour les apps mobiles Shopify

Pour utiliser les notifications push Klaviyo dans une app mobile Shopify, connectez l'app aux profils Klaviyo que vous utilisez déjà, afin que le comportement dans l'app alimente les mêmes segments et scénarios que l'e-mail et le SMS. Préparez trois choses avant d'envoyer : la taxonomie des événements, la logique des scénarios et le consentement. Le push, l'e-mail, le SMS et l'autorisation du système d'exploitation sont des états de consentement distincts.

Ne traitez pas l'app comme un canal de diffusion supplémentaire. Les notifications push, l'e-mail et le SMS ont chacun un travail différent. L'app ajoute des signaux comportementaux, par exemple ce que le client consulte, enregistre et achète, ainsi que de nouveaux endroits pour le joindre.

Ce guide explique comment planifier les notifications push Klaviyo dans une app mobile Shopify. Ce n'est pas un manuel de configuration. Utilisez les instructions d'implémentation officielles de Klaviyo pour le SDK et la configuration de la plateforme.

Prérequis avant de planifier les notifications push Klaviyo

Il vous faut une app Shopify ou Shopify Plus, une intégration Klaviyo sur n'importe quel plan NAPPS et un responsable clair de la logique de campagne. Vous devez aussi décider quels événements avant achat l'app enverra, où chaque notification push atterrira, et comment le client pourra gérer ses préférences de notification.

NAPPS prend en charge Klaviyo sur tous les plans pour l'orchestration des notifications push, de l'e-mail et du SMS avec des segments partagés, et l'app intègre l'identification de profil, le suivi d'événements, les formulaires dans l'app et les deep links depuis un message Klaviyo. Elle ne prend pas en charge le géorepérage. Cadrez le travail à partir de cette liste plutôt qu'à partir du SDK mobile complet de Klaviyo, qui documente des capacités qu'une plateforme d'app peut avoir développées ou non.

La répartition du travail est la suivante :

Si un chiffre ou une décision n'entre dans aucune de ces colonnes, la configuration n'est probablement pas claire.

L'occasion : prolongez la fiche client, pas le volume d'envois

Klaviyo est une base de données clients avant d'être un outil d'envoi. L'e-mail, le SMS et les notifications push utilisent les mêmes profils, événements et segments. Une app mobile se connecte dans deux directions :

• Entrante : l'app écrit sur le profil Klaviyo les événements d'intention avant achat (produit consulté, recherche effectuée, ajout au panier, paiement démarré, notification ouverte), afin que vos segments et scénarios puissent utiliser le comportement dans l'app aux côtés des ouvertures d'e-mail et des événements de commande Shopify qu'ils utilisent déjà. Les commandes finalisées restent avec les événements de commande de Shopify, sans événement d'app en doublon : nous y revenons plus bas.
• Sortante : Klaviyo peut joindre le client via l'app, avec des notifications push et des messages dans l'app, et l'envoyer vers une destination précise de l'app plutôt que vers un écran d'accueil générique.

L'objectif est un seul cycle de vie doté d'une surface native, pas un programme parallèle. Pour chaque client et chaque moment, choisissez le canal et la destination qui aident. Voyez le guide de rétention par les notifications push pour la coordination entre canaux.

Ce que permet le SDK mobile de Klaviyo

Klaviyo documente des SDK mobiles pour iOS, Android, React Native et Flutter, et regroupe leurs capacités en cinq domaines (présentation du SDK Klaviyo) :

La documentation du SDK de Klaviyo décrit ces capacités, et une app NAPPS intègre chacune d'elles sauf le géorepérage. Les sections suivantes couvrent les décisions que chacune vous demande encore : l'identité que vous écrivez, la taxonomie d'événements que vous arrêtez, et l'endroit où chaque message atterrit.

Identité : reliez l'activité dans l'app au profil que vous avez déjà

Tout ce qui sert en aval dépend du fait que Klaviyo sache de qui il observe le comportement. Quand un client se connecte ou crée un compte, l'app l'identifie comme un profil Klaviyo, et ses événements d'app se rattachent à la fiche qui contient son historique d'e-mails et ses commandes Shopify. Avant cela, une partie de la navigation peut être anonyme, et la façon dont ces premiers événements se rattachent ensuite à un profil est un détail à bien traiter.

Les règles pratiques à intégrer à la conception :

• Connu ou anonyme. Décidez ce que fait l'app avant la connexion. La navigation en tant qu'invité convient et convertit souvent mieux, mais sachez clairement quels événements sont capturés de façon anonyme et comment ils se rattachent à un profil dès que le client s'identifie.
• Déconnexion et appareils partagés. La déconnexion doit cesser d'associer la nouvelle activité au profil précédent, pour qu'une tablette partagée ne mélange pas deux clients.
• Une personne, plusieurs appareils et plusieurs jetons. Un même client peut détenir plusieurs jetons de notification sur plusieurs appareils : l'identité se situe donc au niveau de la personne et la joignabilité par push au niveau de l'appareil. Gardez cette distinction en tête chaque fois que vous comptez le public « joignable ».

La base d'événements : le signal qui fait fonctionner tout le reste

Les notifications push et les messages dans l'app dépendent de bons événements. L'objectif n'est pas d'envoyer plus. C'est d'envoyer quelque chose de pertinent à partir de ce que le client vient de faire.

Pour une app de commerce, les événements qui valent la peine d'être captés correspondent à l'intention d'achat avant la commande :

• Produit consulté (avec produit, collection, prix et disponibilité)
• Recherche effectuée (avec la requête, et si elle a renvoyé des résultats)
• Ajout au panier (avec produit, quantité et valeur)
• Paiement démarré (avec la valeur du panier)
• Notification push ouverte (avec la campagne et, le cas échéant, les données du bouton d'action)

Remarquez ce qui n'est pas dans cette liste : l'achat finalisé. Cette omission est volontaire, et c'est la décision d'intégrité des données la plus importante de toute l'intégration.

N'envoyez pas un second événement « achat » depuis l'app

Si votre boutique utilise l'intégration Klaviyo pour Shopify, Klaviyo reçoit déjà Placed Order et les événements de commande associés directement depuis Shopify (référence des données Shopify dans Klaviyo). Si l'app déclenche en plus son propre événement « achat » pour la même commande, vous risquez de déclencher les scénarios deux fois, de gonfler le chiffre d'affaires et de corrompre la segmentation, parce qu'une vraie commande en paraît désormais deux. La règle est donc la suivante :

• Commandes finalisées : utilisez les événements de commande de Shopify (Placed Order et les siens) comme source unique. N'émettez pas d'événement d'achat en doublon depuis l'app.
• Intention avant achat : utilisez les événements de l'app (produit consulté, recherche, ajout au panier, paiement démarré) pour tout ce qui mène à la commande.
• Si vous avez réellement besoin d'un signal de l'app au moment de l'achat (par exemple pour savoir que la commande vient de l'app), envoyez un événement clairement distinct et délibérément nommé, de passage au paiement ou de contexte de commande dans l'app, et assurez-vous qu'aucun scénario ne le traite comme une seconde commande. Dédoublonnez-le contre la commande Shopify avant qu'il puisse déclencher une logique de chiffre d'affaires ou de comptage de commandes.

La première règle sur les propriétés compte tout autant : un événement ne vaut que ce que valent ses attributs. « Produit consulté » est faible, mais « a consulté un produit de la collection X, en stock, à plus de 50 euros » est un segment.

Bien construire cette taxonomie relève du même travail d'activation et de signal comportemental qui soutient la croissance de l'app en général, que nous traitons dans le guide de croissance de l'app.

Des notifications push Klaviyo qui atterrissent quelque part d'utile

Les notifications push sont souvent la première capacité vers laquelle une marque se tourne, et la plus facile à mal employer. Une diffusion générique quotidienne apprend au client à les désactiver. Les règles produit de Klaviyo déterminent la façon de s'en servir.

Le consentement push est une décision à part, avec son propre jeton

Klaviyo indique qu'un consentement explicite aux notifications push mobiles crée sur le profil un jeton de notification propre à l'appareil. Une personne peut détenir plusieurs jetons sur plusieurs appareils, et le consentement à l'e-mail ou au SMS n'accorde pas à lui seul le consentement au push (guide du consentement push de Klaviyo, le consentement dans les profils). Deux conséquences en découlent. D'abord, demandez l'autorisation pour les notifications push en contexte, après que l'app a montré sa valeur, et non au premier lancement à froid. Ensuite, traitez l'autorisation des notifications, le consentement marketing et les préférences de thème ou de catégorie comme trois choix distincts du client, et non comme une autorisation groupée.

Klaviyo note aussi qu'il ne fournit pas de centre de préférences pour les notifications push : le contrôle visible par le client sur ce qu'il reçoit est donc construit par l'équipe de l'app. Cela relève du centre de préférences ou de confidentialité de votre propre app. Traitez-le comme une exigence de conception côté app et non comme un avis juridique : où et comment un client modifie ses préférences de notification est une question de conception du centre de confidentialité, et les distinctions de consentement plus fines appartiennent au groupe d'articles sur la confidentialité, pas à celui-ci.

Sans deep link, une notification push ouvre l'écran d'accueil

Klaviyo est explicite : sans deep link, une notification push ouvre l'écran d'accueil de l'app et laisse le client chercher ce que vous lui avez promis (introduction aux notifications push mobiles de Klaviyo). Pour une marque de commerce, c'est une fuite de conversion directe : une notification « de retour en stock » qui dépose le client sur le fil d'accueil gaspille l'intention qu'elle vient de créer. Chaque brief de campagne devrait donc nommer une destination et l'événement de succès, pas seulement un message.

Les boutons d'action rendent cette destination mesurable. Les boutons d'action de Klaviyo prennent en charge l'ouverture de l'app, un deep link et des actions vers le site, et l'événement de notification ouverte qui en résulte porte le libellé du bouton, son action et, le cas échéant, son lien, que vous pouvez ensuite utiliser dans les rapports et les segments (boutons d'action pour le push de Klaviyo). Un bouton descriptif comme « Voir la collection » rend l'étape suivante et la dimension de reporting claires. Testez-le contre un bouton générique « Acheter » sur votre propre public.

Une ouverture de push n'est pas une ouverture d'e-mail

Le reporting push de Klaviyo distingue les événements reçu, ouvert et rejeté, et une ouverture de push est un appui qui ouvre l'app (référence des indicateurs push de Klaviyo, guide de diffusion push de Klaviyo). Ne comparez pas directement un taux d'ouverture push à un taux d'ouverture e-mail : ce sont des actions différentes mesurées différemment, et la diffusion elle-même dépend du fournisseur et de la plateforme sur iOS (APNs) et Android (FCM). Jugez le push face au push, et face au résultat commercial en aval, pas face à votre tableau de bord e-mail. La stratégie complète se trouve dans le guide complet des notifications push pour Shopify.

Une campagne détaillée : les notifications push Klaviyo de retour en stock

Un brief de campagne doit répondre à plus que « quel texte allons-nous envoyer ? ». Prenez un client qui a consulté un produit en rupture et qui a accordé l'autorisation pour les notifications push.

Le tableau de bord NAPPS rapporte les sessions, les ajouts au panier, les consultations de panier, les paiements, les commandes et les ventes des destinataires d'une notification dans les 12 heures qui suivent l'envoi, ainsi que le chiffre d'affaires par destinataire. N'ajoutez pas ce chiffre au chiffre d'affaires attribué par Klaviyo, par l'e-mail, par le SMS ou par les médias payants. Ces systèmes peuvent créditer la même commande selon des règles différentes.

Les messages dans l'app : la surface après l'ouverture

Les formulaires dans l'app sont des messages que Klaviyo affiche à l'intérieur de celle-ci. Ils peuvent viser des utilisateurs ou des segments précis et se déclencher à l'ouverture de l'app, à l'ouverture d'une notification ou sur un événement suivi (comprendre les formulaires dans l'app, créer un formulaire dans l'app). Ils complètent les notifications push plutôt que de les répéter : la notification obtient l'ouverture de l'app, et le message dans l'app poursuit le parcours une fois le client à l'intérieur.

De bons usages pour une marque de commerce :

• Une annonce de lancement ou de collection quand un client engagé ouvre l'app
• Une invitation de retour en stock ou de baisse de prix liée à quelque chose que le client a consulté
• Une offre réservée à l'app, qui récompense le fait de l'utiliser
• Une surface de relance juste après l'ouverture d'une notification push, qui renforce le même message

Une limite ferme : les formulaires dans l'app de Klaviyo sont des surfaces d'annonce et d'engagement, et le produit actuel ne permet pas de s'en servir pour recueillir un consentement ou des données de profil. Ne concevez donc pas un formulaire dans l'app comme un mécanisme de consentement à la confidentialité ni comme un formulaire de collecte de données. Le recueil du consentement et des préférences relève d'écrans de l'app conçus pour cela, ce qui est un sujet du groupe d'articles sur la confidentialité et non des messages dans l'app.

Coordonnez les canaux : Smart Sending agit par canal, pas entre canaux

C'est la nuance que la plupart des marques manquent, et elle défait la promesse d'« un seul cycle de vie » si vous supposez que la plateforme s'en occupe pour vous. Le Smart Sending de Klaviyo empêche un profil de recevoir trop de messages dans une fenêtre donnée, mais il agit par canal et non entre canaux (guide du Smart Sending de Klaviyo). Un client qui vient de recevoir un e-mail peut encore recevoir un SMS et une notification push dans leurs fenêtres Smart Sending respectives, puisque chaque canal applique sa propre limite indépendamment.

Ajouter un canal de notifications push ne rend donc pas vos messages coordonnés automatiquement. La vraie coordination est un travail délibéré :

• Exclusions : excluez les destinataires du message d'un canal d'un envoi quasi simultané sur un autre.
• Séquence : décidez de l'ordre (par exemple la notification push d'abord, l'e-mail en relance) plutôt que de déclencher tous les canaux en même temps.
• Logique de relance : déclenchez le canal suivant selon que le précédent a été ouvert ou a suscité une action, et non selon une horloge fixe.

Activer le Smart Sending est nécessaire mais pas suffisant. La discipline entre canaux, c'est-à-dire décider quel message unique aide vraiment ce client à cet instant, est la partie la plus difficile. Lisez comment coordonner notifications push, e-mail et SMS avant d'ajouter une nouvelle campagne.

Un modèle de reporting : chaque indicateur dans sa source de vérité

Le moyen le plus rapide de perdre confiance dans le programme est de forcer tous les chiffres dans un seul tableau de bord. Klaviyo, Shopify, l'analytique de votre app et les consoles des stores détiennent chacun des vérités différentes. Shopify est le registre financier et opérationnel des commandes, mais Klaviyo est le bon endroit pour évaluer l'attribution des messages Klaviyo à partir de ses données de commande synchronisées. Ils répondent à des questions différentes. Le guide des indicateurs d'app mobile Shopify explique le modèle de mesure plus large. Voici la répartition propre à Klaviyo :

Deux règles gardent cela honnête. D'abord, définissez si « réachat » veut dire tous canaux ou app seulement avant d'en rendre compte, parce que ces deux versions répondent à des questions différentes. Ensuite, n'additionnez pas le chiffre d'affaires de systèmes d'attribution différents sans documenter leurs fenêtres et leur modèle. La même commande peut être créditée par plusieurs systèmes à la fois : additionner, par exemple, le chiffre d'affaires attribué par Klaviyo à celui attribué par une plateforme de médias payants le compte deux fois. Et même au sein de Klaviyo, les canaux ne sont pas trois totaux superposés qu'on peut additionner, puisque Klaviyo emploie une approche de dernier contact avec des fenêtres propres à chaque canal (documentation du suivi des conversions de Klaviyo). Choisissez un modèle et annoncez sa fenêtre, ou rendez compte séparément et clairement de ce qu'affirme chaque système.

Liste de contrôle d'implémentation

Un ordre de travail praticable, avec un responsable à chaque étape :

1. Identité : définissez la connexion, la création de compte, la déconnexion et le rattachement de l'anonyme au connu.
2. Événements : arrêtez la taxonomie d'événements et ses propriétés pour l'intention avant achat, et confirmez que Shopify détient les commandes finalisées, sans événement d'achat en doublon dans l'app.
3. Deep links : cartographiez vos destinations produit, collection, offre et compte les plus fréquentées, et définissez le comportement de repli.
4. Configuration du push : configuration iOS et Android, cycle de vie des jetons, boutons d'action et préférences de catégorie.
5. Messages dans l'app : déclencheurs et ciblage pour l'ouverture de l'app, l'ouverture d'une notification et les messages fondés sur un événement.
6. Consentement : l'autorisation des notifications est demandée en contexte ; l'autorisation, le consentement marketing et les préférences de catégorie restent séparés ; un centre de préférences est construit côté app, puisque Klaviyo n'en fournit pas.
7. Tests : vérifiez que les événements se déclenchent, que les deep links mènent au bon écran et que les notifications s'affichent correctement sur les deux plateformes.
8. Reporting : reliez chaque indicateur à sa source de vérité selon le tableau ci-dessus avant le lancement, pour que les chiffres du premier jour soient fiables.

Le géorepérage n'est pas disponible sur NAPPS

Le géorepérage de Klaviyo récupère les zones proches après l'ouverture de l'app par un utilisateur, surveille les entrées et les sorties, et crée les événements correspondants pour les scénarios, les segments et le reporting. Il exige une app mobile, une prise en charge à jour du SDK et le partage de la position (guide du géorepérage de Klaviyo).

NAPPS ne prend pas en charge le géorepérage (vérifié le 08/09/2026) : c'est donc la seule capacité de la liste mobile de Klaviyo sur laquelle vous ne pouvez pas compter dans une app NAPPS. Il ajouterait aussi un parcours d'autorisation de localisation et des obligations de confidentialité et de droit régional, ce qui explique qu'il soit rarement la raison pour laquelle une marque choisit une app.

Ce que NAPPS prend en charge aujourd'hui

NAPPS est une plateforme de création d'apps mobiles natives pour les marques Shopify et Shopify Plus. Klaviyo est disponible sur tous les plans pour l'orchestration des notifications push, de l'e-mail et du SMS avec des segments partagés. Votre équipe est responsable de la stratégie de campagne, des décisions de consentement et de toute revue juridique.

L'identification de profil, le suivi d'événements, les formulaires dans l'app et les deep links depuis un message Klaviyo sont intégrés. Le géorepérage n'est pas pris en charge. Gardez Shopify comme registre des commandes et du chiffre d'affaires. Gardez l'attribution des messages Klaviyo distincte du rapport push à 12 heures de l'app.