Bewijs van opt-in voor meldingen: modelleer toestemming per kanaal

Wat toestemming en bewijs‑van‑opt‑in echt betekenen

Toestemming betekent dat een persoon duidelijk heeft ingestemd met het ontvangen van een specifiek soort bericht via een specifiek kanaal. Dat onderscheid is belangrijk omdat e‑mail, SMS en push niet door gebruikers, carriers, appplatforms of privacywetten hetzelfde worden behandeld. Iemand kan een verzendupdate per e‑mail waarderen, maar zich overvallen voelen door een marketing‑sms.

Bewijs is wat je later kunt laten zien wanneer iemand vraagt: "Waarom heeft u mij een bericht gestuurd?" Bewijs‑van‑opt‑in is geen screenshot van een formulier of een vage aantekening zoals "gebruiker geabonneerd." Het is een record waarmee je kunt herleiden wie instemde, waarop ze instemden, wanneer het gebeurde en hoe het vastgelegd werd.

Als records zwak zijn, ontstaan problemen snel. Support kan onverwachte berichten niet uitleggen, terugbetalingen nemen toe en mensen verliezen vertrouwen. Als een klacht escaleert, kun je ook moeite hebben om te laten zien dat toestemming bestond op het moment dat je het bericht stuurde — en dat is vaak het belangrijkste detail.

Toestemming is meer dan een popup

Veel teams richten zich op de UI‑prompt (checkboxes, toggles, OS‑ toestemmingsschermen) en vergeten de audittrail erachter. Het echte doel is vertrouwen en herleidbaarheid. Een helder toestemmingsmodel maakt het eenvoudiger om elke keer het juiste te doen, zelfs als personeel verandert, systemen migreren of gebruikers van gedachten veranderen.

Een praktisch consent‑record beantwoordt een paar basisvragen:

• Wie stemde in (de gebruikersidentifier en, indien relevant, de bestemming zoals een e‑mailadres of telefoonnummer)
• Wat ze goedkeurden (kanaal en berichttype of doel)
• Wanneer het gebeurde (timestamp in UTC, of timestamp plus tijdzone)
• Hoe het gebeurde (waar de vraag werd getoond en wat de gebruiker zag, inclusief versie en taal)
• Context die helpt bij het oplossen van geschillen indien nodig (bijv. app/device‑info of IP‑adres)

Waarom dit vertrouwen opbouwt

Gebruikers beoordelen je op de momenten die als indringend voelen: een push midden in de nacht, een verrassingstex die kosten met zich meebrengt, een e‑mail waarvan ze zich niet herinneren dat ze zich inschreven. Als je het exacte toestemmingsmoment kunt tonen en het in eenvoudige taal kunt uitleggen, kun je tickets rustig en consistent oplossen.

Als je bouwt met een platform zoals AppMaster, helpt het om toestemming vanaf dag één als first‑class data te behandelen: gestructureerd, doorzoekbaar en moeilijk per ongeluk te overschrijven.

Soorten meldingen en waarom de regels verschillen

Niet alle meldingen worden hetzelfde behandeld omdat ze verschillende doelen dienen en mensen op verschillende plekken bereiken. Als je betrouwbaar bewijs van opt‑in voor meldingen wilt, begin dan met het labelen van berichten op doel en op kanaal.

Transactioneel vs marketing (gewone betekenis)

Transactionele berichten worden veroorzaakt door iets wat de gebruiker deed, of iets wat ze moeten weten om de dienst te kunnen gebruiken. Denk aan wachtwoordresets, betaalbewijzen, beveiligingswaarschuwingen of een wijziging in accountstatus. Mensen verwachten deze en het blokkeren ervan kan de productervaring breken.

Marketingberichten zijn promotioneel. Denk aan nieuwsbrieven, productaanbiedingen, win‑back‑campagnes of "dit is er nieuw"‑mails. Deze moeten optioneel zijn en gebruikers moeten "nee" kunnen zeggen zonder toegang tot kernfuncties te verliezen.

Een praktische regel: als het bericht nodig is om te leveren wat de gebruiker vroeg, is het waarschijnlijk transactioneel. Als het bedoeld is om betrokkenheid of verkoop te verhogen, is het marketing.

Kanalen: e‑mail, SMS, push en in‑app

Kanalen gedragen zich verschillend, dus toestemming en bewijs worden meestal per kanaal bijgehouden, niet als één globale checkbox.

E‑mail wordt vaak voor zowel transactioneel als marketing gebruikt. Veel producten beschouwen transactionele e‑mail als onderdeel van de basisdienst, maar marketing‑e‑mail vereist doorgaans een helder "ja" en een duidelijke manier om te stoppen.

SMS voelt indringender, kan in sommige gevallen kosten met zich meebrengen en kent strikte carrier‑ en providerregels. Behandel SMS‑toestemming als een aparte beslissing.

Push‑meldingen worden door het apparaat‑OS geregeld en door gebruikersinstellingen. Je app kan een device token hebben, maar de gebruiker kan push op elk moment uitschakelen. Dat verandert wat je kunt sturen.

In‑app‑berichten verschijnen binnen het product. Die volgen vaak meer product‑UXregels dan telecomregels, maar gebruikers verwachten nog steeds controle, vooral voor promotionele banners.

Omdat eisen per land en providerbeleid verschillen, kiezen veel teams voor een eenvoudige basislijn: duidelijke opt‑in voor marketing per kanaal, en zorgvuldige documentatie voor alles wat betwist kan worden.

"Soft opt‑in" is een veelvoorkomend grijs gebied. In de praktijk betekent het meestal dat je iemand een bericht stuurt vanwege een bestaande relatie (bijv. ze werden klant) ook al hebben ze geen speciale marketingbox aangevinkt. Zelfs dan is documentatie belangrijk: wat de relatie was, wat je stuurde en hoe iemand zich kan afmelden.

Als je dit in AppMaster bouwt, houd het model eenvoudig: een gebruiker kan instemmen met marketing‑e‑mail maar SMS uitschakelen, terwijl ze toch noodzakelijke transactionele meldingen blijven ontvangen. Die scheiding maakt zowel compliance als vertrouwen eenvoudiger.

Hoe opt‑ins per kanaal te modelleren (data die je moet opslaan)

Als je betrouwbaar bewijs van opt‑in voor meldingen wilt, moet je datamodel specifiek zijn. "Gebruiker stemde in" is niet genoeg. Toestemming hangt af van het kanaal (e‑mail, SMS, push) en het doel (marketing, productupdates, beveiligingswaarschuwingen).

Een praktische aanpak is om toestemming als een eigen record te behandelen, niet als een vinkje dat verborgen zit in het gebruikersprofiel. Eén gebruiker kan veel consentrecords hebben, en elk record moet gekoppeld zijn aan één kanaal en één doel.

De minimale velden die je uit de problemen houden

Begin met een Consent‑record in de vorm: user + channel + purpose + status. Voeg daarna de details toe die het record later begrijpelijk maken.

Minimaal hebben de meeste producten nodig:

• user_id
• channel (email, sms, push - houd het een vaste lijst)
• purpose (marketing, product_updates, account_security - houd het een vaste lijst)
• status (opted_in, opted_out, pending, unknown)
• opted_in_at / opted_out_at

Om giswerk later te vermijden, leg ook vast waar het gebeurde en wanneer het voor het laatst is bevestigd:

• source (signup_form, settings_page, checkout, support_action)
• last_confirmed_at (handig na beleidswijzigingen)

Consent‑tekst snapshots (zodat je kunt bewijzen wat ze zagen)

Toestemming is niet alleen een klik. Het is instemming met specifieke woorden. Sla een consent_text_version (of een korte snapshot_id) op die verwijst naar de exacte tekst die destijds werd getoond.

Houd de snapshot simpel: de boodschap, de taal/locale en wanneer die actief was. Als de tekst verandert, maak dan een nieuwe versie in plaats van de oude te bewerken.

Een compact voorbeeld ziet er zo uit:

{
  "user_id": "u_123",
  "channel": "sms",
  "purpose": "marketing",
  "status": "opted_in",
  "opted_in_at": "2026-01-25T10:15:00Z",
  "source": "checkout",
  "consent_text_version": "sms_mkt_v3",
  "last_confirmed_at": "2026-01-25T10:15:00Z"
}

Als je bouwt met AppMaster, past dit goed in een Data Designer‑model (Consent plus ConsentTextSnapshot) en eenvoudige logica in de Business Process Editor. Het belangrijkste is consistentie: elk kanaal en doel volgt dezelfde structuur zodat rapportage en audits geen scramble worden.

