Der Entwicklerleitfaden für serverseitiges Affiliate-Tracking

Der Entwicklerleitfaden für serverseitiges Affiliate-Tracking

In this article

Warum Pixel versagen (und warum Entwickler die Schuld tragen)

Wie serverseitiges Affiliate-Tracking funktioniert

Die Tapfiliate REST API: Ihr Implementierungs-Werkzeugkasten

Implementierungsleitfaden: Vollständige S2S-Konfiguration

Extremfälle, mit denen Entwickler tatsächlich konfrontiert werden

Datenschutz, Sicherheit und DSGVO

Testen Ihrer S2S-Implementierung

FAQ

Schließen Sie die Lücke

Schnelle Zusammenfassung: Serverseitiges Affiliate-Tracking ersetzt browserbasierte Pixel durch direkte API-Aufrufe von Ihrem Backend und erfasst jede Conversion unabhängig von Ad-Blockern, iOS-Datenschutzrichtlinien oder Cookie-Einschränkungen.

  • Das S2S-Tracking speichert eine Klick-ID serverseitig und sendet ein Postback an Tapfiliate, sobald eine Conversion erfolgt
  • Die Tapfiliate REST-API steuert dies über zwei Hauptaufrufe: POST /clicks/ beim Klick, POST /conversions/ beim Kauf
  • Die größte Herausforderung ist nicht der API-Aufruf, sondern die korrekte Speicherung der Klick-ID beim ersten Laden der Nutzerseite
  • Nach der Implementierung steigt die Conversion-Attribution von 60–70 % (Pixel, Mobile) auf nahezu 100 % Genauigkeit

Ihr Affiliate-Dashboard zeigt diesen Monat 847 Conversions an. Ihr Bestellverwaltungssystem hingegen 1.203.

Die Differenz entspricht 356 Verkäufen, die Ihr Affiliate-Programm nicht zuordnen konnte. Das sind 356 Provisionen, die auf Schätzungen basieren, oder 356 Verkäufe, die von Affiliates generiert, aber nicht honoriert wurden, weil ein Pixel nicht ausgelöst wurde.

In beiden Fällen entsteht ein finanzieller Verlust. Wenn das Marketingteam nachfragt, warum die Zahlen nicht übereinstimmen, lautet die Antwort stets: „das Pixel“.

Dieser Leitfaden erklärt, warum Pixel versagen, wie serverseitiges Tracking das Problem architektonisch löst und wie Sie es mit der Tapfiliate REST-API anhand eines funktionalen Codes implementieren.

Am Ende wird die Diskrepanz zwischen Ihren Bestellungen und zugeordneten Conversions endgültig beseitigt sein.

Warum Pixel versagen (und warum Entwickler die Schuld tragen)

Die drei Ausfallmodi des clientseitigen Trackings

Ein Tracking-Pixel wird im Browser des Käufers ausgelöst, wenn er Ihre Bestätigungsseite erreicht. In der Praxis versagt es auf drei vorhersehbare und unterschiedliche Arten.

Ad-Blocker. Erweiterungen wie uBlock Origin und Privacy Badger blockieren Tracking-Skripte standardmäßig. Die Nutzung von Ad-Blockern hat 2025 auf Desktops 40 % überschritten und wächst weiter.

iOS und Safari ITP. Apples Intelligent Tracking Prevention begrenzt die Lebensdauer von Drittanbieter-Cookies auf 24 Stunden nach der letzten Nutzerinteraktion mit dem Tracker. Ein Käufer, der montags auf einen Affiliate-Link klickt und mittwochs konvertiert, hat keinen nachverfolgbaren Cookie. Das Pixel wird ausgelöst, aber es gibt keine Daten zum Auslesen.

Seitenabbruch vor dem Laden. Bei langsamen mobilen Verbindungen können JavaScript-lastige Bestätigungsseiten drei bis fünf Sekunden zum vollständigen Laden benötigen. Schnelle Käufer schließen den Tab. Das Pixel-Skript wird nie ausgeführt.

Die realen Kosten der Attributionslücke

