Noções básicas da composição do schema

Este documento fornece uma introdução aos esquemas Experience Data Model (XDM) e aos blocos de construção, princípios e práticas recomendadas para a composição de schemas a serem usados no Adobe Experience Platform. Para obter informações gerais sobre o XDM e como ele é usado em Platform, consulte a Visão geral do Sistema XDM.

Noções básicas sobre schemas

Um esquema é um conjunto de regras que representam e validam a estrutura e o formato dos dados. Em um alto nível, os esquemas fornecem uma definição abstrata de um objeto do mundo real (como uma pessoa) e destacam quais dados devem ser incluídos em cada instância desse objeto (como nome, sobrenome, aniversário e assim por diante).

Além de descrever a estrutura dos dados, os schemas aplicam restrições e expectativas aos dados para que possam ser validados conforme se movem entre os sistemas. Essas definições padrão permitem que os dados sejam interpretados de forma consistente, independentemente da origem, e removem a necessidade de tradução entre aplicativos.

Experience Platform O mantém essa normalização semântica usando esquemas. Os esquemas são a maneira padrão de descrever dados em Experience Platform, permitindo que todos os dados que estão em conformidade com os esquemas sejam reutilizados em uma organização sem conflitos ou até compartilhados entre várias organizações.

Os esquemas XDM são ideais para armazenar grandes quantidades de dados complexos em um formato autocontido. Consulte as seções em objetos incorporados e big data no apêndice a este documento para obter mais informações sobre como o XDM consegue isso.

Fluxos de trabalho baseados em esquema em Experience Platform

A normalização é um conceito fundamental por trás de Experience Platform. O XDM, impulsionado pelo Adobe, é um esforço para padronizar os dados de experiência do cliente e definir esquemas padrão para o gerenciamento da experiência do cliente.

A infraestrutura na qual Experience Platform é criado, conhecida como XDM System, facilita workflows baseados em esquema e inclui os Schema Registry, Schema Editor, metadados de esquema e padrões de consumo de serviço. Consulte a Visão geral do sistema XDM para obter mais informações.

Há vários benefícios principais para o aproveitamento de schemas em Experience Platform. Primeiro, os esquemas permitem uma melhor governança de dados e minimização de dados, o que é especialmente importante com as regras de privacidade. Em segundo lugar, a criação de esquemas com componentes padrão do Adobe permite insights prontos e o uso de serviços de AI/ML com personalizações mínimas. Por último, os schemas fornecem infraestrutura para informações de compartilhamento de dados e orquestração eficiente.

Planejamento do esquema

A primeira etapa na criação de um esquema é determinar o conceito, ou objeto real, que você está tentando capturar dentro do esquema. Depois de identificar o conceito que você está tentando descrever, você pode começar a planejar seu esquema pensando em coisas como o tipo de dados, campos de identidade em potencial e como o esquema pode evoluir no futuro.

Comportamentos de dados em Experience Platform

Os dados destinados ao uso em Experience Platform são agrupados em dois tipos de comportamento:

  • Registrar dados: Fornece informações sobre os atributos de um assunto. Um assunto pode ser uma organização ou um indivíduo.
  • Dados das séries cronológicas: Fornece um instantâneo do sistema no momento em que uma ação foi tomada direta ou indiretamente por um titular de registro.

Todos os esquemas XDM descrevem dados que podem ser categorizados como registro ou série de tempo. O comportamento de dados de um schema é definido pela classe do schema, que é atribuída a um schema quando ele é criado pela primeira vez. As classes XDM são descritas mais detalhadamente posteriormente neste documento.

Os esquemas de registro e de série de tempo contêm um mapa de identidades (xdm:identityMap). Este campo contém a representação de identidade de um assunto, extraída de campos marcados como "Identidade", conforme descrito na próxima seção.

Identidade

Os esquemas são usados para assimilar dados em Experience Platform. Esses dados podem ser usados em vários serviços para criar uma única visualização unificada de uma entidade individual. Portanto, é importante pensar em schemas pensar nas identidades do cliente e quais campos podem ser usados para identificar um assunto, independentemente de onde os dados possam vir.

Para ajudar nesse processo, os campos principais em seus esquemas podem ser marcados como identidades. Após a assimilação de dados, os dados nesses campos são inseridos no "Gráfico de identidade" para esse indivíduo. Os dados do gráfico podem ser acessados por Real-time Customer Profile e outros Experience Platform serviços para fornecer uma exibição agrupada de cada cliente individual.

Os campos comumente marcados como "Identity" incluem: endereço de email, número de telefone, Experience Cloud ID (ECID), ID do CRM ou outros campos de ID exclusivos. Você também deve considerar todos os identificadores exclusivos específicos da organização, pois também podem ser bons campos "Identity".

É importante pensar nas identidades do cliente durante a fase de planejamento do schema para ajudar a garantir que os dados estejam sendo reunidos para criar o perfil mais robusto possível. Consulte a visão geral em Adobe Experience Platform Identity Service para saber mais sobre como as informações de identidade podem ajudar você a entregar experiências digitais para seus clientes.

Há duas maneiras de enviar dados de identidade para a Platform:

  1. Adicionar descritores de identidade a campos individuais, por meio da Interface do usuário do Editor de Esquema ou usando a API do Registro de Schema
  2. Uso de um campo identityMap

identityMap

identityMap é um campo do tipo mapa que descreve os vários valores de identidade de um indivíduo, juntamente com seus namespaces associados. Este campo pode ser usado para fornecer informações de identidade para seus esquemas, em vez de definir valores de identidade dentro da estrutura do próprio schema.

A principal desvantagem do uso de identityMap é que as identidades se tornam incorporadas aos dados e, como resultado, se tornam menos visíveis. Se você estiver assimilando dados brutos, deverá definir campos de identidade individuais dentro da estrutura do schema real. Os esquemas que usam identityMap também não podem participar de relacionamentos.

No entanto, os mapas de identidade podem ser particularmente úteis se você estiver trazendo dados de fontes que armazenam identidades juntas (como Airship ou Adobe Audience Manager) ou quando houver um número variável de identidades para um esquema. Além disso, os mapas de identidade são necessários se você estiver usando o Adobe Experience Platform Mobile SDK.

Um exemplo de um mapa de identidade simples seria semelhante ao seguinte:

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": false
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "loyaltyId": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": true
    }
  ]
}

Como mostra o exemplo acima, cada chave no objeto identityMap representa um namespace de identidade. O valor de cada chave é uma matriz de objetos, representando os valores de identidade (id) para o namespace respectivo. Consulte a documentação Identity Service para obter uma lista de namespaces de identidade padrão reconhecida pelos aplicativos Adobe.

OBSERVAÇÃO

Um valor booleano para determinar se o valor é uma identidade primária (primary) também pode ser fornecido para cada valor de identidade. As identidades primárias só precisam ser definidas para esquemas destinados a serem usados em Real-time Customer Profile. Consulte a seção sobre schemas de união para obter mais informações.

Princípios de evolução do schema

Como a natureza das experiências digitais continua a evoluir, também os esquemas usados para representá-las. Um schema bem projetado é, portanto, capaz de se adaptar e evoluir conforme necessário, sem causar alterações destrutivas nas versões anteriores do schema.

Como a manutenção da compatibilidade com versões anteriores é crucial para a evolução do schema, Experience Platform aplica um princípio de controle de versão meramente aditivo. Esse princípio garante que qualquer revisão do schema resulte apenas em atualizações e alterações não destrutivas. Em outras palavras, alterações de quebra não são suportadas.

OBSERVAÇÃO

Se um schema ainda não tiver sido usado para assimilar dados em Experience Platform e não tiver sido ativado para uso no Perfil do cliente em tempo real, você poderá introduzir uma alteração de quebra nesse schema. No entanto, uma vez que o schema tenha sido usado em Platform, ele deverá aderir à política de controle de versão aditiva.

