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

Les propriétaires de données peuvent uniquement autoriser les modèles d'analyse ou les comptes à créer des requêtes, et non les deux. Si le propriétaire des données le laisse vide, le membre autorisé à effectuer des requêtes ne peut pas exécuter de requêtes sur la table configurée.

Structure prédéfinie des règles d'analyse personnalisées

L'exemple suivant inclut une structure prédéfinie qui vous montre comment exécuter une règle d'analyse personnalisée avec la confidentialité différentielle activée. La userIdentifier valeur 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 afin de maintenir une définition cohérente des utilisateurs entre les tables.

{
  "allowedAnalyses": ["ANY_QUERY"] | string[],
  "allowedAnalysisProviders": [],
  "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[]
  }

Exemple de règle d'analyse personnalisée

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 :

1. 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.

2. L'entreprise B crée une adhésion à la collaboration. Il permet la journalisation des requêtes dans son compte.

3. L'entreprise A crée une table configurée pour le CRM

4. La société A ajoute une règle d'analyse personnalisée vide à la table configurée des ventes.

5. L'entreprise A associe la table configurée des ventes à la collaboration.

6. La société B crée une table configurée pour le nombre de vues.

7. La société B ajoute une règle d'analyse personnalisée vide à la table configurée par le nombre de vues.

8. La société B associe la table configurée en termes de nombre de vues à la collaboration.

9. 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
          "
   }

10. 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"
      ]
    }

11. 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.

12. 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.

13. 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"
      ]
    }

14. L'entreprise A exécute le modèle d'analyse et utilise la valeur du paramètre05-01-2023.

Règle d'analyse personnalisée avec confidentialité différentielle

Dans AWS Clean Rooms, la règle d'analyse personnalisée prend 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 qui vous aide à protéger vos données contre les tentatives de réidentification.

La confidentialité différentielle prend en charge les analyses agrégées telles que la planification de campagnes publicitaires, les post-ad-campaign mesures, l'analyse comparative au sein d'un consortium d'institutions financières et les tests A/B pour la recherche dans le domaine de la santé.

La structure et la syntaxe de requête prises en charge sont définies dansStructure et syntaxe des requêtes.

Exemple de règle d'analyse personnalisée avec confidentialité différentielle

Examinez l'exemple de règle d'analyse personnalisée présenté dans la section précédente. Cet exemple montre comment vous pouvez utiliser la confidentialité différentielle pour protéger vos données contre les tentatives de réidentification tout en permettant à votre partenaire de tirer des informations critiques de vos données. Supposons que l'entreprise B, qui possède les données d'audience, souhaite protéger ses données en utilisant une confidentialité différentielle. Pour terminer la configuration de la confidentialité différentielle, l'entreprise B effectue les étapes suivantes :

1. L'entreprise B active la confidentialité différentielle tout en ajoutant une règle d'analyse personnalisée au tableau configuré par le nombre de vues. L'entreprise B sélectionne viewershipdata.hashedemail comme colonne d'identifiant utilisateur.

2. L'entreprise B ajoute une politique de confidentialité différentielle à la collaboration afin de rendre sa table de données d'audience disponible pour les requêtes. L'entreprise B sélectionne la politique par défaut pour terminer rapidement la configuration.

L'entreprise A, qui souhaite comprendre l'augmentation des ventes d'une campagne publicitaire sur le site de l'entreprise B, exécute le modèle d'analyse. La requête étant compatible avec la structure de requête à usage général de AWS Clean Rooms Differential Privacy, elle s'exécute correctement.

Structure et syntaxe des requêtes

Les requêtes contenant au moins une table dont la confidentialité différentielle est activée doivent respecter la syntaxe suivante.

query_statement:
    [cte, ...] final_select

 cte:
    WITH sub_query AS (
       inner_select
       [ UNION | INTERSECT | UNION_ALL | EXCEPT/MINUS ]
       [ inner_select ]
    )
   
 inner_select:
     SELECT [user_id_column, ] expression [, ...] 
     FROM table_reference [, ...] 
     [ WHERE condition ]
     [ GROUP BY user_id_column[, expression] [, ...] ] 
     [ HAVING condition ] 

 final_select:
     SELECT [expression, ...] | COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV
     FROM table_reference [, ...]
     [ WHERE condition ]
     [ GROUP BY expression [, ...] ] 
     [ HAVING COUNT | COUNT_DISTINCT | SUM | AVG | STDDEV | condition ]
     [ ORDER BY column_list ASC | DESC ] 
     [ OFFSET literal ]
     [ LIMIT literal ]

 expression:
    column_name [, ...] | expression AS alias | aggregation_functions | window_functions_on_user_id | scalar_function | CASE | column_name math_expression [, expression]  
    
 window_functions_on_user_id:
    function () OVER (PARTITION BY user_id_column, [column_name] [ORDER BY column_list ASC|DESC])

Note

En ce qui concerne la structure et la syntaxe différentielles des requêtes de confidentialité, tenez compte des points suivants :

• Les sous-requêtes ne sont pas prises en charge.

• Les expressions de table communes (CTE) doivent émettre la colonne d'identifiant utilisateur si une table ou un CTE implique des données protégées par une confidentialité différentielle. Les filtres, les regroupements et les agrégations doivent être effectués au niveau de l'utilisateur.

• Final_select autorise les fonctions d'agrégation COUNT DISTINCT, COUNT, SUM, AVG et STDDEV.

Pour plus de détails sur les mots clés SQL pris en charge pour une confidentialité différentielle, consultezSQLcapacités de AWS Clean Rooms Confidentialité différentielle.