Die Differenz zwischen pixelgetrackten Conversions und tatsächlichen Bestellungen kann bei überwiegend mobilem Traffic 30–40 % erreichen, wenn man ITP-Cookie-Ablauf, Ad-Blocker und Seitenabbrüche zusammenzählt.

In einem Programm, das eine durchschnittliche Provision von 20 US-Dollar für 1.000 monatliche Conversions zahlt, entspricht diese Lücke 6.000–8.000 US-Dollar an falsch zugeordneten Provisionen. Affiliates erhalten Guthaben für Verkäufe, die sie nicht generiert haben, oder kein Guthaben für die, die sie generiert haben. Keines dieser Szenarien ist akzeptabel.

Serverseitiges Tracking eliminiert vollständig die Abhängigkeit vom Browser. Das Conversion-Ereignis wird von Ihrem Server an die Tapfiliate-API gesendet. Kein Pixel. Keine Browserabhängigkeit. Keine Lücken.

Wie serverseitiges Affiliate-Tracking funktioniert

Der Lebenszyklus der Klick-ID

Alles im serverseitigen Affiliate-Tracking basiert auf einem Konzept: der Klick-ID. Das Verständnis ihres Lebenszyklus macht die Implementierung klar.

Hier ist der vollständige End-to-End-Ablauf:

  1. Ein Nutzer klickt auf einen Affiliate-Link. Die URL enthält den Affiliate-Referenzcode, z. B. ?ref=sarah123.
  2. Ihr Server empfängt die Landingpage-Anfrage und erkennt den ref-Parameter in der URL.
  3. Ihr Backend macht einen POST /clicks/ Aufruf an die Tapfiliate REST-API und übermittelt den Referenzcode.
  4. Tapfiliate erstellt einen Klickdatensatz und gibt eine eindeutige Klick-ID für dieses spezifische Ereignis zurück.
  5. Ihr Backend speichert die Klick-ID, verknüpft mit der Serversitzung des Nutzers oder einer Datenbankzeile.
  6. Der Nutzer schließt einen Kauf ab. Ihr Bestellbestätigungs-Manager macht einen POST /conversions/ Aufruf und übermittelt die gespeicherte Klick-ID.
  7. Tapfiliate ordnet die Klick-ID dem ursprünglichen Affiliate zu, berechnet die Provision und schreibt das Affiliate-Konto gut.
  8. Der Affiliate sieht die Provision in Echtzeit in seinem Tapfiliate-Dashboard erscheinen.

Die Schritte 1 bis 5 erfolgen während der Anforderung der Zielseite. Die Schritte 6 bis 8 finden beim Bestellbestätigungsereignis statt. Der Browser des Käufers ist nur in Schritt 1 involviert, um den Parameter ref in der URL zu übermitteln.

Client-seitig vs. Server-seitig: der strukturelle Unterschied

Beim client-seitigen Tracking ist der Browser des Käufers die Quelle der Wahrheit. Er hält den Cookie, löst das Pixel aus und meldet die Conversion. Jegliches Versagen auf dem Gerät des Käufers führt zu verlorener Attribution.

Beim server-seitigen Tracking ist Ihr Backend die Quelle der Wahrheit. Es erfasst den Referral-Code bei Ankunft, erstellt den Klick, speichert die Klick-ID und löst das Conversion-Ereignis beim Kauf aus. Die Parameter des Käufer-Browsers sind unerheblich, sei es Cookie, JavaScript-Blockierung oder Web- vs. App-Kontext.

Client-seitig (Pixel)Server-seitig (API S2S)
Quelle des Conversion-SignalsKäufer-BrowserIhr Backend-Server
Auswirkung von Ad-BlockernBlockiert das Tracking-SkriptKeine Auswirkung
Auswirkung von iOS ITPCookie läuft nach 24 Stunden abKeine Auswirkung
Attributionsgenauigkeit (mobil)60–70 %Nahezu vollständig
Multi-Device-TrackingNeinJa (über Sitzung/Konto)
ImplementierungskomplexitätNiedrigMittel
GDPR-ExpositionHöher (Daten im Browser gespeichert)Niedriger (serverseitig kontrolliert)

Die Tapfiliate REST API: Ihr Implementierungs-Werkzeugkasten

Authentifizierung

Jede Anfrage an die Tapfiliate REST API erfordert einen Header:

X-Api-Key: YOUR_API_KEY

Ihr API-Schlüssel ist in Ihrem Tapfiliate-Konto unter Einstellungen verfügbar. Speichern Sie ihn in einer Umgebungsvariable. Kodieren Sie ihn niemals direkt im Quellcode. Senden Sie ihn niemals an ein Versionskontroll-Repository. Legen Sie ihn niemals im clientseitigen JavaScript offen.

Der API-Schlüssel ermöglicht das Erstellen von Conversions und die Genehmigung von Provisionen. Ein offengelegter Schlüssel stellt ein finanzielles Risiko dar, nicht nur ein Tracking-Risiko.

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

Alle Endpunkte verwenden Content-Type: application/json. Alle Antworten sind im JSON-Format. Die API befindet sich aktuell in Version 1.6. Für vollständige Endpunkt-Referenzen konsultieren Sie bitte die Tapfiliate REST API Dokumentation.

Eine schnelle Sicherheits-Checkliste für Ihren API-Schlüssel, bevor Sie eine einzige Tracking-Codezeile schreiben:

  • Speichern Sie den Schlüssel in einer Umgebungsvariable oder einem Geheimnis-Manager (AWS Secrets Manager, Vault, GCP Secret Manager).
  • Erneuern Sie den Schlüssel, wenn er jemals, auch kurzzeitig, in ein Repository hochgeladen wurde, selbst in einem privaten Repository.
  • Richten Sie eine Benachrichtigung ein, falls der Schlüssel in einem neuen Commit erkannt wird, z. B. mit Tools wie GitGuardian oder dem GitHub Secret Scanner.
  • Verwenden Sie unterschiedliche Schlüssel für Staging und Produktion. Ein Test im Staging mit einem Produktionsschlüssel löst echte Provisionen aus.

Dies ist nicht spezifisch für Tapfiliate. Es gilt für alle API-Schlüssel, die Ihr Backend verwaltet. Aber Affiliate-Plattform-Schlüssel sind besonders sensibel, da sie an der Schnittstelle von Geld und Partnervertrauen stehen.

Die drei wesentlichen Endpunkte

Für server-seitiges Affiliate-Tracking benötigen Sie zwei Hauptendpunkte und einen optionalen Endpunkt:

POST /clicks/
Erstellt einen Klick-Datensatz, wenn ein Nutzer über einen Affiliate-Link kommt. Senden Sie den Referral-Code des Affiliates. Tapfiliate gibt ein Klick-Objekt mit der Klick-ID zurück.

POST /conversions/
Erfasst eine Conversion, die mit einer gespeicherten Klick-ID verknüpft ist. Tapfiliate schreibt die Conversion dem richtigen Affiliate zu und stellt die Provision zur Auszahlung bereit. Senden Sie Ihre interne Bestell-ID als external_id, um Duplikate zu vermeiden.

POST /customers/ (optional)
Erstellt einen dauerhaften Kundendatensatz. Relevant für Abonnement- und SaaS-Programme, bei denen Sie den Customer Lifetime Value verfolgen und wiederkehrende Provisionszuweisungen bei mehreren Abrechnungsereignissen wünschen, nicht nur beim Erstkauf.

Tapfiliate unterstützt auch sekundäre Attribution über Referral-Code oder Promo-Code direkt im POST /conversions/. Wenn ein Nutzer ohne ref-Parameter kommt, aber beim Checkout einen Affiliate-Gutschein verwendet, können Sie den Promo-Code im Conversion-Call senden und die Attribution bleibt präzise.

Implementierungsleitfaden: Vollständige S2S-Konfiguration

Dieser Leitfaden verwendet Node.js. Das gleiche Prinzip gilt für Python, Go, Ruby oder jede andere Backend-Sprache. Ersetzen Sie die Fetch-Aufrufe durch Ihren bevorzugten HTTP-Client.

Schritt 1: Erfassen Sie den Affiliate-Ref-Parameter beim Landing

Jeder Besucher Ihrer Website kann einen Affiliate-Ref-Code in der URL enthalten oder auch nicht. Ihre Landing-Middleware sollte bei jeder Anfrage prüfen und bei Vorhandensein einen Klick erfassen.

