La guía del desarrollador para el seguimiento de afiliados del lado del servidor

Resumen rápido: El seguimiento de afiliados del lado del servidor reemplaza los píxeles dependientes del navegador por llamadas directas a la API desde su backend, capturando cada conversión independientemente de bloqueadores de anuncios, configuraciones de privacidad de iOS o restricciones de cookies.

• El seguimiento S2S almacena un ID de clic en el servidor y envía un postback a Tapfiliate cuando ocurre una conversión
• La API REST de Tapfiliate gestiona esto con dos llamadas principales: POST /clicks/ al llegar, POST /conversions/ en la compra
• La parte más compleja no es la llamada a la API, sino el almacenamiento correcto del ID de clic en la primera carga de la página del usuario
• Una vez en producción, las conversiones atribuidas aumentan del 60–70% (píxel, móvil) a una precisión casi total

Su panel de afiliados muestra 847 conversiones este mes. Su sistema de gestión de pedidos muestra 1,203.

La diferencia representa 356 ventas que su programa de afiliados no pudo atribuir. Esto equivale a 356 comisiones calculadas con base en estimaciones, o 356 ventas generadas por afiliados que no fueron recompensados porque un píxel no se activó.

En ambos casos, alguien pierde dinero. Cuando el equipo de marketing pregunta por qué los números no coinciden, la respuesta siempre es la misma: “el píxel”.

Esta guía explica por qué fallan los píxeles, cómo el seguimiento del lado del servidor resuelve el problema en la arquitectura y cómo implementarlo con la API REST de Tapfiliate usando un código funcional.

Al final, la discrepancia entre su número de pedidos y sus conversiones atribuidas se eliminará definitivamente.

Por qué fallan los píxeles (y por qué los desarrolladores son los culpables)

Los tres modos de fallo del seguimiento del lado del cliente

Un píxel de seguimiento se activa desde el navegador del comprador cuando llega a su página de confirmación. En la práctica, falla de tres maneras distintas y previsibles.

Bloqueadores de anuncios. Extensiones como uBlock Origin y Privacy Badger bloquean scripts de seguimiento por defecto. La adopción de bloqueadores de anuncios superó el 40% en escritorios en 2025 y sigue creciendo.

iOS y Safari ITP. La prevención inteligente de rastreo de Apple limita la vida útil de las cookies de terceros a 24 horas después de la última interacción del usuario con el rastreador. Un comprador que hace clic en un enlace afiliado el lunes y convierte el miércoles no tendrá una cookie rastreable. El píxel se activa, pero no hay nada que leer.

Abandono de página antes de la carga. En conexiones móviles lentas, las páginas de confirmación pesadas en JavaScript pueden tardar de tres a cinco segundos en cargarse completamente. Los compradores rápidos cierran la pestaña. El script del píxel nunca se ejecuta.

El costo real de la brecha de atribución

La diferencia entre las conversiones rastreadas por píxel y los pedidos reales puede llegar al 30–40% en un tráfico mayoritariamente móvil cuando se suman la expiración de cookies ITP, bloqueadores de anuncios y abandono de página.

En un programa que paga una comisión promedio de 20 USD por 1,000 conversiones mensuales, esta brecha representa entre 6,000 y 8,000 USD en comisiones mal atribuidas. Los afiliados reciben crédito por ventas que no generaron o no reciben crédito por las que generaron. Ninguno de estos escenarios es viable.

El seguimiento del lado del servidor elimina totalmente la dependencia del navegador. El evento de conversión se envía desde su servidor a la API de Tapfiliate. Sin píxel. Sin dependencia del navegador. Sin brechas.

Cómo funciona el seguimiento de afiliados del lado del servidor

El ciclo de vida del ID de clic

Todo en el seguimiento de afiliados del lado del servidor deriva de un concepto: el ID de clic. Entender su ciclo de vida hace que la implementación sea evidente.

Aquí está el flujo completo de punta a punta:

1. Un usuario hace clic en un enlace afiliado. La URL contiene el código de referencia del afiliado, por ejemplo, ?ref=sarah123.
2. Su servidor recibe la solicitud de la página de destino y detecta el parámetro ref en la URL.
3. Su backend realiza una llamada POST /clicks/ a la API REST de Tapfiliate, transmitiendo el código de referencia.
4. Tapfiliate crea un registro de clic y devuelve un ID de clic único para ese evento específico.
5. Su backend almacena el ID de clic, vinculado a la sesión del servidor del usuario o a una fila de base de datos.
6. El usuario finaliza una compra. Su gestor de confirmación de pedidos realiza una llamada POST /conversions/, transmitiendo el ID de clic almacenado.
7. Tapfiliate asocia el ID de clic con el afiliado de origen, calcula la comisión y acredita la cuenta del afiliado.
8. El afiliado ve la comisión aparecer en tiempo real en su panel de Tapfiliate.

Los pasos del 1 al 5 ocurren durante la solicitud de la página de destino. Los pasos del 6 al 8 suceden en el evento de confirmación del pedido. El navegador del comprador solo está involucrado en el paso 1, para transmitir el parámetro ref en la URL.

Lado del cliente vs lado del servidor: la diferencia estructural

En el seguimiento del lado del cliente, el navegador del comprador es la fuente de verdad. Contiene la cookie, dispara el píxel y reporta la conversión. Cualquier fallo en el dispositivo del comprador resulta en una atribución perdida.

En el seguimiento del lado del servidor, tu backend es la fuente de verdad. Captura el código de referencia al llegar, crea el clic, almacena el ID del clic y dispara el evento de conversión en la compra. Los parámetros del navegador del comprador son irrelevantes, ya sean cookies, bloqueo de JavaScript o contexto web vs aplicación.

	Lado del cliente (Píxel)	Lado del servidor (API S2S)
Fuente de la señal de conversión	Navegadores del comprador	Tu servidor backend
Impacto del bloqueador de anuncios	Bloquea el script de seguimiento	Sin impacto
Impacto del ITP iOS	Expiración de la cookie en 24h	Sin impacto
Precisión de la atribución (móvil)	60–70 %	Casi completa
Seguimiento multi-dispositivo	No	Sí (vía sesión/cuenta)
Complejidad de implementación	Baja	Media
Exposición al GDPR	Mayor (datos almacenados en el navegador)	Menor (controlado en el servidor)

La API REST de Tapfiliate: tu kit de herramientas para implementación

Autenticación

Cada solicitud a la API REST de Tapfiliate requiere un encabezado:

X-Api-Key: YOUR_API_KEY

Tu clave API está disponible en tu cuenta de Tapfiliate en Configuración. Guárdala en una variable de entorno. Nunca la codifiques directamente en el código fuente. Nunca la envíes a un repositorio de control de versiones. Nunca la expongas en el JavaScript del lado del cliente.

La clave API permite crear conversiones y aprobar comisiones. Una clave expuesta representa un riesgo financiero, no solo un riesgo de seguimiento.

# Correct: environment variableexport TAPFILIATE_API_KEY="your_key_here"# Wrong: hardcodedconst apiKey = "tap_live_abc123xyz"; // Do not do this

Todos los endpoints usan Content-Type: application/json. Todas las respuestas son en JSON. La API está actualmente en la versión 1.6. Para referencia completa de los endpoints, consulta la documentación de la API REST de Tapfiliate.

Una lista rápida de seguridad para tu clave API antes de escribir cualquier línea de código de seguimiento:

• Guarda la clave en una variable de entorno o gestor de secretos (AWS Secrets Manager, Vault, GCP Secret Manager).
• Renueva la clave si alguna vez fue enviada a un repositorio, aunque haya sido brevemente, incluso en un repositorio privado.
• Configura una alerta si la clave es detectada en un nuevo commit mediante una herramienta como GitGuardian o el escáner de secretos de GitHub.
• Usa claves distintas para staging y producción. Una prueba en staging disparada con una clave de producción genera comisiones reales.

Nada de esto es específico de Tapfiliate. Se aplica a todas las claves API que tu backend maneja. Pero las claves de plataformas de afiliados son particularmente sensibles, ya que están en la intersección entre dinero y la confianza de los socios.

