From Wiki

Postview (PV) Tracking für Advertiser

Beim Display (Advertising) genügt dank PostView-Tracking der Werbemittelsichtkontakt, um vergütungsberechtigt zu sein, wenn innerhalb der vereinbarten Laufzeit dann eine Bestellung dazu vermittelt wird und Ihr Publisher-Account dafür auch freigegeben wurde vom Advertiser.

Ein PostView-Cookie wird beim Nutzer-Gerät/User-Client gesetzt zusammen mit der Werbemittel-Auslieferung (bspw. Banner-Anzeige). Hierfür wird also keine gesonderte Interaktion vom Webseiten-Besucher benötigt. Es genügt vielmehr eine vermittelte Bestellung, unmittelbar nach dem Werbemittel-Sichtkontakt.

Post View Zielgruppen

Entweder kann man Post View (PV) grundsätzlich für alle zugelassenen Publisher seines Partnerprogramms freigeben oder nur für einzelne PV Publisher (im Gegensatz zum einfachen allgemeinen Post View), was wir empfehlen. Im zweiten Falle hätten dann lediglich eine kleine Anzahl aus vorher ausgewählten und von uns auch persönlich betreuten PV Publishern die Möglichkeit auf PV Basis in Ihrem Partnerprogramm Post View Traffic zu generieren und darüber abgerechnet zu werden.

Das Ziel beim PostView ist die performancebasierte CPM-/TKP-Verarbeitung, d.h. die Öffnung Ihres Partnerprogramms insbesondere auch für umsatzstarke Publisher mit hohem Traffic-Volumen, bei gleichzeitiger Beibehaltung des herkömmlichen CPO-/CPA-Abrechnungsmodells.

Technischer Hintergrund für zusätzlichen Aufruf der PV-HTLP

Wir empfehlen Ihnen als Advertiser das Tracking nach unseren Vorgaben mit bestmöglicher Qualität einzubinden, also entweder immer/permanent bzw. zumindest immer dann wenn kein anderer Vertriebskanal zur Bestellung erkannt wurde, damit wir dann automatisiert prüfen können, ob es innerhalb unseres Netzwerkes eine Werbeleistung gab zu einer übermittelten Bestellung (z.B. nach vorausgegangenem Werbemittelsichtkontakt/PostView).

Nicht jeder Advertiser unterstützt technisch die PostView-Markierung automatisch beim Bild-Aufruf vom Werbemittel/Banner selbst.

Daher benötigen wir in diesem Falle alternativ von Ihnen als Advertiser zwingend einen gesonderten Aufruf auf deren PostView-HighTrafficLandingPage (PV-HTLP), um den User zu markieren für den Vertriebskanal Awin und den Eventtyp PostView. Ohne diesen Aufruf würde ansonsten ggf. Ihre Tracking-Logik nicht greifen, wodurch dann evtl. ein Tracking der über PostView vermittelten Bestellungen (Sales) scheitern könnte, da Ihre Erstkontakt-Markierung (Awin-PostView) nicht korrekt gesetzt oder wieder erkannt wurde.

Voraussetzung für PostView

Damit das Post View Tracking innerhalb des Awin Netzwerks technisch funktionieren kann, ist die Implementation des Awin Tracking-Codes auf der Bestellbestätigungsseite Voraussetzung. Sofern Sie einen bspw. externen technischen Dienstleister/Drittanbieter oder eine allgemeine Lösung zur „Echtzeit-Deduplizierung“ nutzen, wird Awin bei jeder Post View Einblendung zu einer von Ihnen bereitgestellten sogenannten High Traffic Landing Page (HTLP) weiterleiten.

Ist unser Sale-/Lead-Trackingcode stets immer permanent bedingungslos eingebunden (ohne Trackingweiche) auf Ihrer Homepage ist Ihr technisches PostView-Setup bereits ohne eigenen Mehraufwand für Sie abgeschlossen und Sie können unserem Team entsprechend Rückmeldung geben. Ebenso, wenn unser Trackingcode/ConversionTag zwar nicht immer, aber immer dann, wenn kein anderer Vertriebskanal eingebunden wurde, gibt es keinerlei weiteren Setup-Aufwand für die PostView-Umsetzung für Sie.

Nur wenn diese Bedingungen nicht erfüllt sind, beachten Sie bitte die nachfolgenden Hinweise für das PV-Setup im Falle einer eingesetzten Trackingweiche zur Vertriebskanalsteuerung.

Deduplizierung

Bei der Deduplizierung wird ermittelt, über welchen Marketing-/Vertriebskanal ein Sale generiert wurde. Die Identifizierung des Marketingkanals bestimmt, welcher Tracking-Code auf der Bestellbestätigungsseite des Sales angezeigt wird.

Beispiel: Wenn ein Advertiser sein Programm über zwei Affiliate-Marketing-Netzwerke betreibt, ist die Deduplizierung ein Werkzeug, um vereinzelt eine doppelte Vergütung ein und desselben Sales vorzubeugen. Ein solcher Fall kann eintreten, wenn ein Kunde Publisher-Webseiten aus beiden Netzwerken besucht hat und auf seinem Computer zwei Affiliate-Netzwerk-Cookies gespeichert werden.

Durch die Echtzeit-Deduplizierung wird nur der Tracking-Code des Netzwerks angezeigt, in dem der Kunde zuletzt in den Online-Shop des Advertisers weitergeleitet wurde. Der Sale wird nur für ein Netzwerk getrackt, sodass bei der Sales-Freigabe weniger doppelt erfasste Sales vom Advertiser abgelehnt werden müssen.

Ansonsten ist natürlich auch ein bei allen Beteiligten erfasster Sale immer erstmal im sogenannten Status "offen" und die Provision wird erst dann bezahlt oder fällig, wenn die vereinbarte Bearbeitungszeit, die insbesondere auch den Abgleich mit den eigenen Systemen (z.B. in (Waren-Rücksende-)Fällen von Teil- bzw. Voll-Stornos, Zahlungsausfällen, Nichtantritt einer gebuchten Reise o.ä.) ermöglicht, bevor Geld für die vermittelte Bestellung (Sale) dann auch vom Advertiser zum Publisher wechselt. Zu diesem Zweck wird auch immer der letzte Kontaktzeitpunkt vor der vermittelten Bestellung angezeigt (last contact timestamp).

Nutzen Sie eine Trackingweiche/Echtzeit-Deduplizierung zur Aussteuerung unseres Trackingcodes für die Vermittlung von Sales/Leads, dann ist für die technische Unterstützung noch ein zusätzlicher PV-Setup-Aufwand notwendig.

Bei der Deduplizierung wird ermittelt, über welchen Marketingkanal ein Sale generiert wurde. Die Identifizierung des Marketingkanals bestimmt, welcher Tracking-Code bspw. auf der Bestellbestätigungsseite des Sales angezeigt wird. Damit der User also entsprechend markiert werden kann beim Werbemittelsichtkontakt stellen Sie bitte eine gesonderte Landingpage bereit, welche lediglich Ihr Skript zur Markierung des Users (z.B. via temporären und permanenten Cookie sowie möglichst auch cookieunabhängigen Fingerprint) enthält.

Ziel ist letztendlich nur den User auch bei Werbemittelsichtkontakt zu markieren und damit letztendlich diesen auf der Bestellbestätigungsseite beim Sale wiederzuerkennen und somit unseren Sale-Trackingcode aufzurufen.

Nähere technische Informationen zum Thema Deduplizierung/Vertriebskanalsteuerung findet Ihr auch in unserem Wiki.

High Traffic Landing Page (HTLP)

Die Bereitstellung einer sogenannten High Traffic Landing Page im Falle von Post View bzw. Awin Performance Display (Advertising) ist nur dann erforderlich, sollten Sie einen Drittanbieter zur Echtzeit-Deduplizierung Ihrer Online Marketingaktivitäten oder eine selbst entwickelte Multi-Channel-Tracking Lösung nutzen. Sofern Sie den Awin Tracking-Code ohne jede Bedingung und bei jeder Bestellung einblenden oder zumindest immer dann, wenn kein anderer Vertriebskanal eindeutig erkannt wurde, entfällt ein PostView Setup-Aufwand. Denn in diesen Fällen ist die Bereitstellung und das Hosting der PostView-HTLP auf den Awin Servern möglich.

Sofern Sie also eine Echtzeit-Deduplizierung verwenden, stellen Sie bitte Awin eine per https Aufrufbare HTLP bereit. Diese muss folgende Bedingungen erfüllen:
• Erstellung einer Content-leeren/inhaltslosen Seite auf Ihrem Server (oder des Drittanbieters)
• Die PV-HTLP sollte unbedingt auch https unterstützen.
• Setzung eines (separaten) PostView Cookies zur Kanalerkennung von Awin
• überholt, aber für ältere Browser dennoch weiterhin optional möglich: Implementation einer P3P Policy/maschinenlesbaren Datenschutzerklärung (optional ab IE 11 bzw. Microsoft Edge).

Der Cookie sollte den identischen Inhalt wie beim Klick haben, aber niedriger priorisiert werden als ein Klick-Cookie.

Beispiel: Der User besitzt einen Klick-Cookie und erhält anschließend einen View-Cookie. Der Klick-Cookie sollte bei der Entscheidung welcher Tracking-Code angezeigt wird, immer Vorrang haben.

Im Idealfall sollte das Tracking, insbesondere auch das PostView-Tracking unabhängig von den Geräte-/Browser-Einstellungen der Nutzer/User dennoch sicherstellen, das vermittelte Bestellungen (Sales) erfasst werden können und daher empfehlen wir auch den Einsatz cookieunabhängiger Trackingmethoden (bspw. Fingerprint-, eTag-BrowserID, IP-Tracking oder ID-Tracking o.ä.).

PostView-Tracking-Gewichtung

PostView wird niemals einen (Post)Click-Cookie überschreiben können und PostView hat i.d.R. eine maximale Rückkehrspanne/Cookie-Laufzeit von 2 Tagen bzw. natürlich eine programmspezifische individuelle Laufzeit für die Display-/PostView-Werbetätigkeiten. Ein Klick ist von der erbrachten Werbeleistung höherwertiger, da dort dann bereits auch schon ein Shopbesucher vermittelt wurde, wenn dieser zuvor auf eine Werbeanzeige klickt und zum jeweiligen Online-Shop/-Angebot gelangt. Bei einer eigenen Lösung zur Aussteuerung vom Awin-Trackingcode sollte dies daher analog unserer Trackingreihenfolge berücksichtigt werden.

PostView/Display Advertising & (Apple-)Safari-Browser (ITP)

Aus aktuellem Anlass empfehlen wir, insbesondere beim Einsatz von Trackingweichen für das Safari-Browser-Update auch um Beachtung bzgl. ITP, die klassische (Drittanbieter-)Cookies verhindern.

PostView/Display Advertising ist besonders stark betroffen vom Anti-Tracking-Browser-Update.

PostView ist unter ITP (ab 2.0) im Safari, im FF (ETP) und Chrome Browser (seit 04/2021) schwieriger bis gar nicht mehr umsetzbar über eine rein cookie-basierte Trackingweiche, da weder wir als Awin, zanox, affilinet (PV), noch Ihr als Advertiser (HTLP), notwendige (1st party) Coookies schreiben können, da dies immer auf der Seite des Publishers ! geschieht zum Zeitpunkt des Werbemittel-Sichtkontaktes (z.B. Banner oder Produktbild vom Einzelangebot bzw. Logo o.ä.) und somit in einer 3rd-Party-Umgebung. Jedoch verweigert der Browser hierbei ja das Schreiben/Lesen von 3rd Party Cookies. Über den MasterTag/JourneyTag gibt es eine cookieunabhängige alternative Trackingmethode, welche wir dort aktivieren können. Rein cookiebasierte Lösungen für eigene Trackinglösungen werden zunehmend Schwierigkeiten bekommen mit den aktuelleren Browser-Updates und dortigen automatischen Drittanbieter-/3rd-Party-Cookie Blockierungen.

ID-Callback-Tracking

Optional kann auch eine Awin-Kennung (insbesondere auch bei Safari-Usern) zurückgegeben werden.

Die GET-Variable von awc ist entspreched abzufragen und später wieder zurückzugeben, wie z.B. mit PHP:

<?php
session_start();
$awc = $_SESSION["awc"] = $_GET['awc'];
//$_SESSION["zanpid"] = $_GET['zanpid'];
$_SESSION["marketingchannel"] = 'aw';
$_SESSION["eventtype"] = 'click'; 
bzw. 
$_SESSION["eventtype"] = 'postview';
?>

Siehe auch PHP-Session:
http://www.w3schools.com/php/php_sessions.asp
http://php.net/manual/en/reserved.variables.session.php

Für die Wiedererkennungen z.B. nach mehreren Stunden/Tagen in späteren anderen Browser-Sitzungen kann es ggf. auch helfen diesen Wert vorsorglich ebenso innerhalb eines permanenten Cookies mit beim User(-client) wegzuspeichern oder ggf. zur eigenen vorhandenen (Shop-)UserSessionID in die Datenbank o.ä.

Beispiel-Cookie-Skript in PHP Beispiel-Cookie-Skript in JavaSkript Beispiel-Cookie-Skript in ASP

ID-Rückgabe im Awin-Trackingcode:
ConversionTag Image Pixel (awin1.com): ...&cks={awc}...

Für o.g. Variablen, insbesondere ... $awc = $_SESSION["awc"] = $_GET['awc']; ... könnte es dann bspw. so aussehen in PHP:

Awin ConversionTag Image Pixel: ...&cks=$awc...

Ob es nun mit PHP oder anders erfolgt ist nicht relevant sondern soll nur eine Umsetzungsvariante aufzeigen. Neben permanenten Cookies könnte zudem zusätzlich, um Ausfälle zu reduzieren, auch vorsorglich ein sessionbasierter temporärer Cookie für die Browser-Sitzung platziert werden bzw. auch mit alternativen cookie-ähnlichen Lösungen (z.B. web storage api, local storage, session storage, php session, shop session, etag/http header response, send beacon, fingerprint, curl, a href ping etc.) weitere Fallbacks hinzugefügt werden.

PostView i.V.m. Awin-MasterTag/-JourneyTag

Manchmal haben Advertiser auch den Awin-MasterTag/-JourneyTag (dwin1.com) ebenso auf der PV-HTLP integriert. Bitte auf der PV-HTLP entfernen, weil fast alle Display-/PostView-Publisher dies nicht wünschen. Da hier ansonsten bei jedem Werbemittelsichtkontakt (view) eines Display-Advertising-/PostView-Publisher (bzw. Retargeting-Publisher mit Postview) zugleich auch deren Server-Scripte geladen werden würden, was i.d.R. nicht erwünscht ist, weil es nicht mal zuvor einen realen Shop-Besucher gab. Bitte nur im Onlineshop den Awin-MasterTag/-JourneyTag (dwin1.com) laden, jedoch mit Ausnahme dieser vorgenannten PV-HTLP.

weitere PostView/Display Themenseiten

Weitere Informationen zu PostView/Display bspw. mit Nutzung von Google Tools (z.B. Google Analytics) findet man auf folgenden Awin-Themenseiten:

Was ist PostView-Tracking und wofür wird es verwendet?
Wie kann ich das PostView-Tracking für meine Publisher aktivieren?
Wieso unterscheiden sich die Statistiken zwischen dem Awin Reporting und Google Analytics?