Conversion-Tracking für Kurzlinks: Klick-Kennungen, Fenster und Server-Ereignisse

Jeder Linkbericht hat einen natürlichen Endpunkt, und für die meisten Teams ist es der Klick. Das Dashboard meldet, dass ein Link im letzten Monat viertausendmal geöffnet wurde, aufgeschlüsselt nach Land, Gerät, Browser und Quelle, und dort endet die Analyse. Aber viertausend Klicks beschreiben, was Sie ausgegeben haben, nicht, was Sie eingenommen haben. Es ist die billige Hälfte des Funnels — und die Hälfte, die sich auf einem Screenshot am besten macht.

Conversion-Tracking schließt die Lücke, indem es eine Kennung vom Moment der Weiterleitung in dasjenige System trägt, das am Ende die Bestellung erfasst, und von dort wieder zurück. Die Idee ist leicht zu beschreiben und leicht so falsch umzusetzen, dass es erst Monate später auffällt, in Gestalt von Umsatzberichten, die nicht zu den Rechnungen passen. Dieser Artikel behandelt die Kennung, das Zuordnungsfenster und warum es eine geschäftliche Entscheidung ist, den Unterschied zwischen einem serverseitigen und einem browserseitigen Ereignis, warum Geld eine ganze Zahl ist, wie Duplikate behandelt werden und was zu tun ist, wenn die Conversion in einem System passiert, das Sie nicht kontrollieren.

Ein Klick ist ein Kostenposten, kein Ergebnis

Berichte, die bei Klicks aufhören, halten sich, weil der Klick die einfache Messung ist. Eine Weiterleitung läuft auf Infrastruktur, die Sie kontrollieren; sie zu zählen braucht die Mitwirkung von niemandem, während alles danach woanders passiert. Unser Leitfaden dazu, wie Klicks auf Links tatsächlich gemessen werden, beschreibt, was ein einzelnes Klick-Event enthalten kann, und die Kurzfassung lautet: Es weiß, dass der Klick stattgefunden hat, und nichts darüber, was danach kam.

Diese Grenze hat handfeste Folgen. Zwei Platzierungen können identische Klickmengen erzeugen, während die eine Käufer schickt und die andere Leute, die nach drei Sekunden wieder weg sind. Eine Länderaufschlüsselung, die bei den Klicks beeindruckt, kann sich beim Umsatz umkehren. Splittests, die nach der Klickrate entschieden werden, wählen regelmäßig die Variante mit der aggressiveren Überschrift und dem schlechteren Kaufabschluss. Solange an denselben Dimensionen kein Umsatz hängt, ist jedes dieser Urteile eine Vermutung im Kostüm einer Kennzahl.

Ihn anzuhängen braucht genau eines: einen Wert, der die Reise von der Weiterleitung bis zur Bestellung übersteht.

Die Kennung ist der ganze Entwurf

Bei jeder Weiterleitung stellt der Worker ein Token aus und macht damit zwei Dinge. Er hängt es unter einem Parameternamen Ihrer Wahl an die Zieladresse, voreingestellt lp_cid, und er schreibt denselben Wert in ein First-Party-Cookie auf Ihrer Weiterleitungsdomain, gültig für 90 Tage.

Zwei Kopien existieren, weil jede von beiden verloren gehen kann. Ziele entfernen Query-Parameter, mal absichtlich für aufgeräumte URLs, mal als Nebenwirkung einer Weiterleitung auf ihrer Seite. Umgekehrt hat ein Besucher, der heute klickt und drei Tage später die Adresse eintippt, keinen Parameter mehr, trägt aber weiterhin das Cookie. Keine der beiden Kopien ist für sich verlässlich; zusammen decken sie die meisten realistischen Wege durch einen Kauf ab.

