Referência de construção de regra de política de consentimento

Use essa referência na lógica de regra avançada para definir regras precisas e legalmente válidas na cláusula Then do Construtor de políticas de consentimento no Adobe Experience Platform.

Saiba como as regras de política se aplicam à estrutura e aos tipos dos dados de consentimento para aplicar com precisão as preferências de consentimento do cliente.

Leia este documento para saber como filtrar perfis com base em consentimento navegando até campos de container no esquema XDM e selecionando um campo primitivo. Em seguida, use o operador apropriado para definir o valor exato que um perfil deve corresponder.

Pré-requisitos

Antes de usar essa referência, verifique se a configuração da sua política de consentimento está completa e se você compreende os conceitos fundamentais da arquitetura de dados e da estrutura de governança da Adobe Experience Platform.

Certifique-se de atender aos seguintes pré-requisitos:

Conceitos principais: campos primitivos e de contêiner

Leia esta seção para saber como as regras de política de consentimento usam diferentes tipos de campo em esquemas XDM. Entender a distinção entre contêiner e campos primitivos ajuda a selecionar o campo e o operador corretos ao definir as condições da política.

Tipos de campo e lógica de regra compatíveis

As políticas de consentimento aceitam vários tipos de campo, cada um com operadores específicos para a criação de condições de regra. Os tipos de campo são agrupados em duas categorias: tipos de contêiner e tipos primitivos.

Tipos de contêiner (navegação por esquema)

Os tipos de contêiner organizam os dados de consentimento, mas não podem ser usados diretamente nas condições da política. Eles servem como caminhos de navegação para alcançar os campos primitivos que contêm valores reais.

Tipos primitivos (condições da regra)

Os campos primitivos contêm os valores de dados de consentimento reais (por exemplo, true ou "weekly") e são os únicos tipos de campo que podem ser usados para definir condições de política.

A tabela abaixo descreve cada tipo primitivo suportado e os operadores disponíveis.

Trabalho com estruturas de dados complexas

Leia esta seção para saber como navegar em containers aninhados no esquema de consentimento para alcançar campos primitivos. Ele apresenta padrões de esquema comuns e explica como estruturas mais profundas permitem uma lógica de consentimento mais granular.

Manuseio de estruturas de esquema aninhadas e complexas

Esquemas de consentimento complexos geralmente incluem estruturas de contêiner aninhadas que oferecem suporte a gerenciamento de dados flexível e escalável. Como as regras de política só podem fazer referência a campos primitivos, você deve navegar pelas hierarquias de container para chegar aos campos que podem ser usados nas condições de política de consentimento. O aninhamento mais profundo permite o direcionamento de regras mais granulares e específicas.

Padrões comuns de contêiner aninhado incluem:

Exemplo de estrutura de campo

A estrutura a seguir serve como referência visual para exemplos de regras neste guia.

consent.marketing (Object)
├── email (Boolean)
├── sms (Boolean)
├── preferences (Map with dynamic keys)
│   ├── "email_preferences" (Object)
│   │   ├── frequency (String)
│   │   └── channels (Array of Strings)
│   ├── "sms_preferences" (Object)
│   │   ├── frequency (String)
│   │   └── opt_in_time (Date)
│   └── "push_preferences" (Object)
│       ├── frequency (String)
│       └── categories (Array of Strings)
└── lastUpdated (Date)

Criação de regra avançada por tipo de campo

Leia esta seção para obter uma orientação detalhada sobre como criar regras de política de consentimento com base no tipo de campo. Você aprenderá a configurar a lógica de regras para boolianos, mapas, objetos e arrays para capturar condições de consentimento precisas.

Componentes e etapas de criação de regras

A criação de regras eficazes de política de consentimento requer a compreensão de como navegar na estrutura do esquema e aplicar os operadores corretos para cada tipo de campo. Cada regra segue a mesma abordagem básica: navegue até um campo primitivo, selecione o operador apropriado e defina a condição que deve ser atendida.

Siga estas etapas para criar uma regra:

Trabalhar com campos booleanos (lógica de consentimento implícito)

Os campos booleanos armazenam valores de consentimento verdadeiros ou falsos e representam os atributos de consentimento mais comuns. O operador is not equal to permite que você inclua perfis que não tenham sido explicitamente excluídos, oferecendo suporte a cenários de consentimento implícito.

Operadores e resultados booleanos

Exemplo: Consentimento de email implícito

Field: consent.marketing.email (boolean)
Operator: is not equal to
Value: false
Result: Includes profiles who have not explicitly opted out of email marketing (includes both true and missing/null values).

Trabalho com campos de mapa (preferências dinâmicas)

