Neste artigo, explicamos os desafios da reconciliação de IDs e demonstramos nossa abordagem para criar um ID de perfil unificado na plataforma Data do cliente, especificamente no Treasure Data.
Data foi coletado em um armazém off-line Data e no rastreamento on-line do site.
Cliente Data Plataforma
A CDP (Customer Data Platform) permite que as empresas coletem, gerenciem e analisem o cliente data de várias fontes de forma unificada e centralizada. O objetivo de uma 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 de clientes baseada em nuvem. Aqui estão alguns casos comuns de uso comercial do Treasure Data:
Reconciliação de ID
A reconciliação de ID é um processo no qual data relacionados a uma pessoa são comparados e combinados em diferentes sistemas ou bancos de dados para garantir a precisão, a consistência e uma visão unificada dessa pessoa.
Isso é particularmente importante em cenários em que vários sistemas ou fontes data armazenam informações sobre os mesmos indivíduos, mas o data pode estar incompleto ou inconsistente.
O desafio da reconciliação de IDs
A reconciliação de IDs encontra vários desafios, especialmente com conjuntos de dados extensos e diversas fontes de informação. Esses desafios incluem formatos inconsistentes no site data , 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 que represente o usuário em todas as diferentes fontes de informações, tabelas e bancos de dados.
As organizações enfrentam esses desafios investindo em ferramentas avançadas do data , 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: nos bancos de dados do CDP, havia tabelas disponíveis com informações sobre a jornada do usuário no site, bem como informações sobre o cliente do banco de dados do CRM (Customer Relationship Management) no armazém 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.
Online data 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 armazenados em uma tabela separada.
Disponível off-line data : CRM data do depósito data .
Visão geral das etapas para criar um ID de perfil exclusivo:
Unificação de tabelas da Web
Para unificar a Web data , 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 na 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 à Web data, onde é difícil identificar sessões de usuários e unificar a Web data em diferentes sessões.
Definimos que a ID canônica é baseada 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 sites data com o mesmo e-mail (e-mails fornecidos no formulário da Web enviado no site) como sendo do mesmo usuário.
A segunda prioridade é o número de telefone (enviado pelos 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 do cookie primário. O ID do cookie primário é 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: Treasure Data definiu essas 3 entradas como o mesmo ID de usuário (td_canonical_id), já que elas têm o mesmo e-mail. Números de telefone diferentes não afetam o resultado porque definimos que o e-mail tem prioridade maior 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 são definidos, o ID do cookie da primeira parte é usado. Mesmo td_client_id = mesmo ID de usuário (td_canonical_id). Esses visitantes não identificados sem nenhuma informação pessoal identificável (PII) são comuns em 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 somente o envio de formulários em um site contém e-mail e formulário, o que acontece com as tabelas em que 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, a tabela 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'. Como a tabela web_form_submitted já definiu que esses 3 IDs de cookie pertencem ao mesmo usuário, web_page_visits se baseará nessas informações na ausência de e-mail ou telefone.
A mesma lógica se aplica a outras tabelas da Web data que não têm PII data.
Criar uma tabela mestre que una o on-line e o off-line data
Agora que a Web data está unificada entre si, é hora de unificar o data on-line (Web) e off-line. Por data off-line queremos dizer CRM data que contém PII. Do data on-line, usaremos as PII data (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 FULL OUTER JOIN de tabelas da Web com envio de formulários data e 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
OR 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 é fornecido 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 banco de dados do CRM 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 off-line e on-line data. Para cada td_canonical_id, ele pega aquele com a pontuação de correspondência mais alta e, caso a pontuação de correspondência seja a mesma, então 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. O Master Segment (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 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.