Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Regla de análisis personalizada en AWS Clean Rooms

En AWS Clean Rooms, una regla de análisis personalizada es un nuevo tipo de regla de análisis que permite ejecutar consultas personalizadas en la tabla configurada. Las consultas SQL personalizadas mantienen la restricción de tener solo el comando SELECT, pero pueden usar más constructos SQL que las consultas de agregación y las consultas de lista (por ejemplo, funciones de ventana, OUTER JOIN, CTE o subconsultas; consulte Referencia de SQL de AWS Clean Rooms para obtener una lista completa). Las consultas SQL personalizadas no tienen que seguir una estructura de consulta como las consultas de agregación y las consultas de lista.

La regla de análisis personalizada admite casos de uso más avanzados que los que admite una regla de análisis de agregación y de lista, como análisis de atribución personalizado, análisis comparativo, análisis de incrementalidad y detección de audiencias. Esto se suma a un superconjunto de casos de uso compatibles con la regla de análisis de agregación y de lista.

La regla de análisis personalizado también admite privacidad diferencial. La privacidad diferencial es un marco matemáticamente riguroso para la protección de la privacidad de los datos. Para obtener más información, consulte AWS Clean Rooms Privacidad diferencial. Al crear una plantilla de análisis, AWS Clean Rooms Differential Privacy comprueba la plantilla para determinar si es compatible con la estructura de consultas de uso general para AWS Clean Rooms Differential Privacy. Esta validación garantiza que no se cree una plantilla de análisis que no esté permitida con una tabla con protección de privacidad diferencial.

Para configurar la regla de análisis personalizada, los propietarios de los datos pueden optar por permitir que determinadas consultas personalizadas, almacenadas en plantillas de análisis, se ejecuten en sus tablas configuradas. Los propietarios de los datos revisan las plantillas de análisis antes de añadirlas al control de análisis permitido en la regla de análisis personalizada. Las plantillas de análisis están disponibles y visibles solo en la colaboración en la que se crean (incluso si la tabla está asociada a otras colaboraciones) y solo las puede ejecutar el miembro que pueda realizar consultas en esa colaboración.

Como alternativa, los miembros pueden optar por permitir que otros miembros (proveedores de consultas) creen consultas sin revisión. Los miembros añaden las cuentas de proveedores de consultas que los proveedores de consultas permitidos pueden controlar en la regla de análisis personalizada. Si el proveedor de consultas es el miembro que puede realizar la consulta, este puede ejecutar cualquier consulta directamente en la tabla configurada. Los proveedores de consultas también pueden crear consultas mediante la creación de plantillas de análisis. Todas las consultas que hayan creado los proveedores de consultas pueden ejecutarse automáticamente en la tabla en todas las colaboraciones en las que estén presentes y la tabla esté asociada. Cuenta de AWS

Esta página contiene las siguientes secciones:

La regla de análisis personalizado admite los siguientes controles que mejoran la privacidad:

Estructura de reglas de análisis personalizada

La siguiente estructura predefinida muestra los controles disponibles en una regla de análisis personalizada. Incluya solo los controles que necesita para su caso de uso. El userIdentifier valor del differentialPrivacy control es la columna que identifica de forma exclusiva a los usuarios, como user_id. Cuando tiene dos o más tablas con la privacidad diferencial activada en una colaboración, es AWS Clean Rooms necesario configurar la misma columna que la columna del identificador de usuario en ambas reglas de análisis. De este modo, se mantiene una definición uniforme de los usuarios en todas las tablas.

{
  "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"
      }
    ]
  }
}

Puede:

También puede configurar cualquiera de los siguientes controles:

La configuración recomendada es configurar los umbrales mínimos de agregación junto con los controles de comparación. Un umbral por sí solo permite que las columnas de baja cardinalidad o cuasiidentificativas sean comparables, lo que puede reducir los resultados de manera imprevista.

Vale la pena configurar los controles de comparación cuando la tabla contiene columnas con valores cardinales bajos o casi identificativos (como códigos postales o franjas de edad) o cuando el ejecutor de consultas no es de plena confianza. Para ver un ejemplo práctico en el que se muestran ambos controles configurados a la vez, consulte. Ejemplo de regla de análisis personalizada con umbrales mínimos de agregación y controles de comparación