Os campos de mapa armazenam pares de valores-chave com chaves dinâmicas, ao contrário de objetos que têm esquemas fixos. Os mapas são usados com frequência em centros de preferências, onde novas categorias podem ser adicionadas sem atualizações de esquema. Você pode direcionar chaves específicas ou usar a correspondência curinga em todas as chaves.

Correspondência de chave específica

Use essa abordagem para direcionar uma categoria de preferência específica.

Field: consent.preferences["email_preferences"].frequency (string) - navigated to from the map container
Operator: is equal to
Value: "weekly"
Result: Includes profiles who set the email frequency to weekly (for the "email_preferences" key)

Qualquer correspondência de chave

Use a opção de caixa de seleção "find any matching item" para corresponder todas as chaves dinâmicas em um mapa.

Field: consent.preferences.*.frequency (string)
Operator: is equal to
Value: "weekly"
Result: Includes profiles who set frequency to weekly in ANY preference category (for example, email_preferences, sms_preferences, or push_preferences)

Trabalhar com campos de objeto (navegação fixa)

Os campos de objeto atuam como contêineres com esquemas fixos. Eles são usados apenas para navegação e não podem ser referenciados diretamente em condições de política.

Exemplo de navegação

consent.marketing (object) → consent.marketing.email (boolean)

Exemplo de caso de uso:

Field: consent.marketing.email (Boolean) - navigated to from the object
Operator: is equal to
Value: true
Result: Include profiles who have explicitly consented to marketing emails

Trabalhar com campos de matriz (vários valores)

Os campos de matriz contêm vários valores do mesmo tipo e requerem manipulação diferente dependendo se eles armazenam primitivos ou objetos. As opções de navegação e operador variam de acordo com o tipo de matriz.

Matriz de exemplos primitivos

Use o operador contains para identificar perfis com base em valores específicos em uma matriz.

Field: consent.communication_channels (array of strings)
Operator: contains
Value: "email"
Result: Include profiles who have consented to email communication

Exemplo de matriz de objetos

Navegue até a matriz para acessar campos primitivos dentro de objetos aninhados.

Field: consent.preferences["email_preferences"].categories[].type - navigated to from the array
Operator: is equal to
Value: "promotional"
Result: Include profiles where any email category is "promotional"

Combinação de regras com lógica complexa

Esta seção explica como combinar várias condições de regra usando a lógica AND ou OR. Você aprenderá como os operadores lógicos trabalham juntos para definir políticas avançadas de consentimento de várias condições.

Combinação de várias condições (lógica AND ou OR)

É possível combinar várias condições de regra usando a lógica AND ou OR para criar políticas de consentimento mais sofisticadas que segmentem segmentos de perfil específicos.
A lógica AND exige que todas as condições sejam verdadeiras, produzindo correspondências de público-alvo mais estreitas.
A lógica OR permite que qualquer condição seja verdadeira, expandindo o alcance do público-alvo.

Na interface da política de consentimento, use o seletor de lógica que aparece entre as condições da regra para alternar entre a lógica E e OU.

Exemplo de regra complexa geral

O exemplo a seguir combina o status de consentimento básico com a frequência de preferência para criar um segmento direcionado.

Field: consent.marketing.email
Operator: is equal to true
AND
Field: consent.preferences.frequency
Operator: is not equal to "daily"
Result: Include profiles who consent to email marketing but not to a daily frequency

Lógica avançada para arrays de objetos

Ao combinar condições em matrizes de objetos, o comportamento depende do uso da lógica AND ou OR entre as condições.

Exemplo: Matriz de objetos com condições AND

Use a lógica AND quando todas as condições forem aplicáveis ao elemento de matriz same.

Field: consent.preferences["email_preferences"].categories[].enabled (boolean)
Operator: is equal to
Value: true
AND
Field: consent.preferences["email_preferences"].categories[].type (string)
Operator: is equal to
Value: "promotional"
Result: Includes profiles where the same category entry has both enabled=true and type="promotional".
Note: AND conditions apply to the same array entry. Using OR logic would include profiles if any array entry matches any of the conditions.

Exemplo: Matriz de objetos com condições OR

Use a lógica OU para criar correspondências de público-alvo inclusivas, permitindo que qualquer condição seja verdadeira nas entradas da matriz.

Field: consent.preferences["email_preferences"].categories[].enabled (boolean)
Operator: is equal to
Value: true
OR
Field: consent.preferences["email_preferences"].categories[].type (string)
Operator: is equal to
Value: "newsletter"
Result: Includes profiles where any category entry has enabled=true or any entry has type="newsletter".
Note: OR logic allows matching across different array entries. One entry can meet the first condition while another meets the second.

Próximas etapas

Depois de criar e refinar suas regras de política de consentimento, use os seguintes recursos para finalizar a configuração, validar a aplicação de política e revisar os modelos de dados subjacentes.