Analítica y seguimiento

Custom Event & Conversión Tracking
Cada acción que importa, capturada de forma limpia.

Diseño estratégico de capas de datos y seguimiento de eventos personalizado para compras, clientes potenciales, registros y microconversiones. Parámetros completos, datos de artículos, propiedades de usuario y seguimiento de ingresos para que finalmente sepas qué es lo que realmente impulsa la canalización y los ingresos cerrados.

Consigue una auditoría de seguimiento gratuita arrow_forward
↑ 3.8×
Claridad en la atribución de ingresos
98%+
Integridad de los parámetros de eventos
↓ 55%
Caída de conversiones sin explicación
95+
Implementaciones de eventos personalizados

Por qué la mayoría del "seguimiento de conversiones" es incompleto o frágil

Fallos comunes

  • Solo se rastrean envíos de formularios sin contexto sobre qué oferta o página
  • Eventos de compra sin líneas de pedido, descuentos ni método de pago
  • Eventos de lead que se disparan en cada interacción parcial con el formulario
  • Sin distinción entre acciones cualificadas por marketing y cualificadas por ventas
  • Eventos que se rompen en cuanto el sitio se rediseña

Nuestro estándar

Primero diseñamos una taxonomía de eventos completa. Cada acción rastreada tiene un significado comercial claro, parámetros obligatorios y opcionales y un lugar definido en el embudo. Luego lo implementamos de manera defensiva para que sobreviva a los cambios del sitio y aún brinde datos limpios a los anuncios, CRM y análisis.

Patrones de implementación técnica que utilizamos

Diseño de capa de datos

  • Eventos estándar + personalizados: Seguimos exactamente las especificaciones de ecommerce y generación de leads de Google, y luego añadimos los eventos personalizados que realmente importan para tu negocio (precios vistos, demo reservada, cuenta mejorada, etc.).
  • Higiene de parámetros: Tipos coherentes, sin PII en nombres de eventos ni parámetros salvo que esté cifrada con hash y documentada, y moneda y valor siempre presentes en los eventos de ingresos.
  • Arrays de artículos: Datos completos de artículos en cada compra y adición al carrito para que puedas analizar por categoría, producto y margen.

Defensivo y A prueba de futuro

  • Versionado de eventos: Incluimos parámetros event_version o schema_version para que puedas evolucionar los eventos sin romper el análisis histórico.
  • Biblioteca de seguimiento centralizada: Cuando es posible, publicamos un pequeño helper de seguimiento versionado para que los desarrolladores no copien y peguen listeners de GTM por todas partes.
  • Enriquecimiento del lado del servidor: Las propiedades de usuario y los valores de transacción que solo se conocen en el servidor se envían mediante Measurement Protocol o GTM de servidor.

Nuestro evento personalizado y Proceso de seguimiento de conversiones

01

Embudo y Mapeo de acciones

Taller para enumerar cada acción que indica intención o ingresos, desde la primera visita anónima hasta el cierre del trato y las ventas adicionales.

02

Taxonomía y análisis de eventos Esquema

Defina los nombres de los eventos, los parámetros obligatorios/opcionales, los alcances y cómo cada uno se asigna a los eventos clave de GA4, las plataformas publicitarias y las etapas de CRM.

03

capa de datos & Implementación del oyente

Agregue las inserciones de dataLayer en los lugares correctos (o use las existentes). Cree activadores y variables de GTM robustos que sobrevivan a los cambios de DOM.

04

Parámetro y Enriquecimiento de valor

Agregue propiedades de usuario, detalles del artículo, contexto de la campaña y cualquier valor del lado del servidor (margen, nivel LTV, duración del contrato).

05

Validación entre pilas

Depuración de GTM, debugView de GA4, eventos de prueba de plataforma publicitaria, inspección de carga útil de CRM y validación del tráfico de producción de usuarios reales durante más de 7 días.

06

Documentos y Mantenimiento

Catálogo dinámico de eventos con ejemplos, procesos de cambio y alertas cuando los eventos críticos caen por debajo del volumen esperado.

Preguntas frecuentes sobre el seguimiento de eventos personalizados y conversiones

Preguntas técnicas sobre cómo crear un seguimiento de eventos que sobreviva e impulse decisiones reales.

