Este documento descreve as principais recomendações ao projetar o modelo de dados do Adobe Campaign.
Para obter uma melhor compreensão das tabelas integradas do Campaign e sua interação, consulte nesta seção seção.
Ler esta documentação para começar a usar esquemas do Campaign. Saiba como configurar esquemas de extensão para estender o modelo de dados conceituais do banco de dados do Adobe Campaign no este documento.
O sistema Adobe Campaign é extremamente flexível e pode ser estendido além da implementação inicial. No entanto, embora as possibilidades sejam infinitas, é essencial tomar decisões sábias e criar bases sólidas para começar a projetar seu modelo de dados.
Este documento fornece casos de uso comuns e práticas recomendadas para saber como arquitetar corretamente sua ferramenta Adobe Campaign.
O Adobe Campaign é um eficiente sistema de gerenciamento de campanhas em vários canais que pode ajudar você a alinhar suas estratégias online e offline para criar experiências personalizadas de clientes.
Embora a maioria dos provedores de serviços de email esteja se comunicando com os clientes por meio de uma abordagem centrada em listas, o Adobe Campaign depende de um banco de dados relacional para aproveitar uma visualização mais ampla dos clientes e seus atributos.
Essa abordagem centrada no cliente é mostrada no gráfico abaixo. A variável Recipient A tabela em cinza representa a principal tabela do cliente em torno da qual tudo está sendo criado:
Para acessar a descrição de cada tabela, vá para Admin > Configuration > Data schemas, selecione um recurso na lista e clique no botão Documentation guia.
O modelo de dados padrão do Adobe Campaign é apresentado em este documento.
O Adobe Campaign Classic permite criar uma tabela de cliente personalizada. No entanto, na maioria dos casos, é recomendável aproveitar o padrão Tabela de destinatários que já tem tabelas e recursos adicionais pré-criados.
Quais dados devem ser enviados para o Adobe Campaign? É essencial determinar os dados necessários para suas atividades de marketing.
O Adobe Campaign não é um data warehouse nem uma ferramenta de relatórios. Portanto, não tente importar todos os clientes possíveis e suas informações associadas para o Adobe Campaign, ou importe dados que serão usados apenas para criar relatórios.
Para decidir se um atributo seria necessário ou não no Adobe Campaign, pergunte se ele se enquadra em uma destas categorias:
Se não estiver se encaixando em nenhum desses, você provavelmente não precisará desse atributo no Adobe Campaign.
Para garantir uma boa arquitetura e desempenho do sistema, siga as práticas recomendadas abaixo para configurar dados no Adobe Campaign.
Um campo deve ser armazenado em uma tabela se tiver um propósito de direcionamento ou personalização. Em outras palavras, se um campo não é usado para enviar um email personalizado ou usado como critério em um query, ele ocupa espaço em disco, enquanto é inútil.
Para instâncias híbridas e no local, o FDA (Federated Data Access, um recurso opcional que permite acessar dados externos) aborda a necessidade de adicionar um campo "instantaneamente" durante um processo de campanha. Não é necessário importar tudo se você tiver o FDA. Para obter mais informações, consulte Sobre o Federated Data Access.
Além do autopk definida por padrão na maioria das tabelas, você deve considerar adicionar algumas chaves lógicas ou de negócios (número da conta, número do cliente e assim por diante). Ele pode ser usado posteriormente para importações/reconciliação ou pacotes de dados. Para obter mais informações, consulte Identificadores.
Chaves eficientes são essenciais para o desempenho. Os tipos de dados numéricos devem sempre ser preferidos como chaves para tabelas.
Para o banco de dados do SQLServer, você pode considerar o uso de "índice clusterizado" se o desempenho for necessário. Como o Adobe não lida com isso, é necessário criá-lo em SQL.
O atributo de tablespace no esquema permite especificar um tablespace dedicado para uma tabela.
O assistente de instalação permite armazenar objetos por tipo (dados, temporário e índice).
Os tablespaces dedicados são melhores para particionamento, regras de segurança e permitem administração fluida e flexível, melhor otimização e desempenho.
Os recursos do Adobe Campaign têm três identificadores e é possível adicionar um identificador adicional.
A tabela a seguir descreve esses identificadores e sua finalidade.
Identifier | Descrição | Práticas recomendadas |
---|---|---|
ID |
|
|
Nome (ou nome interno) |
|
|
Rótulo |
|
|
As chaves primárias são necessárias para cada tabela criada no Adobe Campaign.
A maioria das organizações está importando registros de sistemas externos. Embora a chave física da tabela Recipient seja o atributo "id", é possível determinar uma chave personalizada além disso.
Essa chave personalizada é a chave primária de registro real no sistema externo que alimenta o Adobe Campaign.
Quando uma tabela pronta para uso tiver uma chave automática e uma chave interna, a chave interna será definida como um índice exclusivo na tabela do banco de dados física.
Ao criar uma tabela personalizada, você tem duas opções:
Um autopk não deve ser usado como referência em fluxos de trabalho.
A chave primária do Adobe Campaign é uma ID gerada automaticamente para todas as tabelas predefinidas e pode ser a mesma para tabelas personalizadas. Para obter mais informações, consulte esta seção.
Esse valor é obtido do que é chamado de sequência, que é um objeto de banco de dados usado para gerar uma sequência numérica.
Há dois tipos de sequências:
A sequência é um valor inteiro de 32 bits, com um número máximo finito de valores disponíveis: 2,14 bilhões. Depois de atingir o valor máximo, a sequência volta para 0, para reciclar ids.
Se os dados antigos não tiverem sido removidos, o resultado será uma violação de chave exclusiva, que se torna um bloqueador para a integridade e o uso da plataforma. O Adobe Campaign não poderia enviar comunicações (quando isso afeta a tabela de logs do delivery) e o desempenho seria altamente afetado.
Portanto, um cliente que enviasse 6 bilhões de emails anualmente com um período de retenção de 180 dias para seus registros ficaria sem ids em quatro meses. Para evitar esse desafio, certifique-se de ter configurações de limpeza de acordo com seus volumes. Para obter mais informações, consulte esta seção.
Quando uma tabela personalizada está sendo criada no Adobe Campaign com uma chave primária como um autoPK, uma sequência dedicada personalizada deve ser sistematicamente associada a essa tabela.
Por padrão, uma sequência personalizada terá valores que variam de +1.000 a +2,1BB. Tecnicamente, é possível obter uma gama completa de 4BB habilitando ids negativas. Isso deve ser usado com cuidado e uma ID será perdida ao passar de números negativos para positivos: o registro 0 normalmente é ignorado pelo Adobe Campaign em consultas SQL geradas.
Para saber mais sobre a exaustão das sequências, assista este vídeo.
Os índices são essenciais para o desempenho. Quando você declarar uma chave no esquema, o Adobe criará automaticamente um índice nos campos da chave. Você também pode declarar mais índices para consultas que não usam a chave.
A Adobe recomenda definir índices adicionais, pois pode melhorar o desempenho.
No entanto, lembre-se do seguinte:
O gerenciamento de índices pode se tornar muito complexo, portanto, é importante entender como eles funcionam. Para ilustrar essa complexidade, vamos ver um exemplo básico, como pesquisar destinatários filtrando o nome e o sobrenome. Para fazer isso:
Vá para a pasta que lista todos os destinatários no banco de dados. Para obter mais informações, consulte Gerenciamento de perfis.
Clique com o botão direito do mouse no First name campo.
Selecione Filter on this field.
Repita essa operação para o Last name campo.
Os dois filtros correspondentes são adicionados na parte superior da tela.
Agora você pode executar a filtragem de pesquisa no First name e Last name de acordo com as várias condições de filtro.
Agora, para acelerar a pesquisa nesses filtros, é possível adicionar índices. Mas quais índices devem ser usados?
Este exemplo se aplica a clientes hospedados que usam um banco de dados PostgreSQL.
A tabela a seguir mostra em quais casos os três índices descritos abaixo são usados ou não, de acordo com o padrão de acesso exibido na primeira coluna.
Critérios de pesquisa | Índice 1 (Nome + Sobrenome) | Índice 2 (apenas nome) | Índice 3 (somente sobrenome) | Comentários |
---|---|---|---|---|
Nome igual a "Johnny" | Usado | Usado | Não usado | Como o nome está na primeira posição no índice 1, ele será usado mesmo assim: não há necessidade de adicionar um critério sobre o sobrenome. |
O nome é igual a "Johnny" E o sobrenome é igual a "Smith" | Usado | Não usado | Não usado | Como ambos os atributos são pesquisados na mesma consulta, somente o índice que combina ambos os atributos será usado. |
O sobrenome é igual a "Smith" | Não usado | Não usado | Usado | A ordem dos atributos no índice é levada em conta. Se você não corresponder a essa ordem, o índice pode não ser usado. |
O nome começa com "João" | Usado | Usado | Não usado | "Pesquisa à esquerda" habilitará os índices. |
O nome termina com "nny" | Não usado | Não usado | Não usado | "Pesquisa direta" desativará os índices e uma verificação completa será executada. Alguns tipos de índice específicos podem lidar com esse caso de uso, mas não estão disponíveis por padrão no Adobe Campaign. |
O nome contém "John" | Não usado | Não usado | Não usado | É uma combinação de pesquisas "esquerda" e "direita". Por causa deste último, ele desativará os índices e uma verificação completa será executada. |
O nome é igual a "john" | Não usado | Não usado | Não usado | Os índices fazem distinção entre maiúsculas e minúsculas. Para não diferenciar maiúsculas de minúsculas, você deve criar um índice específico que inclua uma função SQL como "upper(firstname)". Você deve fazer o mesmo com outras transformações de dados, como "unaccent(firstname)". |
Cuidado com a integridade "própria" em tabelas grandes. A exclusão de registros que têm tabelas amplas em "própria" integridade pode interromper a instância. A tabela é bloqueada e as exclusões são feitas uma por uma. Portanto, é melhor usar a integridade "neutra" em tabelas secundárias com grandes volumes.
Declarar um link como uma associação externa não é bom para o desempenho. O registro de id zero emula a funcionalidade de associação externa. Não é necessário declarar junções externas se o link usar o autopk.
Embora seja possível unir qualquer tabela em um fluxo de trabalho, o Adobe recomenda definir links comuns entre os recursos diretamente na definição da estrutura de dados.
O link deve ser definido em alinhamento com os dados reais nas tabelas. Uma definição incorreta poderia afetar os dados recuperados por meio de links, por exemplo, registros duplicados inesperadamente.
Nomeie o link de forma consistente com o nome da tabela: o nome do link deve ajudar a entender o que é a tabela distante.
Não nomeie um link com "id" como sufixo. Por exemplo, nomeie-o como "transaction" em vez de "transactionId".
Por padrão, o Adobe Campaign criará um link usando a chave primária da tabela externa. Para maior clareza, é preferível definir explicitamente a associação na definição do link.
Um índice será adicionado aos atributos usados em um link.
Os links criado por e modificado por último estão presentes em muitas tabelas. É possível desativar o índice usando o atributo noDbIndex no link, se essas informações não estiverem sendo usadas pela empresa.
Ao projetar um link, verifique se o registro do target é exclusivo quando uma relação 1-1 for declarada. Caso contrário, a associação poderá retornar vários registros quando somente um for esperado. Isso resulta em erros durante a preparação do delivery quando "a consulta retorna mais linhas do que o esperado". Defina o nome do link com o mesmo nome do schema de destino.
Defina um link com uma cardinalidade (1-N) no esquema no lado (1). Por exemplo, a relação Destinatário (1) - (N) Transação deve ser definida no schema da transação.
Observe que uma cardinalidade reversa de um link é (N) por padrão. É possível definir um link (1-1) adicionando o atributo revCardinality='single' à definição do link.
Se o link reverso não deve estar visível para o usuário, você pode ocultá-lo com a definição de link revLink='NENHUM'. Um bom caso de uso para isso é definir um link do recipient para a última transação concluída, por exemplo. Você só precisa ver o link do recipient para a última transação e nenhum link reverso é necessário para estar visível na tabela de transações.
Os links que executam uma associação externa (1-0…1) devem ser usados com cuidado, pois afetarão o desempenho do sistema.
O Adobe Campaign não é um data warehouse nem uma ferramenta de relatórios. Portanto, para garantir um bom desempenho da solução Adobe Campaign, o crescimento do banco de dados deve permanecer sob controle. Para isso, seguir algumas das práticas recomendadas abaixo pode ajudar.
Por padrão, os logs de entrega e rastreamento do Adobe Campaign têm uma duração de retenção de 180 dias. Um processo de limpeza é executado para remover qualquer log mais antigo que isso.
Saiba mais sobre a retenção de dados no Diretrizes de privacidade e segurança do Campaign.
Saiba mais sobre o workflow de limpeza do banco de dados do Campaign nesta seção.
As tabelas personalizadas não são removidas com o processo de limpeza padrão. Embora isso possa não ser necessário no primeiro dia, não se esqueça de criar um processo de limpeza para suas tabelas personalizadas, pois isso pode levar a desafios de desempenho.
Existem algumas soluções para minimizar a necessidade de registros no Adobe Campaign:
Você pode declarar o atributo "deleteStatus" em um esquema. É mais eficiente marcar o registro como excluído e, em seguida, adiar a exclusão na tarefa de limpeza.
Para garantir um melhor desempenho a qualquer momento, siga as práticas recomendadas abaixo.
O Adobe Campaign depende de mecanismos de banco de dados de terceiros. Dependendo do provedor, a otimização do desempenho para tabelas maiores pode exigir um design específico.
Abaixo estão algumas práticas recomendadas comuns que devem ser seguidas ao projetar seu modelo de dados usando tabelas grandes e associações complexas.
O tamanho da tabela é uma combinação do número de registros e do número de colunas por registro. Ambos podem afetar o desempenho das consultas.
No PostgreSQL, uma linha não deve exceder 8 KB para evitar TORRADA mecanismo. Portanto, tente reduzir o máximo possível o número de colunas e o tamanho de cada linha para preservar o desempenho ideal do sistema (memória e CPU).
O número de linhas também afeta o desempenho. O banco de dados do Adobe Campaign não foi projetado para armazenar dados históricos que não são usados ativamente para fins de direcionamento ou personalização. Este é um banco de dados operacional.
Para evitar qualquer problema de desempenho relacionado ao alto número de linhas, mantenha apenas os registros necessários no banco de dados. Qualquer outro registro deve ser exportado para um data warehouse de terceiros e removido do banco de dados operacional do Adobe Campaign.
Estas são algumas das práticas recomendadas relacionadas ao tamanho das tabelas:
Aqui está um exemplo:
Neste exemplo: