2026-års nedslagning af notifikationer: bliver dine push-notifikationer stadig leveret?

Et sted inden for de sidste atten måneder stoppede platformene med at bede afsendere om at opføre sig ordentligt og begyndte at håndhæve det. Chrome begrænser nu hastigheden på websteder, det klassificerer som forstyrrende, og tilbagekalder lydløst meddelelsesgodkendelse fra websteder, som brugerne ignorerer. Android 16 dæmper meddelelsesudbrud som standard, grupperer alt med magt og på nyere Pixel-telefoner placeres salgsfremmende skub i en kollapset, lydløs pakke. Google Beskeder begrænser, hvor mange nye brugere en RCS-afsender med lavt omdømme overhovedet kan nå. Hvis du søgte på "chrome notification crackdown" eller "why are my push notifications not delivered", er denne side referencepunktet: enhver ændring, den primære kilde bag den, hvem det rammer, og de specifikke løsninger, der sikrer, at en afsender leverer.

Dette er et levende dokument. Vi opdaterer det, når en platform udgiver eller annoncerer en ændring, og hver revision logges i ændringsloggen nederst. Sidst opdateret: 17. august 2026.

En indledende bemærkning før detaljerne, fordi den forklarer hver post i tabellen nedenfor. Ingen af disse platforme dræber meddelelser. Alle af dem opdeler meddelelser i to klasser: meddelelser med højt volumen og lavt engagement bliver droslet, dæmpet, bundtet eller afmeldt – mens relevante, hændelsesdrevne meddelelser bevarer fuld levering, og i nogle tilfælde får bedre placering end før. Nedlukningen er ikke mod push. Den er mod masseudsending.

Hvad der ændrede sig: tidslinjen for nedlukningen af meddelelser i 2026

Platform	Ændring	Hvem der påvirkes	Effektiv	Kilde
Chrome (desktop + Android)	Dæmpet UI for tilladelser: dæmpet prompt for brugere, der normalt blokerer, og for websteder med lave acceptrater for prompts; senere udvidet til websteder med misbrugende prompts eller indhold	Websteder, der prompt'er ved første sidevisning eller sender vildledende indhold	Chrome 80, feb. 2020 (håndhævelse udvidet gennem 2020)	Chromium blog
Safari / iOS	Deklarativ Web Push: web push uden en service worker, ingen straf for lydløs push for deklarative payloads	Web push-afsendere, der målretter mod Apple-brugere	iOS/iPadOS 18.4 (marts 2025); Mac i Safari 18.5 (maj 2025)	WebKit blog
Chrome på Android	On-device ML flagger mistænkelige web push-meddelelser som "muligvis vildledende eller spam" med et enkelt tryk til afmelding	Afsendere, hvis meddelelseskopimønster matcher spam	Maj 2025	Chromium blog
Android 16	Meddelelsesnedkøling (udbrud bliver gradvist dæmpet, slået til som standard) og tvungen gruppering af enhver apps meddelelser	Afsendere af apps med høj frekvens; udbrud af enhver art	Stabil 10. juni 2025	Android Authority; vores dybdegående analyse
Chrome (desktop + Android)	Automatisk tilbagekaldelse af meddelelsesgodkendelse via Safety Check for websteder med lavt engagement og højt volumen	Websteder, der sender mange meddelelser, som brugerne aldrig klikker på	Annonceret 10. okt. 2025; udrulning	Chromium blog
Google Beskeder	Gruppering af "Ukendte afsendere"; verificerede forretningsmærker og standardiseret branding for RCS	Virksomheder, der sender beskeder til brugere, som ikke har gemt dem	Fra midten af okt. 2025 (udrulning)	Android Authority
Android 16 QPR2 (Pixel)	Notifikationsorganisator: AI på enheden sorterer "Tilbud" og "Nyheder"-notifikationer i en standard, kollapset bunke; AI-resuméer for samtaler	Push-beskeder fra tilbudsapps på nuværende Pixels (6 lande, engelsk)	Dec 2025	9to5Google
Chrome (desktop + Android)	Push API-ratebegrænsninger: websteder klassificeret som forstyrrende begrænset til 1.000 push-beskeder/minut med HTTP 429 derover; 1 → 7 → 14-dages straffestige	Afsendere med højt volumen og lavt engagement pr. bruger	Udrulning fra jan. 2026	Chrome for udviklere
RCS for virksomheder	Reputationsbaserede trafikbegrænsninger: unikke brugergrænser pr. rullende 28 dage for salgsagenter med lavt omdømme (live i Indien; nye agenter starter med lavt omdømme); analyse af spam-tendenser og afmeldingsårsager	Salgs-RCS-afsendere, især nye agenter	7. jan. / 16. feb. / 1. apr. 2026	Udgivelsesbemærkninger for RCS for virksomheder

