Réseau d'affiliation et trafic

1) Rôles et modèles de coopération

Affiliations : webmaster, médias, sites de contenu, influenceurs, applications, agrégateurs.
Gestionnaire de réseau (votre plateforme) : règles, créatifs, tracking, PRM, paiements.

• CPA - frais pour l'action confirmée (inscription/dépôt/achat).
• CPL - Frais de lead (formulaire/demande) avec les qualifications.
• RevShare - % de marge/chiffre d'affaires (souvent longue queue).
• Hybrid — CPA + RevShare; parfois avec des garanties minimales.
• Finparamètres : cold/fenêtre de validation, clawback (retour à frode/refande), caps (limites journalières/hebdomadaires), tires de paiement.

2) Architecture de suivi et d'attribution

2. 1 Modèle d'événement

Étapes clés : 'click → visit → signup → qualify → target_action (e. g., FT, purchase) → retention events`.

json
{
"event_id": "uuid",
"occurred_at_utc": "2025-10-31T12:45:10Z",
"type": "affiliate.target_action.v1",
"affiliate_id": "aff_001",
"campaign_id": "cmp_42",
"click_id": "c_abc123",
"user_pseudo_id": "u_... (hashed)",
"amount": 49.90,
"currency": "EUR",
"status": "qualified",
"signature": "base64/Ed25519",
"version": 1
}

2. 2 Attribution

Fenêtre : 7-30 jours par clic (ou 24-72 heures par view-through si autorisé).
Modèle : last-click le plus souvent ; data-driven est autorisé pour les grands réseaux.
Priorité des canaux : payant/marque/organique - fixer la matrice de priorité.
Déduplication : Par 'event _ id '/' click _ id' + empreinte de session, serveur (S2S).

2. 3 S2S postbacks et événements c2s

S2S post-back : serveur-k-serveur pour capturer l'action cible (fiabilité, confidentialité).
c2s-stream : les événements du client → votre backend → la normalisation → postback au partenaire (signé).
Idempotence : clé d'idempotence = 'affiliate _ id + click_id + action_type'.

POST https://aff.example/postback
Headers:
X-Signature: ed25519:...
X-Timestamp: 1730388405
Body:
click_id=c_abc123&status=qualified&amount=49.90&currency=EUR&event_id=uuid

3) Antifrod et contrôle de qualité

Vecteurs : bots, trafic incentivized/de mauvaise qualité, cookies de stuffing, échange de références, proxy/émulateurs, « fermes » d'enregistrements.

• Signatures et réputation : device signals, ASN/feuilles proxy, chèque velocity, métriques comportementales (dwell time, scroll, focus).
• Quality score (q-score): композит `q = w1cohort_retention + w2FT_rate + w3refund_rate^-1 + w4fraud_signals^-1`.
• Limites et capes : « accélération » au fur et à mesure de la vérification ; resserrement automatique en cas d'éclatement.
• Qualification différée (cool-off) : confirmation de CPA après N jours d'activité/sans charge.
• Honey-tokens : « pièges » dans les lendings/SDK pour détecter les parsers et les bots de clic.
• Consentement et vie privée : cookies bannières/CMPl, mode sans cookie 3rd-party → accent mis sur le S2S.

4) Créatifs, Lendings et UX

Catalogue créatif : versions/localisation, règles de marque, paramètres UTM, modèles deeplink.
Lendings : TTV rapide (forme simple, login social), tests A/B, contenu par géo/appareil.
Politiques : Verticales/mots interdits, réserves sur les limites d'âge, responsabilité pour les créations trompeuses.
Vitesse : LCP <2. 5s; p95 timing landing fait partie du SLO pour l'affiliation.

5) Processus PRM (Partner Relationship Management)

5. 1 Onbording

Questionnaire, CUS/sanctions, confirmation des sources de trafic, domaines/applications.
Accords : MSA/IO, politique de contenu, DPA (s'il y a une DP), règles d'attribution.
Tehstart : clés API, bac à sable, tests post-back.

5. 2 Opérations

QBR/MBR (examen), objectifs et caps, bibliothèque créative, tiquets de sapport.
Changements de campagne : versions, lancements canariens, périodes freeze sur les grandes versions.
Sanctions/blocages : seuil frod → auto-pause, enquête, rapports.

5. 3 Sortie/modification

Rotation des clés/révocation des tokens, fermeture des campagnes, déchargement des rapports, calculs finaux.

6) Métriques et analyses

• CR (visit→signup, signup→action)
• ARPU/LTV cohorte affiliation/campagne/geo eCPA/eCPL/eROAS
• FT rate / Repeat rate / Retention w4/w8
• Refund/Chargeback rate, Clawback%
• q-score par source, « cartes thermiques » de qualité

utm_source=aff_network&utm_medium=cpa&utm_campaign=cmp_42&utm_content=ban_01&utm_term=kw aff_id=aff_001&click_id=c_abc123&geo=TR&lang=tr

sql
SELECT cohort_week,
aff_id,
COUNT(DISTINCT user_id) AS users,
SUM(first_deposit_amount) AS gmv,
SUM(margin) AS net_rev,
SUM(payout) AS payout,
SUM(margin) - SUM(payout) AS contrib
FROM fact_users
GROUP BY 1,2;

