Seguimiento server-side de HubSpot: guía completa de configuración

Si gestionas el marketing o las ventas a través de HubSpot, la calidad de tus datos de clientes potenciales depende directamente del seguimiento que los alimenta. Y ese seguimiento tiene un problema: los navegadores se están volviendo en su contra.

Todo empieza con una sola cookie. El código de seguimiento estándar de HubSpot establece una cookie llamada «hubspotutk» para reconocer a los visitantes que vuelven y reconstruir el recorrido de un contacto antes incluso de que rellene un formulario. La función «Prevención inteligente de seguimiento» de Safari limita la duración de esa cookie a siete días cuando se establece mediante JavaScript, que es exactamente cómo la configura HubSpot por defecto. Los bloqueadores de anuncios y la configuración de privacidad estricta de Firefox, Edge y Safari van más allá. Bloquean directamente el script de HubSpot y sus formularios incrustados, dejando a veces nada más que un espacio en blanco donde antes estaba tu formulario de captación de clientes potenciales.

Nada de esto es un riesgo futuro. Ya está pasando en tu web, y es una de las principales razones por las que los informes de «Original Source» y de atribución multitoque de HubSpot se alejan más de la realidad de lo que la mayoría de los equipos creen.

El seguimiento server-side de HubSpot soluciona el problema de raíz. En lugar de que el navegador se conecte directamente a los puntos finales js.hs-scripts.com y hsforms.net de HubSpot, es tu propio servidor el que se encarga de la comunicación en nombre del contacto. Esta guía te explica paso a paso cómo configurar el seguimiento server-side para HubSpot usando Google Tag Manager y TAGGRS.

Ventajas del seguimiento server-side de HubSpot

Con el seguimiento del lado del cliente, el script de HubSpot se ejecuta dentro del navegador del visitante. Lee lo que necesita de la página, instala las cookies «hubspotutk» y «__hstc», y se conecta directamente a los servidores de HubSpot para registrar las visitas a la página, identificar a los visitantes y enviar formularios.

El seguimiento server-side traslada esa conexión a tu propio servidor. El navegador envía una solicitud a tu dominio (a través de un contenedor de servidor de Google Tag Manager) y tu servidor reenvía los datos pertinentes a la API de HubSpot mediante una conexión privada y autenticada. El navegador del visitante nunca se comunica con los dominios de HubSpot.

Los equivalentes del lado del servidor del script del lado del cliente de HubSpot son su API de objetos CRM para los contactos y su API de eventos de comportamiento personalizados para todo lo demás: interacciones con páginas, visualizaciones de productos, envíos de formularios personalizados... cualquier cosa que quieras vincular a un registro de contacto.

En pocas palabras, todo lo que hace hoy el script de HubSpot en el navegador tiene su equivalente server-side, así que no estás renunciando a ninguna funcionalidad al trasladarlo, solo estás cambiando el lugar donde se realiza el trabajo. Para un equipo de marketing, el resultado práctico es que los datos que alimentan tus listas, flujos de trabajo e informes llegan de forma más completa y ya no dependen de si el navegador de cada visitante ha colaborado o no.

Merece especialmente la pena configurar el seguimiento server-side si es en HubSpot donde tomas tus decisiones: puntuar clientes potenciales, activar flujos de trabajo, informar sobre la atribución a la dirección o optimizar la inversión publicitaria en función de los datos de contactos y oportunidades. Cuanto más peso le des a esos datos, más te costarán las lagunas.

¿Aún no estás acostumbrado a trabajar con Google Tag Manager? TAGGRS tiene guías que te explican lo básico antes de que empieces a usar HubSpot en concreto:

Por qué el seguimiento del lado del cliente no es fiable para los usuarios de HubSpot en este momento

No se trata de una observación general del tipo «los navegadores son muy estrictos últimamente». Hay unos cuantos cambios concretos y recientes que están afectando directamente al seguimiento de HubSpot, y cada uno de ellos está relacionado con un informe o un flujo de trabajo que ya utilizas habitualmente. A continuación te explicamos qué es lo que está provocando fallos en el seguimiento de HubSpot del lado del cliente y cuánto te cuesta cada uno de ellos.

