Structure de règles d'analyse personnalisée Exemple de règle d'analyse personnalisée avec modèles d'analyse Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux et contrôles de comparaison Assembler le tout

Règle d'analyse personnalisée dans AWS Clean Rooms

Dans AWS Clean Rooms, une règle d'analyse personnalisée est un nouveau type de règle d'analyse qui permet d'exécuter des requêtes personnalisées sur la table configurée. Les requêtes SQL personnalisées sont toujours limitées à la SELECT commande, mais elles peuvent utiliser davantage de constructions SQL que les requêtes d'agrégation et de liste (par exemple, les fonctions de fenêtre, OUTER JOIN, les CTE ou les sous-requêtes ; voir la référence AWS Clean Rooms SQL pour une liste complète). Les requêtes SQL personnalisées ne doivent pas nécessairement suivre une structure de requête telle que les requêtes d'agrégation et de liste.

La règle d'analyse personnalisée prend en charge des cas d'utilisation plus avancés que ceux qui peuvent être pris en charge par la règle d'agrégation et d'analyse de liste, tels que l'analyse d'attribution personnalisée, le benchmarking, l'analyse d'incrémentalité et la découverte d'audience. Cela s'ajoute à un surensemble des cas d'utilisation pris en charge par les règles d'agrégation et d'analyse de listes.

La règle d'analyse personnalisée prend également en charge la confidentialité différentielle. La confidentialité différentielle est un cadre mathématiquement rigoureux pour la protection de la confidentialité des données. Pour plus d’informations, consultez AWS Clean Rooms Confidentialité différentielle. Lorsque vous créez un modèle d'analyse, AWS Clean Rooms Differential Privacy vérifie le modèle pour déterminer s'il est compatible avec la structure de requête à usage général pour AWS Clean Rooms Differential Privacy. Cette validation garantit que vous ne créez pas de modèle d'analyse non autorisé avec une table protégée par la confidentialité différentielle.

Pour configurer la règle d'analyse personnalisée, les propriétaires de données peuvent choisir d'autoriser l'exécution de requêtes personnalisées spécifiques, stockées dans des modèles d'analyse, sur leurs tables configurées. Les propriétaires de données examinent les modèles d'analyse avant de les ajouter au contrôle d'analyse autorisé dans la règle d'analyse personnalisée. Les modèles d'analyse sont disponibles et visibles uniquement dans la collaboration dans laquelle ils ont été créés (même si la table est associée à d'autres collaborations) et ne peuvent être exécutés que par le membre qui peut effectuer des requêtes dans cette collaboration.

Les membres peuvent également choisir d'autoriser d'autres membres (fournisseurs de requêtes) à créer des requêtes sans révision. Les membres ajoutent les comptes des fournisseurs de requêtes que les fournisseurs de requêtes autorisés contrôlent dans la règle d'analyse personnalisée. Si le fournisseur de requêtes est le membre habilité à effectuer des requêtes, il peut exécuter n'importe quelle requête directement sur la table configurée. Les fournisseurs de requêtes peuvent également créer des requêtes en créant des modèles d'analyse. Toutes les requêtes créées par les fournisseurs de requêtes sont automatiquement autorisées à s'exécuter sur la table dans toutes les collaborations dans lesquelles elles sont présentes et où la table est associée. Compte AWS

Cette page contient les sections suivantes :

Structure de règles d'analyse personnalisée
Exemple de règle d'analyse personnalisée avec modèles d'analyse
Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux
Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux et contrôles de comparaison
Tout mettre en place

La règle d'analyse personnalisée prend en charge les contrôles de confidentialité suivants :

Structure de règles d'analyse personnalisée

La structure prédéfinie suivante montre les contrôles disponibles dans une règle d'analyse personnalisée. Incluez uniquement les commandes dont vous avez besoin pour votre cas d'utilisation. La userIdentifier valeur du differentialPrivacy contrôle est la colonne qui identifie de manière unique vos utilisateurs, telle que user_id. Lorsque la confidentialité différentielle est activée sur deux tables ou plus dans le cadre d'une collaboration, AWS Clean Rooms vous devez configurer la même colonne que la colonne d'identifiant utilisateur dans les deux règles d'analyse. Cela permet de conserver une définition cohérente des utilisateurs dans toutes les tables.


{
  "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"
      }
    ]
  }
}

Vous avez le choix entre les options suivantes :

