翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

のカスタム分析ルール AWS Clean Rooms

では AWS Clean Rooms、カスタム分析ルールは、設定されたテーブルでカスタムクエリを実行できるようにする新しいタイプの分析ルールです。カスタム SQL クエリは、現在も SELECT コマンドの使用のみに制限されていますが、集約クエリやリストクエリよりも多くの SQL 構文を使用できます (例えば、ウィンドウ関数、OUTER JOIN、CTE、サブクエリなど。詳細なリストについては、「AWS Clean Rooms SQL リファレンス」を参照してください)。カスタム SQL クエリでは、集約クエリやリストクエリのようなクエリ構造に従う必要はありません。

カスタム分析ルールは、カスタムアトリビューション分析、ベンチマーキング、増分解析、オーディエンス発掘など、集計分析ルールやリスト分析ルールよりも高度なユースケースに対応します。これは、集計分析ルールおよびリスト分析ルールでサポートされるユースケースのスーパーセットに追加されるものです。

カスタム分析ルールは差分プライバシーもサポートします。差分プライバシーは、データプライバシー保護のための数学的に厳格なフレームワークです。詳細については、「AWS Clean Rooms 差分プライバシー」を参照してください。分析テンプレートを作成すると、 AWS Clean Rooms 差分プライバシーはテンプレートをチェックして、 AWS Clean Rooms 差分プライバシーの汎用クエリ構造と互換性があるかどうかを確認します。この検証により、差分プライバシー保護テーブルでは許可されない分析テンプレートが作成されなくなります。

カスタム分析ルールを設定する場合、データ所有者は、分析テンプレートに保存されている特定のカスタムクエリを自身の設定済みテーブルで実行することを許可できます。データ所有者は、分析テンプレートを確認してから、カスタム分析ルールの許可された分析コントロールに追加します。分析テンプレートは、(テーブルが他のコラボレーションに関連付けられている場合でも) 作成されたコラボレーションでのみ使用および表示され、そのコラボレーションでクエリを行えるメンバーのみが実行できます。

または、他のメンバー (クエリプロバイダー) が確認なしでクエリを作成できるよう許可することもできます。その場合は、許可対象のクエリプロバイダーが管理するクエリプロバイダーのアカウントをカスタム分析ルールに追加します。クエリプロバイダーがクエリを行えるメンバーであれば、設定済みテーブルで任意のクエリを直接実行できます。クエリプロバイダーは、分析テンプレートを作成することによってクエリを作成することもできます。クエリプロバイダーによって作成されたクエリは、 が存在し、テーブル AWS アカウント が関連付けられているすべてのコラボレーションで、テーブルで自動的に実行できます。

このページには、以下のセクションが含まれています。

カスタム分析ルールは、以下のプライバシー強化コントロールをサポートしています。

カスタム分析ルール構造

次の事前定義された構造は、カスタム分析ルールで使用可能なコントロールを示しています。ユースケースに必要なコントロールのみを含めます。differentialPrivacy コントロールのuserIdentifier値は、user_id など、ユーザーを一意に識別する列です。コラボレーションで差分プライバシーが有効になっているテーブルが 2 つ以上ある場合、 は両方の分析ルールでユーザー識別子列と同じ列を設定 AWS Clean Rooms する必要があります。これにより、テーブル間でユーザーの一貫した定義が維持されます。

