Data Partnerships & Clean Rooms

# Data Partnerships und Clean Rooms

2021 schaffte Apples Prompt zur App Tracking Transparency etwas, was keine Datenschutzregulierung zustande gebracht hatte: Die identifier-basierte Werbewirtschaft brach fast über Nacht zusammen. Allein Meta verbuchte 2022 einen Umsatzverlust von 10 Milliarden Dollar. Interessanter ist aber, was die Überlebenden gemacht haben. Retailer wie Walmart, Kroger und Albertsons stellten fest, dass die First-Party-Kaufdaten in ihren Warehouses plötzlich die wertvollste Währung in der Werbung waren, nicht weil sie sie verkauften, sondern weil sie einen Weg fanden, Marken die *Nutzung* zu erlauben, ohne sie jemals herauszugeben. Dieser Mechanismus war der Data Clean Room. Und ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → machte Walmart Connect zu einem Geschäft mit über 4 Milliarden Dollar jährlichem Werbeumsatz.

In dieser Lektion geht es um die Maschinerie hinter dieser Verschiebung: wie zwei Organisationen Daten kombinieren, um Wert zu schaffen, den keine allein erschließen kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnte, und dabei Regulatoren, Boards und sich gegenseitig nachweisen, dass kein einziger Rohdatensatz den Besitzer gewechselt hat. Als CDO werden Sie immer häufiger gebeten, solche Konstruktionen abzuzeichnen. Falsche Governance setzt Sie regulatorischer Haftung aus; falsche Architektur zerstört die Wirtschaftlichkeit. Beide Fehler landen auf Ihrem Schreibtisch.

Die Wertlogik: Warum überhaupt Daten kombinieren

Beginnen Sie mit der strategischen Frage, denn die Technologie ist ihr nachgelagert. Eine Data Partnership existiert, um eine Informationsasymmetrie zwischen zwei Parteien aufzulösen, die jeweils ein Fragment eines vollständigen Bildes halten.

Nehmen Sie den klassischen Retail-Media-Fall. Eine Konsumgütermarke weiß, wer ihre Werbung gesehen hat, aber nicht, wer das Produkt gekauft hat. Ein Retailer weiß, wer das Produkt gekauft hat, aber nicht, welche Werbung dazu beigetragen hat. Keiner kann Werbewirkung allein messen. Überlagern Sie die Daten über einen gemeinsamen Key, eine gehashte E-Mail, eine Loyalty-ID, und beide Seiten lernen etwas, für das sie zu zahlen bereit sind: Die Marke erhält den echten Return-on-Ad-Spend, der Retailer ein monetarisierbares Measurement-Produkt. Der Wert entsteht *an der Schnittmenge*, und ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ist tatsächlich gegenseitig.

Das ist der Test, den Sie auf jeden Partnerschaftsvorschlag anwenden sollten, der über Ihren Schreibtisch geht: Gibt es eine Berechnung, die für beide Seiten wertvoller ist als die Daten, die jede einbringt? Profitiert nur eine Seite, haben Sie keine Partnerschaft, sondern einen Datenverkauf im Partnerschaftskostüm, und ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → sollte als Verkauf governiert werden.

Drei Archetypen treten immer wieder auf:

• Measurement und Attribution: Zwei Parteien joinen über Identität, um einen Loop zu schließen (Ads → Outcomes). Der Output sind aggregierte Metriken.
• Audience Enrichment und Activation: Die Attribute einer Partei verbessern das Targeting oder Modeling der anderen. Der Output ist ein Segment oder ein Lift-Modell, keine Einzeldatensätze.
• Supply-Chain- und operatives Matching: Partner gleichen gemeinsame Entitäten ab (Lieferungen, Patienten, Fraud-Signale), um gemeinsame Kosten zu senken.

Beachten Sie, was alle gemeinsam haben: Der *Output* ist schmal und aggregiert, während der *Input* sensibel und roh ist. Die gesamte Disziplin der Clean Rooms besteht darin, die Lücke zwischen diesen beiden Dingen zu vergrößern, den Wert des Outputs zu maximieren und die Exposition des Inputs zu minimieren.

Der Clean Room als Architektur der Einschränkung

Ein Data Clean Room lässt sich am besten nicht als Produkt verstehen, sondern als Satz erzwungener Einschränkungen einer gemeinsamen Berechnung. Die Anbieter, Snowflake, Google Ads Data Hub, AWS Clean Rooms, Habu, InfoSum, unterscheiden sich in der Topologie, implementieren aber alle die gleichen vier Controls. Als CDO bewerten Sie jeden Clean Room daran, nicht an Feature-Listen.