A tabela a seguir detalha quais alterações são compatíveis ao editar esquemas, grupos de campos e tipos de dados:

Alterações suportadas Quebrando alterações (Não suportado)
  • Adicionar novos campos ao recurso
  • Como tornar um campo obrigatório opcional
  • Alteração do nome de exibição e da descrição do recurso
  • Ativar o esquema para participar do perfil
  • Remoção de campos definidos anteriormente
  • Introdução de novos campos obrigatórios
  • Renomeação ou redefinição de campos existentes
  • Remoção ou restrição de valores de campo anteriormente suportados
  • Mover campos existentes para um local diferente na árvore
  • Exclusão do schema
  • Desabilitação do esquema de participar do Perfil

Esquemas e assimilação de dados

Para assimilar dados em Experience Platform, um conjunto de dados deve ser criado primeiro. Os conjuntos de dados são os blocos fundamentais para a transformação e o rastreamento de dados para Catalog Service e geralmente representam tabelas ou arquivos que contêm dados assimilados. Todos os conjuntos de dados são baseados em esquemas XDM existentes, que fornecem restrições para o que os dados assimilados devem conter e como devem ser estruturados. Consulte a visão geral em Ingestão de dados do Adobe Experience Platform para obter mais informações.

Blocos de construção de um schema

Experience Platform O usa uma abordagem de composição na qual os blocos de construção padrão são combinados para criar schemas. Essa abordagem promove a reutilização de componentes existentes e orienta a padronização em todo o setor para suportar esquemas e componentes de fornecedores em Platform.

Os esquemas são compostos usando a seguinte fórmula:

Classe + Grupo de Campos de Esquema * = Esquema XDM

*Um esquema é composto por uma classe e zero ou mais grupos de campos de esquema. Isso significa que é possível compor um esquema de conjunto de dados sem usar grupos de campos.

Classe

A composição de um schema começa pela atribuição de uma classe. As classes definem os aspectos comportamentais dos dados que o schema conterá (registro ou série de tempo). Além disso, as classes descrevem o menor número de propriedades comuns que todos os esquemas baseados nessa classe precisariam incluir e fornecer uma maneira de vários conjuntos de dados compatíveis serem mesclados.

A classe de um esquema determina quais grupos de campos serão qualificados para uso nesse esquema. Isso é discutido com mais detalhes na próxima seção.

O Adobe fornece várias classes XDM padrão ("core"). Duas dessas classes, XDM Individual Profile e XDM ExperienceEvent, são necessárias para quase todos os processos downstream da plataforma. Além dessas classes principais, você também pode criar suas próprias classes personalizadas para descrever casos de uso mais específicos da sua organização. As classes personalizadas são definidas por uma organização quando não há classes principais definidas por Adobe disponíveis para descrever um caso de uso exclusivo.

A captura de tela a seguir demonstra como as classes são representadas na interface do usuário da plataforma. Como o schema de exemplo mostrado não contém nenhum grupo de campos, todos os campos exibidos são fornecidos pela classe do schema (Perfil Individual XDM).

Para obter a lista mais atualizada das classes XDM padrão disponíveis, consulte o repositório XDM oficial. Como alternativa, consulte o guia em explorar componentes XDM se preferir exibir recursos na interface do usuário.

Grupo de campos

Um grupo de campos é um componente reutilizável que define um ou mais campos que implementam determinadas funções, como detalhes pessoais, preferências de hotel ou endereço. Os grupos de campos devem ser incluídos como parte de um schema que implementa uma classe compatível.

Os grupos de campos definem a(s) classe(s) com a qual são compatíveis, com base no comportamento dos dados que representam (registro ou série de tempo). Isso significa que nem todos os grupos de campos estão disponíveis para uso com todas as classes.

Experience Platform O inclui muitos grupos de campos Adobe padrão, além de permitir que os fornecedores definam grupos de campos para seus usuários e usuários individuais definam grupos de campos para seus próprios conceitos específicos.

