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

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