Was ist ein Touch

Ausgehend von einem Touchpoint als abstrakte Definition eines Kundenkontaktes ist der Touch die konkrete Repräsentation dessen.

• Kunde 123 ruft bei der Hotline an
• Anonymer User ruft URL /hallo auf

Dieser Touch wird abstrakt minimal dargestellt als

Subject Action Object

Bei diesen Beispielen wird klar, dass eine wichtige Information fehlt, nämlich der Kontext, also z.B. Raum und Zeit.

Attribute eines Touches

• Subject: Wer:
• Action: macht Was:
• Object: mit Wem: Touchpoint
• Context
  • Location: Wo:
  • DateTime: Wann:
  • Intention: Warum
  • Initiator: Auslöser, Akteur
• Reaktion:

Subject

Eine Person, ein Segment oder eine ganze Zielgruppe. Hierbei ist die Berücksichtigung eines Consents wichtig.

Erst, wenn eine Person ihre Zustimmung gegeben hat, können ihre Daten individuell verarbeitet werden.

Davor ist nach DSGVO im EU Raum nur eine anonymisierte Erfassung möglich.

Also muss bei der Erfassung eines Touches bekannt sein, ob ein Consent vorliegt

Der Standard definiert dafür zwei Namensräume

urn:oms:v2020:subject:anon
urn:oms:v2020:subject:consent

Wenn der Consent für die Verarbeitung vorliegt, kann eine Zuordnung über Identifier erfolgen. Diese Identifier gelten nur für einen bestimmten Zweitraum, deshalb muss die Zuordnung zeitpunktbasiert erfolgen.

urn:oms:v2020:subject:id:mailto:a@example.org
urn:oms:v2020:subject:id:tel:+491234567890
urn:oms:v2020:subject:id:geo:48.33,14.122;u=22.5
urn:oms:v2020:subject:id:mailto:a@example.org

Eine Organisation kann unter einem eigenen Namespace auch eigene Identifikatoren definieren.

urn:oms:v2020:subject:private:q4rl.com:kid:0815

Action

Eine Aktion oder Interaktion, die ein Subject ausführt, wie zum Beispiel lesen, klicken,

urn:oms:v2020:action:view
urn:oms:v2020:action:click
urn:oms:v2020:action:submit
urn:oms:v2020:action:select
urn:oms:v2020:action:scroll

Eine Organisation kann unter einem eigenen Namespace auch eigene Aktionen definieren.

urn:oms:v2020:action:private:q4rl.com:beam

Object

Ein Touchpoint der über einen Namen definiert und unter einer Url lokalisierter ist.

urn:oms:v2020:object:ownedmedia
urn:oms:v2020:object:earnedmedia
urn:oms:v2020:object:paidmedia
urn:oms:v2020:object:platformedmedia

Context

Location

DateTime

Location

Location

Das Touch Log

Einen Touch zu erfassen, ist ähnlich wie bei einem Webserver oder einem Analytics Aufruf. Es is dabei nur wichtig, dass die Daten weiter verarbeitbar sind.

Ausführliche Notation

Bei der ausführlichen Notation ist kein Vorwissen notwendig, dafür sind viele Informationen redundant.

{
	"subject":"oms://q4rl.com/subject/pascal",
	"action":"urn:oms:v2020:action:read",
	"object":"oms://q4rl.com/object/om/q48.de/was-ist/touch",
	"context":
		{
			"utc_created":"2019-01-01T00:00:00Z"
		},
	"meta" :
		{
			"uin": "oms:uin:v1:q4rl.com:1234:456:"
			"base": "oms://q4rl.com"
			"@prefix q4:": "oms://q4rl.com"
			"utc_created":"2019-12-31T23:59:59Z"
		}
}

Kurze Notation

bei der kurzen Notation gibt es ein lokales config file, dass die Redundanzen reduziert

Config File auf dem Touchpoint Host: oms://q4rl.com/object/om/q48.de

{
	"@base subject":"oms://q4rl.com/subject",
	"@alias subject":"s",
	"@base action":"urn:oms:v2020:action",
	"@alias action":"a",
	"@base object":"oms://q4rl.com/object/om/q48.de/"
	"@alias object":"o",
	"@alias context:utc_created":"cdt",
	"@base meta:uin":"oms:uin:v1:q4rl.com",
	"@alias meta:uin":"muin",
}

