Din GA4-kanalattributionsrapport har et hul i sig. Sidste måneds push-afsendelser vises uden medium og uden kilde, så på papiret ligner de direkte trafik i stedet for genvundet omsætning. Du sporer det til en UTM-parameter, der aldrig blev udfyldt ud over pladsholderen, som dit team satte ved installation. Denne konfigurationsvejledning til PushEngage webstedsindstillinger eksisterer, fordi det at rette det ene felt i dag betyder at logge ind på dashboardet, finde den rigtige fane og genindtaste alle andre standardfelter på én gang, da formularen ikke lader dig redigere kun ét.
Det er den faktiske pris for PushEngage webstedsindstillinger: ikke at nogen enkelt indstilling er svær at forstå, men at webstedsoplysninger, kampagneindstillinger og service worker-konfiguration ligger separate steder, røres sjældent nok til, at ingen husker hvor, og kræver en fuld genindtastning af formularen for at rette ét felt. Denne vejledning dækker de tre indstillingsgrupper, du rent faktisk vil genbesøge — webstedsoplysninger, kampagneindstillinger og service worker-indstillinger — og hvordan du ændrer dem med en anmodning på almindeligt sprog til en AI-assistent, der er forbundet til PushEngage MCP-serveren, i stedet for en jagt på dashboard-faner.
Hvorfor konfiguration af PushEngage webstedsindstillinger bliver til en supportbillet i stedet for en løsning på fem minutter
Webstedsindstillinger konfigureres ikke én gang og glemmes. De genbesøges hver gang virksomheden ændrer form: et nyt marked betyder en tidszoneændring, et nyt attributionskrav betyder en UTM-parameteropdatering, en rebranding betyder, at "Powered By PushEngage"-kontakten skal ses nærmere på, en platformsmigrering betyder at kontrollere, om service worker-filen stadig ligger, hvor PushEngage forventer det. Fordi hver af disse ligger i et andet hjørne af dashboardet, er den faktiske friktion ikke selve redigeringen. Det er at finde fanen igen, derefter genindtaste felter, du ikke havde tænkt dig at røre ved, på en opgave, du vil udføre igen om tre måneder, når noget andet ændrer sig.
Tre fejlmodes dukker op ofte nok til at betyde noget, og ingen af dem kaster en fejl, når de sker:
- Et UTM-standardgab. Kampagneindstillinger leveres med pladsholder- eller tomme UTM-parametre, så hver push-afsendelse i det vindue vises i GA4 uden medium eller kilde, usynlig i en kanalattributionsrapport.
- En manglende fallback-meddelelse. Usegmenterede abonnenter, dem der ikke matcher nogen målgrupperegel, får intet, eller generisk tekst, i stedet for en bevidst standard, som dit team valgte.
- En forældet service worker-sti efter en websteds-migrering. Dette stopper meddelelser fra at blive leveret overhovedet, uden at producere en åbenlys fejlmeddelelse, der peger tilbage på den indstilling, der forårsagede det.
Alle tre koster stille og roligt dig data, rækkevidde eller levering, indtil nogen tilfældigvis bemærker det, normalt mens de ser på en rapport, der ikke stemmer.
Det er tilfældet for at behandle webstedsindstillinger som en tilbagevendende kontrol snarere end et engangstrin, og det er tilfældet for at ændre, hvordan du tjekker dem.
Kom godt i gang: Tilslut PushEngage MCP-serveren til din assistent
@pushengage/mcp er PushEngages officielle Model Context Protocol-server, og hvert værktøj i denne guide kører igennem den. Tilføj den til din klients MCP-konfiguration — Claude Desktops claude_desktop_config.json, Cursors ~/.cursor/mcp.json eller Claude Codes egen MCP-konfiguration — med kommandoen npx -y @pushengage/mcp. Ingen global installation er påkrævet.
Første gang du beder din assistent om at logge dig ind, åbner den en browserfane for at godkende forbindelsen, så din PushEngage-adgangskode aldrig rører assistenten selv, og den resulterende token gemmes lokalt på din maskine. Derfra kan du bede om at se dine PushEngage-websteder og vælge det, du vil arbejde på; hvert indstillingsværktøj nedenfor bruger som standard det websted, du i øjeblikket har valgt. For den komplette gennemgang, inklusive fejlfinding af forbindelsesproblemer, se den fulde PushEngage MCP-opsætningsguide.
Webstedsdetaljer: navn, URL, tidszone, geolokation og branding-afbryderen
pushengage_get_site_details læser din nuværende konfiguration; pushengage_update_site_details ændrer den. Mellem dem dækker de de felter, som PushEngages egne onboarding-dokumenter kalder “Tilføj webstedsdetaljer”:
- Webstedsnavn
- Websteds-URL
- Tidszone
- Geolocation-sporing
- “Powered By PushEngage”-branding-afbryderen på din dashboard-widget
Hvis du nogensinde har haft brug for at rette en af disse pushengage-webstedsdetaljer efter den indledende installation, er dette værktøjsparet, der når alle fem felter, og det er det samme værktøjspar til at læse dem tilbage, før du antager, at noget er forkert konfigureret.
Tidszonen betyder mere, end den ser ud til. Det er referencepunktet for enhver planlagt afsendelse og ethvert stykke abonnent-tidszone-baseret planlægning, du kører. Få den forkert, og en afsendelse kl. 9 lander kl. 2 for en del af din liste, hvilket opfattes som en målretningsfejl, når den virkelige årsag er ét forkert konfigureret felt.
Geolocation er slået fra som standard og skal eksplicit tændes, før PushEngage kan knytte by-, stats- og landsdata til en abonnentpost, hvilket er grundlaget geolocation-målretning afhænger af. Hvis dine segmenter refererer til placering, og tallene ser tynde ud, er dette værd at tjekke, før du antager, at din abonnentbase ikke har den geografiske spredning, du forventede.
Branding-afbryderen er enklere: den styrer, om “Powered By PushEngage” overhovedet vises på din dashboard-widget, hvilket er mest relevant for teams, der kører en hvidmærket support- eller chatoplevelse, hvor alle synlige leverandørmærker bliver gransket.
Ingen af disse kræver en supportbillet eller en jagt gennem indlejrede indstillingsmenuer. README'ens eget eksempel er mønsteret, man skal følge: spørg din assistent: “Skift min websteds tidszone til Asia/Kolkata og slå geolokation til,” og begge felter opdateres i én anmodning. Korrigering af din websteds-URL efter en domæneændring eller dit webstedsnavn efter en rebrand følger det identiske mønster.
Kampagnestandarder: indstillingerne, der stille styrer enhver udsendelses tilskrivning og rækkevidde
pushengage_get_campaign_defaults og pushengage_update_campaign_defaults dækker fire felter. Disse pushengage kampagnestandarder er ikke kosmetiske. Det er indstillingerne, der ligger under enhver udsendelse, du kører, uanset om nogen i teamet husker, at de eksisterer, og at få en af dem forkert fejler ikke højt nok til, at nogen bemærker det med det samme.
- UTM-parametre: din basislinje for sporing af push-meddelelser med UTM-parametre i GA4 eller enhver analyse-stack, der ligger nedstrøms for den. Spring denne indstilling over, og enhver udsendelse arver blank tilskrivning: udsendelser uden kilde eller medium, uattribuérbar indtjening, et hul, som ingen bemærker, før en månedlig rapport ikke stemmer. Det er den kanal-tilskrivningsrapport, der åbnede denne artikel.
- Standardmeddelelse: hvad der udløses for en abonnent, der ikke matcher nogen målgrupperegel. Lad den være uindstillet, og disse abonnenter får intet overhovedet.
- Standardattributter: personaliseringstokens for den samme usegmenterede gruppe, så deres tekst læses som bevidst snarere end ødelagt eller generisk. En abonnent uden en matchende attribut bør ikke se et blankt felt, hvor deres fornavn skulle have stået.
- Standardudløb for meddelelser: hvor længe en ikke-leveret udsendelse forbliver i kø, før PushEngage dropper den. En flash-salgsudsendelse med et 7-dages udløb kan stadig lande dage efter, at salget er slut, hvilket vildleder en abonnent i stedet for bare at fejle stille, hvilket er værre for forholdet end at udsendelsen aldrig ankommer.
Indstilling af et 7-dages standardudløb er en enkelt anmodning: “Indstil mit standardudløb for meddelelser til 7 dage,” direkte fra README'ens eget eksempel. Det samme mønster dækker en standardmeddelelse for ikke-matchende abonnenter, standardattributter for den gruppes personalisering, eller en fuld gennemgang af UTM-parametre, så enhver udsendelse korrekt tilskrives tilbage til GA4 fremover. Gennemgang af dine nuværende pushengage kampagnestandarder før et stort udsendelsesvindue, snarere end efter et rapporteringshul dukker op, er den version af denne vane, der er værd at opbygge.
Service worker-indstillinger: registrering, undermappesupport og stien til worker-filen
pushengage_get_service_worker_settings og pushengage_update_service_worker_settings dækker registrering, undermappesupport og stien til worker-filen: mekanismerne, der lader push-notifikationer nå en browser i første omgang. Hvis en af de tre er forkert, er fejltilstanden den samme. Notifikationer stopper med at blive leveret stille og roligt, uden nogen åbenlys fejl, der peger tilbage på den indstilling, der forårsagede det, og det første symptom, nogen bemærker, er et fald i antallet af leverede beskeder uden nogen klar årsag.
Undermappesupport er den, der volder problemer for websteder med platformbegrænsninger, der ikke tillader en worker-fil på rodniveau: et CMS, en undermappeinstallation, et multi-site-setup, der deler et domæne. Hvis din worker-fil ligger et andet sted end roden, skal stivindstillingen matche den nøjagtige placering, både mappe og filnavn, ellers fejler registreringen stille og roligt.
Dette er det første, der er værd at tjekke efter en websteds-migration eller en platformændring: bed din assistent om at hente dine nuværende pushengage service worker-indstillinger og bekræft, at den registrerede sti stadig matcher, hvor filen rent faktisk ligger, den samme slags tjek som PushEngages egen service worker-konfiguration til platformbegrænsede setups eksisterer for at løse.
Registrering i sig selv er også værd et periodisk kig, især efter enhver ændring i, hvordan dit websted indlæser scripts. En opdatering af content security policy, en ny tag manager-container eller et caching-lag, der fjerner headers, kan hver især forstyrre registreringen på måder, der ikke vises andre steder end et stille fald i leverede notifikationer. At hente dine pushengage service worker-indstillinger sammen med et tjek af leveringsraten er en fem-minutters vane, der fanger problemet, før det koster dig en hel rapporteringscyklus.
Delvise redigeringer uden at genindtaste alt: hvorfor merge-adfærden betyder noget
Her er detaljen, der gør det hurtigere at spørge en AI-assistent end dashboardet, ikke bare anderledes: pushengage_update_campaign_defaults fletter din ændring over de aktuelle værdier i stedet for at erstatte hele posten. Bed om kun at ændre standardudløbet for notifikationer, og dine UTM-parametre, fallback-notifikation og fallback-attributter forbliver præcis som de var. Du behøver ikke at angive felter igen, som du ikke har til hensigt at røre ved.
Sammenlign det med en typisk indstillingsformular, hvor ændring af et felt i en gemt blok ofte betyder, at hele formularen genindlæses med alle felter redigerbare, og et fejltrin på et uvæsentligt felt overskriver stille og roligt noget, der fungerede korrekt. "Indstil mit standardudløb for notifikationer til 7 dage" ændrer præcis én ting og lader resten af dine kampagneindstillinger urørt. Det er forskellen mellem en målrettet redigering og en fuld gen-gemning, hver gang en enkelt indstilling skal justeres, og det er forskellen, der gør en månedlig gennemgang af indstillinger fra en femten-minutters pligt tilbage til den en-sætnings anmodning, den burde have været hele tiden.
Hvad nøjagtige indstillinger rent faktisk beskytter: leverbarhed og attribution, ikke kun pænhed
Intet af dette handler egentlig om ryddelighed. En forkert tidszone bryder planlagt afsendelsestidspunkt for en del af din liste. En manglende UTM-standard bryder attribution for hver afsendelse, indtil nogen opdager det. En forkert registreret service worker bryder levering helt, og gør det lydløst. Hver af disse indstillinger ligger under hver kampagne, dit team kører. Kampagnen fejler ikke højlydt; rapporteringen oven på den holder bare stille op med at matche virkeligheden.
Det er det faktiske tilfælde for at behandle webstedsdetaljer, kampagnestandarder og service worker-konfiguration som AI-assistent push-notifikationsindstillinger, du tjekker rutinemæssigt, på samme måde som du ville tjekke et leveringsrate-dashboard, snarere end et engangsopsætningsskridt, du konfigurerer én gang og aldrig vender tilbage til. At indramme disse som AI-assistent push-notifikationsindstillinger snarere end en begravet dashboard-fane betyder, at selve tjekket tager så lang tid, som det tager at skrive anmodningen. At fange en ødelagt UTM-standard eller en forældet worker-sti i én anmodning beskytter de samme genvundne indtægtsnumre, som din fastholdelsesrapportering afhænger af, uden at vente på en IT-billet eller et re-onboarding-opkald for at rette noget, der tager én sætning at sige højt.
Når din PushEngage MCP-server er forbundet, skal du køre igennem de tre indstillingsgrupper, der er dækket i denne PushEngage-webstedsindstillingskonfigurationsguide, på samme måde som du ville køre enhver anden fastholdelsesaudit: hurtigt og på din egen tidsplan, i stedet for kun når en rapport ikke stemmer. Det virker mod enhver PushEngage-plan, inklusive gratis niveauet, så der er ingen port mellem at have MCP-serveren forbundet og rent faktisk bruge den til at tjekke dine PushEngage-webstedsdetaljer, kampagnestandarder og service worker-indstillinger, før de koster dig attribution eller rækkevidde.
