Eine eindeutige Click-ID auf einem kostenlosen Redirect, ganz ohne Worker

Sie schicken bezahlten oder Partner-Traffic durch einen Redirect und wollen, dass jeder Klick mit einer eigenen Kennung am Ziel ankommt — etwas, das sich später gegen eine Conversion joinen lässt. Das naheliegende Werkzeug ist ein Worker, und für alles, was den Klick aufzeichnen soll, bleibt ein Worker das einzige Primitiv, das das kann. Wenn aber alles, was Sie brauchen, ein Klick ist, der eine eindeutige ID trägt, gibt es einen Weg auf dem Free-Plan, in einem gewöhnlichen Single Redirect, ohne eine Zeile Code im Request-Pfad.

Wir haben es am 30. Juli 2026 auf der Zone dieser Seite getestet. Es funktioniert, und drei seiner Kanten beißen. Hier sind die Regel, die Messungen und die Fallen.

Die verbotene Funktion und das erlaubte Feld

Die Ausdruckssprache der Rulesets kennt uuidv4(). Hier dürfen Sie sie nicht benutzen. Die Dokumentation beschränkt sie auf Rewrite-Ausdrücke von Transform Rules, und die API setzt das bei der Validierung durch. Das ist die Live-Antwort auf den Versuch, sie in ein Redirect-Ziel zu setzen:

"'concat(\"https://301.sh/?click_id=\", uuidv4(cf.random_seed))' is not a valid
value for target_url because the use of field cf.random_seed is not allowed,
the use of function uuidv4 is not allowed" (code 20083)

Verboten sind beide, die Funktion und ihr Seed-Feld. Die Ausdruckssprache kann in einem Redirect also keinen Zufall prägen. Was sie kann: eine Kennung wiederverwenden, die Cloudflare für den Request ohnehin schon geprägt hat — cf.ray_id, die Ray-ID, die jeder Request durch Cloudflare bekommt, derselbe Wert, den der CF-RAY-Response-Header und die Dashboard-Logs zeigen. Auf ihrer Feldseite steht keine Produktbeschränkung, und der Validator akzeptiert sie in einem Redirect-Ziel.

Eine Regel, nachgemessen

Ein dynamischer Single Redirect. Der Match ist gewöhnlich; das Ziel ist ein Ausdruck statt einer statischen URL:

Expression:  (http.host eq "301.sh" and http.request.uri.path eq "/go")
Target URL:  concat("https://destination.example/?click_id=", cf.ray_id)
Status:      302, preserve query string off

Fünf Requests hintereinander durch diese Regel, auf dieser Zone:

Location: https://301.sh/…/?click_id=a23684c8a885b183-BTS   CF-RAY: a23684c8a885b183-BTS
Location: https://301.sh/…/?click_id=a23684cbfd5a2915-BTS   CF-RAY: a23684cbfd5a2915-BTS
Location: https://301.sh/…/?click_id=a23684cf493d696b-BTS   CF-RAY: a23684cf493d696b-BTS

Drei Eigenschaften, alle im Output sichtbar. Jeder Request bekam eine andere ID. Jede ID ist Byte für Byte identisch mit dem CF-RAY-Header derselben Antwort — die Click-ID in den Logs Ihres Ziels joint also direkt gegen Cloudflares eigene Logs und das Dashboard. Und eingesetzt wird die volle Form mit dem Rechenzentrums-Suffix (hier -BTS), nicht nur die sechzehn Hex-Zeichen — parsen Sie entsprechend.

Die preserve_query_string-Falle

Der naheliegende nächste Schritt: die Kampagnenparameter behalten, mit denen der Klick ankam. Die Regel hat dafür einen Schalter, und seine Kombination mit einem Zielausdruck, der schon eine Query trägt, ist die Stelle, an der es bricht — gemessen, nicht geraten:

Aufbau	Eingehender Request	Tatsächlich gesendete Location
preserve_query_string: true	/go?utm_source=tg&gclid=abc123	…/?utm_source=tg&gclid=abc123 — click_id weg
preserve_query_string: true	/go	…/ — gar keine Query, auch nicht die des Ziels
manueller Merge, Schalter aus	/go?utm_source=tg&gclid=abc123	…/?click_id=a2368ff0…-BTS&utm_source=tg&gclid=abc123

