Seitenwechsel — Seite 1 von 2

Der Fall aus M360-4782: Ein Besucher landet über eine Anzeige hier, klickt dann in der Navigation der Kundenseite weiter, und die zweite Seite kennt die Kampagne nicht mehr. Beim echten Seitenwechsel schickt der Browser die vorherige URL samt Query im Referer — die API liest sie jetzt.

Schritt 1. Diese Seite mit Merkmalen betreten — ein Fall unten auswählen. Der gclid ist pro Aufruf neu, damit der Testlauf in den Daten wiederzufinden ist.

Schritt 2. Unten auf den Link zu Seite 2 klicken. Das ist ein echter Seitenwechsel, kein Router.

Schritt 3. Auf Seite 2 im Kasten ablesen: die Seiten-URL trägt keine Merkmale, der Referrer trägt sie, und die API ordnet über referrer zu.

→ Weiter zu Seite 2 (echter Seitenwechsel)

Kaufen-Button (nur damit das Widget lädt und save_traffic überhaupt schickt):

Kaufen

Anderes Bid testen: ?default=<id> an die URL hängen (?bid= tut es auch, wie im Testhost). Ebenso banner_id und lng. Alle drei überleben jeden Schritt dieser Testseiten — die Kampagnenmerkmale ausdrücklich nicht.

Was die API sieht

Diese Seite läuft auf einem Maven360-Host, deshalb wird der Traffic als Testtraffic geschrieben (promo_widget_traffic.TEST = 1) und verfälscht keine Auswertung. Ordnet die API nichts zu, obwohl die URL Merkmale trägt, steht BUYNOW_REFERRER_ATTRIBUTION auf false — vor dem Rollout ist das der erwartete Zustand.

→ Der andere Fall: In-App-Navigation (SPA)