Dass das Cookie First-Party ist, ist keine Formsache. Es wird von Ihrer eigenen Weiterleitungsdomain gesetzt, also von der Adresse, die der Besucher tatsächlich angesteuert hat, und genau diese Kategorie von Cookie schaffen die Browser nicht ab. Deshalb hört eine eigene Domain auf, eine Frage des Markenauftritts zu sein, und wird zur Messinfrastruktur: Auf einer geteilten Anbieterdomain gehört das Cookie dem Anbieter.

Was das Token mitführt

Das Token ist signiert, und die Signatur deckt mehr ab als den Klick. Workspace- und Partnerkennung sind Teil der signierten Nutzlast, ein Token vom Link des einen Kunden wird im Workspace eines anderen also genau wie eine Fälschung abgelehnt. Wer Links für mehrere Kunden betreibt, hält den Umsatz des einen damit konstruktionsbedingt aus dem Bericht des anderen heraus, und nicht über einen Filter, an den jemand denken musste.

Was das Token enthält, ist bewusst schmal gehalten: den Zeitpunkt des Klicks, den Link, die Splitvariante, das Land, die Geräteklasse, die Traffic-Quelle und eine Markierung für verdächtigen Traffic. Keine personenbezogenen Daten. Genau diese Liste macht die Umsatzspalte nützlich, denn jedes dieser Felder wird zu einer Dimension, nach der Sie den Umsatz in Analytics aufschlüsseln können, ohne irgendetwas ein zweites Mal zusammenführen zu müssen.

Der Parametername und der Schalter zum Ein- und Ausschalten liegen in den Workspace-Einstellungen, und eine Änderung schreibt die zwischengespeicherte Konfiguration jedes Links sofort neu. Eine Folge, die man einplanen sollte: Enthält ein Tarif keine Conversions, stellt die Weiterleitung überhaupt keine Kennungen mehr aus, und wer die Funktion später einschaltet, bekommt für bereits erfolgte Klicks rückwirkend keine Kennungen.

Das Zuordnungsfenster ist eine geschäftliche Entscheidung

Das Fenster ist das Höchstalter eines Klicks, dem eine Conversion noch gutgeschrieben werden kann. Es ist eine Einstellung je Workspace, und es ist die eine Zahl hier, über die gestritten werden sollte, statt sie als Voreinstellung hinzunehmen.

Setzen Sie es zu kurz, verschenken Sie Umsatz, den Sie tatsächlich erzeugt haben. Setzen Sie es weit zu lang, schreiben Sie Links Käufe gut, die ohnehin stattgefunden hätten, und das ist schlechter als nutzlos, weil es selbstbewusst falsch ist. Entscheiden Sie, indem Sie den Abstand zwischen Erstkontakt und Kauf für Bestellungen messen, die Sie bereits nachverfolgen können: Ein Impulskauf ist in Minuten erledigt, ein überlegter Konsumkauf braucht Tage, ein Geschäftskauf mit Freigabeschritt braucht Wochen.

Der Fehlermodus, den dieser Entwurf vermeidet, ist die stille Ablehnung. Eine Conversion, die nach dem Fenster eintrifft, wird mit attribution_expired zurückgewiesen, einem eigenen Code, getrennt von invalid_click_id. Die beiden Zustände verlangen völlig unterschiedliche Reparaturen, und eine Integration, die für beide denselben allgemeinen Fehler bekommt, sucht eine Woche lang an der falschen Stelle. Loggen Sie den Code, zählen Sie beide getrennt und werten Sie eine steigende attribution_expired-Rate als Zeichen dafür, dass Ihr Fenster nicht mehr zu Ihrem Verkaufszyklus passt.

Die beiden Eingangswege haben außerdem unterschiedliche Obergrenzen. Das Cookie lebt 90 Tage, eine browserseitige Meldung, die daran hängt, kann das also nicht überdauern. Eine serverseitige Meldung speichert die Kennung selbst und ist allein durch das Fenster des Workspace begrenzt.

Zwei Wege hinein, ein Satz Regeln

Beide Wege laufen durch denselben Dienst, Zuordnungsfenster, Entdopplung und Weitergabe nach außen verhalten sich also identisch. Unterschiedlich ist, was jeder Weg übersteht und was er von Ihnen verlangt.

Das serverseitige Ereignis

Ihr Backend schickt die Kennung zusammen mit einem Ziel, einer Bestellnummer, einem Betrag und einer Währung.

curl -X POST https://api.linkprofit.com/v1/conversions \
  -H "Authorization: Bearer lp_live_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10241" \
  -d '{
    "click_id": "1.eyJ1aWQiOiJ...",
    "goal": "purchase",
    "order_id": "10241",
    "amount_cents": 4999,
    "currency": "usd"
  }'

Der Schlüssel braucht den Scope conversions:write, dieser Weg kostet Sie also etwas, was der Browser-Weg nicht kostet: ein Zugangsmittel, das ausgestellt, aufbewahrt und rotiert werden will. Wie Schlüssel mit Scopes verwaltet werden, beschreibt die API-Authentifizierung — und halten Sie diesen Schlüssel auf einem Server, denn ein Schlüssel mit Schreibzugriff auf Ihre Umsatzdaten gehört nicht in eine Seite.

Dafür bekommen Sie eine Meldung, die kein Werbeblocker, kein Skriptblocker, keine Einstellung zum Tracking-Schutz und kein JavaScript-Fehler unterdrücken kann. Sie wird von Ihrer eigenen Infrastruktur ausgelöst, in dem Moment, in dem Ihr eigenes System bestätigt, dass eine Bestellung existiert, sie bildet also die Wahrheit nach der Betrugsprüfung ab und nicht den optimistischen Augenblick, in dem ein Knopf gedrückt wurde.

Das browserseitige Ereignis

Der Worker liefert ein kleines Skript von Ihrer eigenen Weiterleitungsdomain aus, und die Dankeseite ruft es auf.

<script src="https://go.example.com/cv.js" defer></script>
<script>
  window.lpConversion({ goal: 'purchase', orderId: '10241', amountCents: 4999, currency: 'usd' });
</script>

Das Skript liest die Kennung aus der URL oder dem First-Party-Cookie, es muss ihm also nichts von Hand übergeben werden. In der ganzen Kette steckt kein fremder Host, und das zählt doppelt: als Eigenschaft für den Datenschutz und als White-Label-Eigenschaft, denn die Seite Ihres Kunden lädt nichts, was die Plattform darunter beim Namen nennt.

Der Preis ist der übliche Preis clientseitiger Messung. Blocker, Privatsphäre-Modi, fehlgeschlagene Skript-Ladevorgänge und ein Besucher, der den Tab eine halbe Sekunde zu früh schließt, entfernen alle Events, und der Verlust ist nicht gleichmäßig verteilt. Technische und datenschutzbewusste Zielgruppen unterdrücken davon weit mehr als Konsumentenzielgruppen, ein reines Browser-Setup zählt also nicht nur zu wenig, sondern je Segment unterschiedlich zu wenig.

Die Wahl zwischen beiden

Nehmen Sie den Server-Weg überall dort, wo ein Server von der Bestellung weiß, und das ist fast überall dort, wo Geld den Besitzer wechselt. Nehmen Sie den Browser-Weg für Ergebnisse, die es nur im Browser gibt, oder dort, wo Sie keinen Servercode ergänzen können: eine Seite, die Sie nur über einen Tag-Manager bearbeiten, eine Anmeldung auf einer gehosteten Plattform, die Landingpage eines Kunden, die Ihnen nicht gehört.

Beide Wege für dasselbe Ergebnis zu betreiben ist dank Entdopplung sicher, aber nur, wenn beide dieselbe order_id senden. Ohne das erweitern Sie nicht die Abdeckung, sondern zählen Umsatz doppelt.

Die Ziele selbst sind leichtgewichtig. Ein Ziel ist ein benanntes Ergebnis wie purchase, signup oder trial, es kann einen Standardwert und eine Währung für Conversions mitbringen, die ohne Betrag eintreffen, und ein Ziel, das genannt wird, bevor es existiert, wird bei der ersten Verwendung angelegt.

