Votre rapport d'attribution de canaux GA4 présente une lacune. Les envois de notifications push du mois dernier apparaissent sans médium ni source, donc sur le papier, ils ressemblent à du trafic direct au lieu de revenus récupérés. Vous remontez à un paramètre UTM qui n'a jamais été rempli au-delà de l'espace réservé défini par votre équipe lors de l'installation. Ce guide de configuration des paramètres du site pushengage existe car la correction de ce champ unique aujourd'hui signifie se connecter au tableau de bord, trouver le bon onglet et ressaisir tous les autres champs par défaut en une seule fois, car le formulaire ne vous permet pas de modifier un seul champ.
C'est le coût réel des paramètres du site PushEngage : non pas qu'un seul paramètre soit difficile à comprendre, mais que les détails du site, les valeurs par défaut des campagnes et la configuration du service worker se trouvent dans des endroits séparés, sont rarement modifiés au point que personne ne se souvienne où, et nécessitent une ressaisie complète du formulaire pour corriger un champ. Ce guide couvre les trois groupes de paramètres que vous réviserez réellement — les détails du site, les valeurs par défaut des campagnes et les paramètres du service worker — et comment modifier l'un d'entre eux avec une requête en langage naturel à un assistant IA connecté au serveur PushEngage MCP, au lieu d'une chasse aux onglets du tableau de bord.
Pourquoi la configuration des paramètres du site PushEngage se transforme en ticket de support au lieu d'une correction en cinq minutes
Les paramètres du site ne sont pas configurés une fois pour toutes et oubliés. Ils sont révisés chaque fois que l'entreprise change de forme : un nouveau marché signifie un changement de fuseau horaire, une nouvelle exigence d'attribution signifie une mise à jour du paramètre UTM, un relooking signifie que le commutateur « Propulsé par PushEngage » nécessite un nouvel examen, une migration de plateforme signifie vérifier si le fichier du service worker se trouve toujours là où PushEngage s'attend à le trouver. Étant donné que chacun de ces éléments se trouve dans un coin différent du tableau de bord, le véritable obstacle n'est pas la modification elle-même. Il s'agit de retrouver l'onglet, puis de ressaisir les champs que vous n'aviez pas l'intention de toucher, pour une tâche que vous effectuerez à nouveau dans trois mois lorsque quelque chose d'autre changera.
Trois modes d'échec apparaissent suffisamment souvent pour être importants, et aucun d'entre eux ne génère d'erreur lorsqu'ils se produisent :
- Un écart dans les valeurs par défaut UTM. Les valeurs par défaut des campagnes sont livrées avec des paramètres UTM de substitution ou vides, de sorte que chaque envoi de notification push dans cette fenêtre apparaît dans GA4 sans médium ni source, invisible dans un rapport d'attribution de canaux.
- Une notification de secours manquante. Les abonnés non segmentés, ceux qui ne correspondent à aucune règle d'audience, ne reçoivent rien, ou une copie générique, au lieu d'une valeur par défaut délibérée choisie par votre équipe.
- Un chemin de service worker obsolète après une migration de site. Cela empêche la livraison des notifications, sans produire de message d'erreur évident renvoyant au paramètre qui l'a causé.
Ces trois problèmes coûtent silencieusement des données, de la portée ou de la livraison jusqu'à ce que quelqu'un s'en aperçoive, généralement en consultant un rapport qui n'est pas cohérent.
C'est le cas pour traiter les paramètres du site comme une vérification récurrente plutôt qu'une étape d'installation unique, et c'est le cas pour changer la façon dont vous les vérifiez.
Démarrage : connectez le serveur PushEngage MCP à votre assistant
@pushengage/mcp est le serveur officiel du protocole de contexte de modèle (MCP) de PushEngage, et tous les outils de ce guide passent par lui. Ajoutez-le à la configuration MCP de votre client — claude_desktop_config.json de Claude Desktop, ~/.cursor/mcp.json de Cursor, ou la propre configuration MCP de Claude Code — avec la commande npx -y @pushengage/mcp. Aucune installation globale n'est requise.
La première fois que vous demandez à votre assistant de vous connecter, il ouvre un onglet de navigateur pour autoriser la connexion. Ainsi, votre mot de passe PushEngage ne touche jamais l'assistant lui-même, et le jeton résultant est stocké localement sur votre machine. À partir de là, demandez à voir vos sites PushEngage et sélectionnez celui sur lequel vous souhaitez travailler ; tous les outils de configuration ci-dessous utilisent par défaut le site que vous avez actuellement sélectionné. Pour la procédure complète, y compris le dépannage des problèmes de connexion, consultez le guide complet de configuration de PushEngage MCP.
Détails du site : nom, URL, fuseau horaire, géolocalisation et bascule de marque
pushengage_get_site_details lit votre configuration actuelle ; pushengage_update_site_details la modifie. Entre les deux, ils couvrent les champs que la documentation d'intégration de PushEngage appelle « Ajouter les détails du site » :
- Nom du site
- URL du site
- Fuseau horaire
- Suivi de la géolocalisation
- La bascule de marque « Propulsé par PushEngage » sur votre widget de tableau de bord
Si vous avez déjà eu besoin de corriger l'un de ces détails de site pushengage après l'installation initiale, c'est la paire d'outils qui atteint les cinq champs, et c'est la même paire d'outils pour les lire avant de supposer qu'il y a une mauvaise configuration.
Le fuseau horaire est plus important qu'il n'y paraît. C'est le point de référence pour chaque envoi programmé et chaque élément de planification basée sur le fuseau horaire de l'abonné que vous exécutez. Si vous vous trompez, un envoi à 9h atterrit à 2h pour une partie de votre liste, ce qui est interprété comme un échec de ciblage alors que la cause réelle est un champ mal configuré.
La géolocalisation est désactivée par défaut et doit être explicitement activée avant que PushEngage ne puisse attacher des données de ville, d'état et de pays à un enregistrement d'abonné, ce qui est le fondement sur lequel repose le ciblage par géolocalisation. Si vos segments font référence à l'emplacement et que les chiffres semblent faibles, cela vaut la peine de vérifier avant de supposer que votre base d'abonnés n'a pas la répartition géographique que vous attendiez.
La bascule de marque est plus simple : elle contrôle si « Propulsé par PushEngage » s'affiche ou non sur votre widget de tableau de bord, ce qui est le plus important pour les équipes qui gèrent une expérience de support ou de chat en marque blanche où chaque marque de fournisseur visible est examinée.
Aucun de ces éléments ne nécessite un ticket de support ou une recherche dans des menus de paramètres imbriqués. L'exemple du README lui-même est le modèle à suivre : demandez à votre assistant, « Changez le fuseau horaire de mon site en Asia/Kolkata et activez la géolocalisation », et les deux champs sont mis à jour en une seule requête. La correction de l'URL de votre site après un changement de domaine, ou de votre nom de site après un rebrand, suit le même schéma.
Paramètres par défaut de la campagne : les paramètres qui contrôlent silencieusement l'attribution et la portée de chaque envoi
pushengage_get_campaign_defaults et pushengage_update_campaign_defaults couvrent quatre champs. Ces paramètres par défaut de campagne PushEngage ne sont pas cosmétiques. Ce sont les paramètres qui se trouvent sous chaque envoi que vous effectuez, que quelqu'un de l'équipe se souvienne ou non de leur existence, et se tromper sur l'un d'eux ne se manifeste pas assez clairement pour que quiconque le remarque immédiatement.
- Paramètres UTM : votre référence pour suivre les notifications push avec les paramètres UTM dans GA4 ou toute pile d'analyse en aval. Ignorez ce paramètre et chaque envoi hérite d'une attribution vide : envois sans source ni support, revenus non attribuables, une lacune que personne ne remarque jusqu'à ce qu'un rapport mensuel ne corresponde pas. C'est le rapport d'attribution de canal qui a ouvert cet article.
- Notification de secours : ce qui s'affiche pour un abonné qui ne correspond à aucune règle d'audience. Laissez-la non définie et ces abonnés ne recevront rien du tout.
- Attributs de secours : jetons de personnalisation pour ce même groupe non segmenté, afin que leur copie soit intentionnelle plutôt que cassée ou générique. Un abonné sans attribut correspondant ne devrait pas voir un espace vide là où son prénom était censé aller.
- Expiration par défaut de la notification : combien de temps un envoi non délivré reste en file d'attente avant que PushEngage ne l'annule. Un envoi de vente flash avec une expiration de 7 jours peut toujours arriver des jours après la fin de la vente, induisant un abonné en erreur au lieu de simplement échouer silencieusement, ce qui est pire pour la relation que l'envoi n'arrivant jamais.
Définir une expiration par défaut de 7 jours est une requête unique : « Définissez mon expiration de notification par défaut à 7 jours », directement à partir de l'exemple du README. Le même schéma couvre une notification de secours pour les abonnés non correspondants, les attributs de secours pour la personnalisation de ce groupe, ou un passage complet des paramètres UTM afin que chaque envoi attribue correctement à GA4 à l'avenir. Examiner vos paramètres par défaut de campagne PushEngage actuels avant une grande fenêtre d'envoi, plutôt qu'après qu'une lacune de reporting soit apparue, est la version de cette habitude qui vaut la peine d'être développée.
Paramètres du service worker : enregistrement, prise en charge des sous-dossiers et chemin du fichier worker
pushengage_get_service_worker_settings et pushengage_update_service_worker_settings couvrent l’enregistrement, la prise en charge des sous-dossiers et le chemin du fichier worker : les mécanismes qui permettent aux notifications push d’atteindre un navigateur en premier lieu. Une erreur dans l’un des trois et le mode d’échec est le même. Les notifications cessent silencieusement d’être délivrées, sans erreur évidente renvoyant au paramètre qui l’a causé, et le premier symptôme que quiconque remarque est une baisse des chiffres d’envoi sans cause claire.
La prise en charge des sous-dossiers est celle qui pose problème aux sites ayant des contraintes de plateforme qui n’autorisent pas un fichier worker au niveau racine : un CMS, une installation dans un sous-répertoire, une configuration multi-sites partageant un seul domaine. Si votre fichier worker se trouve ailleurs qu’à la racine, le paramètre de chemin doit correspondre exactement à cet emplacement, répertoire et nom de fichier inclus, sinon l’enregistrement échoue silencieusement.
C’est la première chose à vérifier après une migration de site ou un changement de plateforme : demandez à votre assistant de récupérer vos paramètres actuels de service worker pushengage et confirmez que le chemin enregistré correspond toujours à l’endroit où le fichier se trouve réellement, le même type de vérification que la configuration du service worker de PushEngage pour les configurations contraintes par la plateforme vise à résoudre.
L’enregistrement lui-même mérite également un coup d’œil périodique, en particulier après tout changement dans la façon dont votre site charge les scripts. Une mise à jour de la politique de sécurité du contenu, un nouveau conteneur de gestionnaire de balises ou une couche de mise en cache qui supprime les en-têtes peuvent chacun interférer avec l’enregistrement de manière à n’apparaître nulle part ailleurs qu’une baisse silencieuse des notifications délivrées. Récupérer vos paramètres de service worker pushengage parallèlement à une vérification du taux de livraison est une habitude de cinq minutes qui permet de détecter le problème avant qu’il ne vous coûte un cycle de reporting complet.
Modifications partielles sans tout retaper : pourquoi le comportement de fusion est important
Voici le détail qui rend la demande à un assistant IA plus rapide que le tableau de bord, pas seulement différente : pushengage_update_campaign_defaults fusionne votre modification sur les valeurs actuelles au lieu de remplacer l’intégralité de l’enregistrement. Demandez de changer uniquement l’expiration par défaut de la notification, et vos paramètres UTM, votre notification de secours et vos attributs de secours restent exactement comme ils étaient. Vous n’avez pas à spécifier à nouveau les champs que vous n’avez aucune intention de modifier.
Comparez cela à un formulaire de paramètres typique, où la modification d’un champ dans un bloc enregistré signifie souvent que l’ensemble du formulaire se recharge avec chaque champ modifiable, et une erreur sur un champ non lié écrase silencieusement quelque chose qui fonctionnait correctement. « Définir mon expiration de notification par défaut à 7 jours » modifie exactement une chose et laisse le reste de vos paramètres de campagne par défaut inchangés. C’est la différence entre une modification ciblée et une ré-enregistrement complet chaque fois qu’un seul paramètre nécessite un ajustement, et c’est la différence qui transforme une révision mensuelle des paramètres d’une corvée de quinze minutes en la demande d’une phrase qu’elle aurait dû être depuis le début.
Ce que des paramètres précis protègent réellement : la délivrabilité et l’attribution, pas seulement la propreté
Rien de tout cela ne concerne vraiment la propreté. Un fuseau horaire incorrect perturbe le calendrier d’envoi programmé pour une partie de votre liste. Un défaut d’UTM manquant brise l’attribution pour chaque envoi jusqu’à ce que quelqu’un le remarque. Un service worker mal enregistré brise la livraison pure et simple, et ce, silencieusement. Chacun de ces paramètres se trouve sous chaque campagne que votre équipe exécute. La campagne ne échoue pas bruyamment ; le reporting au-dessus cesse simplement de correspondre à la réalité.
C’est le cas réel pour traiter les détails du site, les défauts de campagne et la configuration du service worker comme des paramètres de notification push de l’assistant IA que vous vérifiez régulièrement, de la même manière que vous vérifieriez un tableau de bord de taux de livraison, plutôt qu’une étape de configuration unique que vous configurez une fois et ne revisitez jamais. Présenter ces éléments comme des paramètres de notification push de l’assistant IA plutôt qu’un onglet de tableau de bord enfoui signifie que la vérification elle-même prend autant de temps qu’il en faut pour taper la requête. Capturer un défaut UTM cassé ou un chemin de worker obsolète dans une seule requête protège les mêmes revenus récupérés dont dépend votre reporting de rétention, sans attendre un ticket informatique ou un appel de réintégration pour corriger quelque chose qui prend une phrase à dire à voix haute.
Une fois votre serveur MCP PushEngage connecté, parcourez les trois groupes de paramètres couverts dans ce guide de configuration des paramètres du site PushEngage de la même manière que vous exécuteriez tout autre audit de rétention : rapidement, et selon votre propre calendrier, au lieu de seulement lorsqu’un rapport n’est pas concluant. Cela fonctionne pour tous les plans PushEngage, y compris le niveau gratuit, il n’y a donc pas de barrière entre la connexion du serveur MCP et son utilisation réelle pour vérifier vos détails de site PushEngage, vos défauts de campagne et vos paramètres de service worker avant qu’ils ne vous coûtent en attribution ou en portée.
