python Case study
Microsoft Clarity Analytics Extractor
Clarity records what people actually do on a page: where they rage-click, where they scroll to and stop, where they come back and leave. That is the most direct evidence available about a UX problem, and it is nearly useless while it stays inside the recording viewer.
The business problem
Session recordings and heatmaps are compelling to watch and hard to act on. Watching twenty sessions produces an impression; it does not produce a ranked list of pages with a problem. To connect behaviour signals to a decision they have to come out as data that can be sorted, compared across pages, and checked again after a change.
What I delivered
- A pipeline pulling Clarity behaviour signals into structured output rather than leaving them in the session viewer.
- Page-level aggregation, so the unit of analysis is a page with a problem rather than an individual session.
- Output shaped for before-and-after comparison, since the point of a UX change is to move a signal.
- A structure that lines up with the other reporting, so behaviour data can sit alongside search and commerce data for the same page.
Technical approach
- Aggregate to the page. A single session shows you a possibility; a page with a consistent signal across sessions shows you a problem.
- The output is designed for comparison over time, because the useful question is never what is happening but whether the change helped.
- Keeping the shape consistent with the other extracts is what allows a page to be examined from several angles at once instead of in separate tools.
- Behaviour signals are treated as evidence pointing at a page, not as a conclusion about why. The recording is still where you go to understand the cause.
Result and evidence
Behaviour data became something that can be ranked and rechecked, which is what makes it usable for prioritising UX work rather than for illustrating a hunch.
Commercial value
Most UX debates are won by whoever is most confident. Having page-level behaviour signals turns that into a question with an answer.
Readable implementation brief
implementation_brief {
project: "Microsoft Clarity Analytics Extractor"
input: "Clarity session behaviour signals"
unit: "page-level aggregate, not individual sessions"
purpose: "rank pages by problem; verify after a change"
alignment: "shares shape with the search and commerce
extracts so one page can be seen from all sides"
boundary: "signals point at a page; recordings explain why"
}What this project shows
The judgement here is aggregating to the page rather than showcasing individual recordings. Recordings persuade; aggregates prioritise, and prioritising is the actual job.
Aligning the output with the other extracts was deliberate. Data in three incompatible shapes is three tools nobody correlates.