Por exemplo, para capturar detalhes como "First Name" e "Home Address" para o esquema "Loyalty Members", você poderá usar grupos de campos padrão que definem esses conceitos comuns. No entanto, os conceitos específicos para casos de uso menos comuns (como "Nível do Programa de Fidelidade") geralmente não têm um grupo de campo predefinido. Nesse caso, você deve definir seu próprio grupo de campos para capturar essas informações.

OBSERVAÇÃO

É altamente recomendável usar grupos de campos padrão sempre que possível em seus esquemas, já que esses campos são entendidos implicitamente pelos serviços Experience Platform e fornecem maior consistência quando usados em Platform componentes.

Os campos fornecidos pelos componentes padrão (como "Nome" e "Endereço de email") contêm conotações adicionais além dos tipos básicos de campos escalares, informando Platform que quaisquer campos que compartilhem o mesmo tipo de dados se comportarão da mesma maneira. Esse comportamento pode ser confiável para ser consistente, independentemente de onde os dados vêm ou em que serviço Platform os dados estão sendo usados.

Lembre-se de que os esquemas são compostos de grupos de campos "zero ou mais", portanto, isso significa que você pode compor um schema válido sem usar nenhum grupo de campos.

A captura de tela a seguir demonstra como os grupos de campo são representados na interface do usuário da plataforma. Um único grupo de campos (Demographic Details) é adicionado a um schema neste exemplo, que fornece um agrupamento de campos para a estrutura do schema.

Para obter a lista mais atualizada de grupos de campos XDM padrão disponíveis, consulte o repositório XDM oficial. Como alternativa, consulte o guia em explorar componentes XDM se preferir exibir recursos na interface do usuário.

Tipo de dados

Os tipos de dados são usados como tipos de campo de referência em classes ou esquemas, da mesma forma que os campos literais básicos. A principal diferença é que os tipos de dados podem definir vários subcampos. Semelhante a um grupo de campos, um tipo de dados permite o uso consistente de uma estrutura de vários campos, mas tem mais flexibilidade do que um grupo de campos, pois um tipo de dados pode ser incluído em qualquer lugar de um esquema ao adicioná-lo como o "tipo de dados" de um campo.

Experience Platform O fornece vários tipos de dados comuns como parte do Schema Registry para suportar o uso de padrões padrão para descrever estruturas de dados comuns. Isso é explicado com mais detalhes nos tutoriais Schema Registry, onde ficará mais claro à medida que você percorre as etapas para definir tipos de dados.

A captura de tela a seguir demonstra como os tipos de dados são representados na interface do usuário da plataforma. Um dos campos fornecidos pelo grupo de campos Detalhes Demográficos usa o tipo de dados "Nome da pessoa", conforme indicado pelo texto após o caractere de barra vertical (|) ao lado do nome do campo. Esse tipo de dados específico fornece vários subcampos relacionados ao nome de uma pessoa individual, uma construção que pode ser reutilizada para outros campos onde o nome de uma pessoa precisa ser capturado.

Para obter a lista mais atualizada dos tipos de dados XDM padrão disponíveis, consulte o repositório XDM oficial. Como alternativa, consulte o guia em explorar componentes XDM se preferir exibir recursos na interface do usuário.

Campo

Um campo é o bloco de construção mais básico de um schema. Os campos fornecem restrições sobre o tipo de dados que podem conter, definindo um tipo de dados específico. Esses tipos de dados básicos definem um único campo, enquanto os data types mencionados anteriormente permitem definir vários subcampos e reutilizar a mesma estrutura de vários campos em vários schemas. Assim, além de definir um "tipo de dados" de campo como um dos tipos de dados definidos no Registro, Experience Platform suporta tipos escalares básicos como:

  • String
  • Número inteiro
  • Duplo
  • Booleano
  • Matriz
  • Objeto
DICA

Consulte o apêndice para obter informações sobre os prós e contras do uso de campos de forma livre em campos de tipo de objeto.

