Você deve usar seu data warehouse como seu CDP?

O advento de data warehouses baseados em nuvem (DWHs) trouxe implantação mais simples, maior escala e melhor desempenho para um conjunto crescente de casos de uso orientados a dados. Os DWHs se tornaram mais prevalentes em pilhas de tecnologia corporativa, incluindo pilhas de martech.

Inevitavelmente, isso levanta a questão: você deve empregar seu DWH existente como uma plataforma de dados do cliente (CDP)? Afinal, ao reutilizar um componente existente em sua pilha, você pode economizar recursos e evitar novos riscos.

Mas a história não é tão simples e vários padrões de design em potencial aguardam. Em última análise, há um caso a favor e contra o uso de seu DWH como um CDP. Vamos cavar mais fundo.

DWH como um CDP pode não ser adequado para você

Existem vários problemas inerentes ao uso de um DWH como um CDP. A primeira é óbvia: nem todas as organizações têm um DWH implantado. Às vezes, uma equipe de DWH corporativa não tem tempo ou recursos para oferecer suporte a casos de uso centrados no cliente. Outras empresas implementam efetivamente um CDP como um quase data warehouse. (Nem todos os CDPs podem fazer isso, mas você entendeu.)

Digamos que você tenha a maioria ou todos os dados do cliente em um DWH. O problema para muitas empresas, se não para a maioria, é que os dados não são acessíveis de maneira amigável ao marketing. Normalmente, um DWH corporativo é construído para oferecer suporte a casos de uso de análise, não a casos de uso de ativação. Isso afeta como os dados são rotulados, gerenciados, relacionados e governados internamente.

Lembre-se de que um DWH é essencialmente para armazenamento e computação, o que significa que os dados são armazenados em tabelas de banco de dados com nomes de coluna como atributos. Em seguida, você escreve instruções SQL complexas para acessar esses dados. Não é realista que seus profissionais de marketing se lembrem de nomes de tabelas e colunas antes de poderem criar segmentos para ativação. Em outras palavras, os DWHs normalmente não oferecem suporte ao autoatendimento do profissional de marketing, como a maioria dos CDPs.

Isso também toca em uma questão estrutural mais ampla. Os DWHs normalmente não são projetados para oferecer suporte a casos de uso de marketing em tempo real que muitos CDPs visam. Ele pode realizar cálculos rápidos e você pode agendar a ingestão e o processamento para ocorrer em intervalos frequentes, mas ainda não é em tempo real. Da mesma forma, com algumas exceções, um DWH não deseja atuar com dados brutos, enquanto os profissionais de marketing geralmente desejam empregar dados brutos (normalmente eventos) para acionar determinadas ativações.

Por fim, lembre-se de que os dados e a capacidade de acessá-los não constituem um CDP. A maioria dos CDPs oferece algum subconjunto de recursos adicionais que você não encontrará em um DWH, como:

• Subsistema de eventos com disparo.
• Resolução de identidade anônima.
• Interface amigável ao profissional de marketing para segmentação.
• Segmentar perfis de ativação com conectores.
• Potencialmente serviços de teste, personalização e recomendação.

Um DWH sozinho não fornecerá esses recursos; portanto, você precisará obtê-los em outro lugar. Obviamente, os fornecedores de DWH têm mercados de parceiros consideráveis. Você pode encontrar muitas alternativas, mas elas não são nativas e exigirão esforço de integração e suporte.

Não surpreendentemente, então, há muita conversa sobre “CDPs combináveis” e o papel potencial de um DWH nesse contexto. Argumentei anteriormente que a composição é um espectro e você começa a perder benefícios além de um certo ponto.

Tendo emitido todas essas ressalvas, um DWH pode desempenhar um papel como parte de uma pilha de dados do cliente, incluindo:

• Acabar com um CDP ativando diretamente do DWH.
• Usando o DWH como um quase-CDP com uma plataforma ETL reversa.
• Coexistindo com um CDP.

Vejamos esses três padrões de projeto.

1. Conectando plataformas de marketing diretamente ao seu DWH

Este é talvez o caso mais extremo que critiquei acima, mas algumas empresas fizeram isso funcionar, especialmente na era pré-CDP e as plataformas (como Snowflake com seu amplo ecossistema) estão tentando resolver isso.

A ideia aqui é que sua plataforma de engajamento se conecte diretamente aos dados push-pull com um DWH. Muitas plataformas maduras de e-mail e automação de marketing são conectadas nativamente para fazer isso, embora normalmente via envio em lote. Seus profissionais de marketing usam a plataforma de mensagens para criar segmentos e enviar mensagens para esses segmentos no caso de marketing de saída.

Imagine que você tenha outra plataforma de marketing ou engajamento, um site personalizado ou plataforma de comércio eletrônico. Mais uma vez, você extrai dados do DWH e, em seguida, emprega a plataforma de aplicativos da Web para criar outro conjunto de segmentos para um engajamento mais direcionado.

Você já vê o problema? Já existem dois conjuntos de interfaces de segmentação. O que aconteceria se você tivesse 10 plataformas de marketing? 20? Você continuará criando segmentos em todos os lugares, então sua promessa omnichannel desaparece.

Por fim, e se você tivesse que adicionar outra plataforma de marketing que não suportasse a ingestão direta de um DWH?

2. Empregar DWH com ferramentas de ETL reverso

Essa abordagem resolve vários problemas com o primeiro padrão acima. Notavelmente, ele permite (em teoria) que um especialista não-DWH crie segmentos universais virtualmente no topo do DWH e ative múltiplas plataformas. Com a transformação e uma estrutura de conector melhor, você pode aplicar diferentes mapeamentos de rótulos e estruturas de dados amigáveis ​​ao profissional de marketing a diferentes endpoints.

Veja como funciona. As plataformas de ETL reverso extraem dados do DWH e os enviam para plataformas de marketing após qualquer transformação. Você pode realizar várias transformações e enviar esses dados para vários destinos simultaneamente. Você pode até mesmo automatizá-lo e fazer com que as exportações sejam executadas regularmente em uma programação predefinida.

Mas uma cópia desses dados (ou um subconjunto deles) é realmente copiada para as plataformas de destino, então você realmente não tem apenas uma única cópia dos dados. Como a plataforma ETL reversa não possui uma cópia dos dados, seus segmentos ou audiências necessários são sempre gerados no momento da consulta (normalmente em lotes). Então você os exporta para os destinos.

Essa não é uma abordagem adequada se você deseja ter acionadores em tempo real ou campanhas sempre ativas com base em eventos. Claro, você pode automatizar suas exportações em alta frequência, mas isso não é em tempo real. À medida que você aumenta sua frequência de exportação, seus custos aumentam exponencialmente.

Além disso, embora as ferramentas de ETL reverso forneçam uma interface de segmentação, elas tendem a ser mais técnicas e focadas em DataOps do que em MOps. Antes de declarar que esta é uma solução “amigável para os negócios” adequada para o autoatendimento do profissional de marketing, você deve testá-la com cuidado.

3. DWH coexiste com CDP

Seu DWH corporativo serve como uma camada de infraestrutura de dados do cliente que fornece dados ao seu CDP (entre outros endpoints). Muitos, se não a maioria, CDPs agora oferecem alguns recursos para sincronizar a partir de plataformas DWH, principalmente o Snowflake.

Existem variações em como esses CDPs podem coexistir com DWH. A maioria dos CDPs sincroniza e duplica dados em seu repositório, enquanto outros (incluindo fornecedores de ETL reverso) não fazem uma cópia. No entanto, pode haver compensações que você precisa considerar antes de finalizar o que funciona para você.

Em geral, tendemos a ver grandes empresas preferindo esse padrão de design, embora com ampla variação em relação a onde residem serviços essenciais, como resolução de identidade do cliente.

Vá mais fundo: onde um CDP deve se encaixar em sua pilha de martech?

Embrulhar

As plataformas DWH desempenham papéis cada vez mais essenciais nas pilhas de martech. No entanto, você continua tendo várias opções de arquitetura sobre quais serviços você presta em seu ecossistema de dados.

Acho que é prematuro descartar CDPs em seu futuro. Cada padrão tem suas compensações a serem lembradas ao avaliar suas opções.