--> SanjanaDanait / Clickstream Event Explorer: Chrome Extension

Clickstream Event Explorer: Chrome Extension

A Chrome extension that brought real-time event validation inside the browser — no more dev tools archaeology.
Clickstream Event Explorer
Role Lead Product Designer — sole designer, end-to-end
Timeline Nov 2025 – April 2026 (Research → Beta → GA)
Platform Web — Chrome Extension
Tools Figma, FigmaMake, V0, Cursor, Claude

Overview

Every time a PM or analyst at Intuit ships a new feature, they need to verify that the right tracking events are firing — and that the data attached to those events is correct. The standard workaround was the browser's developer tools Network tab: filter through hundreds of raw network calls, click into each, and cross-reference nested JSON against a taxonomy document — one event at a time. On pages with multiple tracking calls, this could take an hour. Some PMs didn't have the technical fluency to do it at all, which meant validation either got skipped or depended on an engineer.

This friction showed up consistently in the contextual inquiry sessions the PM and I ran as part of a broader instrumentation platform overhaul. We observed every persona — PM, analyst, developer — hit the same wall at the validation and discovery step — one of the most time-consuming parts of the workflow, and the most addressable with a focused solution.

My role was to lead the full design cycle: framing the problem in research, building the prototype that secured director and VP-level alignment, co-authoring the PRD with the PM, and driving UAT through to the GA release in April 2026.

Project Brief How might we give PMs, analysts, and engineers, visibility into product events — so they can discover and validate instrumentation quickly and easily?

Final Designs & Impact

The Clickstream Event Explorer (CEX) is a Chrome side panel that captures every tracking event firing on any Intuit product page in real time — parsed, labeled, and organized the moment it fires.

Impact

CEX launched in GA in April 2026 and is live in Intuit's Chrome Web Store. The March 2026 beta was used by Consumer Group analytics and Marketing Operations teams during tax season — a high-stakes, time-pressured context — before the full GA release.

Within days of launch, users were sharing the extension unprompted across developer and PM channels. The spread was peer-to-peer, not mandated.

“ Hey folks, check out this CEX. I'm working on clickstream validation right now and this is going to save me a ton of time. Senior Software Engineer
“ omg the clickstream extension is exactly what I needed — thank you Senior Staff Data Scientist
“ So nice! Love the filters on properties and widgets. Principal Data Scientist
“ It's awesome! I also shared it in the CG PM channel as well. Staff PM
“ Wow — the ability to expand an event and see the full JSON. The link to the corresponding plugin! The filters are super helpful. Staff Software Engineer

The feedback came unprompted from across all three target personas — PMs, data scientists, and engineers — within the first week of the GA launch.

We knew the workflow was broken. But before designing anything, I needed to understand: whose workflow exactly, and where was the real wall?

Research

In Nov 2025, the PM and I ran contextual inquiry sessions with PMs, analysts, and developers across TurboTax, QuickBooks, and Mailchimp. We watched people try to validate and discover events as part of their actual workflows, not in a lab setting.

Three findings directly shaped the MVP:

Finding 01 PMs and developers were stuck in the same painful loop, for different reasons. Developers knew dev tools well enough to navigate them, but validating a single event still required expanding multiple layers of raw JSON and repeating the process for every event on the page. Some PMs largely avoided dev tools altogether — their only path was to ask an engineer, which introduced delays and dependencies that shouldn't exist for a routine pre-launch check.
Finding 02 Analysts had a compounding problem: discovery came before validation. Before analysts could validate anything, they first needed to figure out what was already instrumented on a page they didn't own. Finding the downstream data lake table for an event meant asking a data engineer. Finding which internal web plugin an event belonged to meant hunting through documentation. Both were multi-hour detours that should have been instant lookups.
Finding 03 The structured property view was the core unlock. PMs didn't need raw JSON — they needed events automatically parsed into readable tiers: the required ECS standard properties (action, object, scope_area, etc.), domain-level context properties, and custom business-specific fields. Separating these three groups meant PMs could scan for what they needed without wading through noise that was only relevant to developers.

Design Decisions

01. Side panel, not a separate popup window

The predecessor tool, Data Buddy, opened as a separate floating window. In practice, users were constantly toggling between the tool and the product they were testing — losing their place each time. I chose the side panel layout to keep the event stream and the product page visible simultaneously. It's the only layout that actually supports real-time validation: interact with the page, watch events appear, without ever switching contexts.

This decision had significant downstream implications. A docked panel at 350px wide is a fundamentally different design surface than a full browser tab — it forced every component decision toward compactness.

Previous tool with floating window vs New chrome extension side panel docked layout comparison Separate window vs. side panel in same window — keeping both the event stream and the live page in view simultaneously.