Die vier Controls

1. Isolation der Inputs. Die Rohdaten jeder Partei bleiben unter ihrer eigenen Kontrolle. In einem „distributed" Clean Room (InfoSums Modell) bewegen sich die Daten physisch überhaupt nicht, die Berechnung ist föderiert und nur verschlüsselte Zwischenergebnisse überschreiten die Grenze. In einem „centralized" Modell (Snowflakes Data Sharing) liegen die Daten in einer governierten Umgebung, aber keine Partei kann die Zeilen der anderen direkt abfragen.

2. Einschränkung der Operationen. Der Clean Room erlaubt nur vorab genehmigte Query-Typen. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen kein SELECT * ausführen. Sie führen einen genehmigten Join-and-Aggregate aus. Dieses Control unterschätzen die meisten CDOs, und es ist das wichtigste.

3. Aggregation und Output-Gating. Ergebnisse unterhalb einer minimalen Gruppengröße werden unterdrückt. Würde eine Query eine Metrik für ein Segment von 3 Personen zurückgeben, liefert der Clean Room null. Das verhindert Differencing-Angriffe, also die Technik, zwei fast identische Queries auszuführen und die Ergebnisse zu subtrahieren, um eine Einzelperson zu isolieren.

4. Logging und gegenseitige Auditierbarkeit. Jede Query, von beiden Parteien, wird geloggt und ist sichtbar. Keine Seite arbeitet im Dunkeln.

Hier kommt der entscheidende Punkt für eine technische Führungskraft: Die Datenschutzgarantie des Clean Rooms stammt fast vollständig aus Control #3, nicht aus der Verschlüsselung in Control #1. Führungskräfte fixieren sich auf „die Daten bewegen sich nie". Aber ein schlecht konfigurierter Clean Room mit starker Verschlüsselung und *ohne* Output-Gating gibt Einzelpersonen trivial preis. Verschlüsselung schützt Daten im Ruhezustand und in Bewegung; gegen eine legitime Query, die auf die Isolierung einer Person ausgelegt ist, bewirkt sie nichts.

Deshalb ist der Aggregationsschwellenwert Ihr wichtigster einzelner Governance-Parameter. Eine konkrete Konfiguration in AWS Clean Rooms sieht so aus:

analysisRuleAggregation:
  aggregateColumns:
    - columnNames: [purchases]
      function: SUM
  joinColumns: [hashed_email]
  outputConstraints:
    - columnName: user_id
      minimum: 100          # Ergebniszeilen mit <100 Nutzern unterdrücken
      type: COUNT
  dimensionColumns: [campaign_id, region]

Das minimum: 100 ist keine Formalie. Es ist der Unterschied zwischen einem aggregierten Insight und einem Re-Identifikationsvektor. Wenn Ihr Partner darauf drängt, es „für granularere Ergebnisse" zu senken, verstehen Sie genau, was Sie dafür aufgeben.

Die Wahl der Topologie

Die Wahl zwischen centralized und distributed ist eine echte strategische Entscheidung, keine Anbieterpräferenz:

• Centralized (Daten gepoolt in einer gemeinsamen governierten Umgebung) ist schneller aufzubauen, unterstützt reichere Analytics und ist in Ordnung, wenn Sie dem Betreiber der Umgebung vertrauen. Die meisten Retail-Media-Clean-Rooms liegen hier.
• Distributed / föderiert (Daten verlassen keine Partei) ist unverzichtbar, wenn die Daten so stark reguliert sind, dass die Bewegung selbst das Risiko ist, Gesundheitsdaten, grenzüberschreitende Daten unter der DSGVO, oder wenn ein Partner gleichzeitig Wettbewerber ist und Sie nicht tolerieren kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, dass dessen Mitarbeiter *irgendeine* Nähe zu Ihren Zeilen haben.

Der Fehler besteht darin, standardmäßig das zu nehmen, was der Anbieter verkauft. Eine Bank, die mit einem Fintech an Fraud-Signalen arbeitet, und ein Lebensmittelhändler, der mit einem CPG-Hersteller an Ad-Measurement arbeitet, haben unterschiedliche Threat-Models und sollten nicht die gleiche Topologie nutzen.

Die Governance, die ein CDO besitzen muss

Die Technologieanbieter verkaufen Ihnen die Plattform. Das Urteilsvermögen verkaufen sie Ihnen nicht, und es ist das Urteilsvermögen, das Sie aus den Schlagzeilen hält. Hier ist der Governance-Stack, der Ihnen gehört.

Vor dem Join: die Partnerschaftsvereinbarung

Die rechtliche Vereinbarung muss Dinge festlegen, die die meisten Vorlagen auslassen. Bestehen Sie auf:

• Zweckbindung, technisch erzwungen. Der Vertrag sollte die konkret erlaubten Analysen benennen, und diese Analysen sollten eins zu eins auf die konfigurierte Query-Allowlist des Clean Rooms abgebildet sein. Wenn der Vertrag „Measurement" sagt, die Konfiguration aber beliebige Aggregation erlaubt, ist Ihr Vertrag dekorativ.
• Re-Identifikationsverbot mit Zähnen. Ein ausdrückliches Verbot, Einzelpersonen zu isolieren, kombiniert mit Auditrechten und definierten Konsequenzen bei Verstoß. InfoSums Non-Movement-Architektur ist zum Teil eine *rechtliche* Strategie, sie macht die Zusicherung physisch glaubwürdig.
• Eigentum am Output und Downstream-Nutzung. Wem gehört das Modell, das im Clean Room trainiert wurde? Kann ein Lift-Segment exportiert und im nächsten Quartal gegen eine andere Population wiederverwendet werden? Hier sickern Wert und Risiko leise aus. Ein Segment, das aus Ihren Daten gebaut und einmal exportiert wurde, liegt außerhalb Ihrer Kontrolle.
• Datenminimierung beim Input. Bringen Sie nur die Spalten ein, die die genehmigte Berechnung braucht. Wenn Measurement eine gehashte ID und ein Kaufkennzeichen benötigt, laden Sie keine Demografie „für den Fall, dass sie später nützlich ist".

Im Betrieb: die Controls, die Sie überwachen

Clean Rooms scheitern durch Akkumulation, nicht durch einen einzelnen dramatischen Breach. Die benannten Risiken:

Differencing-Angriffe. Ein Partner führt Query A über ein Segment aus, dann Query A′ über das gleiche Segment minus ein bekanntes Attribut, und subtrahiert. Verteidigung: minimale Aggregationsschwellen *plus* Monitoring von Query-Überlappungen *plus* eine Obergrenze für die Gesamtzahl der Queries. Kein einzelnes Control genügt, das ist Defense in Depth.

Averaging-Angriffe. Wiederholte leicht variierte Queries mit hinzugefügtem Rauschen, gemittelt, um das Rauschen auszulöschen. Nutzt Ihr Clean Room Differential Privacy (wie Googles ADH), müssen Sie ein Privacy Budget verwalten, ein endliches Epsilon, das jede Query verbraucht. Ist das Budget aufgebraucht, stoppt das Querying. Behandeln Sie Epsilon als governierte Ressource mit einem Owner, nicht als Default, den irgendwer einmal gesetzt hat.

Das Insider-mit-Kontext-Problem. Aggregierte Outputs sind nur relativ zu dem „anonym", was der Empfänger bereits weiß. Ein Partner, der schon umfangreiche Daten über die gleiche Population hält, kann Ihre Aggregate mit seinem Vorwissen kombinieren und re-identifizieren. Ihr Aggregationsschwellenwert sollte also auf Basis *des wahrscheinlichen Zusatzwissens des Partners* gesetzt werden, nicht nach einem abstrakten Standard. Eine Schwelle von 50 kann gegenüber einem Fremden sicher und gegenüber einem Unternehmen mit überlappenden Identitätsdaten leichtsinnig sein.

Das Governance-Entscheidungsframework

Schicken Sie jede vorgeschlagene Partnerschaft durch vier Gates, in dieser Reihenfolge. Fällt eines durch, stoppen Sie:

1. Rechtsgrundlage: Haben wir eine rechtmäßige Grundlage für diese spezifische Nutzung dieser spezifischen Daten unter jedem anwendbaren Regime? (Der Umfang der Einwilligung ist die Stelle, an der Retail-Media-Deals am häufigsten scheitern.)

2. Wertsymmetrie: Ist der gemeinsame Output wertvoller als das, was wir einbringen, und ist dieser Wert gegenseitig?

3. Technische Eindämmung: Machen die konfigurierten Controls (Topologie, Allowlist, Schwellenwerte, Budget) die vertraglichen Versprechen physisch wahr?

4. Reputationstoleranz: Wenn das zutreffend beschrieben auf der Titelseite stünde, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnten wir es verteidigen? Rechtmäßig und verteidigbar sind nicht derselbe Standard.

Gate 4 ist das, was CDOs überspringen und bereuen. Cambridge Analytica war im engen Sinne wohl von Facebooks damaligen Plattformbedingungen erlaubt. Verteidigbar war es nicht.

