Inhaltsverzeichnis:

(Das Märchen von…) Die Sache mit der “Google Analytics Alternative”

(Das Märchen von…) Die Sache mit der “Google Analytics Alternative”

Lesezeit: 17 Min | Autor: Markus Baersch | 2 Kommentare

Teile den Artikel

Cookies, DSGVO, ePrivacy… alles Aspekte, unter denen potentielle, neue oder bereits bestehende Nutzer von Google Analytics nach Alternativen suchen. Neben den typischen alten und neuen Webanalyse-Lösungen tritt dabei seit ein paar Jahren verstärkt eine neue Klasse absichtlich datenreduzierter Tools an. Vielen gemeinsam ist die Positionierung als “Alternative zu Google Analytics”. In diversen Spielarten und mal mehr oder weniger offensiv in der Kommunikation. Was aber steckt im Detail dahinter? Für wen bzw. welchen Anwendungsfall eignen sich die jeweiligen Lösungen – und wo liegen Unterschiede und Grenzen? Ein Erklärungsversuch.

omt logo

Diesen Artikel jetzt als Podcast anhören

Jetzt anhören aut: Spotify | iTunes | Google Podcast

Vorbemerkung: Das hier ist kein “Tool-Bash”und auch kein Vergleich

Mir geht es explizit nicht darum, Google Analytics als allein heilbringende Lösung zu verteidigen oder die hier z. T. auch namentlich genannten anderen Tools schlecht zu machen bzw. generell zu kritisieren. Es geht ausschließlich darum, was es bedeutet, wenn sich andere Anbieter in der Vermarktung als Alternative zu Google Analytics platzieren und in welchem Umfang man als (angehender) Anwender von den Unterschieden a) profitieren und sich b) der Einschränkungen bewusst sein sollte.

Um es vorweg zu nehmen: Viele Anwender von Google Analytics brauchen (vermutlich / leider) tatsächlich nicht mehr als das, was diese oder jene selbstbenannte Alternative anbietet. Insofern hat jedes der Angebote seinen Platz und eine Daseinsberechtigung!

Ausgabe 3 jetzt verfügbar!!!
OMT Magazin - Ausgabe 3

Endlich online! Die 3. Ausgabe des OMT-Magazin. 228 Seiten geballtes Online Marketing-Wissen!

Jetzt kostenfrei downloaden

Wenn überhaupt, störe ich mich an dem Eindruck, den diese Positionierung erweckt: einen in allen Aspekten gleichwertigen Ersatz zu liefern. Ohne Kompromisse, ohne Einschränkungen, gern sogar überlegen. Das ist freilich nicht haltbar. Und damit meine ich nicht irgendwelche Nebenfunktionen, die nur für einen Bruchteil der Analytics-Anwender relevant ist, sondern oft (immer von den eigenen Anforderungen abhängige) handfeste KO-Kriterien. Daher sollte sich jeder, der vor einer Entscheidung steht, dieser Unterschiede bewusst sein. Genau das soll dieser Beitrag fördern.

Zweieinhalb Klassen von Alternativsystemen

Nicht alle Lösungen kann man einfach in einen Topf werfen. Daher möchte ich zumindest zwei unterschiedliche Typen von Tools unterscheiden – und von einer nur die Teilmenge betrachten, die an sich selbst den Anspruch definiert, eine Google-Analytics-Alternative zu sein.

Klasse 1: “Vollwertige” Webanalyse

Die erste Gruppe bilden “die Klassiker”. Schon immer gab es mehr als nur Google Analytics, wenn man vor der Toolauswahl für die Webanalyse stand. Das ist heute nicht anders. Einige sind vielleicht “kleiner” als (oder im Funktionsumfang vergleichbar) mit Google Analytics. Sie richten sich nicht zwingend an die gleiche Zielgruppe. So gibt es z. B. Econda mit Fokus auf E-Commerce, Mixpanel und Amplitude als Vertreter der “Product Analytics” Untergattung, Klassiker wie Mapp Intelligence (früher Webtrekk) und viele andere. Und natürlich gibt es auch “größere” Lösungen. Sei es “Stand-Alone” oder als Teil einer Suite wie im Fall von Adobe Analytics.

Klar: Alles, was irgendwie mit der Sammlung und Auswertung von Daten auf einer Website (oder in einer App) zu tun hat, ist in einem gewissen Umfang vergleichbar und daher potentiell eine Alternative. Der Markt ist groß, die Spielarten vielfältig (was auch gut so ist). Aus dieser Klasse positionieren sich einige offen als “Google Analytics Alternative”.

