Willkommen zum ersten Talk vom MatomoCamp, genau gesagt der einen der beiden ersten Talks,
aber hier sind wir im deutschsprachigen Talk. Also der Moderator hier ist Joachim Nickel,
nutzt Matomo und Biwik schon seit über zehn Jahren und engagiert sich auch in verschiedenen
Open-Source-Projekten, wie zum Beispiel vor allem den CMS Contao, von dem ihr vielleicht
schon gehört habt und von dessen Förderverein ist er Präsident. Und er wird euch jetzt ein
bisschen mehr darüber erzählen, wie man mit Background Tracking etwas mehr Daten erfahren
in Matomo bekommen kann und genau gesagt auch damit, welche Alternativen es zum klassischen
Matomo JavaScript Tracking gibt, welches jeder kennt. Damit, Joachim, kannst du anfangen.
Danke, Lukas. Ja, hallo. Fangen wir gleich an mit dem zweiten Slide bei mir. Lukas hat
im Endeffekt schon im Großteil gesagt, ich bin OMT-Botschafter. Auf das Thema OMT
komme ich ein bisschen später noch zum Tragen. Präsident der Contao Association und Matomo
halt eben seit mindestens 2010, wahrscheinlich sogar schon noch ein bisschen länger. Heute
geht es um die Frage erstmal grundsätzlich, kann ich den Zahlen überhaupt vertrauen,
die wir in Matomo oder halt eben auch irgendwo anders in irgendwelchen Statistiksoftware
in dieser Art tracken? Und kleiner Teaser an der Stelle, ich würde mal sagen, ganz klares
nein. Das hat mehrere Gründe, denn wenn wir uns mal angucken, wie das Standard Tracking
funktioniert, was wir in Matomo haben, sei es über den Tag Manager oder über das normale
JavaScript Tracking, dann kommt der Besucher auf unsere Webseite, holt sich die Daten im
Endeffekt ab und in der Webseite steht dieser kleine Code drin, der halt eben sagt, du Browser,
gib mal die Daten dahinten zu unserer Matomo Instance und tracke das Ganze. Und genau
da haben wir halt eben wirklich dieses riesengroße Problem mit der Datenweitergabe, denn zum
einen gibt es diese Tracking-Schutzgeschichten, ETP und ETP, wie sie nicht alle so schön
heißen. Zum anderen haben wir das große Problem, das User-Consent, den wir halt eben häufig
einsetzen müssen, in Verbindung auch mit den Do-Not-Track-Headern. Aber und ganz speziell
das Problem der Ad-Blocker. Für 2021 habe ich eine Statistik gefunden, die davon ausgeht,
dass in Deutschland rund 40 Prozent der Nutzer, die auf den Webseiten unterwegs sind, Ad-Blocker
einsetzen, weltweit über 42 Prozent. Diese Werte differieren immer unterschiedlich von
den Herstellern, die diese Statistiken halt eben herausgeben. Teilweise gehen die Werte
auf bis zu 50 Prozent hoch und es ist sehr, sehr unterschiedlich bei den einzelnen Webseiten,
da kommen wir gleich drauf. Dieser Fakt war für mich im Endeffekt der Grund, warum ich
gesagt habe, dieser Weg vorne, der ist vielleicht nicht unbedingt der beste, weil halt einfach
zu viele Daten verloren gehen und deswegen sage ich, okay, streichen wir den Weg und
gehen direkt aus der Anwendung in Matomo rein, denn Matomo hat etwas sehr Schönes, was andere
Systeme nicht in der Form anbieten, nämlich die Tracking-API. Der Nachteil bei der ganzen
Sache ist, die Umsetzung muss halt eben in der Anwendung erfolgen und wir müssen dort
wirklich alle Parameter, die wir benötigen für das Tracking, halt eben selber uns zusammensammeln.
Wir haben also nicht den schönen Fall wie im JavaScript-Tracking, dass einfach alles
schon mehr oder weniger out of the box zur Verfügung steht und müssen dann halt eben
gesammelt diese Daten an Matomo schicken. Die Aufgaben, die dabei entstehen, ist zum
einen klar, wir müssen das Thema Session Handling klären, das heißt, wie bekommen wir die einzelnen
Besucher-Sessions zusammen? Matomo kann diese Aufgabe an der Stelle für uns nicht übernehmen,
wir müssen diese Aufgabe halt eben übernehmen in der Anwendung. Wir müssen selber uns um
die Borderkennung zum Großteil kümmern, denn alles, was wir halt eben direkt gegen Matomo
werfen, wird dort halt im Endeffekt ausgewertet. Eine Borderkennung an der Stelle ist schwierig,
weil es halt eben nachgeschaltet ist und wir müssen immer berücksichtigen, dass wir eine
gewisse Latenz haben. Das heißt also, die Anwendung selber sollte den Request an Matomo
auch erst dann schicken, wenn im Endeffekt die Ausgabe an die Webseite, also an den Kunden,
an den Webbrowser, das Kunden ausgeliefert wurde. Aber auch dann ist es doof, wenn der
Prozess halt eben noch zu lange braucht, weil der Weg bis zum Matomo API halt eben zu lang ist
und von daher könnte man sich überlegen, halt eben das Ganze auch selber irgendwo lokal zu
cashen und dann nachträglich erst an Matomo zu übergeben. Wir müssen so oder so mit einem
entsprechenden API-Key arbeiten in der Matomo Instanz, die einen Schreibzugriff hat, um zum
Beispiel die IP-Adresse halt eben auch zu übergeben, entweder gekürzt schon oder halt eben auch im
Klartext, um halt eben dort die Geo-IP-Auflösung zu machen oder wir machen eine Geo-IP-Auflösung
direkt in der Anwendung, das geht natürlich auch. Und alle überein, wir haben natürlich das Thema
des Datenschutzes, das heißt, wir haben in der Anwendung natürlich untreifiele Daten,
wir können möglicherweise den Kunden direkt eins zu eins identifizieren und müssen dann halt
eben überlegen, welche Daten übergeben wird, hat Sache an Matomo, nicht, dass wir hinsichtlich
der Datenschutz-Grundverordnung dort dann entsprechende Probleme bekommen. Gucken wir uns
mal im Vergleich an. Ich habe hier zum einen einen Regionalversorger, den ich diesbezüglich
ausgestattet habe, mit dem Standard Tracking und im Background und wenn ich mir das Ganze
angucke, dann habe ich hier einen Unterschied von ungefähr 60 Prozent, 60 Prozent mehr Daten,
die ich im Background Tracking für diesen Kunden identifiziert bekomme. Wir sehen hier unten auch
die Abweichung der Mobiltypen, also das heißt also, ob das ein Desktop-System ist oder halt
eben ein Mobilsystem. Im Background Tracking haben wir wesentlich mehr Desktop-Systeme, was die
Wahrscheinlichkeit oder die Vermutung hoch liegt, dass die Ad-Blocker halt eben auf Desktop-Browsern
höher sind. Man muss dazu sagen, das war zu einer Zeit, wo man auch auf iOS noch nicht so ohne
weiteres den Standard-Browser ändern konnte. Das heißt, jetzt ist es alles schon ein bisschen
anders. Ich persönlich nutze zum Beispiel sowohl auf dem Desktop als auch auf dem Telefon halt
eben den Browser Brave. Der macht halt eben das Tracking schon mal grundsätzlich schwieriger,
aber an der Stelle gleich noch die Information mit Matomo und in Verbindung mit kuckielosem
Tracking, dass die Matomo Instance auch auf dem gleichen Domain ist. Dann kommt sogar das
JavaScript Tracking durch den Brave Browser hindurch, während andere Sachen halt nicht
abgekapselt werden. Gucken wir uns einen zweiten Vergleich an den Kfz-Online-Shop. Hier sieht das
Ganze so aus, dass wir ungefähr 30 Prozent mehr Visits haben, aber schon ungefähr 40 Prozent mehr
Pageviews. Wodurch kommt das zustande? Ganz klar, einfach aus der Situation heraus, bei einem
Online-Shop im Gegensatz zu einem Regionaleinbieter, wo ich halt sehr häufig nur One-Pager-Visits habe,
habe ich hier natürlich wesentlich längere Visits. Und wenn dann halt eben ein Nutzer,
der länger durch den Online-Shop durchgeht, dann einen Blocker hat, dann werden natürlich die
Differenz zwischen der Anzahl der Visits und der Pageviews anders. Und das ist jetzt der Punkt,
wo ich auch dann im weiteren Verlauf draufkomme. Also hier habe ich noch die Erwähnung kurz
hinsichtlich der Thematik der Mobilbrowser. Das heißt, wir hatten im Standard Tracking halt
eben 74 Prozent Mobilbrowser und im Background Tracking dann noch 67. Das heißt, der Anteil
am Desktop ist auch wieder hier gestiegen und diese Unterscheidung, die muss man halt eben auch
immer berücksichtigen, weil möglicherweise gibt es im Background Tracking dann so viele
unterschiedliche Daten von den Systemen, dass man sich überlegen muss, ob die Strategie,
die man eigentlich wählen wollte, wirklich die richtige ist. Ja, jetzt kommen wir zum OMT. Der
OMT ist eine Online-Plattform, der Treffpunkt für Weiterbildung und Netzwerken im Online-Marketing.
Der Claim vom OMT ist, lebenslang voneinander lernen. Ich bin auch Botschafter der OMT und hatte
halt eben die Chance, diese Seite auch auszuwerten. Hier hatten wir eine Installation mit Google
Analytics. Im Parallelflug dann eine Matomo Standard Installation. Dort gab es mehr oder
weniger eigentlich kaum Abweichungen. Deswegen lasse ich das hier an der Stelle mit Google
Analytics im Vergleich weiter raus. Und dann hatten wir einen Uplift von 15 Prozent in den
Visits. Da war erst mal die große Enttäuschung von wegen, wow, der Unterschied ist ja doch relativ
wenig. Anscheinend nutzen gar nicht so sehr viele Leute hier auf dem System Adblocker. Und dann
guckte ich mir die Daten halt eben in den Pageviews an und stellte fest, okay, ich habe jetzt die
Google Analytics rausgelassen, weil das hat uns an der Stelle keine weiteren Punkte gebracht. Wir
haben hier doch ein paar ganz andere Daten und zwar wir haben 80 Prozent mehr Pageviews gegenüber den
Visits. Das heißt also 15 Prozent mehr Visits, aber 80 Prozent mehr Pageviews. Das wollte ich
mir dann halt immer ein bisschen genauer angucken, aber erst mal die Statistik angeguckt, das ist eine
Online-Lernplattform. Das heißt also, die Leute gehen wirklich häufig unter der Woche drauf. Das
heißt also, die Wochenend-Terminis, die sind einfach entsprechend viel, viel geringer und deshalb diese
Einbrüche an der Stelle. Auch hier, wir haben einen enorm hohen Anteil an Desktop-Nutzern. Das heißt
also, selbst im normalen Tracking haben wir 73 Prozent Desktop-User, während wir dann im
Background sogar schon auf 84 Prozent hochkommen. Die 73 bis 84 Prozent merken wir uns schon mal,
weil jetzt kommen wir mal ein bisschen weiter und gucken uns das Ganze in einer Differenzierung an.
Wir haben das Ganze jetzt mal segmentiert und zwar habe ich die ganzen Einzelpageviews
herausgelassen, um mal zu gucken, was dort halt eben passiert und habe halt eben festgestellt,
bei den Visits haben wir jetzt nicht mehr 15 Prozent, sondern schon 35 Prozent mehr und wenn wir
uns die Pageshoes an der Stelle angucken, dann kommen wir hier sogar auf 140 Prozent. Wir merken
vorher 15 Prozent zu 35 Prozent und 80 Prozent zu 180 Prozent und der Anteil der Nutzer im Desktop-
Bereich geht sogar hier mittlerweile auf 91 Prozent hoch. Die Datenbasis, die wir hier haben,
bei den Pageshoes mindestens zwei, sieht so aus. Wir haben also im Standard Tracking 24 Prozent der
Visits, die etwa 53 Prozent der Pageshoes generieren. Im Background Tracking sind das halt eben nur 5
Prozent mehr an Visits, aber wir haben 18 Prozent mehr an Pageshoes, die hier generiert werden. Das
heißt also, wir sehen hier ganz klar die Differenzierung, die Nutzer, die Adblocker
in dem Fall einsetzen, bringen hier in dem Fall eine wesentlich höhere Anzahl an Pageshoes mit
sich und wenn wir das Ganze auf die Pageshoes-Anzahl von mindestens vier anheben, dann ist diese
Differenz noch mal wesentlich höher. Ja, gucken wir uns ganz kurz die Technik an, von vorne und von
hinten. Von vorne ist halt eben klar die normale Standard Tracking Variante. Das Background Tracking
habe ich hier in der Mitte eingefügt und ganz unten zum Vergleich die Variante, wenn wir mit
Matomo Log File Analytics betreiben, dass man so ein bisschen was sehen kann, wie die uns in
Unterschiede sind. Ereignisse, sprich Event Tracking ist im Standard Tracking überhaupt kein Thema.
Über den Tag Manager, über die normale JavaScript Integration oder ähnliches,
perfekte Ausprägung, können wir alles machen. Im Background Tracking ist das per se erst einmal
von Hause aus gar nicht möglich, weil das Tracking erfolgt ja direkt aus der Anwendung
heraus, sprich in dem Augenblick, wenn das HTML generiert wird. Ich weiß also um die gesamten
Nutzerinteraktionen überhaupt nichts. Wenn ich das halt eben mit reinbringen wollte, müsste ich
mir eine eigene Schnittstelle bauen, mit der ich dann halt diese Daten zusätzlich über die
Tracking API innerhalb der Anwendung halt eben nach Matomo einspeise. Das ist ein bisschen komplizierter,
ist aber theoretisch denkbar. Innerhalb des Log File Trackings überhaupt keine Chance,
irgendetwas mit Ereignissen zu machen. Inhaltselemente Tracking, genau das Gleiche.
Standard vorhanden im Background Tracking eben nur über eine eigene Schnittstelle,
die wir schaffen müssen. Das Gleiche gilt auch für die Downloads, wobei die Downloads halt
eben im Log File Tracking halt vorhanden sind. Das heißt, da haben wir keine Probleme an der
Schnittstelle. Ebenfalls die ausgehenden Links, gleiche Variante über den Background Tracking,
ich muss das über eine eigene Sache lösen. Das sind ja alles Interaktionen innerhalb des Browsers,
die passieren, die kann ich so direkt nicht hinbekommen. Im Log File Tracking überhaupt
keine Chance, das Ganze zu regeln. E-Commerce Tracking ist im Background überhaupt kein Thema,
weil die Daten zu E-Commerce stehen halt sogar noch viel früher zur Verfügung, als sie halt
eben per JavaScript Tracking ganz normal zur Verfügung stehen würden. Auch hier im Log File
Tracking keine Chance da ranzukommen. Cookies können wir natürlich verwenden, um die Leute
wiederzuerkennen im Standard Tracking, inwieweit man das machen will, in Hinsicht auf die User
Consent freie Variante oder ob man dort ein Hybrid Tracking nutzt. Das sei halt eben selbst
überlassen. Im Background muss ich mir da halt eben schon ein bisschen was anderes überlegen,
wie ich den Nutzer halt eben dann da wieder erkennen kann. Ich kann natürlich auch aus der
Anwendung heraus einen lebenslangen Cookie setzen, mit dem ich den Nutzer dann nachträglich wieder
identifizieren kann, aber die Logik muss ich mir da natürlich wiederum in die Anwendung reinholen.
Adblocker werden halt beim Standard Tracking oder sind beim Standard Tracking genau das Problem,
weshalb ich ja dieses Background Tracking durchführen möchte. Im Background Tracking ist es
überhaupt kein Thema, da kommen alle Nutzer an Daten an und zwar eigentlich sogar schon viel zu
viele, denn auch die ganzen normalen Bots werden ja halt eben hiermit protokolliert, aber da gehe
ich gleich nochmal drauf ein. Im LogFi Tracking genau das gleiche und das Thema Caching möchte
ich hier in der Stelle kurz erwähnen. Das Standard Caching, also sprich HTTP Caching, ist mit dem
Standard Tracking überhaupt kein Thema. Wenn ich das aktiviere oder gar ein CDN verwende und das
Background Tracking nutzen möchte, habe ich dort Probleme, weil die Daten für das Tracking kommen
ja gar nicht mehr in der Endanwendung an, weil die Daten kommen ja direkt aus dem Caching-System,
aus dem CDN heraus und somit habe ich dort halt eben die entsprechenden Probleme, diese Daten zu
erfassen. Beim LogFi Geschichten müsste ich dann in dem Fall auf das Tracking aus dem CDN setzen,
nicht aus den einzelnen Server. Session Erkennung, klar, wenn ich halt eben nicht auf Cookies setze,
im Standard Tracking passiert das übers Fingerprinting. Im Background Tracking habe
ich das über das System. Meistens habe ich ja so oder so im System die Variante, dass ich zum
Beispiel eine Warenkopf-Funktionalität habe. Ich erkenne ja den Nutzer anhand der Session und
damit habe ich auch eine wesentlich genauere Session-Erkennung, als ich das jemals mit
Fingerprinting oder Ähnlichem hinbekommen könnte. Und beim LogFi Analytics, da brauchen wir gar nicht
drüber nachzudenken, da wird irgendwie versucht gemacht, aus der IP-Adresse dem User Agent
irgendwie grob herauszufinden, ob das eine zusammenhängende Session sein könnte oder nicht.
LogFi Tracking ist immer eine schöne Parallelvariante, um erstmal überhaupt Gefühle
für zu bekommen, was uns im Standard Tracking möglicherweise abhanden geht, um einfach eine
Größenordnung und Zielgrößenordnung halt eben mal zu ermitteln. Und das ohne den Aufwand zu
betreiben, das Ganze innerhalb des Systems möglicherweise zu integrieren. Integration,
klar, Standard JavaScript Code einfach einbinden, fertig ist die Laube. Bei dem Background Tracking
muss das in der Anwendung erfolgen. Ich habe ein fertiges Modul für das CMS Contaro entwickelt.
Für WordPress bin ich ja relativ weit. Da müssen noch ein paar Tests gemacht werden.
Da sind so viele Unwägbarkeiten mit Erweiterungen, die reinkommen, die dann halt in diese Erweiterung
von mir, die ich entwickelt habe, stören könnten. Da müssen wir halt noch ein paar Tests machen.
Wer Interesse an dieser Erweiterung hat, kann sich gerne bei mir melden. Dann können wir mal
gucken, dass wir da einen kleinen Test mitmachen. Und beim LogFi Importing, klar, da muss das Ganze
halt im Lokal aufgesetzt werden, dass die LogFi Importing wird. Kommen wir zu dem wichtigen
Punkt der Erkennung der Bots. Wir haben erstmal grundsätzlich die Situation, innerhalb des
Webs kommen gerade mal so um die 50 Prozent, vielleicht auch 60 Prozent des Traffic, der
echt durch Menschen erfolgt. Ein großer Anteil von 22, 25 Prozent sowas in den Dreh kommt von
unschädlichen Bots. Unschädliche Bots sind also zum Beispiel der Google Bot selber, der Bing Bot,
Yandex und wie sie nicht alle heißen, aber auch die ganzen anderen Dienste wie SysTricks, wie
Ksovi oder anderen Diensten, die halt eben die Webseiten durchkennen oder halt und auch wir selber
im Zweifelsfall mit Screaming Frog oder sowas. All die Bots, die sich halt eben selber anhand des
User Agent Strings identifizierbar machen, dass sie halt eben Bots sind, können wir als unschädliche
Bots identifizieren oder auswerten in der Form, dass wir sagen, ja, wir können die halt sowieso
sofort ausfiltern und wir wissen, was dort passiert und alles ist gut. Der große Punkt, der wichtig ist,
den wir kennen sollten, der aber grundsätzlich, egal ob bei Google Analytics, Matomo, Standard
Tracking oder ähnlichem ist, das sind diese Impersonator Bots. Das sind etwa 25, 26 Prozent
sowas in den Dreh des Traffics, gehen auf solche Bots. Die tun so, als wenn sie echte, ja, Menschen
wären, die die Webseiten absuchen. Das heißt, der User Agent ist gefälscht logischerweise,
als wäre es halt eben ein normaler Windows Rechner mit einem Chrome Browser und ähnlichen Geschichten.
Er akzeptiert auch Cookies, Obsession Cookies, auch Langzeit Cookies. Diese Cookies werden
teilweise auch über die Instanzen hinweg geteilt. Ich habe also teilweise Sachen gesehen, wo ich
sagte so, dass diesen Menschen möchte ich echt gerne mal kennenlernen, der innerhalb von gerade
mal 15 Minuten einmal aus Asien, einmal aus USA und einmal aus Schweden auf die Webseite zugreift
und jedes Mal immer nur eine und dieselbe Seite und zwar nicht die Startseite, sondern irgendeine
Unterseite. Und daran erkennen wir halt eben ganz klar, das sind halt eben diese Impersonator Bots,
die so tun, als wenn sie Menschen wären, die machen auch Scroll-Events aus, die lösen auch
Lesezeit-Trigger und solche Geschichten aus. Die klicken auch tatsächlich halt eben auf Buttons
und lösen CTAs aus. Das heißt also, wir erkennen anhand des Verhaltens dieser Bots nicht, ob das
wirklich Menschen sind oder ob das eben Bots sind. Die machen wirklich einen verdammt guten Job und
die nerven uns in den Statistiken. Ich habe hier von 2020 noch mal eine etwas aktualisierte Version
von einem anderen Anbieter. Der geht halt eben davon aus, dass wir ebenfalls so um die 25 Prozent
Bad Bots haben. Hier geht man von etwa 60 Prozent Humans aus. Die Werte, muss man jetzt immer wieder
sagen, solche Statistiken sind immer gefärbt. Je nachdem, was für Zugriffe die Anbieter der
Statistiken haben, sind die unterschiedlich. Deswegen, es kommt immer darauf an, schlussendlich,
was auf eurer eigenen Webseite, die ihr überwachen wollt, identifizierbar ist und getrackt werden kann
und dann muss man halt eben die Sachen machen. Ich habe hier mal einen kleinen Vergleich mitgebracht,
was das Thema Impersonator Bots angeht. Dieser Vergleich ist ein bisschen unfair. Das ist meine
eigene Webseite, die ich vom 31. August bis zum 19. September mal im Parallel-Tracking hatte,
und zwar mit einer Matomo-Instanz, wo keinerlei Bot-Erkennung in den Griff war und eine Instanz,
in der ich halt eben alles drin hatte, was ich auffahren konnte, eine manuell gepflegte IP-Adress-
Ausschlussliste von Bot-Netzwerken und Ähnlichem. Der Unterschied sieht halt so aus. Die Kurve ist
identisch, aber die Anzahl halt nicht. Ich habe also fast die Hälfte nur an realen Zugriffen,
die ich halt eben identifizieren konnte, dass das halt wirklich Menschen waren. Der Rest sind
tatsächlich halt eben solche Impersonator Bots gewesen, und die produzieren halt eben auch in
den Seitenansichten gänzlich andere Werte für mich. Das heißt, die Daten, die ich hier habe,
hinsichtlich Lesezeit, hinsichtlich Absprungrate und Ähnlichem, die sind komplett aus dem Ruder
gelaufen, weil ich so viele Impersonator Bots darauf habe. Warum habe ich bei mir so viele? Das
ist ja fast das Doppelte von dem, was ich an normalen Besuchern habe. Ich sagte, wie gesagt,
dieser Vergleich ist so ein bisschen gemein. Bei meiner Webseite www.job.de verwende ich auch
gleichzeitig als Weiterleitungsziel von über 100 anderen Domains, teilweise abgelaufenen
Expired Domains, teilweise Domains, die ich halt eben selber mal von Projekten hatte, aber auch
bestimmt an die 30, 40 Domains, die noch nie irgendwo in Erscheinung getreten sind,
die ich mal registriert habe, die aber ansonsten nie irgendwo in Erscheinung getreten sind. Und
trotzdem bekommen diese Domains massenhaft Besucher von Bots. Und deswegen nutze ich diese
Webseite so ein bisschen als meinen kleinen Honeypot und kann darüber sehr schön halt eben
IP-Adress-Segmente identifizieren, die ich halt eben dann zum Beispiel über WhoIs-Analysen und
Ähnlichem herausfinde, ob diese Daten-Segmente oder diese IP-Adress-Segmente halt eben zu eher
Netzwerkbetreibern dient oder nicht. Thema Erkennung der Bots allgemein. User-Agent ist halt eben eine
freiwillige Angabe, das heißt, die kann definitiv gefälscht sein, darauf sollte ich mich nicht
verlassen. Die Akzeptanz als Session-Cookies zu nutzen ist schwierig, weil erst beim zweiten
Zugriff kann diese Variante halt eben geträgt werden, aber auch Bad-Bots akzeptieren wie gesagt
diese Cookies und scheren die Cookies, verteilen diese Cookies über ihr gesamtes Netzwerk-Segment
und schlussendlich bleibt uns nur die IP-Adresse und da müssen wir halt eben gucken, dass wir dort
eigenständige Filter aufbauen. Problem an der Stelle ist, wir können halt eben die innen und
statische IP-Adress-Segmente nicht so wirklich identifizieren und alles läuft im Endeffekt
darauf hinaus, wenn ich so ein Background-Tracking machen will und die Daten sauber haben will. Ich
muss immer wieder selber auf die Suche nach manuellen Mustererkennungen gehen, um das Ganze zu
handhaben. An der Stelle möchte ich eine Erweiterung von Matomo ins Licht des Fokus richten, weil wenn
ich mir die Downloads-Anzahl von der Tracking Spam Prevention angucke, die lediglich bei 1.828
lag jüngst, als ich diesen Screenshot gemacht habe, dann ist das schon extrem wenig. Diese
Erweiterung sollte eigentlich meiner Ansicht nach wirklich jeder in seiner Matomo Instanz installieren,
weil ich habe hier nicht nur die Möglichkeit zu sagen, ich möchte IP-Adress-Segmente ausschließen,
die beispielsweise von bekannten Cloud-Anbietern wie Oracle, Amazon, Azure Cloud und Ähnliches sind,
da werden Listen automatisiert heruntergeladen. Die sind nicht vollständig, muss ich ganz klar
dazu sagen, aber es ist erstmal schon mal ein sehr, sehr guter Ansatz. Und ich habe aber hier die
Möglichkeit, über Exclude Countries etwas zu machen, um die Datenqualität zu erhöhen. Wenn ich
zum Beispiel eine Webseite habe, wo es mich überhaupt nicht interessiert, ob die Nutzer
aus China, aus den USA, aus Schweden oder Ähnlichem kommen, dann sollten wir aber gucken,
dass diese Sache hier möglicherweise in die Exclude Countries eben mit aufgenommen wird.
Alternativ die Variante, das Ganze umzudrehen, wenn ich sage, mich interessieren wirklich nur
die Nutzer aus dem deutschsprachigen Raum, aus dem Dachraum, dann füge ich möglicherweise einfach
nur hier in Deutschland, Österreich und Schweiz hinzu, möglicherweise noch Frankreich und England
und ähnliche Geschichten, die halt so ein bisschen mehr reinkommen. Aber das sind die Kunden, die
mich interessieren in meinem Logging und ich kann damit schon mal enorm viele log-volle Einträge
halt eben eliminieren, basierend darauf, dass halt eben diese Geo-IP-Datenbank verhältnismäßig
aktuell ist und halt eben verhältnismäßig gut funktioniert. Man muss dazu sagen, diese
kostenfreie Datenbank von der BWIP, die standardmäßig bei Matomo mitinstalliert wird,
beziehungsweise halt angeboten wird, ist aufgrund der Tatsache, es ist eine kostenfreie Variante,
nicht immer hundertprozentig aktuell. Es gibt eine kostenpflichtige Variante, die ist wesentlich
aktueller. Es gibt auch den Dienst von MaxMind, die ist auch wesentlich aktueller. Für die
Country-Erkennung ist meiner Ansicht nach diese kostenfreie Variante aber mehr als ausrangig.
Und die zweite Variante ist halt eben die Liste der global ignorierten IP-Adressen halt wirklich
selber zu pflegen. Ich habe hier an der Stelle wirklich mittlerweile eine Liste von über 1400
IP-Adress-Segmenten, die ich identifiziert habe, die ich hier reinwerfe. Aber man muss dazu sagen,
wenn ich so viele Daten hier drin habe, ist natürlich die Last von Matomo noch einen ganzen
Ticken höher, weil bei jedem einzelnen Abruf muss ja geprüft werden, habe ich einen Blacklist-Ausschluss
oder nicht. Schlussendlich, die manuelle Mustererkennung ist mit eines der wichtigsten
Dingen. Wir müssen dann die IP-Adresse überprüfen und die Bereinigung der Log-Daten durchführen. Da
hilft uns Matomo, indem wir halt eben diese DSGVO oder GDPR-Segmentbereinigung haben, wo ich dann
sagen kann, ok, dieses IP-Adress-Segment möchte ich bitte löschen und dann werden diese gesamten
Daten aus Matomo rausgenommen und ich kann damit halt entsprechend weitergehen. Dann sollte ich
die Liste logischerweise aktualisieren und dieses IP-Segment dann entsprechend mit aufnehmen als
Ausschlussvariante und in dem Zusammenhang möchte ich ganz kurz auf die Anonymisierung von IP-Adressen
eingehen, denn wir müssen mal ganz kurz nachgucken, welche Einstellung hier für diesen Fall, dass ich
so eine manuelle Mustererkennung machen möchte und die Daten auch bereinigen möchte, was ich
für eine Einstellung nutzen wollte. Wenn ich ein Byte anonymisiere, dann packe ich im Endeffekt
ein Cluster von 254 IP-Adressen zusammen und ich kann noch relativ genau sagen, ok, dieses IP-Adress-Segment
liegt mit hoher Wahrscheinlichkeit nur im Einzugsbereich eines Dienstanbieters, eines
Providers. Gerade bei Cloud-Anbietern, die haben meistens mindestens ein Class-C-Netz, also sprich
254 IP-Adressen, die kann ich halt eben darüber relativ gut identifizieren, selbst wenn ich halt
hinten die Variante mit der Null verwende, beziehungsweise ich gucke dann eben nach, wer
gehörte in dieses gesamte IP-Adress-Segment und dann kann ich schon so ein bisschen darüber mehr
Informationen bekommen. Wenn ich die Standardvariante, die empfohlen ist, bei Matomo belasse, das heißt
diese 2-Byte-Variante, dann packe ich in dieses Cluster 65.000 IP-Adressen. Das ist definitiv zu
viel. Also wenn ich diese Einstellung verwende in Matomo, kann ich es knicken, irgendwie versuchen
zu wollen, zu identifizieren, ob dieser Zugriff aus einem IP-Adress-Segment gekommen ist,
was zu einem Netzwerk-Providerdienst oder Ähnlichem, oder ob es ein Dial-In-Netzwerk ist, kann ich an
der Stelle vollends vergessen. Und wenn wir auf 3-Byte gehen, da braucht man gar nicht drüber zu
sprechen, das sind lieber 16 Millionen IP-Adressen, dann kann ich auch eigentlich diese
Lockfall-Analytics-Geschichte bezogen auf die Besuchervarianten komplett integrieren.
Die Datenschutzgeschichte hier unten, also in dem Fall jetzt für unsere Identifizierung für Bots
und Ähnlichem, eher wenig interessant. Und worum geht es im Endeffekt? Im Endeffekt muss man halt
in dieser manuellen Erkennung durch das Besucher-Lock durchgehen und schaut sich dann halt eben hier
diese IP-Adress-Segmente an und nimmt die Würfte gegen die US-Datenbank und schaut sich das Ganze
dann entsprechend an. Ja, damit komme ich eigentlich auch schon zum Resümee meines Vortrags. Wenn wir
halt eben wirklich vollständige Besucher-Daten haben wollen, müssen wir auf das Background-Tracking
setzen. Alternativ, mit einer geringeren Einstiegshürde, um erstmal zu gucken, was geht
uns an Adblockern möglicherweise verloren, ist halt die Lockfall-Analytics. Problem an der Stelle,
wenn ich die Lockfiles zu sehr anonymisiert habe von der IP-Adresse, das heißt also auch mehr als
dieses Class-C-Segment, dann kann ich auch Matomo an der Stelle nicht die Chance überlassen,
bestimmte Daten halt eben rauszufiltern anhand von dieser Tracking-Spam-Prevention-Variante oder halt
eben auch der eigenen IP-Adress-Filtergeschichte. Wenn da halt eben ein Class-C-Netz oder ein
Class-B-Netz halt eben nur anonymisiert ist, dann kann ich das mit den Lockfiles vergessen,
um dann wirklich die Daten zu bereinigen. Ich werde Insights bekommen, ohne Frage,
aber ich werde nicht wirklich identifizieren können, ob das halt eben normale User-Zugriffe
waren, ohne halt eben eher Zugriffe aus Bordnetzwerken. Dadurch kann ich halt eben,
wenn ich das mache, mit dem Background-Tracking oder Lockfile-Geschichten halt eben die Adblocker
umgehen und muss aber gucken, wie sieht es dann halt eben mit den Anwendungsebenen aus, also sprich
mit dem HTTP- und User-Caching, Anwendungscaching allgemein, das heißt, wo kann ich da halt überhaupt
ansetzen, bringt mir das überhaupt was, dieses Background-Tracking zu entwickeln? Ich muss halt
eben eine gute Strategie haben hinsichtlich der Borderkennung, die, wie ich schon gesagt habe,
zum Großteil halt über IP-Adress-Filter läuft und meine Empfehlung an der Stelle immer paralleles
Tracking von vorne, also sprich normales Tracking per JavaScript und das Tracking von hinten parallel
durchführen, weil von vorne bekomme ich Insights, die ich nur mit erheblichem Aufwand durch das
Background-Tracking bekomme. Es geht mir hier im Background-Tracking wirklich darüber oder
vorrangig darum, mal für die jeweilige Webseite herauszufinden, was haben wir denn für einen
Verlust in dem normalen Tracking, um gegebenenfalls das normale Tracking halt eben einfach mit dem
entsprechenden Faktor x uns ein bisschen schön zu rechnen und dadurch trotzdem halt eben bessere
Insights an der Stelle zu bekommen. Wir müssen auch wieder sagen, wenn ich die Sache von OMT
mir angeguckt habe, dort ist keine Möglichkeit zu sagen, ich nehme jetzt einfach den Faktor 1,5,
um halt eben dann zu berechnen, was ich an Nutzern hätte. Mir gehen wirklich viel,
viele Fakten verloren, die gerade im Bereich des Conversions oder auch des Performance-Marketings
relevant sind, weil wenn ich wirklich den Benutzer verliere, der sehr viel mehr Page-Fuse generiert,
der halt eben Umsatz generiert, der halt eben die Käufe macht, wenn ich den im Standard-Tracking
nicht drin habe, aber ich kann den im Background-Tracking erfassen, dann ist das eine ganz andere
Thematik, auf der ich dann halt eben auch meine Google-Ads-Investitionen halt eben anders
steuern könnte, weil ich vielleicht wirklich sehe, dass die Anzeige A gänzlich besser performt,
als die Anzeige B, wie ich es normal aus dem Standard-Tracking herausnehmen könnte. Also von
daher gucken, wie sieht es aus. Dann halt ganz klar das Thema Privacy by Design durchführen,
wie sieht es mit dem User-Consent aus, dass wir halt eben die Daten wirklich vollständig
anonymisieren und natürlich klar unseren Matomo-Instance auf einem eigenen Server
betreiben und dann könnte das Ganze, je nachdem, wie wir es halt eben mit unserem
Datenschutzbeauftragten besprechen, dann halt auch gut funktionieren. Ja, ich würde mal sagen,
halbe Stunde Talk, halbe Stunde Punktlandung und von daher sage ich an der Stelle schon mal,
meinen herzlichen Dank und ja, freue mich jetzt auf Fragen, die reinkommen würden.
Genau, jetzt wäre der Zeitpunkt für alle, falls ihr irgendwelche Fragen, Kommentare,
sonstige Dinge zu dem Thema habt. Eine Frage-Diskussion hat es schon gegeben,
die hätte ich ja auch gestellt, ansonsten, damit könnte man vielleicht gleich mal anfangen,
ist ein bisschen das Thema Datenschutz, Opt-out und so weiter. Das Problem ist ja,
mit der normalen JavaScript-Rap-King ist es relativ simpel, ein Opt-out zu machen,
weil man setzt ein Cookie, das funktioniert einfach mit der Matomo-Funktion und damit ist es
relativ straight forward. Beim Background-Tracking muss man das ja mehr oder weniger selber
implementieren, wie wir das uns dann vorstellen. Im Background-Tracking muss so oder so alles
selber integriert werden, aber genau dort kann ich natürlich auch selbst auf den JavaScript
gesetzten Cookie halt eben zurückgreifen und interpretieren, ob ich das halt eben nutzen darf,
nutzen will. An der Stelle muss man aber natürlich auch sagen, dass das Background-Tracking ist eine
rein technische Ansatz, der prinzipiell die Daten erst mal zur Verfügung stellt. Wie wir das Ganze
hinsichtlich des Datenschutzes dann handhaben, das ist immer noch eine zweite Frage. Ich wollte
jetzt erst mal nur die grundsätzliche Idee, dass das Background-Tracking halt eben der
Möglichkeit an Daten herankommen präsentieren. Aber ja, wenn wir wirklich über ein Opt-out
sprechen und halt eben diese Daten wirklich benötigen oder das nötigerweise umsetzen müssen,
dann ist es richtig, dann kann man das über ein Cookie machen und den kann ich in der
Anwendung dann auch beliebig auswählen. Okay. Ja, wenn es keine weiteren Fragen gibt...
Wir lassen den Leuten mal ein bisschen Zeit, das ist ein bisschen Verzögerung zwischen dem,
was wir hier reden, bis die Leute das sehen. Ja. Entweder habe ich alles so wunderschön
erklärt oder keiner traut sich. Ach doch, da tippt jemand. Ah ja, perfekt.
Auch ansonsten, ihr könnt mich gerne bei LinkedIn und Facebook kontaktieren und da auch jederzeit
gerne Fragen stellen. Ich stehe da gerne mit Rat und Tat zur Verfügung. Genau. Und falls ihr in den
nächsten Stunden auf irgendwas draufkommt, der Chatraum bleibt da offen, da ist nur für den einen
Talk, da kann man während des ganzen Matomo-Camps einfach weiter reden. Genau. Eine Frage aus dem
Chatraum. Gerade hast du Erfahrungen mit Hybridansätzen? Ja, ich habe zwei Ansätze
jetzt momentan gerade in der Vorplanung, wo wir halt eben das normale Tracking ohne User-Consent
umsetzen wollen und zusätzlich dann halt eben den entsprechenden User-Cookie setzen wollen,
wenn der User-Consent vorhanden ist, ist in der Planung, aber ich habe da noch keine Erfahrungswerte.
Tracking für die MP3-Abrufe. Das wird mehr oder weniger wahrscheinlich eher nur eine Variante
sein, das entweder über Lockfall Analytics zu lösen oder aber du schaltest die Analyse oder
besser die Bereitstellung der MP3-Geschichten, zum Beispiel über einen PHP-Redirector, der halt
eben an sich als virtuelles Verzeichnis quasi funktioniert und dann die Daten halt eben in
Empfang nimmt, die Abrufe in Empfang nimmt, die Requests und das dann halt eben auch dann genauso
an die Matomo-RPI schickt als entsprechenden Request. Das lässt sich also problemlos lösen.
Können wir gerne mal drüber sprechen. Genau, ein Proxy-Script. Genau. Genau, so etwas hätte ich auch
vorgeschlagen. Eine Frage ist mir auch noch gekommen, die jetzt nicht im Chat gestellt wurde und zwar
der ein Problem, was ich bei Background-Tracking ein bisschen sehe, ist, wenn wir zum Beispiel eine
ganz normale, ganz simple PHP-Seite haben, dann würde das heißen, jedes Mal, wenn diese PHP-Seite
aufgerufen wird, wird eine Anfrage an Matomo-Server geschickt und das Problem ist, im Gegensatz zum
JavaScript-Tracking heißt es, wenn man das jetzt falsch programmiert, dass der Background-Server wartet,
bis er die Antwort von Matomo bekommt und erst dann die Anfrage an den Benutzer fertig schickt und
somit eigentlich der Seitenaufruf etwas langsamer wird. Ja, das ist die Standard-Fehlerproblematik an dem
Thema, aber man kann das Ganze insofern umgehen. Das mache ich zumindest so, dass ich die
Datensammlung innerhalb des Standard-Prozesses für die Seitengenerierung mache, aber erst nachdem im
Endeffekt der, ja, ob Flash funktioniert, das heißt also die gesamte HTML-Ausgabe an den Kunden
ausgeliefert wurde, kommt dann im Endeffekt als letzter Task der API Connect zum Matomo. Variante 1,
dann habe ich im Endeffekt die Situation, dass zwar der Prozess noch ein tippen länger läuft,
aber die Session zum Browser ist bereits eben geschlossen und dementsprechend bekommt der
Nutzer von diesem Request nicht mehr mit. Die zweite Variante ist es, diese gesamten Daten,
also die gesamten Tracking-Informationen selber sich in eine Datenbank zu schreiben. Da bin ich
gerade dabei, das mal durchzuspielen und dann mit einem separaten Prozess die Daten aus der
Datenbank zu nehmen und dann gegen Matomo zu werfen. Dadurch, dass ich sowieso mit einem
Schreibzugriff arbeiten muss, mit dem API-Key, kann ich ja auch die Uhrzeit des Zugriffes
nachträglich setzen, habe dann zwar einen griffelsten zeitlichen Verzug, habe keine Echtzeitanalyse an
der Stelle in Matomo, sondern halt eben ein, zwei Minuten verzögert, aber das scheint mir gerade
für High-Traffic-Seiten die elegantere Variante, dass ich wirklich mein Logging im Endeffekt nur
in eine lokale MySQL-Datenbank oder wie auch immer Datenbank halt eben speichere und von dort aus das
Ganze wieder raushole und gegen Matomo werfe. Eine Lösung, die ich dann auch noch hätte,
das geht in PHP leider relativ schlecht, aber in anderen Programmiersprachen wäre es zum
Beispiel auch eine Möglichkeit, einfach wirklich, dass das Server mehrere Prozesse hat und dann
einfach das Abschicken der Daten an Matomo in einem separaten Thread auslagert und dann halt
wirklich komplett unabhängig von der Anfrage an den Benutzern ist. Weil der muss ja nicht warten,
weil man braucht die Informationen davon ja nicht, um den Benutzern seine Daten schicken zu können.
Genau, aber das kann man in PHP genauso machen, da kann ich auch ein Thread einfach auslagern.
Genau.
Ja, wie gesagt, wenn noch weitere Fragen sind, gerne jederzeit Kontakt aufnehmen bei LinkedIn,
Facebook oder über meine Webseite selber. Gerne auch auf meiner Webseite einen Termin
buchen für eine Besprechung, dann können wir uns halt eben individuell euren Bedarf auch gerne ansehen.
Ansonsten, falls es keine Fragen mehr gibt und es zu Ende kommt, kann ich mal kurz ankündigen,
was es um 11 Uhr gibt. Um 11 Uhr haben wir wieder zwei Events. Einerseits könnt ihr
in Livestream Raum 1 wechseln, wo Jörg Paul das darüber reden wird, wie man sehr,
sehr große Matomo-Instanzen, also wirklich aus der Sicht von Schweden,
schwedische Steuerbehörde oder solche, also wirklich Matomo-Instanzen, die viele Millionen
Seitenaufrufe im Monat bekommen, wie man das selberseitig trotzdem noch händeln kann,
dass man die Last schafft. Oder ihr wechselt zu dem interaktiven Workshop von Thomas Zeithammel
im Workshop Raum. Da geht es auf Deutsch weiter und ihr könnt darüber reden,
wie man Matomo richtig für Search Engine Optimization nutzt. Das wären jetzt um 11 Uhr
die zwei Möglichkeiten. Ansonsten, danke, Jachim, für den netten Vortrag.
Gerne. Und ja, noch viel Spaß bei Matologen.