Saltar al contenido

Tracking y analíticaServicio

Tracking server-side para Shopify: Stape, autoalojado o una app, según lo que encaje

Configuro la entrega server-side con la opción que encaja con tu volumen y presupuesto, y te digo si aún no compensa. Recupera señal; no arregla los anuncios.

Publicado
Revisado

El problema

¿Por qué está perdiendo datos el tracking basado en el navegador?

El tracking basado en el navegador lleva años perdiendo terreno. Los bloqueadores de anuncios eliminan los píxeles directamente. Intelligent Tracking Prevention de Safari y Enhanced Tracking Protection de Firefox limitan lo que los scripts de terceros pueden ver y cuánto sobreviven las cookies.

El tráfico de iOS, en particular, pierde una parte significativa de los eventos antes de que lleguen siquiera a GA4 o Meta.

Nada de esto aparece como un error: aparece como conversiones infrainformadas y campañas que parecen peores de lo que realmente rinden.

El tracking server-side traslada el procesamiento y el envío a proveedores a infraestructura que tú controlas. Un endpoint de recogida first-party puede reducir algunas pérdidas del navegador y darte más control sobre la ruta de los datos, pero no esquiva por defecto el consentimiento, los bloqueadores ni las protecciones de privacidad del navegador.

Alcance

Qué hago

Orden de trabajo Tracking y analítica

Diseño e implemento tracking server-side para tiendas Shopify, eligiendo la capa de entrega en función de tu situación en lugar de optar por una opción por defecto:

  1. Stapeun host gestionado de GTM server-side, la opción adecuada para la mayoría de las marcas: coste razonable, poco mantenimiento y compatible con los conocimientos de GTM que ya tengas.

  2. Autoalojado, en GCP o similarpara tiendas de mayor volumen donde los costes por evento en una plataforma gestionada empiezan a importar, o donde el control total de la infraestructura es un requisito.

  3. Fixel Pixelun producto de entrega server-side nativo de Shopify que fundé. Lo recomiendo cuando encaja de verdad con tu volumen y tu stack —juzgado por ajuste, soporte y coste total de operación—, no por defecto. Si Stape o el autoalojado encajan mejor en tu caso, eso es lo que propondré, con las limitaciones de cada opción indicadas. Si Fixel Pixel encaja, puedes conectarlo tú mismo; el Setup opcional, hecho por mí, cuesta EUR 240. El enrutamiento a medida más allá de eso se presupuesta como Focused Fix.

El alcance suele incluir el propio contenedor de servidor, un subdominio de primera parte para que las solicitudes parezcan de tu propio dominio en lugar de un tercero, la configuración de cookies comprobada frente a los límites de privacidad del navegador y el enrutamiento de eventos a cada plataforma que necesites —GA4, Meta CAPI y otras según tu stack—.

El proceso

Cómo se desarrolla

  1. Definición del alcance

    Acceso DNS para un subdominio de primera parte, acceso a Shopify y GTM, acceso a las plataformas publicitarias y detalles de cualquier herramienta de consentimiento existente. Si ya usas Stape u otro proveedor, construimos sobre lo que hay en lugar de empezar de cero.

  2. Base

    Configuración del contenedor de servidor, configuración del dominio de primera parte y enrutamiento server-side de GA4 como capa base.

  3. Ampliación de plataformas

    Se añaden Meta CAPI y cualquier otra plataforma dentro del alcance con parámetros de coincidencia enriquecidos y deduplicación basada en event_id frente a los eventos del navegador.

  4. Integración del consentimiento

    El estado de consentimiento recogido en el navegador se propaga al servidor, de modo que los eventos server-side respetan las mismas decisiones de consentimiento que los del navegador: el tracking server-side no es una forma de eludir los requisitos de consentimiento.

  5. Verificación

    La deduplicación se comprueba evento por evento, no se asume, antes de dar la implementación por terminada.

Entrega

Qué obtienes

Un contenedor de servidor funcional, un endpoint de primera parte, deduplicación verificada entre eventos de navegador y de servidor, propagación del estado de consentimiento y un runbook que documenta la arquitectura para que un futuro desarrollador —o yo mismo, meses después— pueda entender qué está funcionando y por qué.

Kit de entrega

  • Configuración server-side en Stape o GCP autoalojado, dimensionada para tu volumen y presupuesto
  • Configuración de subdominio de primera parte y cookies
  • Enrutamiento de eventos server-side plataforma por plataforma (GA4, Meta CAPI y otros según el alcance)
  • Verificación de deduplicación entre eventos de navegador y de servidor
  • Propagación del estado de consentimiento a la capa de servidor
  • Runbook que documenta la configuración para futuros cambios

Precio y plazo

Siguiente paso

