Creación de un CDP personalizado y enriquecimiento de datos de eventos con GTM del lado del servidor

Antes de realizar una compra, los clientes interactúan con las marcas a través de diversos canales, tanto online como offline. Esto puede dificultar que los especialistas en marketing y analítica lleven el seguimiento de estas interacciones en un solo lugar. Las herramientas estándar como Google Analytics o el seguimiento de Matomo del lado del servidor a menudo no pueden rastrear eventos offline. Para solucionar este problema, se suelen utilizar plataformas de datos de clientes (CDP). 

Una forma de utilizar una CDP es adquirir una herramienta prediseñada, lo que puede resultar costoso. Otra opción es crear su propia CDP. En este artículo de blog, mostraremos cómo crear una versión sencilla de una CDP utilizando Google Tag Manager del servidor y una base de datos. 

Esta configuración le permite unificar toda la información de sus clientes en un solo lugar, facilitando su comprensión y permitiéndole interactuar con ellos de forma más eficaz. Tanto si acaba de iniciarse en el seguimiento como si es un especialista con experiencia, esta guía puede ayudarle a crear una CDP que mejore notablemente la forma en que gestiona los datos de los clientes.

El contenedor de Google Tag Manager del lado del servidor recibirá solicitudes sobre todas las interacciones de los usuarios, ya sean online u offline. Puede utilizar clientes estándar como GA4 o Data Client para recibir eventos online desde el GTM web. Para recuperar eventos offline, puede utilizar webhooks. Más adelante en el artículo, mostraré cómo enviar y depurar datos de webhooks dentro de sGTM.

Sin importar el tipo de datos que reciba sGTM, los almacenará en la base de datos. Existen varias bases de datos con las que se puede integrar sGTM, por ejemplo, Firebase, Supabase (mucho más económica que Firestore) o Data Store. Aquí utilizaré Stape Data Store, ya que es una funcionalidad integrada en Stape y gratuita para los clientes de pago de Stape (planes Pro o superiores).

Además de sGTM y Store, también utilizaremos un identificador único de usuario, lo que ayudará a almacenar los datos de un usuario en el mismo documento. 

1. Fuente de datos (CRM, SDK, CMS, aplicación móvil, sitio web, etc.).

2. Contenedor de GTM del lado del servidor.

3. Base de datos (en esta guía utilizaré Data Store. También puede utilizar Firestore o Supabase, para la cual Stape creó la etiqueta Supabase Writer).

4. Para leer/escribir datos desde la base de datos se pueden utilizar estas plantillas de sGTM:

• Etiqueta Stape Store Writer
• Variable Stape Store Lookup
• Variable Stape reStore
• Etiqueta Firestore Writer (en caso de utilizar Firestore)
• Variable Firestore reStore
• Etiqueta Supabase Writer (en caso de utilizar Supabase)
• Variable Supabase Lookup

5. Identificadores únicos de usuario. En esta guía, utilizaré un User ID único o el ID de usuario de WordPress que genera el plugin de WordPress de Stape. 

Así es como fluyen los datos de los usuarios desde la fuente de datos (CRM) hasta la CDP:

1. 1.
   Cada vez que un usuario realiza una compra, el CRM envía un webhook a sGTM. 
2. 2.
   Data Client en sGTM procesa la solicitud entrante en sGTM y la mapea al formato de sGTM. 
3. 3.
   En el contenedor de GTM del lado del servidor, utilizamos la variable reStore para identificar si el usuario que realizó la compra ya existe en la base de datos. Si el usuario existe, comprobamos si la solicitud contiene nueva información del usuario y luego fusionamos los datos más recientes con los de la base de datos. Después de eso, escribimos la información enriquecida. Si el usuario no existe, simplemente creamos un nuevo registro de cliente. 