Anwendung: das Montagmorgen-Playbook

Sie haben einen Partnerschaftsvorschlag auf dem Tisch: Ein großes Medienunternehmen will Audiences mit Ihren First-Party-Daten für ein Co-Selling-Motion kombinieren. So gehen Sie konkret vor.

Woche eins: die Wertlogik hinterfragen, bevor Sie Technologie anfassen. Schreiben Sie in einem Satz die gemeinsame Berechnung und wer davon profitiert. Wenn Sie das nicht kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen, gibt es keinen Deal. Identifizieren Sie dann die minimalen Datenspalten, die jede Seite beitragen muss, damit die Berechnung funktioniert. Diese Spaltenliste wird zur Input-Spezifikation für alles Weitere.

Woche zwei: den Partner spezifisch threat-modellieren. Was weiß dieser Partner bereits über die überlappende Population? Diese Antwort bestimmt Ihren Aggregationsschwellenwert und ob Sie eine föderierte Topologie brauchen. Ein Partner mit tiefen Identity Graphs ist ein höheres Re-Identifikationsrisiko als einer ohne, unabhängig von seinen guten Absichten.

Woche drei: Vertrag und Konfiguration als ein einziges Artefakt ausrichten. Lassen Sie nicht Legal die Vereinbarung entwerfen, während Engineering die Plattform isoliert konfiguriert. Jeder erlaubte Zweck im Vertrag muss einer allowlisteten Query entsprechen; jede verbotene Nutzung muss in der Konfiguration blockiert und nicht nur in Prosa untersagt sein. Widersprechen sich diese beiden Dokumente, haben Sie einen latenten Breach.

Laufend: die Outputs governieren, nicht nur die Inputs. Der verführerische Fehler bei Clean Rooms ist der Glaube, die Arbeit sei erledigt, sobald die Rohdaten geschützt sind. Der Wert und das Restrisiko liegen in dem, was den Raum verlässt. Führen Sie ein Register über jedes erzeugte Modell und Segment, seine erlaubten Nutzungen und sein Ablaufdatum. Ein Lift-Segment ist ein Derivat personenbezogener Daten und sollte verfallen, nicht unbegrenzt fortbestehen.

Eine organisatorische Anmerkung: Clean Rooms erzeugen eine neue interne Stakeholder-Kollision. Ihr Commercial-Team will mehr Queries und niedrigere Schwellenwerte; Ihr Privacy-Team will weniger und höhere. Entscheiden Sie das nicht ad hoc. Etablieren Sie ein festes Review, dasselbe Governance-Gremium, das Sie auch anderswo nutzen, mit der Befugnis, Schwellenwerte und Privacy Budgets als Policy festzulegen. Der Parameter, der Ihre regulatorische Exposition bestimmt, sollte nicht von dem gesetzt werden, der das Ticket einreicht.

Key Takeaways

1. Die Datenschutzgarantie liegt im Output-Gating, nicht in der Verschlüsselung. Setzen und verteidigen Sie den minimalen Aggregationsschwellenwert als Ihren wichtigsten einzelnen Parameter, und kalibrieren Sie ihn auf das, was Ihr konkreter Partner schon weiß, nicht auf einen generischen Standard.

2. Machen Sie Vertrag und Konfiguration zu einem Artefakt. Jeder erlaubte Zweck muss auf eine allowlistete Query abgebildet sein; jedes Verbot muss in der Konfiguration erzwungen werden. Prosa, die die Plattform nicht durchsetzt, ist dekorativ.

3. Governieren Sie die Outputs, nicht nur die Inputs. Modelle und Segmente, die im Clean Room gebaut werden, sind Derivate personenbezogener Daten. Führen Sie ein Register mit erlaubten Nutzungen und Ablaufdaten, das Restrisiko verlässt den Raum mit den Ergebnissen.

4. Schicken Sie jede Partnerschaft durch die vier Gates, Rechtsgrundlage, Wertsymmetrie, technische Eindämmung, Reputationstoleranz, und behandeln Sie Gate vier als nicht verhandelbar. Rechtmäßig und verteidigbar sind unterschiedliche Standards, und in der Lücke dazwischen enden Karrieren.

5. Wählen Sie die Topologie aus dem Threat-Model, nicht vom Anbieter. Föderiert, wenn ein Partner Wettbewerber ist oder die Datenbewegung selbst das regulierte Risiko darstellt; centralized, wenn Sie der Umgebung vertrauen und reichere Analytics brauchen.