Data Partnerships & Clean Rooms

Data Partnerships und Clean Rooms

2021 gelang Apples App-Tracking-Transparency-Prompt etwas, das keine Datenschutzregulierung geschafft hatte: Die auf Identifiern basierende Werbeökonomie brach praktisch über Nacht zusammen. Allein Meta verbuchte 2022 einen Umsatzverlust von 10 Milliarden Dollar. Interessanter ist aber, was die Überlebenden taten. Händler wie Walmart, Kroger und Albertsons entdeckten, dass die First-Party-Kaufdaten in ihren Warehouses plötzlich die wertvollste Währung im Advertising waren, nicht weil sie sie verkauften, sondern weil sie einen Weg fanden, Marken diese Daten *nutzen* zu lassen, ohne sie jemals herauszugeben. Dieser Mechanismus war der Data Clean Room. Und er 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 kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnte, und dabei Regulierern, Boards und einander gegenüber belegen, dass kein einziger Rohdatensatz die Seiten gewechselt hat. Als CDO werden Sie immer häufiger gebeten, solche Konstruktionen freizugeben. Fehler in der Governance setzen Sie regulatorischer Haftung aus; Fehler in der Architektur zerstören die Ökonomie. Beide Fehler landen auf Ihrem Tisch.

Die Wertlogik: Warum überhaupt Daten kombinieren

Beginnen Sie mit der strategischen Frage, denn die Technologie folgt ihr nachgelagert. Eine Data Partnership existiert, um eine Informationsasymmetrie zwischen zwei Parteien aufzulösen, von denen jede nur ein Fragment des Gesamtbildes hält.

Nehmen Sie den klassischen Retail-Media-Fall. Eine CPG-Marke weiß, wer ihre Werbung gesehen hat, aber nicht, wer das Produkt gekauft hat. Ein Händler weiß, wer das Produkt gekauft hat, aber nicht, welche Werbung die Person beeinflusst hat. Keiner kann Werbewirkung allein messen. Überlagern Sie die Daten über einen gemeinsamen Key, eine gehashte E-Mail, eine Loyalty-ID, und beide Seiten erfahren etwas, für das sich zu zahlen lohnt: Die Marke erhält einen echten Return on Ad Spend, der Händler ein monetarisierbares Measurement-Produkt. Der Wert entsteht *an der Schnittmenge*, und ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist tatsächlich gegenseitig.

Das ist der Test, den Sie auf jeden Partnerschaftsvorschlag anwenden sollten, der Ihren Tisch erreicht: 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 er sollte als Verkauf governt werden.

Drei Archetypen tauchen 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 Modelling der anderen. Der Output ist ein Segment oder ein Lift-Modell, keine Einzeldatensätze.
• Supply-Chain- und operatives Matching: Partner reconcilen gemeinsame Entitäten (Lieferungen, Patienten, Fraud-Signale), um kollektive Kosten zu senken.

Beachten Sie, was allen gemeinsam ist: Der *Output* ist schmal und aggregiert, während der *Input* sensibel und roh ist. Die gesamte Disziplin der Clean Rooms dreht sich darum, den Abstand 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 Beschränkung

Einen Data Clean Room versteht man am besten nicht als Produkt, sondern als Set erzwungener Beschränkungen für eine gemeinsame 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. Bewerten Sie als CDO jeden Clean Room an diesen, nicht an Feature-Listen.

Die vier Controls

1. Isolation der Inputs. Die Rohdaten jeder Partei bleiben unter deren eigener Kontrolle. In einem „distributed" Clean Room (das Modell von InfoSum) bewegen sich die Daten physisch überhaupt nicht, die Berechnung ist federated und nur verschlüsselte Zwischenergebnisse überschreiten die Grenze. In einem „centralized" Modell (Snowflakes Data Sharing) liegen die Daten in einer governten Umgebung, aber keine Partei kann die Rows der anderen direkt abfragen.

