Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Analytics / GA4

26.03.2022

Google Universal Analytics ist auf dem Rückzug und nun muss ein Ersatz gefunden werden. Für viele fällt die Wahl auf den "natürlichen Nachfolger" Google Analytics 4. Das ist oft keine schlechte Entscheidung aus funktionaler Sicht. Denn selbst wenn GA4 noch kein vollwertiger Ersatz ist, wird sich die Lücke noch schließen und nur wenige Alternativen werden vermutlich so nah an UA kommen wie GA4.

Trotzdem gibt es reichlich Gründe, auch andere Tools in Erwägung zu ziehen. Dabei geht es nicht nur um Datenschutz oder Bedenken, ob GA4 wirklich den eigenen Anforderungen rechtzeitig gerecht werden kann zum Ableben von Universal Analytics. Vielleicht ist GA nur deshalb im Einsatz, weil es ein sehr flexibles und leicht verfügbares Werkzeug zu der Zeit war, als eine Implementierung anstand. So wird Google Analytics auch da eingesetzt, wo andere (ggf. neuere) Speziallösungen viel passender wären. Der Markt ist vielfältig und alle Produkte haben Vor- und Nachteile, individuelle Eigen- und Besonderheiten. Jüngst wird mir häufiger die Frage gestellt, welches Tool sich als Ersatz anbietet. Meine unbefriedigende und in branchenübliche Antwort lautet dann "it depends". Klar. Aber wovon genau? Dieser Beitrag beleuchtet einige Fragen, die man sich vor einem Wechsel stellen sollte, damit die Wahl nicht nach kurzer Zeit bereut werden muss. Egal ob GA4 mit auf der Liste der Kandidaten steht oder nicht: dieser Schritt darf nicht übersprungen werden!

Toolwechsel = Projekt

Als jemand, der sich in der Vergangenheit eine ganze Zeit hauptsächlich mit Projektmanagement befasst hat, ist der Auswahlprozess aus meiner Sicht ein typisches Projekt. Und selbst in einer Zeit, in der agile Methoden Standard längst zum Standard geworden sind, muss zumindest zum Start ganz klassisch ein Gesamtüberblick über die Anforderungen hergestellt werden, bevor man mit den ersten Sprints anfangen kann. Agilität ist eher für die Implementierungsphase geeignet; Anforderungsmanagement betreibt man besser Old School im Wasserfall-Stil.

Zu groß ist sonst die Gefahr, erst mittendrin und in vollem Schwung von fehlenden Möglichkeiten der neuen Lösung ausgebremst zu werden, wenn späte Anforderungen eintrudeln. Deshalb ist die Basis für einen möglichst schmerzarmen Umstieg (Schmerzfreiheit ist nicht zu erwarten, Sorry) leider etwas zäh. Das widerspricht dem Drang, angesichts der wenigen zur Verfügung stehenden Zeit einen schnellen Wechsel zu vollziehen und verführt dazu, nach Abkürzungen zu suchen. Ich rate davon ab.

Wie starten?

Eine Sammlung von Anforderungen kann auf unterschiedliche Weise stattfinden. Die Komplexität hängt nicht zuletzt davon ab, wie viele Personen a) mit dem Tool selbst und b) den darüber generierten Daten arbeiten. Auch die verwendeten Schnittstellen sind wesentlich dafür, wie viel Kompromisse und Aufwand in der Implementierung einer alternativen Lösung stecken.

Kick Off: Rahmenbedingungen und "große Ziele" festlegen

Wer die Entscheidung allein treffen möchte, sollte auch allein mit den Daten arbeiten - und sich über die u. g. externen Faktoren soweit informieren (lassen), dass diese belastbar ist. In allen anderen Fällen gilt: Abstimmung ist angesagt. Als Kick Off empfiehlt sich daher ein (idealerweise moderierter) gemeinsamer Termin, in dem die ersten Anforderungen gesammelt und mit aktuellen externen Faktoren wie Browser-Trackingschutz, Consent etc. ergänzt mit einer noch großen Kandidatenliste abgeglichen werden. Das muss nicht in einem Rutsch perfekt sein oder viel Zeit in Anspruch nehmen, aber nur so kommen alle auf einen gemeinsamen Stand und können später Entscheidungen für oder gegen einzelne Lösungen nachvollziehen.

