Introducción
Las limitaciones de las cookies de terceros obligan a las redes de afiliación a replantear el seguimiento. Para comerciantes y socios vale: quien pierde visibilidad de las conversiones, pierde ingresos y confianza. Affilentra ofrece en sus ediciones self‑hosted un enfoque pragmático para cerrar las brechas de seguimiento: Identity‑Stitching basado en identificadores first‑party combinado con reconciliación del lado servidor. Esta entrada explica cómo configurar y operar Affilentra de modo que los clics, leads y ventas se atribuyan de forma fiable incluso sin cookies de terceros.
Principios: Qué debe lograr el Identity‑Stitching
- First‑Party‑Identifiers: Captura de datos que el comerciante controla directamente (p. ej., E‑mail hasheado, link‑IDs persistentes almacenados en el servidor).
- Server‑Side‑Reconciliation: Consolidación de eventos (Click, Lead, Sale) a nivel de servidor en lugar de depender únicamente de cookies del cliente.
- Separación de roles y transparencia: Los comerciantes mantienen el control sobre productos, condiciones y datos en bruto; los socios ven sus link‑IDs e historial de pagos.
Preparativos en Affilentra (self‑hosted)
Antes de comenzar la implementación, revise su instalación de Affilentra en los siguientes puntos:
- Edition: PRO o NETWORK instalado y activado.
- Roles: Operador del software, comerciante y socio están creados y los permisos están claramente separados.
- Configuración de webhooks: El sistema tiene acceso a los endpoints de webhook (HTTPS, certificado válido).
- Avisos de privacidad: Mecanismos de consentimiento para datos first‑party están presentes y documentados.
Configuración paso a paso
1) Generación y persistencia de link‑IDs del lado servidor
Flujo de trabajo:
- Los enlaces de los socios llevan a una URL de redirección de Affilentra. Al hacer clic, Affilentra genera una link_id única, almacenada de forma persistente (UUID o similar) y la añade como parámetro de consulta a la URL del comerciante.
- Affilentra guarda link_id, Partner‑ID, URL de destino, marca temporal y metadatos opcionales del contexto cliente (p. ej., etiqueta de campaña).
Nota de configuración: Asegúrese en Affilentra de que la link_id se almacene a largo plazo y no esté vinculada a cookies de sesión del navegador. La link_id es el identificador primario para la posterior reconciliación.
2) Captura de correos electrónicos hasheados como identificador First‑Party
Cuando los usuarios proporcionan un correo electrónico en el sitio del comerciante (p. ej., lead, registro, compra), el comerciante debe normalizar la dirección antes de enviarla a Affilentra (trim, lowercase), añadir sal y hashearla (p. ej., HMAC‑SHA256). Affilentra almacena el hash como first_party_email_hash.
Ventaja: No se transmite texto plano, se conserva un identificador estable que puede utilizarse entre dispositivos una vez que el usuario facilite su correo.
3) Server‑Side Postback para conversiones
El comerciante envía conversiones al servidor de Affilentra (en lugar del único píxel del cliente). La carga útil mínima contiene:
- link_id (si está disponible)
- first_party_email_hash (si está disponible)
- order_id / transaction_id
- amount, currency
- timestamp
- signature (HMAC, para securizar)
En Affilentra debe configurar un endpoint de postback en Ajustes → Integraciones y almacenar un HMAC‑Shared‑Secret.
Ejemplos de Webhook y flujo para la re‑consolidación
A continuación un ejemplo simplificado de cómo un servidor de comerciante publica una conversión a Affilentra y cómo Affilentra realiza la asignación.
Payload de ejemplo (POST)
- partner_id: 12345
- link_id: abcd‑ef01‑... (opcional)
- first_party_email_hash: 9f86d081884c7... (opcional)
- order_id: ORD‑2026‑0001
- amount: 99.90
- currency: EUR
- timestamp: 2026‑10‑24T12:34:56Z
- signature: HMAC_SHA256(payload, shared_secret)
Lógica de reconciliación (lado de Affilentra)
- 1. Verificar la firma; si falla: 401 y registro de eventos.
- 2. Buscar link_id → asignación directa al socio/clic → marcar la conversión como asignada.
- 3. Si no hay link_id: buscar first_party_email_hash → si coincide con un lead/Mapeo de socio existente, establecer la asignación.
- 4. Si aún no hay coincidencia: matching de respaldo mediante order_id/transaction_id contra datos de pedido o revisión manual.
- 5. Guardar el resultado en la BD de Affilentra; notificar al socio vía Webhook o Callback.
Comportamiento recomendado de Webhook en el sistema del comerciante
- Implemente mecanismos de reintento (backoff exponencial) para errores temporales.
- Registre todas las cargas útiles enviadas con Order‑ID y estado para auditorías.
- Proteja las llamadas Webhook con HMAC; defina una estrategia de rotación para los secretos.
Identificadores de respaldo: priorización y recomendaciones
En entornos sin cookies necesita una priorización clara de los identificadores. Orden recomendado:
- link_id persistente del lado del servidor (mejor fiabilidad para el mapeo clic→venta).
- Correo electrónico first‑party hasheado (estable entre dispositivos una vez que el usuario facilita el e‑mail).
- Order‑ID o Transaction‑ID (referencia única, fiable para la atribución de ingresos, menos para atribución causal).
- Fingerprints del lado del servidor (IP + User‑Agent + timestamp hasheados) solo como última opción y tras comprobación de privacidad.
Importante: documente la priorización en su Acuerdo con Socios y en los ajustes de Affilentra, para que comerciantes y socios tengan trazabilidad.
Ejemplos de preguntas comunes de implementación
¿Cómo trato a usuarios recurrentes sin e‑mail?
Confíe en la link_id del lado del servidor, que se genera al hacer clic y se almacena en su backend. Cuando el usuario convierte más tarde, el backend del comerciante compara los valores de link_id referenciados en el pedido y los envía a Affilentra.
¿Qué hacer en caso de atribución múltiple (p. ej., varios clics)?
Defina en Affilentra una estrategia de atribución clara (último clic server‑side, o decaimiento temporal) e implemente esta lógica en la tubería de conciliación. Documente cómo la prioridad de la link_id afecta frente a las coincidencias por correo electrónico.
Seguridad y protección de datos
- Hashing: Utilice procedimientos HMAC seguros con una sal gestionada por el comerciante, que no se almacene en Affilentra en texto plano.
- Minimización de datos: Transmita únicamente el hash, no el correo electrónico en texto plano.
- Consentimiento: Asegúrese de que el procesamiento de los identificadores de primera parte esté cubierto legalmente (gestión de consentimientos).
Ejemplo práctico: Flujo en 6 pasos
- Enlace del partner clicado → Affilentra genera link_id y redirige al comerciante con la link_id en la URL.
- El comerciante almacena la link_id del lado del servidor en la sesión/pedido.
- El usuario compra / se registra → el comerciante normaliza y hashea el correo electrónico, crea order_id.
- El comerciante envía un POST server‑side a Affilentra con link_id, first_party_email_hash, order_id y HMAC.
- Affilentra verifica, reconcilia (link_id → correo electrónico → order_id) y marca la conversión; el partner es notificado.
- La facturación y el pago se realizan de forma transparente sobre la base de los datos de conversión verificados y almacenados en Affilentra.
Conclusión y siguiente paso
El seguimiento sin cookies requiere una mentalidad server‑side: genere link_ids persistentes, utilice correos electrónicos de primera parte hasheados como identificador estable y construya una tubería de conciliación robusta con webhooks seguros. Affilentra como plataforma self‑hosted soporta estos patrones mediante roles separados, almacenamiento persistente de link_id, integraciones de webhooks y una contabilidad transparente de comisiones.
Actúe ahora: Elija su punto de entrada en Affilentra y configure link_ids del lado del servidor así como postbacks de correo electrónico hasheados para reducir inmediatamente las brechas de seguimiento. Elegir punto de entrada: https://affilentra.de
Siguiente paso
Probar Affilentra por usted mismo
Plataforma unificada que reúne de forma transparente la provisión de productos, el seguimiento, la validación de conversiones, el cálculo de comisiones y los pagos a través de roles claramente separados; opción de instalación self‑hosted con licencia perpetua sin participación en ingresos; los comerciantes conservan el control sobre productos, condiciones y creatividades; los partners reciben enlaces de seguimiento personales e historial de pagos verificable.