Notiströtthet: så mäter du den och så minskar du den

Notiströtthet är en prenumerant som slutat läsa era notiser utan att berätta det.

Det är hela problemet i en mening. Ingen hör av sig och klagar. Tillståndet ligger kvar ett tag till. Utskicksvolymen ser likadan ut som förra månaden. Det som ändras är tystare: samma sorts artiklar får färre interaktioner, nya besökare tackar nej till frågan oftare, endpoints börjar fallera, och basen krymper de flesta veckor trots att inget i arbetsflödet har ändrats.

Vill du ha kortversionen av hur man minskar pushtrötthet: sätt tak på exponering per person i stället för per kampanj, och låt taket gälla före utskicket i stället för efteråt. Resten av den här sidan handlar om hur du vet om ni har ett trötthetsproblem, och vad ni faktiskt bör ändra.

Hur trötthet ser ut i data

Trötthet är inte ett tal. Den syns som fyra olika kurvor, och de rör sig i olika takt.

Avregistreringskurvan. Avanmälningar som klumpar ihop sig timmarna efter ett utskick. Det är den snabbaste signalen och den alla redan har. Den underskattar kraftigt, eftersom de flesta trötta prenumeranter aldrig klickar på avregistrera.

Nekandekurvan. Andelen besökare som tackar nej till er permission-fråga. Den stiger när varumärket lärt den bredare publiken att era notiser inte är värda något, och det är den enda kurvan som skadar rekryteringen i stället för behållningen. Web Almanacs PWA-kapitel för 2025, från en HTTP Archive-crawl i juli 2025, rapporterar att desktopanvändare ignorerar permission-frågan 78% av gångerna, med 16% acceptans på mobil. Det är beteende i en crawl, inte er sajt, men det är utgångsläget ni arbetar mot.

Ignoreringskurvan. Personer som fortfarande är prenumeranter, fortfarande tar emot, och inte har interagerat med de senaste fem, tio, tjugo meddelandena. Det är den verkliga trötthetspopulationen och nästan ingen push-dashboard visar den. Chrome uppger att mindre än 1% av alla notiser får någon interaktion alls från användare, vilket säger något om hur stor den gruppen är på webben som helhet.

Kurvan för tysta bortfall. Prenumerationer som försvinner utan avregistrering. Vissa är döda enheter och rensad webbläsardata. Vissa är webbläsaren som bestämmer åt läsaren.

Den sista är förändringen som gjorde trötthet till en leveransfråga i stället för en hövlighetsfråga.

Webbläsaren är numera en del av er trötthetspolicy

Tre saker har hänt, och de gäller redan. Inget av det här är en prognos.

I oktober 2025 började Chrome automatiskt ta 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. Användaren kan ge tillstånd på nytt i Safety Check eller på sajten, eller stänga av auto-revokeringen. Installerade webbappar omfattas inte av funktionen. Det gäller desktop och Android.

I januari 2026 började Chrome 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.

I augusti 2026 beskrev Chrome Security hela stacken som ett flerskiktat försvar: auto-revokering vid lågt engagemang och vid upprepade varningar om misstänkta notiser, beteendedetektering av samordnade nätverk, rate limits på FCM-sidan, och en förenklad tillståndsmodell med avregistrering i ett steg på Android. Användare granskar borttagna tillstånd i Safety Hub.

Läs faktorlistan för rate limits en gång till, för det är den mest användbara mening någon webbläsarleverantör publicerat i ämnet. Faktorerna är kvoter. Inte meddelanden per dygn, utan meddelanden per enhet uppmärksamhet ni faktiskt förtjänat. En sajt vars läsare stannar och kommer tillbaka har mer utrymme än en sajt med samma utskicksvolym och inget engagemang.

Vad ni inte kan göra är att räkna baklänges till tröskeln. Chrome publicerar inte sin interna poängsättning, och den som påstår sig spegla den gissar. Behandla webbläsaren som en yttre gräns och lägg er egen policy med god marginal innanför.

Så mäter du trötthet på er egen lista

Det här är en procedur, inte ett facit. Den använder data ni redan har i vilken push-leverantör som helst plus er analys, och första versionen kan vara igång på en vecka.

1. Bestäm nämnaren

Definiera en aktiv prenumerant uttryckligen: en giltig endpoint som fått minst ett meddelande de senaste 30 dagarna och inte returnerat ett permanent fel. Skriv ner definitionen. De flesta diskussioner om listans storlek är egentligen diskussioner om två olika nämnare.

2. Bygg en huvudbok per utskick

För varje utskick, registrera: behörig målgrupp, levererade, interaktioner, avregistreringar inom 24 timmar, och endpoints som togs bort som ogiltiga inom 24 timmar. Fem tal per rad. Leverantören har fyra av dem; det femte kräver oftast felloggen från leveransen.

3. Bygg en exponeringsräknare per prenumerant

Håll två heltal per prenumerant: meddelanden mottagna senaste 7 dagarna, och antal meddelanden i rad utan interaktion. De två talen är hela den trötthetsmodell som spelar roll, och det är precis dem de flesta plattformar inte sparar.

4. Dela upp listan efter ignoreringsstreak

Gränserna är en utgångspunkt för ett test, inte ett uppmätt facit. Det som spelar roll är att ni delar upp listan över huvud taget, eftersom ett genomsnitt för hela listan döljer formen helt.

5. Följ nettoförändringen varje vecka

Nya tillstånd, minus avregistreringar, minus borttagna ogiltiga endpoints. Rita den per vecka mot utskicksvolymen. Om linjen är negativ de veckor volymen är hög och positiv de veckor volymen är låg har ni ert svar, och ni har det i en form som en redaktör accepterar.

En ärlig brasklapp: ingen webbläsare talar om vilket bortfall som var en auto-revokering. Ni ser att en endpoint returnerar ett permanent fel, och orsaken är antagen, inte rapporterad. Presentera inte antagna orsaker som uppmätta.

Vad som faktiskt minskar trötthet

Frekvenstak per prenumerant. Ett sajttak på åtta utskick per dygn säger ingenting om personen som fick alla åtta. Sätt tak på vad en person tar emot per dygn och per vecka. Den enda ändringen gör oftast mer än allt annat på listan.

Ämnes- och artikeldedupe. Samma artikel som når en läsare två gånger under två rubriker är den mest onödiga formen av trötthet som finns. Deduplicera på innehållet, inte på kampanjraden, och lägg till en nedkylning per ämne så att en pågående nyhet inte äter upp läsarens hela vecka.

Tysta fönster. Rutinutskick respekterar ett lokalt sändningsfönster med riktig tidszon. Nattleverans köper lite räckvidd och mycket irritation, och är den snabbaste vägen till att någon stänger av hela kanalen.

Vila vid ignoreringsstreak. Sluta skicka till dem som ignorerat de senaste meddelandena, och låt dem behålla prenumerationen medan ni gör det. En vila är ett beslut. Det är inte en misslyckad kampanj, och den skyddar ett tillstånd ni redan betalat för att få.

En värdegräns. Vissa utskick bör inte ske vid någon frekvens alls. Är innehållet svagt är rätt antal mottagare noll, och ett tak med utrymme kvar är inget skäl att fylla det.

En uttrycklig override. Breaking news behöver kunna gå förbi policyn. Gör det till ett namngivet och loggat beslut i stället för ett allmänt undantag, annars blir varje artikel breaking news inom en månad.

Trötthet hör hemma före utskicket, inte i en rapport

De flesta push-verktyg lägger trötthet i analysfliken. Ni skickar, och sedan får ni veta vad det kostade. Då är tillståndet redan borta, och kostnaden för att ersätta det är verklig.

Varianten som fungerar behandlar trötthet som en policy utskicket måste klara. Tak per prenumerant, minsta avstånd, tysta timmar, viloregler och en värdegräns utvärderas vid sändning, mottagare som inte är behöriga tas bort före leverans, och skälet registreras så att någon kan ifrågasätta det i efterhand. Den sista delen betyder mer än den låter. På en redaktion förlorar återhållsamhet varje diskussion den inte kan visa siffror för.

Vill ni skriva ner det här i ett portabelt format är Open Attention Policy ett öppet JSON-format för exakt de fälten, med en MIT-licensierad validator. Det fungerar mot vilken leverantör som helst, även en som inte är vår.

Begränsningar och webbläsarförbehåll

• Apples plattformar beter sig annorlunda. Declarative Web Push kom i Safari 18.4 den 31 mars 2025 för webbappar på hemskärmen i iOS och iPadOS, med en standardiserad JSON-payload och utan installerad service worker. Interaktionssignalerna från de prenumeranterna är inte identiska med Chromes, så slå inte ihop dem i en trötthetsmodell utan att kontrollera.
• Chromes rate limits gäller Push API, inte Notifications API. Lokalt utlösta notiser är en annan yta.
• Det finns inget API som över webbläsargränserna talar om varför en prenumeration tog slut. Tysta bortfall är antaganden.
• Varje webbläsarsiffra på den här sidan kommer från Chrome, WebKit eller HTTP Archive, daterade ovan. EngageNudge har inte publicerat något eget trötthetsfacit, och vi tänker inte hitta på ett för att sidan ska se auktoritativ ut.

Så gör EngageNudge

EngageNudge utvärderar trötthetspolicyn innan en Nudge går ut, inte efteråt. Dags- och veckotak för exponering, minsta tid mellan Nudges, signaler för ignoreringsstreak, skydd för vilande läsare, nedkylning per ämne, tysta timmar och en uttrycklig override för breaking news är alla indata till ett enda beslut om att skicka eller hoppa över, och ett skip registreras som ett beslut i stället för ett fel.

En publik reputation-score och full churn-forensik ligger på roadmap och finns inte live idag. Det som finns nu är policylagret och målgruppsvyn bakom det.