7) Calculs, reconnaissance et paiements

7. 1 Règles de calcul

Base de paiement : net-basis (après frais/taxes/bonus) ou grosss - indiquer explicitement.
Fenêtres : T + N (jours/semaines), devises, taux de conversion, invoice/credit note.
Clawback : débite à la frode/chargbacks dans la fenêtre.

7. 2 Reconciliation

Rapports bilatéraux (votre rapport d'affiliation), tolérances de ε, dedup par 'event _ id'.
SLA Fermeture des écarts (par exemple, 5 jours ouvrables ≤), journal des commentaires.

sql
SELECT a.event_id
FROM partner_report a
LEFT JOIN internal_events b ON a.event_id = b.event_id
WHERE a.date BETWEEN:from AND:to
AND b.event_id IS NULL;

8) Politiques en tant que code (gate's)

rego package affiliate.policies

deny["Weak signature"] {
input.webhook.signature.alg not in {"HMAC-SHA256","Ed25519"}
}

deny["No attribution window"] {
not input.campaign.attribution.window_days
}

deny["Fraud spike"] {
input.metrics.fraud_rate > 0.7 input.metrics.signup_to_action_cr < 0.05
}

deny["PII in logs"] {
some f f:= input.logs[_]
contains(f, "ssn") # пример
}

9) Conformité et vie privée

Transparence : disclosure pour le matériel publicitaire, limites d'âge, normes publicitaires locales.
Privacy : minimisation des données aux partenaires (pseudonymes, agrégats), droit de suppression, TTL.
Zones légales : géo-ciblage, interdiction de trafic à partir de régions restreintes, stockage dans des emplacements autorisés.
Anti-coercition : interdiction des incitations « toxiques » (trompeuses).
Journaux d'accès : qui a vu quelles données, rapports d'audit.

10) Modèles et exemples

10. 1 Passeport d'affiliation (YAML)

yaml affiliate_id: "aff_001"
name: "Acme Media"
regions: ["EU","TR","LATAM"]
traffic_sources: ["SEO","Content","Push"]
contracts:
model: "Hybrid"
cpa: 60 revshare: "20% of net"
hold_days: 14 attribution:
window_days: 30 priority_matrix: ["affiliate>paid>brand>organic"]
tech:
postback_url: "https://acme.example/postback"
signature: "Ed25519"
test_click_id: "TEST123"
policies:
caps: { daily: 200, weekly: 1000 }
banned_keywords: ["free money", "no risk"]
quality:
min_q_score: 0.6 cool_off_days: 7 status: "active"
owner: "aff-team-emea"

10. 2 Validateur post-back (pseudo-code)

python def verify_postback(req, key):
ts = int(req.h["X-Timestamp"])
if abs(now()-ts) > 300: return 401 if not ed25519_ok(req.body, req.h["X-Signature"], key): return 401 if seen(req.form["event_id"]): return 200 save_event(req.form); mark_seen(req.form["event_id"]); return 200

10. 3 Formule q-score (exemple)

python q = 0.35retention_w4 + 0.25ft_rate + 0.2(1-refund_rate) + 0.2(1-fraud_score)

10. 4 Règles de déduplication

dedupe_key = SHA256(affiliate_id    click_id    action_type    user_pseudo_id    date)

11) Anti-modèles

Seulement cookie tracking sans S2S → perte d'attribution.
Les CPA « aveugles » sans contrôle de qualité/rétention → épuisement budgétaire.
L'absence de hold/cool-off → les paiements surévalués et les différends.
Le mélange gross/net dans les calculs → des divergences éternelles.
La seule affiliation supergroupe → le risque de concentration.
Il n'y a pas de limites automatiques lors de l'éclatement de la fronde → des pertes massives.
PII dans les logs/webhooks → les risques de confidentialité et les amendes.

12) Chèque de l'architecte

1. Modèle de paiement enregistré, base de calcul et fenêtres (hold, clawback) ?
2. Mise en œuvre du suivi S2S avec signature et idempotence ?
3. Les fenêtres d'attribution et la priorité des canaux sont définies, le dedup fonctionne ?
4. Les signaux antifrod et q-score sont-ils intégrés, les caps et l'auto-pause ?
5. Processus PRM : onbording/KUS, créatifs, bac à sable, tests de cas post-back ?
6. Dashboards : CR, eCPA, LTV, retraite, refund/clawback, q-score ?
7. Reconciliation : rapports bilatéraux, ε, SLA de clôture des différends ?
8. Les politiques en tant que code dans CI/CD/PRM (signatures, fenêtres, ban-list) ?
9. Vie privée : minimum de PD, pseudonymes, TTL, droit de suppression ?
10. Plan d'incident : spike frod, temps d'arrêt post-back, rapports dissynchrones ?

Conclusion

Un réseau d'affiliation fort est un système d'ingénierie, pas seulement le marketing. Lorsque l'attribution est serveur et transparente, que la qualité du trafic est mesurée et gérée, que les processus PRM sont standardisés et que les calculs sont validés par la base de données et le « policy as code », le canal s'adapte de manière prévisible : eCPA est stable, LTV augmente, les différends sont rares et les partenaires investissent volontiers dans votre trafic.