Os intervalos válidos desses tipos escalares podem ser restritos ainda mais a determinados padrões, formatos, mínimos/máximos ou valores predefinidos. Com essas restrições, uma grande variedade de tipos de campos mais específicos pode ser representada, incluindo:

  • Enum
  • Longo
  • Curto
  • Byte
  • Data
  • Data e hora
  • Mapa
OBSERVAÇÃO

O tipo de campo "mapear" permite dados de pares de valores chave, incluindo vários valores para uma única chave. Os mapas só podem ser definidos no nível do sistema, o que significa que você pode encontrar um mapa em um esquema definido pelo setor ou pelo fornecedor, mas não estão disponíveis para uso nos campos definidos. O Guia do desenvolvedor da API de Registro de Schema contém mais informações sobre a definição de tipos de campos.

Exemplo de composição

Os esquemas representam o formato e a estrutura dos dados que serão assimilados em Platform e são criados usando um modelo de composição. Como mencionado anteriormente, esses esquemas são compostos de uma classe e zero ou mais grupos de campos compatíveis com essa classe.

Por exemplo, um esquema que descreve compras feitas em uma loja de varejo pode ser chamado de "Transações da loja". O schema implementa a classe XDM ExperienceEvent combinada com o grupo de campos padrão Commerce e um grupo de campos Informações do produto definido pelo usuário.

Outro esquema que rastreia o tráfego do site pode ser chamado de "Web Visits". Ela também implementa a classe XDM ExperienceEvent, mas desta vez combina o grupo de campos padrão Web.

O diagrama abaixo mostra esses esquemas e os campos contribuídos por cada grupo de campos. Ele também contém dois schemas com base na classe XDM Individual Profile, incluindo o schema "Loyalty Members" mencionado anteriormente neste guia.

União

Embora Experience Platform permita compor esquemas para casos de uso específicos, também permite ver uma "união" de esquemas para um tipo de classe específico. O diagrama anterior mostra dois esquemas com base na classe XDM ExperienceEvent e dois esquemas com base na classe XDM Individual Profile. A união, mostrada abaixo, agrega os campos de todos os schemas que compartilham a mesma classe (XDM ExperienceEvent e XDM Individual Profile, respectivamente).

Ao ativar um schema para uso com Real-time Customer Profile, ele será incluído na união para esse tipo de classe. Profile O oferece perfis robustos e centralizados de atributos do cliente, bem como uma conta com carimbos de data e hora de cada evento que o cliente teve em qualquer sistema integrado com o Platform. Profile O usa a exibição de união para representar esses dados e fornecer uma visão holística de cada cliente individual.

Para obter mais informações sobre como trabalhar com Profile, consulte a Visão geral do Perfil do cliente em tempo real.

Mapeamento de arquivos de dados para esquemas XDM

Todos os arquivos de dados assimilados em Experience Platform devem estar em conformidade com a estrutura de um esquema XDM. Para obter mais informações sobre como formatar arquivos de dados para estar em conformidade com hierarquias XDM (incluindo arquivos de amostra), consulte o documento em amostras de transformações ETL. Para obter informações gerais sobre como assimilar arquivos de dados em Experience Platform, consulte a visão geral da assimilação de lote.

Esquemas para segmentos externos

Se você estiver trazendo segmentos de sistemas externos para o Platform, deverá usar os seguintes componentes para capturá-los em seus esquemas:

Próximas etapas

Agora que você entende as noções básicas da composição do schema, está pronto para começar a explorar e criar schemas usando o Schema Registry.

Para analisar a estrutura das duas classes principais XDM e seus grupos de campos compatíveis comumente usados, consulte a seguinte documentação de referência:

O Schema Registry é usado para acessar o Schema Library no Adobe Experience Platform e fornece uma interface de usuário e a API RESTful a partir da qual todos os recursos de biblioteca disponíveis são acessíveis. O Schema Library contém recursos do Setor definidos pelo Adobe, recursos do Fornecedor definidos pelos Experience Platform parceiros e classes, grupos de campos, tipos de dados e esquemas que foram compostos por membros de sua organização.