// 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();});

Der try/catch-Block ist hier bewusst und essenziell. Die Klick-Erfassung darf niemals das Laden der Seite blockieren. Wenn die Tapfiliate-API langsam oder vorübergehend nicht erreichbar ist, kann der Nutzer Ihre Website trotzdem nutzen. Sie protokollieren den Fehler und fahren fort.

Schritt 2: Speichern Sie die Klick-ID serverseitig

Die Funktion createTapfiliateClick ruft POST /clicks/ auf und gibt die Klick-ID zurück.

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...", ... }}

Das Feld id in der Antwort ist die Klick-ID. Speichern Sie diese in der Serversession, in einem signierten Cookie mit aktivierten HttpOnly- und Secure-Flags oder in einer Datenbankzeile, die mit der Benutzersession verknüpft ist.

Speichern Sie sie nicht in einem für den Client zugänglichen Cookie oder im localStorage. Diese Speicherorte sind für Browsererweiterungen sichtbar und können manipuliert werden.

Schritt 3: Senden Sie das Conversion-Postback

Wenn ein Kauf abgeschlossen ist, rufen Sie POST /conversions/ von Ihrem Backend-Bestellmanager auf. Rufen Sie dies niemals von einem Frontend-Skript oder Tag-Manager auf.

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  }}

Integrieren Sie dies in Ihren Post-Payment-Webhook oder Ihre Bestellbestätigung:

// 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);});

Aus meiner Erfahrung ist der häufigste Implementierungsfehler, diesen Conversion-Aufruf auf der Frontend-Dankeseite per Skript oder GTM-Trigger auszulösen. Wenn der Käufer den Tab schließt, bevor die Seite vollständig geladen ist (was häufiger vorkommt als gedacht), geht die Conversion still verloren. Lösen Sie sie immer aus dem Backend-Zahlungsbestätigungsereignis aus.

Schritt 4: Überprüfen Sie im Tapfiliate-Dashboard

Nach Ihrer ersten Testtransaktion melden Sie sich in Ihrem Tapfiliate-Konto an und gehen zu Conversions. Bestätigen Sie, dass die Conversion mit dem richtigen Affiliate, dem Bestellwert und dem Status „Ausstehend“ angezeigt wird.

Eine 400-Antwort auf POST /conversions/ bedeutet meist, dass die Klick-ID ungültig oder abgelaufen ist. Ein 401 weist darauf hin, dass der API-Schlüssel-Header fehlt oder falsch ist. Für eine vollständige Liste der Fehlercodes und zusätzlicher Parameter, einschließlich wie Sie Metadaten oder Kunden-IDs an Conversions anhängen, lesen Sie bitte die Tapfiliate-Entwicklerintegrationsleitfäden.

Extremfälle, mit denen Entwickler tatsächlich konfrontiert werden

Fehlende Klick-IDs (Direktverkehr und Dark Social)

Nicht alle Besucher kommen über einen Affiliate-Link. Direktverkehr, E-Mail-Newsletter, SMS-Kampagnen und Dark-Social-Sharing enthalten keinen Ref-Parameter. Ihre Middleware findet nichts, speichert keine Klick-ID und weist keinen Affiliate zu.

Ich habe festgestellt, dass Teams diesen Fall oft nicht explizit behandeln. Null-Klick-IDs, die an POST /conversions/ gesendet werden, verursachen 400-Fehler, die wie Integrationsfehler aussehen. Das ist nicht der Fall. Es sind erwartete Situationen, die eine bedingte Verzweigung erfordern.

// 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 });}

Für Käufer, die ohne Ref-Parameter kommen, aber einen Affiliate-Promocode bei der Zahlung verwenden, können Sie den Promocode direkt im Conversion-Aufruf senden statt einer Klick-ID. Tapfiliate löst die Zuordnung anhand des Gutscheins auf.

Vermeidung von doppelten Conversions

Netzwerkverzögerungen führen zu mehrfachen Webhook-Neusendungen. Ohne Duplikaterkennung löst ein einzelner Kauf zwei oder drei Conversion-Events aus. Ihr Affiliate-Programm schreibt denselben Verkauf mehrfach gut.

