De 2026 notification crackdown: worden je pushmeldingen nog steeds bezorgd?

Ergens in de afgelopen achttien maanden zijn de platforms gestopt met het vragen aan afzenders om zich te gedragen en zijn ze begonnen met handhaven. Chrome beperkt nu de snelheid van sites die het als storend classificeert en trekt stilzwijgend de toestemming voor meldingen in van sites die gebruikers negeren. Android 16 dempt meldingenbundels standaard, groepeert alles geforceerd, en op nieuwere Pixels worden promotionele pushes in een samengevouwen, stille bundel geplaatst. Google Berichten beperkt hoeveel nieuwe gebruikers een RCS-afzender met een lage reputatie kan bereiken. Als je zocht naar "chrome notification crackdown" of "waarom worden mijn pushmeldingen niet bezorgd", is deze pagina de referentie: elke wijziging, de primaire bron erachter, wie het treft, en de specifieke oplossingen die een afzender bezorgd houden.

Dit is een levend document. We werken het bij wanneer een platform een wijziging doorvoert of aankondigt, en elke revisie wordt gelogd in het wijzigingenlogboek onderaan. Laatst bijgewerkt: 17 augustus 2026.

Eén kaderende opmerking vóór de details, omdat deze elke vermelding in de onderstaande tabel verklaart. Geen van deze platforms doodt meldingen. Ze splitsen allemaal meldingen in twee klassen: meldingen met een hoog volume en lage betrokkenheid worden vertraagd, stilgezet, gebundeld of afgemeld - terwijl relevante, gebeurtenisgestuurde meldingen volledige bezorging behouden, en in sommige gevallen een betere plaatsing krijgen dan voorheen. De crackdown is niet op 'blast'. Het is op 'blast'.

Wat is er veranderd: de 2026 notification crackdown tijdlijn

Platform	Wijziging	Wie wordt er getroffen	Ingangsdatum	Bron
Chrome (desktop + Android)	Stiller toestemmings-UI: gedempt prompt voor gebruikers die meestal blokkeren en voor sites met lage acceptatiepercentages van prompts; later uitgebreid naar sites met misbruikende prompts of inhoud	Sites die prompten bij het eerste paginabezoek of misleidende inhoud pushen	Chrome 80, feb 2020 (handhaving uitgebreid tot 2020)	Chromium blog
Safari / iOS	Declarative Web Push: web push zonder service worker, geen stille push-straf voor declaratieve payloads	Web push-afzenders gericht op Apple-gebruikers	iOS/iPadOS 18.4 (mrt 2025); Mac in Safari 18.5 (mei 2025)	WebKit blog
Chrome op Android	On-device ML markeert verdachte web pushmeldingen als "mogelijk misleidend of spamachtig" met één tik om af te melden	Afzenders wiens meldingskopiepatroon overeenkomt met spam	Mei 2025	Chromium blog
Android 16	Meldingsafkoeling (bursts worden steeds stiller, standaard ingeschakeld) en geforceerde groepering van de meldingen van elke app	Afzenders van meldingen met hoge frequentie; bursts van welke aard dan ook	Stabiel 10 juni 2025	Android Authority; onze diepgaande analyse
Chrome (desktop + Android)	Automatische intrekking van notificatiepermissies via Safety Check voor sites met weinig interactie en een hoog volume	Sites die veel meldingen sturen waar gebruikers nooit op klikken	Aangekondigd op 10 okt. 2025; wordt uitgerold	Chromium blog
Google Berichten	Groepering van "Onbekende afzenders"; geverifieerde vinkjes voor bedrijven en gestandaardiseerde branding voor RCS	Bedrijven die berichten sturen naar gebruikers die hen niet hebben opgeslagen	Vanaf half okt. 2025 (wordt uitgerold)	Android Authority
Android 16 QPR2 (Pixel)	Notificatie-organizer: AI op het apparaat sorteert Promotie- en Nieuws-meldingen standaard in een stille, samengeklapte bundel; AI-samenvattingen voor gesprekken	Promotionele app-push-verzenders op huidige Pixels (6 landen, Engels)	Dec 2025	9to5Google
Chrome (desktop + Android)	Push API-limieten: sites die als storend worden geclassificeerd, beperkt tot 1.000 pushmeldingen/minuut met HTTP 429 daarboven; 1 → 7 → 14-daagse strafladder	Verzenders met een hoog volume en lage interactie per gebruiker	Uitrol vanaf jan. 2026	Chrome voor ontwikkelaars
RCS voor Bedrijven	Reputatiegebaseerde verkeerslimieten: limieten voor unieke gebruikers per periode van 28 dagen voor promotionele agenten met een lage reputatie (live in India; nieuwe agenten beginnen met een lage reputatie); analyse van spamtrends en redenen voor afmelding	Promotionele RCS-verzenders, met name nieuwe agenten	7 jan. / 16 feb. / 1 apr. 2026	Releaseopmerkingen voor RCS voor Bedrijven

Nu het per platform gedetailleerd, in de volgorde waarin het op je dashboard verschijnt.

Chrome: limieten, automatisch ingetrokken permissies en ML-spamfiltering

Chrome is waar de meeste retentieteams de klop als eerste voelen, omdat web push het kanaal met het hoogste volume is dat de meeste e-commercemerken beheren. Drie afzonderlijke mechanismen zijn nu live en ze versterken elkaar.

Push API-limieten voor "storende" sites

Sinds januari 2026 evalueert Chrome elke site dagelijks op basis van drie factoren: pushmeldingen verzonden per tijd die gebruikers op de site doorbrengen, toestemmingsprompts weergegeven per tijd op de site, en het interactieniveau van de gebruiker met de site (site-engagement score plus voorgrondminuten). Een site die de test niet doorstaat, wordt geclassificeerd als storend en beperkt tot 1.000 pushmeldingen per minuut. Alles boven de limiet krijgt een HTTP 429-antwoord van de pushservice.

De straf escaleert. De eerste storende dag levert een limiet van 1 dag op. Een tweede opeenvolgende dag verlengt dit tot 7 dagen. Vanaf de derde dag loopt de limiet 14 dagen per keer – en de teller wordt pas gereset na 42 opeenvolgende dagen van schoon gedrag. Google heeft geen Chrome-versienummer gepubliceerd voor de uitrol; het mechanisme wordt server-evalueerd en is geruisloos geïntroduceerd.

Doe de berekening voor je eigen lijst. Met 1.000 berichten per minuut duurt een verzending naar 500.000 abonnees meer dan acht uur. Een flash-sale push die binnen vijftien minuten moest landen, landt nu verspreid over een volledige werkdag, en het inkomstenvenster dat het moest raken, is verdwenen. Dat is de werkelijke kosten: geen verbod, maar een verval – je inkomsten uit herstelde winkelwagens en je click-to-revenue-cijfers eroderen terwijl je bezorgingsdashboard nog steeds "verzonden" aangeeft.

Let op de reikwijdte. De limiet is alleen van toepassing op de achtergrond Push API; meldingen die via de Notifications API vanuit een open tabblad worden verzonden, worden niet beïnvloed. Google's eigen formulering is dat “bijna alle websites onaangetast blijven” — het doelwit is de kleine groep afzenders die een hoog volume pushen naar een publiek dat niet meer reageert. Of u tot die groep behoort, is een meetbare vraag, en de zelfaudit hieronder behandelt dit.

Automatische intrekking van toestemming

Het tweede mechanisme verwijdert abonnees die u dacht te bezitten. Aangekondigd op 10 oktober 2025, trekt Chrome's Safety Check nu automatisch de meldingsrechten in van sites die zeer lage gebruikersbetrokkenheid combineren met een hoog aantal verzonden meldingen — dezelfde behandeling die het al toepaste op ongebruikte camera- en locatiepermissies. Chrome's productteam rechtvaardigde dit met één getal: minder dan 1% van alle meldingen ontvangt enige interactie van gebruikers.

De details die ertoe doen voor een afzender:

