Nyhetsnotisen skickades ut kl. 06:47. Åttiotusen prenumeranter. En halv miljon notifikationsikoner tändes på iPhones och laptops i tre tidszoner. Klockan 06:53 visar din instrumentpanel en CTR på 4,1 % – bra för nyheter – och 3 200 klickningar på sex minuter. Nyheten sprids. Du borde känna dig nöjd.
Du känner dig inte nöjd. Pushnotifikationsautomatisering för utgivare ska leverera exakt detta ögonblick rent; istället känner du tre frågor som ingen instrumentpanel kan svara på så här snabbt. Var 80 000 rätt segment, eller gick notisen till politiska opt-outs som aldrig ville bli väckta för politiska nyheter? Var 06:47 rätt tidpunkt, eller skulle 07:15 ha fångat pendeltågssegmentet vid ett bättre tillfälle? Och frågan du inte kan sluta tänka på: fick de inaktiva läsarna från de senaste 30 dagarna denna notis, eller hoppade nedkylningen över dem, och om den hoppade över dem, fick då de läsare som bara läser förstasidan och som faktiskt klickar på nyheter den istället?
Det här är hur pushnotifikationsautomatisering för utgivare ser ut i de flesta nyhetsredaktioner: en RSS-autopush som skickar en notis varje gång en ny artikel läggs till i flödet, en nyhetsutlösare som frontdesken aktiverar manuellt, och en churn-varningstrigger som någon på e-postteamet ställde in för två år sedan och ingen helt förstår. Tre "automatiserade" mekanismer, ingen av dem medveten om de andra, ingen av dem har en sammanhängande bild av var prenumeranten befinner sig i läsresan.
Den här artikeln går igenom hur pushnotifikationsautomatisering för utgivare faktiskt borde se ut – arbetsflödesarkitektur, inte RSS-sändningar med en nyhetsutlösare påklistrad – och levererar fem arbetsflödesmallar för utgivare med tidpunkter, avslutningskriterier och intäktsmatematiken som gör var och en till en försvarbar post för annonsdrift och medlemskap.
- Varför "automatiserade pushnotiser för utgivare" bromsar återkommande besöksfrekvens
- Anatomin av ett arbetsflöde för pushnotiser för utgivare
- Fem arbetsflödesmallar för utgivare
- Ämnessegmentering, A/B-testning, nedkylningar och avslutningskriterier finns inuti arbetsflödet
- Orkestrering av flera kanaler: webb-push, app-push, nyhetsbrev och på webbplatsen
- Retentionsmatematiken: intäkter per arbetsflöde för annons- och prenumerationsutgivare
- Bygg det i PushEngage Workflows för din nyhetsredaktion
- Vad detta förändrar
Varför "automatiserade pushnotiser för utgivare" bromsar återkommande besöksfrekvens
Ordet automation har gjort samma obefogade arbete inom publicering som det har gjort inom e-handel och SaaS. När de flesta nyhetsredaktioners publikteam pratar om automatiserade push-notiser för publicister, menar de RSS-matad sändningsschemaläggning: en notis skickas varje gång en ny artikel publiceras, utan tillstånd, ingen segmentering, inga väntetider mellan kontakter, inga avslutningsvillkor. En ny artikel publiceras, auto-push skickas. En breaking news-story verifieras, redaktionsteamet utlöser manuellt en push. En prenumerant blir inaktiv, en push-notis som varnar för avhopp skickas en gång och ger upp. Varje mekanism är sin egen pipeline, ovetande om alla andra pipelines, och omedveten om var prenumeranten faktiskt befinner sig i sin läscykel.
Ett arbetsflöde är något annat. Ett arbetsflöde är en flerstegsresa med tillstånd. Det vet när prenumeranten anmälde sig, vilka ämnen de bryr sig om, vad de har läst nyligen och vilka villkor som avbryter resan. Ett arbetsflöde för breaking news skickar inte bara en push till alla i samma ögonblick som en artikel verifieras. Det skickas först till en 10-procentig ledande indikator-kohort, väntar fem minuter medan nyhetsredaktionen övervakar responsen, håller tillbaka de återstående 90% tills en redaktör uttryckligen bekräftar att artikeln har hållit måttet under tidig granskning, och skickas sedan till resten – eller dras tillbaka helt om den tidiga responsen signalerar ett problem.

Den sista meningen är skillnaden. RSS auto-push har inget minne av hur den tidiga kohorten svarade. Ett arbetsflöde har det. Om din nyhetsredaktion någonsin har behövt skicka en uppföljande push som korrigerar en tidigare breaking news-push, har du inte ett automationsproblem. Du har en saknad verifieringsgrind som automation faktiskt kan lösa.
För ett publikutvecklingsteam på medelmarknaden är denna distinktion skillnaden mellan en återkommande besöksfrekvens som växer och en som sjunker varje kvartal. Tre utlösare som körs parallellt ger tre kanaler av korsprat och ingen sammanhängande resa. Fem arbetsflöden som körs i samordning ger en resa per prenumerant per livscykelfas, förgrenad och begränsad av ämne, aktualitet och prenumerationsstatus. Sökresultaten på första sidan för detta nyckelord ramar in problemet som “vilken typ av push-notiser man ska skicka” och svarar med en verktygslistikel. Det är inte frågan en nyhetsredaktion klockan 06:47 ställer.
Anatomin av ett arbetsflöde för pushnotiser för utgivare
Före ritningarna, vokabulären. Ett arbetsflöde för push-notiser för publicister byggs upp av sex nodtyper. När du väl vet vad var och en gör, läses varje ritning i den här artikeln som ett diagram, inte en beskrivning.