Ajoutez les ARN du modèle d'analyse au contrôle des analyses autorisées. Dans ce cas, le allowedAnalysisProviders contrôle n'est pas inclus.
```
{
  allowedAnalyses: string[]
}
```
Ajoutez Compte AWS des identifiants de membre au allowedAnalysisProviders contrôle. Dans ce cas, vous ajoutez ANY_QUERY au allowedAnalyses contrôle.
```
{
  allowedAnalyses: ["ANY_QUERY"],
  allowedAnalysisProviders: string[]
}
```

Vous pouvez également configurer l'un des contrôles suivants :

Les colonnes que vous n'autorisez pas à projeter dans le résultat de la requête. Pour plus d’informations, consultez Colonnes de sortie non autorisées.
```
{
  disallowedOutputColumns: string[]
}
```
Seuil d'agrégation minimal qui exige que chaque ligne de résultats représente au moins un nombre minimum de sujets de données distincts. Vous pouvez modifier le seuil pour chaque colonne de sortie et allowedAggregateExpressionType contrôler si outputColumnThresholds les expressions sont autorisées dans les fonctions d'agrégation. Pour plus d’informations, consultez Seuils d'agrégation minimaux, Remplacer le seuil d'agrégation minimum pour des colonnes de sortie spécifiques et Autoriser les expressions imbriquées dans les fonctions d'agrégation.
```
{
  aggregationThresholds: [
    {
      identityColumns: string[],
      minimumIdentityCount: number,
      type: "COUNT_DISTINCT",
      allowedAggregateExpressionType: "COLUMNS_ONLY" | "ANY_EXPRESSION",
      outputColumnThresholds: [
        {
          outputColumnName: string,
          minimumIdentityCount: number
        }
      ]
    }
  ]
}
```
Contrôles de comparaison qui définissent les colonnes qui peuvent être comparées à une valeur littérale et celles qui peuvent être comparées à une autre colonne. Pour plus d’informations, consultez Contrôles de comparaison.
```
{
  comparisonControls: {
    allowedLiteralComparisonColumns: string[],
    allowedColumnComparisonColumns: string[]
  }
}
```
Configuration de confidentialité différentielle qui protège la table en identifiant la colonne d'identifiant utilisateur. Pour plus d'informations, consultez la section ConfidentialitéAWS Clean Rooms différentielle.
```
{
  differentialPrivacy: {
    columns: [
      {
        name: string
      }
    ]
  }
}
```

Il est recommandé de configurer des seuils d'agrégation minimaux ainsi que des contrôles de comparaison. Un seuil à lui seul permet de comparer les colonnes à faible cardinalité ou quasi-identifiables, ce qui peut réduire les résultats de manière involontaire.

Les contrôles de comparaison méritent d'être configurés lorsque votre table contient des colonnes à faible cardinalité ou quasi-identifiables, telles que le code postal ou la tranche d'âge, ou lorsque le lanceur de requêtes n'est pas totalement fiable. Pour un exemple concret illustrant les deux commandes configurées ensemble, voirExemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux et contrôles de comparaison.

Exemple de règle d'analyse personnalisée avec modèles d'analyse

L'exemple suivant montre comment deux entreprises peuvent collaborer à AWS Clean Rooms l'aide de la règle d'analyse personnalisée.

