My App Had Visitors. Nobody Converted. Free AI Analytics Found Exactly Why in 3 Days.
What 30 Real Sessions and a Free Analytics Tool Found That Months of Guessing Missed.
You have traffic. Users are clicking through, entering the app, 62% of them make it past the front door. And then nothing converts. Users drop off somewhere between entry and action, and you have no idea where.
One Indie Hackers founder put it plainly last month: not knowing your baseline conversion rate means you can't measure whether any of your changes actually worked. That's the part nobody says out loud. You have the traffic. You have the drop-off. Between the two: a black box.
I could have rewritten the copy, changed the button colors, rebuilt the onboarding from scratch on instinct (read: pure guessing). Instead I installed Microsoft Clarity, a free tool with no session cap, and spent 3 days watching what my users actually did in the app. Not what I assumed they did. What they actually did.
The result: 20% of sessions had dead clicks. Users were tapping on a decorative element that looked interactive, going nowhere, and leaving. On top of that, a structural flaw Clarity couldn't see on its own: my app was a SPA with a single URL for every screen. The heatmaps had been blind since the day I launched.
Why Clarity and Not the Paid Ones
Hotjar is the default on every SaaS tools list. It's also $39/month for 500 sessions, with recordings gated behind higher tiers. At pre-PMF stage, you're not paying $39/month to discover that your button labels are confusing. The tool you'll actually set up is the one that costs nothing.
Clarity has no session cap. Session recordings, heatmaps, scroll maps, click maps, and Core Web Vitals performance scoring all come free. 1 script tag in your <head>, you're collecting real data in 10 minutes. The signal-to-effort ratio beats every paid alternative before product-market fit.
Clarity also surfaces frustration signals automatically: rage clicks (users tapping the same spot 3 or more times), dead clicks, excessive scrolling, and quick-backs are all flagged without manual event configuration. You don't need to know what you're looking for. The tool tells you which sessions are worth watching.
If you're at the stage where something just shipped and you can't figure out why the checkout flow isn't converting, Vibe Coding, For Real covers the full stack decision before you even get to analytics. Free on Kindle Unlimited, built for builders who've hit exactly this wall.
The trade-off: data lives on Azure. Compliance-heavy stack? You know what to do. For a standard WooCommerce-based tool or early SaaS with no specific data retention requirements, it's not a real concern.
3 Tools for 3 Jobs
The principle before touching anything: the consumer of the data determines the right tool.
If you're investigating manually, the dashboard is your only option. It's the only place where session recordings and heatmaps exist. No API endpoint, no MCP server gives you video of a real user navigating your app. If you need to watch, you open the browser.
When you need to automate, hit the REST API directly. Aggregate metrics via GET request, pushed to local storage, processed by your own code. No intermediary, no conversational overhead.
MCP plus Claude is for conversational querying. Ask in plain English, get structured analysis back. Same underlying data as the REST API, with identical limits. The interface is the upgrade, not the data.
Mode 1: Dead Clicks and the SPA Trap
In the first batch of Clarity data: 20% of sessions with dead clicks, performance score 91/100, 0 JS errors, and scroll depth at 86% meaning users were reading past the fold. And still nothing converted.
The discipline that changed how I read Clarity: the dashboard tells you the WHAT. Getting to the WHY means digging into the code.
First hypothesis was routing. A broken nav state sending users to the wrong screen after an action. I pulled up 30 session recordings and watched back to back. Same element, same spot, session after session. Users tapped it. Nothing happened. They tried again. Left.
(YOU DIED. Cause of death: a div with hover state and no click handler.)
Turned out the element was decorative. A styled div that looked interactive, had a hover state I'd added out of habit during the build, and was connected to absolutely nothing. 1 in 5 users was clicking on a wall. I'd shipped it that way and never noticed. (I've deployed worse. This is a safe space.)
Fix: replaced the div with a button wired to the primary conversion action. Dead click rate dropped in the next observation batch.
My kid walked in while I was watching session 22 and asked why I was watching a video of someone staring at a screen doing nothing. Couldn't really explain it. "Work" covers a lot of ground apparently 😅
Then the deeper problem surfaced.
This is worth sitting with, because it changes how you read every heatmap you've ever looked at. Clarity organizes all visual data by URL. Every click map, every scroll map, every heatmap is scoped to a specific URL path. For a traditional multi-page app, that structure works fine. For a SPA that renders 7 different screens under a single /app URL, it means every interaction across every screen gets aggregated into 1 useless blob. A dead click on the product listing screen looks identical to a dead click on the checkout confirmation, because from Clarity's perspective, they happened on the same page. I had been running this setup for months, watching aggregate heatmaps, drawing conclusions about user behavior, making design decisions based on that data, and every data point was contaminated. The structural mismatch between how analytics tools model pages and how SPAs actually work isn't a Clarity bug. It's a mismatch you don't catch until you've already built the wrong mental model of your users.
Analytics tools are built around page URLs. A SPA that never changes its URL gives them nothing to work with.
Your heatmaps have been lying since launch day.
Fix: hash routing. /app/#product-listing, /app/#checkout, /app/#confirmation. Each screen gets an addressable URL. Then event tagging per screen via clarity('set', 'screen', slug) so sessions segment cleanly in the dashboard.
// Fire whenever the active screen changes
router.on('routechange', (screenSlug) => {
clarity('set', 'screen', screenSlug);
});1 addressable URL per screen is also a marketing asset. You can now point a paid campaign directly to /app/#checkout instead of dumping all traffic at the front door and hoping the onboarding flow closes the gap.
Mode 2: The API and Its Hard Limits
Once you want to automate metric pulls, skip the dashboard. Hit the Clarity Data Export API at the project-live-insights endpoint. Auth via token: Settings, Data Export, Generate Token.
3 limits to know before writing a single line:
The API caps at 10 requests per day, no burst allowance, no override. (Think of it as a mana bar that resets at midnight. Don't blow it on test calls.) A cron job running every hour will fail by morning. Design your polling schedule around this constraint from the start.
Each request covers at most 3 days of history. No rolling 30-day view, no trend comparison in a single call. Build your own storage layer, accumulate daily, deduplicate on date. After 30 days you have a rolling month. After 90 days you start seeing seasonality signals worth acting on.
Each request accepts a maximum of 3 dimensions simultaneously. Device, country, and screen in one call: that's your 3. Add a 4th and the request fails. More segmentation means more calls and faster quota burn.
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()What the REST API doesn't give you: recordings, heatmaps, or session-level detail. Aggregate only. Individual user behavior stays in Mode 1 territory.
If you run multiple apps and want this data feeding something broader, a Claude-powered SaaS monitoring setup is a natural extension. Not a Clarity-specific pattern, but it closes the "is something on fire" question across your whole portfolio without checking 5 dashboards.
Mode 3: Claude and MCP
The @microsoft/clarity-mcp-server package on npm (official Microsoft) wires Claude into the same API you hit in Mode 2. The difference is the interface.
npx @microsoft/clarity-mcp-server --token your_clarity_tokenWith the MCP connected in Claude, you ask in plain English:
"Which screens have the highest dead click rate in the last 3 days? Compare mobile vs desktop."
"What did users do immediately before reaching the checkout screen without completing a purchase?"
Claude returns structured analysis. Patterns that would take an hour of manual session review get surfaced in under a minute. Asking a follow-up is instant. This is where MCP earns its place: fast iteration on investigation hypotheses, not batch automation.
What MCP inherits from the API: every limit, exactly. The same 10 requests per day, 3 days of history, and 3 dimensions per request max apply here as they do to the raw REST call. The MCP server is a transport adapter, not a data layer. It translates Claude's conversational input into REST calls and formats the responses back. It doesn't unlock any data the API doesn't already expose. Go in expecting a better investigation interface for the same data, not a superpower.
The mode that surprised me wasn't the speed of individual answers but the multi-variable comparisons. I asked Claude to compare conversion signals between sessions with dead clicks and sessions without. That cross-slice requires 3 separate API calls with different dimension combinations, quota math on top, and manual merging of responses. The MCP handled all of it in 1 turn. I wrote 0 lines of code and got a clean comparison in under a minute.
I think MCP works best as an investigation sprint tool: burn the 10 daily requests on targeted hypothesis testing, then switch to a script for everything repeatable. Could be I'm reading this wrong, but that split has been clean so far.
Worth noting: once the MCP hits 10 requests, it's done. No queue, no retry. Plan your questions before opening the session, not during. Exploratory asks burn quota fast.
For anything running on a schedule, a purpose-built CLI beats MCP for production automation: no daily cap, no Claude session required, runs in a cron without overhead. Use MCP for investigation, CLI for the scheduled stuff. They cover different parts of the job.
Dead clicks: 20% of sessions at the start, targeting under 5%. Fix deployed, measuring. Hash routing live, heatmaps clean per screen. Event tagging by screen active.
3 days and 1 free tool. That URL should have been there from launch 🤦♂️
Sources
- Microsoft Clarity — session recording, heatmaps, Core Web Vitals, free
- @microsoft/clarity-mcp-server — npm, Microsoft official
- Clarity Data Export API — endpoint documentation, rate limits
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).
Dead clicks, rage scrolls, users tapping nothing and leaving—Clarity caught all three in my session recordings. The demo-vs-product checklist in the kit shows you which production visibility gaps are costing conversions before you even touch analytics.