La cookie de seguimiento tiene un límite de tiempo, y es la que más usa HubSpot. «hubspotutk» se guarda a través de «document.cookie», y las propias reglas de prevención de seguimiento de WebKit borran cualquier cookie establecida de esa forma al cabo de siete días sin visitas.

El límite se reduce a 24 horas específicamente cuando un visitante llega a tu web desde un dominio que Safari ha clasificado como «rastreador entre sitios», a través de un enlace que incluye parámetros de consulta, que es precisamente el patrón que se da en la mayoría de los clics en anuncios de pago. Un cliente potencial que investiga dos semanas antes de rellenar un formulario aparece como un visitante nuevo que visita la web por primera vez cuando finalmente se convierte, porque la cookie que vinculaba sus sesiones anteriores caducó días antes.

En el caso de una compra meditada, con un ciclo de investigación de varias semanas, esto es lo habitual. El canal que atrajo por primera vez a ese cliente potencial (a menudo uno caro, como la búsqueda de pago o un seminario web) no recibe ningún reconocimiento, mientras que lo que sea que haya escrito en la barra de direcciones el día de la conversión (normalmente «directo») se lleva todo el mérito. Multiplica eso por todo un trimestre y verás que tu informe de «Fuente original» sobrevalora el tráfico directo y orgánico, mientras que deja de lado a las campañas que realmente hicieron el trabajo.

Los bloqueadores de anuncios y la prevención de seguimiento del navegador bloquean el script, no solo la cookie. En el propio foro de la comunidad de HubSpot hay varios hilos abiertos sobre esto: la Protección mejorada contra el seguimiento de Firefox y la Prevención estricta del seguimiento de Edge bloquean las solicitudes a hsforms.net, lo que significa que hbspt.forms.create() nunca se ejecuta y los visitantes ven un cuadro vacío donde debería estar el formulario. Ni un mensaje de error, ni una alternativa. Normalmente, el visitante simplemente se va, y tú nunca llegas a saber que ese cliente potencial existió.

El bloqueo a nivel de navegador de Apple se está ampliando. Safari 27 añade el bloqueo de rangos de IP en la capa de red e incluye en su lista de scripts de huellas digitales plataformas de datos centralizadas (CDP) como Segment y Tealium. Si rediriges cualquier seguimiento destinado a HubSpot a través de una CDP, o mediante una etiqueta de script que Safari clasifica como herramienta de identificación digital, puedes perder el acceso a los datos de referencia y a los parámetros de consulta antes incluso de que lleguen a HubSpot.

En otras palabras, la información sobre «de dónde viene este contacto» se elimina en el navegador antes de que HubSpot pueda verla. Dado que más o menos uno de cada cuatro visitantes navega con Safari, eso supone que una parte importante, creciente y con una intención de compra especialmente alta de tu público queda oculta, precisamente los compradores de dispositivos Apple a los que muchas marcas B2B y de gama alta más quieren atribuir sus resultados.

El uso de bloqueadores de anuncios ya no es un problema de un nicho de mercado. Aproximadamente un tercio de los usuarios de Internet utiliza algún tipo de bloqueador de anuncios, y esa cifra no deja de crecer. En resumen, una parte importante de tu tráfico ni siquiera deja que se cargue el script de HubSpot.

Cómo el seguimiento del lado del cliente afecta a la atribución y a los datos de clientes potenciales de HubSpot

Las consecuencias se notan en los campos que usas realmente para llevar a cabo las campañas.

Las fuentes de tráfico «Original» y «Más reciente» se configuran a partir del historial de la sesión de la cookie de seguimiento. HubSpot intenta asociar un nuevo registro de contacto con cualquier actividad anónima registrada en la cookie de ese visitante. Cuando la cookie se reinicia antes de tiempo, esa actividad anterior se pierde, por lo que HubSpot no tiene nada con lo que hacer la asociación y establece la «Fuente original» en función de la sesión que esté activa en el momento en que se crea el registro de contacto, y no en la primera visita real del visitante.