02. Designing for density — borrowing from tooling, not product UI

Intuit's design system is built for consumer-facing surfaces: larger type, generous spacing, comfortable touch targets. None of that scales to an event inspector panel where a single card needs to show a host of information, both, in the collapsed state and in the expanded state.

I developed a custom theme within the Intuit design System, taking direct inspiration from Chrome DevTools and other code editor interfaces — both of which have solved the same problem: surfacing dense technical information for expert users in a compact, scannable format. Smaller type, tighter row spacing, monospace labels for property names and values. This wasn't a deviation from the design system — it was an extension of it for a context the system wasn't originally designed for.

Standard Intuit design system component vs custom compact component comparison Standard IDS spacing vs. the custom compact theme — both standards-compliant, built for different reading contexts.

03. What I scoped out and why

Discovery mode — the visual overlay. The prototype included a mode where all instrumented UI elements on a page would be visually highlighted, letting users see what was tracked without triggering anything. It was the strongest-rated concept in testing. But it required an inference pipeline and data engineering resources that didn't exist for the MVP. Shipping a working validation experience first — rather than waiting for the full vision — was the right call. Discovery mode is on the roadmap.

The strongest concept in testing — deferred to a future release in favour of shipping the validation experience first.

Inline edit link — platform integration. Users wanted a button to jump from a captured event directly into the platform to edit event specs. I deprioritized this because we were actively replacing the existing tool with a new platform (Clickstream Studio), and building the integration into the old tool would have created throwaway work.

04. The Amplitude deep-link — reprioritized after beta

The direct jump to Amplitude was in my initial prototype but scoped for a later release. After the beta, it surfaced as the single most-requested fast-follow from users: validate that an event fires, then immediately chart it in Amplitude — without copying event names, switching tabs, and rebuilding the query from scratch. I worked with the PM to move it into the GA scope. It shipped in April 2026 and was widely appreciated by the PM community.

The Amplitude deep-link — validate an event fires, then immediately chart it without switching tabs or rebuilding the query.
Static screens show layout. They can't show the moment an event appears the instant you click something. How do you get leadership aligned on a felt experience, not a feature list?

Prototype & Alignment

I used FigmaMake and V0 to vibe-code the extension running against a reconstructed Mailchimp homepage — giving stakeholders a real interaction, not a walkthrough.

The question shifted from "will this be useful?" to "when can we ship this?" The prototype was shown to VPs and Directors of Product Management and Engineering for Data & Analytics. It removed the need to explain why structured property parsing mattered or why the side panel was the right call — both were self-evident. It also surfaced the consistent multi-event selection ask, which is what put the Amplitude deep-link back on the MVP roadmap.

Interactive FigmaMake prototype that ran in a browser against a reconstructed Mailchimp product page — giving stakeholders a real interaction, not a walkthrough.

Design Deep Dive

The event card: from raw beacon to readable validation

Chrome DevTools Network tab vs. CEX event card The same event, two views. DevTools requires 4+ clicks and JSON literacy. CEX is readable on first glance. Structured properties view vs raw event payload view - each serves a separate user Three property tiers, always separated — PMs validate taxonomy; developers inspect raw payloads; analysts find their table and plugin in one place.

Search and filter

On a page with 30+ events in a session, the list itself becomes noise. Search by event ID lets users zero in on a specific event without clearing the session. Filters let them narrow by interaction type or widget name.

Search, filtering and settings - controls that let users narrow down on events and customize their view Search, filtering and settings - controls that let users narrow down on events and customize their view

Shipping with an interactive product tour

No matter how focused or simple a tool is, first-time users shouldn't have to go find documentation to understand it. I pushed for us to hold the GA release until we had an interactive product tour in place — one that surfaces the main features in context, the first time a user opens the extension. The goal was to make the value immediately legible without any external onboarding material.

The interactive product tour walks users through CEX's core features on first launch — no docs, no handholding from the team.

Reflection

01 Scope the MVP by resource cost, not user excitement. Discovery mode got the strongest reaction in testing — but the validation-first approach got us to a shipped, used product faster. The adoption data will inform how discovery mode should be built.
02 Compact information density is a legitimate design problem. A 350px panel forced patterns I hadn't used before at Intuit — borrowing from developer tooling rather than product UI. I'd apply this lens earlier on the next technically complex tool.
03 An interactive prototype is worth building when the value is a felt moment. The FigmaMake prototype closed the alignment gap that two meetings and a written PRD hadn't. When core value is experiential, a prototype does work documentation can't.
04 CEX is one layer of a larger platform. The MVP tradeoffs — which integrations to build, what to defer to Clickstream Studio — were only defensible because I was also designing the broader instrumentation platform strategy.
← Work