Comment augmenter le nombre d'impressions Web Push

« L'envoi est parti, mais les impressions sont très en dessous des attentes » est l'une des questions les plus fréquentes des intégrateurs Web Push. Les impressions ne sont pas un indicateur isolé : elles résultent des pertes accumulées aux étapes d'abonnement, d'envoi, de livraison et autres. Cet article vous aide à localiser, couche par couche le long de l'entonnoir, la cause d'un faible nombre d'impressions, propose des mesures d'optimisation pour chaque type de cause et se termine par une approche globale et durable.

Aligner d'abord les définitions : où se situent les impressions dans l'entonnoir

EngageLab comptabilise chaque envoi selon les étapes suivantes. Les définitions de chaque étape figurent dans Statistiques d'envoi et dans l'API de statistiques :

flowchart LR
    plan["Cibles planifiées"]
    targets["Cibles valides<br/>appareils actifs au cours des 365 derniers jours"]
    sent["Envoyés<br/>tâche d'envoi créée par le serveur"]
    delivered["Livrés<br/>réellement livrés au client Web"]
    impressions["Impressions<br/>affichés avec succès sur l'appareil"]
    clicks["Clics"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

Trois points concernant les « impressions » doivent être clarifiés d'emblée, sous peine de confondre un problème de définition statistique avec un problème d'envoi :

1. Les impressions sont remontées par le SDK. Dans l'API de callback, le statut Impression est défini comme « notifications Web Push et messages in-app dont l'affichage réussi est remonté par le SDK » ; voir l'API de callback. Les affichages non remontés via le SDK ne sont pas comptés comme impressions.
2. Les messages personnalisés ne sont pas comptés comme impressions par défaut. Le message (message personnalisé) de l'API de création d'envoi n'est pas affiché dans le navigateur mais transmis tel quel à votre page web ; pour comptabiliser des impressions, vous devez appeler customDisplayReport depuis votre page. Voir l'API du Web SDK.
3. La fenêtre statistique est de 5 jours. Les livraisons et impressions survenant plus de 5 jours après un envoi réussi ne sont ni comptabilisées ni remontées par callback.

Ainsi, lors de l'analyse d'un faible nombre d'impressions, distinguez d'abord « taux d'impression faible » (livré mais non affiché) et « nombre d'impressions faible avec un taux d'impression normal » (le problème se situe en amont : abonnement, envoi ou livraison). Les causes et les solutions de ces deux cas sont totalement différentes.

Partie 1 : Comment rechercher la cause d'un faible nombre d'impressions

Parcourez l'entonnoir de l'amont vers l'aval, en examinant les données de chaque couche avant d'en localiser la cause.

1.1 La base d'abonnés est-elle suffisante ?

Le plafond des impressions est fixé par la taille de votre base d'abonnés. Si les abonnés sont peu nombreux, même d'excellents taux de livraison et d'impression ne produiront pas un volume d'impressions significatif.

Où regarder :

• Aperçu des utilisateurs : comparez « utilisateurs abonnés » et « utilisateurs actifs ». Les utilisateurs abonnés correspondent au nombre d'appareils utilisateurs uniques ayant souscrit et accepté de recevoir des notifications. S'ils sont très inférieurs aux utilisateurs actifs, de nombreux visiteurs n'ont pas terminé l'autorisation.
• Vue d'ensemble : consultez le taux d'activation de l'autorisation de notification sur les appareils et le nombre d'utilisateurs ayant désactivé les notifications.
• Requête de données : vérifiez par sondage l'état en ligne et la dernière connexion de Registration ID précis pour confirmer que l'abonnement est toujours valide.

Causes fréquentes (voir la FAQ et les Paramètres de base) :

• Le mode « demande directe » affiche l'invite d'autorisation native du navigateur. Dès que l'utilisateur clique sur Block / Don't Allow, l'autorisation ne peut plus être redemandée, sauf si l'utilisateur modifie lui-même les paramètres du navigateur.
• Le site n'utilise pas HTTPS ou le domaine n'est pas configuré dans la console : l'invite native ne peut pas s'afficher et l'abonnement est impossible.
• Le Service Worker n'est pas placé à la racine du site, ou sa portée entre en conflit avec un Service Worker PWA existant, ce qui fait échouer l'abonnement.
• Les utilisateurs iOS n'ont pas ajouté le site à l'écran d'accueil, ou la demande d'autorisation n'est pas déclenchée par un geste utilisateur.
• Les utilisateurs naviguent en mode navigation privée, incognito ou invité, qui ne prennent pas en charge Web Push.
• Lorsqu'un même user_str s'abonne sur plusieurs navigateurs ou appareils, le nouvel abonnement remplace l'ancien et seul le dernier appareil abonné reçoit les messages.

1.2 Y a-t-il de fortes pertes entre cibles valides et envoyés ?

Où regarder :

• Historique des envois : comparez cibles valides et envoyés pour un envoi donné, et consultez les motifs d'échec dans les détails du message.
• La requête de cycle de vie de l'API de statistiques : les statuts target_invalid et sent_failed localisent l'étape de perte pour des appareils précis.

Causes fréquentes :

• Les cibles valides sont définies comme « actives au cours des 365 derniers jours » ; les abonnements inactifs depuis longtemps ne deviennent pas des cibles valides.
• Des limites d'envoi par appareil par heure / jour / semaine ou une plage horaire d'envoi autorisée sont configurées dans les Paramètres avancés ; les messages dépassant la limite ou hors plage sont directement rejetés.

1.3 Y a-t-il de fortes pertes entre envoyés et livrés ?

C'est la couche la plus souvent confondue avec « impressions faibles ». Si les livrés sont faibles, les impressions le seront aussi, mais le taux d'impression peut être parfaitement normal.

Où regarder :

• Le taux de livraison d'un envoi donné dans l'historique des envois ; les données de livraison ventilées par navigateur (Chrome, Safari, Firefox, Edge, canal EngageLab, etc.) dans les statistiques d'envoi.
• Le champ sub renvoyé par l'API de statistiques présente séparément livrés et impressions pour notification et message ; les champs engageLab_web, chrome, safari, firefox et edge permettent la ventilation par canal.

Causes fréquentes (voir l'API de création d'envoi et la FAQ) :

• time_to_live est à 0 : les messages hors ligne ne sont pas conservés, seuls les utilisateurs en ligne à cet instant les reçoivent. La valeur par défaut est 86400 secondes (1 jour), le maximum 15 jours.
• Différences entre canaux : le canal EngageLab exige que l'utilisateur ait ouvert la page de votre site ; les canaux système (Chrome, Edge, Firefox, etc.) livrent tant que le processus du navigateur existe dans le système d'exploitation, mais plus une fois le navigateur totalement fermé ; le canal système Safari n'exige pas que le navigateur soit en cours d'exécution.
• L'utilisateur a effacé les cookies / le cache du navigateur, et l'abonnement au canal du fournisseur a été perdu avec. Si l'autorisation de notification reste sur « autoriser », le SDK se réabonne automatiquement au retour de l'utilisateur sur le site et un nouveau Registration ID est émis ; si l'autorisation est passée à « demander » ou « bloquer », il n'y a pas de réabonnement automatique.
• La stratégie third_party_channel.w3push.distribution ne correspond pas au comportement de vos utilisateurs, par exemple forcer mtpush (canal EngageLab uniquement) alors que les utilisateurs restent rarement sur le site.
• Le canal du fournisseur de navigateur est instable ; la FAQ recommande alors de basculer vers une livraison prioritaire par le canal EngageLab.

1.4 Y a-t-il des pertes entre livrés et impressions (taux d'impression faible) ?

Ce n'est que lorsque les livrés sont normaux et les impressions nettement faibles qu'il s'agit d'un véritable problème de « taux d'impression ».

Où regarder :

• « Livrés / Impressions » et leur ratio par plateforme dans les détails de l'historique des envois.
• Les événements Impression et impression_failed de l'API de callback.

Causes fréquentes :

1.5 Liste de contrôle

Suivez les points dans l'ordre ci-dessous, en écartant d'abord les problèmes de définition et d'amont avant d'examiner les impressions elles-mêmes :

Partie 2 : Comment optimiser une fois la cause identifiée

2.1 Élargir la base d'abonnés

• Passez à la demande guidée (pré-invite). Dans l'autorisation de notification des Paramètres de base, choisissez « demande guidée » : expliquez d'abord la valeur des notifications avec une invite personnalisée et ne déclenchez l'invite native qu'une fois l'intention de l'utilisateur manifestée. Vous évitez ainsi qu'il clique sur Block sans en comprendre la valeur, ce qui rendrait l'autorisation définitivement indisponible. La pré-invite permet de configurer l'intervalle initial (3 jours par défaut) et l'intervalle suivant (7 jours par défaut) jusqu'à l'abonnement de l'utilisateur.
• Assurez-vous que les prérequis sont complets. Utilisez HTTPS et configurez vos domaines dans [Paramètres d'intégration] - [Domaine du site] (jusqu'à 100). Placez le fichier du Service Worker à la racine du site pour une portée maximale. Si le site possède déjà un Service Worker PWA, fusionnez les deux ou assurez-vous que leurs portées ne se chevauchent pas ; voir le Guide d'intégration du Web SDK et la FAQ.
• Guidez les utilisateurs iOS. Safari sur iOS / iPadOS 16.4 et versions ultérieures exige que l'utilisateur ajoute le site à l'écran d'accueil et l'ouvre depuis celui-ci, puis que l'autorisation soit déclenchée par un geste utilisateur (par exemple un appui sur un bouton d'abonnement). Une bannière d'orientation sur la page est recommandée.
• Évitez que les appareils ne s'évincent mutuellement. Si vous identifiez les utilisateurs par user_str, notez que lorsqu'un même user_str s'abonne sur plusieurs navigateurs / appareils, seul le dernier appareil abonné reçoit les messages. Pour couvrir tous les appareils d'un utilisateur, ne réutilisez pas le même user_str sur des appareils différents.
• Ne perdez pas d'abonnements lors de la migration. Lors d'une migration depuis un autre fournisseur vers EngageLab, traitez l'ancien Service Worker comme décrit dans Comment éviter la perte d'abonnés lors d'une migration Web Push ; les utilisateurs ayant déjà accordé l'autorisation ne verront pas l'invite réapparaître après l'initialisation.

2.2 Réduire les pertes entre cibles valides et envoyés

• Configurez dans les Paramètres avancés les limites d'envoi par appareil et la plage horaire autorisée selon vos besoins métier. Le contrôle de fréquence protège l'expérience utilisateur, mais un réglage trop strict rejette directement des messages ; évaluez-le avec votre plan d'envoi.
• Utilisez périodiquement l'API de suppression d'utilisateur pour nettoyer les abonnements confirmés inactifs, afin que les cibles valides reflètent plus fidèlement les utilisateurs joignables et que les statistiques ne soient pas diluées par des abonnements invalides. La suppression est irréversible ; procédez avec prudence.

2.3 Améliorer la livraison

• Réglez time_to_live correctement. N'utilisez pas 0 ; conservez la valeur par défaut de 1 jour ou prolongez-la selon la durée de pertinence du contenu, jusqu'à 15 jours. Pour les contenus peu urgents, une conservation hors ligne plus longue permet aux utilisateurs hors ligne de les recevoir encore à la réouverture du navigateur.

• Choisissez une stratégie de distribution adaptée. Dans third_party_channel.w3push.distribution :

  • first_ospush (par défaut) : canal système en priorité, puis canal EngageLab s'il est indisponible ;
  • secondary_push : canal EngageLab en priorité, puis canal système si l'utilisateur est hors ligne ; l'API de création d'envoi recommande cette option ;
  • mtpush : force le canal EngageLab ; adapté uniquement lorsque les utilisateurs restent longtemps sur le site ;
  • ospush : force le canal système uniquement.

  Lorsque le canal du fournisseur de navigateur est instable, vous pouvez basculer temporairement vers la priorité au canal EngageLab.

• Utilisez override_msg_id avec précaution. Remplacer une notification précédente non effacée fait que l'utilisateur ne voit que la plus récente ; cela convient aux mises à jour de contenu, pas aux cas où vous souhaitez que plusieurs notifications restent visibles.

• Utilisez l'envoi à débit contrôlé pour les campagnes ou les gros volumes. Avec big_push_duration, répartissez l'envoi uniformément sur le nombre de minutes indiqué (1440 au maximum) pour éviter les pics instantanés.

2.4 Améliorer les impressions

• Privilégiez les notifications. Pour le contenu qui doit s'afficher dans la zone de notification et être compté comme impression, utilisez notification plutôt que message. Si votre activité exige réellement des messages personnalisés, appelez customDisplayReport('msg_id') après leur affichage sur la page et customClickReport('msg_id') au clic.
• Évitez d'envoyer plusieurs notifications d'affilée au même utilisateur en peu de temps. Sur Chrome, Edge et Firefox, la notification suivante remplace la précédente : l'utilisateur ne voit que la dernière et une seule impression est comptée. Regroupez plusieurs contenus en une seule notification ou espacez les envois.
• Tenez compte de la compatibilité des visuels et des textes avec les navigateurs. L'icon doit faire 192×192 et ne pas dépasser 1 Mo ; les icônes personnalisées ne sont prises en charge que par Chrome et Firefox, Safari et Edge utilisant l'icône système par défaut. L'image doit faire 360×180 et ne pas dépasser 1 Mo ; elle n'est prise en charge que par Chrome et Edge, pas par Firefox ni Safari. Les canaux système limitent la longueur du titre (moins de 20 caractères chinois ou 40 caractères anglais) ; un titre trop long peut nuire à l'affichage.
• Définissez une période de validité d'affichage raisonnable pour les messages in-app. Une fois dépassée, le message ne s'affiche pas au retour de l'utilisateur sur la page et impression_failed est déclenché. Allongez la validité pour les contenus peu urgents et limitez la taille des images pour éviter les échecs de téléchargement.
• Envoyez pendant les heures d'activité des utilisateurs. Utilisez la livraison intelligente des Tâches planifiées ou les données de correspondance des heures actives des statistiques d'envoi pour envoyer lorsque les utilisateurs ont le plus de chances d'avoir le navigateur ouvert, et réduire ainsi les expirations hors ligne.
• Interprétez correctement les données Safari. Le canal système Safari ne peut renvoyer ni callback d'impression ni de clic ; de faibles impressions sur ce canal traduisent une limite statistique et non une absence d'affichage. Évaluez Safari séparément des autres canaux lorsque vous analysez le taux d'impression.

Partie 3 : Approche globale pour augmenter durablement les impressions

Les correctifs ponctuels ne résolvent qu'une couche à la fois. Pour augmenter durablement les impressions, gérez « croissance des abonnés, garantie de livraison et suivi des impressions » comme une routine opérationnelle continue.

3.1 Construire une vue de suivi par canal

• Consultez chaque jour, dans la Vue d'ensemble, l'entonnoir de conversion des envois, les tendances des taux de livraison / d'impression / de clics et le nombre d'utilisateurs ayant activé / désactivé les notifications.
• Ventilez livrés et impressions par navigateur dans les Statistiques d'envoi, en vous concentrant sur Chrome et le canal EngageLab ; évaluez Safari séparément.
• Recevez les événements delivered, Impression, impression_failed, click et autres via l'API de callback et stockez-les pour une analyse par utilisateur et par message plus fine que celle de la console (les statistiques par message sont conservées côté EngageLab un mois au maximum).
• Définissez des références distinctes pour le taux de livraison et le taux d'impression : en cas de baisse anormale du taux de livraison, vérifiez d'abord time_to_live, la stratégie de distribution et les canaux fournisseurs ; en cas de baisse anormale du taux d'impression, vérifiez d'abord le type de message, le remplacement par notifications multiples et les autorisations côté utilisateur.

3.2 Plan d'action par phase

Phase d'intégration (autour du lancement)

• Utiliser HTTPS, configurer les domaines, placer le Service Worker à la racine et vérifier l'absence de conflit de portée ;
• Choisir « demande guidée » pour l'autorisation de notification et configurer le texte et les intervalles de la pré-invite ;
• Préparer un guide « ajouter à l'écran d'accueil » pour les utilisateurs iOS ;
• Utiliser les notifications (notification) plutôt que les messages personnalisés (message) comme principal moyen de contact ;
• Lors des tests d'intégration, vérifier via l'historique des envois et la requête de données que l'état en ligne, la livraison et les impressions des appareils cibles sont correctement comptabilisés.

Phase de croissance (exploitation quotidienne)

• Comparer chaque semaine la croissance des abonnés et des actifs ; si la conversion à l'abonnement est faible, ajuster le texte et le moment de déclenchement de la pré-invite ;
• Maintenir time_to_live à 1 jour ou plus et utiliser secondary_push ou la stratégie par défaut pour distribution ;
• Maîtriser la fréquence d'envoi vers un même utilisateur pour éviter les pertes d'impressions par remplacement, tout en configurant le contrôle de fréquence pour protéger l'expérience ;
• Choisir les créneaux d'envoi grâce à la livraison intelligente ou aux données de correspondance des heures actives ;
• Nettoyer périodiquement les abonnements inactifs depuis longtemps.

Phase de campagne (envois de pointe)

• Utiliser l'envoi à débit contrôlé pour lisser les pics ;
• Raccourcir time_to_live pour les contenus urgents et allonger la conservation hors ligne pour ceux qui peuvent être livrés plus tard ;
• Regrouper plusieurs notifications marketing en une seule, ou envoyer par lots décalés selon les segments d'utilisateurs ;
• Après l'envoi, analyser les taux de livraison et d'impression par canal et réinjecter les enseignements des canaux anormaux dans la configuration du prochain envoi.

3.3 En une phrase

Impressions = utilisateurs abonnés × proportion de cibles valides × taux de livraison × taux d'impression. Utilisez les données de l'entonnoir pour déterminer la couche où se produit la perte, puis optimisez cette couche. Pour la couche « impression » elle-même, l'essentiel est d'utiliser les notifications et de garantir la remontée par le SDK, d'éviter le remplacement par notifications multiples et d'interpréter les données par canal.

Documents de référence

• Guide d'intégration du Web SDK
• API du Web SDK
• Paramètres de base
• Paramètres avancés
• API de création d'envoi
• API de callback
• API de statistiques
• Statistiques d'envoi
• Historique des envois
• FAQ
• Comment éviter la perte d'abonnés lors d'une migration Web Push