Los informes de atribución que atribuyen a un canal la creación de un contacto o de una oportunidad se basan en el mismo historial de interacciones. Cuantas menos visitas a páginas y puntos de contacto se registren, más plana y menos útil será la atribución. Tu estrategia de marketing no ha dejado de funcionar. Es solo que HubSpot ya no la ve.

Los eventos de comportamiento personalizados y los eventos de comercio electrónico que se activan mediante JavaScript del lado del cliente heredan todos y cada uno de estos problemas. Si se bloquea el script, el evento nunca se activa. Cualquier flujo de trabajo o puntuación de cliente potencial que se base en ese evento se queda ahí, sin hacer nada, y sin que aparezca ningún error que te explique por qué.

Hay algo que sigue funcionando incluso con las cookies bloqueadas: los formularios de HubSpot pueden extraer los parámetros UTM directamente de la URL de la página actual en el momento del envío, así que la atribución a nivel de campaña de ese envío concreto suele mantenerse. Lo que no se conserva es todo aquello que depende de vincular ese envío a sesiones anteriores del visitante en las que se utilizaron cookies para el seguimiento.

¿Qué ventajas les ofrece el seguimiento server-side a los usuarios de HubSpot?

El seguimiento server-side cambia lo que puedes considerar fiable en HubSpot. Esto es lo que mejora una vez que la conexión pasa a tu propio servidor:

- Formularios que realmente se cargan, que es lo que más influye directamente en los ingresos de esta lista. Un formulario bloqueado es un cliente potencial que nunca ves y por el que nunca pagas dos veces. Una solicitud de formulario servida desde tu propio dominio, a través de tu servidor, no aparece en las mismas listas de bloqueo que hsforms.net, así que los visitantes con configuraciones de privacidad estrictas o bloqueadores de anuncios siguen viéndola y enviándola.

- Una cookie de seguimiento que dura más de una semana. Las cookies establecidas a través de un encabezado de respuesta HTTP no están sujetas al límite de siete días que Safari aplica a «hubspotutk» mediante JavaScript, pero solo si tu servidor supera la defensa independiente de WebKit contra el enmascaramiento de CNAME y direcciones IP, que también limita a siete días las cookies establecidas por HTTP cuando se activa.

Para sacarle todo el partido a esto, es necesario que tu servidor esté alojado en un subdominio propio auténtico con un rango de IP que coincida con el de tu sitio web principal, algo que se explica en la sección de configuración que viene a continuación. La forma más fiable de garantizar esa coincidencia es redirigir el contenedor de tu servidor a través de un Cloudflare Worker del mismo origen que tu sitio web principal, es decir, una ruta como tudominio.com/metrics en lugar de un subdominio independiente, ya que la comprobación de coincidencia de IP de Safari no se aplica en absoluto cuando todo es realmente del mismo origen.

- Una atribución que refleje lo que realmente está pasando. Se pierden menos sesiones por el camino, así que los informes de «Fuente original», «Última fuente» y «multitoque» se acercan más a la realidad. Esto es lo más importante a la hora de decidir tu presupuesto: una atribución que subestime los clientes potenciales de pago o orgánicos te lleva a recortar los canales que sí funcionan.

- Eventos de comportamiento personalizados fiables. Al enviar los eventos server-side a través de la API de HubSpot, un bloqueador de anuncios en el dispositivo del visitante no afecta a que el evento llegue a HubSpot.

- Más control sobre lo que envías. Tú decides exactamente qué campos se reenvían a HubSpot y cuándo, lo que hace que la minimización de datos y el cumplimiento del consentimiento sean una cuestión de configuración y no de suerte.

- Una página más ligera. Cuantos menos scripts del lado del cliente compitan por el hilo principal, menor será el impacto en el tiempo de carga, lo cual es importante tanto para la tasa de conversión como para los Core Web Vitals.

En conjunto, todo esto se traduce en un mayor número de clientes potenciales que ya estás consiguiendo y que llegan a HubSpot, correctamente atribuidos y listos para que tus flujos de trabajo e informes actúen en consecuencia.

Lo que necesitas antes de empezar

Configurar el seguimiento server-side para HubSpot no requiere volver a crear nada. La mayor parte solo hay que hacerla una vez, y es posible que ya tengas varios elementos si estás utilizando GA4 server-side.

Aquí tienes la lista completa de comprobación antes de crear cualquier etiqueta de HubSpot:

• Una cuenta de Google Tag Manager con un contenedor web y un contenedor de servidor. Si eres nuevo en GTM, empieza por la guía para principiantes.
  
• Una capa de datos operativa en tu sitio web o, como mínimo, una etiqueta de configuración de GA4 que envíe datos básicos de páginas y eventos al contenedor de tu servidor. La guía de configuración server-side de TAGGRS te explica paso a paso cómo poner en marcha esa conexión, ya que la mayoría de las etiquetas de HubSpot en el contenedor del servidor dependen de los datos que ya llegan hasta él por esta vía.
  
• Un contenedor de servidor TAGGRS, implementado con un subdominio propio en tu propio dominio. Crea una cuenta gratuita para empezar; el plan gratuito cubre hasta 10 000 solicitudes al mes, lo cual es suficiente para la mayoría de las configuraciones iniciales.
  
• Un token de acceso a una aplicación privada de HubSpot. HubSpot dejó de utilizar sus claves API antiguas el 30 de noviembre de 2022. Crea una app privada en «Configuración» > «Integraciones» > «Apps privadas», y concédele solo los ámbitos que realmente necesites: crm.objects.contacts.write y crm.objects.contacts.read para los registros de contactos, además de analytics.behavioral_events.send si vas a enviar ocurrencias de eventos de comportamiento personalizados. Si además quieres crear o editar definiciones de eventos a través de la API en lugar de la interfaz de usuario, eso requiere un ámbito distinto: behavioral_events.event_definitions.read_write. La guía de aplicaciones privadas de HubSpot explica los pasos exactos. Copia el token cuando se genere. HubSpot no te volverá a mostrar el valor completo.
  
• Si vas a enviar eventos de comportamiento personalizados, primero tienes que crear las definiciones de los eventos en HubSpot. HubSpot necesita que el evento y sus propiedades estén definidos antes de aceptar una ocurrencia enviada a través de la API. Puedes hacerlo a través de «Gestión de datos» > «Gestión de eventos» en la interfaz de usuario, o mediante la API de definiciones de eventos si prefieres programarlo.
  
• Una configuración de consentimiento que cubra el contenedor de tu servidor, no solo el banner propio de HubSpot. El banner de consentimiento integrado de HubSpot solo bloquea las cookies de HubSpot y las integraciones nativas de HubSpot. No tiene visibilidad sobre un contenedor de servidor GTM personalizado, así que necesitarás que tu plataforma de gestión del consentimiento envíe su señal directamente a GTM. Tanto la configuración del «Consent Mode» de TAGGRS como la guía de integración de CookieConfirm te muestran cómo funciona esa conexión en la práctica.

Paso a paso: cómo configurar el seguimiento server-side de HubSpot con Google Tag Manager

Aquí tienes el proceso completo, de principio a fin:

1. Implementa el contenedor de tu servidor TAGGRS y conéctalo a un subdominio de tu propio dominio (por ejemplo, measure.tudominio.com). Esto es lo que hace que las cookies establecidas por tu servidor se consideren de origen propio en lugar de de terceros.

2. Comprueba que tu capa de datos esté reenviando los datos al contenedor del servidor. La mayoría de las configuraciones lo hacen enviando un evento de configuración de GA4 desde el contenedor web; así, el contenedor del servidor tiene acceso a los mismos datos del evento para todas las etiquetas que crees a partir de él, incluida HubSpot.

3. Crea tu aplicación privada de HubSpot y copia el token de acceso. Guárdalo como una variable server-side de GTM, en lugar de como un valor fijo dentro de una etiqueta, para que luego puedas cambiarlo sin tener que editar todas las etiquetas que lo utilizan.

4. Añade una etiqueta al contenedor de tu servidor que llame a la API de HubSpot. Lo primero que tienes que hacer es buscar en la Template Gallery de la comunidad de Google Tag Manager si ya hay alguna etiqueta de servidor de HubSpot.

5. Configura la etiqueta «Crear o actualizar contacto». Esta es la que convierte el envío de un formulario en un registro de contacto. Como mínimo, asigna una variable de correo electrónico de contacto de tu capa de datos a la solicitud, ya que HubSpot utiliza el correo electrónico para decidir si crea un nuevo contacto o actualiza uno ya existente.

A continuación, añade las propiedades personalizadas que quieras que se registren (detalles de la fuente del cliente potencial, ruta de la página, nombre del formulario) como campos adicionales en el mismo cuerpo de la solicitud. Lo que asignes aquí es lo que verán tu equipo de ventas y tus informes, así que merece la pena asignar más de lo estrictamente necesario mientras estás en ello.

6. Configura el seguimiento de eventos de comportamiento personalizados, si lo necesitas. Asigna el nombre del evento y sus propiedades para que coincidan exactamente con lo que definiste en HubSpot en el paso de configuración anterior. Los nombres tienen que coincidir con el nombre interno que generó HubSpot, no con la etiqueta que se muestra; de lo contrario, el evento será rechazado.

7. Añade desencadenantes para cada etiqueta. Una etiqueta de «creación de contacto» suele activarse cuando se envía un formulario que ya está en tu capa de datos. Una etiqueta de evento de comportamiento se activa con cualquier evento personalizado que estés rastreando (una visita a la página de precios, un vídeo visto hasta el final, un «añadir al carrito» en una integración de comercio conectada a HubSpot).

8. Prueba todo en el modo de vista previa de GTM, con la vista previa activa a la vez tanto en el contenedor web como en el del servidor. La guía de pruebas de TAGGRS explica cómo interpretar el flujo de solicitudes entre ambos. Envía un formulario de prueba real y comprueba que el contacto aparece (o se actualiza) en HubSpot; después, activa un evento de comportamiento de prueba y comprueba que aparece en la cronología del contacto.

9. Deja la nueva configuración funcionando junto con tu código de seguimiento actual de HubSpot durante un breve periodo de tiempo, en lugar de eliminarlo de inmediato. Así podrás comparar el volumen de creación de contactos y de eventos antes de realizar la transición completa, y te protegerá en caso de que algo esté mal configurado en la nueva configuración.

10. Publica tu servidor y tus contenedores web en cuanto veas que las pruebas salen bien.

Una vez publicado, el cambio se aplica de inmediato para todos los visitantes, y los datos empiezan a pasar por tu propio dominio a partir del siguiente envío de formulario. A partir de ahí, el trabajo que queda consiste simplemente en mantener las etiquetas y las reglas de consentimiento. Ya no tendrás que solucionar problemas con un script del lado del cliente cada vez que un navegador cambie sus normas de privacidad.

Errores comunes que hay que evitar

Cuando algo falla en la configuración server-side de HubSpot, normalmente no aparece ningún error. Parece que las etiquetas funcionan, pero los datos o bien no llegan a HubSpot o bien llegan mal, así que el problema suele pasar desapercibido hasta que ves que un informe no cuadra. Estos son los errores que suelen causarlo con más frecuencia:

• Enviar eventos de comportamiento personalizados antes de definirlos en HubSpot. HubSpot rechaza cualquier evento que no reconozca ya, así que la etiqueta se activa, no se registra nada y no hay ningún error evidente que te ayude a identificar la causa. Define siempre primero el evento y sus propiedades en HubSpot.
• Faltan ámbitos o son incorrectos en el token de la aplicación privada. Un token sin el ámbito adecuado no da un error evidente. La etiqueta aparece como «disparada», mientras que HubSpot rechaza la solicitud de forma silenciosa, por lo que los contactos o eventos nunca aparecen. Comprueba el código de respuesta real en el modo de vista previa del contenedor del servidor, en lugar de fiarte del estado «disparada».
• No hay ningún correo electrónico del visitante disponible cuando se activa la etiqueta. El correo electrónico es lo que le dice a HubSpot si debe actualizar un contacto ya existente o crear uno nuevo. Sin él, la llamada o bien falla directamente o bien genera un contacto duplicado sin nada con lo que compararlo, lo que, con el tiempo, va contaminando tu base de datos sin que te des cuenta. Asegúrate de que la variable del correo electrónico esté rellenada antes de que se ejecute la etiqueta.
• Estás ejecutando los sistemas de seguimiento antiguo y nuevo en paralelo sin un plan de limpieza. Es buena idea tener ambas en marcha durante unas semanas para compararlas, pero si las dos siguen creando contactos y eventos sin parar, acabarás contando dos veces los mismos datos e inflando todos los informes basados en ellos. Decide desde el principio cuál de las dos configuraciones es tu fuente de referencia y desactiva la otra en cuanto confíes en las cifras.
• Suponiendo que la cookie del lado del servidor supere automáticamente el límite de siete días. Esto solo funciona si tu subdominio no apunta (mediante un CNAME de DNS) a un dominio de terceros y el rango de IP de tu servidor coincide con el de tu sitio web principal. Si no cumples alguna de estas condiciones, Safari volverá a aplicar el mismo límite de siete días del que intentabas librarte server-side, así que te quedarás con todo el trabajo de configuración y sin ningún beneficio en cuanto a la atribución. El enrutamiento a través de una configuración de Cloudflare Workers del mismo origen es la forma más fiable de garantizar la coincidencia.
• Enviar datos personales antes de comprobar si hay consentimiento. El server-side te da más control sobre lo que envías, pero solo si realmente incorporas la comprobación del consentimiento en las condiciones de activación de cada etiqueta. La arquitectura no te obliga a obtener el consentimiento por ti, y dar por hecho que sí lo hace es la forma en que una configuración segura en materia de privacidad se convierte, sin que te des cuenta, en una que incumple la normativa.
• No hay capa de datos, o es inconsistente. Todas las etiquetas de aquí dependen de que los datos lleguen al contenedor del servidor con un formato predecible. Cuando los nombres de los eventos o las claves de los parámetros varían de una página a otra, las etiquetas dejan de activarse sin motivo aparente, y te ves obligado a depurar la etiqueta cuando el verdadero problema está más arriba en la cadena. Establece una nomenclatura coherente antes de empezar a desarrollar sobre ella.

Herramientas adicionales que vale la pena combinar con tu configuración de HubSpot

Si tus clientes potenciales llegan a través de Google Ads, esta función protege directamente tus informes publicitarios. El GCLID es la etiqueta que usa Google para vincular un clic con una conversión, y cuando Safari la elimina de la URL, Google Ads no puede saber qué clics se convirtieron en clientes, por lo que tu ROAS parece peor de lo que es y el algoritmo se optimiza basándose en datos erróneos. La recuperación del ID de clic restaura los valores del GCLID que Safari elimina de las URL antes de que lleguen a tu formulario.

HubSpot no captura el GCLID de forma predeterminada. Necesitas una propiedad de contacto personalizada cuyo nombre coincida con el parámetro de la URL, que debas añadir a tu formulario como campo oculto; así, el propio sistema de coincidencia de campos ocultos de HubSpot la rellenará cuando un visitante acceda con ese parámetro en la URL. Una vez que tengas esto listo, nuestra guía para corregir las imprecisiones del ROAS de GA4 explica cómo el GCLID almacenado se convierte en una conversión offline una vez que se cierra un trato, y nuestra guía de Conversiones mejoradas trata el tema de la importación con más detalle.

El script de seguimiento mejorado enmascara y encripta la solicitud entre el navegador y el servidor, lo que ayuda a que más eventos superen la detección de patrones de los bloqueadores de anuncios antes incluso de llegar al contenedor de tu servidor.

Si atiendes tráfico de la UE, combina esta configuración con Consent Mode V2 para que las señales de consentimiento viajen junto con los datos hasta HubSpot, y no solo hasta las etiquetas de Google. En nuestra guía general sobre el RGPD para el seguimiento server-side encontrarás más información sobre lo que esto implica en la práctica.

Conclusión

El seguimiento del lado del cliente de HubSpot se diseñó para un mundo de navegadores que ya casi no existe. Entre el límite de siete días para las cookies de Safari, los bloqueadores de anuncios que eliminan el script por completo y los navegadores que clasifican cada vez más elementos de la pila de marketing como un riesgo de «fingerprinting», confiar solo en el navegador significa perder contactos, atribuir erróneamente los que conservas y pasar por alto eventos que deberían alimentar tus puntuaciones de clientes potenciales.

Al trasladar esa conexión server-side, a través de Google Tag Manager y TAGGRS, la solicitud se realiza desde tu propio dominio en lugar del de HubSpot, donde los bloqueadores de anuncios y las configuraciones de prevención de seguimiento no tienen nada con lo que compararse. Además, te permite controlar qué se envía a HubSpot y cuándo, lo que facilita, en lugar de complicar, la gestión de la privacidad.

¿Listo para configurarlo? Crea una cuenta gratuita en TAGGRS o reserva una demostración para que te expliquemos cómo configurar tu HubSpot a tu medida.

Preguntas frecuentes

¿Qué es el seguimiento server-side en HubSpot?

El seguimiento server-side para HubSpot consiste en redirigir primero a través de tu propio servidor los datos que, normalmente, irían directamente desde el navegador de un visitante a los servidores de HubSpot. En lugar de que el script de HubSpot llame directamente a js.hs-scripts.com o a hsforms.net, tu servidor recibe el evento y lo reenvía a las API de CRM y de eventos de HubSpot mediante una conexión autenticada. El resultado es que los datos llegan a HubSpot incluso cuando los bloqueadores de anuncios o la configuración de privacidad del navegador habrían bloqueado el script estándar server-side.

¿HubSpot admite de forma nativa el seguimiento server-side?

No en el sentido en que la mayoría de la gente lo entiende. El código de seguimiento, los formularios y el banner de consentimiento de HubSpot están diseñados para funcionar del lado del cliente, y sus integraciones nativas se sincronizan a través de la API del CRM en lugar de mediante un gestor de etiquetas server-side. Para conseguir un seguimiento auténtico server-side, la mayoría de los equipos combinan un contenedor de servidor de Google Tag Manager con los tokens de acceso de la aplicación privada de HubSpot y sus API de objetos CRM y eventos de comportamiento personalizados, utilizando un proveedor de alojamiento como TAGGRS para ejecutar el contenedor de servidor.

¿Cómo afecta esto a la atribución de clientes potenciales y contactos en HubSpot?

Por lo general, lo mejora. Los informes de «Fuente original», «Fuente más reciente» y de atribución de HubSpot dependen de que una cookie de seguimiento se mantenga activa a lo largo de las sesiones de un visitante. Cuando esa cookie tiene un límite de siete días debido al ITP de Safari, o se bloquea por completo con un bloqueador de anuncios, HubSpot pierde el hilo entre la búsqueda inicial de un visitante y el envío final del formulario. El seguimiento server-side, junto con un subdominio propio bien configurado, alarga el tiempo que dura esa identidad, lo que significa que se atribuyen más contactos al canal que realmente los trajo.

¿El seguimiento server-side de HubSpot cumple con el RGPD?

Sí, siempre que se configure teniendo en cuenta el consentimiento. Como los datos pasan por tu propio servidor antes de llegar a HubSpot, tú controlas exactamente qué se reenvía, lo que facilita aplicar la minimización de datos y comprobar el estado del consentimiento de un visitante antes de que cualquier dato personal salga de tu servidor. El banner de consentimiento de HubSpot no se extiende a un contenedor de servidor personalizado, así que sigues necesitando que tu plataforma de gestión del consentimiento envíe su señal directamente a tu configuración de Google Tag Manager, tal y como se explica en la sección de configuración anterior.

¿Necesitas eliminar el código de seguimiento estándar de HubSpot?

No de inmediato. Lo más seguro es tener ambas opciones funcionando en paralelo durante unas semanas. Así podrás comparar la creación de contactos, el volumen de eventos y la atribución entre las dos configuraciones antes de decidirte. Una vez que confíes en las cifras del lado del servidor, podrás decidir si eliminas por completo el código del lado del cliente o si mantienes una versión reducida del mismo para cosas como el widget de chat de HubSpot, que sigue dependiendo del token de identificación del visitante que se ejecuta en el navegador.