Autor
En este artículo explicamos los retos que plantea la reconciliación de identificadores y mostramos nuestro enfoque para crear un identificador de perfil unificado en Data de clientes, concretamente en Treasure Data.
Data recopilaron a partir de un Data offline y del seguimiento online del sitio web.
Data de clientes
Data de clientes (CDP) permite a las empresas recopilar, gestionar y analizar data de los clientes data 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 data múltiples puntos de contacto, como sitios web, aplicaciones móviles, redes sociales, interacciones por correo electrónico y otros.
Treasure Data
Treasure Data una Data de clientes cloud. A continuación se presentan algunos casos de uso habituales de Treasure Data en el ámbito empresarial:
Conciliación de identificadores
La conciliación de identidades es un proceso en el que se comparan y cotejan data con una persona en diferentes sistemas o bases de datos para garantizar la precisión, la coherencia y una visión unificada de dicha persona.
Esto es especialmente importante en situaciones en las que varios sistemas o data almacenan información sobre las mismas personas, pero los data estar incompletos o ser incoherentes.
El reto de la conciliación de identificadores
La conciliación de identificadores se enfrenta a numerosos retos, especialmente cuando se trata de conjuntos de datos extensos y fuentes de información diversas. Entre estos retos se incluyen data inconsistentes, los problemas de calidad que dan lugar a coincidencias erróneas y la gestión de registros duplicados derivados de errores o cambios en el sistema. El principal reto es la falta de un identificador único que represente al usuario en las diferentes fuentes de información, tablas y bases de datos.
Las organizaciones hacen frente a estos retos invirtiendo en data avanzadas como Treasure Data.
Implementación de la conciliación de identificadores
Hemos implementado la conciliación de identificadores para uno de nuestros clientes utilizando la funcionalidad Data de Treasure Data . En este artículo queremos compartir nuestro enfoque y la lógica de implementación.
Condiciones dadas: en las bases de datos de CDP había tablas disponibles con información sobre el recorrido del usuario en el sitio web, así como información de los clientes procedente de la base de datos de CRM (gestión de relaciones con los clientes) en data .
El objetivo es disponer de un identificador de perfil único en cada tabla del CDP. Esto nos permitirá crear un segmento maestro con una visión de 360 grados del cliente y su recorrido.
data en línea: visitas a las páginas del sitio web, envíos de formularios en el sitio web y otra información específica del sitio web, como los detalles de las páginas de productos, que se almacenan en una tabla independiente.
data sin conexión: data de CRM data del data .
Resumen de los pasos para crear un identificador de perfil único:
Unificación de tablas web
Para unificar data web, data las capacidades de la función Data 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 consultar en Data Treasure Data .
Como resultado, se crea un identificador canónico en cada tabla que se utiliza en la unificación. El objetivo del identificador canónico es crear un identificador que represente a cada usuario web. Resulta útil cuando se aplica a data web, donde resulta complicado identificar las sesiones de los usuarios y unificar data web data diferentes sesiones.
Hemos establecido que el ID canónico se basa en las siguientes claves de fusión:
– nombre: td_canonical_id
merge_by_keys: [email, phone, td_client_id] tablas_de_origen: [web_form_submitted, web_product_detail, web_page_visits]
El orden de las claves de fusión determina la prioridad. La primera clave de fusión identifica todos data web data el mismo correo electrónico (correos electrónicos facilitados en el formulario web enviado a través del sitio web) como pertenecientes al mismo usuario.
La segunda prioridad es el número de teléfono (facilitado por los visitantes en el sitio web): data el mismo número de teléfono también se identifican como pertenecientes al mismo usuario. La tercera prioridad es td_client_id, el identificador First-Party . El identificador First-Party se mantiene en los mismos dominios. Cada dominio tendrá un td_client_id diferente. El td_client_id cambia si el visitante del sitio web borra las cookies del navegador.
El resultado de la unificación se muestra en los ejemplos siguientes.
Ejemplo 1: Treasure Data esas tres entradas como el mismo ID de usuario (td_canonical_id), ya que tienen el mismo correo electrónico. Los números de teléfono diferentes no afectan al resultado porque hemos establecido que el correo electrónico tiene mayor prioridad que el número de teléfono:
Ejemplo 2: cuando no se proporciona una dirección de correo electrónico, un mismo número de teléfono corresponde a un mismo ID de usuario (td_canonical_id):
Ejemplo 3: cuando no se definen campos de coincidencia de mayor prioridad, se utiliza el identificador de la cookie de origen. Un mismo td_client_id equivale a un mismo identificador de usuario (td_canonical_id). Estos visitantes no identificados, que carecen de cualquier información de identificación personal (PII), son habituales en las tablas de visitantes de los sitios web. El td_client_id no es totalmente fiable, ya que puede cambiar tras el borrado de las cookies, pero, a falta de data PII, es la mejor opción de la que disponemos.
Si partimos de la base de que solo el envío de formularios en un sitio web contiene direcciones de correo electrónico y datos de formulario, ¿qué ocurre entonces con las tablas en las que no hay información de identificación personal (PII), como por ejemplo «web_page_visits»? Supongamos que las visitas al sitio web solo cuentan con el identificador First-Party — 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 ID 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 data web que no contienen data de identificación personal.
Crear una tabla maestra que combine data en línea y fuera de línea
Ahora que data web data unificados entre sí, es el momento de unificar data online (web) y offline. Por data offline data referimos a data de CRM data contienen información de identificación personal (PII). De data online, data data de identificación personal data correo electrónico, teléfono) de la tabla «web_form_submitted».
En un caso ideal, data pueden añadir una tabla de CRM a un archivo YML de unificación, pero nos encontramos con un caso en el que los requisitos del cliente para unificar data online y offline data más complejos de lo que permite la unificación automática. Por eso, en este caso recurrimos al potencial de SQL.
Hemos realizado una unión externa completa (FULL OUTER JOIN) entre las tablas web con data de los formularios enviados data las tablas del CRM en función del correo electrónico o el teléfono. Los nombres y apellidos no son únicos y, por lo 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 recomienda 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 en los que el nombre y los apellidos coincidan con los nombres de los clientes del CRM tienen mayor prioridad que aquellos en los que no es así.
Actualizar otras tablas con el «profile_id»
En esta sección definimos el «profile_id» definitivo, que es único para cada usuario, tanto si está identificado como si no.
En resumen, profile_id = COALESCE(crm_client_id, td_canonical_id).
En las tablas web, los crm_client_id se proporcionan por clave web (td_canonical_id) a partir de la tabla maestra creada en el paso 2. Es decir, si los usuarios envían un formulario en un sitio web y facilitan su correo electrónico o número de teléfono, podemos identificarlos en la base de datos CRM como clientes conocidos (en caso de que ya sean clientes de la Compañia). Como resultado, podemos afirmar que aquellas visitas a la página web con el mismo ID de cookie que el formulario web enviado también pertenecen al cliente identificado en el 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 se define de la siguiente manera:
partition by td_canonical_id
order by match_score,
time desc) as rn_web_key
Su función es evitar que se generen duplicados en la tabla de destino, ya que todas las tablas web tienen relaciones «muchos a muchos». Además, comparte el crm_client_id con el perfil que presenta la mejor coincidencia entre data offline y online. Para cada td_canonical_id, se elige aquel con la puntuación de coincidencia más alta y, en caso de que la puntuación sea la misma, se selecciona la entrada más reciente.
Crea Audiencia que contenga los perfiles de todas las tablas
Ahora que todas las tablas tienen un identificador de perfil, es el momento de crear un segmento maestro. El segmento maestro (segmento principal) es una función de Treasure Data unifica toda la información relativa al usuario, incluida su interacción con el sitio web y el producto. Permite a los analistas de negocio, los profesionales del marketing y otros usuarios ver en Audiencia todos los perfiles identificados y no identificados, y crear diversos segmentos con ellos sin necesidad de escribir consultas SQL.
Para crear un segmento maestro, necesitamos disponer de una Audiencia que se utilizará para realizar uniones con todas las tablas de atributos y comportamientos. El objetivo de la Audiencia es reunir todos los perfiles, tanto online como offline. Además, solo contendrá el «profile_id», ya que este debería ser suficiente para realizar uniones con todas las demás tablas (crm_user_table, web_page_visits, web_form_submitted, web_product_detail).
La implementación consiste simplemente en unir todas las tablas que contienen el campo «profile_id» y eliminar los duplicados de todos los «profile_id».
