Det er mandag morgen, og du er kontoadministrator for tre Shopify Plus-klienter, der alle kører via PushEngage. Du har et klientopkald om en time, og før det starter, skal du bruge sidste uges klikrate for hver sides afsendelser af forladte indkøbskurve. Normalt betyder det tre separate PushEngage-dashboard-logins, tre separate eksportfiler og tre separate mentale nulstillinger, før du har sagt et ord til nogen.
Dette er, hvordan håndtering af flere klientkonti med én AI-assistent ser ud i praksis. Med PushEngage MCP-serveren forbundet til Claude, Cursor eller en anden agent-assistent, bliver det mandag morgen-ritual til én samtale. Du beder om sidste uges CTR på det første websted, får den, beder igen om det andet, får den, beder igen om det tredje, og du går ind til opkaldet med alle tre tal, før din kaffe er kold.
Håndtering af flere klientkonti med én AI-assistent lyder simpelt, indtil din liste blander to forskellige situationer: websteder, du administrerer under ét PushEngage-login, og klienter, der hver især har deres egen separate konto. Behandler du dem på samme måde, kan du enten ikke få adgang til halvdelen af dine klienters data, eller værre, du risikerer, at én klients token rører en anden klients konto. Dette er, hvordan PushEngage MCP for bureauer faktisk ser ud, når du kommer forbi demoen: to distinkte mekanismer, ikke én universel switch. Dette indlæg dækker begge, hvornår du skal bruge hvilken, og hvordan du bruger dem uden at åbne et enkelt dashboard manuelt.
Kom godt i gang: Tilslutning af PushEngage MCP til din AI-assistent
Hvis du endnu ikke har konfigureret PushEngage MCP-serveren, er den korte version én kommando. Tilføj npx -y @pushengage/mcp til din klients MCP-konfiguration — Claude Desktops claude_desktop_config.json, Claude Code eller Cursors mcp.json accepterer alle den samme post — og genstart klienten. Bed din assistent om at "logge mig ind på PushEngage", godkend browserprompten, der åbnes, og din assistent gemmer en adgangstoken lokalt; dit kodeord rører aldrig chatten.
Derfra kan du bede "vis mine PushEngage-websteder" og "brug websted [ID]" for at vælge, hvilket websted assistenten skal handle på. Alt nedenfor antager, at denne grundlæggende opsætning allerede er udført for mindst én konto; for den fulde gennemgang, inklusive fejlfinding af en klient, der ikke kan oprette forbindelse, se PushEngage MCP-opsætningsguiden.
Håndtering af flere klientkonti med én AI-assistent betyder at løse to forskellige problemer
Bureauer, der kører PushEngage på tværs af en klientliste, støder på en af to situationer, og de har brug for forskellige løsninger.
Webstedsskift er, hvad du har, når flere klientwebsteder lever under ét PushEngage-login, som du administrerer på klienternes vegne — en almindelig opsætning for bureauer, der onboarder klienter direkte i en agenturejet konto. Ét login, én token, flere websteder at pege assistenten på.
Kontoopdeling er, hvad du har, når hver klient har og betaler for deres egen PushEngage-konto og logger ind uafhængigt. Her er der ingen delt login at skifte imellem – der er flere separate logins, hver med sit eget token, og opgaven er at forhindre dem i nogensinde at blande sig.
En tommelfingerregel afgør, hvilken der gælder: hvis du i øjeblikket ville skifte sider inde i en PushEngage dashboard-fane, vil du have side-skift. Hvis du i øjeblikket skulle logge ud af én kundes dashboard for at logge ind på en andens, vil du have kontoopdeling. At forveksle de to er fejlen, der er værd at undgå: at behandle separate klientkonti, som om de var sider under ét login, er præcis den slags kryds-konto-blanding, der aldrig bør ske med klientdata.
| Side-skift | Kontoopdeling | |
| Hvem har loginnet | Dig, på vegne af klienterne | Hver klient, uafhængigt |
| Hvad ændrer sig mellem klienter | Den valgte side | Hele MCP-serverregistreringen og tokenfilen |
| Værktøjer involveret | pushengage_list_sites, pushengage_select_site | Separate PE_MCP_CONFIG_PATH pr. servernavn |
| Fejltilstand, hvis du bruger den forkerte | Du når aldrig en klients data (hvis virkelig separate konti) | Unødvendig gen-godkendelses-overhead (hvis virkelig ét delt login) |
De fleste bureauer, der kører PushEngage på tværs af en fuld liste, ender med at bruge begge dele på én gang: de skifter mellem PushEngage-sider inden for de få klienter, der deler ét agentur-administreret login, og registrerer separate konti for de klienter, der insisterer på at have deres egne. Intet ved at registrere flere PushEngage-konti forhindrer dig i også at skifte sider inden for en af dem, når du først er logget ind.
Side-skift: trækker CTR på tværs af tre klientsider i én samtale
Til multi-side-tilfældet giver to værktøjer dig mulighed for at skifte mellem PushEngage-sider uden at forlade samtalen: pushengage_list_sites og pushengage_select_site. Hvert side-omfattende værktøj (analyse, segmenter, kampagneindstillinger) virker på den side, der i øjeblikket er valgt, og valget forbliver på tværs af genstarter, så du indstiller det én gang pr. session, og hvert opfølgende spørgsmål i den samtale gælder for den samme side.
Tilbage til mandag morgen. Med ét login forbundet ser CTR-trækket for tre klientsider således ud i en enkelt samtale:
- Spørg "list mine PushEngage-sider." Assistenten returnerer hver sides navn og ID.
- Spørg om at bruge den første sides ID, spørg derefter om sidste uges klikrate. Assistenten kalder
pushengage_get_analytics_timeseriesog returnerer klik, visninger og CTR pr. dag. - Spørg om at skifte til den anden sides ID. Spørg det samme spørgsmål. Gentag for den tredje.
- Spørg om et resumé, der sammenligner de tre. Assistenten har allerede hentet alle tre datasæt i samtalen og kan sætte dem side om side.
Det, der gør dette værd at gøre i stedet for tre dashboard-eksport, er ikke kun hastighed. Det er, at de tal, du trækker, kan tilskrives pr. websted, ikke kun rå åbninger og klik. pushengage_get_analytics_summary og pushengage_get_analytics_timeseries returnerer klik, visninger og målværdi sammen med CTR, så den rapport, du medbringer til kundemødet, læses som genvundet omsætning pr. websted, ikke kun engagement-antal, som du selv skulle oversætte for kunden.
Den indramning betyder noget, fordi CTR alene fortæller kun den halve historie. En brancheomfattende undersøgelse af segmentering og klikrate fandt, at CTR bevæger sig 2 gange eller mere afhængigt af, hvor tæt en kundes udsendelser er segmenteret, så det samme CTR-tal kan betyde meget forskellige omsætningsresultater på tværs af tre kunder med forskellig segmenteringsmodenhed. Den forskel er værd at fremhæve i samtalen, ikke kun rapportere.
Dette er skrivebeskyttet arbejde. Intet ved at skifte mellem PushEngage-websteder på denne måde sender, planlægger eller redigerer en kampagne; pushengage_list_sites og pushengage_select_site ændrer kun, hvilke data fra webstedet resten af samtalen læser.
Kontoseparation: registrering af MCP-serveren under et navn pr. kunde
For ægte separate klientkonti ligger løsningen i selve MCP-konfigurationen, ikke i et værktøjsopkald. PushEngages server læser sin token-placering fra en miljøvariabel, PE_MCP_CONFIG_PATH, som som standard er ~/.pushengage/mcp.json, hvis du aldrig har indstillet den. Registrer serveren to gange, én gang pr. kunde, hver pegende på sin egen fil, og de to logins deler aldrig et token:
{
"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 og Brightleaf er illustrative kundenavne.) PE_MCP_CONFIG_PATH skal være en absolut sti — den bruges præcis som angivet, uden ~-udvidelse, så dobbelttjek stien, før du genstarter din klient. PE_MCP_CLIENT_NAME er valgfri og ændrer kun den etiket, din assistent viser på PushEngages egen godkendelsesskærm; den påvirker ikke isolationen, men det er værd at indstille, så du kan se, hvilken kunde du har godkendt, når browserfanen åbnes.
Log ind på hvert servernavn separat: "log mig ind på pushengage-northwind", derefter, i et senere trin, "log mig ind på pushengage-brightleaf". Hver godkender mod den PushEngage-konto, du vælger i den specifikke browsersession. To servernavne, to konfigurationsfiler, to tokens, der aldrig rører hinanden. Dette er mønsteret for at køre flere PushEngage-konti side om side, og det skalerer ud over to: et bureau med et dusin klientkonti registrerer et dusin serverposter, hver med sin egen PE_MCP_CONFIG_PATH, og ingen af dem deler nogensinde en fil. Det er også den del, som de fleste konkurrerende "multi-client AI"-guides springer over med vag snak om isolation i stedet for en faktisk konfiguration at kopiere.
Kør den samme prompt til oprettelse af segment på tværs af alle klientkonti
Når dine klienter er registreret som separate servernavne, kan du afspille én anmodning på tværs af dem alle uden nogensinde at åbne et dashboard. Lad os sige, at du vil have et segment for "besøgende på /pricing" live på fem klientkonti inden slutningen af dagen. Bed din assistent om at "oprette et segment for besøgende på /pricing" mod pushengage-northwind, derefter pushengage-brightleaf, derefter hvert af de resterende klientservernavne. Hver anmodning kalder pushengage_create_segment mod den pågældende kontos eget token, og hver klient ender med det samme URL-regelsegment, bygget på deres egen abonnentbase.
Grunden til, at den samme prompt overføres rent på tværs af fem forskellige klientkonti, er, at den aktiverer en segmenteringsmodel, som PushEngage leverer indbygget, ikke noget, du arkitekturer fra bunden for hver klient. pushengage_list_segments og pushengage_create_segment fungerer ud fra URL-regler og adfærdskriterier, som platformen allerede forstår – recency, frequency, sidebesøgsmønstre – de samme kategorier, der får e-handelssegmenteringsguidens tilgang til at fungere som et system snarere end en engangsliste. Det er det, der lader én prompt udføre reel segmenteringsarbejde fem gange i stedet for fem separate manuelle opbygninger. Og fordi segmentering nu er et leveringskrav snarere end en "nice-to-have", er gentagelse på tværs af hver klientkonto tættere på standard kontohygiene end en genvej.
At holde en tidligere teammedlems adgang ude af hver anden klients konto
Kontoseparation tjener sit formål den dag, nogen forlader en konto. Fordi hver klients token ligger i sin egen konfigurationsfil, påvirker fjernelse af én persons adgang til én klient aldrig resten af din liste.
To måder at afslutte det på:
- Lokalt: log ud af kun den pågældende klients serverregistrering – "log mig ud af pushengage-northwind" kalder
pushengage_auth_logout, som sletter tokenet fra den ene konfigurationsfil og lader alle andre klients filer urørte. - Server-side: hvis det afgående teammedlem selv godkendte browser-sessionen, tilbagekald den indefra PushEngage under Indstillinger → Sikkerhed på den specifikke klients konto, hvilket ugyldiggør tokenet, uanset hvor det er gemt lokalt.
Sammenlign det med, hvad der sker med et enkelt delt login på tværs af klienter: tilbagekaldelse af adgang betyder at rotere et delt token, hvilket bryder alle teammedlemmers forbindelse til alle klienter på én gang. At holde hver klient på sin egen PE_MCP_CONFIG_PATH forvandler en brandøvelse for hele listen til en enkelt linjes løsning.
Hvad dette ændrer for, hvordan et bureau prissætter og bemander push-arbejde på tværs af flere klienter
Intet af dette ændrer, hvad push-notifikationer gør for en kundes fastholdelsesprocent. PushEngages MCP-server sender, planlægger eller opbygger ikke kampagner af sig selv; hvert pushengage_send_notification- eller pushengage_send_ab_notification-kald kører stadig mod ét websted ad gangen, med din godkendelse. Det, der ændres, er tiden mellem "kunden vil kende deres tal" og "kunden har deres tal", og tid er den ene ressource, en account manager ikke kan købe mere af midt på måneden.
Det er den reelle værdi af at administrere flere klientkonti med én AI-assistent: ikke en ny kapacitet, men tid tilbage. Det betyder noget i den skala, PushEngage allerede kører på — 25.000+ virksomhedsejere i 150+ lande sendte 15,2 milliarder notifikationer gennem platformen alene i de sidste 30 dage.
Et bureau, der administrerer en håndfuld af disse konti, beder ikke denne infrastruktur om at gøre noget nyt; det beder om at nå rapporterings- og publikumsopbygningsarbejdet, som den allerede udfører, uden at et dashboard-login står mellem assistenten og svaret. Account manageren, der plejede at bruge mandag formiddage på at eksportere tre CSV-filer, bruger nu den tid på, hvad disse tal siger om hver kundes gentagne købsrate. Det er den del af jobbet, der aldrig skulle have handlet om logins i første omgang.
Uanset om din liste har brug for websteds-skift, kontoseparation eller begge dele, kører ovenstående mekanik på alle PushEngage-planer, prissat til at skalere med aktive abonnenter snarere end pr. klientkonto, så tilføjelse af den fjerde eller femte klient til denne opsætning betyder ikke genforhandling af, hvad du betaler for at nå dem. Det er den faktiske form af PushEngage MCP for bureauer: ikke et nyt manager-konto-lag ovenpå, men de samme to mekanikker (et login med flere websteder eller flere logins, der aldrig krydses) anvendt på hvor mange klienter du end kører i dette kvartal.