Sei es etracker,

etracker

Matomo

matomo oder Piwik PRO

piwikpro

… um die m. E. drei relevantesten / lautesten aus dieser Klasse zu nennen. Es gibt noch andere Vertreter wie Oribi, die sich in der Kommunikation gar als überlegen darstellen.

Oribi

Dieser Ausschnitt bildet die eine Seite der Waagschale. Ihnen sind bei allen vorhandenen Unterschieden einige Dinge gemein:

  • (optionale) Wiedererkennung von Besuchern über längere Zeiträume. Meistens cookie-basiert
  • Damit einhergehend Dinge wie Attributionsmodelle, besucherzentrierte Kennzahlen und Auswertungen; Blick auf die “Customer Journey / Lifetime Value” und andere
  • Verschiedene Event-Typen Messung von mehr als Seitenaufrufen (Dinge wie E-Commerce-Messung).
  • Unterstützung mehrerer eingehender Datenströme. Nicht nur Cross-Domain-Tracking, sondern auch Apps oder APIs zur Datenanlieferung
  • Zugang zu Rohdaten (aggregiert oder auf Event-Level) auf die eine oder andere Weise (API, Export, direkter Zugang zur Datenbank…)
  • Relativ viele Dimensionen, die im Standard erhoben werden (je nach Consent-Lage unterschiedlich zu gestalten); benutzerdefinierte Dimensionen und / oder Messwerte etc.
  • APIs und / oder Schnittstellen zu anderen Systemen – sei es zu Reporting-Zwecken oder zum Einsatz im Kontext von Targeting oder Werbeerfolgskontrolle

Erweiterte Funktionen zur Datenanalyse direkt im Tool:

  • wie selbstdefinierte Reports
  • Filterung und / oder Segmentierung von Daten
  • Drill-Down Funktionen in “lebenden” Reports

Nicht alle Aspekte sind bei allen Lösungen gleich ausgeprägt und jedes hat zudem ganz eigene Stärken, die in einem Vergleich den Ausschlag geben können. Wenn diese Stärken z. B. gerade das abdecken, was im konkreten Anforderungsprofil wichtig ist.

Außerdem sind nicht alle der oben genannten Punkte gleich wichtig für jeden Anwendungsfall. Insofern ist schon innerhalb dieser Gruppe eine Wahl als Einsteiger nicht einfach… und ein Umstieg von Google Analytics noch weniger. Um es noch komplexer zu machen, kommen wir zur zweiten Gruppe:

Klasse 2: Die “Datenschutzfokussierten”

Auf der anderen Seite des Spektrums stehen vor allem neuere Lösungen. Das liegt daran, dass seit der DSGVO – spätestens mit dem Aufstieg des Consent-Managements – ein begrüßenswerterweise verstärktes Bewusstsein für Datenschutz bei der Erhebung von Daten auf einer Website herrscht. Oder in Apps, die ich hier oft nur aus Platzgründen unter den Tisch fallen lasse. Passend zum Bedarf ist ein Markt entstanden für Lösungen, die dieser Entwicklung Rechnung tragen. Auch hier sei nochmal betont: Ich finde das sehr gut so!

Neben Simple Analytics, Fathom, Plausible ggf. sogar Cloudflare Analytics und anderen zähle ich beispielsweise Trackboxx als deutschen Anbieter in diese Kategorie.

plausible

Ähnlich wie die oben genannten “Vollblutlösungen” haben auch diese ihre Gemeinsamkeiten, wobei der funktionale Umfang im Detail in dieser Klasse natürlich variiert.

  • Cookiefreier Betrieb und damit einhergehend nur Kurzzeiterkennung von Besuchern. Oft basierend auf “ethischem Fingerprinting” mit einem alle 24 Stunden wechselnden Schlüssel
  • Reduzierter Dimensionsumfang bei Datensammlung und Auswertung
  • (nicht alle, aber viele) Hosting in der EU oder ggf. auf eigenen Servern
  • Fokus auf Dashboards und Reports auf “Übersichtslevel” (also weniger auf tatsächliche Analyse)

