Pushfrekvens: hur ofta ska en nyhetssajt skicka notiser?

Det ärliga svaret är att det beror på, och det användbara är vad det beror på.

Det finns inget publicerbart tal för hur ofta en nyhetssajt bör skicka pushnotiser. Den som citerar "två till fem om dagen för publicister" upprepar antingen en leverantörsblogg utan namngivet urval, eller snittar över sajter som inte har något gemensamt med er. Det som däremot finns, och som går att agera på idag, är ett tak webbläsaren upprätthåller, en budget era läsare håller, och en golvnivå satt av vad ett enskilt utskick faktiskt är värt.

Två frekvenser som blandas ihop

Nästan varje improduktiv diskussion om pushfrekvens kommer ur att de här två blandas ihop.

En redaktion som skickar 20 gånger om dagen där en typisk läsare tar emot två är en helt annan produkt än en som skickar fyra där varje läsare får alla fyra. Den andra är mer aggressiv, och utskicksvolymen på dashboarden säger motsatsen.

Frågan "hur ofta ska vi skicka" är alltså två frågor, och bara den andra har ett trötthetssvar. Sätt talet per prenumerant först. Sajtfrekvensen blir då ett redaktions- och målgruppsproblem i stället för ett förtroendeproblem.

Taket Chrome faktiskt upprätthåller

Den här delen är inte en åsikt, och inte en prognos. Den gäller sedan januari 2026.

Chrome började rulla ut rate limits för Push API för sajter som skickar många notiser med lite engagemang på sajten. En sajt som bedöms störande begränsas till lägst 1 000 meddelanden per minut, och överskjutande anrop får HTTP 429. Faktorerna Chrome namnger är push-meddelanden per tid på sajten, permission-frågor per tid på sajten, och engagemang mätt som site engagement score och minuter i förgrunden. Upptrappningen går en dag, sedan sju dagar, sedan fjorton, och läget nollställs efter 42 sammanhängande dygn utan störande beteende. Det gäller bara Push API, inte Notifications API. Chrome uppger att nästan alla webbplatser inte kommer att påverkas.

Separat gäller sedan oktober 2025 att Chrome automatiskt tar bort notistillstånd för sajter som en användare inte interagerat med på sistone, när engagemanget är mycket lågt och notisvolymen hög. Chrome informerar användaren, som kan ge tillstånd på nytt i Safety Check eller på sajten, eller stänga av auto-revokeringen. Installerade webbappar omfattas inte. Desktop och Android.

Två saker följer av det, och båda ändrar hur ni bör tänka på talet.

För det första: måttet som upprätthålls är en kvot, inte ett antal. Push-meddelanden per tid på sajten. Permission-frågor per tid på sajten. En sajt vars läsare stannar och kommer tillbaka har mer utrymme än en sajt med samma utskicksvolym och inget engagemang, vilket betyder att "hur många per dygn" är fel enhet och "hur många per enhet uppmärksamhet vi förtjänat" är rätt.

För det andra: begränsningen gäller per sajt, men auto-revokeringen gäller per person. En frekvens som ser bra ut i aggregat kan ändå tyst plocka bort tillstånd hos er minst engagerade tredjedel.

Ni kan inte räkna fram er position mot Chromes tröskel. Poängsättningen är inte publicerad, och att modellera den är gissningar. Sätt ert eget tak med god marginal innanför deras och sluta leta efter kanten.

Varför den här sidan saknar en branschtabell

Jag skulle kunna lägga in en tabell här med en rad per bransch och ett trovärdigt tal i. Den skulle ranka. Den skulle också vara påhittad.

Vi publicerar webbläsar- och marknadsfakta enbart från ett daterat claim-register med primärkälla, och det finns ingen godkänd källa för "nyhetssajter skickar X notiser per dygn". Leverantörsbloggarna som publicerar opt-in-tal och frekvenser per land namnger ingen nämnare, beskriver inget urval, och mäter mest sin egen kundbas. Teknikdetektering säger vilka sajter som kör en push-plattform, inte hur ofta de skickar.

Vi kör eget crawl-arbete på nordiska publicister. När det ger frekvenssiffror publiceras metoden och urvalet före talen. Till dess ger den här sidan ett ramverk, och ni får behålla ert eget resultat.

Ett ramverk för att hitta ert tal

1. Utgå från taket per prenumerant