Bei größeren Nutzergruppen eine Balance zwischen der Anzahl der Teilnehmer und der Vielfalt der Nutzungskontexte zu finden, kann schon die erste Herausforderung darstellen. Stakeholder, IT, Marketing, Product Owner, Legal, Abteilungsleiter, "Power-User", Redakteure, BI.... da kann es schnell eng werden. Besser sind daher im Zweifelsfall mehrere Termine, in denen z. B. zunächst "nur" aus Anwendersicht auf die Anforderungen geschaut wird, dann die technischen Aspekte und schlussendlich evtl. Datenschutz und Recht im Fokus stehen. Auf der anderen Seite finden sich die Einzelkämpfer, welche ohne einen Prozess schnell Gefahr laufen, wesentliche Punkte zu vergessen, die nicht im Fokus der regelmäßigen Arbeit mit den Daten stehen. Oder das zurecht gefürchtete unbekannte Unbekannte. Daher ist eine Liste mit typischen Punkten ein guter Anfang - wenngleich diese für den individuellen Fall ggf. immer noch Lücken aufweist. Diese werden sich nur schließen, wenn in der Abstimmungsphase alle Eingaben ernst genommen werden.

Anforderungen sammeln

Die erste Zusammenstellung an Anforderungen kann dann entweder vergleichsweise einfach in einer Anforderungsliste, auf einem echten oder digitalen Whiteboard oder in Kollaborationstools erstellt (und priorisiert) werden. Die Form ist weniger wichtig als eine möglichst vollständige Liste an Kriterien, anhand derer die Kandidaten eingegrenzt und gerankt werden können. Sind mehr Personen beteiligt, als in einem Meeting realistisch Gelegenheit zum Feedback hatten, kann ein Mail-Review der ersten Ergebnisse sinnvoll sein. Anschließend lohnt es sich, die Liste durch einen größeren Kreis ergänzen zu lassen. Durch Wiederholung im kleineren Organisationseinheiten wie den einzelnen Abteilungen zum Beispiel.

Welcher Art die Anforderungen sind, hängt meistens von drei Faktoren ab:

  1. Wer analysiert welche "Analytics-Daten" genau - direkt in Analytics oder per Export bzw. Schnittstelle in anderen Lösungen oder für Dashboards etc.? Darin steckt auch, welche KPI ggf. aus den Webanalyse-Daten bedient oder komplett abgeleitet werden.
  2. Wo sind die Daten darüber hinaus relevant? Werden sie z. B. zur Budgetverteilung genutzt oder existiert ein Reporting für andere Abteilungen (Marketing, Sales...)?
  3. Werden Webanalyse-Daten isoliert genutzt oder in einem größeren Kontext (Data Warehouse, BI Tools etc.)?

Sind diese Fragen beantwortet, findet sich i. d. R. auch eine sinnvolle Zusammensetzung eines Teams zur Anforderungsanalyse - und die ersten Einträge auf der Anforderungsliste ebenfalls.

Datenschutz, sich laufend ändernde rechtliche Rahmenbedingungen, Wahl des Hostings, Redundanz und andere Faktoren mit Einfluss auf die Belastbarkeit der Wahl können weitere Maßnahmen wie z. B. eine Risikoanalyse erfordern. Zugegeben: Viel Arbeit, bevor man sich erste Gedanken über "GA4 oder nicht" machen kann. Ohne kommt aber zu schnell Murks am Ende raus.

Mögliche Fragen

Um sich ein Bild über den Umfang der eigenen Nutzung - sowohl aktuell als auch künftig geplant - zu machen, sind mehr Faktoren zu bedenken, als selbst erfahrenen Anwendern auf Anhieb einfallen. Die folgende Liste enthält einen Satz an verschiedenen Themen, die man entweder als Leitfaden für die Sammlung nutzt oder - eigentlich besser - dazu nutzt, um nach einer "freien" Sammlung zu kontrollieren, ob man nicht wichtige Punkte übergangen hat.

Soll in einem Kick-Off-Meeting die komplette Liste "abgearbeitet" werden, wird das möglicherweise schon am Umfang scheitern. Um dies zu verhindern, kann die Zusammenstellung schon im Vorfeld per Mail abgestimmt und von klar irrelevanten Punkten befreit (oder sogar schon um individuelle Eigenheiten ergänzt) werden. Als Kompromiss zwischen thematischer Überforderung und zu viel Schere im Kopf kann das Verteilen der Liste an die Teilnehmer erst kurz vor dem Termin erfolgen.

