Din GA4-rapport för kanalattribution har ett hål i sig. Förra månadens push-utskick visas utan medium och källa, så på papperet ser de ut som direkt trafik istället för återvunnen intäkt. Du spårar det till en UTM-parameter som aldrig fylldes i förbi platshållaren som ditt team satte vid installationen. Den här konfigurationsguiden för PushEngage-webbplatsinställningar finns eftersom att fixa det enda fältet idag innebär att logga in på instrumentpanelen, hitta rätt flik och ange om alla andra standardfält samtidigt, eftersom formuläret inte låter dig redigera bara ett.
Det är den faktiska kostnaden för PushEngage-webbplatsinställningar: inte att någon enskild inställning är svår att förstå, utan att webbplatsdetaljer, kampanjstandarder och service worker-konfiguration finns på separata platser, hanteras så sällan att ingen minns var, och kräver en fullständig omregistrering av formuläret för att fixa ett fält. Den här guiden täcker de tre inställningsgrupperna du faktiskt kommer att återbesöka – webbplatsdetaljer, kampanjstandarder och service worker-inställningar – och hur du ändrar någon av dem med en begäran på vanligt språk till en AI-assistent ansluten till PushEngage MCP-servern, istället för en jakt på instrumentpanelens flikar.
Varför konfigurationen av PushEngage-webbplatsinställningar blir en supportbiljett istället för en fix på fem minuter
Webbplatsinställningar konfigureras inte en gång och glöms bort. De återbesöks varje gång verksamheten förändras: en ny marknad innebär en tidszonsändring, ett nytt krav på attribution innebär en uppdatering av UTM-parametern, en omprofilering innebär att "Powered By PushEngage"-växeln behöver en ny titt, en plattformsflytt innebär att kontrollera om service worker-filen fortfarande ligger där PushEngage förväntar sig den. Eftersom var och en av dessa finns i ett annat hörn av instrumentpanelen, är den faktiska friktionen inte själva redigeringen. Det är att återfinna fliken, sedan ange om fält du inte menade att röra, på en uppgift du kommer att göra igen om tre månader när något annat ändras.
Tre feltyper dyker upp tillräckligt ofta för att spela roll, och ingen av dem ger ett fel när de inträffar:
- Ett glapp i UTM-standardvärden. Kampanjstandarder levereras med platshållar- eller tomma UTM-parametrar, så varje push-utskick under den perioden visas i GA4 utan medium eller källa, osynligt i en rapport för kanalattribution.
- En saknad fallback-notis. Osegmenterade prenumeranter, de som inte matchar någon regel för målgrupp, får ingenting, eller generiskt innehåll, istället för ett avsiktligt standardvärde som ditt team valt.
- En föråldrad sökväg för service worker efter en webbplatsflytt. Detta stoppar leveransen av notiser helt, utan att ge ett uppenbart felmeddelande som pekar tillbaka på inställningen som orsakade det.
Alla tre kostar dig tyst data, räckvidd eller leverans tills någon råkar märka det, vanligtvis när de tittar på en rapport som inte stämmer.
Detta gäller för att behandla webbplatsinställningar som en återkommande kontroll snarare än ett engångssteg vid installation, och det gäller för att ändra hur du kontrollerar dem.
Kom igång: anslut PushEngage MCP-servern till din assistent
@pushengage/mcp är PushEngages officiella Model Context Protocol-server, och varje verktyg i den här guiden körs genom den. Lägg till den i din klients MCP-konfiguration — Claudes skrivbordsversion claude_desktop_config.json, Cursors ~/.cursor/mcp.json, eller Claude Codes egen MCP-konfiguration — med kommandot npx -y @pushengage/mcp. Ingen global installation krävs.
Första gången du ber din assistent att logga in dig öppnas en webbläsarflik för att auktorisera anslutningen, så ditt PushEngage-lösenord rör aldrig assistenten själv, och den resulterande token lagras lokalt på din maskin. Från och med då, be att få se dina PushEngage-webbplatser och välj den du vill arbeta med; varje inställningsverktyg nedan använder som standard den webbplats du för närvarande har valt. För en komplett genomgång, inklusive felsökning av anslutningsproblem, se den fullständiga guiden för PushEngage MCP-installation.
Webbplatsdetaljer: namn, URL, tidszon, geolokalisering och varumärkesväxlingsknappen
pushengage_get_site_details läser din nuvarande konfiguration; pushengage_update_site_details ändrar den. Mellan dessa två täcker de de fält som PushEngages egna installationsdokument kallar "Lägg till webbplatsdetaljer":
- Webbplatsnamn
- Webbplatsens URL
- Tidszon
- Geolokalisering spårning
- Växlingsknappen "Powered By PushEngage" på din instrumentpanelswidget
Om du någonsin har behövt korrigera någon av dessa PushEngage-webbplatsdetaljer efter den första installationen, är detta verktygsparet som når alla fem fält, och det är samma verktygspar för att läsa tillbaka dem innan du antar att något är felkonfigurerat.
Tidszonen spelar större roll än vad den ser ut. Det är referenspunkten för varje schemalagd sändning och varje del av prenumerant-tidszonsbaserad schemaläggning du kör. Om du ställer in den felaktigt landar en sändning kl. 9 på morgonen kl. 2 på natten för en del av din lista, vilket uppfattas som ett misslyckande med målinriktning när den verkliga orsaken är ett felkonfigurerat fält.
Geolokalisering är inaktiverad som standard och måste uttryckligen aktiveras innan PushEngage kan koppla stad-, delstats- och landsdata till ett prenumerantregister, vilket är grunden som geolokaliseringsinriktning bygger på. Om dina segment refererar till plats och siffrorna ser tunna ut, är detta värt att kontrollera innan du antar att din prenumerantbas inte har den geografiska spridning du förväntade dig.
Varumärkesväxlingsknappen är enklare: den styr om "Powered By PushEngage" visas på din instrumentpanelswidget överhuvudtaget, vilket är viktigast för team som kör en vitmärkt support- eller chattupplevelse där varje synlig leverantörsmärke granskas.
Ingen av dessa kräver en supportbiljett eller en jakt genom kapslade inställningsmenyer. README:s eget exempel är mönstret att följa: fråga din assistent, ”Ändra min webbplatstidzon till Asia/Kolkata och aktivera geolokalisering”, och båda fälten uppdateras i en enda begäran. Att korrigera din webbplats URL efter en domänändring, eller ditt webbplatsnamn efter en omprofilering, följer exakt samma mönster.
Kampanjstandarder: inställningarna som tyst styr varje sändnings attribution och räckvidd
pushengage_get_campaign_defaults och pushengage_update_campaign_defaults täcker fyra fält. Dessa pushengage-kampanjstandarder är inte kosmetiska. De är inställningarna som ligger under varje sändning du kör, oavsett om någon i teamet kommer ihåg att de existerar, och att ställa in någon av dem felaktigt misslyckas inte tillräckligt tydligt för att någon ska märka det direkt.
- UTM-parametrar: din baslinje för att spåra pushmeddelanden med UTM-parametrar i GA4 eller någon analysstack nedströms från den. Hoppa över den här inställningen och varje sändning ärver tom attribution: sändningar utan källa eller medium, oattributerbar intäkt, ett gap som ingen märker förrän en månadsrapport inte stämmer. Det är den kanallänkade rapporten som öppnade den här artikeln.
- Reservmeddelande: vad som skickas till en prenumerant som inte matchar någon publikregel. Lämna det oinställt och dessa prenumeranter får ingenting alls.
- Reservattribut: personaliserings-tokens för samma osegmenterade grupp, så att deras text känns avsiktlig snarare än trasig eller generisk. En prenumerant utan matchande attribut bör inte se ett tomt utrymme där deras förnamn skulle ha stått.
- Standardutgång för meddelanden: hur länge en ej levererad sändning förblir i kö innan PushEngage släpper den. En snabbförsäljningssändning med en 7-dagars utgång kan fortfarande landa dagar efter att försäljningen har avslutats, vilket vilseleder en prenumerant istället för att bara misslyckas tyst, vilket är värre för relationen än att sändningen aldrig anländer alls.
Att ställa in en 7-dagars standardutgång är en enda begäran: ”Ställ in min standardutgång för meddelanden till 7 dagar”, direkt från README:s eget exempel. Samma mönster täcker ett reservmeddelande för omatchade prenumeranter, reservattribut för den gruppens personalisering, eller en fullständig genomgång av UTM-parametrar så att varje sändning korrekt attribuerar tillbaka till GA4 framöver. Att granska dina nuvarande pushengage-kampanjstandarder före ett stort sändningsfönster, snarare än efter ett rapporteringsgap dyker upp, är den versionen av denna vana som är värd att bygga.
Service worker-inställningar: registrering, stöd för undermappar och sökvägen till worker-filen
pushengage_get_service_worker_settings och pushengage_update_service_worker_settings täcker registrering, stöd för undermappar och sökvägen till worker-filen: mekanismerna som faktiskt låter pushmeddelanden nå en webbläsare överhuvudtaget. Om någon av de tre är felaktig är felmodellen densamma. Meddelanden slutar tyst att levereras, utan någon uppenbar felkälla som pekar tillbaka på inställningen som orsakade det, och det första symptomet någon märker är en minskning av antalet levererade meddelanden utan någon tydlig orsak.
Stöd för undermappar är det som ställer till det för webbplatser med plattformsbegränsningar som inte tillåter en worker-fil på rotnivå: ett CMS, en installation i en underkatalog, en multisite-konfiguration som delar en domän. Om din worker-fil ligger någon annanstans än i roten måste sökvägsinställningen matcha den exakta platsen, både katalog och filnamn, annars misslyckas registreringen tyst.
Detta är det första som är värt att kontrollera efter en webbplatsmigrering eller en plattformsändring: be din assistent att hämta dina nuvarande pushengage service worker-inställningar och bekräfta att den registrerade sökvägen fortfarande matchar var filen faktiskt finns, samma typ av kontroll som PushEngages egna service worker-konfiguration för plattformsbegränsade installationer finns för att lösa.
Själva registreringen är också värd en periodisk titt, särskilt efter någon ändring av hur din webbplats laddar skript. En uppdatering av innehållssäkerhetspolicyn, en ny tagghanteringsbehållare eller ett cachningslager som tar bort rubriker kan var och en störa registreringen på sätt som inte syns någon annanstans än en tyst nedgång i levererade meddelanden. Att hämta dina pushengage service worker-inställningar tillsammans med en kontroll av leveransgraden är en fem minuters vana som fångar problemet innan det kostar dig en hel rapporteringscykel.
Partiella redigeringar utan att ange allt igen: varför fusionsbeteendet spelar roll
Här är detaljen som gör att fråga en AI-assistent snabbare än instrumentpanelen, inte bara annorlunda: pushengage_update_campaign_defaults slår samman din ändring över de aktuella värdena istället för att ersätta hela posten. Om du ber att ändra bara standardutgången för meddelanden, förblir dina UTM-parametrar, fallback-meddelande och fallback-attribut exakt som de var. Du behöver inte ange fält som du inte har för avsikt att röra vid igen.
Jämför det med ett typiskt inställningsformulär, där ändring av ett fält i ett sparat block ofta innebär att hela formuläret laddas om med varje fält redigerbart, och en miss på ett irrelevant fält tyst skriver över något som fungerade korrekt. "Ställ in min standardutgång för meddelanden till 7 dagar" ändrar exakt en sak och lämnar resten av dina kampanjstandarder orörda. Det är skillnaden mellan en riktad redigering och en fullständig omsparning varje gång en enskild inställning behöver en justering, och det är skillnaden som gör en månatlig granskning av inställningar från en femton minuters syssla tillbaka till den enkla meningen som den borde ha varit hela tiden.
Vad korrekta inställningar faktiskt skyddar: leveransbarhet och attribution, inte bara snygghet
Inget av detta handlar egentligen om ordning och reda. En felaktig tidszon bryter schemalagd sändningstid för en del av din lista. En saknad standard-UTM bryter attribuering för varje sändning tills någon upptäcker det. En felregistrerad service worker bryter leveransen helt och hållet, och gör det tyst. Var och en av dessa inställningar ligger under varje kampanj som ditt team kör. Kampanjen misslyckas inte högljutt; rapporteringen ovanpå den slutar bara tyst att matcha verkligheten.
Det är det faktiska fallet för att behandla webbplatsdetaljer, kampanjstandarder och service worker-konfiguration som AI-assistentens push-meddelandeinställningar som du kontrollerar rutinmässigt, på samma sätt som du skulle kontrollera en instrumentpanel för leveransgrad, snarare än ett engångssteg för installation som du konfigurerar en gång och aldrig återbesöker. Att rama in dessa som AI-assistentens push-meddelandeinställningar snarare än en dold instrumentpanelflik innebär att själva kontrollen tar lika lång tid som det tar att skriva begäran. Att upptäcka en trasig standard-UTM eller en föråldrad worker-sökväg i en begäran skyddar samma återvunna intäktsnummer som din retentionsrapportering är beroende av, utan att behöva vänta på en IT-biljett eller ett återupptagningssamtal för att fixa något som tar en mening att säga högt.
När din PushEngage MCP-server är ansluten, kör igenom de tre inställningsgrupperna som täcks i den här guiden för konfiguration av PushEngage-webbplatsinställningar på samma sätt som du skulle köra någon annan retentionsrevision: snabbt och på din egen tid, istället för bara när en rapport inte stämmer. Det fungerar mot alla PushEngage-planer, inklusive gratisnivån, så det finns ingen grind mellan att ha MCP-servern ansluten och att faktiskt använda den för att kontrollera dina PushEngage-webbplatsdetaljer, kampanjstandarder och service worker-inställningar innan de kostar dig attribuering eller räckvidd.
