From Page Views to Full Telemetry: Rebuilding the Analytics Dashboard

You know that moment when you look at something you built a week ago and think, "Oh no. Oh no no no. We can do better"?

That was me, staring at my analytics dashboard. A week ago, it was a page-view counter with a world map and some bar charts. Functional? Sure. Impressive? About as impressive as a calculator app at a hackathon. It answered one question: "Did anyone visit my site today?" But it couldn't tell me how far they scrolled, what time they showed up, whether they were a human or a bot, or how fast my API was responding.

In other words, it was the analytics equivalent of checking your bank balance but never looking at the transactions.

Today? It's a 9-section, 26-component command center with heatmaps, scroll depth tracking, engagement metrics, bot detection, API telemetry, and Core Web Vitals. It sparks joy. It also sparks questions like "why did I spend an entire session on tooltips?" but we'll get to that.

The Starting Point: What We Had#

Let's set the scene. Before this session, the analytics dashboard already existed (I wrote a whole post about building it and then another one about all the security holes I found in it). It tracked page views, had a Leaflet world map with visitor pins, showed top pages, browsers, devices, and operating systems. It even had IP intelligence lookups.

But it was flat. One long page. No categories. No tooltips explaining what anything meant. If you weren't me, you'd have no idea what half the charts were showing.

Here's what the dashboard looked like, section by section:

That right column? That's the to-do list that kept me up at night. Metaphorically. (Okay, literally.)

The Reasoning: Why Upgrade?#

Before I walk you through the how, let me explain the why. Because adding 13 new metrics to a dashboard isn't a decision you make lightly. Each one has to earn its spot.

Reason 1: You can't optimize what you can't see#

Knowing someone visited your site is great. Knowing they bounced after reading 25% of the page? That's actionable. Maybe the intro is too long. Maybe there's a wall of text that scares people off. Maybe the GIFs aren't funny enough. (Impossible, but hypothetically.)

Reason 2: Security is a spectator sport (for the defender)#

I'm a cybersecurity professional. Watching bot traffic trends and auth attempt patterns isn't just interesting, it's literally my job description applied to my own site. If someone is brute-forcing my analytics login, I want to know about it before they get in, not after.

Reason 3: Performance matters more than you think#

If my API endpoints are responding slowly, I need to catch that before visitors do. If my Core Web Vitals are tanking, Google will quietly bury my search rankings while I sit here thinking everything is fine.

The Upgrade: 13 New Metrics in One Session#

Here's where it gets fun. In a single Claude Code session, we added 13 new analytics metrics, reorganized the entire dashboard into 9 categorized sections, added tooltips to every panel, and created a consistent component architecture.

Let me walk you through each section and why it exists.

Section 1: Overview (The Executive Summary)#

Every dashboard needs a "glance and go" section. Ours has four KPI stat cards at the top:

• Total Page Views (the big number that makes you feel good)
• Unique Visitors (the slightly smaller number that keeps you honest)
• Bounce Rate (the humbling number)
• New vs. Returning (the "are people coming back?" number)

Below the cards: a Page Views Over Time area chart and the star of this section, the Peak Hours Heatmap.

// Peak Hours Heatmap: 7 days × 24 hours
// Each cell's color intensity reflects traffic volume
<PeakHoursHeatmap data={hourlyHeatmap} />

The heatmap is a 7-day-by-24-hour grid where each cell's color intensity shows how much traffic that time slot gets. It answers questions like: "Should I publish blog posts in the morning or evening?" and "Why is there a traffic spike at 3 AM?" (Spoiler: bots. It's always bots.)

Section 2: Audience & Geography#

This section answers the "who" questions. The world map was already here, but we added two new charts:

New vs. Returning Visitors tracks how many first-time visitors you get compared to returning ones. If nobody comes back, your content might not be sticky. If everyone is returning but nobody new is showing up, you might have a discovery problem.

Referrer Breakdown shows where your traffic comes from. Direct visits, Google searches, Twitter links, Hacker News, that one Reddit post that blew up for 20 minutes.

Section 3: Content & Engagement (The Good Stuff)#

This is the section I'm most proud of. Page views tell you that someone showed up. Engagement metrics tell you what they did when they got there.

Scroll Depth tracks how far visitors scroll on each page. We fire tracking events at 25%, 50%, 75%, and 100% scroll milestones:

// Client-side scroll tracking via IntersectionObserver
const SCROLL_THRESHOLDS = [25, 50, 75, 100];

// When a visitor crosses a threshold, fire a beacon
navigator.sendBeacon('/api/analytics/track-engagement', JSON.stringify({
  type: 'scroll',
  path: window.location.pathname,
  depth: threshold
}));

Time on Page measures how long visitors actually spend reading. Combined with scroll depth, you can figure out if someone speed-scrolled to the bottom (looking for a TL;DR) or actually sat there and read all 3,000 words.

Section 4: Technology#

Browsers, devices, and operating systems. This was mostly already built, but we cleaned up the components and added consistent tooltips. Every panel now has a little info icon that explains what the data means and where it comes from.

Section 5: Server Telemetry (New!)#

This section is entirely new and answers a question most dashboards ignore: "How is my backend performing?"

The API Response Chart shows per-endpoint latency with three percentile breakdowns:

// Per-endpoint cards with p50/p75/p95 + error rate
<ApiResponseChart metrics={apiMetrics} dailyMetrics={apiMetricsByDay} />

We also track error rates per endpoint. If /api/analytics/track suddenly has a 15% error rate, something is wrong and I want to know before my visitors do.

Section 6: Performance (Core Web Vitals)#

This section integrates with Vercel Speed Insights to display real-user Core Web Vitals data with color-coded rating bars:

• Green = Good (meeting Google's thresholds)
• Yellow = Needs Improvement (borderline)
• Red = Poor (Houston, we have a problem)

Each metric shows a distribution bar so you can see not just the average, but how many visitors had a good, okay, or bad experience.

Section 7: Security (Because I'm That Guy)#

Remember, I'm a cybersecurity professional. This section is my playground.

Bot Traffic Trend shows a stacked area chart of human vs. bot traffic over time, with a percentage badge. If your bot traffic suddenly spikes from 15% to 60%, someone might be scraping your content or probing for vulnerabilities.

Auth Attempts Chart tracks successful vs. failed login attempts to the analytics dashboard. This is the "is someone trying to break in?" detector.

The Vercel Firewall Card pulls real-time data from Vercel's API to show:

• Active attack detection status
• OWASP Core Rule Set managed rulesets (SQL injection, XSS, scanner detection)
• Custom WAF rules
• Recent firewall events with timestamps

Section 8: Newsletter#

Subscriber counts, active vs. inactive breakdown, and a full subscriber list table. This was already built but it now lives in its own section instead of being awkwardly shoved at the bottom.

Section 9: Recent Activity#

The raw data firehose. Last 50 page views with full visitor details, plus sortable data tables for every dimension (pages, countries, browsers, devices, OS, referrers).

The Component Architecture: Making It Maintainable#

One of the decisions I'm happiest about is the component architecture. Instead of one massive 2,000-line page, every visualization is its own component:

src/app/analytics/_components/
├── api-response-chart.tsx      # API latency + error rates
├── auth-attempts-chart.tsx     # Login attempt tracking
├── bot-trend-chart.tsx         # Human vs. bot traffic
├── browser-chart.tsx           # Browser distribution
├── countries-chart.tsx         # Geographic breakdown
├── device-chart.tsx            # Device type breakdown
├── new-vs-returning-chart.tsx  # Visitor loyalty
├── os-chart.tsx                # Operating system breakdown
├── page-views-chart.tsx        # Traffic over time
├── peak-hours-heatmap.tsx      # When visitors arrive
├── referrer-chart.tsx          # Traffic sources
├── scroll-depth-chart.tsx      # How far they read
├── time-on-page-chart.tsx      # How long they stay
├── panel-wrapper.tsx           # Consistent card frame
├── section-header.tsx          # Section dividers
├── stat-card.tsx               # KPI display cards
└── ... 9 more components

That's 26 components total. Each one:

• Takes typed props (TypeScript interfaces in analytics-types.ts)
• Uses Recharts for consistent visualization
• Wraps in a PanelWrapper for uniform card styling
• Includes an info tooltip explaining what the metric means

The Tooltip Decision (Yes, I'm Writing About Tooltips)#

I spent a non-trivial amount of time adding info tooltips to every single panel. This might seem like a cosmetic detail, but hear me out.

Dashboards have a dirty secret: they're only useful if the person looking at them understands what they're looking at. A chart labeled "p95 API Response Time" means nothing if you don't know what a percentile is. A "bounce rate" of 45% is meaningless without context about what's normal.

Every PanelWrapper now accepts an info prop with a plain-English explanation:

<PanelWrapper
  title="Scroll Depth"
  info="Shows how far visitors scroll on each page. Tracks 25%, 50%, 75%, and 100% milestones. Higher completion rates suggest more engaging content."
>
  <ScrollDepthChart data={scrollDepth} />
</PanelWrapper>

The SQL Behind the Scenes#

All this data has to come from somewhere. The dashboard runs 20+ SQL queries in parallel using Promise.all() against a Neon Serverless Postgres database.

Here's a taste of the new vs. returning visitors query:

SELECT
  date_trunc('day', created_at) AS day,
  COUNT(*) FILTER (WHERE is_first_visit) AS new_visitors,
  COUNT(*) FILTER (WHERE NOT is_first_visit) AS returning_visitors
FROM page_views
WHERE created_at > NOW() - INTERVAL '${days} days'
GROUP BY 1
ORDER BY 1

The Engagement Tracking Pipeline#

Getting scroll depth and time-on-page data required building a new client-side tracking system and a corresponding API endpoint.

Client side (analytics-tracker.tsx):

1. Track scroll position with an event listener
2. Fire a beacon at each 25% milestone (deduped, only fires once per threshold per page)
3. Track elapsed time on the page
4. Send time-on-page via sendBeacon() on page navigation or tab close

Server side (/api/analytics/track-engagement):

1. Validate input with Zod schemas
2. Deduplicate by IP + page + threshold (1 record per combo per hour)
3. For time-on-page, keep only the longest duration per session (people don't un-read a page)
4. Rate limit to prevent abuse

The Recharts Experience#

All the charts use Recharts, a React charting library built on D3. It's composable (you build charts from smaller pieces like <AreaChart>, <XAxis>, <Tooltip>), plays nicely with server components via dynamic imports, and looks great with Tailwind CSS colors.

The peak hours heatmap was the most fun to build. It's not a standard Recharts component. It's a custom SVG grid where each cell's opacity maps to the traffic volume for that hour-of-day and day-of-week:

// Color intensity scales with traffic volume
const opacity = maxViews > 0 ? (views / maxViews) * 0.8 + 0.1 : 0.05;

Minimum opacity of 0.05 so empty cells are still visible, max of 0.9 so the grid doesn't turn into a solid block of color. These tiny design decisions make the difference between a chart that's informative and one that's beautiful and informative.

Lessons Learned#

The Final Dashboard: By the Numbers#

What's Next?#

The dashboard is comprehensive, but there's always more data to track. Some ideas for the future:

• Search query analytics (what are people searching for on the blog?)
• Reading completion rate (scroll depth + time on page combined into a single metric)
• Alerting (get notified when bot traffic spikes or error rates climb)
• A/B testing integration (which post titles get more clicks?)

But for now? I'm going to sit here and watch the heatmap update in real time. It's oddly meditative.

Like a lava lamp, but with data.

Previous in series: 7 Days, 117 Commits: Building a Production Website with AI

Written by Chris Johnson and edited by Claude Code (Opus 4.6). 26 components, 13 new metrics, 9 sections, 1 deeply satisfying heatmap. If your dashboard can't tell you what's happening at 3 AM on a Tuesday, you're not done building it.