Als u een growth- of ops-manager bent van een Shopify Plus- of WooCommerce-winkel en u zich afvraagt waarom mijn getriggerde campagne niet wordt verzonden, is het eerlijke antwoord dat u het waarschijnlijk niet via het dashboard zelf zult ontdekken - u zult het ontdekken omdat een metriek is afgedreven. Cart-recovery-inkomsten zien er de derde week op rij zwak uit. Een abonnee stuurt een bericht naar de ondersteuning en vraagt waarom ze al een maand geen restock-alert hebben ontvangen. Iemand opent eindelijk het automatietabblad dat ze sinds maart niet hebben aangeraakt en merkt dat de back-in-stock-trigger de hele tijd "Pauze" heeft aangegeven.
Dat is de werkelijke faalmodus voor getriggerde campagnes en RSS-auto-pushmeldingen: geen crash, geen foutbanner, gewoon stil. Een cart-abandonment-campagne die halverwege een uitverkoop is gepauzeerd en nooit is hervat, kondigt zichzelf niet aan. Dat geldt ook voor een RSS-feed die kapot ging toen de site naar een nieuwe CMS verhuisde. Beide blijven in de campagnelijst verschijnen en zien er precies zo uit als altijd, totdat iemand de juiste vraag stelt - en tegen de tijd dat iemand dat doet, wordt het antwoord meestal in weken gemeten, niet in minuten.
Dit bericht is die vraag, gesteld in duidelijke taal in plaats van een dashboard-crawl: met behulp van twee alleen-lezen tools ingebouwd in de PushEngage MCP-server, pushengage_list_triggered_campaigns en pushengage_list_rss_campaigns, om getriggerde campagne-analyses en RSS-feedgezondheid in één keer op te halen en een gepauzeerde of defecte automatisering te vangen voordat deze nog een week aan inkomsten kost.
De drie weken durende kloof waar niemand iets van merkt
Getriggerde campagnes en RSS-auto-push delen één eigenschap die ze uniek gemakkelijk te verliezen maakt: zodra ze zijn gebouwd, draaien ze zonder dat iemand ze opnieuw aanraakt. Dat is het hele punt - een cart-abandonment-trigger, een prijsdaler-alert, een back-in-stock-melding, een RSS-feed die elke nieuwe post automatisch pusht. Stel het één keer in, en het vuurt voor altijd op zijn eigen schema.
Behalve dat "voor altijd" ervan uitgaat dat er niets onder verandert. Een trigger wordt gepauzeerd tijdens een uitverkoop om overlapping met een promotionele knaller te voorkomen, en niemand vergeet deze weer in te schakelen. Een RSS-feed-URL verschuift tijdens een site-migratie, en de campagne die ernaar verwees, blijft "Actief" zeggen terwijl hij stilzwijgend niets vuurt. Een back-in-stock-trigger's inventarisfeed stopt met synchroniseren, en de trigger heeft niets meer om op te vuren. In elk geval ziet de campagne er prima uit in de lijstweergave. Hij doet gewoon niets.
Zet er een getal op, illustratief: een mid-market trigger voor winkelwagenverlating die iets als $1.800 per week aan winkelwagenwaarde herstelt, is geen ongebruikelijk cijfer voor een Shopify Plus-account met stabiel verkeer. Drie stille weken - de tijd die het normaal kost om er zelf achter te komen - is $5.400 aan herstelde inkomsten die nooit zijn hersteld, en niemand wist te zoeken totdat het top-line cijfer de vraag dwong.
Waarom getriggerde campagnes en RSS-feeds stilzwijgend falen
Beide automatiseringssoorten falen door een kleine, saaie reeks oorzaken, en geen daarvan activeert een foutstatus die een marketeer ooit zou zien.
- Een pauze overleeft zijn reden. Een campagne voor winkelwagenverlating die halverwege de verkoop is gepauzeerd, om te voorkomen dat deze concurreert met een blast-campagne voor "alleen deze week", wordt zelden op schema hervat - de persoon die de schakelaar omzette, gaat naar een ander project, en zes maanden later staat deze er nog steeds, nog steeds gemarkeerd als gepauzeerd, en niemand weet zeker waarom.
- Een upstream-integratie wordt stil. Een trigger voor prijsdaling of back-in-stock is afhankelijk van een inventaris- of prijsfeed van het winkelplatform. Als die feed stopt met synchroniseren - een plugin-update, een app-verbinding die wordt verbroken, een verlopen API-sleutel - heeft de trigger niets meer om tegen te controleren en vuurt deze simpelweg nooit meer af.
- De feed-URL verplaatst. Een CMS-migratie, een blog-replatforming of een domeinwijziging kan de RSS-feed waarop een auto-push-campagne is gericht, stilzwijgend verbreken, zonder de instellingen van de campagne zelf aan te raken. De campagne blijft actief omdat, voor zover de eigen instellingen van PushEngage betreft, niets is veranderd.
- Een browse-abandonment regel stopt met matchen. Als een website-redesign de URL-structuur verandert of de pagina verwijdert waarop een browse-abandonment trigger toezicht houdt, blijft de trigger draaien, maar heeft deze niets meer om op te vangen.
- Een eenmalige uitzondering wordt permanent. Een trigger wordt uitgeschakeld voor een enkele productlijn tijdens een terugroepactie of een leveranciersprobleem, en de stap om deze opnieuw in te schakelen valt van ieders lijst zodra het oorspronkelijke probleem is opgelost.
Geen van deze genereert een supportticket voor het marketingteam. Ze genereren een supportticket voor de *klantenservice*, drie weken later, van een abonnee die zich afvraagt waar hun restock-alert is gebleven - wat de langzaamste, duurste manier is om erachter te komen, en degene die elke audit in dit bericht is gebouwd om te vermijden.
Waarom uw getriggerde campagne niet verzendt (en hoe u dit in vijf seconden controleert)
De snelste manier om "waarom wordt mijn getriggerde campagne niet verzonden" te beantwoorden, is stoppen met raden en om de lijst vragen. pushengage_list_triggered_campaigns retourneert elke getriggerde campagne op uw site gefilterd op status - actief, gepauzeerd of concept - en met include_analytics ingesteld, komt elke campagne terug met verzonden, gezien en geklikte tellingen voor de periode.
Die enkele aanroep doet de eerste vijftien seconden van triage voor u, waarbij elk resultaat in een van de drie staten wordt gesorteerd:
- Volledig donker — status is actief, maar het aantal verzendingen is nul (of bijna nul) voor de periode. Iets stroomopwaarts is defect geraakt.
- Correct stil — status is actief, het aantal verzendingen is laag, maar dat komt overeen met het werkelijke volume van de trigger (een back-in-stock-melding wordt alleen geactiveerd wanneer iets daadwerkelijk weer op voorraad is; een stille week is geen bug).
- Werkelijk gepauzeerd — status zegt gepauzeerd, simpel en duidelijk, en iemand moet beslissen of dat opzettelijk was.
Uitgelegd voor een illustratief mid-market e-commerce account dat vier getriggerde campagnes runt:
| Getriggerde campagne | Status | Verzonden | Gezien | Geklikt |
|---|---|---|---|---|
| Winkelwagen-abandonment | Actief | 3,940 | 2,610 | 210 |
| Browse-abandonment | Actief | 0 | 0 | 0 |
| Prijsdaler alert | Actief | 812 | 590 | 61 |
| Alert voor back-in-stock | Gepauzeerd | 0 | 0 | 0 |
Twee bevindingen springen er meteen uit. De back-in-stock-trigger is gepauzeerd — het is de moeite waard om te bevestigen of dat opzettelijk was, aangezien elke abonnee die wacht op een melding van herbevoorrading niets ontvangt zolang deze zo blijft staan. Het grotere probleem is de browse-abandonment-trigger: deze is gemarkeerd als actief, maar nul verzendingen betekent dat deze volledig donker is, niet correct stil — een site-wijziging heeft hoogstwaarschijnlijk de paginaregel die deze bewaakt gebroken, en elke bezoeker die sindsdien de browse-sessie heeft verlaten, heeft helemaal geen opvolging ontvangen.
Merk op wat de prijsdaling-melding hier doet: 812 verzendingen is een kleiner aantal dan de 3.940 van de cart-abandonment-trigger, en dat is prima — een prijsdaling-melding wordt alleen geactiveerd wanneer een prijs daadwerkelijk daalt, dus een lager volume is correct stil, geen rode vlag. De vaardigheid die dit gedeelte echt leert, is het onderscheid tussen die twee zonder te gokken: een trigger met verzendingen nabij zijn eigen historische basislijn is gezond bij elk volume; een trigger die regelmatig verzond en tot nul is gedaald, is defect, ongeacht hoe klein deze oorspronkelijk was.
Het is de moeite waard om duidelijk te vermelden: pushengage_list_triggered_campaigns somt op en leest. Het heractiveert geen gepauzeerde campagne, repareert geen defecte paginaregel, of bewerkt de voorwaarden van een trigger — de reparatie gebeurt nog steeds in het PushEngage-dashboard. Wat deze tool doet, is u in één keer precies vertellen welke van uw getriggerde campagnes die reparatie nodig hebben en waarom, in plaats van er doorheen te klikken om erachter te komen. Dat is de volledige waarde van het ophalen van getriggerde campagne-analyses via chat in plaats van een dashboard-tabblad: de bevinding duurt vijf seconden, en de vijftien minuten die u anders zou besteden aan scrollen, worden besteed aan de ene campagne die het daadwerkelijk nodig heeft.
Voor de onderliggende vraag welke gebeurtenissen daadwerkelijk de moeite waard zijn om in de eerste plaats een trigger voor te bouwen — welke gebeurtenissen verdienen trigger-campagnes behandelt de drie tests voor trigger-waardigheid die PushEngage gebruikt voor winkelwagenverlating, browse-verlating, prijsdaling en back-in-stock.
Het opvangen van een RSS-feed die stilzwijgend is gestopt met pushen
RSS auto push-meldingen falen volgens hetzelfde 'ziet er goed uit, is het niet'-patroon als getriggerde campagnes, alleen met een andere oorzaak: in plaats van een gepauzeerde status of een defecte paginaregel, zit de storing meestal in de feed zelf.
Vraag uw assistent om uw RSS-campagnes met status en analyses weer te geven, en pushengage_list_rss_campaigns retourneert elke campagne gefilterd op status, met dezelfde verzonden/gezien/geklikte uitsplitsing wanneer analyses zijn inbegrepen. De aanwijzing hier is bijna identiek aan het geval van getriggerde campagnes: een campagne die als actief is gemarkeerd met een verzonden telling die tot nul is gedaald, of scherp is gedaald ten opzichte van de normale basislijn, betekent bijna altijd dat de feed die het bekijkt, niet meer correct publiceert.
De gebruikelijke boosdoener is klein en gemakkelijk te missen: een contentteam schakelde van CMS-platform, wijzigde het URL-pad van de feed, of een plugin-update wijzigde hoe de feed zijn items formatteert, en niemand vertelde wie de pushmeldingen beheert. Voor een site die een redelijke publicatiecadans draait, is RSS auto-push meestal de hoogste automatiseringsvorm op de account, juist omdat deze wordt geactiveerd bij elke nieuwe post — wat ook betekent dat een kapotte feed sneller dan bijna al het andere op deze lijst van "stil" naar "een echt gat in terugkerend verkeer" gaat.
Een snelle vergelijking voor en na maakt de breuk duidelijk, illustratief:
- Normale week: RSS-campagne wordt 6-9 keer geactiveerd naarmate nieuwe posts worden gepubliceerd, wat overeenkomt met de normale contentcadans van de site.
- Kapotte week: RSS-campagne toont actief, nul verzendingen, en de site heeft vier nieuwe posts gepubliceerd in hetzelfde tijdsbestek — een duidelijk signaal dat de feedverbinding, niet de contentkalender, het probleem is.
Dezelfde nauwkeurigheidsopmerking als hierboven, herhaald omdat het hier net zo belangrijk is: pushengage_list_rss_campaigns somt status en prestaties op en leest deze. Het kan geen kapotte feed-URL opnieuw richten of de campagne zelf herstarten — die correctie gebeurt in het dashboard zodra u weet naar welke feed u moet kijken, meestal door de feed-URL in de instellingen van de RSS-campagne opnieuw te valideren en te bevestigen dat deze nog steeds naar het juiste domein verwijst. Als u nog geen RSS auto-push campagne hebt ingesteld, het instellen van een RSS auto-push campagne doorloopt de configuratie; deze post gaat ervan uit dat er al een loopt en alleen een gezondheidscontrole nodig heeft.
Aangrenzende automatiseringstypen die het waard zijn om in dezelfde pas te bekijken — het maken van een prijsdaling-notificatiecampagne en het instellen van back-in-stock pushmeldingen — dekken de instellingskant van twee van de getriggerde campagnetypen die deze audit controleert. En als drip-campagnes of Workflows ook deel uitmaken van uw automatiseringsstack, het auditen van drip-campagnes en workflows behandelt dat aangrenzende paar op dezelfde manier als deze post getriggerde campagnes en RSS behandelt.
Aan de slag: de PushEngage MCP-server verbinden
Het uitvoeren van deze controle vanuit een chatvenster begint met het toevoegen van de PushEngage MCP-server aan de configuratie van uw assistent. Voor Claude Desktop of Cursor is dat één vermelding in de MCP-configuratie van de client die verwijst naar npx -y @pushengage/mcp — geen aparte installatie nodig, aangezien npx de server op aanvraag ophaalt. Claude Code werkt op dezelfde manier.
Start de client opnieuw op, vraag deze om u aan te melden bij PushEngage (een browsertabblad wordt geopend om de verbinding te autoriseren, zodat uw gegevens nooit via de assistent lopen), vraag vervolgens om uw sites te bekijken en selecteer degene waarmee u wilt werken. Elke site-specifieke tool, inclusief beide tools in dit bericht, wordt daarna standaard voor die site gebruikt. Voor de volledige handleiding — configuratiebestandspaden, aanmelding bij de eerste uitvoering en wat te doen als de verbinding niet start — zie de volledige PushEngage MCP-installatiegids.
Dit in een wekelijkse gewoonte veranderen, geen eenmalige controle
Het doel van deze audit is niet om vandaag de ene defecte campagne te vinden. Het is om het controleren ervan een vraag van vijf seconden te maken in plaats van een project dat niemand plant. PushEngage werkt met een reëel volume — 25.000+ bedrijfseigenaren in 150+ landen verzenden maandelijks meer dan 15,2 miljard meldingen via het platform — en op die schaal kost een gepauzeerde trigger of een defecte feed niet een paar klikken. Het kost de herstelde winkelwagenwaarde of het terugkerende bezoekersverkeer dat automatisering moest vastleggen, voor precies zolang het stil blijft.
Dat is het geval voor het hardop vragen: "waarom stuurt mijn getriggerde campagne niet" op maandag in plaats van erachter te komen via een zacht inkomstengetal in een maandelijkse beoordeling. Vraag uw assistent om uw getriggerde campagnes en RSS-campagnes met analyses op te sommen, kijk naar de PushEngage-abonnementen als een trigger die u mist de moeite waard blijkt te zijn om te bouwen, en besteed de vijftien minuten die u bespaart in het dashboard aan het repareren van het ene ding dat echt defect is.
