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 des seuils d'agrégation minimaux et des 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 seule SELECT commande, mais 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 ; consultez la référence AWS Clean Rooms SQL pour une liste complète). Les requêtes SQL personnalisées n'ont pas besoin de 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 listes, tels que l'analyse d'attribution personnalisée, l'analyse comparative, l'analyse incrémentielle et la découverte d'audience. Cela s'ajoute à un surensemble de cas d'utilisation pris en charge par la règle 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 de plus amples informations, veuillez consulter 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 qui n'est pas autorisé avec une table protégée par une 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 des 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 sont créés (même si le tableau est associé à 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 les 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 qui peut effectuer une requête, 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 à être exécutées sur la table dans toutes les collaborations dans lesquelles le Compte AWS est présent et le tableau est associé.

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 des seuils d'agrégation minimaux et des contrôles de comparaison
Assembler le tout

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. N'incluez que 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 dans le cadre d'une collaboration, vous devez AWS Clean Rooms 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 des ARN de modèles 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 membres au allowedAnalysisProviders contrôle. Dans ce cas, vous ANY_QUERY complétez le allowedAnalyses contrôle.
```
{
  allowedAnalyses: ["ANY_QUERY"],
  allowedAnalysisProviders: string[]
}
```

Vous pouvez également configurer l'une des commandes suivantes :

Les colonnes que vous n'autorisez pas à projeter dans le résultat de la requête. Pour de plus amples informations, veuillez consulter Colonnes de sortie interdites.
```
{
  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 les colonnes de sortie individuelles 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 quelles colonnes peuvent être comparées à une valeur littérale et lesquelles peuvent être comparées à une autre colonne. Pour de plus amples informations, veuillez consulter Contrôles de comparaison.
```
{
  comparisonControls: {
    allowedLiteralComparisonColumns: string[],
    allowedColumnComparisonColumns: string[]
  }
}
```
Configuration de confidentialité différentielle qui protège la table en identifiant la colonne de l'identifiant utilisateur. Pour plus d'informations, consultez la section Confidentialité AWS Clean Rooms différentielle.
```
{
  differentialPrivacy: {
    columns: [
      {
        name: string
      }
    ]
  }
}
```

La configuration recommandée est de configurer des seuils d'agrégation minimaux ainsi que des contrôles de comparaison. Un seuil à lui seul permet toujours de comparer les colonnes à faible cardinalité ou à quasi-identification, ce qui peut restreindre 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-identifiantes, telles que le code postal ou la tranche d'âge, ou lorsque l'exécuteur de requêtes n'est pas totalement fiable. Pour un exemple concret illustrant les deux commandes configurées ensemble, consultezExemple de règle d'analyse personnalisée avec des seuils d'agrégation minimaux et des 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 en AWS Clean Rooms utilisant 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 qui sont utiles à l'entreprise (par exemple, l'appareil qu'elle a utilisé pour visionner la publicité).

L'entreprise A souhaite exécuter une requête incrémentielle 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 société B est un autre membre de la collaboration. L'entreprise A active l'enregistrement des requêtes dans la collaboration et active l'enregistrement des requêtes dans son compte.
L'entreprise B crée une adhésion à la collaboration. Il permet l'enregistrement des requêtes dans son compte.
L'entreprise A crée une table configurée pour le CRM
L'entreprise A ajoute une règle d'analyse personnalisée vide au tableau configuré des ventes.
La société A associe la table configurée des ventes à la collaboration.
L'entreprise B crée une table configurée en termes d'audience.
L'entreprise B ajoute une règle d'analyse personnalisée vide à la table configurée en termes d'audience.
L'entreprise B associe un tableau configuré d'audience à 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 incrémentielle 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 examine son 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 d'incrémentalité et répond à ses exigences de confidentialité relatives à la manière dont sa table configurée en termes d'audience peut être interrogée.
L'entreprise 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 incrémentielle sur leur table configurée en termes d'audience.
```
{
  "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 revoir 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 de sa 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 peut 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 exécuter une analyse personnalisée, les entreprises procèdent comme suit :

L'entreprise A crée une collaboration avec l'entreprise B en tant qu'autre membre et en tant que membre pouvant poser des questions. L'entreprise A permet l'enregistrement des requêtes dans la collaboration et dans son compte.
L'entreprise B devient membre de la collaboration et active l'enregistrement des requêtes sur son compte.
L'entreprise 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 plus faible sensibilité. 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 autorisée. Enfin, la société A ajoute le compte de la société 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 exécute une requête de portée groupée event_date et filtrée par campagne :


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. L'entreprise B connaît donc la portée quotidienne de la campagne de promotion des fêtes sans en savoir plus sur un individu ou un petit groupe.

`event_date`	`reach`
01/01/2026	142
02/01/2026	118
04/01/2026	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 AWS Clean Rooms a donc été supprimée.

La principale différence par rapport à l'approche des modèles d'analyse est que la société A n'a jamais examiné une requête spécifique. L'entreprise A s'appuie plutôt 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 des seuils d'agrégation minimaux et des contrôles de comparaison

La configuration de référence recommandée est la configuration de seuils d'agrégation minimaux ainsi que des contrôles de comparaison. Un seuil à lui seul garantit 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-identifiantes. 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-identifiantes, telles que le code postal ou la tranche d'âge, ou lorsque l'exécuteur 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 colonne à colonne, 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 poursuivre user_id en utilisant des comparaisons colonne par 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 qui inclut également des colonnes de sortie interdites, consultez. Assembler le tout

Assembler le tout

L'exemple suivant montre une configuration complète du type de règle d'analyse personnalisée, à l'aide de colonnes de sortie interdites, de seuils d'agrégation minimaux et de contrôles de comparaison. Cette configuration impose l'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 rejoignant la user_id colonne.

Cette politique offre également une flexibilité supplémentaire en permettant un filtrage de comparaison littéral sur les colonnes à faible sensibilité status et price remplace 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