• Geïnstalleerde webapps zijn vrijgesteld. Een abonnee die uw site aan hun startscherm of bureaublad heeft toegevoegd, behoudt de toestemming.
• De gebruiker wordt op de hoogte gesteld wanneer Chrome een machtiging verwijdert en kan deze herstellen via Safety Check of door uw site opnieuw te bezoeken en zich opnieuw aan te melden.
• Google meldde dat in tests de meldings-overload aanzienlijk daalde met “slechts een minimale verandering in het totale aantal meldingsklikken” — en dat sites die lagere volumes verzonden, hogere klikfrequenties zagen.

Lees dat laatste punt nog eens, want het is de hele crackdown in één zin. De klikken zaten nooit aan het einde van de lijst. Sites die minder verzonden, verdienden meer per verzending. Chrome handhaaft nu de lijsthygiëne die hoog presterende afzenders al beoefenden: uw inactieve segment is niet langer een ijdelheidscijfer op de abonneeteller, het is een aansprakelijkheid die handhaving triggert.

Google heeft de numerieke drempels voor “lage betrokkenheid” of “hoog volume” niet gepubliceerd, dus geen enkele leverancier kan u een veilige limiet beloven. Wat u wel kunt beheersen, is de verhouding die het systeem duidelijk meet: interacties per geleverde melding.

On-device ML-screening op Android

Het derde mechanisme, live sinds mei 2025, plaatst een machine learning-model tussen uw melding en de ogen van de gebruiker. Chrome op Android analyseert inkomende webpush-inhoud op het apparaat (webpush is end-to-end versleuteld, dus de analyse moet lokaal zijn — het model leest de titel, de hoofdtekst en de labels van de actieknoppen). Meldingen die patronen van misleiding of spam vertonen, worden getoond met een waarschuwing en een afmeldingsoptie met één tik.

De kopieerpraktijken die spamclassificatoren in de val lokken, zijn degene waarop afzenders van lage kwaliteit leunen: valse urgentie, clickbait-gaten, misleidende styling van systeemberichten. Als uw meldingskopie verward kan worden met een prijsoplichtingssjabloon, wordt deze op sommige telefoons nu geleverd met een waarschuwingslabel en een uitgangsdeur eraan.

Wat de geschiedenis van Chrome u vertelt over wat hierna komt

Niets hiervan is een ontwijkingsmanoeuvre. Chrome heeft de toestemmingsprompt voor sites met een lage acceptatie in februari 2020 gemute, en heeft de handhaving later datzelfde jaar uitgebreid naar beledigende prompts en beledigende inhoud. De golf van 2025-2026 verplaatst de handhaving van het moment van opt-in naar de verzendrelatie zelf. De richting is al zes jaar éénrichtingsverkeer: elke release maakt betrokkenheid meer belastend. Reken op aanscherping van de drempels, niet op versoepeling.

Android 16: cooldown, geforceerde groepering en de stille Promotions-bundel

Android's wijzigingen treffen app-push in plaats van de browser, en ze veranderen wat "geleverd" betekent in plaats van of levering plaatsvindt.

Notification cooldown, standaard ingeschakeld toen Android 16 stabiel werd op 10 juni 2025, richt zich op bursts. De eerste melding in een burst waarschuwt met volledig volume en een volledige banner; elke volgende binnen ongeveer een minuut wordt steeds stiller en visueel geminimaliseerd, en de burst wordt samengevouwen onder één enkele banner. Oproepen, alarmen en prioriteitsgesprekken zijn vrijgesteld; marketing- en transactionele pushes niet. Niets wordt verwijderd en bezorgingsrapporten bewegen niet - wat precies de reden is waarom de wijziging gevaarlijk is. Je dashboard zegt drie geleverd; de telefoon van de gebruiker presenteerde er één. We hebben een volledige analyse van de mechanica en de fixes voor het verzendontwerp gepubliceerd in onze Android 16 notification cooldown guide.

Geforceerde groepering verwijdert een keuze die ontwikkelaars vroeger hadden: Android 16 bundelt alle meldingen van dezelfde app, ongeacht of de app zich heeft aangemeld. In combinatie met cooldown zijn de tweede en derde push van elke snelle reeks nu stille, samengevouwen items in plaats van banners.

De Notification Organizer is de scherpste van de drie. Uitgerold sinds december 2025 met Android 16 QPR2 op Pixel 9 en 10-serie telefoons (9to5Google), gebruikt het een on-device model om meldingen te classificeren in Promotions, News, Social en Suggested - en de Promotions- en News-categorieën zijn standaard ingeschakeld, waarbij overeenkomende meldingen worden opgeslagen in een samengevouwen bundel in het stille gedeelte van de schaduw. De uitrol is vandaag de dag beperkt (recente Pixels, zes landen, Engels), maar de standaardinstelling is belangrijk: op de apparaten die Google volledig beheert, zoemt een promotionele push niet meer, toont geen banner meer en zit opgevouwen totdat de gebruiker gaat zoeken. Daarnaast comprimeren on-device AI-samenvattingen gespreksmeldingen.

Dezelfde OS-cyclus bouwde ook de tegenovergestelde baan. De op de vooruitgang gerichte meldingen van Android 16 (het Live Updates-patroon) bieden echt live, door de gebruiker gevolgde gebeurtenissen — een bezorging onderweg, een bestelstatus — een persistente, verhoogde plaatsing. De releases van Google in 2026 hebben deze live-contentbaan verder uitgebreid, hoewel details van wat er na Android 16 wordt uitgebracht nog steeds worden vastgesteld en de moeite waard zijn om te controleren tegen de huidige release notes van Android voordat u erop bouwt. De ontwerpintentie is al ondubbelzinnig: inhoud die de gebruiker actief volgt, wordt gepromoot; inhoud die de afzender wil dat de gebruiker opmerkt, wordt uit de weg geruimd.

Onder de OS-laag zijn de langdurige limieten per apparaat van Firebase Cloud Messaging nog steeds van toepassing — 240 berichten per minuut en 5.000 per uur naar een enkel apparaat, waarbij aanhoudende zenders die de limiet bijna bereiken, risico lopen op een misbruikvlag. Elk systeem dat uw bedrijf tegen dezelfde app draait, deelt dat budget.

iOS en Safari: een stiller soort poort

Het verhaal van Apple in 2025-2026 is minder een hardhandige aanpak dan een gecontroleerde opening, omdat Apple zijn poorten vanaf het begin heeft ingebouwd: web push op iOS vereist al dat de gebruiker uw site eerst aan hun beginscherm toevoegt (een opzettelijk filter met hoge intentie, in plaats sinds iOS 16.4), en het beleid van de App Store heeft marketing push al lang beperkt.

Wat is er veranderd:

• Declarative Web Push werd uitgebracht in iOS/iPadOS 18.4 in maart 2025 en bereikte de Mac in Safari 18.5 (WebKit). Hiermee kunt u web push uitvoeren vanuit een gestandaardiseerde JSON-payload zonder service worker, en het verwijdert de stille push-straf voor declaratieve berichten, omdat de payload zelf een zichtbare melding garandeert. Legacy service-worker push blijft werken; het declaratieve formaat is het pad vooruit dat Apple wil dat zenders volgen.
• iOS 26 stelt naar verluidt beginschermwebsites standaard in om als web-apps te worden geopend, wat het oppervlak vergroot waarop iOS web push kan worden uitgevoerd. We hebben dit tot nu toe alleen uit tweede hand gedocumenteerd gezien; behandel het als richtinggevend totdat de documentatie van Apple expliciet is.
• Beleid is ongewijzigd en strikt. App Review Guideline 4.5.4 vereist nog steeds dat push niet vereist is voor de functionaliteit van uw app, geen gevoelige persoonlijke gegevens bevat en — voor promoties of directe marketing — alleen wordt verzonden naar gebruikers die expliciet hebben ingestemd via toestemmingsclausules in de gebruikersinterface van uw app, met een opt-out in de app. Misbruik kan leiden tot intrekking van uw privileges.

