Funcionalidades
Router de eventos server-side
Envía cada conversión una sola vez y deja que cada plataforma la reciba de la forma en que mejor la contabiliza (navegador, servidor o ambos) sin contarla dos veces.
Destination Health
Datos de ejemplo: Estado de ejemplo estático: no es tráfico real ni datos reales de clientes.| Destino | Modo | Salud | Última entrega | Cola |
|---|---|---|---|---|
| Meta | navegador + servidor | correcto | hace 12 s | 0 reintentos |
| Google Ads | servidor | correcto | hace 40 s | 0 reintentos |
| TikTok | navegador + servidor | degradado, circuit breaker abierto | hace 6 min | 3 en la cola de mensajes fallidos |
| servidor | pausado por kill switch | hace 2 h | retenido |
Salud, modo y cola por destino; los fallos se gestionan, no se ocultan.
Ejemplo de Destination Health: dos destinos correctos, una caída de proveedor gestionada por el circuit breaker y un destino pausado por un kill switch.
El navegador y el servidor comparten un ID de evento
Track recibe eventos del SDK del navegador, de tu servidor, de plataformas de e-commerce y de redes de afiliación, los normaliza en un único esquema, aplica el consentimiento y los enruta a 22 tipos de destino con reintentos, circuit breakers, una cola de mensajes fallidos y reenvío.
El SDK del navegador y tu servidor (o el webhook de tu tienda) envían la misma compra con el mismo ID de evento. Track normaliza ambos, evalúa el consentimiento por destino y los transmite; Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn y los demás deduplican por ese ID, Google Ads por el ID de pedido.
Cómo está construido
Las decisiones técnicas detrás de la capacidad: la prueba después del beneficio.
01
Híbrido por defecto
Cada destino puede funcionar con etiqueta en el navegador, API de servidor o ambas. Los dos caminos comparten un ID de evento, de modo que Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn y los demás deduplican de forma fiable.
02
Duradero y observable
Una cola duradera con mensajes idempotentes, reintentos por destino con backoff con jitter, circuit breakers ante proveedores que fallan, almacenamiento de mensajes fallidos y reenvío. Cada intento se registra con una vista previa censurada del payload.
03
First-party por diseño
El tracker se sirve desde tu host CDN, los eventos van a tu host de ingesta y los bundles de configuración están firmados con Ed25519 y se verifican en el navegador antes de cargar nada.
Etiquetas solo en el navegador frente al router híbrido
Por qué un evento a través de Track vale más que el mismo píxel disparado dos veces.
| Etiquetas solo en el navegador frente al router híbrido | Etiquetas solo en el navegador | Navegador + servidor con Track |
|---|---|---|
| Eventos perdidos | Los scripts bloqueados y las pestañas cerradas simplemente pierden la conversión | El camino del servidor la entrega igualmente; el del navegador añade datos de coincidencia cuando están disponibles |
| Duplicados | El píxel y la API de servidor cuentan el mismo pedido dos veces | ID de evento e ID de pedido compartidos; los proveedores deduplican |
| Caída del proveedor | Fallo silencioso, sin reintento | Reintentos con backoff, circuit breaker, cola de mensajes fallidos y reenvío |
| Adónde van los datos | Endpoints de terceros llamados desde la página | Host de ingesta first-party; los proveedores solo reciben los campos mapeados |
Lo que puedes verificar
Hechos del producto que encontrarás en el panel, en la documentación y en el registro de auditoría.
- SDK del navegador por debajo de 30 KB gzip gracias a un presupuesto en CI, con almacenamiento condicionado al consentimiento
- API de servidor con claves de origen para CRM y conversiones offline
- Kill switches por sitio y por organización
- Plano de datos en la UE con aislamiento por tenant a nivel de fila
Preguntas
- ¿El tracking server-side elude el consentimiento?
- No. El consentimiento se evalúa para cada evento y cada destino; sin la finalidad requerida no se almacena, envía ni reenvía nada más tarde.
- ¿Qué ocurre cuando un proveedor está caído?
- Las entregas se reintentan con backoff, el circuit breaker pausa el destino, los eventos fallidos van a la cola de mensajes fallidos y pueden reenviarse cuando el proveedor se recupera.
Más capacidades
Construidas sobre la misma configuración firmada y el mismo esquema de eventos.
- Configuración guiada por IA
Describe tu sitio, confirma cada paso, publica una configuración firmada.
- Depurador de eventos y trazabilidad
Ve cada evento con su instantánea de consentimiento, su decisión de enrutamiento y la respuesta del proveedor.
- Calidad de datos y Health Score
Una única puntuación con componentes explicables e incidencias que enlazan con su solución.
- Consentimiento por diseño
Opt-in estricto por defecto, Consent Mode v2, destinos basados en finalidades, sin reenvío tras el consentimiento.
- IDs de clic y atribución bien hechos
Captura solo los IDs que el destino necesita, solo con consentimiento y solo durante la ventana documentada.
Pruébalo con tu dominio
Crea un sitio, instala un snippet y deja que el asistente configure el primer destino en minutos.