¿Cómo decidís qué microconversiones merece la pena seguir? expand_more
Puntuamos cada acción según dos ejes: con qué fuerza predice ingresos o avance del pipeline, y con qué limpieza puede medirse sin falsos positivos. Solo las acciones con puntuación alta en ambos entran en la lista final.
¿Disparáis los eventos solo en el cliente o también en el servidor? expand_more
Ambos cuando aporta valor. Cliente para señales de UX inmediatas y contexto de página. Servidor para cualquier cosa en la que se deba confiar (pago exitoso, suscripción iniciada, cliente potencial de alto valor marcado por ventas). Deduplicamos usando transaction_id o lead_id.
¿Qué parámetros incluís siempre en los eventos de lead y de compra? expand_more
lead_id o transaction_id, value (con la moneda), lead_source o contexto de canal, parámetros de campaña (o gclid/fbclid), tipo o nivel de usuario si se conoce, y cualquier ID de experimento o variante que estuviera activo.
¿Cómo gestionáis el seguimiento de formularios cuando se cargan por JS o en modales? expand_more
Escuchamos el submit en los elementos reales del formulario y también vigilamos los estados de éxito en la interfaz o en el dataLayer. Capturamos qué formulario (por id o atributo data), qué paso si es multipaso y cualquier contexto de oferta visible.
¿Podéis seguir eventos que ocurren después de que el usuario abandone el sitio (llamadas telefónicas, offline)? expand_more
Sí. Las plataformas de seguimiento de llamadas, los webhooks del CRM y las subidas de conversiones offline alimentan el mismo modelo de eventos. Nos aseguramos de que el ID de clic o de usuario original viaje con el registro offline.
¿Cómo evitáis eventos duplicados cuando los usuarios recargan o hacen clic muy rápido? expand_more
Usamos transaction_id o un event_id generado con lógica de deduplicación en GTM o en el servidor. Para eventos que no son transacciones solemos usar un breve debounce en el cliente o un indicador en sessionStorage.
¿Y los eventos que solo deben dispararse para ciertos segmentos de usuarios? expand_more
Los condicionamos con propiedades de usuario o indicadores del dataLayer (logged_in, customer_type, experiment_cohort). Las condiciones de activación son explícitas y están documentadas para que no se disparen por accidente para la audiencia equivocada.
¿Cómo evolucionáis el esquema de eventos con el tiempo sin romper los datos antiguos? expand_more
Versionamos los eventos (añadimos event_version) y tratamos los parámetros nuevos como opcionales. Los eventos antiguos siguen funcionando. Las vistas de BigQuery pueden combinar los esquemas antiguos y nuevos para un reporting consistente.
¿Seguís eventos negativos o de fallo (error de formulario, checkout abandonado)? expand_more
Sí. A menudo son más diagnósticos que los eventos de éxito. Seguimos form_error, checkout_step_error y payment_failed con el paso y el motivo cuando está disponible. Alimentan el trabajo de UX y CRO.
¿Cómo os aseguráis de que el valor se reporta en la moneda correcta? expand_more
Siempre pasamos la moneda de forma explícita junto con el valor. En sitios multimoneda normalizamos o conservamos la original y gestionamos la conversión en el reporting. Lo probamos con pedidos reales en cada moneda.
¿Podéis rellenar eventos históricos si el sitio tenía antes un seguimiento deficiente? expand_more
De forma limitada. A veces podemos reconstruirlos a partir de logs del servidor, registros del CRM o datos de las plataformas publicitarias y subir conversiones offline. Los eventos puramente del lado del cliente del pasado suelen estar perdidos.
¿Cómo gestionáis las aplicaciones de página única y el enrutamiento en el cliente? expand_more
Escuchamos los eventos del router (o los cambios de historial) y disparamos un page_view virtual + los eventos personalizados correspondientes. Nos aseguramos de que el dataLayer tenga un contexto de página estable incluso cuando la URL no cambia.
¿Qué nivel de detalle ponéis en el array items en sitios que no son ecommerce? expand_more
Para generación de leads y SaaS solemos modelar los "items" como la oferta, el plan o la pieza de contenido con la que interactuó el usuario. Nos permite analizar el rendimiento por producto, nivel o tipo de contenido igual que los equipos de ecommerce analizan sus SKUs.
¿Cómo comprobáis que los eventos llegan correctamente a las plataformas publicitarias? expand_more
Usamos las herramientas oficiales de eventos de prueba (eventos de prueba de Google Ads, prueba del Administrador de eventos de Meta, el asistente de etiquetas UET de Microsoft Advertising) y además revisamos la entrega real en las plataformas tras el retraso de modelado de 24-48 horas.
¿Cuánto suele tardar un buen trabajo de eventos personalizados? expand_more
Eventos principales de ingresos y leads con parámetros: 2-4 semanas. Embudo completo con microconversiones, enriquecimiento en el servidor, versionado y documentación para el equipo: 5-8 semanas.

¿Listo para saber exactamente qué acciones se convierten en ingresos?

Obtenga una auditoría de seguimiento gratuita. Mapearemos y le mostraremos el sistema de eventos completo que su empresa realmente necesita.

Conseguir mi auditoría de seguimiento gratuita arrow_forward