4. 4.
   Fusione los datos del usuario de la solicitud entrante con los datos del usuario en la base de datos. Por ejemplo, si falta el parámetro city en el webhook del CRM y no existe el campo city, este campo se tomará de Store. Si las solicitudes entrantes tienen el campo city pero Store no lo tiene, o es diferente, los datos de la solicitud para este campo se escribirán en Store.
5. 5.
   Utilice un perfil de cliente completo para enviarlo al proveedor a través de una conexión de servidor a servidor.

1. 1.
   Sitio web. Las dos formas más populares de enviar datos desde el sitio web a sGTM son configurando GA4 del lado del servidor y Data Tag.
2. 2.
   Webhooks de CRM (Hubspot, SalesForce, Jira, etc.).
3. 3.
   CMS. Puede utilizar los plugins de seguimiento del lado del servidor para Shopify, WordPress o Magento 2 Google Tag Manager para enviar webhooks de reembolsos y compras a sGTM.
4. 4.
   SDK y aplicación móvil. Stape ha creado SDK para iOS, Android, PHP SDK y Node.js SDK.
5. 5.
   Procesadores de pago (Stripe, Braintree, etc.).

El método para recibir datos depende de cómo los envíe a sGTM. Estas son las tres formas de obtener datos:

1. 1.
   Cliente de GA4. Funciona si utiliza GA4 para enviar datos a sGTM.
2. 2.
   Cliente de Measurement Protocol. Se puede utilizar para controlar el tipo de solicitud enviada a sGTM y adaptarla al estándar de Measurement Protocol. Por lo general, se trata del código de su aplicación.
3. 3.
   Data Client. Se puede utilizar cuando usted no controla las solicitudes entrantes, ya que en Data Client puede modificar la ruta de la solicitud, por ejemplo, en un webhook de Stripe.

Esta es la parte más compleja y crucial. Para crear una CDP adecuada, debe contar con datos precisos sobre los usuarios y sus acciones con su marca. La CDP debe contener información actualizada y datos claros y no duplicados. Necesita un User ID adecuado para construir este sistema de perfiles de usuario. 

Para los usuarios identificados, puede utilizar un correo electrónico o un ID interno que pueda emplearse en diferentes sistemas. Si un usuario no está identificado, puede ser un Stape User ID que consiste en un hash de:

• IP del cliente (IPv4/IPv6)
• User-Agent del navegador
• Ajustes de TLS del navegador
• Hostname

Si su marca gestiona varios dominios, también puede habilitar la opción Cross-domain ID en el power-up User ID. Esta genera un ID adicional (X-Stape-Cross-Domain-Id) a partir de las mismas señales pero sin el hostname, de modo que el mismo usuario no identificado obtiene un único ID en todos sus dominios conectados al contenedor del servidor. Esto ayuda a evitar perfiles duplicados en su CDP.

Si, por motivos de cumplimiento de la privacidad, desea que su User ID sea más exclusivo, puede añadir una variable dependiente. Puede ser un día, mes, semana o año. Todo depende de cuán exclusivo deba ser el ID. 

Utilizaremos la variable reStore o la etiqueta Stape Store Writer y Stape Store Lookup para fusionar y unificar los perfiles de usuario a partir de las solicitudes y la base de datos. También hay copias de estas plantillas disponibles en el GitHub de Stape.

La etiqueta Writer y las variables Lookup son bastante autoexplicativas. Estas dos plantillas le permiten escribir y leer datos desde Data Store. 

La variable reStore identificará primero si el usuario existe en la base de datos. Al principio, la variable obtiene todos los identificadores de usuario de nuestro evento (correo electrónico, teléfono o ID de cliente). Luego, envía una consulta a Store para seleccionar a los clientes que tienen uno de dichos identificadores. Si hay información sobre el cliente en la base de datos, devolverá los datos sobre este cliente.

Cuando una variable obtiene la respuesta del Store, la fusiona con una solicitud entrante. Por ejemplo, si no existe el campo city, se utilizará este campo del Store. Si las solicitudes entrantes tienen un campo city pero el Store no lo tiene, o es diferente, los datos de la solicitud para este campo se escribirán en el Store. Esta variable crea una nueva entidad si un cliente se encuentra parcialmente en el Store.

Una vez que los datos en sGTM se procesan y se formatean en el formato de sGTM, puede utilizarlos para enviarlos a cualquier proveedor que desee, como Meta, TikTok, Google Ads o Analytics. Tenga en cuenta los datos de usuario que se envían en las solicitudes. 

La depuración en sGTM es difícil, pero los eventos offline pueden ser aún más complejos. Analizaremos cómo utilizar lo siguiente:

• Depurador de sGTM
• Registros de acceso/solicitud/respuesta de Stape
• Etiqueta Logger
• Preview Header de sGTM

Presentaré dos casos de uso para demostrar cómo se puede utilizar Data Store. Hemos comprobado que estos son los escenarios más populares para los clientes de Stape.

1. Configure User ID. Utilizaré el power-up User ID de Stape, que ayudará a fusionar usuarios con clientes.

a. Inicie sesión en su cuenta de Stape y active el power-up. Para hacerlo, abra el contenedor de sGTM, haga clic en la pestaña Power up, abra User ID, active el interruptor y guarde los cambios.

b. En el contenedor de Server GTM, cree una variable que recupere el User ID de las cabeceras de la solicitud en el servidor.

2. Escriba datos en la base de datos en el evento purchase. Asegúrese de añadir un Stape User ID a los datos del evento. 

a. Añada una etiqueta Stape store writer a la galería de plantillas de sGTM (descárguela de GitHub e impórtela en la sección de plantillas de etiquetas de sGTM) y cree una etiqueta para escribir los datos del evento en un evento purchase. Escribo todos los datos del evento y añado un Stape User ID al registro del almacén. Lo necesitaremos para fusionar usuarios en un evento pageview.

b. Si la etiqueta funcionó correctamente, verá un registro en su base de datos similar al de la captura de pantalla que aparece a continuación.

3. Enriquezca los datos del evento de vista de página con los datos almacenados en Data Store.

a. Para unificar los usuarios del evento de vista de página y el que almacenamos en la base de datos, utilizaremos de nuevo el User ID de Stape y la variable de consulta Stape Store Lookup que puede recuperar datos del almacenamiento. Añada la variable Stape Store Lookup a la galería de plantillas de variables de sGTM. Para descargar la plantilla desde GitHub, vaya a la sección de plantillas de sGTM. Haga clic en New en la sección de variables y luego en Import.

b. Cree la variable Stape Store Lookup para los parámetros que desee restaurar: ad document path y path name. 

c. Añada una variable de consulta a la etiqueta de vista de página. 

4. Pruebe la configuración. Debería ver los datos de usuario enriquecidos en la etiqueta activada en el contenedor de sGTM. 

En este caso de uso, quiero enviar datos de eventos offline a una red publicitaria. Al enviar datos de conversión a la plataforma del anunciante, el elemento fundamental es enviar un click ID. El click ID es un identificador que se añade a la URL o a las cookies cuando el usuario hace clic en el enlace publicitario. Con la ayuda del click ID, la red publicitaria puede atribuir fácilmente la conversión a la campaña publicitaria. 

Los Click ID están disponibles para todos los eventos web, pero si desea utilizar datos de conversión del CRM o CMS para enviarlos a la red publicitaria, en la mayoría de los casos los Click ID no están disponibles.

Para configurar esta opción, utilizaré la variable de restauración de Stape para escribir datos en el Data Store en pageview y restaurar datos en los eventos purchase. Además de eso, necesitaré una transformación en el contenedor de sGTM para enriquecer el evento enviado a Facebook. Otro elemento crítico es hacer coincidir a los usuarios de los eventos pageview con los usuarios de los webhooks de compras offline. Para hacerlo, debe utilizar un identificador de usuario que permanezca igual en los eventos web pageview y en las compras offline. 

