Meine App hatte Besucher. Niemand konvertierte. Kostenlose KI-Analytics fand in 3 Tagen heraus warum.
Du hast Traffic. Nutzer klicken durch, landen in der App, 62% schaffen es über die Eingangsschwelle. Und dann konvertiert nichts. Die Nutzer springen irgendwo zwischen Einstieg und Aktion ab, und du hast keine Ahnung wo.
Ein Indie Hackers-Gründer brachte es letzten Monat auf den Punkt: Wenn du deine Baseline-Conversion-Rate nicht kennst, kannst du nicht messen, ob deine Änderungen überhaupt funktioniert haben. Das ist der Teil, den keiner laut ausspricht. Du hast den Traffic. Du hast den Drop-off. Dazwischen: eine Black Box.
Ich hätte die Texte umschreiben, die Button-Farben ändern, das Onboarding aus dem Bauch heraus komplett neu aufbauen können (sprich: reines Raten). Stattdessen installierte ich Microsoft Clarity, ein kostenloses Tool ohne Session-Limit, und verbrachte 3 Tage damit zu beobachten, was meine Nutzer tatsächlich in der App machten. Nicht was ich annahm, dass sie taten. Was sie tatsächlich taten.
Das Ergebnis: 20% der Sessions hatten Dead Clicks. Nutzer tippten auf ein dekoratives Element, das interaktiv aussah, kamen nirgendwo hin und verließen die App. Obendrein ein struktureller Fehler, den Clarity allein nicht sehen konnte: meine App war eine SPA mit einer einzigen URL für jeden Screen. Die Heatmaps waren seit dem Launch-Tag blind gewesen.
Warum Clarity und nicht die kostenpflichtigen Tools
Hotjar steht auf jeder SaaS-Tools-Liste ganz oben. Kostet aber auch 39$/Monat für 500 Sessions, mit Recordings hinter höheren Tarifen versteckt. In der Pre-PMF-Phase zahlst du keine 39$/Monat, um herauszufinden, dass deine Button-Labels verwirrend sind. Das Tool, das du tatsächlich einrichtest, ist das, was nichts kostet.
Clarity hat kein Session-Limit. Session Recordings, Heatmaps, Scroll Maps, Click Maps und Core Web Vitals Performance Scoring – alles kostenlos. 1 Script-Tag in deinen <head>, du sammelst echte Daten in 10 Minuten. Das Signal-zu-Aufwand-Verhältnis schlägt jede kostenpflichtige Alternative vor Product-Market Fit.
Clarity erkennt auch Frustrationssignale automatisch: Rage Clicks (Nutzer tippen 3 oder mehr Mal auf dieselbe Stelle), Dead Clicks, exzessives Scrollen und Quick-Backs werden alle markiert, ohne manuelle Event-Konfiguration. Du musst nicht wissen, wonach du suchst. Das Tool sagt dir, welche Sessions es wert sind, angeschaut zu werden.
Falls du in der Phase bist, wo gerade etwas gelauncht wurde und du nicht verstehst, warum der Checkout-Flow nicht konvertiert, behandelt Vibe Coding, For Real die komplette Stack-Entscheidung, bevor du überhaupt zu Analytics kommst. Kostenlos mit Kindle Unlimited, gemacht für Builder, die genau an dieser Wand stehen.
Der Trade-off: Daten liegen auf Azure. Compliance-lastiger Stack? Du weißt, was zu tun ist. Für ein Standard-WooCommerce-basiertes Tool oder frühe SaaS ohne spezifische Datenspeicherungsanforderungen ist es kein echtes Problem.
3 Tools für 3 Jobs
Das Prinzip, bevor du etwas anfasst: Der Konsument der Daten bestimmt das richtige Tool.
Wenn du manuell untersuchst, ist das Dashboard deine einzige Option. Es ist der einzige Ort, wo Session Recordings und Heatmaps existieren. Kein API-Endpoint, kein MCP-Server gibt dir ein Video eines echten Nutzers, der durch deine App navigiert. Wenn du zuschauen musst, öffnest du den Browser.
Wenn du automatisieren musst, triff die REST API direkt. Aggregierte Metriken via GET-Request, gepusht in lokalen Storage, verarbeitet von deinem eigenen Code. Kein Zwischenhändler, kein Gesprächs-Overhead.
MCP plus Claude ist für konversationelle Abfragen. Frag in normalem Deutsch, bekomm strukturierte Analyse zurück. Dieselben zugrundeliegenden Daten wie die REST API, mit identischen Limits. Das Interface ist das Upgrade, nicht die Daten.
Modus 1: Dead Clicks und die SPA-Falle
Im ersten Batch Clarity-Daten: 20% der Sessions mit Dead Clicks, Performance Score 91/100, 0 JS-Fehler, und Scroll Depth bei 86%, was bedeutet, dass Nutzer über den Fold hinaus lasen. Und trotzdem konvertierte nichts.
Die Disziplin, die veränderte, wie ich Clarity lese: Das Dashboard sagt dir das WAS. Zum WARUM zu kommen bedeutet, in den Code zu graben.
Erste Hypothese war Routing. Ein kaputter Nav-State, der Nutzer nach einer Aktion auf den falschen Screen schickt. Ich zog 30 Session Recordings und schaute sie hintereinander. Dasselbe Element, dieselbe Stelle, Session nach Session. Nutzer tippten darauf. Nichts passierte. Sie versuchten es nochmal. Gingen weg.
(YOU DIED. Todesursache: ein div mit Hover-State und ohne Click-Handler.)
Stellte sich heraus, das Element war dekorativ. Ein gestyltes div, das interaktiv aussah, einen Hover-State hatte, den ich aus Gewohnheit während des Builds hinzugefügt hatte, und mit absolut nichts verbunden war. 1 von 5 Nutzern klickte auf eine Wand. Ich hatte es so deployed und nie bemerkt. (Ich hab Schlimmeres deployed. Das hier ist ein Safe Space.)
Fix: ersetzte das div mit einem Button, der zur primären Conversion-Aktion verdrahtet war. Dead Click Rate sank im nächsten Beobachtungs-Batch.
Mein Kind kam rein, während ich Session 22 schaute und fragte, warum ich ein Video von jemandem schaue, der auf einen Bildschirm starrt und nichts tut. Konnte es nicht wirklich erklären. "Arbeit" deckt anscheinend viel Terrain ab 😅
Dann kam das tiefere Problem zum Vorschein.
Das ist es wert, dabei zu verweilen, weil es verändert, wie du jede Heatmap liest, die du je angeschaut hast. Clarity organisiert alle visuellen Daten nach URL. Jede Click Map, jede Scroll Map, jede Heatmap ist auf einen spezifischen URL-Pfad begrenzt. Für eine traditionelle Multi-Page-App funktioniert diese Struktur gut. Für eine SPA, die 7 verschiedene Screens unter einer einzigen /app-URL rendert, bedeutet es, dass jede Interaktion über jeden Screen in 1 nutzlosen Blob aggregiert wird. Ein Dead Click auf dem Produktlisting-Screen sieht identisch aus wie ein Dead Click auf der Checkout-Bestätigung, weil sie aus Claritys Sicht auf derselben Seite passierten. Ich hatte dieses Setup monatelang laufen, schaute aggregierte Heatmaps, zog Schlüsse über Nutzerverhalten, traf Design-Entscheidungen basierend auf diesen Daten, und jeder Datenpunkt war kontaminiert. Das strukturelle Missverhältnis zwischen wie Analytics-Tools Seiten modellieren und wie SPAs tatsächlich funktionieren ist kein Clarity-Bug. Es ist ein Missverhältnis, das du nicht bemerkst, bis du bereits das falsche mentale Modell deiner Nutzer aufgebaut hast.
Analytics-Tools sind um Seiten-URLs herum gebaut. Eine SPA, die ihre URL nie ändert, gibt ihnen nichts, womit sie arbeiten können.
Deine Heatmaps haben seit dem Launch-Tag gelogen.
Fix: Hash Routing. /app/#product-listing, /app/#checkout, /app/#confirmation. Jeder Screen bekommt eine adressierbare URL. Dann Event-Tagging pro Screen via clarity('set', 'screen', slug), damit Sessions sauber im Dashboard segmentiert werden.
// Feuert ab, wann immer sich der aktive Screen ändert
router.on('routechange', (screenSlug) => {
clarity('set', 'screen', screenSlug);
});1 adressierbare URL pro Screen ist auch ein Marketing-Asset. Du kannst jetzt eine bezahlte Kampagne direkt auf /app/#checkout zeigen lassen, anstatt allen Traffic vor die Haustür zu kippen und zu hoffen, dass der Onboarding-Flow die Lücke schließt.
Modus 2: Die API und ihre harten Limits
Sobald du Metrik-Pulls automatisieren willst, überspring das Dashboard. Triff die Clarity Data Export API am project-live-insights-Endpoint. Auth via Token: Settings, Data Export, Generate Token.
3 Limits, die du kennen musst, bevor du eine einzige Zeile schreibst:
Die API begrenzt auf 10 Requests pro Tag, keine Burst-Allowance, kein Override. (Denk daran wie an eine Mana-Bar, die um Mitternacht zurücksetzt. Verbrenn sie nicht für Test-Calls.) Ein Cron Job, der jede Stunde läuft, wird bis zum Morgen versagen. Design deinen Polling-Schedule von Anfang an um diese Beschränkung herum.
Jeder Request deckt höchstens 3 Tage Historie ab. Keine rollende 30-Tage-Ansicht, kein Trend-Vergleich in einem einzigen Call. Bau deinen eigenen Storage-Layer, akkumuliere täglich, dedupliziere nach Datum. Nach 30 Tagen hast du einen rollenden Monat. Nach 90 Tagen siehst du Saisonalitätssignale, auf die es sich zu reagieren lohnt.
Jeder Request akzeptiert maximal 3 Dimensionen gleichzeitig. Device, Country und Screen in einem Call: das sind deine 3. Füg eine 4. hinzu und der Request schlägt fehl. Mehr Segmentierung bedeutet mehr Calls und schnelleren Quota-Verbrauch.
import requests
token = "your_clarity_project_token"
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(
"https://www.clarity.ms/export-data/api/v1/project-live-insights",
headers=headers,
params={
"startDate": "2026-06-11",
"endDate": "2026-06-14",
"dimensions": "device,country,url"
}
)
data = response.json()Was die REST API dir nicht gibt: Recordings, Heatmaps oder Session-Level-Details. Nur Aggregate. Individuelles Nutzerverhalten bleibt Modus-1-Territorium.
Falls du mehrere Apps betreibst und diese Daten in etwas Breiteres einfließen lassen willst, ist ein Claude-powered SaaS Monitoring Setup eine natürliche Erweiterung. Kein Clarity-spezifisches Pattern, aber es schließt die "brennt etwas"-Frage über dein ganzes Portfolio, ohne 5 Dashboards zu checken.
Modus 3: Claude und MCP
Das @microsoft/clarity-mcp-server-Package auf npm (offiziell Microsoft) verdrahtet Claude in dieselbe API, die du in Modus 2 triffst. Der Unterschied ist das Interface.
npx @microsoft/clarity-mcp-server --token your_clarity_tokenMit dem MCP in Claude verbunden, fragst du auf Deutsch:
"Welche Screens haben die höchste Dead Click Rate in den letzten 3 Tagen? Vergleiche Mobile vs Desktop."
"Was machten Nutzer unmittelbar bevor sie den Checkout-Screen erreichten, ohne einen Kauf abzuschließen?"
Claude liefert strukturierte Analyse. Muster, die eine Stunde manueller Session-Review brauchen würden, werden in unter einer Minute aufgedeckt. Eine Nachfrage zu stellen ist sofort. Hier verdient sich MCP seinen Platz: schnelle Iteration bei Untersuchungshypothesen, nicht Batch-Automatisierung.
Was MCP von der API erbt: jedes Limit, exakt. Dieselben 10 Requests pro Tag, 3 Tage Historie und 3 Dimensionen pro Request max gelten hier genauso wie beim rohen REST-Call. Der MCP-Server ist ein Transport-Adapter, kein Daten-Layer. Er übersetzt Claudes konversationelle Eingabe in REST-Calls und formatiert die Antworten zurück. Er schaltet keine Daten frei, die die API nicht bereits freilegt. Geh rein und erwarte ein besseres Untersuchungs-Interface für dieselben Daten, keine Superkraft.
Der Modus, der mich überraschte, war nicht die Geschwindigkeit einzelner Antworten, sondern die Multi-Variable-Vergleiche. Ich fragte Claude, Conversion-Signale zwischen Sessions mit Dead Clicks und Sessions ohne zu vergleichen. Dieser Cross-Slice erfordert 3 separate API-Calls mit verschiedenen Dimensions-Kombinationen, Quota-Math obendrauf und manuelles Mergen der Antworten. Das MCP handhabte alles davon in 1 Turn. Ich schrieb 0 Zeilen Code und bekam einen sauberen Vergleich in unter einer Minute.
Ich denke, MCP funktioniert am besten als Untersuchungs-Sprint-Tool: verbrenn die 10 täglichen Requests für gezieltes Hypothesen-Testen, dann wechsel zu einem Script für alles Wiederholbare. Könnte sein, dass ich das falsch lese, aber diese Aufteilung war bisher sauber.
Erwähnenswert: Sobald das MCP 10 Requests erreicht hat, ist es fertig. Keine Queue, kein Retry. Plan deine Fragen vor dem Öffnen der Session, nicht währenddessen. Explorative Fragen verbrennen Quota schnell.
Für alles, was nach Zeitplan läuft, schlägt eine zweckgebaute CLI MCP für Produktionsautomatisierung: kein tägliches Cap, keine Claude-Session erforderlich, läuft in einem Cron ohne Overhead. Nutze MCP für Untersuchung, CLI für die geplanten Sachen. Sie decken verschiedene Teile des Jobs ab.
Dead Clicks: 20% der Sessions am Anfang, Ziel unter 5%. Fix deployed, messe. Hash Routing live, Heatmaps sauber pro Screen. Event-Tagging nach Screen aktiv.
3 Tage und 1 kostenloses Tool. Diese URL hätte vom Launch an da sein sollen 🤦♂️
Quellen
- Microsoft Clarity — Session Recording, Heatmaps, Core Web Vitals, kostenlos
- @microsoft/clarity-mcp-server — npm, Microsoft offiziell
- Clarity Data Export API — Endpoint-Dokumentation, Rate Limits
Dieser Post könnte Affiliate-Links enthalten. Falls du sie klickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern).