Om du är en tillväxt- eller driftchef på en Shopify Plus- eller WooCommerce-butik och frågar dig varför min utlösta kampanj inte skickas, är det ärliga svaret att du förmodligen inte kommer att få reda på det från själva instrumentpanelen — du kommer att få reda på det för att en mätvärde har drivit. Intäkter från kundvagnsåterhämtning ser svaga ut för tredje veckan i rad. En prenumerant meddelar supporten och frågar varför de inte har fått en påminnelse om påfyllning på en månad. Någon öppnar äntligen fliken för automatiseringar som de inte har rört sedan mars och märker att utlösaren för "tillbaka i lager" har sagt "Pausad" hela tiden.
Det är det faktiska felscenariot för utlösta kampanjer och RSS-automatiska push-meddelanden: inte ett haveri, inte ett felmeddelande, bara tystnad. En kampanj för övergivna kundvagnar som pausas mitt i en rea och aldrig återupptas annonserar inte sig själv. Inte heller ett RSS-flöde som gick sönder när webbplatsen flyttades till ett nytt CMS. Båda fortsätter att visas i kampanjlistan och ser exakt ut som de alltid har gjort, ända tills någon ställer rätt fråga — och när någon gör det, mäts svaret vanligtvis i veckor, inte minuter.
Det här inlägget är den frågan, ställd på vanligt språk istället för en genomsökning av instrumentpanelen: med hjälp av två skrivskyddade verktyg inbyggda i PushEngage MCP-servern, pushengage_list_triggered_campaigns och pushengage_list_rss_campaigns, för att hämta analyser av utlösta kampanjer och hälsostatus för RSS-flöden i en enda genomgång och fånga en pausad eller trasig automatisering innan den kostar ytterligare en veckas intäkter.
Treveckorsgapet som ingen märker
Utlösta kampanjer och RSS-autopush delar en egenskap som gör dem unikt lätta att tappa bort: när de väl är byggda körs de utan att någon rör dem igen. Det är hela poängen — en utlösare för övergiven kundvagn, en prisfallsvarning, en påminnelse om påfyllning i lager, ett RSS-flöde som automatiskt skickar varje nytt inlägg. Ställ in det en gång, och det körs för evigt enligt sitt eget schema.
Förutom att "för evigt" förutsätter att inget någonsin förändras under det. En utlösare pausas under en rea för att undvika överlappning med en kampanjbombning, och ingen kommer ihåg att slå på den igen. En RSS-flödes-URL ändras under en webbplatsmigrering, och kampanjen som pekade på den fortsätter att säga "Aktiv" medan den tyst skickar ingenting. En utlösare för påfyllning i lager slutar synkronisera sin lagerström, och utlösaren har inget kvar att skicka på. I alla fall ser kampanjen bra ut i listvyn. Den gör bara ingenting.
Sätt en siffra på det, illustrativt: en trigger för kundvagnsavhopp på mellanmarknaden som återhämtar cirka 1 800 USD i kundvagnsvärde per vecka är inte en ovanlig siffra för ett Shopify Plus-konto med stadig trafik. Tre tysta veckor – den tid det vanligtvis tar för någon att märka det på egen hand – är 5 400 USD i återhämtad intäkt som aldrig återhämtades, och ingen visste att leta förrän topplinjesiffran tvingade fram frågan.
Varför utlösta kampanjer och RSS-flöden slutar fungera tyst
Båda automationstyperna misslyckas på grund av ett litet, tråkigt antal orsaker, och ingen av dem utlöser ett feltillstånd som en marknadsförare någonsin skulle se.
- En paus lever längre än sin anledning. En kampanj för kundvagnsavhopp som pausas mitt i en rea, för att den inte ska konkurrera med en stor kampanj under "bara den här veckan", återupptas sällan i tid – personen som slog av strömbrytaren går vidare till ett annat projekt, och sex månader senare ligger den fortfarande där, fortfarande markerad som pausad, och ingen är säker på varför.
- En uppströmsintegration blir tyst. En trigger för prissänkning eller åter i lager är beroende av ett lager- eller prisflöde från butiksplattformen. Om det flödet slutar synkroniseras – en plugin-uppdatering, en app som kopplas bort, en API-nyckel som gått ut – har triggern inget mer att kontrollera mot och skickas helt enkelt aldrig igen.
- Flödes-URL:en flyttas. En CMS-migrering, en bloggomplattform eller en domänändring kan tyst bryta RSS-flödet som en auto-push-kampanj pekar på, utan att röra själva kampanjens inställningar alls. Kampanjen säger fortfarande aktiv eftersom, såvitt PushEngages egna inställningar beträffar, ingenting har ändrats.
- En regel för besöksavhopp slutar matcha. Om en omdesign av webbplatsen ändrar URL-strukturen eller tar bort sidan som en trigger för besöksavhopp övervakar, fortsätter triggern att köras men har inget mer att fånga.
- Ett engångsundantag blir permanent. En trigger inaktiveras för en enskild produktlinje under en återkallelse eller ett leverantörsproblem, och steget för återaktivering faller bort från allas lista när det ursprungliga problemet är löst.
Ingen av dessa genererar en supportbiljett till marknadsteamet. De genererar en supportbiljett till *kundtjänst*, tre veckor senare, från en prenumerant som undrar vart deras lagerpåminnelse tog vägen – vilket är det långsammaste och dyraste sättet att få reda på det, och det som varje granskning i det här inlägget är byggt för att hoppa över.
Varför din utlösta kampanj inte skickar (och hur du kontrollerar på fem sekunder)
Det snabbaste sättet att svara på "varför skickar min utlösta kampanj inte" är att sluta gissa och be om listan. pushengage_list_triggered_campaigns returnerar varje utlöst kampanj på din webbplats filtrerad efter status – aktiv, pausad eller utkast – och med include_analytics inställt, kommer var och en tillbaka med antal skickade, visade och klickade för perioden.
Den enda anropet gör de första femton sekunderna av triage åt dig, och sorterar varje resultat i ett av tre tillstånd:
- Helt mörkt — status är aktiv, men antal skickade är noll (eller nära noll) för perioden. Något har gått sönder uppströms.
- Korrekt tyst — status är aktiv, antal skickade är lågt, men det matchar triggerns verkliga volym (en "åter i lager"-avisering utlöses bara när något faktiskt fylls på lager; en tyst vecka är inte ett fel).
- Faktiskt pausad — status säger pausad, helt enkelt, och någon måste bestämma om det var avsiktligt.
Utformad för ett illustrativt e-handelskonto i mellanklassen som kör fyra utlösta kampanjer:
| Utlöst kampanj | Status | Skickat | Sedda | Klickade |
|---|---|---|---|---|
| Varukorgsavhopp | Aktiv | 3,940 | 2,610 | 210 |
| Övergivna webbläsningar | Aktiv | 0 | 0 | 0 |
| Meddelande om prissänkning | Aktiv | 812 | 590 | 61 |
| Åter i lager-varning | Pausad | 0 | 0 | 0 |
Två fynd sticker ut omedelbart. "Åter i lager"-triggern är pausad — värt att bekräfta om det var avsiktligt, eftersom varje prenumerant som väntar på en avisering om påfyllning får ingenting medan den är i det läget. Det större problemet är "lämna kundvagnen"-triggern: den är markerad som aktiv, men noll skickade betyder att den är helt mörk, inte korrekt tyst — en webbplatsändring har mest troligt brutit sidregeln den övervakar, och varje besökare som lämnat kundvagnen sedan dess har inte fått någon uppföljning alls.
Lägg märke till vad pris-dropp-aviseringen gör här: 812 skickade är ett mindre antal än "lämna kundvagnen"-triggerns 3 940, och det är okej — en pris-dropp-avisering utlöses bara när ett pris faktiskt sjunker, så en lägre volym är korrekt tyst, inte en varningsflagga. Färdigheten som detta avsnitt verkligen lär ut är att skilja dessa två åt utan att gissa: en trigger med skickade nära sin egen historiska baslinje är frisk vid alla volymer; en trigger som brukade skicka regelbundet och har sjunkit till noll är trasig oavsett hur liten den var från början.
Värt att påpeka tydligt: pushengage_list_triggered_campaigns listar och läser. Den återaktiverar inte en pausad kampanj, fixar en trasig sidregel eller redigerar en triggers villkor — fixen sker fortfarande i PushEngage-instrumentpanelen. Vad detta verktyg gör är att berätta, i ett anrop, exakt vilka av dina utlösta kampanjer som behöver den fixen och varför, istället för att klicka igenom var och en för att ta reda på det. Det är hela värdet av att hämta analyser av utlösta kampanjer via chatt istället för en instrumentpanelsflik: fyndet tar fem sekunder, och de femton minuter du annars skulle spendera på att scrolla spenderas på den enda kampanjen som faktiskt behöver det.
För den underliggande frågan om vilka händelser som faktiskt är värda att bygga en trigger för från första början — vilka händelser som förtjänar triggerkampanjer täcker de tre testerna för trigger-värdighet som PushEngage använder för kundvagnsövergivande, webbplatsöverlevnad, prissänkning och åter i lager.
Fånga ett RSS-flöde som tyst slutade att skicka
RSS-automatiska push-aviseringar misslyckas med samma mönster "ser bra ut, är det inte" som utlösta kampanjer, bara med en annan orsak: istället för en pausad status eller en trasig sidregel, sitter felet vanligtvis i själva flödet.
Be din assistent att lista dina RSS-kampanjer med status och analys, och pushengage_list_rss_campaigns returnerar varje kampanj filtrerad efter status, med samma uppdelning av skickade/sedda/klickade när analyser inkluderas. Tricket här är nästan identiskt med fallet med utlöst kampanj: en kampanj markerad som aktiv med ett skickat antal som har sjunkit till noll, eller sjunkit kraftigt från sin normala baslinje, betyder nästan alltid att flödet den övervakar slutade publiceras korrekt.
Den vanliga boven är liten och lätt att missa: ett innehållsteam bytte CMS-plattformar, ändrade flödets URL-sökväg, eller en plugin-uppdatering ändrade hur flödet formaterar sina objekt, och ingen informerade den som äger push-notifikationerna. För en webbplats som kör en anständig publiceringstakt är RSS auto-push vanligtvis den mest volymmässiga automatiseringen i kontot just för att den utlöses vid varje nytt inlägg — vilket också innebär att ett trasigt flöde går från "tyst" till "ett verkligt gap i återvändande trafik" snabbare än nästan något annat på den här listan.
En snabb jämförelse före/efter gör avbrottet uppenbart, illustrativt:
- Normal vecka: RSS-kampanj utlöses 6–9 gånger när nya inlägg publiceras, vilket matchar webbplatsens normala innehållstakt.
- Trasig vecka: RSS-kampanj visar aktiv, noll sändningar, och webbplatsen har publicerat fyra nya inlägg under samma tidsperiod — ett tydligt tecken på att flödesanslutningen, inte innehållskalendern, är problemet.
Samma noggrannhetsanmärkning som ovan, omformulerad eftersom den är lika viktig här: pushengage_list_rss_campaigns listar och läser status och prestanda. Den kan inte peka om en trasig flödes-URL eller starta om själva kampanjen — den korrigeringen sker i instrumentpanelen när du vet vilket flöde du ska titta på, vanligtvis genom att återvalidera flödes-URL:en i RSS-kampanjens inställningar och bekräfta att den fortfarande löser sig till rätt domän. Om du inte redan har ställt in en RSS auto-push-kampanj, går att ställa in en RSS auto-push-kampanj igenom konfigurationen; det här inlägget förutsätter att en redan körs och bara behöver en hälsokontroll.
Intilliggande automationstyper värda att titta på i samma genomgång — att skapa en kampanj för prissänkning och att ställa in push-notifikationer för lageråterkomst — täcker inställningssidan för två av de utlösta kampanjtyperna som den här granskningen kontrollerar. Och om droppkampanjer eller arbetsflöden också är en del av din automationsstack, täcker granskning av droppkampanjer och arbetsflöden det intilliggande paret på samma sätt som det här inlägget täcker utlösta kampanjer och RSS.
Komma igång: ansluta PushEngage MCP-servern
Att köra den här kontrollen från ett chattfönster börjar med att lägga till PushEngage MCP-servern i din assistents konfiguration. För Claude Desktop eller Cursor är det en post i klientens MCP-konfiguration som pekar på npx -y @pushengage/mcp — ingen separat installation behövs, eftersom npx hämtar servern vid behov. Claude Code fungerar på samma sätt.
Starta om klienten, be den logga in dig på PushEngage (en webbläsarflik öppnas för att auktorisera anslutningen, så dina uppgifter skickas aldrig via assistenten), be sedan att få se dina webbplatser och välj den du vill arbeta med. Varje webbplats-specifikt verktyg, inklusive båda verktygen i det här inlägget, används som standard för den webbplatsen därefter. För hela genomgången — sökvägar till konfigurationsfiler, inloggning första gången och vad du ska göra om anslutningen inte startar — se den fullständiga guiden för PushEngage MCP-installation.
Att bygga detta till en veckovis vana, inte en engångskontroll
Syftet med denna granskning är inte att hitta den enda trasiga kampanjen idag. Det är att göra kontrollen av en sådan till en fem sekunders fråga istället för ett projekt som ingen schemalägger. PushEngage arbetar med verklig volym — 25 000+ företagare i över 150 länder skickar mer än 15,2 miljarder meddelanden i månaden via plattformen — och i den skalan kostar en pausad trigger eller en trasig feed inte ett klick eller två. Det kostar den återvunna kundvagns-värdet eller trafiken från återkommande besökare som automatiseringen byggdes för att fånga, exakt så länge den förblir tyst.
Det är fallet för att på måndagen högt fråga, ”varför skickar inte min triggade kampanj” istället för att upptäcka det från ett svagt intäktsnummer i en månadsöversikt. Be din assistent att lista dina triggade kampanjer och RSS-kampanjer med analyser, titta snabbt på PushEngage-planerna om en trigger du saknar visar sig vara värd att bygga, och spendera de femton minuterna du sparar i instrumentpanelen på att fixa det enda som faktiskt är trasigt.