Los tres endpoints esenciales

Para el seguimiento de afiliados del lado del servidor, necesitas dos endpoints principales y un endpoint opcional:

POST /clicks/
Crea un registro de clic cuando un usuario llega vía enlace de afiliado. Envía el código de referencia del afiliado. Tapfiliate devuelve un objeto clic que contiene el ID del clic.

POST /conversions/
Registra una conversión vinculada a un ID de clic almacenado. Tapfiliate asigna la conversión al afiliado correcto y pone la comisión en cola para pago. Envía tu ID interno de pedido como external_id para evitar duplicados.

POST /customers/ (opcional)
Crea un registro persistente del cliente. Relevante para programas de suscripción y SaaS donde rastreas el valor de vida del cliente y deseas atribución recurrente de comisiones en múltiples eventos de facturación, no solo en la primera compra.

Tapfiliate también soporta atribución secundaria vía código de referencia o código promocional directamente en POST /conversions/. Si un usuario llega sin el parámetro ref, pero usa un cupón afiliado en el pago, puedes enviar el código promocional en la llamada de conversión y la atribución será precisa.

Guía de Implementación: Configuración Completa S2S

Esta guía utiliza Node.js. El mismo modelo aplica para Python, Go, Ruby o cualquier otro lenguaje backend. Sustituye las llamadas fetch por tu cliente HTTP preferido.

Paso 1: Capture el parámetro ref del afiliado al llegar

Cada visitante de su sitio puede o no contener un código de referencia de afiliado en la URL. Su middleware de landing debe verificar esto en cada solicitud y crear un clic cuando esté presente.

// Express.js middleware, runs on every incoming page requestapp.use(async (req, res, next) => {  const affiliateRef = req.query.ref || req.query.tap_a;  if (affiliateRef) {    try {      const click = await createTapfiliateClick(affiliateRef);      // Store the click ID in the server-side session      req.session.tapClickId = click.id;    } catch (err) {      // Non-blocking: log the failure, do not prevent page load      console.error('Tapfiliate click creation failed:', err.message);    }  }  next();});

El bloque try/catch aquí es intencional y crucial. La creación del clic nunca debe bloquear la carga de la página. Si la API de Tapfiliate está lenta o temporalmente no disponible, el usuario aún podrá acceder a su sitio. Usted registra la falla y continúa.

Paso 2: Almacene el ID del clic en el servidor

La función createTapfiliateClick llama a POST /clicks/ y devuelve el ID del clic.

