Autor
Neste artigo, explicamos os desafios da reconciliação de identidades e demonstramos nossa abordagem para criar um perfil de identidade unificado na Data do Cliente, especificamente na Treasure Data.
Data coletados a partir de um Data offline e do rastreamento online do site.
Data do Cliente
Data do Cliente (CDP) permite que as empresas coletem, gerenciem e analisem data de clientes data diversas fontes de maneira unificada e centralizada. O objetivo de uma CDP é criar uma visão abrangente e coesa de cada cliente, agregando data vários pontos de contato, como sites, aplicativos móveis, redes sociais, interações por e-mail e muito mais.
Treasure Data
Data Treasure Data uma Data do cliente cloud. Aqui estão alguns casos de uso comuns da Treasure Data:
Reconciliação de identidades
A reconciliação de identidades é um processo no qual data a uma pessoa são comparados e cruzados entre 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 situações em que vários sistemas ou data armazenam informações sobre as mesmas pessoas, mas os data estar incompletos ou inconsistentes.
O desafio da reconciliação de identidades
A reconciliação de identidades enfrenta inúmeros desafios, especialmente quando se trata de conjuntos de dados extensos e fontes de informação diversificadas. Esses desafios incluem data inconsistentes, problemas de qualidade que levam a correspondências incorretas e o gerenciamento de registros duplicados resultantes de erros ou alterações no sistema. O principal desafio é a falta de um identificador único que represente o usuário nas diferentes fontes de informação, tabelas e bancos de dados.
As organizações enfrentam esses desafios investindo em data avançadas data , como o Treasure Data.
Implementação da reconciliação de identidades
Implementamos a reconciliação de identidades para um de nossos clientes utilizando a funcionalidade Data do Treasure Data . Neste artigo, queremos compartilhar nossa abordagem e a lógica de implementação.
Condições existentes: nas bases de dados do CDP, havia tabelas disponíveis com informações sobre a jornada do usuário no site, bem como informações sobre os clientes provenientes da base de dados de CRM (Gestão de Relacionamento com o Cliente) no data .
O objetivo é ter um identificador de perfil único em cada tabela do CDP. Isso nos permitirá criar um Segmento Mestre com uma visão completa do cliente e de sua jornada.
data online data : visualizações das páginas do site, envios de formulários no site e outras informações específicas do site, como detalhes das páginas de produtos, que são armazenados em uma tabela separada.
data offline data : data de CRM data data .
Visão geral das etapas para criar um ID de perfil exclusivo:
Unificação de tabelas na Web
Para unificar data da web, data a funcionalidade de Data Treasure Data . Para isso, é necessário definir as tabelas de origem e as colunas que precisam ser unificadas em uma configuração no formato YAML. O guia passo a passo sobre como implementar a unificação no Treasure Data ser encontrado na Data Treasure Data .
Como resultado, ele cria um ID canônico em cada tabela utilizada na unificação. O objetivo do ID canônico é criar um identificador que represente cada usuário da web. Ele é útil quando aplicado a data da web, onde é difícil identificar sessões de usuários e unificar data da web data diferentes sessões.
Definimos que o ID canônico se baseia nas seguintes chaves de fusão:
– nome: td_canonical_id
merge_by_keys: [email, telefone, td_client_id] tabelas_de_origem: [web_form_submitted, web_product_detail, web_page_visits]
A ordem das chaves de fusão define a prioridade. A primeira chave de fusão identifica todos data da web data o mesmo endereço de e-mail (endereços fornecidos no formulário enviado pelo site) como pertencentes ao mesmo usuário.
A segunda prioridade é o número de telefone (fornecido pelos visitantes no site): data o mesmo número de telefone também são identificados como pertencentes ao mesmo usuário. A terceira prioridade é o td_client_id — o ID First-Party . O ID First-Party é persistente nos mesmos domínios. Domínios diferentes terão um td_client_id diferente. O td_client_id muda se o visitante do site limpar os cookies do navegador.
O resultado da unificação é mostrado nos exemplos abaixo.
Exemplo 1: O Treasure Data essas três entradas como pertencentes ao mesmo ID de usuário (td_canonical_id), uma vez que possuem o mesmo e-mail. Os números de telefone diferentes não afetam o resultado, pois 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 o mesmo ID de usuário (td_canonical_id):
Exemplo 3: quando não há campos de correspondência de prioridade mais alta definidos, utiliza-se o ID do cookie de primeira parte. O mesmo td_client_id corresponde ao mesmo ID de usuário (td_canonical_id). Esses visitantes não identificados, sem nenhuma informação de identificação pessoal (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 dos cookies, mas, na ausência de data PII, é a melhor opção que temos.
Se assumirmos que apenas o envio de formulários em um site contém e-mail e formulário, o que acontece com as tabelas nas quais não há informações de identificação pessoal (PII) disponíveis, como, por exemplo, a tabela web_page_visits? Vamos supor que as visitas ao site tenham apenas o ID First-Party — 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 três IDs de cookie pertencem ao mesmo usuário, a tabela web_page_visits se baseará nessa informação na ausência de e-mail ou telefone.
A mesma lógica se aplica a outras data da web que não contêm data de identificação pessoal.
Criar uma tabela mestre que junte data online e offline
Agora que data da web data unificados entre si, é hora de unificar data online (da web) e offline. Por data offline data data do CRM data contêm informações de identificação pessoal (PII). Dos data online, data data de identificação pessoal data e-mail, telefone) contidas na tabela web_form_submitted.
Em uma situação ideal, data podem incluir uma tabela do CRM em um arquivo YML de unificação, mas tivemos um caso em que os requisitos do cliente para unificar data online e offline data mais complexos do que a unificação automática poderia oferecer. Por isso, recorremos aqui ao poder do SQL.
Realizamos uma junção externa completa (FULL OUTER JOIN) entre as tabelas da web com data de envio de formulários data as tabelas do CRM com base em e-mail ou telefone. O nome e o sobrenome não são únicos 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 é recomendável definir uma lógica para a pontuação de correspondência, caso sejam enviados vários formulários com o mesmo e-mail ou número de telefone. Por exemplo, os formulários da web cujos nomes e sobrenomes correspondam aos nomes dos clientes do CRM têm prioridade maior do que aqueles em que isso não ocorre.
Atualizar outras tabelas com o profile_id
Nesta seção, definimos o `profile_id` final, que é único para cada usuário, seja ele identificado ou não.
Em resumo, profile_id = COALESCE(crm_client_id, td_canonical_id).
Nas tabelas da web, os crm_client_id são fornecidos por chave da web (td_canonical_id) a partir 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 afirmar que as visitas à página da web com o mesmo ID de cookie do formulário enviado também pertencem ao cliente identificado no CRM.
FROM web_page_visits t
LEFT JOIN master_table d
ON t.td_canonical_id = d.td_canonical_id
AND d.rn_web_key = 1
rn_web_key é definido da seguinte forma:
particionado por td_canonical_id
ordenado por match_score,
time desc) como rn_web_key
Sua função é evitar a criação de registros duplicados na tabela de destino, uma vez que todas as tabelas da web possuem relações muitos-para-muitos. Além disso, ela compartilha o crm_client_id com o perfil que apresenta a melhor correspondência entre data offline e online. Para cada td_canonical_id, ela seleciona aquele com a pontuação de correspondência mais alta e, caso a pontuação seja igual, a entrada mais recente.
Criar audience que contenha os perfis de todas as tabelas
Agora que todas as tabelas possuem um ID de perfil, é hora de criar um Segmento Mestre. O Segmento Mestre (Segmento Pai) é um recurso do Treasure Data unifica todas as informações relativas ao usuário, incluindo sua interação com o site e o produto. Ele permite que analistas de negócios, profissionais de marketing e outros usuários visualizem no Audience todos os perfis identificados e não identificados e criem diversos segmentos com eles, sem precisar escrever nenhuma consulta SQL.
Para criar um Segmento Mestre, precisamos de uma audience que será usada para unir todas as tabelas de atributos e comportamentos. O objetivo da audience é reunir todos os perfis — online e offline. E ela conterá apenas o profile_id, já que isso deve ser suficiente para unificá-la com 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 o campo profile_id e a deduplicação de todos os valores de profile_id.