Spätestens jetzt sieht man, dass diese Vielfalt an Lösungen nicht in einen Sack passen kann. Dennoch passiert es immer wieder – vor allem bei der Positionierung als Alternative zu Google Analytics. Die Google-Analytics-Alternativliste bei Trackboxx ist dazu nur ein Beispiel.

Nachdem diese mühselige (und dennoch nur grobe) Einordnung der sich selbst als Alternativen positionierenden Kandidaten erfolgt ist, kann nun (endlich) das beleuchtet werden, was diese Unterschiede im Detail für einen Ein- oder Umsteiger bedeuten… und warum ich den obigen Titel für diesen Beitrag gewählt habe.

Konsequenzen funktionaler und konzeptioneller Unterschiede

Während der “Detailteufel” in der ersten Klasse vor allem in der Tiefe und Verfügbarkeit der jeweiligen Funktionen liegt, sind es vor allem prinzipielle Unterschiede aus der zweiten Klasse, die wesentliche Konsequenzen für die Nutzbarkeit der Daten haben.

Folgen der Kurzzeitidentität

Ein Kernvorteil, den die datenschutz-zentrierten Vertreter zu bieten haben, ist der Verzicht auf Cookies und die damit einhergehende längerfristige Wiedererkennung der Besucher. Während es technisch keine Herausforderung wäre, mit Fingerprinting auch eine längere Erkennungsphase zu nutzen, ist es hier der “privacy by design” – Ansatz, der dafür sorgt, dass man Besucher i. d. R. nach spätestens 24 Stunden nicht mehr wiedererkennen kann.

Da Fingerprinting auf Basis von IP-Adresse und User-Agent (und ggf. anderer Dimensionen, welche wie im Fall von Trackboxx vorbildlich dokumentiert sind) aber seine Grenzen hat, ist hier eines der Probleme die Auflösung, die im Vergleich zu Cookies grob bei “um die 80%” liegt. Was bedeutet, dass der Rest aus versehentlich in einen Topf geworfenen unterschiedlichen Besuchern besteht, die sich die IP teilen (je nach System wird vor der Bildung eines Hashes auch diese anonymisiert, was den Effekt vergrößert) und den gleichen User Agent (also den gleiche Browser und das gleiche Betriebssystem) nutzen.

Das ist nicht so dramatisch, wie es klingt. In der Praxis kann man damit zumeist gut leben. Zudem gibt es Spielarten, die aus Session-Cookies, Cookies mit kurzer Laufzeit von max. 30 Minuten (bei Piwik PRO zum Beispiel) oder alternativen “flüchtigen” Speichern im Browser wie sessionStorage bedienen. So oder so muss eine irgendwie geartete Klammer um einzelne Seitenaufrufe existieren, um einen Kontext wie “Besuch” oder “Besucher” herstellen zu können. Wer dazu mehr wissen möchte, findet dies im Beitrag zur Bedeutung der “Identität” in der Webanalyse und den Herausforderungen des Trackings ohne explizit eingeholten Consent.

Bei Wahl eines solchen Ansatzes sind die oben im Kontext der Wiedererkennung in Systemen der Klasse 1 genannten Punkte typischerweise nicht oder nur sehr eingeschränkt nutzbar. Das ist kein Fehler, sondern Teil des Konzepts. Die Folgen sind nicht für alle Anwender gleich relevant, aber vielfältig.

Attribution ist über den Besuch (oder einen Tag) hinaus nicht möglich. Wo Ziele und / oder Transaktionen betrachtet werden, sind diese ausschließlich der Quelle des Besuchs zuzuordnen, in dem das Ziel-Ereignis aufgetreten ist. Unter der Maßgabe, dass Webanalyse oft dazu dient, Kanäle und Marketingmaßnahmen zu bewerten – sei es isoliert, mit Blick auf mehr als nur eine Sitzung oder gar über mehrere Touchpoints hinweg -, ist das mehr als nur eine geringfügige Einschränkung. Es ist ein potentielles K.O-Kriterium für diese Kandidaten in vielen Einsatzszenarien; selbst wenn es “nur” um Dashboards und Reports geht.

Betrachtungen zum Besucher, die hierdurch wegfallen, sind neben der (Multi-) Kanal-Attribution weitere Funktionen, Messwerte und Dimensionen wie:

  • Customer Lifetime Value
  • Tage bis zum Kauf
  • Vorbereitende (Mikro-) Conversions
  • Neue vs. wiederkehrende Besucher
  • Bildung und Nutzung von Zielgruppen innerhalb und außerhalb der Webanalyse
  • Verknüpfbarkeit mit anderen Daten (zumindest ohne heimliche und nicht-konforme Hash-Tables auf dem eigenen Server)

