Práticas recomendadas para modelagem de dados

Experience Data Model O (XDM) é a estrutura principal que padroniza os dados de experiência do cliente fornecendo estruturas e definições comuns para uso nos serviços downstream da Adobe Experience Platform. Seguindo os padrões XDM, todos os dados de experiência do cliente podem ser incorporados a uma representação comum que permite obter insights valiosos das ações do cliente, definir públicos-alvo do cliente e expressar atributos do cliente para fins de personalização.

Como o XDM é extremamente versátil e personalizável por design, é importante seguir as práticas recomendadas para a modelagem de dados ao projetar seus esquemas. Este documento aborda as principais decisões e considerações que você deve tomar ao mapear os dados de experiência do cliente para o XDM.

Introdução

Antes de ler este guia, consulte o Visão geral do sistema XDM para obter uma introdução de alto nível ao XDM e sua função no Experience Platform.

Além disso, este guia se concentra exclusivamente nas principais considerações relacionadas ao design do esquema. Portanto, é altamente recomendável que você consulte a noções básicas da composição do esquema para obter explicações detalhadas dos elementos individuais do schema mencionados neste guia.

Resumo de práticas recomendadas

A abordagem recomendada para projetar seu modelo de dados para uso no Experience Platform pode ser resumida da seguinte maneira:

1. Entenda os casos de uso de negócios para seus dados.
2. Identificar as fontes de dados primárias que devem ser trazidas para Platform para lidar com esses casos de uso.
3. Identifique quaisquer fontes de dados secundárias que também possam ser de interesse. Por exemplo, se atualmente apenas uma unidade de negócios em sua organização estiver interessada em portar seus dados para o PlatformNo entanto, uma unidade de negócios semelhante também pode estar interessada em portar dados semelhantes no futuro. Considerar essas fontes secundárias ajuda a padronizar o modelo de dados em toda a organização.
4. Crie um diagrama de relacionamento de entidade de alto nível (ERD) para as fontes de dados que foram identificadas.
5. Converter o ERD de alto nível em um PlatformERD centrado em (incluindo perfis, eventos de experiência e entidades de pesquisa).

As etapas relacionadas à identificação das fontes de dados aplicáveis necessárias para realizar os casos de uso de negócios variam de uma organização para outra. Embora o restante das seções neste documento se concentre nas últimas etapas de organização e construção de um ERD após a identificação das fontes de dados, as explicações dos vários componentes do diagrama podem informar suas decisões sobre para quais fontes de dados devem ser migradas Platform.

Criar um ERD de alto nível

Depois de determinar as fontes de dados que deseja trazer para o Platform, crie um ERD de alto nível para ajudar a orientar o processo de mapeamento de seus dados para esquemas XDM.

O exemplo abaixo representa um ERD simplificado para uma empresa que deseja trazer dados para o Platform. O diagrama destaca as entidades essenciais que devem ser classificadas em classes XDM, incluindo contas de clientes, hotéis, endereços e vários eventos comuns de comércio eletrônico.

Classificar entidades em categorias de perfil, pesquisa e evento

Depois de criar um ERD para identificar as entidades essenciais que você gostaria de trazer para Platform, essas entidades devem ser classificadas em categorias de perfil, pesquisa e evento:

Considerações para classificação de entidade

As seções abaixo fornecem mais orientação sobre como classificar as entidades nas categorias acima.

Dados mutáveis e imutáveis

Uma maneira primária de classificar entre categorias de entidade é se os dados capturados são mutáveis ou não.

Os atributos pertencentes a perfis ou entidades de pesquisa normalmente são mutáveis. Por exemplo, as preferências de um cliente podem mudar com o tempo e os parâmetros de um plano de assinatura podem ser atualizados, dependendo das tendências do mercado.

Por outro lado, os dados do evento normalmente são imutáveis. Como os eventos são anexados a um carimbo de data e hora específico, o "instantâneo do sistema" fornecido por um evento não é alterado. Por exemplo, um evento pode capturar as preferências de um cliente ao finalizar a compra de um carrinho e não é alterado mesmo que as preferências do cliente acabem sendo alteradas posteriormente. Os dados do evento não podem ser alterados após serem registrados.

Em resumo, perfis e entidades de pesquisa contêm atributos mutáveis e representam as informações mais atuais sobre os assuntos capturados, enquanto eventos são registros imutáveis do sistema em um momento específico.

Atributos do cliente

Se uma entidade contiver atributos relacionados a um cliente individual, ela provavelmente será uma entidade de perfil. Exemplos de atributos do cliente incluem:

• Detalhes pessoais, como nome, data de nascimento, sexo e ID(s) da conta.
• Informações de localização, como endereços e informações de GPS.
• Informações de contato, como números de telefone e endereços de email.

Rastreamento de dados ao longo do tempo

Se você quiser analisar como determinados atributos em uma entidade mudam ao longo do tempo, ela provavelmente será uma entidade de evento. Por exemplo, a adição de itens de produto a um carrinho pode ser rastreada como eventos de adição ao carrinho em Platform:

Casos de uso de segmentação

Ao categorizar suas entidades, é importante pensar nos públicos que você pode querer criar para atender aos casos de uso específicos da empresa.

Por exemplo, uma empresa quer conhecer todos os membros "Ouro" ou "Platina" de seu programa de fidelidade que fizeram mais de cinco compras no ano passado. Com base nesta lógica de segmentação, podem ser tiradas as seguintes conclusões sobre a forma como as entidades relevantes devem ser representadas:

• "Ouro" e "Platina" representam status de fidelidade aplicáveis a um cliente individual. Como a lógica de segmentação só se preocupa com o status de fidelidade atual dos clientes, esses dados podem ser modelados como parte de um esquema de perfil. Se você quiser rastrear as alterações no status de fidelidade ao longo do tempo, também poderá criar um esquema de evento adicional para as alterações no status de fidelidade.
• Compras são eventos que ocorrem em um momento específico e a lógica de segmentação se refere a eventos de compra em uma janela de tempo especificada. Portanto, esses dados devem ser modelados como um schema de evento.

Casos de uso de ativação

Além de considerações relacionadas aos casos de uso de segmentação, você também deve revisar os casos de uso de ativação para esses públicos-alvo para identificar atributos relevantes adicionais.

Por exemplo, uma empresa criou um público-alvo com base na regra que country = US. Em seguida, ao ativar esse público-alvo para determinados destinos downstream, a empresa deseja filtrar todos os perfis exportados com base no estado inicial. Por conseguinte, uma state O atributo também deve ser capturado na entidade de perfil aplicável.

Valores agregados

Com base no caso de uso e na granularidade dos dados, você deve decidir se determinados valores precisam ser pré-agregados antes de serem incluídos em um perfil ou entidade de evento.

Por exemplo, uma empresa deseja criar um público-alvo com base no número de compras de carrinho. Você pode optar por incorporar esses dados na menor granularidade ao incluir cada evento de compra com carimbo de data e hora como sua própria entidade. No entanto, às vezes isso pode aumentar o número de eventos registrados exponencialmente. Para reduzir o número de eventos assimilados, é possível optar por criar um valor agregado numberOfPurchases durante um período de uma semana ou de um mês. Outras funções agregadas, como MIN e MAX, também podem ser aplicadas a essas situações.

Cardinalidade

As cardinalidades estabelecidas no seu ERD também podem fornecer algumas pistas sobre como categorizar suas entidades. Se houver uma relação um para muitos entre duas entidades, a entidade que representa o "muitos" provavelmente será uma entidade de evento. No entanto, também há casos em que "muitos" é um conjunto de entidades de pesquisa que são fornecidas como uma matriz em uma entidade de perfil.

A tabela a seguir descreve alguns relacionamentos de entidade comuns e as categorias que podem ser derivadas deles:

Vantagens e desvantagens de diferentes classes de entidade

Embora a seção anterior tenha fornecido algumas diretrizes gerais para decidir como categorizar suas entidades, é importante entender que geralmente pode haver vantagens e desvantagens em escolher uma categoria de entidade em vez de outra. O estudo de caso a seguir ilustra como você pode considerar suas opções nessas situações.

Uma empresa rastreia assinaturas ativas para seus clientes, onde um cliente pode ter muitas assinaturas. A empresa também deseja incluir assinaturas para casos de uso de segmentação, como encontrar todos os usuários com assinaturas ativas.

Nesse cenário, a empresa tem duas opções possíveis para representar as assinaturas de um cliente em seu modelo de dados:

1. Usar atributos de perfil
2. Usar entidades de evento

Abordagem 1: usar atributos de perfil

A primeira abordagem seria incluir uma matriz de assinaturas como atributos na entidade de perfil para Clientes. Os objetos nesta matriz conteriam campos para category, status, planName, startDate, e endDate.

Pontos positivos

• A segmentação é viável para o caso de uso pretendido.
• O esquema só preservará os registros de assinatura mais recentes de um cliente.

Pontos negativos

• A matriz inteira deve ser reiterada sempre que ocorrerem alterações em qualquer campo na matriz.
• Se diferentes fontes de dados ou unidades de negócios estiverem alimentando dados no storage, será desafiador manter o storage atualizado mais recente sincronizado em todos os canais.

Abordagem 2: usar entidades de evento

A segunda abordagem seria usar schemas de evento para representar assinaturas. Isso envolve a assimilação dos mesmos campos de subscrição que a primeira abordagem, com a adição de uma ID de subscrição, uma ID de cliente e um carimbo de data e hora de quando o evento de subscrição ocorreu.

Pontos positivos

• As regras de segmentação podem ser mais flexíveis (como encontrar todos os clientes que alteraram suas assinaturas nos últimos 30 dias).
• Quando o status da assinatura de um cliente muda, você não precisa mais atualizar um array longo e potencialmente complexo nos atributos do perfil do cliente. Isso é especialmente útil se ocorrerem alterações simultâneas na lista de assinaturas do cliente a partir de várias fontes.

