Regra de análise personalizada em AWS Clean Rooms

Em AWS Clean Rooms, uma regra de análise personalizada é um novo tipo de regra de análise que permite que consultas personalizadas sejam executadas na tabela configurada. As consultas SQL personalizadas ainda estão restritas a ter apenas o comando SELECT, mas podem usar mais construções SQL do que consultas de agregação e lista (por exemplo, funções de janela, OUTER JOIN, CTEs ou subconsultas; consulte a Referência SQL do AWS Clean Rooms para obter uma lista completa). As consultas SQL personalizadas não precisam seguir uma estrutura de consulta, como consultas de agregação e lista.

A regra de análise personalizada é compatível com casos de uso mais avançados do que os permitidos pela regra de agregação e análise de listas, como análise de atribuição personalizada, avaliação comparativa, análise de incrementalidade e descoberta de público. Isso é um acréscimo a um superconjunto dos casos de uso suportados pela regra de agregação e análise de listas.

A regra de análise personalizada também é compatível com a privacidade diferencial. A privacidade diferencial é uma estrutura matematicamente rigorosa para proteção da privacidade de dados. Para ter mais informações, consulte AWS Clean Rooms Privacidade diferencial. Quando você cria um modelo de análise, a Privacidade AWS Clean Rooms Diferencial verifica o modelo para determinar se ele é compatível com a estrutura de consulta de uso geral da Privacidade Diferencial AWS Clean Rooms . Essa validação garante que você não crie um modelo de análise que não seja permitido com uma tabela diferencial protegida por privacidade.

Para configurar a regra de análise personalizada, os proprietários dos dados podem optar por permitir que consultas personalizadas específicas, armazenadas em modelos de análise, sejam executadas em suas tabelas configuradas. Os proprietários dos dados revisam os modelos de análise antes de adicioná-los ao controle de análise permitido na regra de análise personalizada. Os modelos de análise estão disponíveis e são visíveis somente na colaboração em que foram criados (mesmo que a tabela esteja associada a outras colaborações) e só podem ser executados pelo membro que pode consultar essa colaboração.

Como alternativa, os membros podem optar por permitir que outros membros (provedores de consultas) criem consultas sem revisão. Os membros adicionam as contas dos provedores de consulta que os provedores de consulta permitidos controlam na regra de análise personalizada. Se o provedor de consulta for o membro que pode consultar, ele poderá executar qualquer consulta diretamente na tabela configurada. Os provedores de consultas também podem criar consultas criando modelos de análise. Todas as consultas criadas pelos provedores de consultas podem ser executadas automaticamente na tabela em todas as colaborações nas quais a Conta da AWS está presente e a tabela está associada.

Os proprietários de dados só podem permitir que modelos de análise ou contas criem consultas, não ambos. Se o proprietário dos dados os deixar em branco, o membro que pode consultar não poderá executar consultas na tabela configurada.

Estrutura predefinida da regra de análise personalizada

O exemplo a seguir inclui uma estrutura predefinida que mostra como concluir uma regra de análise personalizada com a privacidade diferencial ativada. O valor de userIdentifier é a coluna que identifica exclusivamente seus usuários, como user_id. Quando você tem duas ou mais tabelas com privacidade diferencial ativada em uma colaboração, é AWS Clean Rooms necessário configurar a mesma coluna que a coluna do identificador do usuário em ambas as regras de análise para manter uma definição consistente dos usuários nas tabelas.

{
  "allowedAnalyses": ["ANY_QUERY"] | string[],
  "allowedAnalysisProviders": [],
  "differentialPrivacy": {
    "columns": [
      {
        "name": "userIdentifier"
      }
    ]
  }
}

Você também pode:

• Adicione ARNs do modelo de análise ao controle de análises permitido. Nesse caso, o controle allowedAnalysisProviders não está incluído.

  {
    allowedAnalyses: string[]
  }

• Adicione Conta da AWS IDs de membros ao allowedAnalysisProviders controle. Nesse caso, você adiciona ANY_QUERY ao controle allowedAnalyses.

  {
    allowedAnalyses: ["ANY_QUERY"],
    allowedAnalysisProviders: string[]
  }

Exemplo de regra de análise personalizada

O exemplo a seguir demonstra como duas empresas podem colaborar no AWS Clean Rooms uso da regra de análise personalizada.

A empresa A tem dados de clientes e vendas. A empresa A está interessada em entender a incrementalidade de vendas de uma campanha publicitária no site da empresa B. A empresa B tem dados de visualização e atributos de segmento que são úteis para a empresa (por exemplo, o dispositivo usado ao visualizar a publicidade).

A empresa A tem uma consulta de incrementalidade específica que deseja executar na colaboração.

Para criar uma colaboração e executar uma análise personalizada em colaboração, as empresas fazem o seguinte:

1. A empresa A cria uma colaboração e cria uma associação. A colaboração tem a Empresa B como outro membro da colaboração. A empresa A permite o registro de consultas na colaboração e permite o registro de consultas em sua conta.

2. A empresa B cria uma associação na colaboração. Ele permite o registro de consultas em sua conta.

3. A empresa A cria uma tabela configurada de CRM

4. A empresa A adiciona uma regra de análise personalizada vazia à tabela configurada de vendas.

5. A empresa A associa a tabela configurada de vendas à colaboração.

6. A empresa B cria uma tabela configurada de visualização.

7. A empresa B adiciona uma regra de análise personalizada vazia à tabela configurada de visualização.

8. A empresa B associa a tabela configurada de visualização à colaboração.

9. A empresa A visualiza a tabela de vendas e a tabela de visualizações associadas à colaboração e cria um modelo de análise, adicionando a consulta de incrementalidade e o parâmetro para o mês da campanha.

   {
       "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. A empresa A adiciona sua conta (por exemplo, 444455556666) ao controle permitido do provedor de análise na regra de análise personalizada. Eles usam o controle permitido do provedor de análise porque desejam permitir que todas as consultas criadas sejam executadas na tabela configurada de vendas.

    {
      "allowedAnalyses": [
        "ANY_QUERY"
      ],
      "allowedAnalysisProviders": [
        "444455556666"
      ]
    }

11. A empresa B vê o modelo de análise criado na colaboração e revisa seu conteúdo, incluindo a string de consulta e o parâmetro.

12. A empresa B determina que o modelo de análise atinge o caso de uso de incrementalidade e atende aos requisitos de privacidade de como sua tabela configurada de audiência pode ser consultada.

13. A empresa B adiciona o ARN do modelo de análise ao controle de análise permitido na regra de análise personalizada da tabela de visualizações. Eles usam o controle de análise permitido porque só querem permitir que a consulta de incrementalidade seja executada em sua tabela configurada de visualização.

    {
      "allowedAnalyses": [
        "arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292"
      ]
    }

14. A empresa A executa o modelo de análise e usa o valor do parâmetro 05-01-2023.

Regra de análise personalizada com privacidade diferencial

Em AWS Clean Rooms, a regra de análise personalizada oferece suporte à privacidade diferencial. A privacidade diferencial é uma estrutura matematicamente rigorosa para proteção da privacidade de dados que ajuda você a proteger seus dados contra tentativas de reidentificação.

A privacidade diferencial suporta análises agregadas, como planejamento de campanhas publicitárias, post-ad-campaign mensuração, benchmarking em um consórcio de instituições financeiras e testes A/B para pesquisas em saúde.

A estrutura e a sintaxe de consulta suportadas são definidas em Estrutura e sintaxe da consulta.

Exemplo de regra de análise personalizada com privacidade diferencial

Considere o exemplo de regra de análise personalizada apresentado na seção anterior. Esse exemplo demonstra como você pode usar a privacidade diferencial para proteger seus dados contra tentativas de reidentificação e, ao mesmo tempo, permitir que seu parceiro aprenda informações essenciais para os negócios com base nos seus dados. Suponha que a Empresa B, que tem os dados de audiência, queira proteger seus dados usando a privacidade diferencial. Para concluir a configuração de privacidade diferencial, a Empresa B conclui as seguintes etapas:

1. A empresa B ativa a privacidade diferencial ao adicionar uma regra de análise personalizada à tabela configurada de audiência. A empresa B seleciona viewershipdata.hashedemail como coluna de identificação do usuário.

2. A empresa B adiciona uma política de privacidade diferencial à colaboração para disponibilizar sua tabela de dados de audiência para consulta. A empresa B seleciona a política padrão para concluir rapidamente a configuração.

A empresa A, que deseja entender a incrementalidade de vendas de uma campanha publicitária no site da empresa B, executa o modelo de análise. Como a consulta é compatível com a estrutura de consulta de uso geral da privacidade diferencial do AWS Clean Rooms , a consulta é executada com êxito.

Estrutura e sintaxe da consulta

As consultas que contêm pelo menos uma tabela com a privacidade diferencial ativada devem seguir a sintaxe a seguir.

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])

nota

Para a estrutura e a sintaxe de consulta de privacidade diferencial, lembre-se de que:

• Subconsultas não são compatíveis.

• Expressões de tabela comuns (CTEs) deverão emitir a coluna de identificador do usuário se uma tabela ou CTE envolver dados protegidos por privacidade diferencial. Filtros, agrupamentos e agregações devem ser feitos no nível do usuário.

• Final_select permite as funções agregadas COUNT DISTINCT, COUNT, SUM, AVG e STDDEV.

Consulte mais detalhes sobre quais palavras-chave de SQL são compatíveis com a privacidade diferencial em Capacidades SQL da AWS Clean Rooms Privacidade Diferencial.