Diese Liste ist nicht vollständig, zeigt aber deutlich auf, wo die Nutzbarkeit der gesammelten Daten endet, wenn man auf die Wiedererkennung von Besuchern weitestgehend verzichtet. Wobei diese Einschränkungen ebenso zum Tragen kommen, wenn man bei den Alternativen der Klasse 1 die jeweiligen Funktionen für den cookielosen Betrieb oder den Modus der eingeschränkten Datensammlung ohne Consent bei Piwik PRO nutzt – oder Google Analytics im “cookielosen” Betrieb.

Insofern ist diese Einschränkung nichts, was man einzelnen Tools “ankreiden” müsste. Es ist die Folge einer bewussten (Produkt- oder Setup) Entscheidung, wie Tracking stattzufinden hat. Sei es aus Überzeugung des Anbieters oder weil es ohne Zustimmung gerade nicht anders geht.

Folgen dieses Ansatzes reichen noch weiter. Typische Differenzen zwischen in den Tools gleich genannten Dingen werden dadurch zum Beispiel wahrscheinlicher. Während zwei Systeme schon immer unterschiedlich eine Sitzung oder einen Besucher definiert und identifiziert haben, kommt nun hinzu, dass ein Besucher in einem System morgen wiedererkannt wird und im anderen evtl. nicht mehr. Weisen Tools mit maximal 24 Stunden Wiedererkennung eine Anzahl der Besucher aus, statt konsequenterweise von Sitzungen oder Besuchen zu reden, wird dies problematisch, wo Auswertungen mehr als einen Tag umfassen.

Erkennt Tool A einen Besucher morgen und übermorgen noch wieder (mit allen Einschränkungen, die ITP und Trackingschutz für cookiebasierte Systeme bedeuten), sind es mehrere Besucher in System B, wenn dieses mit Kurzzeiterkennung arbeitet. Während die Zahl in System A also nur deshalb nicht hart belastbar ist, weil Tracking nie perfekt ist, steckt in System B durch geringe Auflösung und fehlende Wiedererkennung schon eine gute Portion hausgemachter “Falschinformation”. Leider gehen einige Tools eher flapsig damit um, was wie genau benannt wird.

Folgen von Dimensionsarmut

Auf gleiche Weise wird die Eignung von Lösungen für bestimmte Aufgaben dadurch bestimmt, welche Daten gesammelt werden. Legt ein Tool den Datenschutz nicht nur optional, sondern unveränderlich für alle Besucher stets in den Vordergrund (ohne dass dies durch das Einholen von Consent geändert werden kann), muss man in der Auswertung mit einem reduzierten Satz von Angaben zu Besuch und Besucher leben. Das kann z. B. bedeuten, dass Herkunft und Standort des Besuchers unbekannt bleiben. Ist das immer gleich relevant? Nein. Aber es ist nur ein Beispiel.

Andere:

  • System, Browser, Versionen: Ohne User Agent nicht vorhanden. Bei aller Unsicherheit in der Auflösung ist das nicht für jeden Zweck vollkommen irrelevant
  • Benutzerdefinierte Dimensionen: Sind in Analytics und Systemen der Klasse 1 oft möglich, bei Klasse 2 i. d. R. nicht. Diese sind für viele Implementierungen ein wesentlicher Bestandteil und Hilfe zur Beantwortung bestimmter Fragen

Fähigkeit zur Beantwortung konkreter Fragen

Webanalyse ist nicht ganz von allein nützlich” ist ein in verschiedenen Varianten viel zitierter Satz. Datensammlung als Basis von Reporting ist nicht das Ende der Fahnenstange, wenn es um das Einsatzspektrum von Webanalyse geht. Sie sollte Fragen nicht nur aufwerfen, sondern ebenso beantworten können. Aus Antworten sollen Einsichten, aus Einsichten Veränderungen und daraus idealerweise wiederum Verbesserungen entstehen.

Während in allen Tools auf die eine oder andere Weise Daten in Dashboards und vordefinierten Reports betrachtet werden können, sind Funktionen zur Auswertung der Daten wesentlich, wenn es um konkrete Fragestellungen geht.