Voor een retentieteam is de conclusie voor iOS dat Apple uw publiek al voor u heeft gefilterd. Een iOS web push-abonnee koos ervoor om uw site te installeren; een app push-abonnee koos ervoor om zich aan te melden voor marketing. Beide lijsten zijn klein en hebben een hoge intentie — wat betekent dat het verbranden ervan met een hoge frequentie duurder is per abonnee dan elders.

RCS: reputatielimieten arriveren op het nieuwste kanaal

Als je RCS of WhatsApp aan je mix toevoegt — en voor cart recovery en orderupdates zou je berichtenkanalen moeten evalueren — heeft Google de handhavingslaag al geïnstalleerd waar web push zes jaar over deed.

Volgens Google's RCS for Business-documentatie heeft elke zakelijke afzender (agent) een reputatie — Hoog, Gemiddeld of Laag — gedreven door gebruikersfeedback en spamrapporten, en alle nieuwe agenten beginnen Laag. Reputatie bepaalt een verkeerslimiet: het aantal unieke gebruikers waarmee de agent gesprekken kan initiëren per periode van 28 dagen. Antwoorden op gesprekken die de gebruiker is gestart, zijn hiervan uitgezonderd. Handhaving werd live voor promotionele agenten in India op 7 januari 2026, werd aangescherpt op 1 april 2026 met een cross-agent limiet voor afzenders met een lage reputatie, en de ontwikkelaarsconsole rapporteert nu reputatieniveau, verkeerslimiet, spamtrend en redenen voor afmeldingen over perioden van 7 en 28 dagen.

Aan de consumentenkant groepeert Google Berichten sinds half oktober 2025 berichten van onbekende afzenders onder "Onbekende afzenders" en rolt het geverifieerde vinkjes en gestandaardiseerde bedrijfsbranding uit — teardown-fase bewijs over enkele details, maar de richting komt overeen met al het andere in dit document. Op RCS krijg je geen respijtperiode om slechte gewoonten op te bouwen: bereik wordt verdiend door betrokkenheid vanaf het eerste bericht.