2. Beschränkung der Operationen. Der Clean Room erlaubt nur vorab genehmigte Query-Typen. Sie kö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 nahezu identische Queries auszuführen und die Ergebnisse voneinander abzuziehen, um eine einzelne Person zu isolieren.

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

Hier die entscheidende Erkenntnis für eine technische Führungskraft: Die Privacy-Garantie des Clean Rooms kommt 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 at rest und in motion; gegen eine legitime Query, die darauf ausgelegt ist, eine Person zu isolieren, hilft sie nicht.

Deshalb ist der Aggregations-Threshold Ihr wichtigster 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          # jede Output-Zeile 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-Identifikations-Vektor. Wenn Ihr Partner drängt, es „für granularere Ergebnisse" zu senken, sollten Sie genau verstehen, was Sie dafür hergeben.

Die Topologie wählen

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

• Centralized (Daten gepoolt in einer gemeinsamen governten Umgebung) ist schneller aufzubauen, unterstützt reichere Analytics und ist unproblematisch, wenn Sie dem Betreiber der Umgebung vertrauen. Die meisten Retail-Media-Clean-Rooms liegen hier.
• Distributed / federated (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 DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen →, oder wenn ein Partner gleichzeitig Wettbewerber ist und Sie nicht tolerieren können, dass dessen Mitarbeiter *irgendeine* Nähe zu Ihren Rows haben.

Der Fehler ist, standardmäßig 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 Ad Measurement betreibt, haben unterschiedliche Threat Models und sollten nicht dieselbe Topologie verwenden.

Die Governance, die ein CDO verantworten muss

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

Vor dem Join: die Partnerschaftsvereinbarung

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

• Zweckbindung, rechnerisch erzwungen. Der Vertrag sollte die konkret erlaubten Analysen benennen, und diese Analysen sollten eins zu eins auf die konfigurierte Query-Allowlist des Clean Rooms abbilden. Wenn der Vertrag „Measurement" sagt, die Konfiguration aber beliebige Aggregation erlaubt, ist Ihr Vertrag Dekoration.
• Ein Re-Identifikationsverbot mit Zähnen. Ein ausdrückliches Verbot, Einzelpersonen zu isolieren, verbunden mit Auditrechten und definierten Konsequenzen bei Verstößen. InfoSums Non-Movement-Architektur ist teilweise eine *rechtliche* Strategie, sie macht die Zusage physisch glaubwürdig.
• Eigentum am Output und Downstream-Nutzung. Wer besitzt das Modell, das im Clean Room trainiert wurde? Darf 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 wurde, ist nach dem Export 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 Kauf-Flag benötigt, laden Sie keine Demografie „für den Fall, dass sie später nützlich ist".

Im Betrieb: die Controls, die Sie monitoren

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 dasselbe Segment minus ein bekanntes Attribut, und subtrahiert. Verteidigung: minimale Aggregations-Thresholds *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 Noise, gemittelt, um den Noise auszugleichen. Wenn Ihr Clean Room Differential Privacy nutzt (wie Googles ADH), müssen Sie ein Privacy Budget managen, ein endliches Epsilon, das jede Query verbraucht. Ist das Budget erschöpft, stoppt das Querying. Behandeln Sie Epsilon als governte Ressource mit einem Owner, nicht als Default, den irgendwann einmal jemand 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 dieselbe Population hält, kann Ihre Aggregate mit seinem Vorwissen kombinieren und re-identifizieren. Das heißt: Ihr Aggregations-Threshold sollte anhand *des wahrscheinlichen Zusatzwissens des Partners* gesetzt werden, nicht anhand eines abstrakten Standards. Ein Threshold von 50 kann gegenüber einem Fremden sicher und gegenüber einem Unternehmen, das schon überlappende Identitätsdaten hält, fahrlässig 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 für diese spezifische Nutzung dieser spezifischen Daten unter jedem anwendbaren Regime eine Rechtsgrundlage? (Am Umfang der Consent scheitern Retail-Media-Deals am häufigsten.)
2. Wertsymmetrie: Ist der gemeinsame Output wertvoller als das, was wir einbringen, und ist dieser Wert gegenseitig?
3. Technisches Containment: Machen die konfigurierten Controls (Topologie, Allowlist, Thresholds, Budget) die vertraglichen Versprechen physisch wahr?
4. Reputationstoleranz: Wenn das korrekt beschrieben auf der Titelseite erschiene, könnten wir es verteidigen? Legal und verteidigbar sind nicht derselbe Standard.

Gate 4 ist das, welches CDOs überspringen und dann bedauern. Cambridge Analytica war, streng genommen, nach Facebooks damaligen Plattformbedingungen wohl zulässig. Verteidigbar war es nicht.

Anwendung: das Playbook für Montagmorgen

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

Woche eins: die Wertlogik hinterfragen, bevor Sie Technologie anfassen. Schreiben Sie in einem Satz auf, was die gemeinsame Berechnung ist und wer davon profitiert. Wenn Sie das nicht können, gibt es keinen Deal. Identifizieren Sie dann die minimalen Datenspalten, die jede Seite einbringen muss, damit die Berechnung funktioniert. Diese Spaltenliste wird zur Input-Spezifikation für alles Nachgelagerte.

Woche zwei: den Partner konkret threat-modeln. Was weiß dieser Partner schon über die überlappende Population? Diese Antwort setzt Ihren Aggregations-Threshold und bestimmt, ob Sie eine federated Topologie brauchen. Ein Partner mit tiefen Identity Graphs ist ein höheres Re-Identifikationsrisiko als einer ohne, unabhängig von guten Absichten.

Woche drei: Vertrag und Konfiguration als ein einziges Artefakt ausrichten. Lassen Sie nicht die Rechtsabteilung den Vertrag entwerfen, während Engineering isoliert die Plattform konfiguriert. Jeder im Vertrag erlaubte Zweck muss einer allowlisteten Query entsprechen; jede verbotene Nutzung muss in der Konfiguration blockiert sein, nicht bloß in Prosa untersagt. Wenn diese beiden Dokumente auseinandergehen, haben Sie einen latenten Verstoß.

Laufend: die Outputs governen, nicht nur die Inputs. Der verführerische Fehler bei Clean Rooms ist der Glaube, die Arbeit endet, wenn die Rohdaten geschützt sind. Der Wert, und das Restrisiko, liegt in dem, was den Raum verlässt. Führen Sie ein Register über jedes produzierte Modell und Segment, seine erlaubten Nutzungen und sein Verfallsdatum. Ein Lift-Segment ist ein Derivat personenbezogener Daten und sollte verfallen, nicht unbegrenzt bestehen.

Eine organisatorische Anmerkung: Clean Rooms erzeugen eine neue interne Stakeholder-Kollision. Ihr Commercial-Team will mehr Queries und niedrigere Thresholds; Ihr Privacy-Team will weniger und höhere. Entscheiden Sie das nicht ad hoc. Etablieren Sie ein ständiges Review, dasselbe Governance-Gremium, das Sie auch anderswo nutzen, mit der Befugnis, Thresholds 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 Privacy-Garantie steckt im Output-Gating, nicht in der Verschlüsselung. Setzen und verteidigen Sie den minimalen Aggregations-Threshold als Ihren wichtigsten Parameter und kalibrieren Sie ihn an dem, was Ihr konkreter Partner schon weiß, nicht an einem generischen Standard.

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

1. Governen 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 Verfallsdaten, das Restrisiko verlässt den Raum mit den Ergebnissen.

1. Schicken Sie jede Partnerschaft durch die vier Gates, Rechtsgrundlage, Wertsymmetrie, technisches Containment, Reputationstoleranz, und behandeln Sie Gate vier als nicht verhandelbar. Legal und verteidigbar sind unterschiedliche Standards, und im Abstand zwischen ihnen enden Karrieren.

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