Die Lösung ist das Feld external_id im POST /conversions/. Tapfiliate lehnt jede Conversion ab, die mit einer bereits in Ihrem Konto vorhandenen external_id gesendet wird.

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

Verwenden Sie immer Ihre interne Bestell-ID als external_id. Immer. Generieren Sie niemals bei jedem Neusendeversuch eine neue ID. Eine stabile Bestell-ID stellt sicher, dass der Endpunkt idempotent ist. Sie können so oft versuchen, wie nötig, ohne doppelte Provisionen zu erzeugen.

Multitouch- und Sitzungsübergreifende Attribution

Ein Nutzer interagiert oft mit mehreren Affiliate-Links, bevor er konvertiert. Er klickt montags auf einen Instagram-Beitrag von Affiliate A. Donnerstags klickt er auf einen Blog-Link von Affiliate B. Freitags tätigt er den Kauf.

Das Standardmodell von Tapfiliate schreibt die Provision dem letzten Klick zu, also Affiliate B. Wenn Ihr Programmmodell die First-Touch-Attribution verwendet, können Sie die erste gespeicherte Klick-ID beibehalten, indem Sie prüfen, ob sie bereits in der Session existiert, bevor Sie sie überschreiben:

// 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;}

Welches Modell Sie verwenden, hängt von den Regeln Ihres Programms ab. Die Implementierung ist in beiden Fällen identisch. Der Unterschied besteht darin, ob die gespeicherte Klick-ID bei nachfolgenden Besuchen von Affiliate-Links überschrieben wird oder nicht.

Datenschutz, Sicherheit und DSGVO

Geben Sie Ihren API-Schlüssel niemals auf der Client-Seite preis

Der Header X-Api-Key authentifiziert Anfragen, die Conversions erstellen und Provisionen validieren. Es handelt sich nicht um einen reinen Lese-Analyse-Token.

Wenn der Schlüssel in einer Netzwerk-Anfrage des Browsers erscheint (z. B. in einer React-Komponente, einem benutzerdefinierten HTML-Tag im GTM oder einer Segment-Source-Funktion), kann jeder Nutzer ihn über die Entwicklertools des Browsers auslesen. Dadurch könnten betrügerische Conversions für jeden Affiliate Ihres Programms generiert werden.

Alle REST-API-Aufrufe von Tapfiliate müssen von Ihrem Backend stammen. Ihr JavaScript-Frontend hat keinen legitimen Grund, die Tapfiliate-API aufzurufen. Wenn Sie einen clientseitigen Tag-Manager mit Ihrer S2S-Implementierung verwenden, stellen Sie sicher, dass die Integration des Tag-Managers eine separate und isolierte Datenschicht nutzt. Übermitteln Sie Ihren API-Schlüssel niemals darüber.

DSGVO und Datenminimierung für Klick-IDs

Eine Klick-ID ist ein pseudonymisierter Bezeichner, der in Kombination mit anderen Daten einer Person zugeordnet werden kann. Je nach Verarbeitungskontext kann sie als personenbezogenes Datum unter der DSGVO gelten.

Praktische Compliance-Maßnahmen:

  1. Setzen Sie eine Aufbewahrungsfrist. Das Standard-Attributionsfenster von Tapfiliate beträgt 30 Tage. Löschen Sie gespeicherte Klick-IDs in Ihrer Session oder Datenbank nach 30 Tagen ohne Conversion.
  2. Vermeiden Sie unnötige Verknüpfungen. Speichern Sie Klick-IDs nicht in derselben Datenbankzeile wie direkt identifizierbare Daten (Name, E-Mail) ohne dokumentierte Rechtsgrundlage.
  3. Integrieren Sie das Management der Klick-IDs in Ihren Datenverarbeitungsvertrag mit Tapfiliate. Der DPA regelt die Daten, die Tapfiliate in Ihrem Auftrag verarbeitet.
  4. Erfüllen Sie Löschanfragen. Anfragen zum Recht auf Löschung müssen auch die Entfernung der gespeicherten Klick-IDs zu diesem Nutzer umfassen.