Log Eintrag:

{
	"s": "/name/pascal",
	"a": ":read",
	"o": "/om/q48.de/was-ist/touch",
	"cdt": "2019-01-01T00:00:00Z"
	"muin": ":0815:42"
}

einzeilig:
{ "s": "/pascal", "a": "read", "o": "/om/q48.de/was-ist/touch", 	"cdt": "2019-01-01T00:00:00Z", "muin":":0815:42" }

Das Subjekt mit der ID: oms://q4rl.com/subject/pascal hat zum Zeitpunkt 2019-01-01T00:00:00Z eine Interaktion der Art ms:interaction:read beim Objekt oms://q4rl.com/object/om/q48.de/was-ist/touch ausgeführt.

Die Erfassung dieser Interaktion war zu einem anderen Zeitpunkt, nämlich 2019-12-31T23:59:59Z

Vom Touch zur Traction

Manche Berührungen sind zufällig. Und genauso sollten Touches überprüft werden, ob sie valide sind.

Dabei sind folgende Dinge wichtig:

• Ein Touch Log ist write-only, darf also nicht überschrieben werden. Die Erfassung muss also revisionssicher sein.
• Traction Daten können sich durch späteres Wissen verändern, also können sich auch Reports verändern. Späteres Wissen muss also einen Erkenntniszeitpunkt enthalten, damit man zum vorherigen Wissen zurück kehren kann.
• Ein Real Time Tracking wird dadurch erschwert, weil Touches erst prozessiert werden müssen

Um als Traction bewertet zu werden, muss ein Touch folgende Schritte durchlaufen:

1. Touch Tracking
2. Touch Validation
3. Retouche
4. Traction

Traction Log

Das Traction Log fasst die Tractions zusammen, die später ausgewertet werden können.

{ "s": "oms:anonym:handy:123", "a": "read", "o": "/handy", 	"dt": "2019-01-01T00:00:01Z" }

Retouche

Die Retouche analysiert Touches und entscheidet, ob sie valide sind oder nicht.

Dabei werden die originalen Touches nicht verändert, sondern auf Basis von transparenten Regeln gefiltert.

und sie ersetzt Elemente durch neues Wissen

Validität

Beispiel: Bounces

Regel: Eine Interaktion soll nur erfasst werden, wenn ein zweiter Touch stattfindet (Aktion: click, scroll, select)

Beispiel: Fraud Detection

Regel: Eine Interaktion soll nur erfasst werden, wenn der Besucher eine IP-Adresse hatte, die keinem Rechenzentrum zugewiesen ist.

Wissen

Der Retouche Server ersetzt veraltete Elemente durch aktuelle Referenzen

Beispiel: User Merging

User A surft mit Handy und Desktop auf einer Seite.

oms:anonym:handy:123 liest /handy
oms:anonym:desktop:123 liest /desktop

Er meldet sich mit der email a@example.org um 2019-01-01T00:00:05Z am Desktop an, bekommt einen Login-Link zugeschickt, klickt ihn auf dem handy um 2019-01-01T00:00:15Z an, dann weiss der Retouche Server jetzt:

Zum Zeitpunkt: 2019-01-01T00:00:15Z

Zum Zeitpunkt: `2019-01-01T00:00:15Z`
oms:id:email:a@example.org benutzt als Device M1 oms:anonym:handy:123 

Zum Zeitpunkt: `2019-01-01T00:00:15Z`
oms:id:email:a@example.org benutzt als Device D1 oms:anonym:desktop:123

Durch dieses neue Wissen kann das Interaktionslog aktualisiert werden:

vorher

{ "s": "oms:anonym:handy:123", "a": "read", "o": "/handy", 	"dt": "2019-01-01T00:00:01Z" }
{ "s": "oms:anonym:desktop:123", "a": "read", "o": "/desktop", 	"dt": "2019-01-01T00:00:05Z" }

Nachher

	{ "s": "oms:id:email:a@example.org", "a": "read", "o": "/handy", "d":"M1", 	"dt": "2019-01-01T00:00:01Z" }
{ "s": "oms:id:email:a@example.org", "a": "read", "o": "/desktop", "d":"D1",	"dt": "2019-01-01T00:00:05Z" }

Der Touch als Hit im Web

Ein Logfile des Servers Apache zeigt eine solche Darstellung im Common Logformat

LogFormat "%h %l %u %t \"%r\" %>s %b" common
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
<IP-Adresse> - <User> [<Zeitpunkt>] "<Anfrage>" <ServerResponseCode> <AntwortLänge>
<Location> - <Subjekt> [<DateTime>] "<Objekt>" <ReaktionDesObjektes>

Im Combined Logformat kommen noch der Referer und der User-Agent hinzu

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
<IP-Adresse> - <User> [<Zeitpunkt>] "<Anfrage>" <ResponseCode> <AntwortLänge> "<vorhergehendeSeite>" "<UserAgent>"

Subjekt Interaktion Objekt 

Touch Log

Touch URIs

Die formale Logik ist angelehnt an das RDF-Modell (Resource Description Framework) des W3C

Subjekt Prädikat Objekt

mit dem ein semantisches Netz dargestellt werden kann. Das RDF beschreibt sog. Ressourcen und gibt ihnen jeweils eine eindeutige Adresse, eine sog. URI (Uniform Resource Identifier).

Die bekannteste Anwendung von URIs sind URLs.

Analog dieser Logik hätte dann auch jeder Touchpoint eine URI.

Nach dem aktuellen Standard RFC 3986 besteht eine URI aus fünf Teilen:

• scheme: Schema oder Protokoll

• authority: Organisation, Anbieter oder Server im Sinne von Zuständigkeit

• path: hierarchischer Pfad

• query: Key-Value basierte Abfrage einer Ressource, die nicht durch einen Pfad alleine eindutig identifizierbar ist.

• fragment: Element innerhalb einer Ressource

    scheme ":" [ "//" authority "/" path ] [ "?" query ] [ "#" fragment ]
  

Nach dem Online Marketing Standard könnte z.B. eine URI des ersten Footer Links dieser Seite auf die Homepage folgendermaßen lauten:

oms2020://q4rl.com/q48.de/was-ist/touchpoint/#footer-home-link

• scheme: oms2020 – die Grundlage dieses Modells
• authority: Organisation, die den Touchpoint anbietet, also z.b. die primäre Domain oder Company ID
• path: also in diesem Fall bei Owned Media, die Domain als erstes Element des Pfades, dann der relative Ausgangspfad des Elements und
• query: Schema oder Protokoll
• fragment: als eindeutige Identifikation auf der Seite die Tag ID

Man erkennt schnell, dass die Konzeption des Pfades in der URI, eine Extrem wichtige Funktion zu Zuordnung, Wiedererkennung und Aggregation hat.

Und eine E-Mail von Pascal

oms2020://q4rl.com/pf@q4rl.com/[msg id]

• path: die E-Mail Adresse als erstes Element des Pfades, dann eine eindeutige Message id (z.B. des Mailservers)

Und ein Link in dieser E-Mail

oms2020://q4rl.com/pf@q4rl.com/[msg id]/[link id]

• path: die E-Mail Adresse als erstes Element des Pfades, dann eine eindeutige Message id (z.B. des Mailservers) und zuletzt die Link ID in der Nachricht.

Und ein Anruf

oms2020://q4rl.com/0123456789/[utc datetime]/[link id]

• scheme: oms2020 – die Grundlage dieses Modells
• authority: Organisation, die den Touchpoint anbietet
• path: also in diesem Fall bei Owned Media, die E-MAil Adresse als erstes Element des Pfades, dann der relative Ausgangspfad des Elements und als eindeutige Identifikation auf der Seite die Tag ID

Andere Beispiele

oms2020://q4rl.com/spiegelverlag/derspiegel/2019/24/U4
oms2020://q4rl.com/RMS/radiogong/2019-12-31-23-59-59
oms2020://q4rl.com/RMS/radiogong/2019-12-31-23-59-59

https://de.wikipedia.org/wiki/Uniform_Resource_Identifier https://tools.ietf.org/html/rfc3986