Nu detaljerne pr. platform, i den rækkefølge de vises på dit dashboard.

Chrome: ratebegrænsninger, automatisk tilbagekaldte tilladelser og ML spam-screening

Chrome er der, hvor de fleste retention-teams mærker nedslaget først, fordi web push er den mest volumen-baserede ejede kanal, som de fleste e-handelsbrands kører. Tre separate mekanismer er nu live, og de forstærker hinanden.

Push API-ratebegrænsninger for "forstyrrende" websteder

Siden januar 2026 har Chrome dagligt evalueret hvert websted ud fra tre faktorer: push-beskeder sendt pr. tid brugerne tilbringer på webstedet, tilladelsesprompter vist pr. tid på webstedet, og brugerens engagementniveau med webstedet (site engagement score plus forgrundsminutter). Et websted, der fejler testen, klassificeres som forstyrrende og begrænses til 1.000 push-beskeder pr. minut. Alt over grænsen får en HTTP 429-respons fra push-tjenesten.

Straffen eskalerer. Den første forstyrrende dag giver en 1-dages grænse. En anden på hinanden følgende dag udvider den til 7 dage. Fra den tredje dag og fremefter løber grænsen 14 dage ad gangen – og tælleren nulstilles først efter 42 sammenhængende dage med ren adfærd. Google har ikke offentliggjort et Chrome-versionsnummer for udrulningen; mekanismen evalueres på serveren og ankom stille.

Lav regnestykket mod din egen liste. Ved 1.000 beskeder pr. minut tager en udsendelse til 500.000 abonnenter mere end otte timer at fuldføre. En flash-sale push, der skulle lande på femten minutter, lander nu over en hel arbejdsdag, og indtjeningsvinduet, den skulle have ramt, er væk. Det er den faktiske pris: ikke et forbud, men en nedbrydning – dine indtægter fra genfundne kurve og dine click-to-revenue-tal udhules, mens dit leveringsdashboard stadig siger "sendt."

Bemærk omfanget. Begrænsningen gælder kun for den bagvedliggende Push API; notifikationer, der sendes fra en åben fane via Notifications API, påvirkes ikke. Googles egen formulering er, at “næsten alle websites vil være upåvirkede” — målet er den lille gruppe af afsendere, der sender et stort antal beskeder til et publikum, som er holdt op med at reagere. Om du er i den gruppe, er et målbart spørgsmål, og selv-auditten herunder gennemgår det.

Automatisk tilbagekaldelse af tilladelse

Den anden mekanisme fjerner abonnenter, som du troede, du ejede. Meddelt den 10. oktober 2025, tilbagekalder Chromes Sikkerhedstjek nu automatisk notifikationstilladelse fra websites, der kombinerer meget lav brugerengagement med et højt antal sendte notifikationer — den samme behandling, som den allerede anvendte på ubrugte kamera- og placeringstilladelser. Chromes produktteam begrundede det med ét tal: mindre end 1 % af alle notifikationer modtager nogen interaktion fra brugere.

Detaljerne, der betyder noget for en afsender:

• Installerede webapps er undtaget. En abonnent, der har tilføjet dit website til deres startskærm eller skrivebord, beholder tilladelsen.
• Brugeren får besked, når Chrome fjerner en tilladelse, og kan gendanne den via Sikkerhedstjek eller ved at besøge dit website igen og tilmelde sig igen.
• Google rapporterede, at notifikationsoverbelastningen i test faldt markant med “kun en minimal ændring i det samlede antal notifikationsklik” — og at websites, der sendte lavere mængder, så klikraterne stige.

Læs det sidste punkt igen, for det er hele nedslaget i én sætning. Klikkene var aldrig i halen af listen. Websites, der sendte mindre, tjente mere per afsendelse. Chrome håndhæver nu den listehigiejne, som højtydende afsendere allerede praktiserede: dit inaktive segment er ikke længere et forfængelighedstal på abonnenttælleren, det er en forpligtelse, der udløser håndhævelse.

