Como criar uma planilha CDP a partir de seus casos de uso

O mundo da tecnologia de marketing costuma ser uma bagunça confusa. Os serviços oferecidos pelas plataformas de dados do cliente, plataformas de gerenciamento de dados, plataformas de automação de marketing e provedores de serviços de e-mail geralmente se sobrepõem e pode ser difícil decidir o que você precisa.

Se você está considerando um CDP, há muito por onde escolher e eles vêm em vários sabores diferentes. As peculiaridades únicas de qualquer CDP geralmente são determinadas por sua história de origem. A maioria dos CDPs começou como outra coisa e aderiu a serviços adicionais para se tornar CDPs completos. Aquele que começou como um provedor de serviços de e-mail (ESP) será um animal diferente daquele que começou como um mecanismo de recomendação. Eles também diferem em se concentrar mais em B2B, B2C, varejo, publicação, etc.

Uma maneira de eliminar a névoa é distinguir esses serviços por seus componentes de back-end e front-end.

Back-end vs. front-end

Os componentes de back-end incluem a infraestrutura técnica e os processos usados ​​para coletar, armazenar, harmonizar e gerenciar dados do cliente. Essa categoria normalmente inclui integração de dados, armazenamento, governança e recursos de segurança. O componente de back-end é responsável por garantir que os dados do cliente sejam precisos, completos e acessíveis, com o objetivo de mesclar registros diferentes de várias fontes para criar uma única visão do cliente.

O componente front-end de um CDP pode ser dividido em recursos voltados para o profissional de marketing e voltados para o cliente. O lado voltado para o profissional de marketing incluiria visualização de dados e relatórios, enquanto o lado voltado para o cliente poderia incluir mecanismos de recomendação, gerenciamento de paywall e exibição de conteúdo personalizado.

Alguns CDPs são quase exclusivamente back-end, com quase nenhum recurso de front-end voltado para o cliente. Outros CDPs incluem muitas “ativações” de front-end. Para complicar ainda mais, todas essas funções estão disponíveis em serviços autônomos e dedicados.

O truque para avaliar um CDP é descobrir quais componentes são necessários para seus casos de uso e quais precisam fazer parte do próprio CDP.

Por exemplo, um CDP pode ter um ESP integrado. Isso pode ou não ser uma coisa boa para você. Se um de seus casos de uso exigir que você envie um e-mail no momento em que um usuário realizar uma ação em seu site, você precisará do CDP para poder enviar o e-mail ou precisará de uma conexão em tempo real para um ESP externo.

É útil pensar em um CDP da mesma forma que você pode pensar em um resort de férias. O proprietário do resort quer poder dizer que o resort tem alguma atividade, como um toboágua, então eles constroem um toboágua simbólico na propriedade. Não vai ser tão bom quanto o toboágua dedicado na estrada, mas também não é na estrada. É bem ali no resort.

Da mesma forma, o ESP embutido em um CDP provavelmente não terá tantos recursos quanto um ESP dedicado, mas isso não importa. O que importa é qual solução atende aos requisitos de seus casos de uso.

Para tornar ainda mais complicado, existem muitos serviços “semelhantes ao CDP” que fazem parte do trabalho de um CDP.

Para navegar nessa confusão confusa, considere alguns casos de uso e veja como a métrica back-end versus front-end pode ajudar.

Mecanismos de recomendação de conteúdo

Adicionar recomendações personalizadas a um artigo em seu site pode aprimorar a experiência do visitante com sua marca e aumentar as visualizações de página.

A funcionalidade exigida por esse caso de uso depende de quais dados o mecanismo de recomendação usará.

Se você deseja recomendar artigos com base (pelo menos em parte) em quais boletins eletrônicos o cliente recebe ou em quais produtos o cliente assina, você precisará de uma conexão de back-end com o ESP e/ou o sistema de atendimento e você precisará da capacidade de mesclar o perfil online do usuário com esses dados. Mas se você deseja apenas fazer recomendações com base no comportamento do usuário na Web, não precisa dessa função de back-end e pode nem precisar de um CDP. Muitos mecanismos de recomendação independentes podem lidar com isso.