Wat als bewijs telt, en wat je moet vastleggen

"Bewijs" is alles waarmee je later twee vragen kunt beantwoorden: waar stemde de gebruiker mee in, en hoe stemde diegene in? Voor bewijs‑van‑opt‑in voor meldingen wil je records die specifiek zijn, een tijdstempel hebben en gekoppeld zijn aan een echte gebruikersactie (niet alleen "consent = true").

Begin met de actie zelf. Als toestemming wordt gegeven via een checkbox, toggle of double‑opt‑in link, sla dan de interactie op en de exacte tekst die de gebruiker zag (of een versie‑ID). Screenshots schalen zelden; een consent copy/version label doet het vaak beter.

Leg genoeg detail vast om het moment reproduceerbaar te maken:

• action type (vinkje aangezet, toggle omgezet, bevestigingslink aangeklikt)
• timestamp in UTC
• kanaal en doel
• consent text version of policy/version identifier
• paginanaam of schermnaam en taal

Voeg technische context zorgvuldig toe. Het kan helpen bij het oplossen van geschillen, maar verhoogt ook privacyrisico. Voor web kunnen IP en user agent nuttig zijn als dat gepast is. Voor mobiel kun je een device ID overwegen die al in je identiteitsmodel zit, maar vermijd het verzamelen van extra identifiers "voor het geval dat."

Als je via providers verzendt, bewaar dan ook hun identifiers. Provider message IDs (e‑mail, SMS, push) helpen te tonen dat een specifiek consentrecord gebruikt werd voor een specifieke verzending bij onderzoeken naar klachten of afleverproblemen.

Bepaal tenslotte wat je niet opslaat. Goed bewijs betekent niet alles verzamelen. Vermijd het opslaan van volledige berichtinhoud als templates genoeg zijn, en vermijd niet‑relevante apparaatgegevens. Als je deze flow in AppMaster bouwt, behandel bewijsvelden als gevoelig: houd ze consistent en beperk toegang zodat alleen de juiste rollen auditdetails kunnen bekijken.

Stappenplan: zet een consent‑ en bewijsflow op

Begin met besluiten waar je toestemming voor vraagt. Toestemming is niet alleen "meldingen ja/nee." Mensen willen vaak bonnetjes maar geen promoties. Schrijf je notificatiedoelen in eenvoudige taal op en map elk doel naar de kanalen die je wilt gebruiken.

Ontwerp toestemmingsschermen per kanaal in plaats van één gemengde prompt. Elk scherm moet zeggen wat er gestuurd wordt en hoe je het later kunt wijzigen. Houd de bewoording specifiek: "Orderbonnen per e‑mail" is duidelijker dan "transactionele berichten."

Een praktische flow ziet er zo uit:

• definieer doelen en welke een opt‑in vereisen (bijv. marketing vs bonnetjes)
• vraag op het moment dat het logisch is (checkout voor bonnetjes, na onboarding voor tips)
• kies veilige standaardinstellingen (uit voor marketing; alleen aan voor wat nodig is om de dienst te leveren)
• wanneer een gebruiker een toggle wijzigt, schrijf meteen een eventrecord (wie, wat veranderde, wanneer en waar)
• zet consentchecks in het verzendpad zodat niets het kan omzeilen, inclusief admin‑tools en geautomatiseerde jobs

Dat eventrecord is wat later toestemming bewijst. Behandel het als een bankontvangst: append‑only en moeilijk na het feit te wijzigen. In AppMaster houden teams vaak een huidige‑staat tabel voor snelle checks en schrijven ze consent‑events via een Business Process zodat elke update een overeenkomend audit‑item produceert.

Test vóór release opt‑out en randgevallen. Je wilt dat hetzelfde resultaat optreedt of de gebruiker instellingen wijzigt op web, mobiel of via accountverwijdering. Let vooral op:

• afmelden op het ene apparaat terwijl ingelogd op een ander apparaat
• telefoonnummer of e‑mail wijzigen
• app opnieuw installeren (push tokens veranderen)
• gastcheckout vs ingelogde gebruikers
• verwijderde of gedeactiveerde accounts (geen sends, maar bewijs bewaren waar nodig)

Omgaan met opt‑out, wijzigingen en account‑levenscyclus