{
  "allowedAnalyses": ["ANY_QUERY"] | string[],
  "allowedAnalysisProviders": [],
  "disallowedOutputColumns": [],
  "aggregationThresholds": [
    {
      "identityColumns": [],
      "minimumIdentityCount": number,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY" | "ANY_EXPRESSION",
      "outputColumnThresholds": [
        {
          "outputColumnName": string,
          "minimumIdentityCount": number
        }
      ]
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [],
    "allowedColumnComparisonColumns": []
  },
  "differentialPrivacy": {
    "columns": [
      {
        "name": "userIdentifier"
      }
    ]
  }
}

次のいずれかを行うことができます。

次のいずれかのコントロールを設定することもできます。

比較コントロールとともに最小集約しきい値を設定することが推奨されます。しきい値自体では、カーディナリティが低い列や準識別列が同等になり、意図しない方法で結果を絞り込む可能性があります。

比較コントロールは、郵便番号や年齢帯などの低カーディナリティまたは準識別列がテーブルに含まれている場合、またはクエリランナーが完全に信頼されていない場合に設定できます。両方のコントロールが一緒に設定されている実例については、「」を参照してください最小集計しきい値と比較コントロールを使用したカスタム分析ルールの例。

分析テンプレートを使用したカスタム分析ルールの例

次の例は、2 つの企業がカスタム分析ルール AWS Clean Rooms を使用して でコラボレーションする方法を示しています。

A 社には顧客データと売上データがあります。A 社は、B 社のサイトで実施した広告キャンペーンによる売上の増分を把握したいと考えています。B 社には、A 社にとって有用な閲覧データとセグメント属性 (広告を閲覧する際に使用したデバイスなど) があります。

企業 A には、コラボレーションで実行したい特定の増分クエリがあります。

コラボレーションを作成し、コラボレーションでカスタム分析を実行するために、各社は次のことを行います。

最小集計しきい値を使用したカスタム分析ルールの例

次の例は、2 つの企業が、個々の分析テンプレートを確認する代わりに、最小限の集計しきい値でカスタム分析ルール AWS Clean Rooms を使用してコラボレーションする方法を示しています。

A 社は、user_id、、campaign_idおよび を含むimpressionsテーブルを持つパブリッシャーですevent_date。B 社は、キャンペーンのリーチ、つまり特定のキャンペーンを見た個別のユーザーの数を測定する広告主です。A 社は、クエリ結果が個人や小グループを明らかにできないようにしたいため、個々の分析テンプレートを確認するのではなく、最小限の集計しきい値を使用します。

コラボレーションを作成し、カスタム分析を実行するために、企業は以下を実行します。

分析テンプレートアプローチとの主な違いは、A 社が特定のクエリをレビューしたことがないことです。代わりに、A 社はしきい値に依存して、クエリが返すことができるものを制約します。詳細については、「最小集計しきい値」および「比較コントロール」を参照してください。

最小集計しきい値と比較コントロールを使用したカスタム分析ルールの例

比較コントロールとともに最小集約しきい値を設定することが、推奨されるベースライン設定です。しきい値だけでは、すべての結果行が個別のデータサブジェクトの最小数を表しますが、低カーディナリティまたは準識別列の比較は妨げられません。比較コントロールがない場合でも、クエリランナーはそれらの列をフィルタリングまたは結合できるため、意図しない方法で結果を絞り込む可能性があります。

比較コントロールは、郵便番号や年齢帯などの低カーディナリティまたは準識別列がテーブルに含まれている場合、またはクエリランナーが完全に信頼されていない場合に設定できます。比較コントロールを追加すると、リテラル比較と列column-to-column比較で表示できる列が制限され、しきい値だけが開いたままにするギャップが閉じられます。

次の設定は、両方のコントロールを組み合わせています。

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

この設定では、すべての結果行が少なくとも 100 個の個別のデータセットを表します。クエリランナーは、リテラル比較campaign_idを使用してフィルタリングし、column-to-column比較user_idを使用して に結合できます。比較許可リストが設定されているため、郵便番号や経過時間バンドなどの低カーディナリティ列を含む、リストされていない列は、比較にまったく使用できません。

各コントロールの詳細については、最小集計しきい値「」および「」を参照してください比較コントロール。許可されていない出力列も含まれる詳細な設定については、「」を参照してくださいまとめ。

まとめ

次の例は、許可されていない出力列、最小集計しきい値、比較コントロールを使用した、カスタム分析ルールタイプの完全な設定を示しています。この設定では、100 個の個別のデータサブジェクトの最小集約を強制し、クエリ結果に が射影user_idされるのを防ぎ、クエリランナーがuser_id列に参加している顧客の交差を分析できるようにします。

また、このポリシーは、機密性の低い列statusと でリテラル比較フィルタリングを許可することで柔軟性を高めprice、campaign_id列の最小集約しきい値を 5 に上書きします。

{
  "disallowedOutputColumns": [
    "user_id"
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ],
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  },
  "aggregationThresholds": [
    {
      "identityColumns": [
        "user_id"
      ],
      "minimumIdentityCount": 100,
      "type": "COUNT_DISTINCT",
      "allowedAggregateExpressionType": "COLUMNS_ONLY",
      "outputColumnThresholds": [
        {
          "outputColumnName": "campaign_id",
          "minimumIdentityCount": 5
        }
      ]
    }
  ],
  "allowedAnalyses": [
    "ANY_QUERY"
  ],
  "allowedAnalysisProviders": [
    "444455556666",
    "333366669999"
  ]
}