Loop je risico? De zelfaudit {#self-audit}

Chrome en Google publiceren de factoren maar niet de drempels, dus de eerlijke audit is relatief: meet of je lijkt op de afzender die deze systemen moesten stoppen. Voer deze acht controles uit op je laatste 30 dagen aan verzendingen. Elke "nee" is een bevinding. Verschillende van deze controles hebben alleen betekenis tegenover externe nummers, dus voer ze uit naast onze pushmelding benchmarks van 2026, waar de percentielverdelingen voor weergavepercentage en doorklikpercentage je laten zien wat de mediaan, p75 en p90 afzender daadwerkelijk haalt.

1. Interactieratio. Ligt je doorklikpercentage van web push significant boven de basislijn van minder dan 1% interactie van het ecosysteem die Chrome citeerde toen het automatische intrekking rechtvaardigde? Als je CTR een nul heeft na het decimale punt, bevind je je binnen het profiel waar Chrome tegen handhaaft.
2. Volume versus bezoeken. De eerste disruptieve sitefactor van Chrome zijn pushmeldingen die per tijd op de site worden verzonden. Stuur je meer meldingen naar een typische abonnee per week dan die abonnee per week sessies met je heeft? Een abonnee die maandelijks bezoekt en dagelijks wordt gepusht, faalt deze ratio.
3. Inactieve staart. Welk deel van je lijst heeft 90 dagen lang geen enkele melding aangeklikt? Als meer dan de helft van je verzendingen naar die staart gaat, wordt je totale betrokkenheidspercentage bepaald door mensen die al vertrokken zijn — en de platforms beoordelen het totaal.
4. Promptdiscipline. Vraagt u toestemming voor meldingen bij het eerste paginabezoek, voordat de bezoeker iets heeft gedaan? De acceptatiegraad van prompts is zowel een criterium voor inschrijving met een stille UI als een factor voor storende sites. Prompts vragen na een aangetoonde actie (tweede paginabezoek, toevoegen aan winkelwagen, account aanmaken) is de oplossing, en dit is direct zichtbaar in uw opt-in-percentage.
5. Massale verzending. Welk percentage van uw maandelijkse verzendvolume bestaat uit ongerichte, naar de hele lijst verzonden berichten, versus meldingen die zijn getriggerd door iets wat de ontvanger heeft gedaan (verlaten winkelwagen, prijsdaling, artikel weer op voorraad, bestelling verzonden)? Boven ongeveer de helft massale verzending, bent u qua volume zwaar in precies het patroon dat elk mechanisme op deze pagina bestraft.
6. Frequentielimieten en stille uren. Stelt u een limiet per abonnee in voor elke campagne en elk systeem dat kan verzenden — marketing, transactioneel, RSS en elk ander hulpmiddel? De afkoelperiode en geforceerde groepering van Android betekenen dat ongecoördineerde verzenders nu zichtbaar elkaar kannibaliseren op hetzelfde apparaat.
7. Eerlijkheid van de tekst. Zou een recente melding een sceptische lezerstest 'is dit misleidend?' overleven — geen valse urgentie, geen namaak van systeemberichten, geen lokkertjes? De on-device classifier van Chrome voert die test op Android al uit.
8. Trend voor afmeldingen. Is uw afmeldingspercentage per verzending stabiel of dalend? Op RCS voedt dit nu een reputatiescore met een harde verkeerslimiet; op web push is het uw vroege waarschuwing. Onze gids voor het verlagen van afmeldingen voor pushmeldingen behandelt de diagnose in detail.

Beoordeel uzelf eerlijk. Vijf of meer correcte antwoorden en de aanpak is grotendeels een meevaller voor u — de spray-and-pray van uw concurrenten wordt beperkt terwijl uw verzendingen blijven aankomen. Drie of meer bevindingen en u moet aannemen dat u al bereik verliest dat u niet kunt zien in een bezorgrapport.

Het compliance-handboek: oplossingen die standhouden

Elk mechanisme hierboven meet dezelfde onderliggende hoeveelheid — waarde per melding — dus de oplossingen convergeren. Deze zes stappen, in volgorde van prioriteit.

1. Verwijder de inactieve staart voordat de platforms dit voor u doen. Bouw een segment van inactieve gebruikers (geen klik in 90 dagen), voer er één eerlijke win-back-reeks doorheen en stop dan met het verzenden naar niet-reagerende gebruikers. Dit is contra-intuïtief voor teams die de lijstgrootte als KPI beschouwen, maar de wiskunde is nu eenrichtingsverkeer: een slapende abonnee draagt nul omzet bij en degradeert actief de engagementratio waarop Chrome u beoordeelt. In PushEngage onderhoudt dynamische segmentatie de inactieve groep automatisch, en omdat de prijsstelling alleen actieve abonnees telt, verlaagt het verwijderen van dood gewicht uw factuur in plaats van uw bereik.

2. Verschuif het verzendvolume van massa-e-mails naar triggers. Een pushmelding voor een verlaten winkelwagentje, een waarschuwing voor prijsdalingen, een melding dat een product weer op voorraad is — deze leveren klikken op omdat het gedrag van de ontvanger ze heeft gepland. Het verplaatsen van zelfs de helft van uw maandelijkse volume van kalendergestuurde massa-e-mails naar getriggerde campagnes verhoogt uw interactieratio op elke factor die Chrome meet, en het is waar de inkomsten sowieso waren: getriggerde verzendingen worden toegeschreven aan herstelde winkelwagentjes en voltooide bestellingen, niet aan impressies. We hebben het volledige argument gemaakt, met de definities van campagneklassen en de wiskunde van inkomsten per verzending, in waarom het tijdperk van massa-e-mails net is afgelopen.

3. Segmenteer wat nog steeds wordt uitgezonden. Sommige verzendingen gaan legitiem breed — een winkelwijde uitverkoop, een breaking news-verhaal van een uitgever. Breed is niet hetzelfde als ongesegmenteerd. Het splitsen van een uitzending op gedrag, aankoopgeschiedenis of categorieaffiniteit verhoogt de klikfrequentie op elke sectie en houdt de persoonlijke push-per-bezoekratio van elke abonnee verdedigbaar. Segmentatie is nu een vereiste voor leverbaarheid, geen persoonlijkheidslekkernij — die post bevat het volledige leverbaarheidsargument.

4. Handhaaf één frequentielimiet voor elk kanaal en systeem. De Android 16 cooldown heeft dit concreet gemaakt: uw CRM, uw transactionele laag en uw promotiekalender delen één aandachtsbegroting op het apparaat, ongeacht of ze een dashboard delen. Stel een limiet per abonnee en rustige uren in op platformniveau, waarbij web push, app push en WhatsApp samen worden genomen, zodat vier redelijke systemen niet kunnen uitgroeien tot één misbruikpatroon. Dit werkt alleen als één segmentatiemotor elke verzending ziet — het sterkste praktische argument voor het consolideren van kanalen in plaats van één tool per kanaal te gebruiken.

5. Fix het opt-in moment. Verplaats de toestemmingsprompt achter een actie die intentie aangeeft, gebruik een tweestapsprompt zodat de vraag op browseniveau alleen wordt geactiveerd bij een ja, en accepteer de kleinere, schonere lijst. De acceptatiegraad van de prompt voedt de scoring van Chrome aan beide kanten — stille UI-inschrijving en de beoordeling van storende sites — en een geconsenteerde lijst is ook simpelweg de lijst die klikt.

6. Zorg dat de tekst een classificator overleeft. Eerlijke claims, echte urgentie alleen wanneer de deadline echt is, afzenderidentiteit duidelijk. Op Android leest een ML-model uw titel en body voordat de gebruiker dat doet. Eerlijke tekst was altijd een betere retentiepraktijk; nu is het ook een leverbaarheidsvereiste.

Als u deze zes op PushEngage uitvoert, is de eerlijke samenvatting van waar het product helpt: getriggerde campagnes, RFM- en gedragssegmenten, cross-channel frequentielimieten, rustige uren en per-notificatie omzetattributie zijn allemaal ingebouwd, op abonnementen die alleen factureren voor actieve abonnees — het prijsmodel wijst toevallig dezelfde richting op als de platforms nu afdwingen. Wat geen enkele tool kan doen, is besluiten te stoppen met massale verzendingen; dat deel is beleid, en het is aan u.

Veelgestelde vragen

Waarom worden mijn pushmeldingen in 2026 niet afgeleverd? Controleer vier verdachten op volgorde. Ten eerste, Chrome's automatische intrekking: als het aantal abonnees stilletjes slinkt, verliezen abonnees met weinig betrokkenheid mogelijk de toestemming via Veiligheidscontrole. Ten tweede, Chrome snelheidslimieten: als verzendingen naar grote lijsten plotseling uren duren of uw pushservice HTTP 429-antwoorden logt, bent u waarschijnlijk als storend geclassificeerd. Ten derde, Android-presentatie: op Android 16 gebeurt de levering nog steeds, maar worden bursts gedempt en gegroepeerd, en op nieuwere Pixels landen promotionele pushes in een stille bundel - afgeleverd, ongezien. Ten vierde, de saaie oorzaken die de repressie voorafgingen: verlopen abonnementen, service-worker-fouten en meldinginstellingen op OS-niveau.

Heeft Chrome pushmeldingen verboden? Nee. Chrome legt snelheidslimieten op aan sites die het als storend classificeert (hoog volume, lage betrokkenheid) en trekt toestemmingen in die gebruikers aantoonbaar negeren. Een afzender wiens meldingen worden aangeklikt, wordt door beide mechanismen niet beïnvloed, en Google's tests hebben aangetoond dat afzenders met een lager volume een stijging van de klikfrequenties zagen.

Welke betrokkenheidsratio houdt me veilig voor Chrome's automatische intrekking? Google heeft geen drempels gepubliceerd en elke leverancier die u een veilig getal noemt, raadt maar wat. De gepubliceerde feiten: minder dan 1% van alle meldingen ontvangt enige interactie, en intrekking richt zich op de combinatie van zeer lage betrokkenheid met een hoog verzendvolume. De verdedigbare strategie is om uw klikfrequentie ruim boven die basislijn te houden en te stoppen met het verzenden naar abonnees die gestopt zijn met reageren.

Beïnvloeden de snelheidslimieten van Chrome mijn hele account of slechts één site? De evaluatietaal van Chrome is per site - berichten, prompts en betrokkenheid worden allemaal gemeten tegenover 'een site'. Afzenders die een pushplatform gebruiken, worden geëvalueerd op het gedrag van hun eigen domein, niet op het aggregaat van hun leverancier. Google heeft hierover geen richtlijnen gepubliceerd, dus behandel cross-domein specifieke zaken als onbevestigd.

Wat is er veranderd voor pushmeldingen in Android 16? Drie dingen: meldingen afkoelen (bursts worden progressief gedempt voor maximaal een minuut, standaard ingeschakeld, oproepen en alarmen uitgezonderd), geforceerd groeperen van de meldingen van elke app, en - vanaf de QPR2-update van december 2025 op recente Pixels - de Notification Organizer, die Promoties en Nieuws meldingen standaard in een stille, samengevouwen bundel plaatst. Volledige mechanica in onze Android 16 afkoelgids.

Is de repressie van toepassing op iOS? De beperkingen van Apple gingen er grotendeels aan vooraf: iOS web push vereist dat de gebruiker uw site toevoegt aan hun startscherm, en App Store Richtlijn 4.5.4 vereist expliciete opt-in plus een in-app opt-out voor marketing push. De wijziging van 2025 is Declarative Web Push (iOS 18.4 / Safari 18.5), een eenvoudiger, service-worker-vrij formaat zonder stille push-straf voor declaratieve berichten.

Worden RCS-bedrijfsberichten ook beperkt? Ja, op basis van reputatie. Google kent elke RCS-bedrijfsagent een hoge/gemiddelde/lage reputatie toe op basis van gebruikersfeedback en spamrapporten; agenten met een lage reputatie (inclusief alle nieuwe agenten) worden beperkt in het aantal unieke gebruikers dat per periode van 28 dagen een bericht initieert. De handhaving is live voor promotionele agenten in India vanaf begin 2026, met rapportage over reputatie en spamtrends in de ontwikkelaarsconsole voor iedereen.

Is web push in 2026 nog steeds de moeite waard? Voor afzenders die triggers en segmenten gebruiken, meer dan voorheen: het afgenomen 'spray-and-pray'-verkeer concurreerde vroeger om dezelfde notificatiebalk als jij. De platforms versterken het kanaal voor de afzenders waarvoor het kanaal is gebouwd - en duwen de rest eruit.

Laatst bijgewerkt en wijzigingen {#changelog}

Dit centrum wordt onderhouden als een levende referentie. Conventie: de datum 'Laatst bijgewerkt' verandert alleen bij inhoudelijke updates (wanneer een platform een wijziging uitbrengt, aankondigt of documenteert), niet bij tekstuele correcties. Elke inhoudelijke update krijgt een regel in het wijzigingenoverzicht met een bron. Als u deze pagina citeert, citeer deze dan met de datum van de laatste bijwerking.

• 2026-09-21 — Eerste publicatie. Behandelt: Chrome Push API-limieten (januari 2026), automatische herroeping van Chrome-machtigingen (aangekondigd oktober 2025), Chrome on-device ML-notificatiescreening (mei 2025), Android 16 cooldown + geforceerde groepering (juni 2025), Android 16 QPR2 Notification Organizer (december 2025), Declarative Web Push (iOS 18.4 / Safari 18.5, 2025), RCS-limieten op basis van reputatie en spamtrendanalyse (januari-april 2026), wijzigingen in onbekende afzender en geverifieerde branding van Google Berichten (vanaf oktober 2025).

Is er iets veranderd dat we niet hebben vastgelegd? De snelste manier om het bij ons onder de aandacht te brengen, is via de chatwidget op deze pagina.