Die Kernfragen zur Erstellung jeder Anforderungsliste sind i. d. R. stets Variationen von:

  • Was nutze ich heute?
  • Was davon brauche ich unbedingt und was ist ggf. verzichtbar?
  • Was brauche ich (absehbar) darüber hinaus morgen?

Um darauf Antworten zu finden, können Eigenschaften und Aspekte im Zusammenhang mit einer Tracking-Lösung betrachtet werden. Nicht jedes Tool bildet diese gleich gut ab und manche auch gar nicht. Daher fallen reichlich Produkte durch Antworten auf die folgenden Fragen durch das Raster. Beim OMT gibt es bei Bedarf weitere Details von mir dazu, warum eine Alternative nicht immer eine Alternative ist.

Funktional / Daten

  • Ziele / Conversions (Anzahl, Komplexität der Definition etc.)
  • Segmente und Kohorten: Nach welchen Kriterien muss segmentiert werden können (und wo kann man sie nutzen)?
  • Kampagnentracking (Nutzung und Verfügbarkeit von Kanälen, UTMs, Quelle/Medium)
  • Evtl. Attributionsmodell (fix - welches oder wählbar)
  • Dimensionen + Metriken (Umfang und Abbildbarkeit)
  • Cookies & Consent / Umfang Tracking:
    • Cookieloses Tracking möglich?
    • Optionen für First Party Script Delivery & Tracking Endpunkt
    • "Enhanced / Auto Tracking" relevant?
    • Measurement ohne Zustimmung relevant?
    • Client- / Serverside?
  • Kontext:
    • Nur Web?
    • Apps?
    • Single-/Multi-Domain?
    • SPA Unterstützung / virtuelle Seitenaufrufe
  • Tag Management?
  • Zugriff auf Daten für verschiedene Nutzer / Abteilungen
    • Staging etc. nicht vergessen: Gibt es besondere Anforderungen an die Vermessung von Testsystemen o. Ä.?
  • E-Commerce + Checkout Funnel
    • Umfang Tracking
    • Produktauswertungen
    • Anreichern von Produktdimensionen
  • Schnittstellen
    • Google Ads u. a.
    • Google Data Studio oder Reporting Tools
    • BI
    • Genutzte Datenimport und -exportfunktionen (siehe unten)
  • Externe Nutzung, Zugriff oder Weitergabe der Daten
  • Welche Reports sind "zentral" wichtig?
  • UI Komplexität + Anforderungen
    • Wie einfach ist es zu bedienen ("geführte" Probeläufe können helfen)
    • Welche Analyse-Techniken im UI werden benötigt (Dyn. Funnels, Pathing etc.)?
    • Report-Filter
    • Nutzung Custom Reporting
    • Filter / Datenansichten: Welche und warum?
  • Verfügbarkeit von Daten
    • Echtzeit?
    • Reporting-Lag?
    • Geschwindigkeit beim Zugriff auf Daten im UI (auch mehr als nur ein paar Testdaten)?

Nicht-Funktional

  • Hosting (Self, On Demand, US / EU, Zertifizierungen, Green Energy)
  • Policy Stuff: SLAs etc.
  • Kosten (einmalig + laufend)
  • Komplexität und Aufwand für Setup
  • Wartung (Aufwand intern)
  • Möglichkeiten (und Bedarf) für Schulungen
  • Verfügbarkeit von Support

Liste in Zwischenablage kopieren

Problemfall Schnittstellen

Speziell die Punkte zu Schnittstellen und Datenexport erfordern oft ein wenig Vorarbeit. Während Details wie ein echter Event- und Tagging-Plan von der Wahl des Tools abhängt und daher auch später erstellt werden kann (schlussendlich unterscheiden sich die reinen "Fähigkeiten zur Messung" bei den einzelnen Kandidaten nur im Detail), ist es für einen Überblick der tatsächlichen Nutzung aller auf der Website erhobenen Daten prima, wenn es dazu ein Diagramm gibt. Oder eine Tabelle - die Form ist fast egal. Es sollte aber ein möglichst vollständiges Bild aller Datenempfänger existieren, inkl. der Wege, auf denen die Daten von der Website über die Webanalyse (oder auf anderem Weg) zu den Empfängern gelangen.