preserve_query_string mergt die eingehende Query nicht in Ihr Ziel. Es ersetzt die Query des Ziels vollständig — auch dann, wenn die eingehende Query leer ist, was die gerade gebaute click_id löscht. Die zwei Features schließen sich gegenseitig aus.

Die funktionierende Form lässt den Schalter aus und macht den Merge im Ausdruck:

concat("https://destination.example/?click_id=", cf.ray_id, "&", http.request.uri.query)

Eine kosmetische Kante: ist die eingehende Query leer, endet das Ergebnis auf ein nacktes &. Jeder Query-Parser, der uns interessiert, ignoriert es, aber es steht in der URL — wissen Sie das, bevor Sie Logs diffen.

Ein 301 spielt die ID von gestern noch einmal ab

Dieselbe Regel mit Status 301 setzt an der Edge pro Request eine frische Ray-ID ein — auch das haben wir gemessen. Das Problem liegt vor der Edge: der 301 kommt ohne Cache-Control-Header zurück, und ein permanenter Redirect ohne explizite Frische-Information ist genau das, was Browser heuristisch cachen dürfen. Ein wiederkehrender Besucher kann dann von seinem eigenen Cache umgeleitet werden, mit der Click-ID seines ersten Besuchs, und der Request erreicht Cloudflare gar nicht — eine doppelte ID in Ihren Logs und ein untergezählter Klick. Für dieses Muster wollen Sie 302 oder 307.

Wo es bricht

Auf Cloudflares Seite zeichnet niemand die ID auf. Redirect ist eine terminierende Aktion in der ersten Request-Phase; kein Analytics-Produkt sieht den Request je, und die Regel kann nirgendwohin schreiben. Die ID existiert nur in der Location-URL. Loggt das Ziel seine Query nicht, verdunstet die ID im Flug.

Eine Ray-ID ist eine Kennung, kein Geheimnis. Sie ist eindeutig, aber in keinem adversarialen Sinn zufällig — benutzen Sie sie nicht als Token, das irgendetwas autorisiert. Join-Schlüssel: ja. Berechtigung: nein.

Jeder Fetch bekommt eine ID, nicht jeder Mensch. Link-Prefetcher, Scanner und Preview-Bots folgen Redirects auch, und jeder bekommt seine eigene, völlig gültige Click-ID. Die Regel kann sie nicht unterscheiden; Dedup und Filterung bleiben Aufgabe des Ziels.

Die Quote ist real, aber geräumig. Zehn Single-Redirect-Regeln pro Zone auf dem Free-Plan — pro Zone, nicht pro Account —, dann 25 auf Pro, 50 auf Business, 300 auf Enterprise (geprüft am 30. Juli 2026). Eine Tracking-Regel mit Wildcard deckt eine ganze Pfadfamilie ab, zehn reichen also weiter, als es klingt. Reguläre Ausdrücke brauchen Business; dieses Muster braucht sie nicht.

Wenn ein Stempel nicht mehr reicht

Gehört das Ziel Ihnen, sind diese Regel plus Ihre eigene Analytics, die click_id liest, womöglich schon das ganze System: kein Worker, kein Code, nichts zu warten, und die ID joint per Konstruktion gegen Cloudflares Logs.

Das Muster hört genau dort auf zu reichen, wo der Attributions-Artikel anfängt: das Ziel gehört nicht Ihnen, oder der Klick soll auch dann aufgezeichnet werden, wenn das Ziel nichts loggt, oder das Ganze läuft über ein Portfolio von Domains statt über eine Zone. Aufzeichnen auf der Redirect-Seite ist exakt das, was eine terminierende Regel nicht kann — diese Seite muss jemand betreiben, und dafür ist 301.st da: es besitzt das Redirect-Ende, prägt und speichert die ID dort und reicht dieselbe ID stromabwärts weiter, damit der Join funktioniert, ob das Ziel mitspielt oder nicht.