Opt‑in is maar de helft van het werk. Mensen veranderen van gedachten, wisselen van apparaat, verliezen toegang tot een e‑mail of vragen support om instellingen te wijzigen. Als afmelden lastig is, merken gebruikers dat snel en ziet je "bewijs" er al snel twijfelachtig uit.

Maak opt‑out even eenvoudig als opt‑in. Zet het waar mensen het verwachten: notificatie‑instellingen, de voettekst van marketing‑e‑mails en duidelijke STOP‑instructies voor SMS waar vereist. Verberg het niet achter "contact support" of extra stappen voordat iemand kan vertrekken.

Als je een bevestigingsbericht stuurt, houd het minimaal en gebruik het alleen wanneer nodig of wettelijk verplicht. Een enkele "Je bent afgemeld"‑e‑mail kan nuttig zijn. Herhaalde opvolgberichten zoals "Weet je zeker?" kunnen als spam voelen. Voor SMS wordt vaak één bevestiging na STOP verwacht. Voor push volstaat meestal een stille in‑app statuswijziging.

Account‑levenscyclus is waar veel consent‑systemen breken. Plan vroegtijdig voor deze gevallen:

• Uitgelogde gebruikers: als iemand zich afmeldt voor e‑mail terwijl ze niet zijn ingelogd, registreer het tegen het e‑mailadres, niet alleen tegen een sessie.
• Verwijderde accounts: gehoor aan verwijderingsverzoeken, maar bewaar waar toegestaan een minimaal do‑not‑contact record zodat ze per ongeluk niet opnieuw worden toegevoegd.
• Samengevoegde accounts: ga er nooit van uit dat toestemming mee verhuist; los conflicten op met de meest privacy‑vriendelijke keuze.
• Apparaatwissels: een nieuwe telefoon maakt een nieuw push token; behandel het token als technische data en de push‑toestemming van de gebruiker als de bepalende regel.

Schrijf retentie‑regels op en pas ze consistent toe. Bewaar consentlogs lang genoeg om klachten, audits of chargebacks te beantwoorden, maar bewaar niet meer persoonlijke data dan nodig. Als je gegevens moet verwijderen, beslis dan wat geanonimiseerd kan worden (bijv. het hashen van een e‑mail) terwijl de gebeurtenisgeschiedenis bruikbaar blijft.

Support‑gestuurde wijzigingen hebben een duidelijk intern proces nodig. Beperk wie toestemming kan bewerken, eis een reden‑code (zoals "gebruiker verzocht via chat") en registreer wie de wijziging maakte en wanneer. In AppMaster modelleren teams dit vaak met een kleine PostgreSQL‑tabel voor consent‑events en een tweede tabel voor support‑acties, en gebruiken ze een Business Process om wijzigingen toe te passen en elke keer een audit‑entry te schrijven.

Veelgemaakte fouten die vertrouwen (en je audittrail) breken

Veel teams voegen een consent‑toggle toe en breken die later stilletjes met shortcuts. Het resultaat is voorspelbaar: gebruikers voelen zich bedrogen en wanneer je bewijs van opt‑in nodig hebt, houden de records geen stand.

Een veelvoorkomende val is toestemming behandelen als een enkele globale ja/nee. E‑mail, SMS en push hebben verschillende verwachtingen en vaak verschillende wettelijke regels. Een enkele vlag zoals marketing_ok=true maakt het te gemakkelijk om via een kanaal te verzenden waar de gebruiker nooit mee heeft ingestemd.

Een andere vertrouwen‑killer is onduidelijke keuzedesign. Vooraf aangevinkte vakjes, kleine disclaimers of controls die meerdere doelen bundelen ("Productupdates en aanbiedingen") leiden tot verwarring. Je database kan "geconsenteerd" zeggen, maar je support‑inbox vertelt een ander verhaal.

De fouten die het vaakst zowel vertrouwen als bewijs breken zijn:

• alleen de laatste toestandswaarde opslaan en geschiedenis verwijderen
• de exacte consent‑tekst (en versie) die de gebruiker accepteerde niet opslaan
• "gebruiker heeft ingestemd" loggen zonder kanaal, timestamp en bron
• handmatige campagnes toestaan die consent checks omzeilen
• een verkeerde instelling "fixen" door de database te bewerken, waardoor het verleden verdwijnt

Een typisch falen ziet er zo uit: een gebruiker zet push aan tijdens onboarding, schakelt later marketing‑SMS uit in de instellingen en klaagt vervolgens over een ongewenste sms. Als je systeem het oude record heeft overschreven, kun je niet laten zien wat ze zagen of wanneer ze zich afmelden. Erger nog: je kunt niet bewijzen dat SMS‑toestemming ooit bestond.

Behandel toestemming als financiële geschiedenis: houd de huidige staat voor snelle checks, maar verlies het verleden niet. Handvaten die helpen zijn simpel: scheid toestemming per kanaal en doel, sla een consent text ID en locale op, forceer elke verzendroute door dezelfde consent‑checkstap en schrijf nieuwe events in plaats van oude te bewerken.

Als je in AppMaster bouwt, modelleer consent events als een eigen tabel en dwing de check af in een gedeeld Business Process zodat geautomatiseerde notificaties en operatoracties dezelfde regels volgen.

Snelle checks vóór livegang

Voordat je echte meldingen verzendt, test je consenttrail zoals je betalingen zou testen. Als je niet kunt uitleggen wie heeft ingestemd, via welk kanaal en onder welke bewoording, wed je op gokwerk in plaats van op vertrouwen.

Voor elk kanaal (e‑mail, SMS, push) moet je het moment kunnen tonen waarop de gebruiker instemde en waar het gebeurde. "Waar" moet een specifieke scherm- of formularenaam betekenen, plus of het bij signup, instellingen, checkout of support gebeurde.

Zorg er ook voor dat je de consent‑bewording kunt afspelen. Het is niet genoeg om "marketing=true" op te slaan. Sla de tekstversie (of template‑ID) en de taal op waarin het aan de gebruiker werd getoond. Als de copy later verandert, heb je nog steeds de oude bewoording nodig voor de mensen die er toen mee instemden.

Een korte pre‑ship checklist die de meeste problemen vangt:

• Je kunt timestamp, bron (web, iOS, Android) en de UI‑locatie voor elke opt‑in laten zien.
• Je kunt de exacte consent‑bewording en taal op het moment ophalen.
• De laatste opt‑out overschrijft alles en wordt overal weergegeven (inclusief taken in de wachtrij).
• Support kan "waarom kreeg ik dit?" in minder dan 2 minuten beantwoorden vanuit één gebruikersweergave.
• Consent logs kunnen niet worden bewerkt en toegang is beperkt tot geautoriseerde rollen.

Draai een oefening: laat een collega zich op web inschrijven, op mobiel afmelden en vraag support vervolgens om een uitleg. Als het antwoord graafwerk door ruwe tabellen of meerdere tools vereist, ervaren gebruikers die frictie ook.

Als je op AppMaster bouwt, behandel consentbewijs als een eigen datamodel en proces, niet als een bijproduct. Een dedicated consent log entiteit plus een eenvoudige interne weergave voor support en auditors doet veel, zeker als je beperkt wie het kan exporteren.

Voorbeeldscenario: één gebruiker, drie kanalen, veranderende keuzes

Mina maakt een account op je website om bestellingen te volgen. Tijdens signup ziet ze aparte keuzes voor e‑mail, SMS en push. Ze stemt in met pushmeldingen voor orderupdates (nadat ze de app installeert), houdt marketing‑e‑mail uitgeschakeld en laat SMS leeg.

Een week later installeert ze de mobiele app en logt in. De app vraagt OS‑toestemming voor push en ze accepteert. Dit is waar veel teams in de war raken: OS‑toestemming is niet hetzelfde als je zakelijke toestemming. Je wilt beide, apart vastgelegd, zodat je opt‑in bewijs tijdens een audit helder blijft.

Zo ontwikkelt Mina's verhaal zich en wat support als een duidelijke tijdlijn zou moeten zien.

Tijdlijn en bewijs‑snapshots

1. Web signup (Dag 1)

Je slaat op wat ze koos (of niet koos) op web, plus de context van het verzoek.

2. Mobiele installatie en push‑toestemming (Dag 8)

Je slaat het device token en het OS‑toestemmingsresultaat op, gekoppeld aan Mina's account, plus de exacte promptversie die in‑app werd getoond.

3. Wijziging telefoonnummer (Dag 20)

Ze voegt een nieuw telefoonnummer toe voor leveringscoördinatie. Behandel dit als een nieuwe SMS‑bestemming en eis een verse SMS opt‑in. Neem toestemming van het oude nummer niet mee.