Auch der Weg, auf dem die Daten auf der Website erhoben werden, kann relevant sein. Ist GA derzeit z. B. nicht nur auf der Website direkt oder per Tag Manager integriert, sondern auch direkt im Code (z. B. in Form einer Property-ID, die in einem Backend, Third-Party Tool oder Plugin eingetragen wird) relevant, ist das auch bei einer Umstellung zu bedenken. Bezieht das Tracking ggf. aktuell Daten in einem "GA-freundlichen" Format über das System (in Form eines E-Commerce dataLayers zum Beispiel), sollte sich das irgendwo wiederfinden, denn spätestens beim Austausch muss eine neue Implementierung damit zurecht kommen.

Das Ergebnis - reduziert auf die Website Daten und ohne sonstige Datenlieferanten für ein Data Warehouse o. Ä. - muss nicht immer so aussehen...

Datenfluss als einfache Übersicht

... aber: endet das Diagramm bei der Benutzeroberfläche von Google Analytics? Dann unbedingt nochmal nachdenken und hinterfragen, ob es nicht doch noch Datenbanken, Reports oder Schnittstellen zu Backends, Landing Page Tools, Marketing Automation, integrierte Elemente auf der Website wie Chat-Tools o. Ä. gibt. Das ist eigentlich fast immer so.

Denkbare Kandidaten

Tools, welche sich nach einer Auflistung der wesentlichen Anforderungen (priorisiert und aufgeteilt in Klassen wie "unverzichtbar", "nice-to-have" o. a.) für eine Evaluierung empfehlen, haben dann üblicherweise eine überschaubare Anzahl. Oder es werden mehrere Tools für unterschiedliche Zwecke eingesetzt, denn nicht alle Alternativen zu Universal Analytics stammen aus der gleichen "Klasse" von Tools. Dass GA4 dabei eine Sonderstellung hat, ist unbestritten. Es ist deshalb aber nicht automatisch die richtige Wahl, denn GA4 ist ein vollkommen anderes Produkt im Vergleich zu Universal Analytics und weist reichlich Besonderheiten auf.

Von reinen Statistiktools über Alleskönner, Lösungen mit Marketing- oder Produktfokus, Plattformen für serverseitiges Tracking bis zu CDPs und Spezialisten für einzelne Kategorien wie E-Commerce gibt es eine Vielzahl von Anbietern und Produkten, wovon einige in mehrere Kategorien passen. Eine alles andere als vollständige Liste:

  • Einfachere und oft cookiefreie und ggf. ohne Consent zu betreibende Tools wie Plausible Analytics, Simple Analytics, Fathom, Trackboxx oder Digistats
    • oder "runter" bis auf einfache WordPress-Plugins wie Koko Analytics oder WP Statistics
  • Eher auf Marketing ausgerichtete Tools und "Vollblutlösungen" wie GA4, Matomo (wenngleich im Standard eher auf Reporting fokussiert), Piwik PRO, E-Tracker oder Adobe Analytics
  • Measurement mit Fokus auf Marketing Automation via Hubspot, Funnel.io, GetResponse u. a.
  • Amplitude, Mixpanel, Heap u. a. mit Schwerpunkt auf Product Analytics
  • "First Party" Tracking mit ssGTM, Snowplow, ggf. Elbwalker oder wiederum eine Nummer kleiner mit Matomo bzw. Open Webanalytics
  • CDPs wie Segment, Snowplow, Tealium, Piwik PRO und andere
  • Lösungen für Apps: GA4 / Firebase, Snowplow, Elbwalker, Piwik PRO, AppsFlyer & Co.
  • Kategorie "Irgendwas-Dazwischen"; z. B. Funnelytics
  • E-Commerce Spezialist Econda
  • Wenn sich Mut und Faulheit paaren: Oribi (ist allerdings aktuell auf dem Weg, ein LinkedIn Tool zu werden)

Abgesehen von den vielen zusätzlichen Optionen wie dem Speichern von eigenen Rohdaten in einem Data Warehouse, einer Datenbank auf eigener Infrastruktur oder in der Cloud, die oft parallel zum Universal Analytics Nachfolger eingerichtet werden (oder weiter betrieben) werden sollen, können dabei mehrere Tracking Tools für unterschiedliche Zwecke die richtige Antwort sein. Also nicht nur GA4 oder etwas anderes, sondern GA4 und andere Optionen. Matomo für möglichst umfangreiches "First Party Measurement" und Auswertungen auf der Matomo Datenbank. Oder Trackboxx als Self-Service Reporting Tool. Möglicherweise ist die "Flucht nach oben" der richtige Weg und man steigt um auf Adobe oder Google Analytics 360.