Perguntas a serem feitas:

• Este caso de uso requer gerenciamento de dados de back-end?
• A função de front-end do CDP é boa o suficiente ou preciso de um serviço dedicado?
• O CDP se integra a esse serviço dedicado?

“Clientes que compraram isso…”

No espaço de varejo, os fornecedores desejam fornecer recomendações de produtos, o que pode aumentar o valor de cada pedido.

Se as recomendações forem baseadas (pelo menos em parte) no histórico de pedidos do cliente, o mecanismo de recomendação precisará desses dados de back-end. Se as recomendações forem simplesmente baseadas em médias de todos os clientes, informações específicas sobre o histórico de compras do cliente são irrelevantes.

Gerenciando um acesso pago

Os editores que não desejam depender exclusivamente da receita de anúncios para financiar a criação de seu conteúdo podem oferecer acesso a conteúdo premium por uma taxa. Isso requer a criação e manutenção de contas para gerenciar o acesso a esse conteúdo.

Em muitos casos, essas contas precisarão ser coordenadas com outras contas, como uma assinatura de revista. Por exemplo, um assinante de revista pode acessar o paywall gratuitamente ou com desconto. Nesse caso, o sistema de gerenciamento de acesso pago terá que se integrar aos dados de back-end do sistema de preenchimento de revistas.

Otimização da página de destino

Os testes A/B ou multivariados da página de destino podem aumentar drasticamente o sucesso de uma loja online, formulários online e páginas de inscrição em boletins eletrônicos. Os serviços que facilitam a criação e implantação desses testes geralmente não fazem distinção entre clientes e não clientes, e isso parece funcionar na maioria das situações. Nesses casos, você não precisa de um CDP.

No entanto, se você tiver motivos para acreditar que seus clientes são significativamente diferentes do visitante médio da Web, talvez seja necessário que o cálculo de otimização da página de destino mostre estatísticas diferentes para grupos diferentes.

Por exemplo, um site com conteúdo médico pode ter um público dividido que inclui profissionais médicos e cidadãos comuns. Você não gostaria que os resultados de um teste A/B em uma página de destino para um relatório escrito para médicos incluíssem estatísticas sobre como todos responderam. Nesse caso, informações de back-end sobre o público podem ser cruciais.

Vá mais fundo: o que é um CDP e como isso dá aos profissionais de marketing a cobiçada 'visão única' de seus clientes?

pesquisas

As pesquisas podem ajudá-lo a entender seus clientes, o que pode ajudá-lo a fornecer um serviço melhor. Muitos CDPs podem gerenciar pesquisas, mas muito poucos CDPs podem competir com a funcionalidade de uma plataforma de pesquisa dedicada. Como isso afeta sua avaliação de possíveis fornecedores de CDP?

Perguntas a serem feitas:

• Minhas pesquisas serão aprimoradas com a incorporação de dados de back-end do cliente? (Por exemplo, não fazer perguntas que você já sabe ou fazer perguntas diferentes para públicos diferentes.)
• É importante poder estender o processo de pesquisa ao longo do tempo por meio de perfis progressivos?

Construindo uma planilha

Espero que esses exemplos tenham levado você a imaginar uma planilha mais ou menos como esta.

Este é um exemplo excessivamente simples, mas você pode usar essa ideia geral para personalizar uma planilha para seus requisitos específicos.

A chave é começar com casos de uso e considerá-los em termos de funções front-end e back-end, considerando também alternativas de terceiros. Quanto mais seus casos de uso exigirem funções de back-end, mais provável será que você precise de um CDP. E depois de criar esse documento, ele tornará o processo de RFP/descoberta muito mais fácil.