Einwilligungs- und Präferenzdatensätze als Daten: was wann und über welche Oberfläche gewählt wurde

Worum es geht

Ein Präferenzdatensatz ist ein Append-only-Fakt: welche Person oder welches Gerät, welcher Zweck, welche Entscheidung (zugestimmt, abgelehnt, widerrufen), wann, über welche Oberfläche (Banner-Version, Einstellungsseite, API-Aufruf, ein Protokollsignal) und welche Textversion angezeigt wurde. Der aktuelle Zustand wird aus dem jeweils letzten Datensatz pro betroffener Person und Zweck abgeleitet; er ist kein Boolean in der Benutzerzeile. Manche Entscheidungen treffen als Protokollsignale ein: Der Editor's Draft von Global Privacy Control (W3C Privacy Working Group) definiert ein Anfrage-Header-Feld Sec-GPC mit dem Wert 1 sowie eine passende DOM-Eigenschaft, die die Präferenz einer Person gegenüber der Website übermittelt. Eine Anwendung behandelt ein solches Signal als einen weiteren Input für den Datensatz, mit vermerkter Quelle; was eine Website als Reaktion darauf tun muss, liegt ausserhalb dieses Artikels.

Warum es wichtig ist

Zwei Fragen kommen später und beide brauchen Historie: «Was hatte diese Person zum Zeitpunkt des Versands jener E-Mail gewählt?» und «Welche Benutzer waren vom Banner-Fehler zwischen den Versionen 4 und 5 betroffen?». Ein Boolean beantwortet keine von beiden. Nachgelagerte Systeme (Mailversand, Analyse-Pipeline, Tag-Manager) brauchen eine Abfrage, die billig und eindeutig ist, und eine Vorfallsanalyse braucht die Abfolge der Ereignisse.

So wird es angewendet

• Tabelle preference_events(subject_id, purpose, choice, recorded_at, source, text_version, evidence); Zeitstempel in UTC, geschrieben in RFC-3339-Form; Zeilen werden nie aktualisiert oder gelöscht, ausser gemäss dem Aufbewahrungsplan.
• preference_current pro (Subjekt, Zweck) per Trigger oder periodischem Job materialisieren, und jeden Konsumenten nur diese Sicht lesen lassen.
• Zwecke als Konstanten auf Code-Ebene aufzählen; ein neuer Zweck ist ein neuer Datensatz, nie eine unterstellte Erweiterung eines alten.
• Die Kennung oder den Hash des Textes, den die Person gesehen hat, mit dem Ereignis speichern, damit eine Formulierungsänderung in den Daten sichtbar wird.
• Die Präferenz am Verwendungsort anwenden: Der Mailjob prüft preference_current zum Sendezeitpunkt, nicht zum Zeitpunkt der Einreihung.
• Widerrufe über ein Outbox-Ereignis mit Wiederholungen an Dritte weitergeben und die Bestätigung als weiteres Ereignis erfassen.

Stolpersteine

Standardwerte, die aufgezeichnet werden, als wären sie Entscheidungen gewesen. Entscheidungen, die nur in einem Cookie gespeichert sind, das mit dem Browser verschwindet. Zwecke, die so gekoppelt sind, dass «Marketing» drei Dinge bedeutet. Kein Index auf (subject_id, purpose, recorded_at DESC). Konsumenten, die den Boolean stundenlang zwischenspeichern. Löschen der Ereignishistorie bei einer Kontolöschung, ohne den minimalen Datensatz zu behalten, der nötig ist, um einen Opt-out danach weiterhin zu respektieren.