Möglicherweise war ein Webanalyse-Werkzeug für das eigene Online-Produkt viel schlechter geeignet, als es ein auf Product Analytics fokussiertes Tool wie Amplitude oder Mixpanel wäre. In einem solchen Fall können Lücken ggf. mit Spezial-Tools gefüllt werden. Mit großer Wahrscheinlichkeit wird eine neue Architektur zudem darauf basieren, dass ein Tool ein anderes mit Daten füttert. Oder via Edge- (z. B. Edgetag oder Zaraz) bzw. serverside Tagging (z. B. Serverside Google Tag Manager) mehrere Dienste versorgt werden. Weiterhin kann GA4 als Datenübergabe-Ziel einer CDP oder "Mittlerlösungen" wie Jentis angebunden werden.

(Unvollständige) Kandidatenliste

Je nachdem, in welche Richtung die Reise geht, will man sich ggf. von mehreren (meistens weniger verbreiteten) Optionen ein kurzes Bild machen. "Nach oben" findet man nicht nur, aber vor allem Adobe Analytics. Da eine Implementierung ohne entsprechende Unterstützung unsinnig ist, kann man sich hier zur Orientierung eigentlich nur zwischen ein paar Videos und dem Gang in den Sales Prozess machen. Auch Econda, reine App-Tools oder CDPs etc. habe ich aus gleichem Grund nicht in die Liste aufgenommen.

Wenn es um Lösungen mit serverseitigen Komponenten geht, ist ebenfalls meistens zumindest technische Unterstützung erforderlich. Die folgenden Produkte sind aber sowohl in Eigenregie anhand der Website, Demos und anderen Infos sowohl einschätzen als auch bei Bedarf einem Test unterziehen. Der Umfang mag dabei selten mit Google Analytics vergleichbar sein, aber alle bieten einen gemeinsamen Umfang von Kern-Reports für die Vermessung von Websites. Selbst die unten zu findenden, eher auf Produkt- statt Marketing-Analytics fokussierten Werkzeuge haben ihren Platz auf der Liste verdient; eignen sich aber sicher nicht für jeden Anwendungsfall.

Produkt Weitere Info Frei bis / Testdauer Preis / EUR
Webanalyse mit Marketing-Analytics Fokus
Piwik PRO YT Playlist mit Infos zu Produkt, Tag Manager + Setup bis 500.000 Hits auf Anfrage
Matomo Live Demo 21 Tage Test (Cloud) / unbegrenzt (On-Premise) 19,-- (Cloud) / 0,-- (On-Premise)
eTracker Kurztest im Video (ehem. kostenloser Plan) 0,-- nicht mehr verfügbar ab 9,--
Cookieloste Tools mit Website-Statistik / Reporting-Fokus
Trackboxx Kurztest im Video (frühe Version) bis 2.500 Aufrufe ab 5,--
Digistats Kurztest im Blog bis 500 Aufrufe ab 4,90
Pirsch Kurztest im Blog 30 Tage Test ab 5,-- ($)
Plausible Live Demo 30 Tage Test ab 9,--
Simple Analytics Live Demo 14 Tage Test ab 9,--
Fathom Live Demo 7 Tage Test 14,-- ($)
Visitor Analytics Kurztest im Blog bis 400 Aufrufe ab 12,99
Product-Analytics mit "Website-Eignung"
Heap Videos mit Demos bis 10.000 Sitzungen ab 300,--
Mixpanel --- bis 100.000 Besucher ab $25
Amplitude Demo (on-demand, gegen Mailadresse) bis 10.000 Events auf Anfrage

Welches Volumen erzeugt meine Website aktuell?

Ein nicht unwesentlicher Aspekt bei der Auswahl eines Nachfolgers ist das Volumen an Hits, Seitenaufrufen, Sitzungen... je nach Preismodell der Kandidaten. Für einen schnellen Überblick bietet sich neben dem Nachschlagen in Analytics über einen längeren Zeitraum z. B. ein Audit bei Analytrix an. Dort gehört das Volumen zu den Checks, so dass die Metriken für die letzten Monate direkt im Ergebnis abgelesen werden können.