Für Programme mit EU-Nutzern dokumentieren Sie die Verarbeitung der Klick-IDs in Ihren Verzeichnissen von Verarbeitungstätigkeiten. Für eine vertiefte Lektüre zur S2S-Integration im Influencer-Tracking lesen Sie das hybride Influencer-Tracking mit Affiliate-Software.

Testen Ihrer S2S-Implementierung

Validierung des parallelen Trackings

Bevor Sie Ihr bestehendes Pixel-Tracking deaktivieren, lassen Sie beide Systeme mindestens 48 Stunden parallel laufen. So können Sie die Conversion-Zahlen vergleichen und Probleme bei der Speicherung der Klick-IDs erkennen, ohne Attributionsdaten zu verlieren.

Testprotokoll:

  1. Aktivieren Sie Ihren S2S-Postback-Code parallel zum bestehenden Client-seitigen Pixel.
  2. Generieren Sie 10 bis 20 kontrollierte Testtransaktionen über Ihre eigenen Affiliate-Links.
  3. Vergleichen Sie die Anzahl der Conversions in Tapfiliate mit Ihrem Auftragsverwaltungssystem.
  4. Wenn die Zahlen für die 10 bis 20 Testbestellungen übereinstimmen: funktioniert das S2S korrekt. Deaktivieren Sie das Pixel.
  5. Bei Abweichungen: Prüfen Sie zuerst die Logik zur Abfrage der Klick-IDs im Zahlungs-Manager. Die häufigste Ursache ist das Session-Timeout zwischen Zugriff und Kauf bei längeren Entscheidungsprozessen.

Eine praktische Methode zum Testen ohne echte Bestellungen: Nutzen Sie das Tapfiliate-Test-Affiliate-Konto und eine Pre-Production-Umgebung. Erstellen Sie einen Test-Affiliate, klicken Sie im Inkognito-Modus auf Ihren eigenen Affiliate-Link, tätigen Sie einen Testkauf und prüfen Sie anschließend, ob die Conversion im Tapfiliate-Dashboard erscheint. So erhalten Sie einen vollständigen End-to-End-Test ohne Beeinträchtigung der Produktionsdaten.

Ein letzter Check: Stellen Sie sicher, dass Ihre external_id-Deduplizierung funktioniert. Senden Sie dieselbe Testbestell-ID zweimal und bestätigen Sie, dass der zweite Aufruf einen 409-Code oder eine ähnliche Duplikat-Ablehnung zurückgibt. Wenn beide Aufrufe erfolgreich sind, funktioniert Ihre Deduplizierung nicht und Sie sammeln bei erneuten Webhook-Versuchen doppelte Provisionen.

Die Tapfiliate-Conversion-Liste zeigt die Attributionsquelle jedes Eintrags. Sie können nach Datumsbereich filtern und bestätigen, dass die Conversions über die S2S-API liefen. Wenn während des parallelen Tests Conversions über den JavaScript-Pfad erscheinen, erfasst Ihre S2S-Middleware die Klick-ID auf der Landingpage nicht korrekt.

Für größere Programme, die von einer anderen Affiliate-Plattform migriert wurden, lesen Sie den Tapfiliate Affiliate-Programm-Migrationsleitfaden.

FAQ

Was ist serverseitiges Affiliate-Tracking?

Serverseitiges Affiliate-Tracking sendet Conversion-Events direkt von Ihrem Backend-Server an die API der Affiliate-Plattform, anstatt sich auf ein im Browser des Käufers ausgelöstes Pixel zu verlassen. Da das Conversion-Signal von Ihrem Server stammt, wird es nicht von Werbeblockern, Cookie-Einschränkungen auf iOS oder Seitenabbruch vor dem Laden von JavaScript beeinträchtigt.

Was ist eine Postback-URL im Affiliate-Marketing?

Eine Postback-URL ist der API-Endpunkt, den Ihr Server aufruft, um eine erfolgte Conversion zu melden. Wenn ein Käufer einen Kauf tätigt, sendet Ihr Backend die gespeicherte Klick-ID an den Endpunkt der Affiliate-Plattform. Die Plattform verknüpft diese ID mit dem ursprünglichen Klick, schreibt die Conversion dem entsprechenden Affiliate zu und berechnet die fällige Provision.