async function createTapfiliateClick(referralCode) {  const response = await fetch('https://api.tapfiliate.com/1.6/clicks/', {    method: 'POST',    headers: {      'Content-Type': 'application/json',      'X-Api-Key': process.env.TAPFILIATE_API_KEY,    },    body: JSON.stringify({      referral_code: referralCode,    }),  });  if (!response.ok) {    throw new Error(`Tapfiliate API returned ${response.status}`);  }  return response.json(); // Returns { id: "click_abc123...", ... }}

El campo id en la respuesta es el ID del clic. Almacénelo en la sesión del servidor, en una cookie firmada con las banderas HttpOnly y Secure activadas, o en una fila de base de datos vinculada al identificador de sesión del usuario.

No lo almacene en cookies accesibles por el cliente ni en localStorage. Este almacenamiento es visible para extensiones del navegador y puede ser manipulado.

Paso 3: Dispare el postback de conversión

Cuando se complete una compra, llame a POST /conversions/ desde su gestor de pedidos backend. Nunca lo haga desde un script frontend o gestor de etiquetas.

async function recordTapfiliateConversion(clickId, orderId, orderValue) {  const response = await fetch('https://api.tapfiliate.com/1.6/conversions/', {    method: 'POST',    headers: {      'Content-Type': 'application/json',      'X-Api-Key': process.env.TAPFILIATE_API_KEY,    },    body: JSON.stringify({      click_id:    clickId,      external_id: orderId,    // Your internal order ID (used for deduplication)      amount:      orderValue, // Order value in your program's base currency    }),  });  if (!response.ok) {    const errorBody = await response.text();    console.error(`Tapfiliate conversion failed [${response.status}]: ${errorBody}`);    // Add to retry queue; do not silently discard  }}

Integre esto en su webhook post-pago o gestor de confirmación de pedido:

// Post-payment webhook endpointapp.post('/webhooks/payment-confirmed', async (req, res) => {  const { orderId, orderValue, sessionId } = req.body;  // Look up the click ID stored during the user's landing visit  const clickId = await getClickIdForSession(sessionId);  if (clickId) {    await recordTapfiliateConversion(clickId, orderId, orderValue);  }  res.sendStatus(200);});

En mi experiencia, el error de implementación más común es disparar esta llamada de conversión en la página “gracias” frontend mediante un script o disparador GTM. Si el comprador cierra la pestaña antes de que la página cargue completamente (lo que sucede más de lo que se imagina), la conversión se pierde silenciosamente. Siempre dispare desde el evento de confirmación de pago backend.

Paso 4: Verifique en el panel de Tapfiliate

Después de su primera transacción de prueba, inicie sesión en su cuenta de Tapfiliate y acceda a Conversiones. Confirme que la conversión aparece con el afiliado correcto, el valor del pedido y el estado “Pendiente”.

Una respuesta 400 al POST /conversions/ generalmente indica que el ID del clic es inválido o ha expirado. Un 401 indica que el encabezado de la clave API está ausente o incorrecto. Para la lista completa de códigos de error y parámetros adicionales, incluyendo cómo adjuntar metadatos o IDs de clientes a las conversiones, consulte las guías de integración para desarrolladores de Tapfiliate.

Casos extremos que enfrentan los desarrolladores

IDs de clic ausentes (tráfico directo y dark social)

No todos los visitantes llegan a través de un enlace de afiliado. El tráfico directo, newsletters por correo electrónico, campañas SMS y compartidos en dark social no contienen el parámetro ref. Su middleware no encuentra nada, no se almacena ningún ID de clic y no se registra ningún afiliado.

He notado que los equipos frecuentemente olvidan tratar explícitamente este caso. IDs de clic nulos enviados al POST /conversions/ generan errores 400 que parecen fallas de integración. Esto no es cierto. Son situaciones esperadas que requieren una rama condicional.

// In your payment confirmation handlerif (clickId) {  await recordTapfiliateConversion(clickId, orderId, orderValue);} else {  // No affiliate referral detected; organic or direct conversion  logger.info('Conversion recorded without affiliate attribution', { orderId });}

Para compradores que llegan sin parámetro ref pero usan un código promocional afiliado en el pago, puede enviar directamente el código promocional en la llamada de conversión en lugar de un ID de clic. Tapfiliate resuelve la atribución a partir del cupón.

Prevención de conversiones duplicadas

Los retrasos en la red causan reenvíos de webhooks. Sin deduplicación, una sola compra dispara dos o tres eventos de conversión. Su programa de afiliados acredita varias veces la misma venta.

La solución es el campo external_id en el POST /conversions/. Tapfiliate rechaza cualquier conversión enviada con un external_id ya existente en su cuenta.

body: JSON.stringify({  click_id:    clickId,  external_id: orderId,   // Your stable internal order ID (safe to retry)  amount:      orderValue,}),

Use siempre su ID interno de pedido como external_id. Siempre. Nunca genere un nuevo ID en cada intento de reenvío. Un ID de pedido estable garantiza que el endpoint sea idempotente. Puede intentar las veces que necesite sin crear comisiones duplicadas.

Atribución multitouch y entre sesiones

Un usuario frecuentemente interactúa con varios enlaces de afiliados antes de convertir. Hace clic en una publicación de Instagram del afiliado A el lunes. Hace clic en un enlace de blog del afiliado B el jueves. Realiza la compra el viernes.

El modelo estándar de Tapfiliate atribuye la comisión al último clic, es decir, al afiliado B. Si su modelo de programa utiliza atribución en el primer contacto, puede mantener el primer ID de clic almacenado verificando si ya existe en la sesión antes de sobrescribirlo:

// Only store a click ID if one is not already present for this sessionif (!req.session.tapClickId) {  const click = await createTapfiliateClick(affiliateRef);  req.session.tapClickId = click.id;}

El modelo que utiliza depende de las reglas de su programa. La implementación es idéntica en ambos casos. La diferencia está en sobrescribir o no el ID de clic almacenado durante visitas subsecuentes a enlaces de afiliados.

Privacidad, seguridad y LGPD

Nunca exponga su clave API del lado del cliente

El encabezado X-Api-Key autentica las solicitudes que crean conversiones y validan comisiones. No es un token de solo lectura para análisis.

Si la clave aparece en una solicitud de red del navegador (un componente React, una etiqueta HTML personalizada GTM o una función de origen Segment), cualquier usuario puede extraerla mediante las herramientas de desarrollo del navegador. Entonces podría generar conversiones fraudulentas para cualquier afiliado de su programa.

Todas las llamadas a la API REST de Tapfiliate deben provenir de su backend. Su JavaScript frontend no tiene una razón legítima para llamar a la API de Tapfiliate. Si utiliza un gestor de etiquetas del lado del cliente con su implementación S2S, asegúrese de que la integración del gestor utilice una capa de datos separada y aislada. Nunca transmita su clave API a través de ella.

LGPD y minimización de datos para IDs de clic

Un ID de clic es un identificador seudonimizado que, combinado con otros datos, puede vincularse a una persona. Dependiendo del contexto del procesamiento, puede considerarse un dato personal bajo la LGPD.

Medidas prácticas para cumplir:

1. Establezca un límite de retención. La ventana estándar de atribución de Tapfiliate es de 30 días. Elimine los IDs de clic almacenados en su sesión o base de datos después de 30 días sin conversión.
2. Evite enlaces innecesarios. No almacene IDs de clic en la misma fila de la base de datos que datos directamente identificables (nombre, correo electrónico) sin una base legal documentada.
3. Incluya la gestión de los IDs de clic en su Contrato de Procesamiento de Datos con Tapfiliate. El DPA cubre los datos que Tapfiliate procesa en su nombre.
4. Atienda las solicitudes de eliminación. Las solicitudes de derecho al borrado deben incluir la eliminación de los IDs de clic almacenados relacionados con ese usuario.

Para programas con usuarios de la UE, documente el procesamiento de los IDs de clic en sus Registros de Actividades de Procesamiento. Para una lectura profunda sobre la integración S2S en el seguimiento de programas de influencers, consulte el seguimiento híbrido de influencers con software de afiliados.

Probando su implementación S2S

Validación del seguimiento paralelo

Antes de desactivar su seguimiento por píxel existente, haga que ambos sistemas funcionen en paralelo durante al menos 48 horas. Esto permite comparar los conteos de conversión y detectar problemas en el almacenamiento de los IDs de clic sin pérdida de datos de atribución.

El protocolo de prueba:

1. Active su código postback S2S en paralelo con el píxel del lado del cliente existente.
2. Genere de 10 a 20 transacciones de prueba controladas usando sus propios enlaces de afiliados.
3. Compare el número de conversiones en Tapfiliate con el de su sistema de gestión de pedidos.
4. Si los conteos coinciden para los 10 a 20 pedidos de prueba: el S2S está funcionando correctamente. Desactive el píxel.
5. En caso de discrepancia: primero verifique la lógica de recuperación de los IDs de clic en el gestor de pagos. La causa más común es la expiración de la sesión entre el acceso y la compra para compras que requieren más tiempo de decisión.

Un método práctico para probar sin pedidos reales: use la cuenta de afiliado de prueba de Tapfiliate y un entorno de preproducción. Cree un afiliado de prueba, haga clic en su propio enlace de afiliado en modo de navegación privada, realice una compra de prueba y luego verifique si la conversión aparece en el panel de Tapfiliate. Esto ofrece una prueba completa de extremo a extremo sin afectar los datos de producción.

Un último punto a verificar: asegúrese de que su deduplicación external_id esté funcionando. Envíe dos veces el mismo ID de pedido de prueba y confirme que la segunda llamada devuelve un código 409 o un rechazo similar por duplicación. Si ambas llamadas tienen éxito, su deduplicación no está funcionando y acumulará comisiones duplicadas en nuevos intentos de webhook.

La lista de conversiones de Tapfiliate muestra la fuente de atribución de cada registro. Puede filtrar por rango de fechas y confirmar que las conversiones pasaron por la API S2S. Si aparecen conversiones vía ruta JavaScript durante la prueba paralela, su middleware S2S no está capturando correctamente el ID de clic en la página de destino.

Para programas más grandes migrados de otra plataforma de afiliados, consulte la guía de migración de programas de afiliados de Tapfiliate.

Preguntas Frecuentes

¿Qué es el seguimiento de afiliados del lado servidor?

El seguimiento de afiliados del lado del servidor envía eventos de conversión directamente desde tu servidor backend a la API de la plataforma de afiliados, en lugar de depender de un píxel activado en el navegador del comprador. Como la señal de conversión proviene de tu servidor, no se ve afectada por bloqueadores de anuncios, restricciones de cookies en iOS o abandono de la página antes de que se cargue el JavaScript.

¿Qué es una URL de postback en el marketing de afiliados?

Una URL de postback es el endpoint de la API que tu servidor llama para reportar una conversión realizada. Cuando un comprador realiza una compra, tu backend envía el ID del clic almacenado al endpoint de la plataforma de afiliados. La plataforma asocia este ID con el clic original, atribuye la conversión al afiliado correspondiente y calcula la comisión correspondiente.

¿Qué es un ID de clic en el seguimiento de afiliados?

Un ID de clic es un identificador único generado cuando un usuario hace clic en un enlace de afiliado. Tu backend captura el código de referencia en la URL, realiza una llamada POST /clicks/ y recibe el ID de clic en respuesta. Lo almacenas en el servidor. En el momento de la compra, lo envías junto con el evento de conversión, sirviendo como prueba que conecta un clic específico con una venta específica sin usar cookies.

¿Cómo implementar el seguimiento S2S sin cookies?

Captura el parámetro ref de la URL en la primera solicitud en la página de destino del usuario. Realiza una llamada POST /clicks/ con el código de referencia y almacena el ID de clic devuelto en la sesión del servidor o en la base de datos. Cuando el usuario convierta, realiza una llamada POST /conversions/ con el ID de clic almacenado desde tu gestor de pagos backend. No se usa ninguna cookie en ninguna etapa. Consulta la documentación de la API REST de Tapfiliate para referencia completa de parámetros y esquemas de respuesta.

¿El seguimiento de afiliados del lado del servidor cumple con la LGPD?

Sí, cuando se implementa correctamente. El seguimiento S2S no utiliza cookies de terceros y ofrece control directo sobre los identificadores almacenados, su duración y base legal. Debes documentar el procesamiento de los IDs de clic en tus Registros de Actividades de Tratamiento, respetar solicitudes de eliminación y aplicar la minimización de datos. Comparado con el seguimiento por píxel, el seguimiento del lado del servidor generalmente reduce tu exposición a la LGPD, ya que el navegador ya no es el punto de recolección de datos.

Cierra la brecha

Tu sistema de gestión de pedidos ya tiene la verdad. Cada compra confirmada está registrada ahí.

La única pregunta es si tu programa de afiliados también está informado.

Tres llamadas API separan una tasa de atribución del 65% de una atribución casi completa. POST /clicks/ en la página de destino. ID de clic almacenado en la sesión. POST /conversions/ en la confirmación de compra.

El afiliado que generó 847 de estas 1,203 ventas merece una atribución precisa para esas 847. Tu programa merece los datos para identificar qué fuentes de tráfico realmente convierten y cuáles no.

Comienza tu prueba gratuita en Tapfiliate y conecta directamente tu backend a la API REST de Tapfiliate. No se requiere tarjeta de crédito. Adoptado por más de 69,500 profesionales de marketing y equipos técnicos.