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

class="img-responsive

O Treasure Data é uma plataforma Data de clientes baseada em nuvem. Aqui estão alguns casos comuns de uso comercial do Treasure Data:

  • Análise do cliente Data . O Treasure Data pode ser usado para agregar e analisar a interação com o cliente data. Isso ajuda as empresas a criar uma visão unificada do comportamento e das preferências dos clientes.

  • Marketing personalizado. Ao aproveitar as informações do cliente coletadas pelo Treasure Data, as empresas podem criar campanhas de marketing personalizadas. Isso inclui mensagens direcionadas, recomendações personalizadas e ofertas sob medida com base nos perfis individuais dos clientes.

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 data a partir do rastreamento de sites

  • Criar uma tabela mestra que contenha informações on-line e off-line data

  • Enriquecer outras tabelas com a ID do perfil

  • Crie a tabela audience que contém profile_ids de todas as tabelas para ter uma visão de 360 graus do cliente

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:

canonical_ids:
- 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:

class="img-responsive

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):

class="img-responsive

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.

class="img-responsive

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.

CREATE master_table AS
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.

  • O profile_id das tabelas da Web é o td_canonical_id, que tem uma relação de 1 para muitos, conforme mostrado nas tabelas de exemplo - várias linhas do site data podem estar relacionadas ao mesmo perfil.

  • Quando há uma correspondência entre o formulário da Web data e o cliente do CRM data, o profile_id da tabela da Web é o crm_client_id.

  • Para data on-line sem correspondência com data off-line, profile_id permanece td_canonical_id.

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.

Selecione COALESCE(d.crm_client_id, t.td_canonical_id) como profile_id, t.*
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:

row_number() over (
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.

class="img-responsive

Blog do Medium por Artefact.

Este artigo foi publicado inicialmente no Medium.com.
Siga-nos em nosso blog no Medium!