Geld ist eine ganze Zahl

Beträge sind ganze Mindesteinheiten. 4999 bedeutet 49,99 in einer Währung mit zwei Nachkommastellen, und ein Betrag von 49.99 wird unter Nennung des Feldes abgelehnt statt still gerundet.

Das ärgert Leute etwa einen Tag lang und rettet sie danach jahrelang. Binäre Fließkommazahlen können die meisten Dezimalbrüche nicht exakt darstellen, die klassische Vorführung, bei der die Summe zweier Beträge eine unerwartete Nachkommastelle produziert, ist deshalb keine Kuriosität, sondern das, was im großen Maßstab mit jeder Summe in einer Umsatzspalte passiert. Währungen ohne Nachkommastellen zerlegen zusätzlich jede Annahme, eine Division durch hundert sei überall richtig.

Die Nachkommazahl an der Grenze abzulehnen schiebt die eine ehrliche Umrechnung, vom menschenlesbaren Preis in Mindesteinheiten, an genau eine Stelle: in Ihren Code, einmal, wo Sie sie testen können.

Duplikate sind Sache der Datenbank

Die Entdopplung passiert als einzelnes atomares Insert, nicht als Lesen mit anschließendem Schreiben. Mehrfache Zustellungen derselben order_id erzeugen eine Conversion und geben sie als Duplikat markiert zurück.

Der Unterschied klingt akademisch und ist es nicht. Ein Prüfen-dann-Schreiben hat eine Lücke zwischen den beiden Operationen, und ein Webhook, den ein ungeduldiger Absender wiederholt, legt zwei Aufrufe genau in diese Lücke. Beide sehen keinen bestehenden Datensatz, und beide schreiben einen. So wächst einem Umsatzbericht ein Phantom von zehn Prozent zu, das hinterher niemand findet, weil jeder einzelne Datensatz vollkommen legitim aussieht.

Die praktische Regel lautet: Wählen Sie eine Bestellkennung, die in Ihrem System stabil und eindeutig ist, und ändern Sie danach nie, wie Sie sie herleiten. Ihre eigene Bestellnummer ist meist richtig; ein Zeitstempel oder irgendetwas, das bei jedem Versuch neu erzeugt wird, ist genau falsch. Kombinieren Sie das mit einem Idempotency-Key-Header wie in der Anfrage oben, und ein fehlgeschlagener Aufruf wird zu etwas, das Sie wiederholen, statt es zu untersuchen.

Verdächtiger Traffic wird ausgewiesen, nicht versteckt. Das Urteil des Klassifikators reist im Token mit, eine Conversion aus einem Rechenzentrum oder von einem Proxy wird also schon beim Erfassen als verdächtig markiert und erscheint in den Berichten als eigenes Segment. Zweihundert Conversions und zweihundert Conversions, von denen vierzig innerhalb einer Stunde aus einem einzigen Hosting-Bereich stammen, sind zwei verschiedene Tatsachen, und nur eine davon ist Geld wert. Genau hier hören Conversion-Daten und Traffic-Filterung auf, getrennte Funktionen zu sein.

Wenn die Conversion woanders passiert

Der größte Teil der Schwierigkeit liegt in der Praxis nicht in der API. Er liegt darin, dass der messenswerte Moment in einem gehosteten Shop, einem CRM oder bei einem Abrechnungsdienst stattfindet, und Ihre Aufgabe ist es, eine einzige Zeichenkette vom Klick in dieses System und wieder heraus zu bekommen.

Gehostete Shops. Erlaubt die Plattform eigene Bestellattribute oder Metadaten, ist das der saubere Weg: die Kennung beim Eintreffen des Besuchers auslesen, in einem versteckten Feld durch den Checkout tragen, an der Bestellung speichern und die Conversion von Ihrem Server melden, sobald die Bestellung bestätigt ist, statt in dem Moment, in dem der Knopf gedrückt wird. Erlaubt die Plattform keine eigenen Felder, wohl aber ein Skript auf der Bestätigungsseite, nehmen Sie stattdessen den Browser-Weg. Unsere Lösungsseite für E-Commerce geht auf diese Entscheidungen genauer ein.

