Page Views vs Custom Events: When to Use Which

Two types of tracking, two different questions

Every analytics tool gives you two fundamental ways to track what happens on your website: page views and events. Page views answer "where did visitors go?" Events answer "what did visitors do?" Understanding when to use each — and when they overlap — is the difference between useful data and noise.

Page views: automatic and universal

A page view fires every time a visitor navigates to a new page. Most analytics tools track this automatically — you install the script and page views just work. You get paths, titles, entry pages, exit pages, and navigation flows.

Page views are perfect for:

• Content sites and blogs — which articles get read, how deep visitors go
• Multi-page flows — signup wizards, checkout steps, onboarding sequences
• SEO analysis — which landing pages attract organic traffic
• Navigation patterns — where visitors enter, where they drop off

For single-page applications (SPAs), the analytics script needs to detect route changes via pushState and popstate. Web Analyzer App handles this automatically — no extra configuration needed.

Events: intentional and specific

Events track specific actions that don't involve a page change. A button click, a form submission, a video play, a file download, a scroll past the pricing section. Events require you to explicitly define what to track.

Events are essential for:

• CTA clicks — did visitors click "Start free trial" or "Book a demo"?
• Form interactions — how many started the form vs completed it?
• Feature usage — in a SaaS app, which features are actually used?
• Engagement signals — video plays, accordion opens, tab switches
• Purchases and conversions — the actions that generate revenue

How to implement custom events

With Web Analyzer App, tracking a custom event is one line of JavaScript:

Tracker.track('signup_clicked', { plan: 'pro', source: 'pricing_page' });

The first argument is the event name. The second is an optional payload — any JSON object with extra context. Keep event names descriptive, lowercase, and consistent. Use past tense for completed actions (form_submitted) and present tense for intent (pricing_viewed).

Common mistakes to avoid

Tracking everything. Don't fire events on every mouse move, scroll pixel, or hover. You'll drown in data you'll never look at. Track actions that correlate with business outcomes.

Inconsistent naming. If one developer uses signUp, another uses sign_up, and a third uses user-registered, you'll have three events measuring the same thing. Establish a naming convention early and enforce it.

Replacing page views with events. Don't fire a custom event for "page loaded" — that's what page views are for. Events should capture actions that page views can't.

No payload context. An event named button_clicked without context is useless. Always include enough payload to answer "which button?" and "where?" A better version: Tracker.track('cta_clicked', { label: 'Start free trial', page: '/pricing' }).

When they work together

The most powerful analytics combine both. Consider a SaaS signup flow:

1. Page view: visitor lands on /pricing (automatic)
2. Event: pricing_plan_selected with { plan: 'pro' }
3. Page view: visitor navigates to /signup (automatic)
4. Event: signup_form_submitted
5. Page view: visitor reaches /welcome (automatic)
6. Event: onboarding_started

Page views give you the navigation skeleton. Events fill in the intent. Together, they tell the complete story of how a visitor becomes a customer.