Consent and preference records as data: what was chosen, when and through which surface

What it is

A preference record is an append-only fact: which person or device, which purpose, which choice (opted in, opted out, withdrawn), when, through which surface (banner version, settings page, API call, a protocol signal), and which text version was shown. The current state is derived from the latest record per subject and purpose; it is not a boolean on the user row. Some choices arrive as protocol signals: the Global Privacy Control editor's draft (W3C Privacy Working Group) defines a Sec-GPC request header field whose value is 1 and a matching DOM property, conveying a person's preference to the site. An application treats such a signal as one more input to the record, with its source noted; what a site must do in response is outside this article.

Why it matters

Two questions arrive later and both need history: "what had this person chosen at the time that email was sent?" and "which users were affected by the banner bug between versions 4 and 5?" A boolean answers neither. Downstream systems (mail sender, analytics pipeline, tag manager) need a query that is cheap and unambiguous, and an incident review needs the sequence of events.

How to apply

• Table preference_events(subject_id, purpose, choice, recorded_at, source, text_version, evidence); timestamps in UTC written in RFC 3339 form; rows are never updated or deleted except under the retention schedule.
• Materialise preference_current per (subject, purpose) with a trigger or a periodic job, and let every consumer read only that view.
• Enumerate purposes as code-level constants; a new purpose is a new record, never an implied extension of an old one.
• Store the identifier or hash of the text the person saw with the event, so a change of wording is visible in the data.
• Apply the preference at the point of use: the mail job checks preference_current at send time, not at enqueue time.
• Propagate withdrawals to third parties through an outbox event with retries, and record the acknowledgement as another event.

Pitfalls

Defaults recorded as if they were choices. Choices stored only in a cookie that disappears with the browser. Purposes coupled so that "marketing" means three things. No index on (subject_id, purpose, recorded_at DESC). Consumers caching the boolean for hours. Deleting the event history during account deletion without keeping the minimal record needed to honour an opt-out afterwards.