CRM und vertriebsbegleitete Abschlüsse. Erfassen Sie die Kennung als verstecktes Feld im Lead-Formular und speichern Sie sie am Datensatz, und melden Sie die Conversion, sobald der Abschluss als gewonnen markiert ist. Die Falle heißt hier Zeit: Ein Abschluss, der sieben Wochen braucht, braucht ein Fenster für sieben Wochen, und wenn Ihr CRM die einzige Stelle ist, die die Kennung kennt, werden sein Aufbewahrungs- und Exportverhalten Teil Ihrer Zuordnungsarchitektur. Erwägen Sie, beim Lead ein signup-Ziel und beim Abschluss ein purchase-Ziel zu senden, damit der obere Teil des Funnels auch dann gemessen wird, wenn der untere ein Quartal dauert.

Abrechnung und Abonnements. Lassen Sie den Webhook des Abrechnungsdienstes den Auslöser sein. Ist eine Rechnung bezahlt, schlägt Ihr Server die zu diesem Kunden gespeicherte Kennung nach und meldet eine Conversion mit der Rechnungsnummer als Bestellnummer. Wiederkehrende Abbuchungen kommen dann ganz von selbst als eigene Conversions an, und Erstzahlungen bleiben über das Ziel von Verlängerungen unterscheidbar.

In allen drei Formen ist das Muster dasselbe: Das externe System muss nichts über Links wissen. Es hält eine undurchsichtige Zeichenkette und gibt sie Ihnen zurück.

Wohin die Zahlen danach reisen, ist bewusst konventionell gelöst. Ein signiertes conversion.created-Ereignis geht durch die normale Webhook-Maschinerie hinaus, und eingerichtete Werbeintegrationen bekommen die Conversion über eine Warteschlange mit dokumentiertem Backoff und einer Aufgabe-Markierung statt endloser Versuche. Tarife können außerdem die Zahl angenommener Conversions je Kalendermonat deckeln, gezählt in UTC, und wird dieser Deckel überschritten, lautet die Antwort quota_exceeded statt einer Tarifsperre — „nicht in Ihrem Tarif“ und „diesen Monat aufgebraucht“ bleiben so ohne Support-Ticket unterscheidbar.

Beim ersten Mal richtig aufsetzen

1. Schalten Sie Conversions vor der Kampagne ein, nicht danach. Kennungen entstehen im Moment der Weiterleitung und lassen sich nicht rückwirkend erzeugen.
2. Betreiben Sie Links auf Ihrer eigenen Domain, damit das First-Party-Cookie Ihnen gehört.
3. Leiten Sie das Fenster aus Ihrem gemessenen Kaufzyklus ab und prüfen Sie es erneut, sobald sich die attribution_expired-Rate bewegt.
4. Bevorzugen Sie den Server-Weg überall dort, wo ein Server von der Bestellung weiß.
5. Rechnen Sie Preise an genau einer Stelle in Ihrem Code in ganze Mindesteinheiten um.
6. Verwenden Sie Ihre echte Bestellnummer als Bestellkennung und senden Sie sie aus jedem Weg identisch.
7. Loggen Sie Ablehnungscodes getrennt, gleichen Sie einmal je Periode mit der Abrechnung ab und untersuchen Sie die Differenz, statt sie wegzumitteln.

Die vollständige Feldreferenz steht in der Conversions-Dokumentation, und die Funktionsseite zum Conversion-Tracking beschreibt, wie sich die Umsatzspalte in den Berichten verhält, die Sie ohnehin lesen. Nichts davon ersetzt Ihre Buchhaltung. Es beantwortet eine engere Frage, die die Buchhaltung nicht beantworten kann: welcher Link, welches Land, welches Ziel und welche Traffic-Quelle das Geld gebracht haben.