Para começar a compor o schema usando a interface do usuário, siga o Tutorial do Editor de Esquema para criar o schema "Membros de Fidelidade" mencionado em todo este documento.

Para começar a usar a API Schema Registry, leia o Guia do desenvolvedor da API do Registro de Schema. Depois de ler o guia do desenvolvedor, siga as etapas descritas no tutorial em criar um schema usando a API do Registro de Schema.

Apêndice

As seções a seguir contêm informações adicionais sobre os princípios da composição do schema.

Tabelas relacionais versus objetos incorporados

Ao trabalhar com bancos de dados relacionais, as práticas recomendadas envolvem a normalização de dados ou a divisão de uma entidade em partes discretas que são exibidas em várias tabelas. Para ler os dados como um todo ou atualizar a entidade, as operações de leitura e gravação devem ser realizadas em várias tabelas individuais usando JOIN.

Por meio do uso de objetos incorporados, os esquemas XDM podem representar diretamente dados complexos e armazená-los em documentos autônomos com uma estrutura hierárquica. Um dos principais benefícios dessa estrutura é que ela permite consultar os dados sem precisar reconstruir a entidade por associações caras a várias tabelas desnormalizadas. Não há restrições rígidas para quantos níveis sua hierarquia de esquema pode ter.

Esquemas e grandes dados

Sistemas digitais modernos geram grandes quantidades de sinais comportamentais (dados de transação, logs da Web, internet de coisas, exibição e assim por diante). Esses grandes dados oferecem oportunidades extraordinárias para otimizar experiências, mas são desafiadores a usá-las devido à escala e variedade dos dados. Para obter valor dos dados, a sua estrutura, formato e definições devem ser padronizados de modo a que possam ser processados de forma consistente e eficiente.

Os esquemas solucionam esse problema ao permitir que os dados sejam integrados de várias fontes, padronizados por meio de estruturas e definições comuns e compartilhados entre soluções. Isso permite que processos e serviços subsequentes respondam a qualquer tipo de pergunta que esteja sendo feita sobre os dados, afastando-se da abordagem tradicional à modelagem de dados, onde todas as perguntas que serão feitas sobre os dados são conhecidas antecipadamente e os dados são modelados de forma a estarem em conformidade com essas expectativas.

Objetos versus campos de forma livre

Há alguns fatores principais a serem considerados ao escolher objetos em vez de campos de forma livre ao projetar seus esquemas:

Objetos Campos de forma livre
Aumenta o aninhamento Menos ou sem aninhamento
Cria agrupamentos de campos lógicos Os campos são colocados em locais ad hoc

Objetos

Os prós e contras do uso de objetos em campos de forma livre estão listados abaixo.

Vantagens:

  • Os objetos são melhor usados quando você deseja criar um agrupamento lógico de determinados campos.
  • Os objetos organizam o schema de maneira mais estruturada.
  • Os objetos ajudam indiretamente na criação de uma boa estrutura de menu na interface do usuário do Construtor de segmentos. Os campos agrupados no schema são refletidos diretamente na estrutura de pastas fornecida na interface do usuário do Construtor de segmentos.

Desvantagens:

Campos de forma livre

Os prós e contras do uso de campos de forma livre em objetos estão listados abaixo.

Vantagens:

  • Campos de forma livre são criados diretamente no objeto raiz do esquema (_tenantId), aumentando a visibilidade.
  • As sequências de referência para campos de forma livre tendem a ser mais curtas ao usar o Serviço de query.

Desvantagens:

  • O local dos campos de forma livre no esquema é ad hoc, o que significa que eles aparecem em ordem alfabética no Editor de esquemas. Isso pode tornar os esquemas menos estruturados e campos de forma livre semelhantes podem acabar sendo muito separados, dependendo de seus nomes.

Nesta página