Thema: vitrado startet Cache-Tracking

Wie in diesem Blogpost zu lesen ist, wird vitrado mit dem anstehenden Relaunch als erstes deutschsprachiges Affiliate-Netzwerk das Cahce-Tracking einführen. In diesem Thread können Fragen dazu gestellt werden, die dann direkt von vitrado-Mitarbeitern beantwortet werden.

Re: vitrado startet Cache-Tracking

Nach einer mittleren Anmelde Odyssee hier im Forum ein kurzes Statement dazu:

Das Cache-Tracking halte ich für einen neuen Beitrag im Buzz-Word des Jahres Spiel, weil die Relevanz eines Browsers, der weder durch session cookies identifiziert werden kann, aber dennoch in rgendeinen shop bedienen kann und da einkauft, imho minimal ist.

Aber zu meiner Frage: Wie schaut es mit APIs aus? Da fehlt mir zur Zeit einfach die Basis um Vitrado in meinen Abstraktions-Layer einzubinden. Ich bräuchte: EinzelTransaktionsListen und Meine Programme mit Stati und aktueller individueller Provisionierung.

Wenn ich mal die Wunschliste öffnen darf:

Transaktion:
- Unique Transaction ID

- UTC Create
- UTC Update

- UTC Event First View Time
- UTC Event Last View Time
- UTC Event First Click Time
- UTC Event Last Click Time
- UTC Event Checkout Time
- UTC Event Checkout Payment Time

- Status (open, closed)
- Transaction Status (open, confirmed, rejected)

- Original Value
- Actual Value
- Checkout Value
- Original Currency
- Actual Currency
- Checkout Currency

- Checkout Item IDs
- Checkout Item Names

- Program ID
- Program Name

- User Site ID
- User Site Name

- AlphanumericalSubids (min. 64Chars)

- Views before Transaction (über das gesamte Netzwerk)
- Clicks before Transaction (über das gesamte Netzwerk)

... mal ein erster Schuss
Bin gespannt auf Euer System.

Viele Grüße,
pascal

Re: vitrado startet Cache-Tracking

Hallo Pascal,

da versuche ich mich doch gern an deiner ausführlichen Frage - bin mal gespannt was da noch kommt, wenn dass dein erster Schuss war!

Vielleicht ein kurzes Wort zum Cache-Tracking: Im Prinzip stimme ich dir zu, ein Großteil aller Bestellungen wird sicherlich direkt in einer Session abgewickelt bzw. die Bestellung in einem Shop setzt zwingend aktivierte Cookies voraus.

Zusätzliche Tracking-Methoden machen für mich dennoch immer Sinn: Nicht alle Shops setzen Cookies zwingend voraus, Cookies können von Nutzern dennoch nach einer Session gelöscht werden etc. - Aber das nur am Rande.

Jetzt zu den Möglichkeiten unserer API-Schnittstelle.

Prinzipiell wird das Ganze über SOAP abgewickelt und steht sowohl Affiliates als auch Merchants zur Verfügung. Möglich ist der Zugriff auf die meisten Statistiken und Prämienwerte, sowie natürlich Artikeldatenbanken.

Im Detail (ich umschreibe immer kurz was ich unter deinem Begriff verstehe, ein ganz einheitliche Sprachregelung gibt es ja leider noch nicht - 'vorraussichtlich' per API abrufbar bedeutet, dass die Funktion eventuell erst nach dem Relaunch verfügbar sein wird):

- Unique Transaction ID

Einmalige, vom Merchant vergebene Vorgangsnummer --> ist per API abrufbar

- UTC Create

Zeitpunkt, an dem die Vorgangsnummer an uns übermittelt wurde --> per API abrufbar

- UTC Update

Zeitpunkt, an dem der Vorgang aktualisiert wurde (z.B. Prämienfreischaltung) --> vorraussichtlich per API abrufbar

- UTC Event First View Time
- UTC Event Last View Time
- UTC Event First Click Time
- UTC Event Last Click Time

Zeitpunkt, an dem vom Endkunden zum ersten/letzten Mal ein Werbemittel gesehen/geklickt wurde vor einer Transaktion --> nur der jeweils "Last View/Click" verfügbar

- UTC Event Checkout Time
- UTC Event Checkout Payment Time

Zeitpunkt, an dem eine Bestellung abgeschlossen bzw. eine Bezahlung durch den Endkunden durchgeführt wurde --> prinzipiell machbar, müsste aber erst vom  Merchant geliefert werden. Auf jeden Fall per API verfügbar ist der Zeitpunkt, an dem unser Zählpixel aufgerufen wurde.

- Status (open, closed)
- Transaction Status (open, confirmed, rejected)

Ich verstehe noch nicht genau die verschiedenen Status --> per API verfügbar ist auf jeden Fall der Prämienstatus wie beschrieben

- Original Value
- Actual Value
- Checkout Value

Warenkorbwertwert --> per API ist EIN Warenkorbwert je UTC verfügbar

- Original Currency
- Actual Currency
- Checkout Currency

Währung bei internationalen Programmen? --> wir konzentrieren uns auf Deutschland, alle Werte daher in € per API verfügbar

- Checkout Item IDs
- Checkout Item Names

Ich vermute Einzelbestandteile eines Warenkorbs? --> prinzipiell per API verfügbar, müsste aber auch entsprechend vom Merchant geliefert werden

- Program ID
- Program Name

Per API verfügbar

- User Site ID
- User Site Name

Meinst du die Website, die der Affiliate in seinem Profil eingegeben hat, oder den tatsächlichen Referrer der Bestellung? --> Ersteres auf jeden Fall, letzteres vorraussichtlich per API verfügbar

- AlphanumericalSubids (min. 64Chars)

SubIDs (auch mit wesentlich mehr Chars) per API verfügbar

- Views before Transaction (über das gesamte Netzwerk)
- Clicks before Transaction (über das gesamte Netzwerk)

Den Wert verstehe ich leider noch nicth ganz ;-)

Darüber hinaus ist auch noch einiges andere verfügbar (z.B. Sonderzahlungen je Programm etc.), aber soweit ist erstmal der aktuelle Stand!

Beste Grüße,
Sascha

Re: vitrado startet Cache-Tracking

Hallo Sascha,

danke für die schnelle Antwort.

Zum Cache Tracking: nach meinem Verständnis fragen die meisten Browser nach dem neuen Browserstart alle gecachten Objekte neu an. Ob der eTag da gleich bleibt bin ich mir in der Tat nicht sicher, ich dachte, das wäre nicht einheitlich so.

Zur API: SOAP klingt gut, gibt es auch alternative Formate wie JSON oder CSV?

- Unique Transaction ID

nicht Merchant, sondern Systemweit eindeutig, d.h. es gibt keine zwei Transaktionen zu der ID. Alternativ wäre auch eine historisierte Version möglich, d.h. es gibt n Transaktionen zu der ID, die jeweils den überarbeiteten Stand als Historie darstellen.

Aber die IDee, eine Merchant ID einzufügen, mit der man bei einem Storno automatisch beim Merchant System nach dem Stornogrund fragen könnte, klingt auch gut.

Die Stati werden imho in den APIs sehr unsaube gehandhabt.
Für mich gibt es einen Status des Transaktions-Atoms und der ist open = es können noch Änderungen kommen, oder closed =  Die Transaktion hat einen finalen Status erreicht.

Das zweite ist der Status innerhalb der Transaktion, da könnte es ja auch so etwas wie Teilstornos oder Ratenzahlung geben, die heute z.T. noch undefiniert und eher Merchant als System-abhängig sind.


btw UTC ist nicht die Transaction ID sondern
"Die koordinierte Weltzeit, international UTC genannt, ist eine stets überall auf der Erde geltende, einheitliche Uhrzeit. UTC ist eine englisch-französische Wortschöpfung und steht für Coordinated Universal Time, beziehungsweise Temps Universel Coordonné – die Buchstabenreihenfolge UTC ist ein sprachneutraler Kompromiss[1]. Im Gegensatz zur älteren GMT, welche den Schwankungen der Erdrotation folgt, glättet die UTC selbige Schwankungen mittels Schaltsekunden mit dem Zweck, global betriebene Technologien genauer abzugleichen." (wikipedia)

Views before Transaction / Clicks before Transaction gibt es noch in keiner API.

Für mich wäre der Wert interessant um den "Umwerbungsgrad" und damit das Risiko, nicht last Cookie zu sein eines Programms darstellen. Damit könnte ich in meinem System den Rank des Programmes mitbewerten.

Bei mir ranken die unterschiedlichen "clients" -> Abstaktion von Programm über die Netzwerke nach einem eRpM also estimated Revenue per Millia. Darin kalkuliert ich z.B. gewichtete Stornoraten nach Aler der Transaktion ein, um aus einer offenen Transaktion einen Zielwert zu haben, nach dem ich bis zur finalen Bestätigung optimieren kann. Wenn ich noch keine Stornorate habe, wird die der anderen Netzwerke, respektive die des Verticals angenommen. Es sind durchaus noch ein paar mehr Werte, die da rein kommen, aber ein Wert ist eben die Wahrscheinlichkeit einer Transaktion nach dem View. Das wäre spannend.

Was bei den Sonderzahlungen cool wäre:
Wenn ich die automatisch in mehrere virtuelle Transaktionen splitten könnte, die sich auf jeweils alle Transaktionen in dem Zeitraum beziehen,damit mein eRPM auf der Einzel-Transaktion stimmt.

Soweit klar?
Viele Grüße,
Pascal

Re: vitrado startet Cache-Tracking

Hi Pascal,

diesmal mit ein bißchen Verzögerung, aber noch zu deinen anderen Fragen:

Zum Cache Tracking: nach meinem Verständnis fragen die meisten Browser nach dem neuen Browserstart alle gecachten Objekte neu an. Ob der eTag da gleich bleibt bin ich mir in der Tat nicht sicher, ich dachte, das wäre nicht einheitlich so.

Unser Tracking nutzt gerade das Anfragen der Browser aus, bzw. den Vergleich der eTag-Werte. Damit funktioniert das Cache Tracking (sollte wahrscheinlich strenggenommen auch eTag Tracking heißen) natürlich auf jeden Fall auch nach dem Beenden eines Browsers.

Zur API: SOAP klingt gut, gibt es auch alternative Formate wie JSON oder CSV?

Bisher ist nur SOAP verfügbar, andere Formate können wir aber nachreichen wenn das für entsprechend viele Nutzer wichtig ist.

nicht Merchant, sondern Systemweit eindeutig, d.h. es gibt keine zwei Transaktionen zu der ID.

Eine eindeutige ID, die für jede Transaktion (also auch für jede Updatebuchung) vergeben wird, nutzen wir bisher im System nicht, da wir auch mit dem beschriebenen System jeden Vorgang eindeutig zuordnen können.

Die Stati werden imho in den APIs sehr unsauber gehandhabt.

Ich weiß nicht genau wie die anderen Netzwerke das handhaben, aber bei uns ist der Status freigegeben bzw. storniert immer 'closed'.

Spannend finde ich aber vor allem dein Frage nach einem erpm über ein netzwerk bzw. sinnvoller über einzelne Programme. Solche Durchschnittswerte sind bei uns aktuell nicht angedacht. Ich selbst bin mir dabei ehrlich gesagt unsicher, wie aussagekräftig so etwas ist: Wenn ich Durchschnittswerte über unser gesamtes Netzwerk bilde kann ich daraus nur sehr schwer Prognosen für einzelne Partner ableiten, da natürlich die jeweilige Trafficqualität der Partner extrem unterschiedlich sein kann.

Durchschnittswerte würden für mich also wenn nur je Partner Sinn machen und die könnte man dann ja wiederum aus den anderen Kennwerten ableiten. Aber selbst hier können solche Prognosen glaube ich schwer daneben liegen - selbst ähnliche Programme aus der gleichen Branche performen oftmals ja sehr unterschiedlich.

Beste Grüße,
Sascha

P.S.: Da es jetzt doch teilweise sehr ins Detail geht: Vielleicht kann man das ja Morgen auf der Tactixx noch vertiefen, wir sind da mit einem Stand vertreten!