¿No sabes si el tracking server-side ya vale la pena? Describe tu configuración; hablarlo es gratis. Si primero hay que establecer la pérdida de señal, el Tracking Health Check, de solo lectura, puede revisar la ruta de los datos para un problema acordado.

Si ya sabes que lo necesitas, escribe a next@taskfordaniel.com con tu stack actual y te presupuesto la implementación directamente; si la causa de la pérdida de señal aún no está establecida, solicita primero un Tracking Health Check. El enrutamiento server-side específico para Meta se combina con el trabajo en Meta Conversions API si la deduplicación o la calidad de coincidencia es el problema de fondo.

PresupuestoFijado antes de empezar

Precio
Focused Fix desde EUR 425 · Custom Engineering Project desde EUR 1.400 · presupuesto por escrito
Plazo
De 4 días laborables a 2 semanas según el alcance
Describe tu tarea

Una nota de Daniilantes de decidir

¿Cuándo no ayuda el tracking server-side?

Merece la pena ser directo con esto, porque se vende en exceso en todo el sector. El tracking server-side no va a:

  • Arreglar un evento roto. Si tu evento purchase tiene el items array equivocado o tu integración CAPI carece de lógica de deduplicación, trasladar esa lógica al servidor solo reubica el error. Arregla primero el evento.
  • Arreglar el rendimiento publicitario. Recupera señal de medición; no mejora tu creatividad, tu oferta ni tu segmentación. Mejores datos pueden fundamentar mejores decisiones, pero no son una palanca de rendimiento por sí mismos.
  • Hacer que el consentimiento sea opcional. Cada evento server-side sigue teniendo que respetar las mismas decisiones de consentimiento que el visitante tomó en el navegador. Esto es un cambio de arquitectura, no una forma de sortear el cumplimiento normativo.
  • Amortizarse en todas las cuentas. Para una tienda pequeña con una inversión publicitaria modesta, el coste mensual de infraestructura de un contenedor de servidor puede superar la señal que recupera. Parte de definir el alcance con honestidad es decirte cuándo todavía no vale la pena.

— Daniil

Preguntas

Preguntas frecuentes

Stape, autoalojado o Fixel Pixel, ¿cuál necesito?

Depende del volumen, el presupuesto y cuánto control quieras sobre la infraestructura. Stape encaja en la mayoría de las marcas: gestionado, coste razonable, poco mantenimiento. El GCP autoalojado encaja en tiendas de mayor volumen donde importan los costes por evento. Fixel Pixel, que fundé, es una capa de entrega nativa de Shopify creada específicamente para simplificar esto: comparo las tres por ajuste, soporte y coste total de operación y recomiendo la que encaja con tu tienda, con sus limitaciones y las alternativas, no aquella en la que tengo participación.

¿Qué mejora debo esperar al pasar a server-side?

No te daré una cifra aquí: depende en gran medida de la combinación de dispositivos de tu tráfico, de la prevalencia de bloqueadores de anuncios y de cuánta pérdida de señal soportas actualmente. Un endpoint first-party puede reducir algunas pérdidas del navegador, pero el dispositivo del visitante sigue teniendo que enviar la petición. Safari también limita las cookies establecidas mediante CNAME que encubren servicios de terceros. El Tracking Health Check evalúa la ruta real de los datos; la recuperación no es una promesa genérica.

¿Cuáles son los costes recurrentes?

El tracking server-side funciona sobre una infraestructura que no es gratuita: un contenedor alojado tiene una cuota mensual que escala con el volumen de eventos, sea cual sea el proveedor que elijas. Dimensionaré ese coste como parte de la definición del alcance para que no sea una sorpresa tras la puesta en marcha.

¿Sustituye esto a mi tracking del lado del navegador?

No, funciona junto a él. Los eventos server-side se deduplican frente a los eventos del navegador, no se usan para sustituirlos sin más. Eliminar por completo el tracking del navegador suele hacerte perder señales del lado del cliente (como la profundidad de scroll o el comportamiento en la página) que solo el navegador puede ver.

¿Arreglará esto por sí solo una discrepancia de ingresos en GA4 o un problema de deduplicación de Meta CAPI?

No por sí solo. Si la causa raíz es un evento purchase roto o una lógica de deduplicación ausente, trasladar esa lógica rota a un servidor no lo arregla: solo mueve el error. El tracking server-side es un cambio de infraestructura; funciona mejor cuando la lógica de eventos subyacente ya es correcta.

Dónde seguir

Daniil Maximkin

Hola, soy Daniil.

Trabajo contigo desde la definición del problema hasta la implementación y la entrega. Hablas con quien hace el trabajo. Trabajo en inglés y ruso.

Mi historia Mi trabajo

¿Qué necesitas poner en marcha?

Describe tu tarea

La primera respuesta es gratis, en un día laborable. O escribe directamente: next@taskfordaniel.com