Ein QR-Code, mehrere Ziele: Weiterleitungsregeln und A/B-Tests

Ein gedruckter QR-Code hat genau ein Muster, aber die Menschen, die ihn scannen, sind nicht eine Zielgruppe. Die Hälfte hält ein iPhone, die Hälfte ein Android. Manche lesen Deutsch, manche Italienisch. Wer Ihr Café-Plakat um 09:00 scannt, will Frühstück; um 21:00 die Cocktailkarte. Weiterleitungsregeln lassen einen Code all das unterschiedlich beantworten — entschieden im Moment des Scans.

Wie die Auswertung läuft

Regeln sind eine kurze geordnete Liste. Bei jedem Scan werden sie von oben nach unten geprüft, und der erste Treffer gewinnt — spätere Regeln werden nicht mehr betrachtet. Trifft keine, entscheidet ein optionaler gewichteter A/B-Split. Gibt es auch den nicht, geht der Besucher zum Standardziel des Codes.

Diese Reihenfolge ist das ganze Denkmodell: Eine breite Regel über einer engen frisst sie auf. „Alle Mobilgeräte → App-Seite“ über „Android → Play Store“ heißt, dass die Play-Store-Regel nie greift. Spezielles nach oben, Auffangregel nach unten.

Die drei Bedingungen

Gerät

Treffer auf Betriebssystem (iOS, Android, Windows, macOS …) und/oder Gerätetyp (mobil, Tablet, Desktop). Naheliegend sind App-Downloads — für den reinen Store-Split gibt es allerdings einen eigenen App-Store-Codetyp, der iOS und Android ohne Regeln automatisch trennt.

Wirklich nützlich wird die Geräteregel subtiler: Desktop-Scans (jemand hat den Code abfotografiert und später am Laptop geöffnet) auf eine vollwertige Seite, mobile Scans auf eine leichte. Oder Tablets auf eine Karte für größere Bildschirme.

Ein Haken: Eine Geräteregel ohne ausgewähltes OS und ohne Gerätetyp trifft nie. Leer heißt „kein Filter“, nicht „alles“.

Sprache

Treffer auf die Sprachpräferenz des Browsers, mit zweibuchstabigen Codes. Ein Scan, dessen Browser de-AT verlangt, trifft eine Regel für de. Für ein mehrsprachiges Produkt ist das die nützlichste Regel überhaupt: ein Code auf der Verpackung, und jede Kundschaft landet auf einer Anleitung, die sie lesen kann.

Sprache ist nicht Standort. Sie spiegelt die Einstellung des Telefons, nicht seinen Aufenthaltsort. Eine ukrainische Touristin in Rom bekommt am Museums-Code die ukrainische Seite — meist genau das, was man will, und etwas völlig anderes als eine länderbasierte Regel.

Zeit

Treffer auf Wochentage und ein Stundenfenster. Das Fenster ist halboffen — 11 bis 15 deckt 11:00 bis ausschließlich 15:00 ab —, sodass aufeinanderfolgende Fenster ohne Überlappung geschrieben werden können.

Stunden sind in UTC. Das ist die Falle des ganzen Features. Liegt Ihr Café in Berlin und soll die Mittagskarte von 11:00 bis 15:00 Ortszeit laufen, konfigurieren Sie im Sommer 09:00–13:00 UTC und im Winter 10:00–14:00. Die Zeitumstellung verschiebt Ihre Regel zweimal jährlich stillschweigend — eine Kalendererinnerung lohnt sich. Wochentage laufen von 0 für Sonntag bis 6 für Samstag, ebenfalls in UTC: um Mitternacht ist der UTC-Tag nicht Ihr lokaler Tag.

A/B-Tests

Statt nach Merkmal zu leiten, können Sie Traffic gewichtet auf bis zu zehn Ziele verteilen. Gewichte sind relativ, keine Prozente: 3 und 1 schickt etwa drei Viertel in eine Richtung. Zwei Ziele mit 50 und 50 sind der einfache Münzwurf.

Zwei ehrliche Grenzen, um die man herum planen sollte:

• Der Split ist nicht klebend. Jeder Scan wird unabhängig gezogen, dieselbe Person kann beim zweiten Scan die andere Variante sehen. Für einen Headline-Test ist das in Ordnung; für alles, wo Wiederkehrende Konsistenz brauchen — Checkout, ein halb ausgefülltes Formular —, nicht.
• Die Messung liegt bei Ihnen. Die Scan-Analytics sagen, wie viele insgesamt gescannt haben, nicht auf welche Variante sie geschickt wurden. Geben Sie jeder Variante eigene UTM-Parameter oder eigene URLs und lesen Sie die Konversion in Ihrer Analytics.

