Introduction
Les restrictions des cookies tiers obligent les réseaux d'affiliation à repenser le suivi. Pour les commerçants et les partenaires : qui perd la visibilité sur les conversions perd des revenus et la confiance. Affilentra propose, dans ses éditions self‑hosted, une approche pragmatique pour combler les lacunes du tracking : l'Identity‑Stitching fondé sur des identifiants first‑party combiné à une réconciliation côté serveur. Cet article explique comment configurer et exploiter Affilentra afin que clics, leads et ventes soient attribués de manière fiable même sans cookies tiers.
Principes : ce que doit accomplir l'Identity‑Stitching
- Identifiants first‑party : collecte de données contrôlées par le commerçant lui‑même (p. ex. e‑mail haché, link_id persistante côté serveur).
- Réconciliation côté serveur : fusion des événements (clic, lead, vente) au niveau serveur plutôt que de se reposer uniquement sur des cookies client.
- Séparation des rôles et transparence : le commerçant conserve le contrôle des produits, des conditions et des données brutes ; les partenaires voient leurs link_id et l'historique des paiements.
Préparations dans Affilentra (self‑hosted)
Avant de commencer l'implémentation, vérifiez votre installation Affilentra sur les points suivants :
- Édition : PRO ou NETWORK installée et activée.
- Rôles : opérateur logiciel, commerçant et partenaire créés et droits strictement séparés.
- Configuration des webhooks : accès système aux endpoints Webhook disponible (HTTPS, certificat valide).
- Mentions relatives à la protection des données : mécanismes de consentement pour les données first‑party mis en place et documentés.
Configuration pas à pas
1) Génération et persistance des link_id côté serveur
Flux de travail :
- Les liens partenaires pointent vers une URL de redirection Affilentra. Au clic, Affilentra génère une link_id unique, persistante (UUID ou équivalent) et la transmet en paramètre de requête vers l'URL du commerçant.
- Affilentra enregistre la link_id, l'ID du partenaire, l'URL de destination, l'horodatage et éventuellement un méta‑contexte client (p. ex. tag de campagne).
Conseil de configuration : assurez‑vous dans Affilentra que la link_id est stockée de façon durable et n'est pas liée aux cookies de session du navigateur. La link_id est l'identifiant principal pour la réconciliation ultérieure.
2) Collecte des e‑mails hachés comme identifiant first‑party
Lorsque l'utilisateur saisit une adresse e‑mail chez le commerçant (p. ex. lead, inscription, achat), le commerçant doit normaliser l'adresse avant transmission à Affilentra (trim, minuscules), la saler et la hacher (p. ex. HMAC‑SHA256). Affilentra stocke le hash sous first_party_email_hash.
Avantage : pas de transport en clair, conservation d'un identifiant stable pouvant être utilisé sur plusieurs appareils dès que l'utilisateur fournit son e‑mail.
3) Postback côté serveur pour les conversions
Le commerçant envoie les conversions côté serveur à Affilentra (au lieu d'un simple pixel client). La charge utile minimale contient :
- link_id (si disponible)
- first_party_email_hash (si disponible)
- order_id / transaction_id
- amount, currency
- timestamp
- signature (HMAC, pour sécurisation)
Dans Affilentra, vous devez configurer un endpoint de postback sous Paramètres → Intégrations et enregistrer un secret partagé HMAC.
Exemples de webhook et processus de re‑consolidation
Ci‑dessous un exemple simplifié montrant comment un serveur marchand poste une conversion à Affilentra et comment Affilentra effectue l'attribution.
Exemple de payload (POST)
- partner_id: 12345
- link_id: abcd‑ef01‑... (optionnel)
- first_party_email_hash: 9f86d081884c7... (optionnel)
- order_id: ORD‑2026‑0001
- amount: 99.90
- currency: EUR
- timestamp: 2026‑10‑24T12:34:56Z
- signature: HMAC_SHA256(payload, shared_secret)
Logique de réconciliation (côté Affilentra)
- 1. Vérifier la signature ; en cas d'échec : 401 et journalisation.
- 2. Rechercher le link_id → attribution directe au partenaire/clic → marquer la conversion comme attribuée.
- 3. Si pas de link_id : rechercher le first_party_email_hash → si correspondance avec un lead/mapping partenaire existant, effectuer l'attribution.
- 4. Si toujours pas de correspondance : appariement de secours basé sur order_id/transaction_id contre les données de commande ou examen manuel.
- 5. Enregistrer le résultat dans la base de données Affilentra ; informer le partenaire via webhook ou callback.
Comportement webhook recommandé sur le système du commerçant
- Implémentez des mécanismes de retry (backoff exponentiel) pour les erreurs temporaires.
- Consignez tous les payloads envoyés avec l'order_id et le statut pour les audits.
- Sécurisez les appels webhook avec HMAC ; définissez une stratégie de rotation des secrets.
Identifiants de secours : priorisation et recommandations
Dans des environnements sans cookies, vous avez besoin d'une priorisation claire des identifiants. Ordre recommandé :
- link_id persistante côté serveur (meilleure fiabilité pour le mapping clic→vente).
- Adresse e‑mail first‑party hachée (stable entre appareils dès que l'utilisateur fournit son e‑mail).
- Order‑ ou transaction‑ID (référence unique, fiable pour l'attribution de chiffre d'affaires, moins pour l'attribution marketing).
- Fingerprints côté serveur (IP + User‑Agent + timestamp hachés) uniquement en dernier recours et après vérification conformité RGPD.
Important : documentez la priorisation dans votre contrat partenaire et dans les paramètres Affilentra afin que commerçants et partenaires disposent de traçabilité.
Exemples de questions fréquentes d'implémentation
Comment gérer les utilisateurs revenants sans e‑mail ?
Fiez‑vous à la link_id côté serveur, générée au clic et stockée dans votre backend. Quand l'utilisateur convertit plus tard, le backend du marchand compare les valeurs link_id référencées sur la commande et les envoie à Affilentra.
Que faire en cas d'attribution multiple (p. ex. plusieurs clics) ?
Définissez dans Affilentra une stratégie d'attribution claire (Last‑Click côté serveur, ou Time‑Decay) et implémentez cette logique dans la pipeline de réconciliation. Documentez comment la priorité de la link_id agit par rapport aux correspondances par e‑mail.
Sécurité et protection des données
- Hashing : Utilisez des procédures HMAC sécurisées avec un sel côté marchand, qui n'est pas stocké en clair dans Affilentra.
- Minimisation des données : Transmettez uniquement le hash, pas l'e‑mail en clair.
- Consentement : Assurez‑vous que le traitement des identifiants first‑party est couvert légalement (gestion du consentement).
Exemple pratique : déroulement en 6 étapes
- Le lien partenaire est cliqué → Affilentra génère une link_id et redirige vers le marchand avec la link_id dans l'URL.
- Le marchand enregistre la link_id côté serveur dans la session/la commande.
- L'utilisateur achète / s'enregistre → le marchand normalise et hash l'e‑mail, crée un order_id.
- Le marchand envoie un POST serveur à Affilentra avec link_id, first_party_email_hash, order_id et HMAC.
- Affilentra vérifie, réconcilie (link_id → e‑mail → order_id) et marque la conversion ; le partenaire est notifié.
- La facturation et le paiement s'effectuent de manière transparente sur la base des données de conversion vérifiées et stockées dans Affilentra.
Conclusion et prochaine étape
Le suivi sans cookies exige une approche côté serveur : générez des Link‑ID persistantes, utilisez des e‑mails first‑party hachés comme identifiant stable et construisez une pipeline de réconciliation robuste avec des webhooks sécurisés. Affilentra en tant que plateforme self‑hosted prend en charge ces modèles via des rôles séparés, le stockage persistant des Link‑ID, des intégrations webhook et une facturation des commissions transparente.
Agissez maintenant : Choisissez votre point d'entrée dans Affilentra et configurez des Link‑ID côté serveur ainsi que des postbacks d'e‑mail hachés pour réduire immédiatement les lacunes de suivi. Choisir un point d'entrée : https://affilentra.de
Étape suivante
Essayer Affilentra soi‑même
Plateforme unifiée qui regroupe de manière transparente la mise à disposition des produits, le suivi, la validation des conversions, le calcul des commissions et le paiement selon des rôles clairement séparés ; option d'installation self‑hosted avec licence perpétuelle sans participation au chiffre d'affaires ; les marchands conservent le contrôle sur les produits, les conditions et les supports publicitaires ; les partenaires reçoivent des liens de suivi personnels et un historique de paiements traçable.