Välj ett maximum en enskild person kan ta emot per dygn och per vecka. Välj det medvetet, skriv ner det, och låt det vara den begränsning allt annat arbetar innanför. Om redaktionen protesterar gör talet sitt jobb.

2. Sätt en värdegräns innan ni sätter ett antal

Vissa utskick bör inte gå ut vid någon frekvens alls. Definiera vad en artikel måste klara innan den blir en Nudge: en tröskel på innehållssäkerhet, en regel per artikeltyp, vad desken nu accepterar. Ett tak med utrymme kvar är ingen uppmaning att fylla det.

3. Skilj rutin från brådska, uttryckligen

Rutinutskick ligger innanför taket, respekterar tysta timmar och hoppar över vilande prenumeranter. Brådskande utskick får bryta taket genom en namngiven override som loggas. Loggas den inte blir allt brådskande inom en månad. Jag har sett det hända.

4. Styr på kvalitet per utskick, inte utskick per dygn

Talet som är värt att sätta på väggen är vad ett utskick kostar och ger, inte hur många ni hann med.

En användbar variant: ta interaktioner per 1 000 levererade, och dra ifrån avregistreringar och ogiltiga endpoints per 1 000 levererade. Det ger ett nettotal per utskick som sjunker när ni skickar en svag artikel till en bred publik, vilket är precis det beteende måttet ska bestraffa. Det här är vårt ramverk, inte en branschstandard. Ändra vikterna om er ekonomi ser annorlunda ut, men behåll subtraktionen, för ett mått utan kostnadsterm kommer alltid att argumentera för fler utskick.

5. Flytta ett steg i taget och håll kvar

Ändra taket per prenumerant med ett steg, håll det i två till fyra veckor, och följ nettoförändringen på listan: nya tillstånd minus avregistreringar minus ogiltiga endpoints. En variabel, tillräckligt länge för att listan ska hinna svara. Frekvensexperiment som körs i fyra dagar mäter nyhetsläget, inte er policy.

Delen som är specifik för publicister

Varje journalist vill att den egna artikeln pushas. Det är inte ett fel i redaktionen, det är redaktionen som fungerar, och varje enskild begäran är rimlig i sig.

Problemet är att den som äger publiken argumenterar mot en hög av var för sig rimliga begäranden, och det enda talet i rummet är klickantalet från förra utskicket. Klickantal argumenterar alltid för att skicka mer. Inget på en vanlig dashboard visar vad utskicket kostade i prenumeranter, så återhållsamheten kommer in med en åsikt och förlorar.

Det är skälet att föra en huvudbok per utskick redan innan ni ändrar någon policy. Klick, avregistreringar, ogiltiga endpoints och veckans nettoförändring, på en rad per utskick. Diskussionen blir aritmetik, och aritmetik är betydligt lättare att vinna med.

Begränsningar och webbläsarförbehåll

• Chromes rate limits gäller Push API, inte Notifications API, och Chrome uppger att nästan alla sajter inte påverkas. Använd dem inte för att skrämma någon till ett tal.
• Apples plattformar skiljer sig. Declarative Web Push kom i Safari 18.4 den 31 mars 2025 för webbappar på hemskärmen i iOS och iPadOS. Frekvenstolerans och signalerna ni får tillbaka är inte identiska med Chromes.
• Webbläsarmixen ändrar vad allt det här betyder för er. StatCounter rapporterade webbläsarandelar för juli 2026 som Chrome 68,22% och Safari 16,47% globalt, Chrome 60,71% och Safari 18,67% i Europa, och Chrome 57,37% och Safari 24,75% i Sverige. En frekvenspolicy anpassad efter Chromes beteende täcker olika stor del av er lista på olika marknader.
• Inget tal på den här sidan är en EngageNudge-mätning. Ramverket är vårt, webbläsarfakta är Chromes och WebKits, och andelarna är StatCounters, daterade ovan.

Så hanterar EngageNudge frekvens

Frekvens i EngageNudge är en policy utskicket måste klara, inte ett fält på kampanjen. Dags- och veckotak per prenumerant, minsta avstånd mellan Nudges, tysta timmar, viloregler och ett lågvärdesfilter utvärderas före leverans, och en Nudge som inte klarar dem hoppas över med skälet registrerat.

Under det ligger holdouts, så att frågan "kom någon faktiskt tillbaka tack vare det extra utskicket" har ett svar som inte är klickantalet.