Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Regole di analisi in AWS Clean Rooms
Per abilitare una tabella da utilizzare AWS Clean Rooms per l'analisi collaborativa, il membro della collaborazione deve configurare una *regola di analisi*.
Una regola di analisi è un controllo che migliora la privacy che ogni proprietario dei dati imposta su una tabella configurata. Una regola di analisi determina in che modo la tabella configurata può essere analizzata.
La regola di analisi è un controllo a livello di account sulla tabella configurata (una risorsa a livello di account) e viene applicata in qualsiasi collaborazione in cui è associata la tabella configurata. Se non è configurata alcuna regola di analisi, la tabella configurata può essere associata alle collaborazioni ma non può essere interrogata. Le query possono fare riferimento solo a tabelle configurate con lo stesso tipo di regola di analisi.
Per configurare una regola di analisi, è necessario innanzitutto selezionare un tipo di analisi e quindi specificare la regola di analisi. Per entrambi i passaggi, è necessario considerare il caso d'uso che si desidera abilitare e il modo in cui si desidera proteggere i dati sottostanti.
AWS Clean Rooms applica i controlli più restrittivi su tutte le tabelle configurate a cui fa riferimento una query.
Gli esempi seguenti illustrano i controlli restrittivi.
**Example Controllo restrittivo: vincolo di output**
+ Il collaboratore A ha un vincolo di output sulla colonna identifier di 100.
+ Il collaboratore B ha un vincolo di output sulla colonna identifier pari a 150.
Una query di aggregazione che fa riferimento a entrambe le tabelle configurate richiede almeno 150 valori distinti di identifier all'interno di una riga di output per essere visualizzata nell'output della query. L'output della query non indica che i risultati siano stati rimossi a causa del vincolo di output.
**Example Controllo restrittivo: modello di analisi non approvato**
+ Collaborator A ha consentito un modello di analisi con una query che fa riferimento alle tabelle configurate di Collaborator A e Collaborator B nelle relative regole di analisi personalizzate.
+ Il collaboratore B non ha consentito il modello di analisi.
Poiché il Collaboratore B non ha consentito il modello di analisi, il membro che può eseguire la query non può eseguire quel modello di analisi.
## Tipi di regole di analisi
Esistono tre tipi di regole di analisi: [aggregazione](analysis-rules-aggregation.md), [elenco](analysis-rules-list.md) e [personalizzata](analysis-rules-custom.md). Le tabelle seguenti confrontano i tipi di regole di analisi. Ogni tipo ha una sezione separata che descrive la specificazione della regola di analisi.
**Nota**
Esiste un tipo di regola di analisi chiamato regola di analisi della tabella di mappatura degli ID. Tuttavia, questa regola di analisi è gestita da AWS Clean Rooms e non può essere modificata. Per ulteriori informazioni, consulta [Regola di analisi della tabella di mappatura degli ID](analysis-rules-id-mapping-table.md).
Le sezioni seguenti descrivono i casi d'uso e i controlli supportati per ogni tipo di regola di analisi.
### Casi di utilizzo supportati
Le tabelle seguenti mostrano un riepilogo di confronto dei casi d'uso supportati per ogni tipo di regola di analisi.
| Caso d'uso | [Aggregazione](analysis-rules-aggregation.md) | [Elenco](analysis-rules-list.md) | [Personalizza](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Analisi supportate | Query che aggregano le statistiche utilizzando le funzioni COUNT, SUM e AVG in dimensioni opzionali | Query che generano elenchi a livello di riga delle sovrapposizioni tra più tabelle | Qualsiasi analisi personalizzata purché il modello di analisi o il creatore dell'analisi siano stati esaminati e consentiti |
| Casi d'uso comuni | Analisi, misurazione, attribuzione dei segmenti | Arricchimento, costruzione di segmenti | Attribuzione immediata, analisi incrementali, scoperta del pubblico |
| Costrutti SQL | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules.html) | La maggior parte delle funzioni SQL e dei costrutti SQL sono disponibili con il comando SELECT |
| Sottoquery ed espressioni di tabella comuni () CTEs | No | No | Sì |
| Modelli di analisi | No | No | Sì |
### Controlli supportati
Le tabelle seguenti mostrano un riepilogo di confronto del modo in cui ogni tipo di regola di analisi protegge i dati sottostanti.
| Controllo | [Aggregazione](analysis-rules-aggregation.md) | [Elenco](analysis-rules-list.md) | [Personalizza](analysis-rules-custom.md) |
| --- | --- | --- | --- |
| Meccanismo di controllo | Controlla come i dati della tabella possono essere utilizzati in una query*(Ad esempio, consenti COUNT e SUM della colonna hashed\$1email.)* | Controlla come i dati della tabella possono essere utilizzati in una query*(Ad esempio, consenti l'uso della colonna hashed\$1email solo per l'unione.)* | Controlla quali interrogazioni possono essere eseguite sulla tabella*(Ad esempio, consenti solo le interrogazioni definite nei modelli di analisi «Query personalizzata 1".)* |
| Tecniche integrate per il miglioramento della privacy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules.html) |
| Esaminate la query prima che possa essere eseguita | No | No | Sì, utilizzando modelli di analisi |
Per ulteriori informazioni sulle regole di analisi disponibili in AWS Clean Rooms, consultate i seguenti argomenti.
+ [Regola di analisi di aggregazione](analysis-rules-aggregation.md)
+ [Regola di analisi delle liste](analysis-rules-list.md)
+ [Regola di analisi personalizzata in AWS Clean Rooms](analysis-rules-custom.md)
# Regola di analisi di aggregazione
Nel AWS Clean Rooms, una *regola di analisi di aggregazione* genera statistiche aggregate utilizzando le funzioni COUNT, SUM, and/or AVG insieme a dimensioni opzionali. Quando la regola di analisi di aggregazione viene aggiunta a una tabella configurata, consente al membro che può eseguire query sulla tabella configurata.
La regola di analisi di aggregazione supporta casi d'uso come la pianificazione delle campagne, la copertura dei media, la misurazione della frequenza e l'attribuzione.
La struttura e la sintassi delle query supportate sono definite in. [Struttura e sintassi delle interrogazioni di aggregazione](#agg-query-structure-syntax)
I parametri della regola di analisi, definita in[Regola di analisi dell'aggregazione: controlli di interrogazione](#agg-query-controls), includono i controlli di interrogazione e i controlli dei risultati delle query. I suoi controlli di interrogazione includono la possibilità di richiedere che una tabella configurata sia aggiunta ad almeno una tabella configurata di proprietà del membro che può eseguire query, direttamente o in modo transitivo. Questo requisito ti consente di garantire che la query venga eseguita sull'intersezione (INNERJOIN) della tua tabella e della loro.
## Struttura e sintassi delle interrogazioni di aggregazione
Le query su tabelle che dispongono di una regola di analisi di aggregazione devono rispettare la sintassi seguente.
```
--select_aggregate_function_expression
SELECT
aggregation_function(column_name) [[AS] column_alias ] [, ...]
--select_grouping_column_expression
[, {column_name|scalar_function(arguments)} [[AS] column_alias ]][, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--group_by_expression
[GROUP BY {column_name|scalar_function(arguments)}, ...]]
--having_expression
[HAVING having_condition]
--order_by_expression
[ORDER BY {column_name|scalar_function(arguments)} [{ASC|DESC}]] [,...]]
```
Nella tabella seguente vengono illustrate tutte le espressioni elencate nella sintassi precedente.
| Expression | Definizione | Esempi |
| --- | --- | --- |
| select\$1aggregate\$1function\$1expression | Un elenco separato da virgole contenente le seguenti espressioni: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Deve essercene almeno una `select_aggregation_function_expression` in. `select_aggregate_expression` | `SELECT SUM(PRICE), user_segment` |
| select\$1aggregation\$1function\$1expression | Una o più funzioni di aggregazione supportate applicate a una o più colonne. Sono consentite solo le colonne come argomenti delle funzioni di aggregazione. Deve essercene almeno uno `select_aggregation_function_expression` in. `select_aggregate_expression` | `AVG(PRICE)` `COUNT(DISTINCT user_id)` |
| select\$1grouping\$1column\$1expression | Un'espressione che può contenere qualsiasi espressione utilizzando quanto segue: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-aggregation.html) `select_aggregate_expression`può assegnare un alias alle colonne con o senza il parametro. `AS` Per ulteriori informazioni, vedere [AWS Clean Rooms SQL Reference.](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) | `TRUNC(timestampColumn)` `UPPER(campaignName)` |
| table\$1expression | Una tabella, o unione di tabelle, che collega espressioni condizionali di join con`join_condition`. `join_condition`restituisce un valore booleano. I `table_expression` supporti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-aggregation.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Un'espressione condizionale che restituisce un valore booleano. Può essere composta dai seguenti elementi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-aggregation.html) Le condizioni di confronto supportate sono ()`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`. Gli operatori logici supportati sono (`AND, OR`). Il `where_expression` è facoltativo. | `WHERE where_condition` `WHERE price > 100` `WHERE TRUNC(timestampColumn) = '1/1/2022'` `WHERE timestampColumn = timestampColumn2 - 14` |
| group\$1by\$1expression | Un elenco di espressioni separate da virgole che soddisfano i requisiti per. `select_grouping_column_expression` | `GROUP BY TRUNC(timestampColumn), UPPER(campaignName), segment` |
| having\$1expression | Un'espressione condizionale che restituisce un valore booleano. Hanno una funzione di aggregazione supportata applicata a una singola colonna (ad esempio`SUM(price)`) e vengono confrontati con un valore letterale numerico. Le condizioni supportate sono (). `=, >, <, <=, >=, <>, !=` Gli operatori logici supportati sono (`AND, OR`). Il `having_expression` è facoltativo. | `HAVING SUM(SALES) > 500` |
| order\$1by\$1expression | Un elenco di espressioni separate da virgole compatibile con gli stessi requisiti definiti in `select_aggregate_expression` precedenza. Il `order_by_expression` è facoltativo. `order_by_expression`permessi e parametri`ASC`. `DESC` [Per ulteriori informazioni, vedere i parametri ASC DESC nel AWS Clean Rooms riferimento SQL.](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) | `ORDER BY SUM(SALES), UPPER(campaignName)` |
Per quanto riguarda la struttura e la sintassi delle query di aggregazione, tieni presente quanto segue:
+ I comandi SQL diversi da quelli non SELECT sono supportati.
+ Le sottoquery e le espressioni di tabella comuni (ad esempioWITH) non sono supportate.
+ Gli operatori che combinano più interrogazioni (ad esempioUNION) non sono supportati.
+ TOPLIMIT, e OFFSET i parametri non sono supportati.
## Regola di analisi dell'aggregazione: controlli di interrogazione
Con i controlli di interrogazione di aggregazione, puoi controllare come le colonne della tabella vengono utilizzate per interrogare la tabella. Ad esempio, è possibile controllare quale colonna viene utilizzata per l'unione, quale colonna può essere contata o quale colonna può essere utilizzata nelle WHERE istruzioni.
Nelle sezioni seguenti viene illustrato ogni controllo.
**Topics**
+ [Controlli di aggregazione](#agg-functions)
+ [Unisci i controlli](#join-controls)
+ [Controlli dimensionali](#dimension-controls)
+ [Funzioni scalari](#scalar-functions)
### Controlli di aggregazione
Utilizzando *i controlli di aggregazione*, è possibile definire quali funzioni di aggregazione consentire e a quali colonne devono essere applicate. Le funzioni di aggregazione possono essere utilizzate nelle espressioni SELECTHAVING, e. ORDER BY
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| aggregateColumns | Colonne di colonne di tabella configurate che è possibile utilizzare all'interno delle funzioni di aggregazione. | `aggregateColumns`può essere utilizzato all'interno di una funzione di aggregazione nelle SELECT espressioniHAVING, e ORDERBY. Alcuni `aggregateColumns` possono anche essere classificati come `joinColumn` (definiti in seguito). `aggregateColumn`Given non può anche essere classificato come `dimensionColumn` (definito in seguito). |
| function | Le funzioni COUNT, SUM e AVG consentite possono essere utilizzate in aggiunta a. aggregateColumns | `function`può essere applicato a qualsiasi `aggregateColumns` oggetto ad esso associato. |
### Unisci i controlli
Una `JOIN` clausola viene utilizzata per combinare righe di due o più tabelle, in base a una colonna correlata tra di esse.
È possibile utilizzare *i controlli Join* per controllare il modo in cui la tabella può essere unita ad altre tabelle in. `table_expression` AWS Clean Rooms supporta solo INNERJOIN. INNERJOINle istruzioni possono utilizzare solo colonne che sono state classificate in modo esplicito come una delle regole di analisi, `joinColumn` in base ai controlli definiti dall'utente.
INNERJOINDevono operare su una `joinColumn` tabella configurata e su un'altra tabella configurata nella collaborazione. `joinColumn` Sei tu a decidere quali colonne della tabella possono essere utilizzate come`joinColumn`.
Ogni condizione di corrispondenza all'interno della ON clausola è richiesta per utilizzare la condizione di confronto di uguaglianza (`=`) tra due colonne.
Le condizioni di corrispondenza multiple all'interno di una ON clausola possono essere:
+ Combinato utilizzando l'operatore logico `AND`
+ Separato utilizzando l'operatore `OR` logico
**Nota**
Tutte le JOIN condizioni di partita devono corrispondere a una riga su ciascun lato delJOIN. Anche tutti i condizionali collegati da un operatore logico `OR` o da un operatore `AND` logico devono rispettare questo requisito.
Di seguito è riportato un esempio di interrogazione con un operatore logico`AND`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
Di seguito è riportato un esempio di interrogazione con un operatore `OR` logico.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| joinColumns | Le colonne (se presenti) che si desidera consentire al membro che può eseguire la query di utilizzare nell'INNERJOINistruzione. | Uno specifico `joinColumn` può anche essere classificato come `aggregateColumn` (vedi[Controlli di aggregazione](#agg-functions)). La stessa colonna non può essere utilizzata sia come che come `joinColumn` `dimensionColumns` (vedi più avanti). A meno che non sia stata anche classificata come una`aggregateColumn`, a non `joinColumn` può essere utilizzata in altre parti della query diverse da. INNER JOIN |
| joinRequired | Controlla se hai bisogno di un messaggio INNER JOIN con una tabella configurata dal membro che può eseguire la query. | Se si abilita questo parametro, INNER JOIN è necessario un. Se non abiliti questo parametro, an INNER JOIN è facoltativo. Supponendo che questo parametro sia abilitato, il membro che può eseguire la query deve includere una tabella di sua proprietà in. INNER JOIN Devono unire JOIN la propria tabella alla propria, direttamente o transitivamente (ossia, unire la propria tabella a un'altra tabella, che a sua volta è unita al tavolo dell'utente). |
Di seguito è riportato un esempio di transitività.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
**Nota**
Il membro che può eseguire la query può anche utilizzare il `joinRequired` parametro. In tal caso, la query deve unire la propria tabella ad almeno un'altra tabella.
### Controlli dimensionali
*I controlli delle dimensioni* controllano la colonna lungo la quale le colonne di aggregazione possono essere filtrate, raggruppate o aggregate.
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| dimensionColumns | Le colonne (se presenti) che consenti al membro che può eseguire la query di utilizzare inSELECT,, WHERE e. GROUP BY ORDER BY | A `dimensionColumn` può essere usato in SELECT (`select_grouping_column_expression`)WHERE, GROUPBY, e ORDERBY. La stessa colonna non può essere sia a `dimensionColumn``joinColumn`, a che and/or an`aggregateColumn`. |
### Funzioni scalari
*Le funzioni scalari* controllano quali funzioni scalari possono essere utilizzate nelle colonne dimensionali.
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| scalarFunctions | Le funzioni scalari che possono essere utilizzate `dimensionColumns` nella query. | Speciifica le funzioni scalari (se presenti) su cui è possibile applicare (ad esempioCAST). `dimensionColumns` Le funzioni scalari non possono essere utilizzate sopra altre funzioni o all'interno di altre funzioni. Gli argomenti delle funzioni scalari possono essere colonne, stringhe letterali o letterali numerici. |
Sono supportate le seguenti funzioni scalari:
+ Funzioni matematiche: ABS, CEILING, FLOOR, LOG, LN, ROUND, SQRT
+ Funzioni di formattazione dei tipi di dati — CAST, CONVERT, TO\$1CHAR, TO\$1DATE, TO\$1NUMBER, TO\$1TIMESTAMP
+ Funzioni di stringa: LOWER, UPPER, TRIM, RTRIM, SUBSTRING
+ Per RTRIM, i set di caratteri personalizzati da tagliare non sono consentiti.
+ Espressioni condizionali — COALESCE
+ Funzioni di data: EXTRACT, GETDATE, CURRENT\$1DATE, DATEADD
+ Altre funzioni: TRUNC
Per maggiori dettagli, consulta [AWS Clean Rooms SQL](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) Reference.
## Regola di analisi di aggregazione: controlli dei risultati delle query
Con i controlli dei risultati delle query di aggregazione, è possibile controllare quali risultati vengono restituiti specificando una o più condizioni che ogni riga di output deve soddisfare per poter essere restituita. AWS Clean Rooms supporta vincoli di aggregazione sotto forma di. `COUNT (DISTINCT column) >= X` Questo modulo richiede che ogni riga aggreghi almeno X valori distinti di una scelta dalla tabella configurata (ad esempio, un numero minimo di valori distinti). `user_id` Questa soglia minima viene applicata automaticamente, anche se la query inviata stessa non utilizza la colonna specificata. Vengono applicate collettivamente a ogni tabella configurata nell'interrogazione effettuata dalle tabelle configurate di ciascun membro della collaborazione.
Ogni tabella configurata deve avere almeno un vincolo di aggregazione nella regola di analisi. I proprietari delle tabelle configurate possono aggiungerne di più `columnName` e associarle `minimum` e vengono applicate collettivamente.
### Vincoli di aggregazione
I *vincoli di aggregazione* controllano quali righe dei risultati della query vengono restituite. Per essere restituita, una riga deve soddisfare il numero minimo specificato di valori distinti in ogni colonna specificata nel vincolo di aggregazione. Questo requisito si applica anche se la colonna non è menzionata esplicitamente nella query o in altre parti della regola di analisi.
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| columnName | Il `aggregateColumn` that viene utilizzato nella condizione che ogni riga di output deve soddisfare. | Può essere qualsiasi colonna nella tabella configurata. |
| minimum | Il numero minimo di valori distinti associati `aggregateColumn` che deve avere la riga di output (ad esempio, COUNT DISTINCT) per poter essere restituita nei risultati della query. | `minimum`Deve essere almeno il valore 2. |
## Struttura delle regole di analisi dell'aggregazione
L'esempio seguente mostra una struttura predefinita per una regola di analisi di aggregazione.
Nell'esempio seguente, *`MyTable`* fa riferimento alla tabella di dati. È possibile sostituire ciascuno di essi *user input placeholder* con le proprie informazioni.
```
{
"aggregateColumns": [
{
"columnNames": [MyTable column names], "function": [Allowed Agg Functions]
},
],
"joinRequired": ["QUERY_RUNNER"],
"joinColumns": [MyTable column names],
"dimensionColumns": [MyTable column names],
"scalarFunctions": [Allowed Scalar functions],
"outputConstraints": [
{
"columnName": [MyTable column names], "minimum": [Numeric value]
},
]
}
```
## Regola di analisi dell'aggregazione: esempio
L'esempio seguente dimostra come due aziende possono collaborare AWS Clean Rooms utilizzando l'analisi di aggregazione.
L'azienda A dispone di dati sui clienti e sulle vendite. L'azienda A è interessata a comprendere l'attività di restituzione dei prodotti. La società B è uno dei rivenditori della società A e dispone di dati sui resi. La società B dispone inoltre di attributi di segmento relativi ai clienti utili all'azienda A (ad esempio, ha acquistato prodotti correlati, utilizza il servizio clienti del rivenditore). L'azienda B non desidera fornire dati sui resi dei clienti a livello di riga e informazioni sugli attributi. La società B desidera solo abilitare una serie di query per l'azienda A per ottenere statistiche aggregate sui clienti che si sovrappongono a una soglia minima di aggregazione.
La società A e la società B decidono di collaborare in modo che l'azienda A possa comprendere l'attività di restituzione dei prodotti e fornire prodotti migliori presso l'azienda B e altri canali.
Per creare la collaborazione ed eseguire un'analisi di aggregazione, le aziende eseguono le seguenti operazioni:
1. L'azienda A crea una collaborazione e crea un'iscrizione. La collaborazione ha l'azienda B come altro membro della collaborazione. La società A consente la registrazione delle interrogazioni nell'ambito della collaborazione e la registrazione delle interrogazioni nel proprio account.
1. L'azienda B crea un'appartenenza alla collaborazione. Consente la registrazione delle query nel proprio account.
1. La società A crea una tabella configurata per le vendite.
1. La società A aggiunge la seguente regola di analisi di aggregazione alla tabella configurata per le vendite.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"purchases"
],
"function": "AVG"
},
{
"columnNames": [
"purchases"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"dimensionColumns": [
"demoseg",
"purchasedate",
"productline"
],
"scalarFunctions": [
"CAST",
"COALESCE",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 2,
"type": "COUNT_DISTINCT"
},
]
}
```
`aggregateColumns`— La società A desidera contare il numero di clienti unici nella sovrapposizione tra i dati di vendita e i dati sui resi. L'azienda A desidera inoltre sommare il numero di `purchases` prodotti da confrontare con il numero di`returns`.
`joinColumns`— La società A intende utilizzare questa tecnica `identifier` per abbinare i clienti provenienti dai dati di vendita ai clienti provenienti dai dati sui resi. Ciò aiuterà l'Azienda A ad abbinare i resi agli acquisti giusti. Inoltre, aiuta l'azienda A a segmentare i clienti che si sovrappongono.
`dimensionColumns`— La società A filtra in base `dimensionColumns` al prodotto specifico, confronta gli acquisti e i resi in un determinato periodo di tempo, assicura che la data di restituzione sia successiva a quella del prodotto e aiuta a segmentare i clienti che si sovrappongono.
`scalarFunctions`— La società A seleziona la funzione `CAST` scalare per aiutare ad aggiornare i formati dei tipi di dati, se necessario, in base alla tabella configurata che la società A associa alla collaborazione. Aggiunge inoltre funzioni scalari per facilitare la formattazione delle colonne, se necessario.
`outputConstraints`— La società A stabilisce vincoli minimi di output. Non è necessario limitare i risultati perché all'analista è consentito visualizzare i dati a livello di riga dalla tabella delle vendite
**Nota**
La società A non include `joinRequired` nella regola di analisi. Offre all'analista la flessibilità necessaria per interrogare solo la tabella delle vendite.
1. La società B crea una tabella configurata per i resi.
1. La società B aggiunge la seguente regola di analisi di aggregazione alla tabella configurata per i resi.
```
{
"aggregateColumns": [
{
"columnNames": [
"identifier"
],
"function": "COUNT_DISTINCT"
},
{
"columnNames": [
"returns"
],
"function": "AVG"
},
{
"columnNames": [
"returns"
],
"function": "SUM"
}
],
"joinColumns": [
"hashedemail"
],
"joinRequired": [
"QUERY_RUNNER"
],
"dimensionColumns": [
"state",
"popularpurchases",
"customerserviceuser",
"productline",
"returndate"
],
"scalarFunctions": [
"CAST",
"LOWER",
"UPPER",
"TRUNC"
],
"outputConstraints": [
{
"columnName": "hashedemail",
"minimum": 100,
"type": "COUNT_DISTINCT"
},
{
"columnName": "producttype",
"minimum": 2,
"type": "COUNT_DISTINCT"
}
]
}
```
`aggregateColumns`— La società B consente alla società A di effettuare una somma `returns` da confrontare con il numero di acquisti. Hanno almeno una colonna aggregata perché abilitano una query aggregata.
`joinColumns`— La società B consente alla società A di aderire per `identifier` abbinare i clienti provenienti dai dati di restituzione ai clienti dai dati di vendita. `identifier`i dati sono particolarmente sensibili e la loro presenza `joinColumn` garantisce che non vengano mai inseriti in una query.
`joinRequired`— L'azienda B richiede che le domande sui dati di restituzione vengano sovrapposte ai dati di vendita. Non vogliono consentire all'azienda A di interrogare tutte le persone nel loro set di dati. Hanno anche concordato tale restrizione nel loro accordo di collaborazione.
`dimensionColumns`— La società B consente alla società A di filtrare e raggruppare per `state``popularpurchases`, e `customerserviceuser` si tratta di attributi unici che potrebbero aiutare a effettuare l'analisi per la società A. La società B consente all'azienda A di utilizzare per filtrare l'output in base `returndate` a `returndate` ciò che si verifica successivamente`purchasedate`. Con questo filtraggio, l'output è più accurato per valutare l'impatto della modifica del prodotto.
`scalarFunctions`— L'azienda B consente quanto segue:
+ TRUNC per le date
+ LOWER e UPPER nel caso in `producttype` cui i dati siano immessi in un formato diverso
+ CASTse la società A deve convertire i tipi di dati delle vendite in modo che corrispondano ai tipi di dati dei resi
La società A non abilita altre funzioni scalari perché non ritiene che siano necessarie per le query.
`outputConstraints`— L'azienda B stabilisce vincoli minimi di output `hashedemail` per contribuire a ridurre la capacità di reidentificare i clienti. Aggiunge inoltre un vincolo minimo di output `producttype` per ridurre la capacità di identificare nuovamente i prodotti specifici che sono stati restituiti. Alcuni tipi di prodotto potrebbero essere più dominanti in base alle dimensioni della produzione (ad esempio,). `state` I loro vincoli di output verranno sempre applicati indipendentemente dai vincoli di output aggiunti dalla società A ai propri dati.
1. La società A crea una tabella di vendita associata alla collaborazione.
1. La società B crea un'associazione tra tabelle di restituzione e collaborazione.
1. La società A esegue interrogazioni, come nell'esempio seguente, per comprendere meglio la quantità di resi nell'azienda B rispetto al totale degli acquisti per località nel 2022.
```
SELECT
companyB.state,
SUM(companyB.returns),
COUNT(DISTINCT companyA.hashedemail)
FROM
sales companyA
INNER JOIN returns companyB ON companyA.identifier = companyB.identifier
WHERE
companyA.purchasedate BETWEEN '2022-01-01' AND '2022-12-31' AND
TRUNC(companyB.returndate) > companyA.purchasedate
GROUP BY
companyB.state;
```
1. La Società A e la Società B esaminano i registri delle interrogazioni. La società B verifica che la richiesta sia in linea con quanto concordato nell'accordo di collaborazione.
## Risoluzione dei problemi relativi alle regole di analisi di aggregazione
Utilizza queste informazioni per aiutarti a diagnosticare e risolvere i problemi più comuni quando lavori con le regole di analisi di aggregazione.
**Topics**
+ [La mia query non ha prodotto alcun risultato](#query-no-results)
### La mia query non ha prodotto alcun risultato
Questo può accadere quando non ci sono risultati corrispondenti o quando i risultati corrispondenti non soddisfano una o più soglie minime di aggregazione.
Per ulteriori informazioni sulle soglie minime di aggregazione, consulta. [Regola di analisi dell'aggregazione: esempio](#agg-analysis-rule-example)
# Regola di analisi delle liste
In AWS Clean Rooms, una *regola di analisi degli elenchi* genera elenchi a livello di riga della sovrapposizione tra la tabella configurata a cui viene aggiunta e le tabelle configurate del membro che può eseguire la query. Il membro che può eseguire query esegue query che includono una regola di analisi dell'elenco.
Il tipo di regola di analisi degli elenchi supporta casi d'uso come l'arricchimento e la creazione di audience.
Per ulteriori informazioni sulla struttura e sulla sintassi delle query predefinite per questa regola di analisi, vedere. [Struttura predefinita della regola di analisi delle liste](#intersection-list-params-template)
I parametri della regola di analisi dell'elenco, definita in[Regola di analisi delle liste: controlli di interrogazione](#parameters-list-query-controls), dispongono di controlli di interrogazione. I suoi controlli di interrogazione includono la possibilità di selezionare le colonne che possono essere elencate nell'output. La query deve avere almeno un join con una tabella configurata dal membro che può eseguire la query, direttamente o in modo transitivo.
Non esistono controlli sui risultati delle query come quelli per la regola di [analisi di aggregazione](analysis-rules-aggregation.md).
Le query di elenco possono utilizzare solo operatori matematici. Non possono utilizzare altre funzioni (come l'aggregazione o lo scalare).
**Topics**
+ [Elenca la struttura e la sintassi delle interrogazioni](#list-query-controls)
+ [Regola di analisi delle liste: controlli di interrogazione](#parameters-list-query-controls)
+ [Struttura predefinita della regola di analisi delle liste](#intersection-list-params-template)
+ [Regola di analisi delle liste: esempio](#list-example)
## Elenca la struttura e la sintassi delle interrogazioni
Le interrogazioni su tabelle che dispongono di una regola di analisi degli elenchi devono rispettare la sintassi seguente.
```
--select_list_expression
SELECT DISTINCT column_name [[AS] column_alias ] [, ...]
--table_expression
FROM table_name [[AS] table_alias ]
[[INNER] JOIN table_name [[AS] table_alias] ON join_condition] [...]
--where_expression
[WHERE where_condition]
--limit_expression
[LIMIT number]
```
Nella tabella seguente vengono illustrate tutte le espressioni elencate nella sintassi precedente.
| Expression | Definizione | Esempi |
| --- | --- | --- |
| select\$1list\$1expression | Un elenco separato da virgole contenente almeno il nome di una colonna della tabella. È richiesto un `DISTINCT` parametro. Le colonne `select_list_expression` possono essere utilizzate come alias con o senza il `AS` parametro. Per ulteriori informazioni, vedere [AWS Clean Rooms SQL Reference.](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) | `SELECT DISTINCT segment` |
| table\$1expression | Una tabella, o unione di tabelle, `join_condition` a cui connetterla`join_condition`. `join_condition`restituisce un valore booleano. I `table_expression` supporti: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-list.html) | FROM consumer_table
INNER JOIN provider_table
ON
consumer_table.identifier1 = provider_table.identifier1
AND
consumer_table.identifier2 = provider_table.identifier2
|
| where\$1expression | Un'espressione condizionale che restituisce un valore booleano. Può essere composta dai seguenti elementi:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/clean-rooms/latest/userguide/analysis-rules-list.html)Le condizioni di confronto supportate sono ()`=, >, <, <=, >=, <>, !=, NOT, IN, NOT IN, LIKE, IS NULL, IS NOT NULL`. Gli operatori logici supportati sono (`AND, OR`).Il `where_expression` è facoltativo. | `WHERE state + '_' + city = 'NY_NYC'` `WHERE timestampColumn = timestampColumn2 - 14` |
| limit\$1expression | Questa espressione deve assumere un numero intero positivo. Il `limit_expression` è facoltativo. | `LIMIT 100` |
Per quanto riguarda la struttura e la sintassi delle query di elenco, tenete presente quanto segue:
+ I comandi SQL diversi da SELECT non sono supportati.
+ Le sottoquery e le espressioni di tabella comuni (ad esempio,WITH) non sono supportate
+ Le BY clausole GROUP BY HAVING e ORDER non sono supportate
+ Il parametro OFFSET non è supportato
## Regola di analisi delle liste: controlli di interrogazione
Con i controlli di interrogazione degli elenchi, puoi controllare come le colonne della tabella vengono utilizzate per interrogare la tabella. Ad esempio, è possibile controllare quale colonna viene utilizzata per l'unione o quale colonna può essere utilizzata nell'istruzione e nella WHERE clausola SELECT.
Le seguenti sezioni spiegano ogni controllo.
**Topics**
+ [Unisci i controlli](#list-controls-join-controls)
+ [Elenca i controlli](#list-controls)
### Unisci i controlli
Con *i controlli Join*, puoi controllare come la tua tabella può essere unita ad altre tabelle in **table\$1expression**. AWS Clean Rooms supporta solo JOIN. INNER Nella regola di analisi dell'elenco, è richiesto almeno un INNER JOIN e il membro che può eseguire la query deve includere una tabella di sua proprietà nel INNER JOIN. Ciò significa che devono unire il tuo tavolo al loro, direttamente o transitivamente.
Di seguito è riportato un esempio di transitività.
```
ON
my_table.identifer = third_party_table.identifier
....
ON
third_party_table.identifier = member_who_can_query_table.id
```
INNERLe istruzioni JOIN possono utilizzare solo colonne che sono state esplicitamente classificate come una delle regole di `joinColumn` analisi.
Il INNER JOIN deve funzionare su una `joinColumn` tabella configurata e su un'altra tabella configurata nella collaborazione. `joinColumn` Sei tu a decidere quali colonne della tua tabella possono essere utilizzate come`joinColumn`.
Ogni condizione di corrispondenza all'interno della ON clausola è richiesta per utilizzare la condizione di confronto di uguaglianza (`=`) tra due colonne.
Le condizioni di corrispondenza multiple all'interno di una ON clausola possono essere:
+ Combinato utilizzando l'operatore `AND` logico
+ Separato utilizzando l'operatore `OR` logico
**Nota**
Tutte le JOIN condizioni di partita devono corrispondere a una riga su ciascun lato delJOIN. Anche tutti i condizionali collegati da un operatore logico `OR` o da un operatore `AND` logico devono rispettare questo requisito.
Di seguito è riportato un esempio di interrogazione con un operatore logico`AND`.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id AND table1.name = table2.name
```
Di seguito è riportato un esempio di interrogazione con un operatore `OR` logico.
```
SELECT some_col, other_col
FROM table1
JOIN table2
ON table1.id = table2.id OR table1.name = table2.name
```
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| joinColumns | Le colonne che si desidera consentire al membro che può eseguire la query di utilizzare nell'istruzione INNER JOIN. | La stessa colonna non può essere classificata sia come a `joinColumn` che come `listColumn` (vedi[Elenca i controlli](#list-controls)). `joinColumn`non può essere utilizzato in altre parti della query diverse da INNER JOIN. |
### Elenca i controlli
*I controlli elenco* controllano le colonne che possono essere elencate nell'output della query (ovvero utilizzate nell'istruzione SELECT) o utilizzate per filtrare i risultati (ovvero utilizzate nell'WHEREistruzione).
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| listColumns | Le colonne che consentite al membro che può eseguire la query di utilizzare nell'istruzione SELECT e WHERE | A listColumn può essere utilizzato in SELECT eWHERE.La stessa colonna non può essere utilizzata sia come che come `listColumn``joinColumn`. |
## Struttura predefinita della regola di analisi delle liste
L'esempio seguente include una struttura predefinita che mostra come completare una regola di analisi degli elenchi.
Nell'esempio seguente, *`MyTable`* fa riferimento alla tabella di dati. È possibile sostituire ciascuno di essi *user input placeholder* con le proprie informazioni.
```
{
"joinColumns": [MyTable column name(s)],
"listColumns": [MyTable column name(s)],
}
```
## Regola di analisi delle liste: esempio
L'esempio seguente dimostra come due aziende possono collaborare AWS Clean Rooms utilizzando l'analisi delle liste.
L'azienda A dispone di dati sulla gestione delle relazioni con i clienti (CRM). L'azienda A desidera ottenere dati di segmento aggiuntivi sui propri clienti per saperne di più sui propri clienti e potenzialmente utilizzare gli attributi come input per altre analisi. L'azienda B dispone di dati sui segmenti composti da attributi di segmento unici creati sulla base dei dati di prima parte. La società B desidera fornire gli attributi univoci del segmento alla società A solo ai clienti che si sovrappongono tra i loro dati e i dati dell'azienda A.
Le aziende decidono di collaborare in modo che l'azienda A possa arricchire i dati sovrapposti. La società A è il socio che può effettuare le domande e la società B è il collaboratore.
Per creare una collaborazione ed eseguire l'analisi degli elenchi in collaborazione, le aziende eseguono le seguenti operazioni:
1. L'azienda A crea una collaborazione e crea un'iscrizione. La collaborazione ha l'azienda B come altro membro della collaborazione. La società A consente la registrazione delle interrogazioni nella collaborazione e la registrazione delle interrogazioni nel proprio account.
1. L'azienda B crea un'appartenenza alla collaborazione. Consente la registrazione delle interrogazioni nel proprio account.
1. L'azienda A crea una tabella configurata con CRM
1. La società A aggiunge la regola di analisi alla tabella configurata dal cliente, come mostrato nell'esempio seguente.
```
{
"joinColumns": [
"identifier1",
"identifier2"
],
"listColumns": [
"internalid",
"segment1",
"segment2",
"customercategory"
]
}
```
`joinColumns`— La società A desidera utilizzare `hashedemail` and/or `thirdpartyid` (ottenuto da un fornitore di identità) per abbinare i clienti dei dati CRM ai clienti dei dati del segmento. Ciò contribuirà a garantire che l'azienda A abbini dati arricchiti per i clienti giusti. Dispongono di due JoinColumns per migliorare potenzialmente il tasso di corrispondenza dell'analisi.
`listColumns`— La società A le utilizza `listColumns` accanto per ottenere colonne arricchite e `internalid` le utilizza all'interno dei propri sistemi. `segment1`Aggiungono `segment2` e `customercategory` potenzialmente limitano l'arricchimento a segmenti specifici utilizzandoli nei filtri.
1. La società B crea una tabella configurata per segmenti.
1. La società B aggiunge la regola di analisi alla tabella configurata del segmento.
```
{
"joinColumns": [
"identifier2"
],
"listColumns": [
"segment3",
"segment4"
]
}
```
`joinColumns`— La società B consente all'azienda A di partecipare `identifier2` per abbinare i clienti dai dati del segmento ai dati CRM. La società A e la società B hanno collaborato con il fornitore di identità per ottenere `identifier2` una soluzione adatta a questa collaborazione. Non ne hanno aggiunti altri `joinColumns` perché ritenevano che `identifier2` fornisse il tasso di corrispondenza più elevato e preciso e non fossero necessari altri identificatori per le query.
`listColumns`— L'azienda B consente all'azienda A di arricchire i propri dati con `segment3` `segment4` attributi unici che ha creato, raccolto e utilizzato (con il cliente A) per contribuire all'arricchimento dei dati. Vogliono che l'azienda A ottenga questi segmenti per la sovrapposizione a livello di riga perché si tratta di una collaborazione per l'arricchimento dei dati.
1. L'azienda A crea un'associazione di tabelle CRM alla collaborazione.
1. La società B crea un'associazione di tabelle di segmenti alla collaborazione.
1. L'azienda A esegue interrogazioni, come la seguente, per arricchire i dati sovrapposti dei clienti.
```
SELECT companyA.internalid, companyB.segment3, companyB.segment4
INNER JOIN returns companyB
ON companyA.identifier2 = companyB.identifier2
WHERE companyA.customercategory > 'xxx'
```
1. L'azienda A e la società B esaminano i registri delle interrogazioni. La società B verifica che la richiesta sia in linea con quanto concordato nell'accordo di collaborazione.
# Regola di analisi personalizzata in AWS Clean Rooms
In AWS Clean Rooms, una *regola di analisi personalizzata* è un nuovo tipo di regola di analisi che consente di eseguire query personalizzate sulla tabella configurata. Le query SQL personalizzate sono ancora limitate al solo SELECT comando, ma possono utilizzare più costrutti SQL rispetto alle query di [aggregazione](analysis-rules-aggregation.md#agg-query-controls) ed [elenco](analysis-rules-list.md#list-query-controls) (ad esempio, funzioni di finestra, OUTER JOIN o sottoquery; per un elenco completo CTEs, vedere [AWS Clean Rooms SQL](https://docs.aws.amazon.com/clean-rooms/latest/sql-reference/sql-reference.html) Reference). [[Le query SQL personalizzate non devono seguire una struttura di query come le query di aggregazione e le query a elenco.](analysis-rules-list.md#list-query-controls)](analysis-rules-aggregation.md#agg-query-structure-syntax)
La regola di analisi personalizzata supporta casi d'uso più avanzati rispetto a quelli che possono essere supportati dalla regola di aggregazione e analisi degli elenchi, come l'analisi di attribuzione personalizzata, il benchmarking, l'analisi di incrementalità e l'individuazione dell'audience. Si aggiunge a un superset dei casi d'uso supportati dalle regole di aggregazione e analisi degli elenchi.
La regola di analisi personalizzata supporta anche la privacy differenziale. La privacy differenziale è un quadro matematicamente rigoroso per la protezione della privacy dei dati. Per ulteriori informazioni, consulta [AWS Clean Rooms Privacy differenziale](differential-privacy.md). Quando si crea un modello di analisi, AWS Clean Rooms Differential Privacy controlla il modello per determinare se è compatibile con la struttura di interrogazione generica per Differential Privacy. AWS Clean Rooms Questa convalida garantisce che non si crei un modello di analisi non consentito con una tabella differenziale protetta dalla privacy.
Per configurare la regola di analisi personalizzata, i proprietari dei dati possono scegliere di consentire l'esecuzione di query personalizzate specifiche, archiviate in [modelli di analisi](create-analysis-template.md), sulle tabelle configurate. I proprietari dei dati esaminano i modelli di analisi prima di aggiungerli al controllo di analisi consentito nella regola di analisi personalizzata. I modelli di analisi sono disponibili e visibili solo nella collaborazione in cui vengono creati (anche se la tabella è associata ad altre collaborazioni) e possono essere eseguiti solo dal membro che può eseguire query nell'ambito di tale collaborazione.
In alternativa, i membri possono scegliere di consentire ad altri membri (fornitori di query) di creare query senza revisione. I membri aggiungono gli account dei provider di query controllati dai provider di query consentiti nella regola di analisi personalizzata. Se il provider di query è il membro che può eseguire le query, possono eseguire qualsiasi query direttamente sulla tabella configurata. I provider di query possono anche creare interrogazioni [creando modelli di analisi](create-analysis-template.md). Tutte le query create dai provider di query possono essere eseguite automaticamente sulla tabella in tutte le collaborazioni in cui Account AWS è presente e la tabella è associata.
I proprietari dei dati possono consentire solo ai modelli di analisi o agli account di creare query, non entrambi. Se il proprietario dei dati lo lascia vuoto, il membro che può eseguire le query non può eseguire query sulla tabella configurata.
**Topics**
+ [Struttura predefinita della regola di analisi personalizzata](#custom-predefined-structure)
+ [Esempio di regola di analisi personalizzata](#custom-example)
+ [Regola di analisi personalizzata con privacy differenziale](#custom-diff-privacy)
## Struttura predefinita della regola di analisi personalizzata
L'esempio seguente include una struttura predefinita che mostra come completare una regola di analisi personalizzata con la privacy differenziale attivata. *Il `userIdentifier` valore è la colonna che identifica in modo univoco gli utenti, ad esempio user\$1id.* Quando in una collaborazione sono attivate due o più tabelle con privacy differenziale, è AWS Clean Rooms necessario configurare la stessa colonna come colonna dell'identificatore utente in entrambe le regole di analisi per mantenere una definizione coerente degli utenti tra le tabelle.
```
{
"allowedAnalyses": ["ANY_QUERY"] | string[],
"allowedAnalysisProviders": [],
"differentialPrivacy": {
"columns": [
{
"name": "userIdentifier"
}
]
}
}
```
Puoi eseguire una delle seguenti operazioni:
+ Aggiungi un modello di analisi ARNs al controllo delle analisi consentito. In questo caso, il `allowedAnalysisProviders` controllo non è incluso.
```
{
allowedAnalyses: string[]
}
```
+ Aggiungi membro Account AWS IDs al `allowedAnalysisProviders` controllo. In questo caso, si aggiunge `ANY_QUERY` al `allowedAnalyses` controllo.
```
{
allowedAnalyses: ["ANY_QUERY"],
allowedAnalysisProviders: string[]
}
```
## Esempio di regola di analisi personalizzata
L'esempio seguente dimostra come due aziende possono collaborare AWS Clean Rooms utilizzando la regola di analisi personalizzata.
L'azienda A dispone di dati sui clienti e sulle vendite. L'azienda A è interessata a comprendere l'incrementalità delle vendite di una campagna pubblicitaria sul sito della Società B. L'azienda B dispone di dati sulle visualizzazioni e attributi dei segmenti utili all'azienda (ad esempio, il dispositivo utilizzato per visualizzare la pubblicità).
L'azienda A ha una query di incrementalità specifica che desidera eseguire nell'ambito della collaborazione.
Per creare una collaborazione ed eseguire un'analisi personalizzata in collaborazione, le aziende eseguono le seguenti operazioni:
1. L'azienda A crea una collaborazione e crea un'iscrizione. La collaborazione ha l'azienda B come altro membro della collaborazione. La società A consente la registrazione delle interrogazioni nella collaborazione e la registrazione delle interrogazioni nel proprio account.
1. L'azienda B crea un'appartenenza alla collaborazione. Consente la registrazione delle interrogazioni nel proprio account.
1. L'azienda A crea una tabella configurata con CRM
1. La società A aggiunge una regola di analisi personalizzata vuota alla tabella configurata per le vendite.
1. La società A associa la tabella configurata per le vendite alla collaborazione.
1. La società B crea una tabella configurata per la visualizzazione.
1. La società B aggiunge una regola di analisi personalizzata vuota alla tabella configurata per la visualizzazione.
1. La società B associa la tabella configurata per la visualizzazione alla collaborazione.
1. La società A visualizza la tabella delle vendite e la tabella delle visualizzazioni associate alla collaborazione e crea un modello di analisi, aggiungendo la query di incrementalità e il parametro per il mese della campagna.
```
{
"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
"
}
```
1. La società A aggiunge il proprio account (ad esempio, 444455556666) al controllo consentito dal fornitore di analisi nella regola di analisi personalizzata. Utilizzano il controllo del provider di analisi consentito perché desiderano consentire l'esecuzione di tutte le query create sulla tabella configurata per le vendite.
```
{
"allowedAnalyses": [
"ANY_QUERY"
],
"allowedAnalysisProviders": [
"444455556666"
]
}
```
1. L'azienda B vede il modello di analisi creato nell'ambito della collaborazione e ne esamina il contenuto, inclusi la stringa di query e il parametro.
1. La società B stabilisce che il modello di analisi soddisfa il caso d'uso dell'incrementalità e soddisfa i requisiti di privacy relativi alle modalità di interrogazione della tabella configurata per la visualizzazione.
1. La società B aggiunge il modello di analisi ARN al controllo di analisi consentito nella regola di analisi personalizzata della tabella di visualizzazione. Utilizzano il controllo di analisi consentito perché desiderano solo consentire l'esecuzione della query di incrementalità sulla tabella configurata per la visualizzazione.
```
{
"allowedAnalyses": [
"arn:aws:cleanrooms:us-east-1:111122223333:membership/41327cc4-bbf0-43f1-b70c-a160dddceb08/analysistemplate/1ff1bf9d-781c-418d-a6ac-2b80c09d6292"
]
}
```
1. La società A esegue il modello di analisi e utilizza il valore del parametro. `05-01-2023`
## Regola di analisi personalizzata con privacy differenziale
Nel AWS Clean Rooms, la regola di analisi personalizzata supporta la privacy differenziale. La privacy differenziale è un framework matematicamente rigoroso per la protezione della privacy dei dati che consente di proteggere i dati dai tentativi di reidentificazione.
La privacy differenziale supporta analisi aggregate come la pianificazione di campagne pubblicitarie, la post-ad-campaign misurazione, il benchmarking in un consorzio di istituti finanziari e i test A/B per la ricerca sanitaria.
La struttura e la sintassi delle query supportate sono definite in. [Struttura e sintassi delle query](#dp-query-structure-syntax)
### Regola di analisi personalizzata con esempio di privacy differenziale
**Nota**
AWS Clean Rooms La privacy differenziale è disponibile solo per le collaborazioni in cui i dati sono archiviati in Amazon S3.
Considera l'[esempio di regola di analisi personalizzata](#custom-example) presentato nella sezione precedente. Questo esempio dimostra come è possibile utilizzare la privacy differenziale per proteggere i dati dai tentativi di reidentificazione, permettendo al contempo al partner di acquisire informazioni fondamentali per l'azienda dai dati. Supponiamo che l'azienda B, che dispone dei dati sulle visualizzazioni, voglia proteggere i propri dati utilizzando una privacy differenziale. Per completare la configurazione della privacy differenziale, l'azienda B completa i seguenti passaggi:
1. La società B attiva la privacy differenziale aggiungendo una regola di analisi personalizzata alla tabella configurata per la visualizzazione. La società B seleziona `viewershipdata.hashedemail` come colonna identificativa dell'utente.
1. La società B [aggiunge una politica sulla privacy differenziale](configure-differential-privacy.md) alla collaborazione per rendere disponibile la tabella dei dati di visualizzazione per le interrogazioni. L'azienda B seleziona la politica predefinita per completare rapidamente la configurazione.
La società A, che desidera comprendere l'incrementalità delle vendite di una campagna pubblicitaria sul sito dell'azienda B, utilizza il modello di analisi. Poiché la query è compatibile con la [struttura di interrogazione generica di AWS Clean Rooms Differential Privacy, la query](#dp-query-structure-syntax) viene eseguita correttamente.
### Struttura e sintassi delle query
Le query contenenti almeno una tabella con la privacy differenziale attivata devono rispettare la sintassi seguente.
```
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**
Per quanto riguarda la struttura e la sintassi delle query di privacy differenziali, tenete presente quanto segue:
Le sottoquery non sono supportate.
Common Table Expressions (CTEs) dovrebbe emettere la colonna dell'identificatore utente se una tabella o un CTE coinvolgono dati protetti dalla privacy differenziale. I filtri, i raggruppamenti e le aggregazioni devono essere eseguiti a livello di utente.
Final\$1select consente le funzioni di aggregazione COUNT DISTINCT, COUNT, SUM, AVG e STDDEV.
Per ulteriori dettagli su quali parole chiave SQL sono supportate per la privacy differenziale, vedere. [Funzionalità SQL di AWS Clean Rooms Differential Privacy](dp-sql-capabilities.md)
# Regola di analisi della tabella di mappatura degli ID
In AWS Clean Rooms, una regola di analisi della *tabella di mappatura degli ID non è una regola di analisi* autonoma. Questo tipo di regola di analisi è gestita AWS Clean Rooms e utilizzata per unire dati di identità diversi per facilitare l'esecuzione di query. Viene aggiunta automaticamente alle tabelle di mappatura degli ID e non può essere modificata. Eredita i comportamenti delle altre regole di analisi previste dalla collaborazione, purché tali regole di analisi siano omogenee.
La regola di analisi della tabella di mappatura degli ID impone la sicurezza su una tabella di mappatura degli ID. Impedisce a un membro della collaborazione di selezionare o ispezionare direttamente la popolazione non sovrapposta tra i set di dati dei due membri utilizzando la tabella di mappatura degli ID. La regola di analisi della tabella di mappatura degli ID viene utilizzata per proteggere i dati sensibili nella tabella di mappatura degli ID quando viene utilizzata implicitamente in query con altre regole di analisi.
Con la regola di analisi della tabella di mappatura degli ID, AWS Clean Rooms impone una sovrapposizione su entrambi i lati della tabella di mappatura degli ID in SQL espanso. Ciò consente di eseguire le seguenti attività:
+ Utilizza la sovrapposizione della tabella di mappatura degli ID nelle JOIN istruzioni.
AWS Clean Rooms consente un INNERLEFT, o un RIGHT join nella tabella di mappatura degli ID se rispetta la sovrapposizione. Per proteggere le informazioni di mappatura sensibili, la tabella di mappatura degli ID deve essere sempre sul lato "inner" di qualsiasi operazione. JOIN Ad esempio, sono valide le seguenti JOIN operazioni:
+ table LEFT JOIN id\$1mapping\$1table
+ id\$1mapping\$1table RIGHT JOIN table
+ table INNER JOIN id\$1mapping\$1table
Le seguenti JOIN operazioni non sono valide:
+ id\$1mapping\$1table LEFT JOIN table
+ table RIGHT JOIN id\$1mapping\$1table
Ciò impedisce l'esposizione dei record di mappatura che non hanno corrispondenze corrispondenti nel set di dati. L'autorizzazione di tali operazioni potrebbe potenzialmente rivelare informazioni sensibili sulle mappature dei dati degli altri membri della collaborazione.
+ Usa le colonne della tabella di mappatura nelle istruzioni. JOIN
Non è possibile utilizzare le colonne della tabella di mappatura nelle seguenti istruzioni:SELECT,, WHERE HAVINGGROUP BY, o ORDER BY (a meno che non vengano modificate le protezioni sull'associazione dello spazio dei nomi dell'ID di origine o sull'associazione dello spazio dei nomi dell'ID di destinazione).
+ In SQL espanso, supporta AWS Clean Rooms OUTER JOIN anche, implicit e CROSS. JOIN JOIN Questi join non possono soddisfare i requisiti di sovrapposizione. Viene invece AWS Clean Rooms utilizzato `requireOverlap` per specificare su quali colonne devono essere unite.
La struttura e la sintassi delle interrogazioni supportate sono definite in. [Struttura e sintassi delle query della tabella di mappatura degli ID](#id-mapping-table-query-controls)
I parametri della regola di analisi, definita in[Controlli di interrogazione delle regole di analisi delle tabelle di mappatura degli ID](#parameters-id-mapping-query-controls), includono i controlli di interrogazione e i controlli dei risultati delle query. I suoi controlli di interrogazione includono la possibilità di richiedere la sovrapposizione della tabella di mappatura degli ID nelle JOIN istruzioni (ovvero,). `requireOverlap`
**Topics**
+ [Struttura e sintassi delle query della tabella di mappatura degli ID](#id-mapping-table-query-controls)
+ [Controlli di interrogazione delle regole di analisi delle tabelle di mappatura degli ID](#parameters-id-mapping-query-controls)
+ [Struttura predefinita della regola di analisi della tabella di mappatura degli ID](#id-mapping-table-predefined-structure)
+ [Regola di analisi della tabella di mappatura degli ID: esempio](#id-mapping-table-example)
## Struttura e sintassi delle query della tabella di mappatura degli ID
Le interrogazioni su tabelle che dispongono di una regola di analisi delle tabelle di mappatura degli ID devono rispettare la seguente sintassi.
```
--select_list_expression
SELECT
provider.data_col, consumer.data_col
--table_expression
FROM provider
JOIN idMappingTable idmt ON provider.id = idmt.sourceId
JOIN consumer ON consumer.id = idmt.targetId
```
### Tabelle di collaborazione
Le tabelle seguenti rappresentano tabelle configurate esistenti in una AWS Clean Rooms collaborazione. La colonna **id** in entrambe le tabelle **cr\$1drivers\$1license e **cr\$1insurance**** rappresenta una colonna da abbinare alla tabella di mappatura degli ID.
**cr\$1drivers\$1license**
| | | |
| --- |--- |--- |
| id | nome\$1driver | stato\$1di\$1registrazione |
| 1 | Eduard | TX |
| 2 | - Dana | MA |
| 3 | Gweneth | IL |
**cr\$1insurance**
| | | |
| --- |--- |--- |
| id | policyholder\$1email | numero\$1politica |
| a | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 |
| b | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 |
| c | rosa@internal.company.com | d7692e84-3d3c-47b8-b46d-a0d5345f0601 |
### Tabella di mappatura degli ID
**La tabella seguente rappresenta una tabella di mappatura degli ID esistente che corrisponde alle tabelle **cr\$1drivers\$1license e cr\$1insurance**.** Non tutte le voci avranno per entrambe le tabelle di collaborazione. IDs
| | |
| --- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id |
| 1 | a |
| 2 | null |
| 3 | b |
| null | c |
La regola di analisi della tabella di mappatura degli ID consente solo l'esecuzione di query sull'insieme di dati sovrapposti, che avrebbero il seguente aspetto:
| | | | | | |
| --- |--- |--- |--- |--- |--- |
| cr\$1drivers\$1license\$1id | cr\$1insurance\$1id | nome\$1conducente | stato\$1di\$1registrazione | policyholder\$1email | numero\$1politica |
| 1 | a | Eduard | TX | eduardo@internal.company.com | 17f9d04e-f5be-4426-bdc4-250ed59c6529 |
| 3 | b | Gweneth | IL | gwen@internal.company.com | 3f0092db-2316-48a8-8d44-09cf8f6e6c64 |
### Query di esempio
Gli esempi seguenti mostrano posizioni valide per i join della tabella di mappatura degli ID:
```
-- Single ID mapping table
SELECT
[ select_items ]FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
;
-- Single ID mapping table (Subquery)
SELECT
[ select_items ]FROM (
SELECT
[ select_items ]
FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
)
;
-- Single ID mapping table (CTE)
WITH
matched_ids AS (
SELECT
[ select_items ]
FROM
cr_drivers_license cr_dl
[ INNER | LEFT ] JOIN cr_identity_mapping_table idmt ON idmt.cr_drivers_license_id = cr_dl.id
[ INNER | RIGHT ] JOIN cr_insurance cr_in ON idmt.cr_insurance_id = cr_in.id
)SELECT
[ select_items ]FROM
matched_ids
;
```
### Considerazioni
Per quanto riguarda la struttura e la sintassi delle query della tabella di mappatura degli ID, tenete presente quanto segue:
+ Non puoi modificarlo.
+ Per impostazione predefinita, viene applicato alla tabella di mappatura degli ID.
+ Utilizza un'associazione di namespace ID di origine e destinazione all'interno della collaborazione.
+ La tabella di mappatura degli ID è configurata per impostazione predefinita per fornire protezioni predefinite per la colonna che proviene dallo spazio dei nomi ID. È possibile modificare questa configurazione in modo che la colonna che proviene dallo spazio dei nomi ID (`sourceID`o`targetID`) possa essere consentita in qualsiasi punto della query. Per ulteriori informazioni, consulta [Namespace ID in AWS Clean Rooms](working-with-id-namespaces.md).
+ La regola di analisi della tabella di mappatura degli ID eredita le restrizioni SQL delle altre regole di analisi della collaborazione.
## Controlli di interrogazione delle regole di analisi delle tabelle di mappatura degli ID
Con i controlli di interrogazione della tabella di mappatura degli ID, AWS Clean Rooms controlla come le colonne della tabella vengono utilizzate per interrogare la tabella. Ad esempio, controlla quali colonne vengono utilizzate per l'unione e quali colonne devono essere sovrapposte. La regola di analisi della tabella di mappatura degli ID include anche funzionalità che consentono di consentire la `sourceID` proiezione di`targetID`, di o di entrambe senza richiedere un JOIN.
Nella tabella seguente viene illustrato ogni controllo.
| Controllo | Definizione | Utilizzo |
| --- | --- | --- |
| joinColumns | Le colonne che il membro che può eseguire la query può utilizzare nell'istruzione INNER JOIN. | Non è possibile joinColumns utilizzarle in altre parti della query diverse da INNER JOIN.Per ulteriori informazioni, consulta [Unisci i controlli](analysis-rules-aggregation.md#join-controls). |
| dimensionColumns | Le colonne (se presenti) che il membro che può eseguire la query può utilizzare nelle istruzioni SELECT e GROUP BY. | A `dimensionColumn` può essere utilizzato in SELECT e GROUPBY. A `dimensionColumn` può apparire come`joinKeys`. È possibile utilizzarla `dimensionColumns` nella clausola JOIN solo se la si specifica tra parentesi. |
| queryContraints:RequireOverlap | Le colonne della tabella di mappatura degli ID che devono essere unite per poter eseguire la query. | Queste colonne devono essere utilizzate per UNIRE la tabella di mappatura degli ID e una tabella di collaborazione. |
## Struttura predefinita della regola di analisi della tabella di mappatura degli ID
La struttura predefinita per una regola di analisi della tabella di mappatura degli ID include protezioni predefinite che vengono applicate alla e. `sourceID` `targetID` Ciò significa che la colonna con le protezioni applicate deve essere utilizzata nelle query.
È possibile configurare la regola di analisi della tabella di mappatura degli ID nei seguenti modi:
+ Entrambi `sourceID` e protetti `targetID`
In questa configurazione, non è `targetID` possibile proiettare entrambi. `sourceID` Il `sourceID` e `targetID` deve essere utilizzato in un JOIN quando si fa riferimento alla tabella di mappatura degli ID.
+ Solo protetto `targetID`
In questa configurazione, non `targetID` possono essere proiettati. `targetID`Deve essere utilizzato in un JOIN quando si fa riferimento alla tabella di mappatura degli ID. `sourceID`Può essere usato nella query.
+ Solo `sourceID` protetto
In questa configurazione, non `sourceID` possono essere proiettati. `sourceID`Deve essere utilizzato in un JOIN quando si fa riferimento alla tabella di mappatura degli ID. `targetID`Può essere usato nella query.
+ Nessuno dei due `sourceID` o `targetID` protetto
In questa configurazione, la tabella di mappatura degli ID non è soggetta ad alcuna applicazione specifica che può essere utilizzata nelle query.
L'esempio seguente mostra una struttura predefinita per una regola di analisi della tabella di mappatura degli ID con le protezioni predefinite applicate alla sabbia. `sourceID` `targetID` In questo esempio, la regola di analisi della tabella di mappatura degli ID consente solo un INNER JOIN sia sulla colonna che sulla colonna. `sourceID` `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id",
"target_id"
]
}
}
],
"dimensionColumns": [] // columns that can be used in SELECT and JOIN
}
```
L'esempio seguente mostra una struttura predefinita per una regola di analisi della tabella di mappatura degli ID con protezioni applicate a. `targetID` In questo esempio, la regola di analisi della tabella di mappatura ID consente solo un INNER JOIN sulla colonna. `sourceID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"target_id"
]
}
}
],
"dimensionColumns": [
"source_id"
]
}
```
L'esempio seguente mostra una struttura predefinita per una regola di analisi della tabella di mappatura degli ID con protezioni applicate a. `sourceID` In questo esempio, la regola di analisi della tabella di mappatura ID consente solo un INNER JOIN sulla colonna. `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": [
"source_id"
]
}
}
],
"dimensionColumns": [
"target_id"
]
}
```
L'esempio seguente mostra una struttura predefinita per una regola di analisi della tabella di mappatura ID senza protezioni applicate all'or. `sourceID` `targetID` In questo esempio, la regola di analisi della tabella di mappatura degli ID consente un INNER JOIN sia sulla colonna che sulla colonna. `sourceID` `targetID`
```
{
"joinColumns": [
"source_id",
"target_id"
],
"queryConstraints": [
{
"requireOverlap": {
"columns": []
}
}
],
"dimensionColumns": [
"source_id",
"target_id"
]
}
```
## Regola di analisi della tabella di mappatura degli ID: esempio
Invece di scrivere una lunga dichiarazione a cascata che faccia riferimento a informazioni di identificazione personale (PII), ad esempio, le aziende possono utilizzare la regola di analisi delle tabelle di mappatura degli ID per utilizzare la transcodifica multipartitica. LiveRamp L'esempio seguente dimostra come è possibile collaborare all'utilizzo della regola di analisi delle tabelle di mappatura degli ID. AWS Clean Rooms
La società A è un inserzionista che dispone di dati sui clienti e sulle vendite, che verranno utilizzati come fonte. La società A esegue anche la transcodifica per conto delle parti coinvolte nella collaborazione e fornisce le credenziali. LiveRamp
La società B è un editore che dispone di dati sugli eventi, che verranno utilizzati come destinazione.
**Nota**
La società A o la società B possono fornire credenziali di LiveRamp transcodifica ed eseguire la transcodifica.
Per creare una collaborazione che consenta l'analisi delle tabelle di mappatura degli ID in collaborazione, le aziende eseguono le seguenti operazioni:
1. La società A crea una collaborazione e crea un'iscrizione. Aggiunge la società B, che crea anche un'appartenenza alla collaborazione.
1. La società A associa una fonte di namespace ID esistente o ne crea una nuova AWS Entity Resolution utilizzando la console. AWS Clean Rooms
La società A crea una tabella configurata con i relativi dati di vendita e una colonna inserita nella tabella di mappatura degli `sourceId` ID.
L'origine del namespace ID fornisce i dati da transcodificare.
1. La società B associa una destinazione dello spazio dei nomi ID esistente o ne crea una nuova utilizzando la console. AWS Entity Resolution AWS Clean Rooms
La società B crea una tabella configurata con i dati relativi agli eventi e una colonna inserita nella tabella di mappatura degli `targetId` ID.
Il target dello spazio dei nomi ID non fornisce dati da transcodificare, ma solo metadati relativi alla configurazione. LiveRamp
1. L'azienda A scopre i due namespace ID associati alla collaborazione e crea e popola una tabella di mappatura degli ID.
1. La società A esegue una query sui due set di dati unendosi alla tabella di mappatura degli ID.
```
--- this would be valid for Custom or List
SELECT provider.data_col, consumer.data_col
FROM provider
JOIN idMappingTable-123123123123-myMappingWFName idmt
ON provider.id = idmt.sourceId
JOIN consumer
ON consumer.id = idmt.targetId
```