START. Ingången. En START-nod definierar hur arbetsflödet utlöses, antingen genom en prenumerantshändelse (story_published, breaking_news_verified, article_read, paywall_meter_hit, breaking_news_confirmed — händelsen för redaktionell bekräftelse som en nyhetsredaktion skickar från instrumentpanelen) eller genom ett publikfilter som väljer prenumeranter som matchar kriterier vid en schemalagd tidpunkt (last_active > 14d, subscription_inactive, topic_opted_in: sports). Ett arbetsflöde har exakt en START.
WAIT. En paus. En WAIT-nod håller prenumeranten under en specificerad tid: minuter för verifieringsfönster för nyheter, timmar för uppföljningssekvenser, dagar för vård av prenumerationskonvertering, eller tills en specifik kalendertid. Pauser är hur ett arbetsflöde lär sig att inte vara en sändning.
DECISION. En tvåvägsgren. En DECISION-nod kontrollerar ett villkor per prenumerant — har prenumeranten valt politik, har de nått betalväggsmätaren, är de för närvarande betalande prenumeranter, har redaktionen redan skickat händelsen breaking_news_confirmed. Beslut är hur ett arbetsflöde slutar behandla varje prenumerant och varje nyhetshistoria på samma sätt.
SPLIT_PATH. En procentbaserad förgrening. SPLIT_PATH-noder dirigerar prenumeranter över sökvägar baserat på konfigurerade procentandelar: 10/90 för den stegvisa utrullningen av nyheter nedan, 50/50 för ett A/B-test på texten för prenumerationsfrågan, 33/33/34 för en trevägs sändningstidstest av det dagliga nyhetsbrevet. Lastbalansering är automatisk; när du har en vinnare, marknadsför du den sökvägen till 100 %.
ACTION. Själva arbetet. ACTION-noder skickar ett push-meddelande, lägger till prenumeranten i ett segment, uppdaterar anpassade attribut, skickar en HTTP-begäran till din ESP (Mailchimp, Substack, Beehiiv, Sailthru — för att samordna nyhetsbrevsinnehåll eller registreringar), startar ett annat arbetsflöde eller stoppar ett. PushEngage Workflows stöder elva åtgärdstyper. De mest användbara för utgivare är SendPushNotification, AddSegment, HttpRequest och Workflow.Start.
END / EXIT. Terminalen. END markerar den naturliga slutsatsen. EXIT markerar en tidig avslutning — på NEJ-sökvägen av ett beslut när prenumeranten inte längre kvalificerar sig, när kylningsregeln utlöses, eller när målet uppnås (prenumeration startad, förlorad läsare återvände, artikel avslutad).
Varje ritning nedan bygger på dessa sex delar.
Fem arbetsflödesmallar för utgivare
Dessa är inte mallar. De är fungerande ritningar för automatisering av push-meddelanden för nyheter som ett publikutvecklingsteam kan leverera samma vecka. Var och en listar dess utlösare, körtyp, nodsekvens, avslutningskriterier och den utgivarmetrik den är byggd för att flytta. Du kan ladda upp var och en i PushEngage Workflows-byggaren och leverera den första versionen på under en timme. Den gamla hubbposten om push-meddelanden för att marknadsföra en nyhetswebbplats katalogiserar de bredare kampanjtyperna som dessa ritningar implementerar; vad som följer är researkitekturen som kopplar ihop dessa kampanjer till en sekvens.
Mall 1 — Välkomstmeddelande till nya prenumeranter
- Utlösare (START): Händelse
PushEngage.Subscriber.Added - Körningstyp: Enkel (en välkomstresa per prenumerant per 90-dagarsperiod)
- Flöde: Välkomstpush omedelbart med din mest populära senaste artikel → VÄNTA 1 dag → push för ämnespreferenser som frågar vilka sektioner som är viktigast (sport, politik, affärer, lokalt, livsstil, opinion) → VÄNTA 2 dagar → BESLUT: har prenumeranten öppnat någon artikel från dessa ämnen? → JA-sökväg: lägg till i segmentet
active_subscribers, SLUT → NEJ-sökväg: skicka en push med frågan ”vad förde dig hit?” med en kuraterad sammanfattning av tre artiklar, SLUT - Avslutningskriterier: Inga. Välkomstserien bör köras till slutförande för alla som anmäler sig.
- Publicistmetrik: Andel återkommande besökare vid dag 7. Den andra kontakten för ämnespreferenser är det mest effektiva ögonblicket i välkomnandet — sidan exempel på pushmeddelanden för nyhetswebbplatser och publicister katalogiserar kopiamönster som fungerar för denna kontakt. För optimering av anmälan uppströms om detta arbetsflöde täcker inlägget öka din webbpush-anmälningsgrad mekaniken för prompten.
Mall 2 — Snabb utplacering av nyheter
- Utlösare (START): Anpassad händelse
breaking_news_verified(utlöst av redaktionellt CMS när en nyhet har passerat initial verifiering) - Körningstyp: Flera parallella (varje breaking news-artikel är en egen arbetsflödesinstans)
- Flöde: SPLIT_PATH 10/90 — 10 % av prenumerantuppsättningen som har valt ämne får pushen omedelbart som en ledande indikator; de återstående 90 % väntar 5 minuter → BESLUT: har nyhetsrummet utlöst händelsen
breaking_news_confirmedfrån instrumentpanelen efter att ha granskat 10 %-kohortens initiala svar? → JA-sökväg: HANDLING utlös push till de 90 % → NEJ-sökväg: HANDLING skicka en korrigerad push med en uppdaterad rubrik till de 90 %, SLUT - Kylningsregel: arbetsflödesnivå, verkställs via ett avslutningskriterium kopplat till ett prenumerantattribut
received_breaking_push_recently. Ingen andra breaking news-push till samma prenumerant inom 90 minuter. - Avslutningskriterier:
story_corrected(redaktionen drar tillbaka) ELLERreceived_breaking_push_recently=true - Publicistmetrik: Klickfrekvens för breaking news per ämne. Detta är arbetsflödet som löser avvägningen mellan hastighet och noggrannhet som varje nyhetsredaktion argumenterar om. 10 %-kohorten med ledande indikatorer ger redaktionen en realtidssignal utan att engagera hela prenumerantbasen. Grinden för redaktionell bekräftelse är en mänsklig kontroll, inte en automatisk klickfrekvensgräns — motorn väntar på att en redaktör ska bekräfta att artikeln har hållit sig innan den skickas till de 90 %. Arkitekturen matchar hur seriösa nyhetsredaktioner faktiskt verifierar breaking news-artiklar; arbetsflödet upprätthåller bara disciplinen.
Mall 3 — Uppföljning av artikel (en kedja med två arbetsflöden)
Uppföljning av artiklar är två sammankopplade arbetsflöden som är sammankopplade av ett segment, inte ett arbetsflöde med en öppen händelse-VÄNTAN. VÄNTAN-noder i arbetsflöden stöder tidsbaserade och datumbaserade väntningar men inte semantik för ”vänta tills händelse X utlöses”, så rullande artikelmönster komponeras som två arbetsflöden som delar tillstånd genom ett följarsegment.
Arbetsflöde A (prenumerera på artikel):
- Trigger (START): Anpassad händelse
article_readmedstory_idpayload - Körningstyp: Flera parallella
- Flöde: ACTION lägg till prenumerant i segmentet
story_X_followers→ SLUT
Arbetsflöde B (notera vid uppdatering):
- Trigger (START): Anpassad händelse
story_updateförstory_idOCH publikfilter segmentetstory_X_followers - Körningstyp: Flera parallella
- Flöde: BESLUT: är uppdateringen viktig eller en mindre ändring (drivs av ett fält
update_severitypå triggern, satt av redaktionella CMS)? → JA-sida: ACTION skicka push till alla följare → NEJ-sida: AVSLUT - Avslutningskriterier för båda arbetsflödena: Prenumerantnivå
unsubscribed_from_story_XELLER publiknivåstory_closed - Publicistmetrik: Sessioner per användare för pågående artiklar. Detta är publicistens motsvarighet till e-handelns övergivna kundvagnar — du vet vad prenumeranten läste, du håller dem uppdaterade medan artikeln utvecklas, och du avslutar när artikeln stängs eller de väljer bort.
Mall 4 — Konvertering av prenumeration / betalvägg
- Trigger (START): Anpassad händelse
paywall_meter_hit(prenumeranten har läst N gratis artiklar på 30 dagar och nått mätargränsen) - Körningstyp: Enkel per 90-dagarsperiod
- Flöde: VÄNTA 1 timme → mjuk push som nämner artikeln de nådde gränsen för → VÄNTA 2 dagar → BESLUT: prenumererade de? → JA: AVSLUT → NEJ-sida: push med 30 % rabatt på introduktionserbjudande → VÄNTA 5 dagar → BESLUT → JA: AVSLUT → NEJ-sida: slutlig push som presenterar medlemskapsnivåns fördelar och en 7-dagars provperiod → SLUT
- Avslutningskriterier: Mål
subscription_startedvid valfri nod - Publicistmetrik: Konverteringsgrad från betalvägg till betalande kund. Detta är publicistens mest försvarbara intäktsflöde — varje ytterligare 1 % konvertering vid en årstaxa på 80 USD med 50 000 månatliga mätarträffar är ungefär 40 000 USD i inkrementell ARR. Logiken för övergivna kundvagnar från PushEngages e-handelsmallbibliotek översätts direkt: byt ut
cart_abandonedmotpaywall_meter_hit, byt utpurchasemotsubscription_started, och väntetiderna kan hållas nära samma kadens. För mer om hur push- och in-app-ytor kompletterar varandra för konverteringsögonblicket, täcker push vs in-app notifications kanalsvalsmatematiken.
Mall 5 — Återaktivering av inaktiva läsare
- Trigger (START): Publikfilter
last_active > 14 days AND subscription_inactive - Körningstyp: Enkel (ett återaktiveringsförsök per prenumerant per 90-dagarsperiod)
- Flöde: Personlig push som visar tre toppartiklar från prenumerantens föredragna ämne (beräknat från läshistorik) → VÄNTA 5 dagar → BESLUT: har prenumeranten återvänt till webbplatsen? → JA-sida: lägg till i segmentet
re-engaged, AVSLUT → NEJ-sida: push med texten ”vi saknar dig” och en uppmaning att uppdatera ämne → VÄNTA 7 dagar → BESLUT: fortfarande inaktiv? → JA-sida: push med texten ”är detta fortfarande användbart?” och ett avregistreringsalternativ (Apples rekommenderade mönster för trötthetshantering) → SLUT - Umgångskriterier:
last_active < 7 dagar(prenumerant återvände på egen hand) - Publicistmetrik: Återaktiveringsgrad för bortfallna läsare efter 60 dagar. Pushwooshs studie från 2025 om nyhetsappar fann att fler pushar inte leder till fler klick förbi en trötthetströskel; arbetsflödet för återvinning respekterar det fyndet genom att erbjuda prenumeranten ett explicit avstående innan fler skickas.
En notering om triggern i Blueprint 5. Detta är den enda blueprinten här som använder en publikumsbaserad trigger snarare än en händelsebaserad trigger. Publikumstriggers batchbearbetas endast vid tidpunkten för arbetsflödets start — prenumeranter som blir inaktiva efter att arbetsflödet körs denna vecka inkluderas inte automatiskt i den aktiva instansen, och att redigera publikumfiltret på ett aktivt arbetsflöde lägger inte till nya prenumeranter. För ett rullande återvinningsprogram, duplicera arbetsflödet schemalagt varje vecka eller varannan vecka snarare än att förvänta sig att ett långvarigt publikumarbetsflöde fortsätter att ta emot nya bortfallna läsare.
Ämnessegmentering, A/B-testning, nedkylningar och avslutningskriterier finns inuti arbetsflödet
Det dominerande mönstret över publicisters push-artiklar är att lista dessa fyra koncept som "bästa praxis" — generiska punkter i slutet av ett strategipost, skilda från de kampanjer som använder dem. Det är fel ram. I verklig automatisering av push-notiser för nyheter är de inte bästa praxis som sitter bredvid arbetsflödet. De är arbetsflödet.
| Koncept | Bästa praxis-inramning (fel) | Arbetsflödesnod-inramning (korrekt) |
|---|---|---|
| Ämnessegmentering | ”Segmentera dina push-prenumeranter efter ämnesintresse” | En BESLUT-nod på topic_opted_in: sports som dirigerar en sportnyhet endast till sportprenumeranter, med separat dirigeringslogik för politik, affärer och lokalt. Pushwooshs studie från 2025 om nyhetsappar fann att sport-CTR presterar materiellt bättre än politik-CTR, vilket innebär att arbetsflödet för nyheter behöver olika nedkylningsregler och olika text per ämne. |
| A/B-testning | ”A/B-testa alltid dina rubriker” | En SPLIT_PATH-nod med 50/50-allokering, lastbalanserade prenumeranter per sökväg och ett fält för winner_edge_id som befordrar vinnaren till 100 % när testet når signifikans. |
| Nedkylningar | ”Spamma inte dina prenumeranter” | En regel på arbetsflödesnivå baserad på en prenumerantattributet received_breaking_push_recently som avbryter arbetsflödet om prenumeranten fick en annan push inom 90 minuter (eller vad din ämnesspecifika trötthetströskel är) |
| Avslutningskriterier | ”Stoppa betalväggskonverteringssekvensen när de prenumererar” | En regel på arbetsflödesnivå som kontrollerar prenumeranten mot målet subscription_started före varje nod och avbryter arbetsflödet om det matchar |
Skillnaden spelar roll eftersom punkter med bästa praxis är lätta att nicka åt och svåra att genomdriva. Arbetsflödesnoder genomdrivs av motorn. BESLUT körs varje gång. SPLIT_PATH balanserar varje prenumerant. Nedkylningsregeln blockerar den andra nyhetspushen utan att någon behöver komma ihåg att kontrollera tiden. Utgångsregeln avbryter betalväggskonverteringsarbetsflödet oavsett om kampanjägaren är uppmärksam eller inte.
För Blueprint 4:s konvertering av betalväggar innebär detta att i samma ögonblick som en gratis läsare prenumererar – vid timme 1, timme 50 eller timme 100 av resan – utlöses avslutningsregeln, arbetsflödet avbryts för den läsaren, och inga fler pushmeddelanden om ”du har en dag kvar att prenumerera” skickas till någon som redan betalade dig igår. Ingen support-e-post. Ingen klagomål från medlemmar till chefredaktören.
Orkestrering av flera kanaler: webb-push, app-push, nyhetsbrev och på webbplatsen
Publicister använder fler kanaler än e-handels-team eller SaaS-livscykel-team. Web push täcker läsare på dator och mobilwebb. App push täcker den kohort som laddade ner din nyhetsapp. E-postsammanfattning sammanfattar dagen eller veckan för prenumeranter som föredrar en längre ankomst i inkorgen. Nyhetsbrevsregistrering är den högre LTV-kanalen som publicister spenderar år på att växa. Bandannerrubriker på plats (ytor i sidan och meddelanden i chattstil) når läsare medan de redan är aktiva. Att komponera alla dessa inom ett arbetsflöde – istället för att köra fem frånkopplade kampanjer och sedan avstämma analyser – är skillnaden mellan ett publikutvecklingsteam som växer mätvärdet och ett som bara mäter det.
En komponerad uppföljningsresa för en artikel ser ut så här:
- START (Arbetsflöde B): händelse
story_updateOCH publikfilterstory_X_followers - BESLUT: är prenumeranten för närvarande på webbplatsen (webb eller mobilwebb)?
- JA: ÅTGÄRD skicka ett banner på sidan via chattkanalen (minst friktion; avbryt inte den aktuella sessionen med en push)
- NEJ: fortsätt
- BESLUT: är prenumeranten prenumererad på webb push?
- JA: ÅTGÄRD skicka en webb push
- NEJ: fortsätt
- BESLUT: har prenumeranten appen installerad och aktiv?
- JA: ÅTGÄRD skicka en app push
- NEJ: fortsätt
- ÅTGÄRD: HttpRequest till nyhetsbrevsplattformen (Mailchimp, Substack, Beehiiv, Sailthru) för att inkludera denna artikeluppdatering i nästa sammanfattningsutskick för denna prenumerant
- AVSLUT vid
unsubscribed_from_story_X
En prenumerantidentitet, ett arbetsflöde, fyra kanaler valda efter status. Den billigaste möjliga kanalen går först – banner på sidan om de är på plats, webb push om prenumererad, app push om app-aktiv, nyhetsbrevsinkludering som reserv som når prenumeranten var de än läser härnäst. Ytor i appen och på plats är det första steget här eftersom de når läsaren i det ögonblick med minst friktion under resan.
Att köra detta med separata verktyg innebär fyra synkroniseringar mellan plattformar, två segmenteringsmotorer som inte är överens om vem som räknas som anmäld till politik, och ingen enskild intäktsattribuering eftersom varje verktyg rapporterar sina egna mätvärden. Att göra det inom en arbetsflödesmotor innebär en prenumerantidentitet, en uppsättning beslutlogik och en trattrapport som visar var resan faktiskt bryts.
Ingen av de femton bästa sökresultaten för detta nyckelord beskriver ett arbetsflöde för flera kanaler för publicister som ett enda objekt. Varje resultat behandlar webb push som en kanal och e-post som jämförelse, med sociala medier och app push som separata angelägenheter. Inramningen med ett enda arbetsflöde är den arkitektoniska skillnaden.
Retentionsmatematiken: intäkter per arbetsflöde för annons- och prenumerationsutgivare
Förlagsmonetarisering delas på två sätt. Annonsmonetariserade förlag (de flesta lokala nyheter, de flesta traditionella tidningar, webbplatser av BuzzFeed-typ, annonsstödda livsstils- och underhållningssajter) mäter inkrementella sessioner per prenumerant och annons-RPM på arbetsflödesnivå. Prenumerationsförlag (NYT, WaPo, Atlantic, FT, Bloomberg, Substack-typ) mäter konverteringsgrad från betalvägg till betalande och ARR per arbetsflöde. Båda monetariseringsmodellerna mappas till PushEngage Workflows nodnivåanalys på samma sätt.
PushEngage Workflows spårar tre siffror vid varje nod:
- Köade användare: prenumeranter som för närvarande väntar vid denna nod (vanligtvis en WAIT eller en nedkylningsomplanering)
- Slutförda användare: prenumeranter som passerade genom denna nod
- Avslutade användare: prenumeranter som lämnade arbetsflödet vid denna nod, antingen för att avslutningskriterierna matchade eller för att de avslutade prenumerationen
Här är hur nodnivåanalys ser ut för ett aktivt arbetsflöde för betalväggskonvertering hos ett prenumerationsförlag med en årlig nivå på 80 USD och 50 000 månatliga meter-träffar (illustrativa siffror):
| Nod | Köad | Slutförd | Avslutad | Anteckningar |
|---|---|---|---|---|
| START (paywall_meter_hit) | 0 | 50,000 | 0 | Alla prenumeranter som träffat mätaren kommer in |
| VÄNTA 1 timme | 920 | 49,000 | 80 | 80 prenumererade innan den mjuka prompten aktiverades |
| ÅTGÄRD: mjuk prompt-push | 0 | 49,000 | 0 | Avisering skickad |
| VÄNTA 2 dagar | 1,100 | 45,800 | 2,100 | 2 100 prenumererade efter beröring #1 (4,3 % konvertering enbart vid beröring) |
| BESLUT: prenumererade | 0 | 45,800 | 0 | Förgrening |
| ÅTGÄRD: 30 % rabatt-push | 0 | 45,800 | 0 | Avisering skickad |
| VÄNTA 5 dagar | 640 | 44,200 | 960 | Ytterligare 960 prenumererade (2,1 % konvertering vid beröring #2) |
| ÅTGÄRD: medlemskapsnivå + provprenumerations-push | 0 | 44,200 | 0 | Sista beröring |
| SLUT | ej | 44,200 | ej | 44 200 prenumererade inte |
I denna kohort konverterade 3 140 gratis läsare till betalande prenumeranter av 50 000 meter-träffar — en konverteringsgrad från betalvägg till betalande på 6,3 % driven av arbetsflödets tre beröringar. Till en årlig nivå på 80 USD är det 251 200 USD i inkrementell ARR per kohort, eller ungefär 3,0 miljoner USD i årlig inkrementell ARR om den månatliga kohortstorleken håller sig. De två väntetiderna (48h och 120h) är de noder med högst avhopp i tratten, vilket är det förväntade mönstret. Om ditt arbetsflöde visar det omvända — höga avhopp vid åtgärdsnoder, låga avhopp vid väntetider — landar dina beröringar för sent och väntetiderna bör förkortas.
Kostnadsberäkningen följer samma form som artiklarna 1 och 2 i denna serie. Web push och app push har noll kostnad per sändning efter opt-in. Banders på sidan är noll. Kostnader för e-postdigest skalas med ESP-kontraktet — för en förlagslista med 500 000 prenumeranter kostar en enda digest-sändning vanligtvis några tusen dollar per beröring från Mailchimp eller Sailthru beroende på kontraktsnivå. Arbetsflödets uppgift är att använda den billigaste möjliga kanalen först och eskalera till e-post endast när tillståndet kräver det.
För annonsmonetariserade förlag omformuleras beräkningen. Metriken är inkrementella sessioner per prenumerant per månad, och arbetsflödets bidrag attribueras på nivån per avisering. En återkommande besökare som kommer tillbaka för att läsa tre ytterligare artiklar driven av ett arbetsflöde för artikeluppföljning bidrar med tre ytterligare visningsuppsättningar, som vid förlagets blandade RPM producerar inkrementell annonsintäkt per prenumerant per arbetsflöde. Pushwooshs studie från 2025 om nyhetsappar fann att fler pushar inte översätts till fler klick förbi en trötthetströskel — vilket direkt stöder regeln om nedkylning på arbetsflödesnivå från föregående avsnitt. När raden lyder ”arbetsflöde för artikeluppföljning lade till X sessioner per prenumerant och Y USD i annonsintäkt per prenumerant per kvartal”, är QBR-konversationen kort.
Bygg det i PushEngage Workflows för din nyhetsredaktion
Var och en av de fem publicistmallarna mappar direkt till PushEngage Workflows-komponenter. Mappningen:
| Ritning | Nodtyper som används | Åtgärdstyper som används | Arbetsflödesalternativ |
|---|---|---|---|
| Välkomstmeddelande till nya prenumeranter | START, VÄNTA, BESLUT, HANDLING, SLUT | SendPushNotification, AddSegment | Körningstyp: Enkel |
| Snabb utrullning av breaking news | START, SPLIT_PATH, WAIT, DECISION, ACTION, END | SendPushNotification | Körningstyp: Flera parallella; nedkylningsregel på arbetsflödesnivå |
| Arbetsflöde för uppföljning av artiklar A | START, ACTION, END | AddSegment | Körningstyp: Flera parallella |
| Arbetsflöde för uppföljning av artiklar B | START, BESLUT, ACTION, END | SendPushNotification | Körningstyp: Flera parallella; publikutlösare + anpassad händelseutlösare |
| Konvertering av prenumeration / betalvägg | START, VÄNTA, BESLUT, HANDLING, SLUT | SendPushNotification | Körningstyp: Enkel; avslutas vid mål subscription_started |
| Återaktivering av inaktiva läsare | START, HANDLING, VÄNTA, BESLUT, SLUT | SendPushNotification, AddSegment | Körningstyp: Enkel; publikbaserad utlösare |
Workflows-motorn levereras med 60+ färdiga mallar som täcker byggstenarna för var och en av dessa mallar. De flesta mallar är utformade för e-handel men kan enkelt översättas till publicistfall: logiken för mallen för övergiven kundvagn blir logik för betalväggskonvertering med cart_abandoned utbytt mot paywall_meter_hit och purchase utbytt mot subscription_started. Logiken för mallen för övergiven surf blir arbetsflödet för uppföljning av artiklar B med mönstret för segmentutlösare. Mallen för välkomstserier passar direkt för mall 1. Arkitekturen är vertikalt-agnostisk; utlösarhändelserna och avslutningsvillkoren är vad du byter när du anpassar en e-handelsmall för publicistbruk.
För den omedelbara provperioden ger gratisplanen dig 200 prenumeranter, alla kanaler (webb push, app push, WhatsApp för högprioriterade varningar, livechatt för banners på webbplatsen) och hela Workflows-motorn från dag ett. Det räcker för att driftsätta mall 1 (välkomst) och mall 2 (breaking news) på en testkohort, fånga analyserna och ha ett försvarbart antal för annonsdrift och medlemskap nästa vecka. För täckning av PushEngages webb push-kanal specifikt — publicistens primära leveransyta — täcker PushEngage webb push-meddelanden funktionsuppsättningen och plattformsstödet.
Vad detta förändrar
Om du tar med dig en sak från den här artikeln, ta detta: pushmeddelandeautomatisering för publicister är arbetsflödesarkitektur, inte RSS-sändningar med en inbyggd breaking-utlösare. Arbetsflödet för breaking news som begränsar 90% bakom en redaktionell bekräftelsehändelse, arbetsflödena för uppföljning av artiklar som kedjas via ett segment, och resan för betalväggskonvertering som avslutas i samma ögonblick som en gratis läsare prenumererar har alla samma form. En START, några WAITs, några DECISIONs, några ACTIONs, en EXIT. Tre fristående utlösare kan inte göra detta. En arbetsflödesmotor kan. Andelen återkommande besökare växer därifrån.
Börja med gratisplanen för att driftsätta den första mallen under din nästa breaking news-cykel.