Diese müssen nicht komplex sein. So kann man z. B. in Trackboxx-Reports durch einen Klick auf eine Seite z. B. sehen, aus welchen Quellen die Besucher dieser Seite stammen. Will man aber für eine Quelle sehen, auf welchen Seiten diese Besucher eingestiegen sind, ist eine Antwort per Klick nicht verfügbar.

Daher sollte man sich darüber im Klaren sein, dass zwar nicht alle Tools der Klasse 2 reine “Dashboard-Tools” sind… hier aber die Eintauchtiefe in die Daten nicht nur durch die geringe Anzahl an Dimensionen begrenzt ist, sondern mitunter auch durch die verfügbaren Analyse-Funktionen.

Bietet eine Lösung gewisse Drill-Down Möglichkeiten per Klick auf einen Eintrag an, muss das nicht bedeuten, dass damit alle typischen Fragen zu beantworten sind. Direkt in der Oberfläche eines Tools sind es oft Mittel wie sekundäre Dimensionen, Listen-Filter und Segmente, die auf dem Weg zu einer Antwort nötig sind oder zur detaillierten Verhaltensanalyse von bestimmten Ziel- oder Verhaltensgruppen der Websitebesucher; wo gern selbst definierte Berichte eine Rolle spielen.

Spätestens dann, wenn die Oberfläche eines Tools nicht ausreicht, ist das Thema “Analyse” daher an anderer Stelle durch- oder fortzuführen. Ist dies für einen Anwendungsfall relevant, disqualifiziert das alle Kandidaten, die ohne Schnittstellen oder brauchbaren Datenexport eher isolierte Datensilos darstellen.

Was einen weiteren Aspekt aufwirft:

Einsatz im Verbund mit anderen Systemen

Schnittstellen sind generell ein wesentlicher Punkt, wenn mehr als nur das Verhalten auf der Website messbar gemacht werden soll. APIs, die dazu dienen, Daten in das System zu bekommen auf der einen Seite; Exportfunktionen und die Fähigkeit automatisierter Anbindung auf der anderen Seite, fehlen typischerweise bei Lösungen der Klasse 2.

  • Sollen Daten automatisch in Excel, Google Sheets, Google Data Studio, Tableau genutzt werden?
  • Oder in Python, R oder sonstwo weiterverarbeitet werden?
  • Als Basis von Vorhersagemodellen dienen?
  • Was ist mit der Bildung von Zielgruppen für Werbemaßnahmen?
  • Tracking von Conversions für Google Ads?
  • sonstige Nutzung der erhobenen Daten jenseits der bestehenden Reports und Dashboards?

Dann sind diese Anforderungen mit den Möglichkeiten einer in Frage kommenden Alternativen abzugleichen. Nicht alle Kandidaten fallen dabei unbedingt durch. Und noch häufiger wird Google Analytics selbst dann eingesetzt, wenn diese Punkte gar keine Relevanz haben. Und ja: genau dann sind die meisten sich selbst anbietenden Alternativen ohne große Einbußen nutzbar. Das ist aber nicht die Regel.

Versteht und nutzt man Google Analytics als Teil eines vor allem auf das “Google Universum” ausgerichteten Systems; eingebettet in eine komplexere Marketingstrategie, kann man es unmöglich einfach ersetzen. Jenseits der isolierten Rolle als “Websitebesuchermonitor” oder noch dramatischer ausgedrückt “bessere Logfileanalyse” ist Google Analytics schlichtweg so tatsächlich oft alternativlos. Wer es zynisch mag, wird den Titel des LinkedIn-Beitrags von Siegfried Stepke in diesem Zusammenhang zu schätzen wissen.

Von Teufeln, die in Details stecken

Sind all diese Punkte berücksichtigt, kommen zum Unglück noch weitere Unterschiede hinzu, die selbst bei “Featuregleichheit” nicht bedeuten, dass man in einem Alternativsystem das tun kann, was man vielleicht gerade in Analytics nutzt.

Ein Beispiel sind Ziele. Gibt es diese im potentiellen Ersatz überhaupt? Und wenn ja, wie werden sie erreicht? In manchen Systemen muss man ein Ziel explizit durch spezielle Events melden, in anderen sind diese nur auf Basis von Seitenaufrufen zu definieren; im dritten noch viel flexibler als in Google Universal Analytics (wie z. B. sitzungsübergreifend, was in Google Analytics erst seit GA4 denkbar ist).

