Någon gång under de senaste arton månaderna slutade plattformarna att be avsändare att bete sig och började upprätthålla det. Chrome begränsar nu hastigheten för webbplatser som klassificeras som störande och återkallar tyst notifikationsbehörighet från webbplatser som användare ignorerar. Android 16 tystar notifikationsutbrott som standard, grupperar allt med tvång och på nyare Pixels lägger kampanjmeddelanden i ett kollapsat, tyst paket. Google Messages begränsar hur många nya användare en RCS-avsändare med lågt anseende ens kan nå. Om du sökte på ”chrome notification crackdown” eller ”why are my push notifications not delivered”, är den här sidan referensen: varje ändring, den primära källan bakom den, vem den drabbar och de specifika lösningarna som håller en avsändare levererad.
Detta är ett levande dokument. Vi uppdaterar det när en plattform levererar eller annonserar en ändring, och varje revision loggas i ändringsloggen längst ner. Senast uppdaterad: 17 augusti 2026.
En inledande anmärkning före detaljerna, eftersom den förklarar varje post i tabellen nedan. Ingen av dessa plattformar dödar notifikationer. Alla delar upp notifikationer i två klasser: högvolyms-, lågengagemangssändningar begränsas, tystas, grupperas eller avregistreras – medan relevanta, händelsestyrda notifikationer behåller full leverans, och i vissa fall får bättre placering än tidigare. Tillsnävningen är inte mot push. Den är mot massutskick.
Vad som ändrades: 2026 års tidslinje för notifikationstillsnävning
| Plattform | Ändra | Vem som drabbas | Gäller från | Källa |
|---|---|---|---|---|
| Chrome (dator + Android) | Tystare UI för behörigheter: tyst prompt för användare som vanligtvis blockerar och för webbplatser med låga acceptansgrader för prompter; senare utvidgat till webbplatser med bedrägliga prompter eller innehåll | Webbplatser som frågar vid första sidvisningen eller skickar bedrägligt innehåll | Chrome 80, feb 2020 (upprätthållande utvidgat genom 2020) | Chromium-bloggen |
| Safari / iOS | Deklarativ Web Push: web push utan service worker, ingen straffavgift för tyst push för deklarativa nyttolaster | Web push-avsändare som riktar sig till Apple-användare | iOS/iPadOS 18.4 (mars 2025); Mac i Safari 18.5 (maj 2025) | WebKit-bloggen |
| Chrome på Android | Maskininlärning på enheten flaggar misstänkta webb push-notifikationer som ”möjligen vilseledande eller spam” med avregistrering med ett tryck | Avsändare vars notifikationstext matchar spam | Maj 2025 | Chromium-bloggen |
| Android 16 | Notifikationsnedkylning (utbrott tystas gradvis, aktiverat som standard) och tvångsgruppering av alla appar-notifikationer | Avsändare av högfrekventa app-push; utbrott av något slag | Stabil 10 juni 2025 | Android Authority; vår djupdykning |
| Chrome (dator + Android) | Automatisk återkallning av notifikationsbehörighet via Säkerhetskontroll för webbplatser med lågt engagemang och hög volym | Webbplatser som skickar många notifikationer som användare aldrig klickar på | Annonserat 10 okt 2025; rullas ut | Chromium-bloggen |
| Google Meddelanden | Gruppering av "okända avsändare"; verifieringsmärken för företag och standardiserad varumärkesprofilering för RCS | Företag som skickar meddelanden till användare som inte har sparat dem | Från mitten av okt 2025 (rullas ut) | Android Authority |
| Android 16 QPR2 (Pixel) | Aviseringsorganisatör: AI på enheten sorterar bort kampanjer och nyhetsaviseringar i ett tyst, komprimerat paket som standard; AI-sammanfattningar för konversationer | Kampanj-app-push-avsändare på nuvarande Pixels (6 länder, engelska) | Dec 2025 | 9to5Google |
| Chrome (dator + Android) | Push-API-hastighetsgränser: webbplatser som klassificeras som störande begränsas till 1 000 push-meddelanden/minut med HTTP 429 ovanför det; 1 → 7 → 14-dagars straffstege | Avsändare med hög volym och lågt engagemang per användare | Rullas ut från jan 2026 | Chrome för utvecklare |
| RCS för företag | Gräns för trafik baserad på rykte: unika användargränser per rullande 28 dagar för kampanjagenter med lågt rykte (live i Indien; nya agenter börjar med lågt rykte); analys av spamtrender och avregistreringsorsaker | Kampanj-RCS-avsändare, särskilt nya agenter | 7 jan / 16 feb / 1 apr 2026 | RCS för företag – versionsanteckningar |
Nu detaljerna per plattform, i den ordning de kommer att visas på din instrumentpanel.
Chrome: hastighetsgränser, automatiskt återkallade behörigheter och ML-spamfiltrering
Chrome är där de flesta retentionsteam känner av nedgången först, eftersom webb-push är den mest volymrika egna kanalen som de flesta e-handelsvarumärken använder. Tre separata mekanismer är nu aktiva, och de förstärker varandra.
Push-API-hastighetsgränser för "störande" webbplatser
Sedan januari 2026 utvärderar Chrome varje webbplats dagligen mot tre faktorer: push-meddelanden som skickas per tid användare spenderar på webbplatsen, behörighetsförfrågningar som visas per tid på webbplatsen och användarens engagemangsnivå med webbplatsen (webbplatsens engagemangspoäng plus minuter i förgrunden). En webbplats som misslyckas med testet klassificeras som störande och begränsas till 1 000 push-meddelanden per minut. Allt över gränsen får ett HTTP 429-svar från push-tjänsten.
Straffet eskalerar. Den första störande dagen ger en 1-dagars gräns. En andra på varandra följande dag utökar den till 7 dagar. Från och med den tredje dagen löper gränsen 14 dagar i taget – och räknaren återställs först efter 42 på varandra följande dagar med rent beteende. Google har inte publicerat ett Chrome-versionsnummer för utrullningen; mekanismen utvärderas på servern och kom tyst.
Gör uträkningen mot din egen lista. Vid 1 000 meddelanden per minut tar en sändning till 500 000 prenumeranter mer än åtta timmar att slutföra. En flash-sale-push som behövde landa inom femton minuter landar nu över en hel arbetsdag, och intäktsfönstret den skulle ha träffat är borta. Det är den faktiska kostnaden: inte ett förbud, en urholkning – dina intäkter från återvunna kundvagnar och dina klick-till-intäkter minskar medan din leveransinstrumentpanel fortfarande säger "skickat."
Notera omfånget. Gränsen gäller endast bakgrunds-API:et för Push; aviseringar som skickas från en öppen flik via Notifications API påverkas inte. Googles egen formulering är att ”nästan alla webbplatser kommer att påverkas” — målet är den lilla uppsättning av sändare som skickar stora volymer till en publik som har slutat svara. Huruvida du tillhör den uppsättningen är en mätbar fråga, och självgranskningen nedan går igenom den.
Automatisk återkallning av behörighet
Den andra mekanismen tar bort prenumeranter som du trodde att du ägde. Meddelat den 10 oktober 2025, återkallar Chromes säkerhetskontroll nu automatiskt aviseringstillstånd från webbplatser som kombinerar mycket lågt användarengagemang med en hög volym av skickade aviseringar — samma behandling som den redan tillämpade på oanvända kamera- och platstillstånd. Chromes produktteam motiverade det med en siffra: mindre än 1 % av alla aviseringar får någon interaktion från användare.
Detaljerna som är viktiga för en sändare:
- Installerade webbappar är undantagna. En prenumerant som har lagt till din webbplats på sin startskärm eller skrivbord behåller tillståndet.
- Användaren meddelas när Chrome tar bort ett tillstånd, och kan återställa det via Säkerhetskontroll eller genom att besöka din webbplats igen och välja att delta på nytt.
- Google rapporterade att i tester minskade aviseringöverbelastningen avsevärt med ”endast en minimal förändring i totala aviseringklick” — och att webbplatser som skickade lägre volymer såg klickfrekvensen öka.
Läs den senaste punkten igen, för det är hela nedslaget i en mening. Klick fanns aldrig i slutet av listan. Webbplatser som skickade mindre tjänade mer per sändning. Chrome upprätthåller nu den listrensning som högpresterande sändare redan praktiserade: ditt inaktiva segment är inte längre ett fåfängas nummer på prenumeranträknaren, det är en belastning som utlöser tillsyn.
Google har inte publicerat de numeriska tröskelvärdena för ”lågt engagemang” eller ”hög volym”, så ingen leverantör kan lova dig ett säkert tak. Vad du kan kontrollera är förhållandet som systemet tydligt mäter: interaktioner per levererad avisering.
Maskininlärningsfiltrering på enheten på Android
Den tredje mekanismen, live sedan maj 2025, placerar en maskininlärningsmodell mellan din avisering och användarens ögon. Chrome på Android analyserar inkommande webb-push-innehåll på enheten (webb-push är end-to-end-krypterat, så analysen måste vara lokal — modellen läser rubriken, brödtexten och etiketter för åtgärdsknappar). Aviseringar som mönstermatchar bedrägeri eller spam visas med en varning och ett alternativ för avprenumeration med ett tryck.
De formuleringar som snubblar spamklassificerare är de som lågkvalitativa sändare förlitar sig på: falsk brådska, clickbait-luckor, vilseledande systemmeddelandestyling. Om din aviseringstext kan misstas för en mall för prisbedrägeri, skickas den nu på vissa telefoner med en varningsetikett och en utgångsdörr.
Vad Chromes historik berättar för dig om vad som kommer härnäst
Inget av detta är en undanmanöver. Chrome tystade tillåtelseprompten för webbplatser med låg acceptans i februari 2020, och utökade sedan tillämpningen till att omfatta oönskade prompter och oönskat innehåll senare samma år. Vågen 2025–2026 flyttar tillämpningen från opt-in-ögonblicket till själva relationen mellan avsändare och mottagare. Riktningen har varit enkelriktad i sex år: varje utgåva gör engagemanget mer belastande. Räkna med att trösklarna stramas åt, inte luckras upp.
Android 16: nedkylning, tvångsgruppering och det tysta Promotions-paketet
Androids ändringar påverkar appaviseringar snarare än webbläsaren, och de ändrar vad "levererad" betyder snarare än om leverans sker.
Notifieringsnedkylning, som aktiverades som standard när Android 16 blev stabilt den 10 juni 2025, riktar sig mot utbrott. Den första notifieringen i ett utbrott ljuder med full volym och en fullständig banner; varje efterföljande notifiering inom ungefär en minut blir gradvis tystare och visuellt minimerad, och utbrottet kollapsar under en enda banner. Samtal, larm och prioriterade konversationer är undantagna; marknadsförings- och transaktionsaviseringar är det inte. Ingenting raderas och leveransrapporter flyttas inte – vilket är precis varför ändringen är farlig. Din instrumentpanel visar tre levererade; användarens telefon presenterade en. Vi publicerade en fullständig genomgång av mekanismerna och korrigeringar av sändningsdesignen i vår guide för Android 16 notifieringsnedkylning.
Tvångsgruppering tar bort ett val som utvecklare tidigare hade: Android 16 grupperar alla notifieringar från samma app oavsett om appen valde att delta eller inte. I kombination med nedkylning är den andra och tredje aviseringen i en snabb sekvens nu tysta, kollapsade rader snarare än banners.
Notifieringsorganisatören är den skarpaste av de tre. Den rullas ut sedan december 2025 med Android 16 QPR2 på Pixel 9- och 10-seriens telefoner (9to5Google), den använder en modell på enheten för att klassificera notifieringar i Kampanjer, Nyheter, Socialt och Föreslaget – och kategorierna Kampanjer och Nyheter är aktiverade som standard, och placerar matchande notifieringar i ett kollapsat paket i den tysta sektionen av skuggan. Utbyggnaden är smal idag (senaste Pixels, sex länder, engelska), men standardinställningen är viktig: på de enheter som Google helt kontrollerar, surrar en kampanjavisering inte längre, visar ingen banner längre och ligger hopvikt tills användaren letar. Tillsammans med den komprimerar AI-sammanfattningar på enheten konversationsaviseringar.
Samma OS-cykel byggde också den motsatta filen. Android 16:s progress-centrerade aviseringar (Live Updates-mönstret) ger genuint live, användarspårade händelser — en leverans på väg, en orderstatus — ihållande, förhöjd placering. Googles 2026-releaser har fortsatt att utöka denna live-innehållsfil, även om detaljerna om vad som skickas utöver Android 16 fortfarande håller på att stabiliseras och är värda att kontrollera mot aktuella Android-releaseanteckningar innan du bygger på dem. Designintentionen är redan otvetydig: innehåll som användaren aktivt spårar främjas; innehåll som avsändaren vill att användaren ska märka organiseras bort.
Under OS-lagret gäller fortfarande Firebase Cloud Messaging:s långvariga gränser per enhet — 240 meddelanden per minut och 5 000 per timme till en enda enhet, med ihållande sändare nära gränsen som riskerar en missbruksflagga. Varje system som ditt företag kör mot samma app delar den budgeten.
iOS och Safari: en tystare typ av grind
Apples 2025–2026-historia är mindre en nedslagning än en kontrollerad öppning, eftersom Apple byggde in sina grindar från början: webb-push på iOS har alltid krävt att användaren först lägger till din webbplats på sin hemskärm (ett avsiktligt filter med hög avsikt, på plats sedan iOS 16.4), och App Store-policy har länge begränsat marknadsförings-push.
Vad som ändrades:
- Deklarativ Web Push skickades i iOS/iPadOS 18.4 i mars 2025 och nådde Mac i Safari 18.5 (WebKit). Det låter dig köra webb-push från en standardiserad JSON-nyttolast utan en service worker, och det tar bort straffet för tyst push för deklarativa meddelanden eftersom nyttolasten i sig garanterar en synlig avisering. Äldre service worker-push fortsätter att fungera; det deklarativa formatet är den framåtriktade vägen som Apple vill att sändare ska använda.
- iOS 26 ställer enligt uppgift in webbplatser på hemskärmen som standard för att öppnas som webbappar, vilket breddar ytan där iOS webb-push kan köras. Vi har bara sett detta dokumenterat i andra hand hittills; behandla det som en riktning tills Apples dokumentation är tydlig.
- Policyn är oförändrad och strikt. App Review Guideline 4.5.4 kräver fortfarande att push inte krävs för att din app ska fungera, inte innehåller känsliga personuppgifter och — för kampanjer eller direktmarknadsföring — endast skickas till användare som uttryckligen har godkänt genom samtyckesspråk i din apps användargränssnitt, med en inbyggd avanmälan. Missbruk "kan leda till återkallande av dina privilegier."
För ett retentionsteam är slutsatsen från iOS att Apple förfiltrerade din målgrupp åt dig. En iOS webb-push-prenumerant valde att installera din webbplats; en app-push-prenumerant valde att anmäla sig till marknadsföring. Båda listorna är små och med hög avsikt — vilket innebär att det är dyrare per prenumerant att bränna dem med massfrekvens än någon annanstans.
RCS: ryktesgränser anländer till den nyaste kanalen
Om du lägger till RCS eller WhatsApp i din mix – och för återhämtning av kundvagnar och orderuppdateringar bör du utvärdera meddelandekanaler – har Google redan installerat det verkställighetslager som webb-push tog sex år att få.
Enligt Googles RCS for Business-dokumentation har varje företagssändare (agent) ett rykte – Högt, Medium eller Lågt – drivet av användarfeedback och spamrapporter, och alla nya agenter börjar på Lågt. Rykte sätter en trafikgräns: antalet unika användare som agenten kan initiera konversationer med per rullande 28 dagar. Svar på konversationer som användaren startade är undantagna. Verkställigheten blev aktiv för kampanjagenter i Indien den 7 januari 2026, skärptes den 1 april 2026 med ett övergripande tak för sändare med lågt rykte, och utvecklarkonsolen rapporterar nu ryktesnivå, trafikgräns, spamtrend och avregistreringsorsaker över 7- och 28-dagarsperioder.
På konsumentsidan har Google Messages grupperat meddelanden från osparade avsändare under "Okända avsändare" sedan mitten av oktober 2025 och rullar ut verifierade bockar och standardiserad företagsbranding – nedmonteringsstadiumsbevis på vissa detaljer, men riktningen matchar allt annat i detta dokument. På RCS får du ingen nådatid för att bygga dåliga vanor: räckvidd tjänas genom engagemang från första meddelandet.
Är du i riskzonen? Självgranskningen {#self-audit}
Chrome och Google publicerar faktorerna men inte tröskelvärdena, så den ärliga granskningen är relativ: mät om du ser ut som den avsändare som dessa system byggdes för att stoppa. Kör dessa åtta kontroller mot dina senaste 30 dagars sändningar. Varje "nej" är ett fynd. Flera av dessa kontroller betyder bara något mot externa nummer, så kör dem tillsammans med våra riktmärken för pushmeddelanden 2026, där percentilfördelningarna för visningsfrekvens och klickfrekvens visar dig vad median-, p75- och p90-avsändaren faktiskt uppnår.
- Interaktionsförhållande. Är din klickfrekvens för webb-push meningsfullt över ekosystemets baslinje för interaktion under 1 % som Chrome citerade när det motiverade automatisk återkallelse? Om din CTR har en nolla efter decimalpunkten är du inom profilen som Chrome verkställer mot.
- Volym vs. besök. Chromes första störande webbfaktor är pushmeddelanden som skickas per spenderad tid på webbplatsen. Skickar du fler aviseringar till en typisk prenumerant per vecka än vad den prenumeranten har sessioner med dig per vecka? En prenumerant som besöker månadsvis och får pushmeddelanden dagligen misslyckas med detta förhållande.
- Inaktiv svans. Vilken andel av din lista har inte klickat på något meddelande på 90 dagar? Om mer än hälften av dina sändningar går till den svansen, sätts din totala engagemangsgrad av personer som redan har lämnat – och plattformarna betygsätter helheten.
- Promptdisciplin. Begär du notisbehörighet vid första sidvisningen, innan besökaren har gjort något? Antal accepterade prompter är både ett kriterium för registrering i ett tyst UI och en faktor för störande webbplatser. Att fråga efter en demonstrerad åtgärd (andra sidvisningen, lägg till i varukorg, kontoskapande) är lösningen, och det syns direkt i din opt-in-frekvens.
- Massutskick. Vilken procentandel av din månatliga utskicksvolym utgörs av oadresserade massutskick, jämfört med notiser som utlösts av något mottagaren gjorde (övergiven varukorg, prissänkning, vara tillbaka i lager, beställning skickad)? Över ungefär hälften massutskick, har du en volym som följer exakt det mönster som varje mekanism på den här sidan bestraffar.
- Frekvensbegränsningar och tysta timmar. Tillämpar du en gräns per prenumerant över alla kampanjer och system som kan skicka – marknadsföring, transaktionella, RSS och alla andra verktyg? Androids nedkylning och tvingade gruppering innebär att okoordinerade avsändare nu synligt kannibaliserar varandra på samma enhet.
- Ärlighet i texten. Skulle någon nyligen skickad notis överleva en skeptisk läsares test: ”är detta vilseledande?” – ingen falsk brådska, ingen utklädnad till systemmeddelande, inga lockbeten? Chromes klassificerare på enheten kör redan det testet på Android.
- Trend för avprenumerationer. Är din avprenumerationsfrekvens per utskick platt eller fallande? På RCS matar den nu en ryktespoäng med en hård trafikbegränsning kopplad; på webb-push är det din tidiga varning. Vår guide för att minska avprenumerationer för push-notiser täcker diagnostiken i detalj.
Betygsätt dig själv ärligt. Fem eller fler rena svar och nedslagningen är mestadels en medvind för dig – dina konkurrenters spray-and-pray stryps medan dina utskick fortsätter att nå fram. Tre eller fler fynd och du bör anta att du redan förlorar räckvidd som du inte kan se i en leveransrapport.
Spelplanen för efterlevnad: åtgärder som håller.
Varje mekanism ovan mäter samma underliggande kvantitet – värde per notis – så åtgärderna konvergerar. Dessa sex drag, i prioritetsordning.
1. Skär bort den inaktiva svansen innan plattformarna gör det åt dig. Bygg ett segment för inaktiva (ingen klickning på 90 dagar), kör en ärlig återvinningssekvens genom det, sluta sedan skicka till icke-svarande. Detta är kontraintuitivt för team som behandlar liststorlek som KPI, men matematiken är enkelriktad nu: en vilande prenumerant bidrar med noll intäkter och försämrar aktivt engagemangsgraden som Chrome betygsätter dig på. I PushEngage underhåller dynamisk segmentering den inaktiva gruppen automatiskt, och eftersom prissättningen bara räknar aktiva prenumeranter, minskar trimning av dödvikt din faktura snarare än din räckvidd.
2. Skifta sändningsvolym från massutskick till triggers. En pushnotis om övergiven kundvagn, en prisfallsvarning, ett meddelande om att en vara finns i lager igen – dessa ger klick eftersom mottagarens eget beteende schemalade dem. Att flytta även hälften av din månatliga volym från kalenderstyrda massutskick till triggade kampanjer höjer din interaktionsgrad för varje faktor som Chrome mäter, och det är där intäkterna ändå fanns: triggade utskick attribueras till återvunna kundvagnar och slutförda beställningar, inte intryck. Vi presenterade hela argumentet, med definitionerna av kampanjklasser och matematiken för intäkter per utskick, i varför massutskickseran just tog slut.
3. Segmentera det som fortfarande sänds ut brett. Vissa utskick går legitimt brett – en butiksomfattande rea, en nyhetsredaktions brytande nyhet. Brett är inte samma sak som osegmenterat. Att dela upp ett brett utskick baserat på beteende, köphistorik eller kategoriintresse höjer klickfrekvensen för varje del och håller varje prenumerants personliga push-per-besök-kvot försvarbar. Segmentering är nu ett leveranskrav, inte en personaliseringsfiness – det inlägget innehåller hela argumentet för leveransbarhet.
4. Inför en frekvensbegränsning över alla kanaler och system. Android 16:s nedkylning gjorde detta konkret: ditt CRM, ditt transaktionslager och din kampanjkalender delar en uppmärksamhetsbudget på enheten, oavsett om de delar en instrumentpanel eller inte. Ställ in en gräns per prenumerant och tysta timmar på plattforms nivå, som spänner över webb-push, app-push och WhatsApp tillsammans, så att fyra rimliga system inte kan samverka till ett missbrukande mönster. Detta fungerar bara om en segmenteringsmotor ser varje utskick – det starkaste praktiska argumentet för att konsolidera kanaler snarare än att köra ett verktyg per kanal.
5. Åtgärda opt-in-ögonblicket. Flytta tillståndsfönstret bakom en åtgärd som signalerar avsikt, använd ett tvåstegsfrågeformulär så att webbläsarfrågan bara utlöses vid ett ja, och acceptera den mindre, renare listan. Antalet accepterade frågor matar Chromes poängsättning i båda ändar – registrering via tyst UI och utvärdering av störande webbplatser – och en samtyckt lista är också helt enkelt den lista som klickar.
6. Låt texten överleva en klassificerare. Enkla påståenden, verklig brådska endast när deadline är verklig, avsändaridentitet uppenbar. På Android läser en ML-modell din titel och brödtext innan användaren gör det. Ärlig text var alltid en bättre praxis för att behålla användare; nu är det också ett leveranskrav.
Om du kör dessa sex på PushEngage, är den ärliga sammanfattningen av var produkten hjälper: triggade kampanjer, RFM- och beteendesegment, kanalövergripande frekvensbegränsningar, tysta timmar och intäktsattribuering per notis är allt inbyggt, på planer som fakturerar endast aktiva prenumeranter – prismodellen råkar peka åt samma håll som plattformarna nu tvingar fram. Vad inget verktyg kan göra är att besluta att sluta med massutskick; den delen är policy, och den är din.
FAQ
Varför levereras inte mina push-notiser 2026? Kontrollera fyra misstänkta i ordning. Först, Chromes automatiska återkallelse: om dina prenumerantantal tyst krymper, kan prenumeranter med lågt engagemang förlora behörigheten via Säkerhetskontroll. För det andra, Chromes hastighetsbegränsningar: om sändningar till stora listor plötsligt tar timmar eller din push-tjänst loggar HTTP 429-svar, har du troligen klassificerats som störande. För det tredje, Android-presentation: på Android 16 sker leveransen fortfarande men utbrott tystas och grupperas, och på nyare Pixels landar kampanjmeddelanden i ett tyst paket — levererade, osedda. För det fjärde, de tråkiga orsakerna som föregick nedslagningen: utgångna prenumerationer, service-worker-fel och OS-nivå notisinställningar.
Förbjöd Chrome push-notiser? Nej. Chrome begränsar hastigheten för webbplatser som den klassificerar som störande (hög volym, lågt engagemang) och återkallar behörigheter som användare uppenbart ignorerar. En avsändare vars notiser klickas påverkas inte av någon av mekanismerna, och Googles tester visade att avsändare med lägre volym såg klickfrekvensen öka.
Vilken engagemangsgrad håller mig säker från Chromes automatiska återkallelse? Google har inte publicerat några tröskelvärden, och alla leverantörer som anger ett säkert nummer gissar. De publicerade fakta: mindre än 1 % av alla notiser får någon interaktion, och återkallelse riktar sig mot kombinationen av mycket lågt engagemang med hög sändningsvolym. Den försvarbara strategin är att hålla din klickfrekvens långt ifrån den baslinjen och att sluta skicka till prenumeranter som har slutat svara.
Påverkar Chromes hastighetsbegränsningar hela mitt konto eller bara en webbplats? Chromes utvärderingsspråk är per webbplats — meddelanden, uppmaningar och engagemang mäts alla mot ”en webbplats”. Avsändare som använder en push-plattform utvärderas baserat på deras egen domäns beteende, inte deras leverantörs aggregerade. Google har inte publicerat någon ytterligare vägledning, så behandla domänspecifika detaljer som obekräftade.
Vad ändrades för push-notiser i Android 16? Tre saker: notisnedkylning (utbrott tystas gradvis i upp till ett minut, aktiverat som standard, samtal och larm undantagna), tvångsgruppering av varje apps notiser, och — från uppdateringen QPR2 i december 2025 på nyare Pixels — Notisorganisatören, som som standard arkiverar kampanj- och nyhetsnotiser i ett tyst kollapsat paket. Fullständiga mekanismer i vår guide för Android 16 nedkylning.
Gäller nedslagningen iOS? Apples begränsningar föregår mestadels den: iOS webb push kräver att användaren lägger till din webbplats på sin hemskärm, och App Store Guideline 4.5.4 kräver explicit opt-in plus en in-app opt-out för marknadsföringspush. Ändringen 2025 är Declarative Web Push (iOS 18.4 / Safari 18.5), ett enklare format utan service-worker och utan straff för tyst push för deklarativa meddelanden.
Begränsas även RCS Business-meddelanden av hastighetsgränser? Ja, baserat på rykte. Google tilldelar varje RCS Business-agent ett rykte (högt/medel/lågt) baserat på användarfeedback och spamrapporter; agenter med lågt rykte (inklusive alla nya agenter) har begränsningar för unika användare som initierats per rullande 28-dagarsperiod. Genomförandet är live för kampanjagenter i Indien från och med början av 2026, med rapportering av rykte och spamtrender i utvecklarkonsolen för alla.
Är webb-push fortfarande värt det 2026? För avsändare som utlöser och segmenterar, mer än tidigare: den begränsade massutskickstrafiken brukade konkurrera om samma notiscenter som du. Plattformarna stärker kanalen för de avsändare som kanalen byggdes för – och trycker ut resten.
Senast uppdaterad och ändringslogg {#changelog}
Det här navet underhålls som en levande referens. Konvention: datumet för "Senast uppdaterad" ändras endast vid väsentliga uppdateringar (en plattform som lanseras, annonserar eller dokumenterar en ändring), inte för redigering av text. Varje väsentlig uppdatering får en rad i ändringsloggen med en källa. Om du citerar den här sidan, citera den med dess datum för senast uppdaterad.
- 2026-09-21 — Initial publicering. Omfattar: Chrome Push API-hastighetsgränser (jan 2026), automatisk återkallning av Chrome-behörigheter (annonserat okt 2025), Chrome on-device ML-filtrering av aviseringar (maj 2025), Android 16 cooldown + tvingad gruppering (juni 2025), Android 16 QPR2 Notification Organizer (dec 2025), deklarativ webb-push (iOS 18.4 / Safari 18.5, 2025), RCS ryktesbaserade trafikbegränsningar och spamtrendanalyser (jan–apr 2026), ändringar i Google Messages okända avsändare och verifierat varumärke (från okt 2025).
Har något ändrats som vi inte har loggat? Det snabbaste sättet att få det framför oss är chattwidgeten på den här sidan.