Ejemplo de regla de análisis personalizada con plantillas de análisis

El siguiente ejemplo demuestra cómo dos empresas pueden colaborar en el AWS Clean Rooms uso de la regla de análisis personalizada.

La empresa A tiene datos de clientes y de ventas. La empresa A está interesada en conocer la incrementalidad de las ventas de una campaña publicitaria en el sitio de la empresa B. La empresa B tiene datos de visualizaciones y atributos de segmento que son útiles para la empresa (por ejemplo, el dispositivo utilizado para ver la publicidad).

La empresa A tiene una consulta de incrementalidad específica que quiere ejecutar en la colaboración.

Para crear una colaboración y ejecutar en ella un análisis personalizado, las empresas hacen lo siguiente:

Ejemplo de regla de análisis personalizada con umbrales mínimos de agregación

El siguiente ejemplo demuestra cómo dos empresas pueden colaborar para AWS Clean Rooms utilizar la regla de análisis personalizada con umbrales de agregación mínimos en lugar de revisar las plantillas de análisis individuales.

La empresa A es una editorial con una impressions tabla que contiene user_idcampaign_id, yevent_date. La empresa B es un anunciante que quiere medir el alcance de la campaña, es decir, el número de usuarios distintos que han visto una campaña determinada. La empresa A quiere asegurarse de que ningún resultado de una consulta revele a personas o grupos pequeños, por lo que utiliza umbrales mínimos de agregación en lugar de revisar las plantillas de análisis individuales.

Para crear una colaboración y ejecutar un análisis personalizado, las empresas hacen lo siguiente:

La diferencia clave con respecto al enfoque de las plantillas de análisis es que la empresa A nunca revisó una consulta específica. En cambio, la empresa A se basa en el umbral para restringir lo que puede arrojar cualquier consulta. Para obtener más información, consulte Umbrales mínimos de agregación y Controles de comparación.

Ejemplo de regla de análisis personalizada con umbrales mínimos de agregación y controles de comparación

La configuración básica recomendada es configurar los umbrales mínimos de agregación junto con los controles de comparación. Un umbral por sí solo garantiza que cada fila de resultados represente un número mínimo de sujetos de datos distintos, pero no impide las comparaciones en columnas con un nivel de cardinalidad bajo o casi identificativas. Sin controles de comparación, un ejecutor de consultas puede seguir filtrando o uniendo esas columnas, lo que podría reducir los resultados de forma imprevista.

Vale la pena configurar los controles de comparación cuando la tabla contiene columnas con valores cardinales bajos o casi identificativos (como códigos postales o franjas de edad) o cuando no se confía plenamente en el ejecutor de consultas. La adición de controles de comparación restringe las columnas que pueden aparecer en las comparaciones literales y entre columnas, lo que cierra la brecha que deja un umbral por sí solo.

La siguiente configuración combina ambos controles:

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

Con esta configuración, cada fila de resultados representa al menos 100 sujetos de datos distintos. El ejecutor de consultas puede filtrar campaign_id mediante comparaciones literales y unirse user_id mediante comparaciones de columna a columna. Como las listas de comparación permitidas están configuradas, ninguna columna que no aparezca en la lista (incluidas las columnas con valores cardinales bajos, como el código postal o el grupo de edad) no se puede utilizar en absoluto en una comparación.

Para obtener más información sobre cada control, consulte y. Umbrales mínimos de agregación Controles de comparación Para obtener una configuración más completa que también incluya las columnas de salida no permitidas, consulteResumen global.

Resumen global

El siguiente ejemplo muestra una configuración completa del tipo de regla de análisis personalizada, con columnas de salida no permitidas, umbrales mínimos de agregación y controles de comparación. Esta configuración impone la agregación mínima de 100 sujetos de datos distintos, user_id evita que se proyecten en el resultado de la consulta y permite al ejecutor de la consulta analizar la intersección de los clientes que se unen en la columna. user_id

Esta política también otorga flexibilidad adicional al permitir el filtrado de comparaciones literales en las columnas de baja sensibilidad status yprice, además, anula el umbral mínimo de agregación de 5 para la columna: campaign_id

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