Was ist eine Klick-ID im Affiliate-Tracking?

Eine Klick-ID ist ein eindeutiger Identifikator, der generiert wird, wenn ein Nutzer auf einen Affiliate-Link klickt. Ihr Backend erfasst den Referenzcode in der URL, führt einen POST-Aufruf an /clicks/ aus und erhält die Klick-ID als Antwort. Diese speichern Sie auf dem Server. Zum Zeitpunkt des Kaufs senden Sie diese zusammen mit dem Conversion-Event, was als Nachweis dient, der einen spezifischen Klick mit einem spezifischen Verkauf ohne Verwendung von Cookies verbindet.

Wie implementiert man Cookie-freies S2S-Tracking?

Erfassen Sie den Ref-Parameter aus der URL bei der ersten Anfrage auf der Zielseite des Nutzers. Führen Sie einen POST-Aufruf an /clicks/ mit dem Referenzcode durch und speichern Sie die zurückgegebene Klick-ID in der Serversitzung oder Datenbank. Wenn der Nutzer konvertiert, führen Sie einen POST-Aufruf an /conversions/ mit der gespeicherten Klick-ID aus Ihrem Backend-Zahlungsmanager durch. Es werden keine Cookies in irgendeinem Schritt verwendet. Siehe die Tapfiliate REST API-Dokumentation für vollständige Parameter- und Antwortschemas.

Ist serverseitiges Affiliate-Tracking DSGVO-konform?

Ja, wenn es korrekt implementiert wird. S2S-Tracking verwendet keine Drittanbieter-Cookies und bietet direkte Kontrolle über gespeicherte Identifikatoren, deren Dauer und Rechtsgrundlage. Sie müssen die Verarbeitung der Klick-IDs in Ihren Verarbeitungsverzeichnissen dokumentieren, Löschanfragen respektieren und Datenminimierung anwenden. Im Vergleich zum Pixel-Tracking reduziert serverseitiges Tracking in der Regel Ihre DSGVO-Exposition, da der Browser nicht mehr der Datenerfassungspunkt ist.

Schließen Sie die Lücke

Ihr Bestellverwaltungssystem hält bereits die Wahrheit. Jeder bestätigte Kauf ist dort erfasst.

Die einzige Frage ist, ob Ihr Affiliate-Programm ebenfalls informiert ist.

Drei API-Aufrufe trennen eine Attributionsrate von 65 % von einer nahezu vollständigen Attribution. POST /clicks/ auf der Landingpage. Klick-ID in der Sitzung gespeichert. POST /conversions/ bei Kaufbestätigung.

Der Affiliate, der 847 dieser 1.203 Verkäufe generiert hat, verdient eine präzise Attribution für diese 847. Ihr Programm benötigt die Daten, um zu erkennen, welche Traffic-Quellen tatsächlich konvertieren und welche nicht.

Starten Sie Ihre kostenlose Testphase bei Tapfiliate und verbinden Sie Ihr Backend direkt mit der Tapfiliate REST API. Keine Kreditkarte erforderlich. Genutzt von über 69.500 Marketingexperten und technischen Teams.

Jessica Rangel

Jessica Rangel

Spending my days writing marketing content, cycling around canals in Amsterdam, and attempting to master the Dutch language.

In this article

Warum Pixel versagen (und warum Entwickler die Schuld tragen)

Wie serverseitiges Affiliate-Tracking funktioniert

Die Tapfiliate REST API: Ihr Implementierungs-Werkzeugkasten

Implementierungsleitfaden: Vollständige S2S-Konfiguration

Extremfälle, mit denen Entwickler tatsächlich konfrontiert werden

Datenschutz, Sicherheit und DSGVO

Testen Ihrer S2S-Implementierung

FAQ

Schließen Sie die Lücke

Mobile sign-up can be tricky

Drop your contact info, and get a detailed guide to test Tapfiliate faster and effectively

I consent to processing of my personal data, and confirm that I have read and understood the Privacy Policy of Tapfiliate.
Sign up on mobile
Tapfiliate blog subscribe

Don’t miss what matters in affiliate marketing.

We pick the best and send it to your inbox.