Ebenso teilweise gar nicht (oder sehr unterschiedlich) gelöst sind Filter für Standardaufgaben wie den Ausschluss interner Besucher, Trennung von Produktions- und Live-Webseite oder Spam durch rendernde Bots.

Selbst das von vielen Alternativen angeführte “No-Consent Argument” kann schnell hinfällig sein. Was den Vorteil nicht verringert, der darin liegt, dieses oder jenes System ohne explizite Zustimmung des Besuchers einsetzen zu können. Was diese Lösungen z. B. als Ersatz- oder Parallelsysteme zu Analytics für den Fall fehlender Zustimmung perfekt qualifiziert.

Wenn wirklich nur diese Daten benötigt werden, ist ein Verzicht auf störende Cookie-Abfragen auf diesem Weg ein echter Vorteil. Besteht Tracking aber aus mehr als Google Analytics und will man bei Zustimmung weitere Tags von Google Ads, Bing Ads, Facebook, Pinterest und anderen ausspielen, kommt man am Consent Dialog nicht vorbei. Schön ist es dann, wenn die Webanalyse diesen Vorteil auch nutzen kann. Speziell Tools aus Klasse 2 bieten aber keine zwei Modi zur Datensammlung, denn dazu sind sie nicht konzipiert.

Fazit: das “Alternativ-Argument” ist weder haltbar noch notwendig

Nicht nur die Länge, sondern (hoffentlich) die zahlreichen, angesprochenen Aspekte zeigen deutlich, wie unglücklich es sein kann, wenn man sich als Alternative zu Google Analytics positioniert. Weder ist es bis auf die letzte funktionale Detailebene haltbar, noch tut man sich einen Gefallen, wenn man damit versucht, Anwender von Google Analytics auf die eigene Lösung zu ziehen. Herrgott, nicht mal Google Analytics (4) ist eine vollwertige Alternative zu Google Analytics (Universal), jedenfalls nach aktuellem Stand! Zu groß ist (noch) die Liste der Dinge, die in der neuen Version erst kommen müssen, um in komplexeren Szenarien von der alten auf die neue Fassung umzusteigen.

Was richtig ist: Google Analytics wird heute von vielen Anwendern hauptsächlich deshalb auf der eigenen Webseite verwendet, weil es einfach verfügbar und leicht einzubinden ist.  Im schlimmsten Fall werden die Daten nicht einmal oder nur in Form von Reports zur Befriedigung “unspezifischer” Neugier genutzt. Dann allerdings ist ein Ausbau und Verzicht die eigentlich richtige Handlung und der Wechsel auf ein kostenpflichtiges Tool eher unwahrscheinlich. Sollte sich das Marketing der Alternativanbieter auf diese Gruppe konzentrieren, darf die Lösung (bis zu einem gewissen Umfang zumindest) nichts kosten und muss mit vertretbarem Aufwand zu implementieren sein.

Bestehen eher einfache und auf die Website bzw. das Messobjekt beschränkte Reportinganforderungen, mag die Rechnung aufgehen. Liegt man mit der eigenen Lösung an für den konkreten Einsatz wesentlichen Punkten hinter Google Analytics zurück, erhält man aber keine zufriedenen Kunden durch Abwerben.

Es sollte daher besser sein, die Unterschiede selbst klar zu benennen, einzuordnen und die eigenen Vorteile in den Vordergrund zu stellen. Jedes System hat Stärken, Alleinstellungsmerkmale und/oder konzeptionelle Unterschiede zu Google Analytics. “Nicht Google Analytics” und zugleich “genau so gut” zu sein, halte ich deshalb nicht für ein gutes Verkaufsargument… es ist in gewisser Weise unlogisch.

Wer auf der Suche nach einer passenden Lösung als Ergänzung oder eben “Alternative” ist, wird sich trotz aller Marketingaussagen leider den Schritt der Definition der eigenen Anforderungen nicht sparen können. Die meisten Tools bieten zum Glück auf die eine oder andere Weise Möglichkeiten zur Erprobung in Form von Testzeiträumen oder offen zugänglichen Demo-Accounts, anhand derer man sich ein Bild davon machen kann, wie gut sich die eigenen Anforderungen mit den Fähigkeiten des jeweiligen Analyse/Reporting-Tools decken.

Teile den Artikel
Wie ist Deine Meinung zu dem Thema? Wir freuen uns über Deinen Kommentar