Google har ikke offentliggjort de numeriske tærskler for “lavt engagement” eller “højt antal”, så ingen leverandør kan love dig et sikkert loft. Hvad du kan kontrollere, er det forhold, som systemet tydeligvis måler: interaktioner per leveret notifikation.

On-device ML-screening på Android

Den tredje mekanisme, live siden maj 2025, placerer en machine learning-model mellem din notifikation og brugerens øjne. Chrome på Android analyserer indkommende web push-indhold på enheden (web push er end-to-end-krypteret, så analysen skal være lokal — modellen læser titlen, brødteksten og handlingsknap-etiketterne). Notifikationer, der matcher mønstre af bedrag eller spam, vises med en advarsel og en afmeld-mulighed med ét tryk.

De kopivaner, der udløser spam-klassifikatorer, er dem, som lavkvalitetsafsendere læner sig op ad: falsk hast, clickbait-huller, vildledende systemmeddelelsesstyling. Hvis din notifikationstekst kunne forveksles med en præmiesvindel-skabelon, sendes den på nogle telefoner nu med et advarselsmærke og en udgangsdør vedlagt.

Hvad Chromes historie fortæller dig om, hvad der kommer næste gang

Intet af dette er et sidespring. Chrome dæmpede tilladelsesprompten for websteder med lav accept i februar 2020, og udvidede derefter håndhævelsen til at omfatte misbrugsaf prompts og misbrugsaf indhold senere samme år. Bølgen i 2025-2026 flytter håndhævelsen fra opt-in-øjeblikket til selve afsenderrelationen. Retningen har været ensrettet i seks år: hver udgivelse gør engagementet mere bærende. Planlæg med, at tærsklerne strammes, ikke løsnes.

Android 16: nedkøling, tvungen gruppering og den lydløse Promotions-bundle

Androids ændringer rammer app-push frem for browseren, og de ændrer, hvad "leveret" betyder, snarere end om levering sker.

Notifikationsnedkøling, som blev aktiveret som standard, da Android 16 blev stabil den 10. juni 2025, sigter mod bursts. Den første notifikation i en burst alarmerer med fuld lydstyrke og et fuldt banner; hver efterfølgende inden for cirka et minut bliver gradvist mere stille og visuelt minimeret, og burst'en kollapser under et enkelt banner. Opkald, alarmer og prioriterede samtaler er undtaget; marketing- og transaktionspushes er det ikke. Intet slettes, og leveringsrapporter flyttes ikke – hvilket netop er grunden til, at ændringen er farlig. Dit dashboard viser tre leverede; brugerens telefon præsenterede én. Vi udgav en fuld gennemgang af mekanismerne og rettelserne til afsenderdesignet i vores Android 16 notifikationsnedkølingsguide.

Tvungen gruppering fjerner et valg, som udviklere plejede at have: Android 16 samler alle notifikationer fra samme app, uanset om appen har tilmeldt sig eller ej. Kombineret med nedkøling er den anden og tredje push i en hvilken som helst hurtig sekvens nu stille, kollapsede linjeelementer snarere end bannere.

Notifikationsorganisatoren er den skarpeste af de tre. Den rulles ud siden december 2025 med Android 16 QPR2 på Pixel 9 og 10-serie telefoner (9to5Google), den bruger en on-device model til at klassificere notifikationer i Promotions, News, Social og Suggested — og Promotions- og News-kategorierne er aktiveret som standard, og placerer matchende notifikationer i en kollapset bundle i skyggens lydløse sektion. Udrulningen er snæver i dag (nyere Pixels, seks lande, engelsk), men standarden betyder noget: på de enheder, Google fuldt ud kontrollerer, summer en salgsfremmende push ikke længere, bannerer ikke længere, og sidder foldet, indtil brugeren leder efter den. Sammen med den komprimerer on-device AI-resuméer samtalenotifikationer.

Den samme OS-cyklus byggede også den modsatte bane. Android 16's fremskridtsorienterede notifikationer (Live Updates-mønsteret) giver ægte live, bruger-sporede begivenheder — en levering på vej, en ordrestatus — vedvarende, forhøjet placering. Googles udgivelser i 2026 har fortsat med at udvide denne live-indholds-bane, selvom detaljer om, hvad der udgives ud over Android 16, stadig er under afklaring og værd at tjekke mod de aktuelle Android-udgivelsesnoter, før du bygger til dem. Designintentionen er allerede utvetydig: indhold, som brugeren aktivt sporer, bliver promoveret; indhold, som afsenderen ønsker, at brugeren skal bemærke, bliver organiseret væk.

Under OS-laget gælder Firebase Cloud Messaging's langvarige grænser pr. enhed stadig — 240 beskeder pr. minut og 5.000 pr. time til en enkelt enhed, med vedvarende afsendere tæt på grænsen, der risikerer et misbrugsflag. Hvert system, som din virksomhed kører mod den samme app, deler dette budget.

iOS og Safari: en mere stille form for port

Apples historie i 2025-2026 er mindre en indskrænkning end en kontrolleret åbning, fordi Apple byggede sine porte ind fra starten: web-push på iOS har altid krævet, at brugeren først tilføjer dit websted til deres startskærm (et bevidst filter med høj intention, på plads siden iOS 16.4), og App Store-politikken har længe begrænset marketing-push.

Hvad der ændrede sig:

• Deklarativ Web Push blev udgivet i iOS/iPadOS 18.4 i marts 2025 og nåede Mac i Safari 18.5 (WebKit). Det giver dig mulighed for at køre web-push fra en standardiseret JSON-nyttelast uden en service worker, og det fjerner straffen for stille push for deklarative beskeder, fordi selve nyttelasten garanterer en synlig notifikation. Ældre service worker-push fungerer stadig; det deklarative format er den fremadrettede vej, Apple ønsker, at afsendere skal følge.
• iOS 26 indstiller angiveligt Home Screen-websteder til at åbne som webapps som standard, hvilket udvider overfladen, hvor iOS web-push kan køre. Vi har kun set dette dokumenteret indirekte indtil videre; betragt det som retningsgivende, indtil Apples dokumentation er eksplicit.
• Politikken er uændret og streng. App Review Guideline 4.5.4 kræver stadig, at push ikke er påkrævet for, at din app kan fungere, ikke indeholder følsomme personlige data, og — for kampagner eller direkte markedsføring — kun sendes til brugere, der eksplicit har tilmeldt sig gennem samtykkesprog i din apps brugergrænseflade, med en in-app afmelding. Misbrug "kan resultere i tilbagekaldelse af dine privilegier."

For et retention-team er konklusionen for iOS, at Apple har forfiltreret din målgruppe for dig. En iOS web-push-abonnent valgte at installere dit websted; en app-push-abonnent valgte at tilmelde sig markedsføring. Begge lister er små og med høj intention — hvilket betyder, at det er dyrere pr. abonnent at brænde dem med hyppige udsendelser end andre steder.

RCS: ry-grænser ankommer på den nyeste kanal

Hvis du tilføjer RCS eller WhatsApp til din blanding — og til genfinding af indkøbskurve og ordreopdateringer bør du evaluere beskedkanaler — har Google allerede installeret håndhævelseslaget, som web push tog seks år at få.

Ifølge Googles RCS for Business-dokumentation har hver virksomhedsafsender (agent) et omdømme — Høj, Mellem eller Lav — drevet af brugerfeedback og spamrapporter, og alle nye agenter starter Lavt. Omdømme sætter en trafikgrænse: antallet af unikke brugere, agenten kan initiere samtaler med pr. rullende 28 dage. Svar på samtaler, som brugeren startede, er undtaget. Håndhævelse blev live for salgsagenter i Indien den 7. januar 2026, strammet den 1. april 2026 med en tværgående agentgrænse for afsendere med lavt omdømme, og udviklerkonsollen rapporterer nu omdømmeniveau, trafikgrænse, spamtrend og afmeldingsårsager over 7- og 28-dages vinduer.

For forbrugeren har Google Beskeder grupperet beskeder fra usikrede afsendere under "Ukendte afsendere" siden midten af oktober 2025 og udruller verificerede flueben og standardiseret virksomhedsbranding — nedbrydningsstadiebeviser på nogle detaljer, men retningen matcher alt andet i dette dokument. På RCS får du ingen nådeperiode til at opbygge dårlige vaner: rækkevidde opnås ved engagement fra første besked.

