Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Benutzerdefinierte Analyseregel in AWS Clean Rooms

In AWS Clean Rooms ist eine benutzerdefinierte Analyseregel eine neue Art von Analyseregel, mit der benutzerdefinierte Abfragen für die konfigurierte Tabelle ausgeführt werden können. Benutzerdefinierte SQL-Abfragen sind weiterhin darauf beschränkt, nur den SELECT Befehl zu verwenden, können jedoch mehr SQL-Konstrukte als Aggregations - und Struktur und Syntax von Abfragen auflisten Listenabfragen verwenden (z. B. Fensterfunktionen, OUTER JOIN, CTEs oder Unterabfragen; eine vollständige Liste finden Sie in der AWS Clean Rooms SQL-Referenz). Benutzerdefinierte SQL-Abfragen müssen keiner Abfragestruktur wie Struktur und Syntax von Aggregationsabfragen Aggregations- und Listenabfragen folgen. Struktur und Syntax von Abfragen auflisten

Die benutzerdefinierte Analyseregel unterstützt komplexere Anwendungsfälle als die, die von der Regel zur Aggregation und Listenanalyse unterstützt werden können, wie z. B. benutzerdefinierte Attributionsanalysen, Benchmarking, Inkrementalitätsanalysen und Zielgruppenermittlung. Dies gilt zusätzlich zu einer Obermenge der Anwendungsfälle, die von der Aggregations- und Listenanalyseregel unterstützt werden.

Die benutzerdefinierte Analyseregel unterstützt auch differenzierten Datenschutz. Differentieller Datenschutz ist ein mathematisch strenger Rahmen für den Datenschutz. Weitere Informationen finden Sie unter AWS Clean Rooms Differenzierter Datenschutz. Wenn Sie eine Analysevorlage erstellen, überprüft AWS Clean Rooms Differential Privacy die Vorlage, um festzustellen, ob sie mit der allgemeinen Abfragestruktur für Differential Privacy kompatibel ist. AWS Clean Rooms Diese Überprüfung stellt sicher, dass Sie keine Analysevorlage erstellen, die mit einer Tabelle, die durch Differential Privacy geschützt ist, nicht zulässig ist.

Um die benutzerdefinierte Analyseregel zu konfigurieren, können Datenbesitzer festlegen, dass bestimmte benutzerdefinierte Abfragen, die in Analysevorlagen gespeichert sind, auf ihren konfigurierten Tabellen ausgeführt werden. Datenbesitzer überprüfen die Analysevorlagen, bevor sie sie der zulässigen Analysesteuerung in der benutzerdefinierten Analyseregel hinzufügen. Analysevorlagen sind nur in der Kollaboration verfügbar und sichtbar, in der sie erstellt wurden (auch wenn die Tabelle anderen Kollaborationen zugeordnet ist). Sie können nur von dem Mitglied ausgeführt werden, das Abfragen in dieser Kollaboration durchführen kann.

Alternativ können sich Mitglieder dafür entscheiden, anderen Mitgliedern (Abfrageanbietern) zu gestatten, Abfragen ohne Überprüfung zu erstellen. Mitglieder fügen in der benutzerdefinierten Analyseregel Konten von Abfrageanbietern hinzu, die von den zulässigen Abfrageanbietern kontrolliert werden. Wenn der Abfrageanbieter das Mitglied ist, das Abfragen durchführen kann, können sie jede Abfrage direkt in der konfigurierten Tabelle ausführen. Abfrageanbieter könnten Abfragen auch erstellen, indem sie Analysevorlagen erstellen. Alle Abfragen, die von den Abfrageanbietern erstellt wurden, dürfen in allen Kollaborationen, in denen die Tabelle vorhanden AWS-Konto ist und die Tabelle verknüpft ist, automatisch auf der Tabelle ausgeführt werden.

Diese Seite enthält die folgenden Abschnitte:

Die benutzerdefinierte Analyseregel unterstützt die folgenden datenschutzfreundlichen Steuerelemente:

Regelstruktur für benutzerdefinierte Analysen

Die folgende vordefinierte Struktur zeigt die verfügbaren Steuerelemente in einer benutzerdefinierten Analyseregel. Schließen Sie nur die Steuerelemente ein, die Sie für Ihren Anwendungsfall benötigen. Der userIdentifier Wert im differentialPrivacy Steuerelement ist die Spalte, die Ihre Benutzer eindeutig identifiziert, z. B. user_id. Wenn Sie in einer Kollaboration zwei oder mehr Tabellen mit aktiviertem differentiellem Datenschutz haben, AWS Clean Rooms müssen Sie in beiden Analyseregeln dieselbe Spalte wie die Benutzer-ID-Spalte konfigurieren. Dadurch bleibt eine konsistente Definition der Benutzer in allen Tabellen erhalten.

{
  "allowedAnalyses": ["ANY_QUERY"] | string[],
  "allowedAnalysisProviders": [],
  "disallowedOutputColumns": [],
  "aggregationThresholds": [
    {
      "identityColumns": [],
      "minimumIdentityCount": number,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY" | "ANY_EXPRESSION",
      "outputColumnThresholds": [
        {
          "outputColumnName": string,
          "minimumIdentityCount": number
        }
      ]
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [],
    "allowedColumnComparisonColumns": []
  },
  "differentialPrivacy": {
    "columns": [
      {
        "name": "userIdentifier"
      }
    ]
  }
}

Führen Sie dazu einen der folgenden Schritte aus:

Sie können auch jedes der folgenden Steuerelemente konfigurieren:

Die Konfiguration von minimalen Aggregationsschwellenwerten zusammen mit Vergleichskontrollen ist die empfohlene Konfiguration. Ein Schwellenwert allein sorgt immer noch dafür, dass Spalten mit niedriger Kardinalität oder quasi identifizierenden Spalten vergleichbar sind, was die Ergebnisse auf ungewollte Weise einschränken kann.

Es lohnt sich, Vergleichskontrollen zu konfigurieren, wenn Ihre Tabelle Spalten mit niedriger Kardinalität oder quasi identifizierende Spalten enthält — wie beispielsweise eine Postleitzahl oder eine Altersgruppe — oder wenn dem Abfragerunner nicht vollständig vertraut wird. Ein funktionierendes Beispiel, das zeigt, wie beide Steuerelemente zusammen konfiguriert sind, finden Sie unter. Beispiel für eine benutzerdefinierte Analyseregel mit minimalen Aggregationsschwellenwerten und Vergleichskontrollen

Beispiel für eine benutzerdefinierte Analyseregel mit Analysevorlagen

Das folgende Beispiel zeigt, wie zwei Unternehmen bei der AWS Clean Rooms Verwendung der benutzerdefinierten Analyseregel zusammenarbeiten können.

Unternehmen A verfügt über Kunden- und Vertriebsdaten. Unternehmen A ist daran interessiert, die Umsatzsteigerung einer Werbekampagne auf der Website von Unternehmen B zu verstehen. Unternehmen B verfügt über Zuschauerdaten und Segmentattribute, die für Unternehmen nützlich sind (z. B. das Gerät, mit dem das Unternehmen die Werbung angesehen hat).

Unternehmen A hat eine spezielle Inkrementalitätsabfrage, die es im Rahmen der Zusammenarbeit ausführen möchte.

Um eine Kollaboration zu erstellen und gemeinsam eine benutzerdefinierte Analyse durchzuführen, gehen die Unternehmen wie folgt vor:

Beispiel für eine benutzerdefinierte Analyseregel mit minimalen Aggregationsschwellenwerten

Das folgende Beispiel zeigt, wie zwei Unternehmen zusammenarbeiten können, um die benutzerdefinierte Analyseregel mit minimalen Aggregationsschwellenwerten zu AWS Clean Rooms verwenden, anstatt einzelne Analysevorlagen zu überprüfen.

Unternehmen A ist ein Herausgeber mit einer impressions Tabelleuser_id, diecampaign_id, und enthält. event_date Unternehmen B ist ein Werbetreibender, der die Reichweite seiner Kampagne messen möchte — die Anzahl der einzelnen Nutzer, die eine bestimmte Kampagne gesehen haben. Unternehmen A möchte sicherstellen, dass aus keinem Abfrageergebnis Einzelpersonen oder kleine Gruppen hervorgehen. Daher verwendet es Mindestwerte für die Aggregation, anstatt einzelne Analysevorlagen zu überprüfen.

Um eine Zusammenarbeit zu erstellen und eine benutzerdefinierte Analyse durchzuführen, gehen die Unternehmen wie folgt vor:

Der wesentliche Unterschied zum Ansatz mit Analysevorlagen besteht darin, dass Unternehmen A eine bestimmte Anfrage nie überprüft hat. Stattdessen stützt sich Unternehmen A auf den Schwellenwert, um einzuschränken, was eine Abfrage zurückgeben kann. Weitere Informationen erhalten Sie unter Minimale Schwellenwerte für die Aggregation und Steuerelemente für den Vergleich.

Beispiel für eine benutzerdefinierte Analyseregel mit minimalen Aggregationsschwellenwerten und Vergleichskontrollen

Die empfohlene Basiskonfiguration ist die Konfiguration von minimalen Aggregationsschwellenwerten zusammen mit Vergleichskontrollen. Ein Schwellenwert allein stellt sicher, dass jede Ergebniszeile eine Mindestanzahl unterschiedlicher Datensubjekte repräsentiert, verhindert jedoch nicht, dass Vergleiche anhand von Spalten mit niedriger Kardinalität oder quasi identifizierenden Spalten durchgeführt werden. Ohne Vergleichskontrollen kann ein Abfragerunner diese Spalten immer noch filtern oder nach ihnen verknüpfen, wodurch die Ergebnisse möglicherweise auf unbeabsichtigte Weise eingeschränkt werden.

Es lohnt sich, Vergleichskontrollen zu konfigurieren, wenn Ihre Tabelle Spalten mit niedriger Kardinalität oder quasi identifizierende Spalten enthält — wie beispielsweise eine Postleitzahl oder eine Altersgruppe — oder wenn dem Abfrage-Runner nicht vollständig vertraut wird. Das Hinzufügen von Vergleichskontrollen schränkt ein, welche Spalten bei literalen Vergleichen und Vergleichen von Spalte zu Spalte vorkommen können. Dadurch wird die Lücke geschlossen, die allein ein Schwellenwert offen lässt.

Die folgende Konfiguration kombiniert beide Steuerelemente:

{
  "aggregationThresholds": [
    {
      "identityColumns": [
        "user_id"
      ],
      "minimumIdentityCount": 100,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY"
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "campaign_id"
    ],
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  },
  "allowedAnalyses": [
    "ANY_QUERY"
  ],
  "allowedAnalysisProviders": [
    "444455556666"
  ]
}

Bei dieser Konfiguration steht jede Ergebniszeile für mindestens 100 verschiedene Datensubjekte. Der Abfragerunner kann campaign_id mithilfe von Literalvergleichen filtern und user_id mithilfe von Spalte-zu-Spalten-Vergleichen verknüpfen. Da die zulässigen Vergleichslisten festgelegt sind, können alle nicht aufgelisteten Spalten — einschließlich Spalten mit niedriger Kardinalität wie Postleitzahl oder Altersgruppe — überhaupt nicht in einem Vergleich verwendet werden.

Weitere Informationen zu den einzelnen Steuerelementen finden Sie unter und. Minimale Schwellenwerte für die Aggregation Steuerelemente für den Vergleich Eine umfassendere Konfiguration, die auch unzulässige Ausgabespalten enthält, finden Sie unter. Zusammenführung

Zusammenführung

Das folgende Beispiel zeigt eine vollständige Konfiguration des benutzerdefinierten Analyseregeltyps mit unzulässigen Ausgabespalten, minimalen Aggregationsschwellenwerten und Vergleichskontrollen. Diese Konfiguration erzwingt eine Mindestaggregation von 100 verschiedenen Datensubjekten, user_id verhindert, dass sie in das Abfrageergebnis projiziert wird, und ermöglicht es dem Abfragerunner, die Schnittmenge der Kunden zu analysieren, die in der Spalte beitreten. user_id

Diese Richtlinie bietet auch zusätzliche Flexibilität, da sie eine literale Vergleichsfilterung für Spalten mit niedriger Sensitivität ermöglicht status und price den minimalen Aggregationsschwellenwert für die Spalte auf 5 überschreibt: campaign_id

{
  "disallowedOutputColumns": [
    "user_id"
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ],
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  },
  "aggregationThresholds": [
    {
      "identityColumns": [
        "user_id"
      ],
      "minimumIdentityCount": 100,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY",
      "outputColumnThresholds": [
        {
          "outputColumnName": "campaign_id",
          "minimumIdentityCount": 5
        }
      ]
    }
  ],
  "allowedAnalyses": [
    "ANY_QUERY"
  ],
  "allowedAnalysisProviders": [
    "444455556666",
    "333366669999"
  ]
}