Pontos negativos

• A segmentação se torna mais complexa para o caso de uso pretendido original (identificando o status das assinaturas mais recentes dos clientes). O público-alvo agora precisa de lógica adicional para sinalizar o último evento de assinatura para um cliente para verificar seu status.
• Os eventos têm um risco maior de expiração automática e de serem removidos da loja de perfis. Consulte o guia sobre Expirações do evento de experiência para obter mais informações.

Criar esquemas com base nas entidades categorizadas

Depois de classificar as entidades em perfis, pesquisas e categorias de eventos, você pode começar a converter o modelo de dados em esquemas XDM. Para fins de demonstração, o modelo de dados de exemplo mostrado anteriormente foi classificado em categorias apropriadas no diagrama a seguir:

A categoria em que uma entidade foi classificada deve determinar a classe XDM na qual você baseia seu esquema. Para reiterar:

• As entidades de perfil devem usar o XDM Individual Profile classe.
• As entidades de evento devem usar o XDM ExperienceEvent classe.
• As entidades de pesquisa devem usar classes XDM personalizadas definidas por sua organização. As entidades de perfil e evento podem fazer referência a essas entidades de pesquisa por meio de relacionamentos de esquema.

As seções abaixo fornecem orientações gerais sobre a construção de esquemas com base no seu ERD.

Adotar uma abordagem de modelagem iterativa

A variável regras de evolução do schema determinam que somente as alterações não destrutivas possam ser feitas nos schemas depois de implementadas. Em outras palavras, depois que você adiciona um campo a um esquema e os dados são assimilados nesse campo, o campo não pode mais ser removido. Portanto, é essencial adotar uma abordagem de modelagem iterativa ao criar seus esquemas pela primeira vez, começando com uma implementação simplificada que ganha progressivamente complexidade ao longo do tempo.

Se você não tiver certeza se um campo específico é necessário incluir em um esquema, a prática recomendada é deixá-lo de fora. Se posteriormente for determinado que o campo é necessário, ele sempre poderá ser adicionado na próxima iteração do schema.

Campos de identidade

No Experience Platform, os campos XDM marcados como identidades são usados para unir informações sobre clientes individuais provenientes de várias fontes de dados. Embora um esquema possa ter vários campos marcados como identidades, uma única identidade principal deve ser definida para que o esquema seja ativado para uso no Real-Time Customer Profile. Consulte a seção sobre campos de identidade em basics of schema composition para obter informações mais detalhadas sobre o caso de uso desses campos.

Ao criar seus esquemas, todas as chaves primárias nas tabelas do banco de dados relacional provavelmente serão candidatas a identidades primárias. Outros exemplos de campos de identidade aplicáveis são endereços de email de clientes, números de telefone, IDs de conta e ECID.

Grupos de campos de esquema do aplicativo Adobe

O Experience Platform fornece vários grupos de campos de esquema XDM prontos para uso para capturar dados relacionados aos seguintes aplicativos Adobe:

• Adobe Analytics
• Adobe Audience Manager
• Adobe Campaign
• Adobe Target

Por exemplo, a variável Modelo de evento de experiência do Adobe Analytics grupo de campos permite mapear AnalyticsCampos específicos do para seus esquemas XDM. Dependendo dos aplicativos de Adobe com os quais você está trabalhando, você deve usar esses grupos de campos fornecidos por Adobe em seus esquemas.

Os grupos de campos de aplicativos Adobe atribuem automaticamente uma identidade principal padrão por meio do uso do identityMap campo, que é um objeto somente leitura gerado pelo sistema que mapeia valores de identidade padrão para um cliente individual.

Para o Adobe Analytics, a ECID é a identidade principal padrão. Se um valor de ECID não for fornecido por um cliente, a identidade principal assumirá AAID como padrão.

Campos de validação de dados

Para evitar que dados incorretos sejam assimilados na Platform, é recomendável definir os critérios de validação em nível de campo ao criar seus esquemas. Para definir restrições em um campo específico, selecione o campo no Editor de esquemas para abrir a variável Propriedades do campo barra lateral. Consulte a documentação em propriedades do campo específico do tipo para obter descrições exatas dos campos disponíveis.

Próximas etapas

Esse documento abordou as diretrizes gerais e as práticas recomendadas para a criação do modelo de dados para o Experience Platform. Para resumir:

• Use uma abordagem de cima para baixo classificando suas tabelas de dados em categorias de perfil, pesquisa e evento antes de construir seus esquemas.
• Geralmente, há várias abordagens e opções quando se trata de projetar esquemas para diferentes propósitos.
• Seu modelo de dados deve oferecer suporte aos casos de uso da empresa, como segmentação ou análise de jornada do cliente.
• Torne seus esquemas o mais simples possível e adicione novos campos somente quando absolutamente necessário.

Quando estiver pronto, consulte o tutorial em criação de um esquema na interface para obter instruções passo a passo sobre como criar um esquema, atribua a classe apropriada à entidade e adicione campos para mapear seus dados.