Autor
En este artículo explicamos los retos que plantea la conciliación de identificadores y mostramos nuestro enfoque para crear un identificador de perfil unificado en la plataforma Customer Data, concretamente...
Data se recopiló a partir de un Almacén Data fuera de línea y del seguimiento de un sitio web en línea.
Cliente Plataforma Data
La Plataforma de Clientes Data (CDP) permite a las empresas recopilar, gestionar y analizar data de clientes procedentes de diversas fuentes de forma unificada y centralizada. La objetivo de un CDP es crear una visión global y cohesionada de cada cliente agregando data de 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 para clientes Data basada en cloud. He aquí algunos casos de uso empresarial habituales para Treasure Data:
Conciliación ID
La conciliación de identificaciones es un proceso en el que se comparan y cotejan data relacionados con una persona en diferentes sistemas o bases data para garantizar la exactitud, la coherencia y una visión unificada de esa persona.
Esto es especialmente importante en escenarios en los que múltiples sistemas o fuentes data almacenan información sobre los mismos individuos, pero la 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 data extensos y fuentes de información diversas. Estos retos incluyen formatos data incoherentes, problemas de calidad que conducen a falsas coincidencias y la gestión de registros duplicados resultantes de errores o cambios en el sistema. El reto clave es la falta de una identificación única representando al usuario a través de las diferentes fuentes de información, tablas y databases.
Las organizaciones afrontan estos retos invirtiendo en herramientas avanzadas data como Treasure Data.
Aplicación de la conciliación de la identificación
Hemos implementado la conciliació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 CDP databases 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 CRM (Customer Relationship Management) database en dataalmacén.
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.
data en línea disponible: visualizaciones en las páginas del sitio web, envíos de formularios en el sitio web, otra información específica del sitio web, como los detalles de las páginas de productos que se almacenan en la tabla separada.
data fuera de línea disponible: 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. Para ello es necesario definir las tablas de origen y las columnas que deben unificarse 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 Tesoro Data Documentación.
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 para la web data, donde es un reto 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 web data con el mismo correo electrónico (correos electrónicos facilitados en el formulario web enviado en el sitio web) como del mismo usuario.
La segunda prioridad es número de teléfono (enviados por los visitantes de la página 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 - ID de cookie de primera parte. 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: El Tesoro 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 facilite el correo electrónico, lo 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 ninguna Información de Identificación Personal (PII) son comunes en las tablas de visitantes de sitios web. Td_client_id no es totalmente fiable, ya que puede cambiar tras el borrado de cookies, pero en ausencia de PII data, es la mejor baza 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 se dispone de IIP, por ejemplo visitas_página_web? Supongamos que las visitas al sitio web sólo tienen el ID de cookie de primera parte - td_client_id. En el primer ejemplo visitas_página_web tabla 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 web_form_submitted La tabla ya ha definido que esos 3 identificadores de cookie pertenecen al mismo usuario, visitas_página_web se basará en esta información en ausencia de correo electrónico o teléfono.
La misma lógica se aplica a otras tablas web data que no tienen PII data.
Crear tabla maestra que una online y offline data
Ahora que la data web está unificada entre sí, ha llegado el momento de unificar la data online (web) y offline. Por data offline nos referimos al data CRM que contiene PII. De online data tomaremos el uso de PII data (email, 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. Así que 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.teléfono = d.teléfono)
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 cuyo nombre y apellidos coincidan con los nombres de los clientes del CRM tendrán mayor prioridad que los que no coincidan.
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 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 enviaron un formulario en una página web y facilitaron su correo electrónico o teléfono, podemos identificarlos en la base data del CRM como clientes conocidos (en caso de que ya sean clientes de la empresa). 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
ordenar por puntuación_del_partido,
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 tenga 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.
Cree la tabla audience 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 principal (segmento matriz) es una función de Treasure Data que unifica toda la información relativa al usuario, incluida la interacción de éste con el sitio web y el producto. Permite a los analistas de negocio, a los responsables de marketing y a otros usuarios ver en Audience Studio todos los perfiles identificados y no identificados y crear diversos segmentos con ellos sin necesidad de escribir ninguna consulta SQL.
Para crear un segmento maestro necesitamos disponer de una tabla audience que se utilizará para unir todas las tablas de atributos y comportamientos. El objetivo de la tabla audience es tener todos los perfiles, en línea y fuera de línea. 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 contengan profile_id, y la deduplicación de todos los profile_ids.