Weil das gedruckte Muster nie wechselt, geht der Test auch langsam: zwei Wochen alles auf Variante A, dann zwei Wochen auf B. Weniger bewegliche Teile, kein Klebe-Problem — nur langsamer und anfällig für Saisonalität.

Wofür Regeln gelten

Regeln werden für URL- und PDF-Codes ausgewertet — die beiden Typen, bei denen „das Ziel“ ein Link ist, der je Besucher plausibel abweichen kann. Ein WLAN-Code oder eine vCard löst auf eine eigene Seite auf und hat nichts zu routen. Brauchen Sie bedingtes Verhalten, bauen Sie den Code als URL-Typ auf Seiten, die Sie kontrollieren.

Die Limits sind großzügig genug, um sie zu ignorieren: bis 20 Regeln und 10 A/B-Ziele pro Code. Weiterleitungsregeln sind ein Pro- und Business-Feature.

Rezepte, die wirklich genutzt werden

• Tischaufsteller im Restaurant: Zeitregeln für Frühstück, Mittag und Abend, die À-la-carte-Karte als Standard außerhalb der Fenster. Ein gedruckter Code für die Lebensdauer des Tisches.
• Mehrsprachige Verpackung: Sprachregeln für Ihre Hauptmärkte, Englisch als Standard. Pflegehinweise in der Sprache der Kundschaft, ohne fünf Etiketten zu drucken.
• Event-Beschilderung: vor dem Einlass das Programm, während des Events der laufende Zeitplan, am Morgen danach ein Feedback-Formular. Zeitregeln erledigen das, ohne dass jemand Plakate tauscht.
• Messestand: Desktop auf ein Whitepaper, mobil auf ein kurzes Kontaktformular — im Stehen füllt niemand ein langes Formular aus.
• Plakat-Headline-Test: zwei Landingpages gleich gewichtet, unterschiedliche UTM-Tags, nach zwei Wochen entscheiden.

Fehler, die Scans kosten

• Breite Regel über enger Regel. Der erste Treffer gewinnt; die Reihenfolge ist die Logik.
• Standardziel vergessen. Es bedient alle, die Ihre Regeln nicht beschreiben, und muss immer irgendwo Sinnvolles hinführen.
• Ortszeit statt UTC. Der häufigste Fehler, und er scheitert leise: Der Code funktioniert, liefert nur für ein paar Stunden das Falsche.
• Unprüfbare Regeln. Jeden Zweig testen: Handy-Sprache umstellen, vom Desktop-Browser scannen, und bei Zeitregeln entweder das Fenster abwarten oder es kurz auf jetzt legen.
• Testen ohne Metrik. Ein A/B-Split ohne UTM und ohne Konversionsziel liefert zwei Zahlen, die man nicht vergleichen kann.

Was Regeln hier nicht können, unverblümt: es gibt kein Geo-Targeting. Bedingungen sind Gerät, Browsersprache und Zeit — kein Land, keine Region, keine Stadt. Sprache ist ohnehin der bessere Näherungswert, weil sie der Person folgt und nicht der SIM-Karte.

Bei Enqre setzen Sie Regeln im Code-Editor. Sie werden in der Reihenfolge ausgewertet, in der Sie sie angelegt haben; Umsortieren per Drag-and-drop gibt es noch nicht — legen Sie also die spezifischen Fälle zuerst an, oder löschen und neu anlegen, um die Reihenfolge zu ändern. Jeder Scan wird erfasst, welchen Zweig er auch nahm.

Häufige Fragen

Kann ein QR-Code zu verschiedenen Seiten führen?

Ja, mit einem dynamischen Code und Weiterleitungsregeln. Das Ziel wird beim Scan aus Gerät, Browsersprache oder Uhrzeit bestimmt — ein gedrucktes Muster bedient mehrere Zielgruppen.

Kann ich nach Land oder Stadt steuern?

Bei Enqre nicht. Regeln greifen nur auf Gerät, Browsersprache und Zeit — Geolokalisierung gibt es im Produkt nirgends. Für die meisten Fälle ist die Browsersprache das bessere Signal: Sie folgt dem Besucher, nicht dem Netz.

Merkt sich der A/B-Test die gezeigte Variante?

Nein. Jeder Scan ist eine unabhängige gewichtete Ziehung, ein zweiter Scan kann auf der anderen Variante landen. Für Inhaltstests geeignet, nicht für Abläufe, die zwischen Besuchen konsistent sein müssen.

Warum griff meine Zeitregel zur falschen Stunde?

Stunden sind UTC. Aus der Ortszeit umrechnen und daran denken, dass die Zeitumstellung den Offset zweimal jährlich verschiebt.

Welche Codetypen unterstützen Regeln?

URL und PDF. Andere Typen lösen auf ihre eigenen Landingpages auf und haben kein Alternativziel.