Einleitung
Die Einschränkungen von Drittanbieter‑Cookies zwingen Affiliate‑Netzwerke, Tracking neu zu denken. Für Händler und Partner gilt: Wer Conversion‑Sichtbarkeit verliert, verliert Umsatz und Vertrauen. Affilentra bietet in seinen self‑hosted Editionen einen pragmatischen Weg, Tracking‑Lücken zu schließen: Identity‑Stitching auf Basis First‑Party‑Identifiers kombiniert mit serverseitiger Reconciliation. Dieser Beitrag erklärt, wie Sie Affilentra so konfigurieren und betreiben, dass Klicks, Leads und Sales auch ohne Third‑Party‑Cookies zuverlässig zugeordnet werden.
Prinzipien: Was Identity‑Stitching leisten muss
- First‑Party‑Identifiers: Erfassung von Daten, die der Händler selbst kontrolliert (z. B. gehashte E‑Mail, persistent serverseitige Link‑IDs).
- Server‑Side‑Reconciliation: Zusammenführen von Ereignissen (Click, Lead, Sale) auf Server‑Ebene statt allein durch Client‑Cookies.
- Rollen‑Trennung und Transparenz: Händler behalten Kontrolle über Produkte, Konditionen und Rohdaten; Partner sehen ihre Link‑IDs und Auszahlungshistorie.
Vorbereitungen in Affilentra (self‑hosted)
Bevor Sie mit Implementierung beginnen, prüfen Sie Ihre Affilentra‑Installation auf folgende Punkte:
- Edition: PRO oder NETWORK installiert und aktiviert.
- Rollen: Softwarebetreiber, Händler und Partner sind angelegt und die Rechte sauber getrennt.
- Webhook‑Konfiguration: Systemzugang zu Webhook‑Endpoints vorhanden (HTTPS, gültiges Zertifikat).
- Daten‑Schutzhinweise: Einwilligungsmechanismen für First‑Party‑Daten sind vorhanden und dokumentiert.
Schritt‑für‑Schritt‑Konfiguration
1) Erzeugung und Persistenz serverseitiger Link‑IDs
Workflow:
- Partner‑Links führen auf eine Affilentra‑Redirect‑URL. Beim Klick erzeugt Affilentra eine eindeutige, persistent gespeicherte link_id (UUID oder vergleichbar) und setzt diese als Query‑Parameter weiter auf die Merchant‑URL.
- Affilentra speichert link_id, Partner‑ID, Ziel‑URL, Timestamp und optionales Client‑Kontext‑Meta (z. B. campaign tag).
Konfigurationshinweis: Stellen Sie in Affilentra sicher, dass link_id langfristig und nicht an Browsersession‑Cookies gebunden gespeichert wird. Die link_id ist primärer Identifier zur späteren Rekonsolidierung.
2) Erfassung gehashter E‑Mails als First‑Party Identifier
Wenn Nutzer beim Händler eine E‑Mail eingeben (z. B. Lead, Registrierung, Kauf), sollte der Händler die Adresse vor der Übertragung an Affilentra normalisieren (Trim, Lowercase), salten und gehashed (z. B. HMAC‑SHA256). Affilentra speichert den Hash als first_party_email_hash.
Vorteil: Kein Klartext‑Transport, Erhalt eines stabilen Identifier, der geräteübergreifend genutzt werden kann, sobald der Nutzer seine E‑Mail angibt.
3) Server‑Side Postback für Conversions
Der Händler sendet Conversions serverseitig an Affilentra (statt alleinige Client‑Pixel). Minimaler Payload enthält:
- link_id (wenn vorhanden)
- first_party_email_hash (wenn vorhanden)
- order_id / transaction_id
- amount, currency
- timestamp
- signature (HMAC, zur Absicherung)
In Affilentra müssen Sie unter Einstellungen → Integrationen einen Postback‑Endpoint konfigurieren und eine HMAC‑Shared‑Secret hinterlegen.
Webhook‑Beispiele und Ablauf zur Re‑Konsolidierung
Nachfolgend ein vereinfachtes Beispiel, wie ein Händlerserver eine Conversion an Affilentra postet und wie Affilentra die Zuordnung vornimmt.
Beispiel‑Payload (POST)
- partner_id: 12345
- link_id: abcd‑ef01‑... (optional)
- first_party_email_hash: 9f86d081884c7... (optional)
- order_id: ORD‑2026‑0001
- amount: 99.90
- currency: EUR
- timestamp: 2026‑10‑24T12:34:56Z
- signature: HMAC_SHA256(payload, shared_secret)
Reconciliation‑Logik (Affilentra‑Seite)
- 1. Prüfen der Signatur; bei Fehlschlag: 401 und Logging.
- 2. Suche nach link_id → direkte Zuordnung zu Partner/Klick → Markiere Conversion als zugeordnet.
- 3. Falls kein link_id: Suche nach first_party_email_hash → falls Match zu existierendem Lead/Partner‑Mapping, Zuordnung herstellen.
- 4. Falls weiterhin kein Match: Fallback‑Matching anhand order_id/transaction_id gegen Bestelldaten oder manuelle Prüfung.
- 5. Ergebnis in Affilentra‑DB speichern; per Webhook oder Callback Partner informieren.
Empfohlenes Webhook‑Verhalten auf Händlersystem
- Implementieren Sie Retry‑Mechanismen (exponentielles Backoff) bei temporären Fehlern.
- Loggen Sie alle gesendeten Payloads mit Order‑ID und Status für Audits.
- Sichern Sie Webhook‑Aufrufe mit HMAC; legen Sie eine Rotationsstrategie für Secrets fest.
Fallback‑Identifier: Priorisierung und Empfehlungen
In cookieless Umgebungen brauchen Sie eine klare Priorisierung der Identifier. Empfohlene Reihenfolge:
- Persistente serverseitige link_id (beste Zuverlässigkeit für Klick→Sale‑Mapping).
- Gehashte First‑Party‑E‑Mail (stabil geräteübergreifend, sobald Nutzer E‑Mail angibt).
- Order‑ oder Transaction‑ID (eindeutige Referenz, zuverlässig für Umsatzzuordnung, weniger für Attribution).
- Server‑side Fingerprints (IP + User‑Agent + Timestamp hashed) nur als letzte Option und mit Datenschutz‑Prüfung.
Wichtig: Dokumentieren Sie die Priorisierung in Ihrem Partner‑Agreement und in Affilentra‑Einstellungen, damit Händler und Partner Nachvollziehbarkeit haben.
Beispiele für gängige Implementierungsfragen
Wie gehe ich mit Returning‑Users ohne E‑Mail vor?
Verlassen Sie sich auf die serverseitige link_id, die bei Klick erzeugt und in Ihrem Backend gespeichert wurde. Wenn der Nutzer später konvertiert, vergleicht das Merchant‑Backend die auf Bestellung referenzierten link_id‑Werte und sendet diese an Affilentra.
Was tun bei Mehrfach‑Attribution (z. B. mehrere Klicks)?
Definieren Sie in Affilentra eine klare Attribution‑Strategie (Last‑Click serverseitig, oder Time‑Decay) und implementieren Sie diese Logik in der Reconciliation‑Pipeline. Dokumentieren Sie, wie link_id‑Priorität gegenüber E‑Mail‑Matches wirkt.
Sicherheit und Datenschutz
- Hashing: Verwenden Sie sichere HMAC‑Verfahren mit einem Händler‑seitigen Salt, das nicht in Affilentra im Klartext gespeichert wird.
- Datenminimierung: Übertragen Sie nur den Hash, nicht die E‑Mail in Klartext.
- Einwilligung: Sorgen Sie dafür, dass die Verarbeitung der First‑Party‑Identifier rechtlich gedeckt ist (Consent Management).
Praxisbeispiel: Ablauf in 6 Schritten
- Partner‑Link klickt → Affilentra erzeugt link_id und redirectet zum Händler mit link_id in URL.
- Händler speichert link_id serverseitig an der Session/Bestellung.
- Nutzer kauft / registriert sich → Händler normalisiert und hasht die E‑Mail, erstellt order_id.
- Händler sendet serverseitigen POST an Affilentra mit link_id, first_party_email_hash, order_id und HMAC.
- Affilentra verifiziert, reconciliert (link_id → E‑Mail → order_id) und markiert Conversion; Partner wird benachrichtigt.
- Abrechnung und Auszahlung erfolgen transparent auf Basis der in Affilentra gespeicherten, verifizierten Conversion‑Daten.
Fazit und nächster Schritt
Cookieless‑Tracking erfordert eine serverseitige Denkweise: Erzeugen Sie persistente Link‑IDs, nutzen Sie gehashte First‑Party‑E‑Mails als stabilen Identifier und bauen Sie eine robuste Reconciliation‑Pipeline mit sicheren Webhooks. Affilentra als self‑hosted Plattform unterstützt diese Muster durch getrennte Rollen, persistente Link‑ID‑Speicherung, Webhook‑Integrationen und transparente Provisionsabrechnung.
Handeln Sie jetzt: Wählen Sie Ihren Einstieg in Affilentra und konfigurieren Sie serverseitige Link‑IDs sowie hashed E‑Mail‑Postbacks, um Tracking‑Lücken sofort zu reduzieren. Einstieg wählen: https://affilentra.de
Nächster Schritt
Affilentra selbst ausprobieren
Einheitliche Plattform, die Produktbereitstellung, Tracking, Conversion-Validierung, Provisionsberechnung und Auszahlung entlang klar getrennter Rollen transparent zusammenführt; Option zur self-hosted Installation mit Dauerlizenz ohne Umsatzbeteiligung; Händler behalten Kontrolle über Produkte, Konditionen und Werbemittel; Partner erhalten persönliche Trackinglinks und nachvollziehbare Auszahlungshistorie.