C'est lundi matin, et vous êtes le responsable de compte de trois clients Shopify Plus qui utilisent tous PushEngage. Vous avez un appel client dans une heure, et avant qu'il ne commence, vous avez besoin du taux de clics de la semaine dernière pour les envois d'abandon de panier de chaque site. Normalement, cela signifie trois connexions distinctes au tableau de bord PushEngage, trois exportations distinctes et trois remises à zéro mentales distinctes avant d'avoir dit un mot à qui que ce soit.
C'est ce que signifie gérer plusieurs comptes clients avec un seul assistant IA en pratique. Avec le serveur PushEngage MCP connecté à Claude, Cursor ou un autre assistant agentique, ce rituel du lundi matin se transforme en une seule conversation. Vous demandez le CTR de la semaine dernière pour le premier site, vous l'obtenez, vous demandez à nouveau pour le second, vous l'obtenez, vous demandez à nouveau pour le troisième, et vous entrez dans l'appel avec les trois chiffres avant que votre café ne soit froid.
Gérer plusieurs comptes clients avec un seul assistant IA semble simple jusqu'à ce que votre liste mélange deux situations différentes : les sites que vous gérez sous un seul identifiant PushEngage, et les clients qui ont chacun leur propre compte séparé. Traitez-les de la même manière et vous ne pourrez pas accéder aux données de la moitié de vos clients, ou pire, vous risquez qu'un jeton client touche le compte d'un autre client. C'est à quoi ressemble réellement PushEngage MCP pour les agences une fois que vous avez dépassé la démo : deux mécanismes distincts, pas un seul commutateur universel. Cet article couvre les deux, quand utiliser lequel, et comment les utiliser sans ouvrir un seul tableau de bord à la main.
Pour commencer : connecter PushEngage MCP à votre assistant IA
Si vous n'avez pas encore configuré le serveur PushEngage MCP, la version courte est une seule commande. Ajoutez npx -y @pushengage/mcp à la configuration MCP de votre client — le fichier claude_desktop_config.json de Claude Desktop, Claude Code, ou le fichier mcp.json de Cursor acceptent tous la même entrée — et redémarrez le client. Demandez à votre assistant de « me connecter à PushEngage », approuvez l'invite du navigateur qui s'ouvre, et votre assistant stocke un jeton d'accès localement ; votre mot de passe ne touche jamais le chat.
À partir de là, demandez « montre mes sites PushEngage » et « utilise le site [ID] » pour choisir celui sur lequel l'assistant agit. Tout ce qui suit suppose que cette configuration de base est déjà effectuée pour au moins un compte ; pour le guide complet, y compris le dépannage d'un client qui ne se connecte pas, consultez le guide de configuration PushEngage MCP.
Gérer plusieurs comptes clients avec un seul assistant IA signifie résoudre deux problèmes différents
Les agences qui utilisent PushEngage sur une liste de clients rencontrent l'une des deux situations, et elles ont besoin de solutions différentes.
Le changement de site est ce que vous avez lorsque plusieurs sites clients résident sous un seul identifiant PushEngage que vous gérez pour le compte des clients — une configuration courante pour les agences qui intègrent les clients directement dans un compte appartenant à l'agence. Un identifiant, un jeton, plusieurs sites auxquels l'assistant peut se référer.
La séparation de compte est ce que vous avez lorsque chaque client détient et paie son propre compte PushEngage, et se connecte indépendamment. Ici, il n'y a pas de connexion partagée pour basculer à l'intérieur — il y a plusieurs connexions séparées, chacune avec son propre jeton, et le travail consiste à les empêcher de se mélanger.
Une règle empirique détermine lequel s'applique : si vous changiez actuellement de sites dans un onglet de tableau de bord PushEngage, vous voulez le changement de site. Si vous deviez actuellement vous déconnecter du tableau de bord d'un client pour vous connecter à celui d'un autre, vous voulez la séparation de compte. Confondre les deux est l'erreur à éviter : traiter des comptes clients séparés comme s'ils étaient des sites sous une seule connexion est exactement le genre de mélange inter-comptes qui ne devrait jamais arriver avec les données clients.
| Changement de site | Séparation de compte | |
| Qui détient la connexion | Vous, pour le compte des clients | Chaque client, indépendamment |
| Ce qui change entre les clients | Le site sélectionné | L'intégralité de l'enregistrement du serveur MCP et du fichier de jetons |
| Outils impliqués | pushengage_list_sites, pushengage_select_site | PE_MCP_CONFIG_PATH séparé par nom de serveur |
| Mode d'échec si vous utilisez le mauvais | Vous n'atteignez jamais les données d'un client (si comptes réellement séparés) | Surcharge de ré-authentification inutile (si une seule connexion partagée) |
La plupart des agences gérant PushEngage pour une liste complète finissent par utiliser les deux à la fois : elles basculent entre les sites PushEngage au sein de la poignée de clients qui partagent une connexion gérée par l'agence, et enregistrent des comptes séparés pour les clients qui insistent pour détenir les leurs. Rien dans l'enregistrement de plusieurs comptes PushEngage ne vous empêche de changer également de site au sein de l'un d'eux une fois connecté.
Changement de site : extraction du CTR sur trois sites clients dans une seule conversation
Pour le cas multi-sites, deux outils vous permettent de basculer entre les sites PushEngage sans quitter la conversation : pushengage_list_sites et pushengage_select_site. Chaque outil limité au site (analyses, segments, paramètres de campagne) agit sur le site actuellement sélectionné, et la sélection persiste après les redémarrages, vous la définissez donc une fois par session et chaque question de suivi dans cette conversation s'applique au même site.
Retour au lundi matin. Avec une connexion établie, l'extraction du CTR pour trois sites clients ressemble à ceci dans une seule conversation :
- Demandez « liste mes sites PushEngage ». L'assistant renvoie le nom et l'ID de chaque site.
- Demandez d'utiliser l'ID du premier site, puis demandez le taux de clics de la semaine dernière. L'assistant appelle
pushengage_get_analytics_timeserieset renvoie les clics, les vues et le CTR par jour. - Demandez de basculer vers l'ID du deuxième site. Posez la même question. Répétez pour le troisième.
- Demandez un résumé comparant les trois. L'assistant a déjà extrait les trois ensembles de données en conversation et peut les comparer côte à côte.
Ce qui rend cela utile au lieu de trois exportations de tableaux de bord n’est pas seulement la vitesse. C’est que les chiffres que vous extrayez sont attribuables par site, pas seulement des ouvertures et des clics bruts. pushengage_get_analytics_summary et pushengage_get_analytics_timeseries renvoient les clics, les vues et la valeur des objectifs aux côtés du CTR, de sorte que le rapport que vous présentez lors de l’appel client indique les revenus récupérés par site, et non pas seulement des décomptes d’engagement que vous devriez traduire vous-même pour le client.
Ce cadrage est important car le CTR seul ne raconte qu’une partie de l’histoire. Une étude à l’échelle de l’industrie sur la segmentation et le taux de clics a révélé que le CTR évolue 2 fois plus ou plus en fonction de la précision avec laquelle les envois d’un client sont segmentés, de sorte que le même chiffre de CTR peut signifier des résultats de revenus très différents pour trois clients ayant une maturité de segmentation différente. Cette différence mérite d’être soulignée lors de l’appel, pas seulement rapportée.
Il s’agit d’un travail en lecture seule. Rien dans le passage d’un site PushEngage à l’autre de cette manière n’envoie, ne planifie ou ne modifie une campagne ; pushengage_list_sites et pushengage_select_site ne font que changer les données existantes du site lu par le reste de la conversation.
Séparation des comptes : enregistrement du serveur MCP sous un nom par client
Pour des comptes clients véritablement séparés, la solution réside dans la configuration MCP elle-même, et non dans un appel d’outil. Le serveur de PushEngage lit l’emplacement de son jeton à partir d’une variable d’environnement, PE_MCP_CONFIG_PATH, qui est par défaut ~/.pushengage/mcp.json si vous ne la définissez jamais. Enregistrez le serveur deux fois, une fois par client, chacun pointant vers son propre fichier, et les deux connexions ne partageront jamais de jeton :
{
"mcpServers": {
"pushengage-northwind": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-northwind.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Northwind)"
}
},
"pushengage-brightleaf": {
"command": "npx",
"args": ["-y", "@pushengage/mcp"],
"env": {
"PE_MCP_CONFIG_PATH": "/Users/you/.pushengage/mcp-brightleaf.json",
"PE_MCP_CLIENT_NAME": "Claude Desktop (Brightleaf)"
}
}
}
}(Northwind et Brightleaf sont des noms de clients illustratifs.) PE_MCP_CONFIG_PATH doit être un chemin absolu — il est utilisé tel quel, sans expansion de ~, alors vérifiez le chemin avant de redémarrer votre client. PE_MCP_CLIENT_NAME est facultatif et ne change que l’étiquette affichée par votre assistant sur l’écran d’autorisation de PushEngage ; il n’affecte pas l’isolement, mais il vaut la peine de le définir afin que vous puissiez savoir quel client vous avez autorisé lorsque l’onglet du navigateur s’ouvre.
Connectez-vous séparément à chaque nom de serveur : « connecte-moi à pushengage-northwind », puis, à une étape ultérieure, « connecte-moi à pushengage-brightleaf ». Chacun s’autorise auprès du compte PushEngage que vous choisissez dans cette session de navigateur spécifique. Deux noms de serveur, deux fichiers de configuration, deux jetons qui ne se touchent jamais. C’est le modèle pour exécuter plusieurs comptes PushEngage côte à côte, et il s’étend au-delà de deux : une agence avec une douzaine de comptes clients enregistre une douzaine d’entrées de serveur, chacune avec son propre PE_MCP_CONFIG_PATH, et aucun d’entre eux ne partage jamais de fichier. C’est aussi la partie que la plupart des guides concurrents sur l’« IA multi-clients » survolent avec des propos vagues sur l’isolement au lieu d’une configuration réelle à copier.
Exécution de la même invite de création de segment sur chaque compte client
Une fois vos clients enregistrés en tant que noms de serveur distincts, vous pouvez rejouer une requête sur tous sans jamais ouvrir de tableau de bord. Supposons que vous souhaitiez qu'un segment « visiteurs de /pricing » soit actif sur cinq comptes clients avant la fin de la journée. Demandez à votre assistant, à tour de rôle, de « créer un segment pour les visiteurs de /pricing » sur pushengage-northwind, puis sur pushengage-brightleaf, puis sur chaque nom de serveur client restant. Chaque requête appelle pushengage_create_segment sur le jeton de ce compte, et chaque client se retrouve avec le même segment de règles d'URL, construit sur sa propre base d'abonnés.
La raison pour laquelle la même invite se transfère proprement sur cinq comptes clients différents est qu'elle invoque un modèle de segmentation intégré à PushEngage, et non quelque chose que vous architectez à partir de zéro pour chaque client. pushengage_list_segments et pushengage_create_segment fonctionnent sur des règles d'URL et des critères comportementaux que la plateforme comprend déjà — récence, fréquence, schémas de visite de pages — les mêmes catégories qui font que l'approche du guide de segmentation e-commerce fonctionne comme un système plutôt que comme une liste unique. C'est ce qui permet à une seule invite de faire un travail de segmentation réel cinq fois au lieu de cinq constructions manuelles distinctes. Et comme la segmentation est désormais une exigence de délivrabilité plutôt qu'un avantage, la rejouer sur chaque compte client s'apparente davantage à une hygiène de compte standard qu'à un raccourci.
Empêcher l'accès d'un ancien membre de l'équipe au compte de chaque autre client
La séparation des comptes est utile le jour où quelqu'un quitte un compte. Étant donné que le jeton de chaque client réside dans son propre fichier de configuration, la suppression de l'accès d'une personne à un client n'affecte jamais le reste de votre liste.
Deux façons d'y mettre fin :
- Localement : déconnectez-vous de l'enregistrement du serveur de ce client uniquement — « déconnecte-moi de pushengage-northwind » appelle
pushengage_auth_logout, qui supprime le jeton de ce fichier de configuration unique et laisse intact le fichier de chaque autre client. - Côté serveur : si le membre de l'équipe partant a autorisé la session du navigateur lui-même, révoquez-la depuis PushEngage sous Paramètres → Sécurité sur le compte de ce client spécifique, ce qui invalide le jeton quel que soit l'endroit où il est stocké localement.
Comparez cela à ce qui se passe avec une seule connexion partagée entre les clients : révoquer l'accès signifie faire pivoter un jeton partagé, ce qui interrompt la connexion de chaque membre de l'équipe à chaque client en même temps. Garder chaque client sur son propre PE_MCP_CONFIG_PATH transforme une alerte générale en une correction en une seule ligne.
Ce que cela change pour la façon dont une agence tarife et dote en personnel le travail de push multi-clients
Rien de tout cela ne change ce que les notifications push font pour les chiffres de rétention d’un client. Le serveur MCP de PushEngage n’envoie, ne planifie ni ne crée de campagnes par lui-même ; chaque appel à pushengage_send_notification ou pushengage_send_ab_notification s’exécute toujours sur un seul site à la fois, avec votre approbation. Ce qui change, c’est le temps entre « le client veut connaître ses chiffres » et « le client a ses chiffres », et le temps est la seule ressource qu’un gestionnaire de compte ne peut pas acheter davantage en milieu de mois.
C’est la vraie valeur de la gestion de plusieurs comptes clients avec un seul assistant IA : pas une nouvelle capacité, mais du temps retrouvé. Cela compte à l’échelle à laquelle PushEngage fonctionne déjà — 25 000+ propriétaires d’entreprises dans plus de 150 pays ont envoyé 15,2 milliards de notifications via la plateforme au cours des 30 derniers jours seulement.
Une agence gérant une poignée de ces comptes ne demande pas à cette infrastructure de faire quelque chose de nouveau ; elle demande à atteindre le travail de reporting et de création d’audience qu’elle fait déjà, sans qu’une connexion au tableau de bord ne se place entre l’assistant et la réponse. Le gestionnaire de compte qui avait l’habitude de passer les lundis matins à exporter trois CSV passe maintenant ce temps à analyser ce que ces chiffres disent du taux d’achats répétés de chaque client. C’est la partie du travail qui n’a jamais été censée concerner les connexions en premier lieu.
Que votre liste nécessite de changer de site, de séparer les comptes, ou les deux, les mécanismes ci-dessus fonctionnent sur tous les plans PushEngage, au prix adapté à la croissance des abonnés actifs plutôt que par compte client, donc l’ajout du quatrième ou cinquième client à cette configuration ne signifie pas renégocier ce que vous payez pour les atteindre. C’est la forme réelle de PushEngage MCP pour les agences : pas un nouveau niveau de compte gestionnaire ajouté au-dessus, mais les mêmes deux mécanismes (une connexion avec plusieurs sites, ou plusieurs connexions qui ne se croisent jamais) appliqués au nombre de clients que vous gérez ce trimestre.
