Aspectos Técnicos da Segmentação de Clientes Parte 2 - Integridade dos Dados

O último artigo nos ajudou a entender como a sincronização de dados permite uma segmentação eficaz. Mas para se tornar um verdadeiro assistente de segmentação, você precisa de mais uma coisa — a capacidade de avaliar e manter a qualidade dos dados, definida coletivamente como integridade de dados . Embora a melhor maneira de aprender sobre isso seja através da prática, envolver sua cabeça em conceitos críticos lhe dará uma vantagem inicial.

A integridade dos dados é um tópico amplo. Verdade seja dita, é o objetivo primordial de todo o departamento de TI. Todos são contratados para evitar extrair insights com base em dados incorretos.

Quando reduzimos a segmentação de clientes, um especialista em CRM deve estar ciente da exclusividade dos dados, tipos de dados e restrições de dados.

Exclusividade dos dados

Imagine um cliente recebendo uma mensagem duas vezes ou, pior ainda, recebendo uma mensagem duas vezes a cada vez com um desconto diferente. Um único caso não causará muito dano, mas se esse número aumentar, a campanha pode ser um fracasso instantâneo com consequências de longo prazo, incluindo a queda da fidelidade.

É por isso que seu banco de dados de clientes precisa cuidar da exclusividade dos dados. Para fazer isso, você precisa encontrar um identificador que permita distinguir entre dois clientes. Pode ser um e-mail ou um número de telefone. Embora sejam únicos para cada Tom, Dick ou Harry, eles não são bons candidatos para um identificador. Em primeiro lugar, endereços de e-mail e números de telefone podem mudar para uma pessoa. Em segundo lugar, você pode ter problemas para garantir a exclusividade de emails, incluindo “.” e “+” ou caracteres não ingleses.

É por isso que os CRMs usam um identificador interno exclusivo. É cunhado como um identificador exclusivo universal (UUID) ou identificador exclusivo global (GUID) .

Esses são algoritmos que pegam os atributos exclusivos do cliente (como e-mail ou número de telefone), os criptografam e geram uma sequência de caracteres aleatórios — exclusivos para cada cliente . Quando John se tornar seu cliente, o CRM gerará um identificador para ele, como 8f14a65f-3032-42c8-a196-1cf66d11b930.

Ao criar um identificador tão longo, você reduz o risco de gerar um ID duplicado para quase zero.

Tipos de dados

O formato no qual você armazena os dados pode ser outra ameaça ou ajudar na integridade dos dados. Imagine realizar uma pesquisa e pedir ao seu público um smartphone favorito – você deseja enviar uma oferta a todos os clientes que escolheram o iPhone X durante a promoção.

Ao ler a lista de respostas, você vê os seguintes registros:

• iPhone X
• iphone X
• i Telefone10
• iPhone X
• iphone 10
• Nokia 3310
• E assim por diante...

Ao criar um segmento para clientes “iPhone X”, o sistema mostrará apenas um cliente em vez de cinco. A solução para esse problema é simples — basta alterar o tipo de campo de resposta para uma lista predefinida em vez de um texto aberto. Mas se você esquecê-lo antes de um lançamento, você acaba com muitos trabalhos manuais no seu prato.

Erros simples, mas problemáticos, como esse podem ser evitados entendendo e verificando novamente o modelo de dados para cada etapa da jornada do cliente. A primeira etapa é visitar a documentação sobre as opções que seu CRM oferece para armazenar e processar dados para cada entidade — isso é chamado de esquema de dados.

Vamos explorar a aparência de um esquema de dados e como você pode usar seus recursos para garantir a integridade dos dados. Os tipos de dados vão primeiro.

Tipos de dados

Tipos de dados são atributos de dados que informam ao CRM como podemos usar os dados ou quais operações podemos fazer com eles. Aqui está a lista de tipos que você pode encontrar em praticamente todas as ferramentas de CRM.

Primitivos - tipos básicos

• Boolean – representa valores true ou false. Por exemplo, imagine um atributo: is_first_time_customer.
• Inteiro – representa um número, positivo ou negativo, que não possui ponto decimal. Por exemplo, no Salesforce CRM, os números inteiros têm um valor mínimo de -2.147.483.648 e um valor máximo de 2.147.483.647.
• Decimal (float) – um número que inclui um ponto decimal, por exemplo, 3,14159.
• Caractere – uma única letra ou qualquer caractere, incluindo números (coletivamente chamados de alfanuméricos).
• String – armazena uma string de quaisquer caracteres alfanuméricos, como uma palavra, uma frase ou uma sentença.
• Data – um valor que indica um dia específico.
• Datetime – um valor que indica um determinado dia e hora.
• Blob – (do objeto binário grande) uma coleção de dados binários armazenados como um único objeto. Você pode pensar nisso como um único arquivo (imagem, gravação de voz, filme, PDF, etc.) para simplificar.

Antes de passarmos para os tipos avançados, vamos fazer uma pausa por um momento para obter alguma intuição sobre como escolher o tipo certo. Você provavelmente já percebeu que cada tipo de dado tem duas características:

• que tipo de valores ela pode representar,
• quais são os valores mínimo e máximo que ele pode armazenar.

Existem duas regras de ouro para ambos:

1) Quando se trata de representação de valor – quanto mais flexibilidade você tiver, menos automação de dados será possível, ou melhor, mais trabalho em software será necessário para processar dados. Um exemplo simples seria o código postal nos EUA. Se for um número, podemos usar intervalos para inferir o estado (por exemplo, Alabama é 35801 a 35816). Isso seria impossível para a corda.

Outro bom exemplo seria nossa pesquisa. Se quiséssemos contar as variantes do iPhone X com a versão de texto aberto, precisaríamos ajustar nossa consulta para incluir todos os valores. Além disso, precisaríamos manter a consulta – toda vez que encontramos uma nova variante digitada por um usuário, a consulta deve ser atualizada.

2) A segunda regra é sobre os valores mínimo e máximo. Quanto maior o tamanho que você configurar para um atributo, mais flexível ele será. Agora, você deve estar se perguntando por que nem sempre usar a maior opção? Porque o tamanho maior precisa de mais memória do computador necessária para processar dados, e isso custa mais. Pode ser insignificante quando você tem centenas de registros, mas quando chega a milhões, sua instância de CRM pode demorar a responder ou você atingirá o limite e será forçado a atualizar para um plano de preços mais alto.

Composto – resultado da combinação de duas ou mais primitivas

• Array – um grupo de primitivos de qualquer tamanho. Geralmente é representado como uma série ou primitivas entre colchetes, por exemplo, [1, 3, 5, 13, 5].
• Set – um grupo de primitivas de qualquer tamanho, mas com valores únicos apenas [1, 3, 5, 13].
• Enum – um enum (de enumerator) é um tipo de dados com valores que cada um assume exatamente um de um conjunto finito de identificadores que você especifica (é um que devemos usar para nossa pesquisa para evitar confusão!).
• Objeto – Um objeto é um valor que contém outros valores, normalmente em números e sequências fixos e normalmente indexados por nomes. Os elementos dos registros são geralmente chamados de campos ou membros. Lembre-se dos exemplos JSON da primeira parte, eles são objetos.

Restrições de dados

Os tipos de dados já nos ajudam a manter a ordem nos dados e evitar tarefas tediosas de limpeza de dados, algo sobre o qual podemos agir com a ajuda das máquinas. Mas podemos fazer mais do que isso com restrições.

As restrições de dados definem propriedades específicas com as quais os dados devem obedecer. Um sistema de CRM confiável garante que as restrições permaneçam em todos os momentos, ou seja, quando você cria um novo objeto ou modifica um existente.

Você já recebeu um título de e-mail Dear {first.name}? Isso pode ser resultado do esquecimento de uma restrição NOT NULL no atributo first name.

Veja como essa e outras restrições típicas funcionam:

• Not null – cada valor não deve ser “NULL”, o que significa que não pode ser vazio.
• Unique – os valores devem ser exclusivos para cada objeto em um banco de dados. Por exemplo, se você deseja identificar clientes por e-mail ou número de telefone, deve tornar este campo exclusivo para evitar mensagens duplicadas e problemas mais graves.
• Chave primária – o(s) valor(es) deve(m) ser único(s) para cada objeto e não ser NULL. A maioria dos CRMs implementa essas restrições prontas para uso.
• Chave estrangeira – os valores devem fazer referência a um registro existente em outro objeto (por meio de sua chave primária ou alguma outra restrição exclusiva). Imagine que você encontre um cartão-presente em seu sistema, mas ele não tenha informações do proprietário. Você hesita em desativá-lo porque talvez um de seus clientes o tenha recebido e ficará desapontado se ele falhar no checkout. Adicionar uma chave estrangeira entre um cartão-presente e objetos de cliente resolveria esse problema porque o sistema não criará um cartão sem o proprietário atribuído ou removendo um proprietário de um cartão existente por engano.
• Check – uma expressão que deve ser verdadeira para que a restrição seja satisfeita. Essa é uma restrição abrangente para condições que você pode aplicar a atributos de tipos de dados específicos. Os exemplos a seguir devem ajudá-lo a entender o conceito:

• O e-mail (string) deve obedecer a um padrão específico (leia o artigo do wiki para ver que é mais complicado do que @ obrigatório no meio).
• Idade (inteiro) deve ser maior que 13.
• A data de nascimento (data) deve ser em março.
• A criação do cliente (data) deve ser anterior a 1º de outubro de 2020.
• O último pedido (DateTime) não deve ser anterior ao meio-dia de ontem.
• O número de telefone (string) deve começar com um prefixo de país.
• O endereço (objeto) deve consistir na rua, número, cidade, país, código postal – que podem ter suas próprias restrições de “verificação”. ‍

Normalização de dados

Há outro conceito que você deve conhecer para melhorar sua compreensão da integridade dos dados, a parte de duplicação de dados para ser mais específico. É chamado de normalização de dados .

Como exemplo, vamos pegar um programa de fidelidade. Precisamos agrupar os clientes em camadas para realizar algumas análises posteriormente. Imagine uma tabela mantendo informações sobre quando um cliente ingressou em uma camada específica.

Em vez de armazenar o nome da camada, que pode ser tão longa quanto Dunder Mifflin Golden Tier para cada pessoa, simplesmente mantemos um número que faz referência a uma tabela das camadas do programa.

Então, em vez de ter 20.000 Dunder Mifflin Golden Tier, temos 20.000 referências como a nº 3. Quando você deseja alterar o nome da camada por algum motivo, é necessário atualizá-lo apenas em um local e a integridade dos dados será mantida.

Agora, vamos aprofundar um conceito de normalização mais avançado. Vamos supor que você queira monitorar como um cliente se moveu em diferentes níveis. Podemos armazená-lo na seguinte tabela:

Cliente | Camada | Data de inserção do nível

Mike Scott | Nível Dourado DM | 21/07/2020

Mike Scott | DM Nível Prata | 04/06/2020

Jim Halpert | Nível DM Bronze | 17/06/2020

Mas é melhor criar três objetos separados para armazenar isso, uma tabela com a lista de camadas, uma tabela com a lista de clientes e outra para conectar os dois. Isso nos dá a maior liberdade que podemos obter ao alterar as informações do cliente ou as informações do nível separadamente, e temos menos dados duplicados, é claro.

Os objetos de CRM padrão geralmente seguem os conceitos de normalização de dados. Ainda assim, se você deseja criar alguns objetos personalizados estendendo o esquema pronto para uso, deve sempre manter a normalização de dados em mente.

Aprendizado

Quando você estiver trabalhando com um novo CRM, visite a documentação para explorar o esquema de dados. Percorra os objetos padrão para ver o que você pode fazer imediatamente. Aprenda os tipos de dados e como você pode agir sobre eles com mecanismos integrados, como cálculos Hubspot, campos calculados do Salesforce com fórmulas ou como apresentá-los com linguagens de modelo como Liquid.

Como exercício, você também pode visitar o artigo do Fabric sobre como criar um esquema de dados de comércio eletrônico para explorar como uma teoria de integridade de dados desta postagem se aplica a um caso de uso da vida real.