L'entreprise A possède des données sur les clients et les ventes. L'entreprise A souhaite comprendre l'augmentation des ventes d'une campagne publicitaire sur le site de l'entreprise B. L'entreprise B possède des données d'audience et des attributs de segment utiles à l'entreprise (par exemple, l'appareil utilisé pour visionner la publicité).

L'entreprise A souhaite exécuter une requête d'incrémentalité spécifique dans le cadre de la collaboration.

Pour créer une collaboration et exécuter une analyse personnalisée en collaboration, les entreprises procèdent comme suit :

L'entreprise A crée une collaboration et crée une adhésion. La collaboration a la société B comme autre membre de la collaboration. L'entreprise A active la journalisation des requêtes dans la collaboration, et elle active la journalisation des requêtes dans son compte.
L'entreprise B crée une adhésion à la collaboration. Il permet la journalisation des requêtes dans son compte.
L'entreprise A crée une table configurée pour le CRM
La société A ajoute une règle d'analyse personnalisée vide à la table configurée des ventes.
L'entreprise A associe la table configurée des ventes à la collaboration.
La société B crée une table configurée pour le nombre de vues.
La société B ajoute une règle d'analyse personnalisée vide à la table configurée par le nombre de vues.
La société B associe la table configurée en termes de nombre de vues à la collaboration.

L'entreprise A consulte le tableau des ventes et le tableau d'audience associés à la collaboration et crée un modèle d'analyse, en ajoutant la requête d'incrémentalité et le paramètre pour le mois de la campagne.


{
    "analysisParameters": [
    {
        "defaultValue": ""
        "type": "DATE"
        "name": "campaign_month"
    }
    ],
    "description": "Monthly incrementality query using sales and viewership data"
    "format": "SQL"
    "name": "Incrementality analysis"
    "source": 
        "WITH labeleddata AS
        (
        SELECT hashedemail, deviceid, purchases, unitprice, purchasedate,
        CASE
            WHEN testvalue IN ('value1', 'value2', 'value3') THEN 0
            ELSE 1
        END AS testgroup
        FROM viewershipdata
        )
        SELECT labeleddata.purchases, provider.impressions
        FROM labeleddata 
        INNER JOIN salesdata
          ON labeleddata.hashedemail = provider.hashedemail
        WHERE MONTH(labeleddata.purchasedate) > :campaignmonth
        AND testgroup = :group
       "
}

L'entreprise A ajoute son compte (par exemple, 444455556666) au contrôle du fournisseur d'analyse autorisé dans la règle d'analyse personnalisée. Ils utilisent le contrôle du fournisseur d'analyse autorisé car ils souhaitent autoriser l'exécution de toutes les requêtes qu'ils créent sur leur table configurée pour les ventes.
```
{
  "allowedAnalyses": [
    "ANY_QUERY"
  ],
  "allowedAnalysisProviders": [
    "444455556666"
  ]
}
```
L'entreprise B voit le modèle d'analyse créé dans la collaboration et en examine le contenu, y compris la chaîne de requête et le paramètre.
L'entreprise B détermine que le modèle d'analyse répond au cas d'utilisation de l'incrémentalité et répond à ses exigences de confidentialité quant à la manière dont sa table configurée d'audience peut être interrogée.
La société B ajoute l'ARN du modèle d'analyse au contrôle d'analyse autorisé dans la règle d'analyse personnalisée de la table d'audience. Ils utilisent le contrôle d'analyse autorisé car ils souhaitent uniquement autoriser l'exécution de la requête d'incrémentalité sur leur table configurée par affichage.
```
{
  "allowedAnalyses": [
    "arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292"
  ]
}
```
L'entreprise A exécute le modèle d'analyse et utilise la valeur du paramètre05-01-2023.

Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux

L'exemple suivant montre comment deux entreprises peuvent collaborer en AWS Clean Rooms utilisant la règle d'analyse personnalisée avec des seuils d'agrégation minimaux au lieu de passer en revue des modèles d'analyse individuels.

La société A est un éditeur dont le impressions tableau contient user_idcampaign_id, etevent_date. L'entreprise B est un annonceur qui souhaite mesurer la portée d'une campagne, c'est-à-dire le nombre d'utilisateurs distincts qui ont vu une campagne donnée. L'entreprise A souhaite s'assurer qu'aucun résultat de requête ne puisse révéler des individus ou de petits groupes. Elle utilise donc des seuils d'agrégation minimaux plutôt que de passer en revue des modèles d'analyse individuels.

Pour créer une collaboration et effectuer une analyse personnalisée, les entreprises procèdent comme suit :

L'entreprise A crée une collaboration avec la société B en tant qu'autre membre et en tant que membre habilité à effectuer des requêtes. L'entreprise A permet la journalisation des requêtes dans la collaboration et dans son compte.
L'entreprise B crée une adhésion à la collaboration et active la journalisation des requêtes dans son compte.
La société A crée une table impressions configurée.
L'entreprise A ajoute une règle d'analyse personnalisée à la table impressions configurée avec un seuil d'agrégation minimum afin que chaque ligne renvoyée représente au moins 100 utilisateurs distincts. L'entreprise A définit user_id comme colonne d'identité et remplace le seuil à 5 pour la colonne de campaign_id sortie la moins sensible. L'entreprise A permet également une comparaison littérale event_date afin que l'entreprise B puisse étendre une requête à une campagne et à une plage de dates. campaign_id Chaque colonne qui apparaît dans une comparaison littérale doit figurer dans la liste d'autorisation, à l'exception des comparaisons avec des valeurs toujours autorisées. Pour plus d’informations, consultez Valeurs littérales toujours autorisées. Enfin, l'entreprise A ajoute le compte de l'entreprise B au contrôle des fournisseurs d'analyse autorisés afin que l'entreprise B puisse exécuter des requêtes sans révision par modèle.
```
{
  "aggregationThresholds": [
    {
      "identityColumns": [
        "user_id"
      ],
      "minimumIdentityCount": 100,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY",
      "outputColumnThresholds": [
        {
          "outputColumnName": "campaign_id",
          "minimumIdentityCount": 5
        }
      ]
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "campaign_id",
      "event_date"
    ]
  },
  "allowedAnalyses": [
    "ANY_QUERY"
  ],
  "allowedAnalysisProviders": [
    "444455556666"
  ]
}
```
L'entreprise A associe la table impressions configurée à la collaboration.

L'entreprise B lance une requête de portée groupée par campagne event_date et filtrée en fonction de celle-ci :


SELECT event_date, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE event_date >= '2026-01-01' AND campaign_id = 'Holiday Promotion'
GROUP BY event_date;

AWS Clean Rooms renvoie uniquement les lignes soutenues par au moins 100 utilisateurs distincts et supprime le reste, de sorte que l'entreprise B prend connaissance de la portée quotidienne de la campagne de promotion des fêtes sans avoir à connaître un individu ou un petit groupe.

`event_date`	`reach`
01/01/2021	142
02/01/2026/	118
04/01/2021	103

La date 2026-01-03 n'apparaît pas dans les résultats car moins de 100 utilisateurs distincts ont vu la campagne ce jour-là. Cette ligne a donc AWS Clean Rooms été supprimée.

La principale différence par rapport à l'approche des modèles d'analyse est que l'entreprise A n'a jamais examiné une requête spécifique. Au lieu de cela, l'entreprise A s'appuie sur le seuil pour limiter ce que toute requête peut renvoyer. Pour plus d’informations, consultez Seuils d'agrégation minimaux et Contrôles de comparaison.

Exemple de règle d'analyse personnalisée avec seuils d'agrégation minimaux et contrôles de comparaison

La configuration de référence recommandée consiste à configurer des seuils d'agrégation minimaux ainsi que des contrôles de comparaison. Un seuil garantit à lui seul que chaque ligne de résultats représente un nombre minimum de sujets de données distincts, mais il n'empêche pas les comparaisons sur des colonnes à faible cardinalité ou quasi-identifiables. Sans contrôles de comparaison, un lanceur de requêtes peut toujours filtrer ou joindre ces colonnes, ce qui peut réduire les résultats de manière involontaire.

Les contrôles de comparaison méritent d'être configurés lorsque votre table contient des colonnes à faible cardinalité ou quasi-identifiables, telles que le code postal ou la tranche d'âge, ou lorsque le lanceur de requêtes n'est pas totalement fiable. L'ajout de contrôles de comparaison limite les colonnes qui peuvent apparaître dans les comparaisons littérales et les comparaisons entre colonnes, comblant ainsi l'écart qu'un seuil à lui seul laisse ouvert.

La configuration suivante combine les deux commandes :


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

Avec cette configuration, chaque ligne de résultats représente au moins 100 sujets de données distincts. Le lanceur de requêtes peut filtrer en campaign_id utilisant des comparaisons littérales et se joindre à d'autres user_id en utilisant des comparaisons colonne à colonne. Les listes d'autorisation de comparaison étant définies, aucune colonne non répertoriée, y compris les colonnes à faible cardinalité telles que le code postal ou la tranche d'âge, ne peut pas du tout être utilisée dans une comparaison.

Pour plus d'informations sur chaque contrôle, reportez-vous aux sections Seuils d'agrégation minimaux etContrôles de comparaison. Pour une configuration plus complète incluant également les colonnes de sortie interdites, voir. Assembler le tout

Assembler le tout

L'exemple suivant montre une configuration complète du type de règle d'analyse personnalisée, utilisant des colonnes de sortie interdites, des seuils d'agrégation minimaux et des contrôles de comparaison. Cette configuration impose une agrégation minimale de 100 sujets de données distincts, user_id empêche toute projection dans le résultat de la requête et permet au lanceur de requêtes d'analyser l'intersection des clients se joignant à la user_id colonne.

Cette politique apporte également une flexibilité supplémentaire en autorisant le filtrage de comparaison littéral sur les colonnes à faible sensibilité status et price en remplaçant le seuil d'agrégation minimum à 5 pour la colonne : 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"
  ]
}

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Règle d'analyse des listes

Analyses autorisées