4. SMS ingetrokken (Dag 35)

Ze antwoordt met STOP of schakelt SMS uit in de instellingen. Je slaat het opt‑out‑event op en stopt onmiddellijk met verzenden.

Hoe het bewijsrecord eruit kan zien

Hieronder een vereenvoudigd voorbeeld van het soort audittrail dat support kan lezen wanneer Mina zegt: "Ik heb nooit ingestemd met SMS."

[
  {
    "ts": "2026-01-02T10:14:22Z",
    "user_id": "u_123",
    "channel": "email",
    "purpose": "marketing",
    "action": "no_opt_in",
    "capture": {"surface": "web_signup", "form_version": "signup_v3"},
    "evidence": {"ip": "203.0.113.10", "user_agent": "Chrome"}
  },
  {
    "ts": "2026-01-09T08:03:11Z",
    "user_id": "u_123",
    "channel": "push",
    "purpose": "order_updates",
    "action": "opt_in",
    "capture": {"surface": "ios_app", "prompt_version": "push_prompt_v2"},
    "evidence": {"device_id": "d_77", "os_permission": "granted", "push_token": "..."}
  },
  {
    "ts": "2026-01-21T16:40:05Z",
    "user_id": "u_123",
    "channel": "sms",
    "purpose": "delivery_updates",
    "action": "opt_in",
    "capture": {"surface": "account_settings", "form_version": "sms_optin_v1"},
    "evidence": {"phone": "+15551234567", "verification": "code_confirmed"}
  },
  {
    "ts": "2026-02-05T09:12:44Z",
    "user_id": "u_123",
    "channel": "sms",
    "purpose": "delivery_updates",
    "action": "opt_out",
    "capture": {"surface": "sms_reply", "keyword": "STOP"},
    "evidence": {"phone": "+15551234567"}
  }
]

Als je op een platform zoals AppMaster bouwt, kun je consent events modelleren in de Data Designer en ze appenden via Business Process flows telkens wanneer een gebruiker een toggle aantikt, een code bevestigt of de app een permissieresultaat ontvangt. Wat telt, is dat support met datums, locaties en exacte keuzes kan antwoorden, niet met gissingen.

Volgende stappen: bouw het in je productworkflow

Behandel toestemming als een productfeature, niet als een vinkje. De makkelijkste manier om bewijs van opt‑in voor meldingen te behouden, is het inbouwen in dezelfde workflow die je gebruikt om berichten te verzenden, supporttickets af te handelen en audits uit te voeren.

Begin met een minimaal model dat huidige voorkeur scheidt van historisch bewijs. Een eenvoudig schema dat in de meeste producten werkt:

• Users (identiteit en accountstatus)
• ConsentPreferences (huidige aan/uit per kanaal, en per doel indien nodig)
• ConsentEvents (elke wijziging met tijdstempels en context)
• MessageSends (elke verzendpoging, inclusief de consent‑beslissing op dat moment)

Bepaal wie wat kan zien. Consentbewijs kan IP‑adres, user agent, telefoonnummer of andere gevoelige details bevatten, dus beveilig het met role‑based access. Support heeft vaak een consent‑tijdlijnweergave nodig, maar alleen een kleinere groep zou het mogen exporteren.

Bouw een kleine interne weergave die één vraag snel beantwoordt: "Waarom hebben we deze gebruiker gecontacteerd?" Zoek op gebruiker, filter op kanaal en maak het makkelijk om een tijdlijn te exporteren wanneer dat nodig is.

Maak vervolgens consentchecks automatisch. Elke verzending moet dezelfde logica aanroepen: controleer de nieuwste ConsentPreferences, bevestig dat er een geldig ConsentEvent is voor dat kanaal en doel, en registreer de beslissing in MessageSends, ook wanneer de verzending wordt geblokkeerd.

Als je al AppMaster gebruikt, is een praktisch patroon om de consenttabellen in de Data Designer te houden en de consent‑poort in een gedeeld Business Process te plaatsen dat draait vóór elke e‑mail, SMS of push‑actie. Zo blijven de regels consistent over webapps, backend‑jobs en native mobiele apps.

Een eenvoudige regel houdt stand: als iemand een notificatie kan verzenden zonder door de consent‑check te gaan, zal er vroeg of laat een bug live gaan.