Er du i fare? Selv-revisionen {#self-audit}

Chrome og Google offentliggør faktorerne, men ikke tærsklerne, så den ærlige revision er relativ: mål, om du ligner afsenderen, som disse systemer blev bygget til at stoppe. Kør disse otte tjek mod dine sidste 30 dages afsendelser. Hvert "nej" er en fundenhed. Flere af disse tjek giver kun mening mod eksterne numre, så kør dem sammen med vores push-notifikationsbenchmarks for 2026, hvor percentilspredningerne for visningsrate og klikrate viser dig, hvad den mediane, p75 og p90 afsender faktisk rammer.

1. Interaktionsforhold. Er din web push-klikrate meningsfuldt over økosystemets interaktionsbaseline på under 1%, som Chrome citerede, da det begrundede auto-tilbagekaldelse? Hvis din CTR har et nul efter decimaltegnet, er du inden for profilen, som Chrome håndhæver imod.
2. Volumen vs. besøg. Chromes første disruptive-site-faktor er pushes sendt pr. tid brugt på siden. Sender du flere notifikationer til en typisk abonnent pr. uge, end den abonnent har sessioner med dig pr. uge? En abonnent, der besøger månedligt og modtager daglige pushes, fejler dette forhold.
3. Inaktiv hale. Hvilken andel af din liste har ikke klikket på nogen notifikation i 90 dage? Hvis mere end halvdelen af dine afsendelser går til den hale, bliver din samlede engagementrate bestemt af folk, der allerede er gået — og platformene bedømmer det samlede.
4. Prompt-disciplin. Anmoder du om tilladelse til notifikationer ved første sidevisning, før den besøgende har foretaget sig noget? Prompt-acceptrate er både et kriterium for tilmelding til et stille UI og en faktor for forstyrrende websteder. At anmode om det efter en demonstreret handling (anden sidevisning, tilføjelse til indkøbskurv, oprettelse af konto) er løsningen, og det afspejles direkte i din tilmeldingsrate.
5. Masseafsendelse. Hvilken procentdel af dit månedlige afsendelsesvolumen er utargeterede masseafsendelser til hele listen, kontra notifikationer udløst af noget, modtageren gjorde (forladt indkøbskurv, pris faldet, vare tilbage på lager, ordre afsendt)? Over cirka halvdelen masseafsendelse, er du volumen-tung i præcis det mønster, som alle mekanismer på denne side straffer.
6. Frekvensbegrænsninger og stille timer. Håndhæver du en grænse pr. abonnent på tværs af alle kampagner og systemer, der kan sende – marketing, transaktionelle, RSS og ethvert andet værktøj? Androids nedkøling og tvungne gruppering betyder, at ukoordinerede afsendere nu synligt kannibaliserer hinanden på samme enhed.
7. Kopihonesthed. Ville nogen nylig notifikation overleve en skeptisk læsers test af “er dette vildledende?” – ingen falsk hast, ingen forklædning som systembesked, ingen lokkemad? Chromes klassifikator på enheden kører allerede den test på Android.
8. Trend for afmeldte. Er din afmeldingsrate pr. afsendelse flad eller faldende? På RCS føder den nu en omdømmerating med en hård trafikbegrænsning knyttet til; på web push er det din tidlige advarsel. Vores guide til at reducere afmeldingsrater for push-notifikationer dækker diagnosen i dybden.

Bedøm dig selv ærligt. Fem eller flere rene svar, og nedslaget er mest en medvind for dig – dine konkurrenters spray-and-pray bliver droslet, mens dine afsendelser fortsat lander. Tre eller flere fund, og du bør antage, at du allerede mister rækkevidde, som du ikke kan se i en leveringsrapport.

Compliance-playbooken: rettelser, der holder

Hver mekanisme ovenfor måler den samme underliggende mængde – værdi pr. notifikation – så rettelserne konvergerer. Disse seks træk, i prioriteret rækkefølge.

1. Skær den inaktive hale af, før platformene gør det for dig. Byg et segment af inaktive (intet klik i 90 dage), kør en ærlig genaktiveringssekvens igennem det, og stop derefter med at sende til dem, der ikke reagerer. Dette er kontraintuitivt for teams, der betragter listestørrelse som KPI'en, men matematikken er ensrettet nu: en sovende abonnent bidrager med nul indtægt og forringer aktivt engagementforholdet, som Chrome scorer dig på. I PushEngage vedligeholder dynamisk segmentering den inaktive pulje automatisk, og da prissætningen kun tæller aktive abonnenter, reducerer trimning af dødvægt din regning snarere end din rækkevidde.

2. Skift sendvolumen fra udsendelser til triggere. En vogn-forladt push, en pris-falds-advarsel, en besked om, at varen er tilbage på lager – disse giver klik, fordi modtagerens egen adfærd planlagde dem. At flytte blot halvdelen af din månedlige volumen fra kalenderstyrede udsendelser til triggere kampagner øger din interaktionsrate på alle faktorer, Chrome måler, og det er alligevel her, indtægten var: triggere sender bidrager til gendannede vogne og afsluttede ordrer, ikke visninger. Vi fremlagde hele argumentet, med kampagneklassifikationsdefinitionerne og indtægt-per-send-regnestykket, i hvorfor udsendelsesæraen netop er slut.

3. Segmentér alt, der stadig udsendes. Nogle udsendelser går legitimt bredt – et udsalg i hele butikken, en udgivers breaking news. Bred er ikke det samme som ussegmenteret. Opdeling af en udsendelse efter adfærd, købshistorik eller kategori-affinitet øger klikraten på hver del og holder hver abonnents personlige push-per-besøg-rate forsvarlig. Segmentering er nu et leveringskrav, ikke en personaliserings-behagelighed – det indlæg indeholder hele leveringsargumentet.

4. Håndhæv én frekvensgrænse på tværs af alle kanaler og systemer. Android 16's nedkøling gjorde dette konkret: din CRM, dit transaktionslag og din promo-kalender deler ét opmærksomhedsbudget på enheden, uanset om de deler et dashboard eller ej. Indstil en grænse pr. abonnent og stille timer på platformsniveau, der spænder over web push, app push og WhatsApp sammen, så fire rimelige systemer ikke kan sammensættes til et misbrugsmønster. Dette virker kun, hvis én segmenteringsmotor ser hver udsendelse – det stærkeste praktiske argument for at konsolidere kanaler frem for at køre ét værktøj pr. kanal.

5. Ret øjeblikket for opt-in. Flyt tilladelsesprompten bag en handling, der signalerer hensigt, brug en to-trins prompt, så browser-niveau-forespørgslen kun udløses ved et ja, og accepter den mindre, renere liste. Prompt-acceptrate påvirker Chromes scoring i begge ender – stille UI-tilmelding og evalueringen af forstyrrende websteder – og en samtykkende liste er også simpelthen den liste, der klikker.

6. Lad teksten overleve en klassifikator. Ærlige påstande, reel hast kun når deadline er reel, afsenderidentitet tydelig. På Android læser en ML-model din titel og brødtekst, før brugeren gør det. Ærlig tekst var altid en bedre praksis for fastholdelse; nu er det også et leveringskrav.

Hvis du kører disse seks på PushEngage, er den ærlige opsummering af, hvor produktet hjælper: triggere kampagner, RFM- og adfærdssegmenter, frekvensgrænser på tværs af kanaler, stille timer og indtægtsattribution pr. notifikation er alle indbygget, på planer, der kun fakturerer for aktive abonnenter – prismodellen peger tilfældigvis i samme retning, som platformene nu håndhæver. Hvad intet værktøj kan gøre, er at beslutte at stoppe med at udsende; den del er politik, og den er din.

Ofte stillede spørgsmål

Hvorfor leveres mine push-notifikationer ikke i 2026? Tjek fire mistænkte i rækkefølge. Først, Chromes auto-tilbagekaldelse: hvis dine abonnentantal stille svinder ind, kan abonnenter med lavt engagement miste tilladelsen via Sikkerhedstjek. For det andet, Chrome-ratebegrænsninger: hvis afsendelser til store lister pludselig tager timer, eller din push-tjeneste logger HTTP 429-svar, er du sandsynligvis blevet klassificeret som forstyrrende. For det tredje, Android-præsentation: på Android 16 sker levering stadig, men bursts dæmpes og grupperes, og på nyere Pixels lander promoverende pushes i en lydløs bundt – leveret, uset. For det fjerde, de kedelige årsager, der går forud for nedslaget: udløbne abonnementer, service-worker-fejl og OS-niveau notifikationsindstillinger.

Har Chrome forbudt push-notifikationer? Nej. Chrome begrænser websteder, det klassificerer som forstyrrende (højt volumen, lavt engagement), og tilbagekalder tilladelser, som brugerne demonstrativt ignorerer. En afsender, hvis notifikationer bliver klikket, påvirkes ikke af begge mekanismer, og Googles test fandt, at afsendere med lavere volumen så klikraterne stige.

Hvilken engagementrate holder mig sikker fra Chromes auto-tilbagekaldelse? Google har ikke offentliggjort tærskler, og enhver leverandør, der citerer dig et sikkert tal, gætter. De offentliggjorte fakta: mindre end 1 % af alle notifikationer modtager nogen interaktion, og tilbagekaldelse målretter kombinationen af meget lavt engagement med højt afsendelsesvolumen. Den forsvarsbare strategi er at holde din klikrate et godt stykke fra den baseline og stoppe med at sende til abonnenter, der er holdt op med at svare.

Påvirker Chromes ratebegrænsninger hele min konto eller kun ét websted? Chromes evalueringssprog er pr. websted – beskeder, prompts og engagement måles alle mod “et websted.” Afsendere, der bruger en push-platform, evalueres på deres eget domænes adfærd, ikke deres leverandørs aggregerede. Google har ikke offentliggjort vejledning ud over det, så betragt cross-domain-specifikke oplysninger som ubekræftede.

Hvad ændrede sig for push-notifikationer i Android 16? Tre ting: notifikationsnedkøling (bursts dæmpes gradvist i op til et minut, slået til som standard, opkald og alarmer undtaget), tvungen gruppering af hver apps notifikationer, og – fra december 2025 QPR2-opdateringen på nyere Pixels – Notifikationsorganisatoren, som arkiverer Promotions- og Nyhedsnotifikationer i en lydløs kollapset bundt som standard. Fuld mekanik i vores Android 16 nedkølingsguide.

Gælder nedslaget for iOS? Apples begrænsninger går for det meste forud for det: iOS web push kræver, at brugeren tilføjer dit websted til deres Hjemmeskærm, og App Store Guideline 4.5.4 kræver eksplicit opt-in plus en in-app opt-out for marketing push. Ændringen i 2025 er Declarative Web Push (iOS 18.4 / Safari 18.5), et simplere, service-worker-frit format uden straf for lydløs push for deklarative beskeder.

Er RCS-forretningsbeskeder også hastighedsbegrænsede? Ja, baseret på omdømme. Google tildeler hver RCS-forretningsagent et Høj/Medium/Lav omdømme baseret på brugerfeedback og spam-rapporter; agenter med lavt omdømme (inklusive alle nye agenter) står over for begrænsninger på unikke brugere, der initieres per rullende 28 dage. Håndhævelse er live for salgsfremmende agenter i Indien fra primo 2026, med rapportering om omdømme og spam-trends i udviklerkonsollen for alle.

Er web push stadig værd at bruge i 2026? For afsendere, der udløser og segmenterer, mere end før: den droslede spray-and-pray-trafik plejede at konkurrere om den samme notifikationsskærm som dig. Platformene styrker kanalen for de afsendere, som kanalen blev bygget til — og skubber resten ud.

Sidst opdateret og ændringslog {#changelog}

Dette hub vedligeholdes som en levende reference. Konvention: datoen for “Sidst opdateret” ændres kun for væsentlige opdateringer (en platform, der udgives, annonceres eller dokumenteres en ændring), ikke for tekstredigeringer. Hver væsentlig opdatering får en linje i ændringsloggen med en kilde. Hvis du citerer denne side, skal du citere den med dens sidst opdaterede dato.

• 2026-09-21 — Første udgivelse. Dækker: Chrome Push API-hastighedsbegrænsninger (jan 2026), Chrome automatisk tilbagekaldelse af tilladelser (annonceret okt 2025), Chrome ML-baseret screening af notifikationer på enheden (maj 2025), Android 16 cooldown + tvungen gruppering (juni 2025), Android 16 QPR2 Notification Organizer (dec 2025), Deklarativ Web Push (iOS 18.4 / Safari 18.5, 2025), RCS omdømmebaserede trafikbegrænsninger og spam-trendanalyse (jan-apr 2026), Google Beskeder ukendte afsender- og verificeret branding-ændringer (fra okt 2025).

Noget ændret, som vi ikke har logget? Den hurtigste måde at få det foran os på er chat-widgetten på denne side.