Hit-Übersicht in Analytrix

Alternativ können Zahlen gezielt - auch für längere Zeiträume - über die API abgerufen werden. Der schnellste Weg führt über den Query Explorer für Universal Analytics. Dort kann nach Autorisierung und Auswahl der Datenansicht ein Report über Hits, Seitenaufrufe, Sitzungen und Nutzer nach Monaten erstellt werden.

Hit-Übersicht im Query Explorer

Und dann? Alles selbst testen?

Anforderungsmanagement allein liefert keinen Projektplan (oder füllt ein Kanban Board) und macht auch das vermutliche Ende bzw. den ggf. verfügbaren Puffer bis zum endgültigen Wegfall von Universal Analytics nicht unbedingt gleich absehbar. Aber von hier ab ist es möglich, alle Aufgaben sinnvoll unter den bestehenden Ressourcen zu verteilen und schnell in die Evaluierung zu gehen, damit danach die Implementierung und Tests einzelner Aspekte mit den eigenen Daten starten können. Dabei ist eine Menge Zeit zu sparen:

Fast immer kann man bei der Einschränkung der Liste auch ohne Installation und Test auf der eigenen Domain wichtige Antworten finden. Eine Demo, aufgezeichnete Workshops, Support-Dokumente und Communities können da helfen, wo das eigene (oder eingekaufte) Wissen nicht ausreicht. Die obige Liste enthält einige Links für einen ersten Einblick. Schlussendlich ist niemand Experte für alles und die Liste der Kernfragen zeigt, dass es sehr viele Aspekte gibt, die bei einer Auswahl berücksichtigt werden wollen.

Tipp: Vor allem, wenn es um Datenschutz geht, ist das Finden von Antworten teilweise nicht einfach. Beim PrivacyBoard wird eine Liste von Audit-Ergebnissen angeboten. In den Details finden sich Antworten auf alle Fragen rund um Datenschutz und eine Vergleichsfunktion.

Sind nur noch zwei oder drei konkurrierende Produkte im Rennen, muss irgendwann dennoch der Weg in das Tool gesucht werden. Testinstallationen, probeweise Anbindung von APIs etc. und ein Parallelbetrieb zum bestehenden Tracking sind schlichtweg unvermeidlich.

Den Faktor Mensch nicht unterschätzen

Bei aller Konzentration auf die Aufgabe, ein möglichst auf der funktionalen Ebene ebenbürtige Lösung zu finden, dürfen nicht-funktionale Aspekte nicht vergessen werden. Legal lassen wir hier heute mal unberücksichtigt und blicken auf Anwender. Denn: Das Bekannte ist der Feind des Neuen. Und Menschen sind träge. Beides zusammen sorgt stets für Widerstand gegen ein neues Tool. Im schlimmsten Fall findet das im Stillen statt. Obwohl das Beibehalten des alten Werkzeugs im Fall von Universal Analytics keine Option ist, sollte man früh für das neue Tool "interne Werbung" machen. Schulungsangebote sollten nicht begrenzt sein: Nicht nur beim Umstieg auf ein ganz anderes Tool, sondern auch bei GA4 als "natürlichen" Nachfolger wird man sich mit "Universal - Spezialwissen" allein nicht zurechtfinden. Frust ist daher vorprogrammiert und nicht jeder lernt auf die gleiche Weise gleich gut und gern. Ein gutes Konzept zur Einführung beinhaltet daher zwingend einen Mix an Self-Service Ressourcen, Schulungsangeboten, Workshops und ggf. Zertifizierungen.

Anleitungen dazu, wie bestimmte Dinge aus Universal Analytics im neuen Tool funktionieren, helfen u. U. enorm beim Umstieg. Botschafter für das Tool im eigenen Unternehmen, Workshops zum Kennenlernen des Tools anhand praxisbezogener Aufgaben, "Übersetzungslisten" für Namen ähnlicher Dinge, die in beiden Tools unterschiedlich sind - man kann eine ganze Menge unternehmen, um den Migrationsschmerz zu lindern. Auf jeden Fall ist die Einführung eines neuen Werkzeugs für die Digital-Analyse alles andere als ein rein technischer Vorgang. Wer auf dem Weg Begleitung und Beratung sucht: Hier geht es zu den Kontaktmöglichkeiten 😉

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2022 Markus Baersch