Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Consent preference keeper series ~5 min read

How a consent event gets recorded

The evidence is only worth anything if it was captured at the time, and the specific thing that gets lost is the wording. A record saying somebody agreed on the sign-up form is worth very little once the sign-up form has been rewritten twice.

Key takeaways

  • Store the exact wording shown, not a reference to a page that will change.
  • Capture the source, the timestamp, the purpose and proof it was that person.
  • Purposes are few and separate: three or four, not fifteen.
  • A double opt-in produces two events, and the second is the one that counts.
  • Never write an event on behalf of somebody. Every event has a real action behind it.

What one event holds

person        a stable identifier — not just an email address
purpose       marketing | service | orders | research
state         granted | withdrawn
at            2026-08-07T10:14:02Z
source        checkout_form | preference_centre | unsubscribe_link |
              staff_entry | import
wording       the exact text shown, verbatim, stored inline
page          the URL, for context only
proof         signed token, session id, or a staff member’s name
channel       email | sms | post

The wording field is the one that matters and the one most often implemented as a reference to a version number or a page. Both are worthless in practice: version numbers get reused, and pages get rewritten without anybody thinking about the consent record. A few hundred bytes of verbatim text per event removes the whole problem.

Recording it

How a consent event is captured and recordedA vertical chain of five steps entered by a box labelled Somebody acts, by ticking, clicking or asking. Step one asks whether there is a real action rather than an inference; if not it exits to Do not record, noting that a purchase is not consent. Step two captures the wording exactly as shown, verbatim. Step three captures the proof: a token, a session, or a staff member's name. Step four appends the event to an append-only event log and never updates. Step five invalidates the cache, because the state changes now. A note says the first branch is the important one, because convenience is where consent records go wrong.AWS ACCOUNTSomebody actsticks, clicks, or asksIs there a real action?not an inferenceDo not recorda purchase is not consentnoCapture the wordingas shown, verbatimCapture the prooftoken, session, or a nameAppend the eventnever updateEvent logappend-onlyInvalidate the cachestate changes nowThe first branch is the important one. Convenience is where consent records go wrong.
Fig 1. How one event is recorded. The refusal at the first step is what keeps the record honest, and it is the step under the most pressure from people who want a bigger list.
  • Database
  • App integration
  • Security & identity
  • Management
  • Front-end & mobile

Never infer

The pressure to infer is constant and always framed as reasonable. They bought something, so they must want to hear about similar things. They filled in a contact form, so they are interested. They are an existing customer, so a newsletter is fine.

Each of those may be lawful under some basis in some jurisdiction and none of them is consent, and a system that records them as consent produces a log that cannot be trusted for the things that genuinely were. If a different lawful basis applies, that is a separate field with a separate name — not a consent event with a shrug behind it.

How many purposes

PurposeCoversTypical basis
OrdersConfirmations, dispatch, deliveryNecessary for the contract, not consent
ServiceOutages, changes to terms, safetyLegitimate interest, usually
MarketingNewsletters, offers, campaignsConsent
ResearchSurveys, feedback requestsConsent, usually separate

Four is about right. Fifteen granular purposes produce a preference centre nobody completes and a resolver nobody can reason about; one combined purpose produces the failure where withdrawing from marketing stops order confirmations.

The first two rows are worth noting: they are not consent at all, and recording them in the same system with an explicit basis field is better than pretending they are, because the sending systems still need to ask the same question and get a correct answer.

Double opt-in

How a double opt-in produces two consent eventsA horizontal row of five boxes. Form submitted: an event recording requested. Confirmation sent: one email. Link clicked: an event recording granted. Both kept: the pair together is the evidence. Never clicked: which is not consent and expires. A note says the unclicked case is the common one and must not resolve to granted.DOUBLE OPT-IN IS TWO EVENTSForm submittedevent: requestedConfirmation sentone emailLink clickedevent: grantedBoth keptthe pair is the evidenceNever clickednot consent, and it expiresThe unclicked case is the common one and it must not resolve to granted.
Fig 2. How a double opt-in is recorded. Two events rather than one, and the unconfirmed state is a real state rather than a pending version of granted.
  • App integration
  • Machine learning
  • Management
  • Front-end & mobile

The pair is stronger evidence than either event alone: a request from a form plus a confirmation click from an address that received an email is close to conclusive that the person controlling that address agreed.

The unconfirmed request expiring rather than lingering matters, because a months-old unconfirmed request sitting in the log is exactly the thing that somebody later resolves as “they did sign up” when they did not.

Next: answering the question.

All posts