Autor
Neste artigo, explicamos os desafios da reconciliação de ID e demonstramos nossa abordagem para criar um ID de perfil unificado na plataforma Data do cliente, especificamente...
O Data foi coletado de um armazém Data off-line e do rastreamento on-line do site.
Cliente Plataforma Data
A Customer Data Platform (CDP) permite que as empresas coletem, gerenciem e analisem os dados de clientes data de várias fontes de forma unificada e centralizada. A objetivo de um CDP é criar uma visão abrangente e coesa de cada cliente, agregando data de vários pontos de contato, como sites, aplicativos móveis, mídias sociais, interações por e-mail e muito mais.
Tesouro Data
O Treasure Data é uma plataforma Data para clientes baseada no cloud. Veja a seguir alguns casos comuns de uso comercial do Treasure Data:
Reconciliação de ID
A reconciliação de ID é um processo no qual o data relacionado a uma pessoa é comparado e combinado em diferentes sistemas ou bases de data para garantir precisão, consistência e uma visão unificada dessa pessoa.
Isso é particularmente importante em cenários em que vários sistemas ou fontes de data armazenam informações sobre os mesmos indivíduos, mas o data pode ser incompleto ou inconsistente.
O desafio da reconciliação de IDs
A reconciliação de IDs encontra vários desafios, especialmente com conjuntos extensos de data e diversas fontes de informação. Esses desafios incluem formatos data inconsistentes, problemas de qualidade que levam a falsas correspondências e o gerenciamento de registros duplicados resultantes de erros ou alterações no sistema. O principal desafio é a falta de um ID exclusivo representar o usuário em diferentes fontes de informação, tabelas e bases de dados data.
As organizações enfrentam esses desafios investindo em ferramentas data avançadas, como o Treasure Data.
Implementação da reconciliação de ID
Implementamos a reconciliação de IDs para um de nossos clientes usando a funcionalidade de unificação do Treasure Data. Neste artigo, queremos compartilhar nossa abordagem e lógica de implementação.
Condições dadas: No CDP databases, havia tabelas disponíveis com informações sobre a jornada do usuário no site, bem como informações de clientes do CRM (Customer Relationship Management) database no depósito data.
O objetivo é ter um identificador de perfil exclusivo em cada tabela CDP. Isso nos permitirá criar um Master Segment com uma visão de 360 graus sobre o cliente e sua jornada.
data on-line disponível: visualizações nas páginas do site, envios de formulários no site, outras informações específicas do site, como detalhes da página do produto, que são armazenadas em uma tabela separada.
data off-line disponível: CRM data do armazém data.
Visão geral das etapas para criar um ID de perfil exclusivo:
Unificação de tabelas da Web
Para unificar o data da Web, aproveitaremos o recurso da funcionalidade de unificação do Treasure Data. Isso requer a definição das tabelas de origem e das colunas que precisam ser unificadas na configuração formatada em YAML. O guia passo a passo sobre como implementar a Unificação no Treasure Data pode ser encontrado em Documentação do Treasure Data.
Como resultado, ele cria um ID canônico em cada tabela que é usada na unificação. O objetivo da ID canônica é criar uma ID que represente cada usuário da Web. É útil quando aplicado ao data da Web, em que é difícil identificar sessões de usuários e unificar o data da Web em diferentes sessões.
Definimos que a ID canônica se baseia nas seguintes chaves de mesclagem:
- name: td_canonical_id
merge_by_keys: [email, phone, td_client_id]. source_tables: [web_form_submitted, web_product_detail, web_page_visits].
A ordem das chaves de mesclagem define a prioridade. A primeira chave de mesclagem identifica todos os data da Web com a mesma e-mail (e-mails fornecidos no formulário da Web enviado no site) do mesmo usuário.
A segunda prioridade é número de telefone (enviados por visitantes do site): data com o mesmo número de telefone também é identificado como sendo do mesmo usuário. A terceira prioridade é td_client_id - ID de cookie da primeira parte. O ID do cookie da primeira parte é persistente nos mesmos domínios. Domínios diferentes terão td_client_id diferentes. O td_client_id muda se o visitante do site limpar o navegador cookies.
O resultado da unificação é mostrado nos exemplos abaixo.
Exemplo 1: O Treasure Data definiu essas 3 entradas como a mesma ID de usuário (td_canonical_id), pois elas têm a mesma e-mail. Números de telefone diferentes não afetam o resultado porque definimos que o e-mail tem prioridade maior do que o número de telefone:
Exemplo 2: Quando o e-mail não é fornecido, o mesmo número de telefone representa a mesma ID de usuário (td_canonical_id):
Exemplo 3: Quando os campos de correspondência de prioridade mais alta não forem definidos, será usado o ID do cookie da primeira parte. Idem td_client_id = mesma ID de usuário (td_canonical_id). Esses visitantes não identificados sem nenhuma informação pessoal identificável (PII) são comuns nas tabelas de visitantes de sites. O td_client_id não é totalmente confiável, pois pode mudar após a limpeza do cookie, mas, na ausência de PII data, é a melhor chance que temos.
Se presumirmos que apenas o envio de formulários em um site contém e-mail e formulário, o que acontece com as tabelas, onde não há PII disponíveis, por exemplo web_page_visits? Vamos supor que as visitas ao site tenham apenas o ID do cookie da primeira parte - td_client_id. No primeiro exemplo web_page_visits com os td_client_id ‘asd-123-qwe-456’, ‘zxc-234-ert-345’ e ‘567-tyu-ghj-234’ terá o td_canonical_id = ‘abcd1234’. Desde que web_form_submitted A tabela já definiu que esses 3 IDs de cookie pertencem ao mesmo usuário, web_page_visits O senhor poderá contar com essas informações na ausência de e-mail ou telefone.
A mesma lógica se aplica a outras tabelas data da Web que não têm PII data.
Criar uma tabela mestre que una o on-line e o off-line data
Agora que o data da web está unificado entre si, é hora de unificar o data on-line (web) e off-line. Por data off-line entendemos o data de CRM que contém PII. Do data on-line, usaremos o data de PII (e-mail, telefone) na tabela web_form_submitted.
Em um caso ideal, os engenheiros do data podem adicionar uma tabela de CRM em um arquivo yml de unificação, mas tivemos um caso em que a condição do cliente para unificar o data on-line e off-line era mais complexa do que a unificação automática pode oferecer. Portanto, contamos aqui com o poder do SQL.
Executamos o FULL OUTER JOIN das tabelas da Web com o envio de formulário data e as tabelas de CRM ON e-mail ou telefone. O nome e o sobrenome não são exclusivos e, portanto, não são confiáveis.
SELECT t.crm_client_id, d.td_canonical_id
FROM crm_user_table t
FULL OUTER JOIN web_form_submitted d
ON (t.email = d.email
OU t.phone = d.phone)
Também é aconselhável definir uma lógica para a pontuação de correspondência, caso vários formulários sejam enviados com o mesmo e-mail ou número de telefone. Por exemplo, os formulários da Web cujos nomes e sobrenomes correspondem aos nomes dos clientes de CRM têm prioridade mais alta do que aqueles que não correspondem.
Enriquecer outras tabelas com profile_id
Nesta seção, definimos o profile_id final que é exclusivo para cada usuário, identificado e não identificado.
Em resumo, profile_id = COALESCE(crm_client_id, td_canonical_id).
Para tabelas da web crm_client_id são fornecidos por chave da web (td_canonical_id) da tabela mestre criada na etapa 2. Ou seja, se os usuários enviaram um formulário em um site e forneceram e-mail ou telefone, podemos identificá-los no CRM database como clientes conhecidos (caso já sejam clientes da empresa). Como resultado, podemos dizer que as visitas à página da Web com o mesmo ID de cookie do formulário da Web enviado também pertencem ao cliente de CRM identificado.
from web_page_visits t
left join master_table d
on t.td_canonical_id = d.td_canonical_id
e d.rn_web_key = 1
A rn_web_key é definida da seguinte forma:
partição por td_canonical_id
order by match_score,
time desc) as rn_web_key
Sua função é evitar duplicatas na tabela de destino, pois todas as tabelas da Web têm relacionamentos de muitos para muitos. Além disso, ele compartilha crm_client_id com o perfil que tem a melhor correspondência entre o data off-line e on-line. Para cada td_canonical_id, ele seleciona aquele com a maior pontuação de correspondência e, caso a pontuação de correspondência seja a mesma, a entrada mais recente.
Criar a tabela audience que contém o perfil de todas as tabelas
Agora que todas as tabelas têm um ID de perfil, é hora de criar um Master Segment. Segmento principal (segmento pai) é um recurso do Treasure Data que unifica todas as informações sobre o usuário, inclusive a interação do usuário com o site e o produto. Ele permite que os analistas de negócios, profissionais de marketing e outros usuários vejam no Audience Studio todos os perfis identificados e não identificados e criem vários segmentos com eles sem escrever nenhuma consulta SQL.
Para criar um Master Segment, precisamos ter uma tabela audience que será usada para unir todas as tabelas de atributos e comportamento. O objetivo da tabela audience é ter todos os perfis - on-line e off-line. E ela conterá apenas profile_id, pois isso deve ser suficiente para uni-la a todas as outras tabelas (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
A implementação é tão simples quanto a união de todas as tabelas que contêm profile_id e a deduplicação de todos os profile_ids.