Con los CMS estándar, esto es fácil de lograr porque suelen tener este tipo de identificador en las cookies. Deberá pedir a los desarrolladores que agreguen estos parámetros en sitios web personalizados. Mi configuración se realiza en un sitio de WordPress. El plugin de WordPress de Stape envía un User ID único en los eventos web y lo agrega al webhook. Con este User ID, puedo hacer coincidir a los usuarios en los webhooks de pageview y purchase en la base de datos. 

1. Reciba el webhook de compra desde la fuente de datos offline dentro de sGTM. 

a. Envíe un webhook desde el CRM. Para esto utilizaré la aplicación de WordPress de Stape. Vaya a la pestaña Webhooks y agregue la Server GTM container URL. Este es el dominio que utiliza para su contenedor de GTM del servidor. Recomendamos configurar un dominio personalizado dentro del dominio de su sitio web, ya que permitirá configurar cookies de origen. No olvide marcar las casillas de verificación. 

b. Agregue Data Client a las plantillas de clientes de sGTM y configúrelo para recuperar los webhooks que envía desde el CRM. Para hacerlo, cree una plantilla de Data Client y agregue una Webhook path.

c. Configure el power-up Preview Header config de sGTM en Stape para depurar los webhooks entrantes en sGTM. Vaya a la vista previa de sGTM, haga clic en los tres puntos de la esquina superior derecha y haga clic en Send requests manually. Copie el encabezado HTTP X-Gtm-Server-Preview y péguelo en el power-up Preview Header config de sGTM.

d. Abra el depurador de sGTM y compruebe que haya recibido webhooks. Una vez que se active el webhook, debería ver la solicitud entrante dentro de sGTM y que el cliente de datos reclamó dicha solicitud.

2. Escriba los parámetros fbc, fbp y client ID del evento pageview en la base de datos.

En este paso, le mostraré cómo escribir los parámetros fbc y fbp en la base de datos utilizando la variable reStore. Para hacerlo, utilizaremos una etiqueta de pageview de Facebook para activar eventos pageview y una transformación que escribirá datos en el almacén utilizando la variable restore.

a. Añada una variable restore a las variables de sGTM mediante este enlace. Deberá descargarla de GitHub, crear una nueva plantilla de variable en sGTM y hacer clic en Importar.

b. Configure la variable restore. Debe utilizar un User ID de WordPress y un identificador, y escribir fbp, fbc y el User ID de WordPress en el almacén.

c. Cree una transformación que enriquezca los datos de eventos en los eventos pageview de Facebook utilizando la variable restore y añada esta transformación a su etiqueta de pageview de FB.

d. Pruebe la configuración. Si todo está configurado correctamente, debería ver los datos registrados en el Data Store. 

e. Configure un evento purchase de Facebook que se active cada vez que se reciba un webhook. Para enriquecer este evento con los datos del Data Store, necesitaríamos utilizar una transformación y la misma variable de restauración que usamos para la transformación en un evento pageview de FB. Esto extraerá el parámetro requerido en un evento purchase. No obstante, para enviar los datos en el formato que Facebook reconozca, necesitaremos usar una variable extractora de objetos que extraiga el objeto requerido de la variable de restauración.

f. Pruebe su configuración. Si todo funciona correctamente, debería ver que los parámetros fbc y fbp se enviaron con éxito a Facebook o en un evento offline de purchase.

Con la ayuda de Data Store, puede crear una base de datos de clientes o una CDP. Proporciona una forma sencilla de recopilar y almacenar toda la información que pueda obtener de sus clientes, lo que puede ayudarle a crear mejores formularios de analítica o a mejorar los resultados de sus campañas de pago. Ampliar y enriquecer los datos de sus clientes puede ayudarle a obtener información valiosa sobre su comportamiento y preferencias, lo que a su vez le ayudará a mejorar sus estrategias de marketing.