Autor
En este artículo explicamos los retos de la conciliación de ID y demostramos nuestro enfoque para crear un ID de perfil unificado en la plataforma de clientes Data , concretamente en Treasure Data.
Data se recopiló a partir de un almacén fuera de línea Data y del rastreo de sitios web en línea.
Cliente Data Plataforma
Customer Data Platform (CDP) permite a las empresas recopilar, gestionar y analizar la información de los clientes data procedente de diversas fuentes de forma unificada y centralizada. El objetivo de una CDP es crear una visión completa y coherente de cada cliente mediante la agregación de data desde múltiples puntos de contacto, como sitios web, aplicaciones móviles, redes sociales, interacciones por correo electrónico, etc.
Tesoro Data
Treasure Data es una plataforma de atención al cliente basada en la nube Data . Estos son algunos casos de uso empresarial comunes para Treasure Data:
Conciliación ID
La conciliación de documentos de identidad es un proceso en el que data relacionados con una persona se comparan y cotejan en diferentes sistemas o bases de datos para garantizar la exactitud, coherencia y una visión unificada de esa persona.
Esto es especialmente importante en situaciones en las que varios sistemas o fuentes de data almacenan información sobre las mismas personas, pero data puede ser incompleta o incoherente.
El reto de la conciliación de la identificación
La conciliación de documentos de identidad se enfrenta a numerosos retos, especialmente con conjuntos de datos extensos y fuentes de información diversas. Estos retos incluyen formatos incoherentes en data , problemas de calidad que conducen a falsas coincidencias y la gestión de registros duplicados resultantes de errores o cambios en el sistema. El principal problema es la falta de un identificador único que represente al usuario en las distintas fuentes de información, tablas y bases de datos.
Las organizaciones afrontan estos retos invirtiendo en herramientas avanzadas de data como Treasure Data.
Aplicación de la conciliación de documentos de identidad
Hemos implementado la reconciliación de ID para uno de nuestros clientes utilizando la funcionalidad de unificación de Treasure Data . En este artículo queremos compartir nuestro enfoque y lógica de implementación.
Condiciones dadas: en las bases de datos CDP se disponía de tablas con información sobre el recorrido del usuario en el sitio web, así como de información sobre los clientes procedente de la base de datos CRM (Customer Relationship Management) en el almacén data .
El objetivo es disponer de un identificador de perfil único en cada tabla CDP. Esto nos permitirá crear un segmento maestro con una visión de 360 grados sobre el cliente y su recorrido.
Online data disponible: vistas en páginas web, envíos de formularios en el sitio web, otra información específica del sitio web, como detalles de la página de productos que se almacenan en la tabla separada.
Disponible sin conexión data : CRM data del almacén data .
Resumen de los pasos para crear un ID de perfil único:
Unificación de tablas web
Para unificar la web data aprovecharemos la capacidad de la funcionalidad de unificación de Treasure Data . Esto requiere definir las tablas de origen y las columnas que necesitan ser unificadas en una configuración con formato YAML. La guía paso a paso sobre cómo implementar la Unificación en Treasure Data puede encontrarse en la Documentación de Treasure Data .
Como resultado, crea un ID canónico en cada tabla que se utiliza en la unificación. El objetivo del ID canónico es crear un ID que represente a cada usuario web. Es útil cuando se aplica a la web data, donde es difícil identificar las sesiones de usuario y unificar la web data a través de diferentes sesiones.
Definimos que la identificación canónica se basa en las siguientes claves de fusión:
- nombre: td_canonical_id
merge_by_keys: [correo electrónico, teléfono, td_client_id] source_tables: [formulario_web_enviado, detalle_producto_web, visitas_página_web]
El orden de las claves de fusión define la prioridad. La primera clave de fusión identifica todas las páginas web data con el mismo correo electrónico (correos electrónicos proporcionados en el formulario web enviado en la página web) como del mismo usuario.
La segunda prioridad es el número de teléfono (facilitado por los visitantes del sitio web): data con el mismo número de teléfono también se identifica como del mismo usuario. La tercera prioridad es td_client_id - First-Party Cookie ID. El First-Party Cookie ID es persistente a través de los mismos dominios. Diferentes dominios tendrán diferentes td_client_id. Td_client_id cambia si el visitante del sitio web borra el navegador cookies.
El resultado de la unificación se muestra en los ejemplos siguientes.
Ejemplo 1: Treasure Data definió esas 3 entradas como el mismo ID de usuario (td_canonical_id), ya que tienen el mismo correo electrónico. Los diferentes números de teléfono no afectan al resultado porque hemos definido que el correo electrónico tiene mayor prioridad que el número de teléfono:
Ejemplo 2: cuando no se facilita el correo electrónico, el mismo número de teléfono representa el mismo ID de usuario (td_canonical_id):
Ejemplo 3: cuando no se definen campos de coincidencia de mayor prioridad, se utiliza el ID de cookie de la primera parte. Mismo td_client_id = mismo ID de usuario (td_canonical_id). Este tipo de visitantes no identificados sin ningún tipo de información personal identificable (PII) son comunes en las tablas de visitantes de sitios web. Td_client_id no es totalmente fiable ya que puede cambiar después de borrar las cookies, pero en ausencia de PII data, es la mejor opción que tenemos.
Si suponemos que sólo el envío de formularios en un sitio web contiene el correo electrónico y el formulario, ¿qué ocurre con las tablas en las que no hay ninguna IIP disponible, por ejemplo web_page_visits? Supongamos que las visitas al sitio web sólo tienen el ID de la cookie de origen - td_client_id. En el primer ejemplo, la tabla web_page_visits con esos td_client_id 'asd-123-qwe-456', 'zxc-234-ert-345' y '567-tyu-ghj-234' tendrá el td_canonical_id = 'abcd1234'. Dado que la tabla web_form_submitted ya ha definido que esos 3 identificadores de cookie pertenecen al mismo usuario, web_page_visits se basará en esta información en ausencia de correo electrónico o teléfono.
La misma lógica se aplica a otras tablas de la web data que no tienen PII data.
Crear tabla maestra que una online y offline data
Ahora que la web data está unificada entre sí, ha llegado el momento de unificar online (web) y offline data. Por offline data entendemos CRM data que contiene PII. De data en línea tomaremos el uso de PII data (correo electrónico, teléfono) en la tabla web_form_submitted.
En un caso ideal, los ingenieros de data pueden añadir una tabla CRM en un archivo yml de unificación, pero nos encontramos con un caso en el que la condición del cliente para unificar data online y offline era más compleja de lo que la unificación automática puede proporcionar. Por lo tanto, aquí confiamos en la potencia de SQL.
Realizamos FULL OUTER JOIN de tablas web con envío de formulario data y tablas CRM ON email o teléfono. Los nombres y apellidos no son únicos y, por tanto, no son fiables.
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)
También se aconseja definir una lógica para la puntuación de coincidencia, en caso de que se envíen varios formularios con el mismo correo electrónico o número de teléfono. Por ejemplo, los formularios web cuyos nombres y apellidos coincidan con los nombres de los clientes de CRM tienen mayor prioridad que los que no.
Enriquecer otras tablas con profile_id
En esta sección definimos el profile_id final que es único para cada usuario, identificado y no identificado.
En resumen, profile_id = COALESCE(crm_client_id, td_canonical_id).
Para las tablas web crm_client_id se proporcionan por clave web(td_canonical_id) de la tabla maestra creada en el paso 2. Es decir, si los usuarios envían un formulario en un sitio web e indican su correo electrónico o teléfono, podemos identificarlos en la base de datos de CRM como clientes conocidos (en caso de que ya sean clientes de Compañia). Como resultado, podemos decir que aquellas visitas a páginas web con el mismo ID de cookie que el formulario web enviado también pertenecen al cliente CRM identificado.
from visitas_página_web t
left join tabla_maestra d
on t.td_canonical_id = d.td_canonical_id
y d.rn_web_key = 1
rn_web_key se define como sigue:
partición por td_canonical_id
ordenado por match_score,
time desc) as rn_web_key
Su función es evitar que se produzcan duplicados en la tabla de destino, ya que todas las tablas web tienen relaciones de muchos a muchos. Además, comparte crm_client_id con el perfil que tiene la mejor coincidencia entre offline y online data. Para cada td_canonical_id toma el que tiene la mayor puntuación de coincidencia, y en caso de que la puntuación de coincidencia sea la misma, entonces la entrada más reciente.
Crear Audiencia tabla que contiene el perfil de todas las tablas
Ahora que todas las tablas tienen un id de perfil, es el momento de crear un Segmento Maestro. Segmento Maestro (Segmento Padre) es una característica de Treasure Data que unifica toda la información referente al usuario, incluyendo la interacción del usuario con el sitio web y el producto. Permite a los Analistas de Negocios, Mercadólogos y otros usuarios ver en Audiencia Studio todos los perfiles identificados y no identificados y crear varios segmentos con ellos sin escribir ninguna consulta SQL.
Para crear un Segmento Maestro necesitamos tener una tabla Audiencia que se utilizará para unir todas las tablas de atributos y comportamientos. El objetivo de la tabla Audiencia es tener todos los perfiles - online y offline. Y contendrá sólo profile_id, ya que debería ser suficiente para unirla con todas las demás tablas (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
La implementación es tan sencilla como la unión de todas las tablas que contienen profile_id, y la deduplicación de todos los profile_ids.
