Skip to content
tezvyn:

How do you track page views in a Single Page Application?

Source: developer.mozilla.orgMediumHow cards are made

How do you track page views in a Single Page Application?

Tests your grasp of SPA navigation vs. traditional page loads. A great answer explains how SPA routers use the History API (pushState) and how to listen for changes to send analytics events. A red flag is suggesting polling the URL.

What's really being asked

Your understanding of how Single Page Applications handle navigation without full page reloads. The interviewer wants to see if you know the underlying browser APIs (the History API) that frameworks like React Router use, and how to hook into those changes to fire analytics events. It separates candidates who just use a framework from those who understand how it works.

The full answer

Four key points in order. First, acknowledge that SPAs don't trigger new page loads on internal navigation, so standard analytics snippets fail. Second, identify the browser's History API as the solution; specifically, pushState() and replaceState() which are used by SPA routers to change the URL. Third, explain the two detection methods: listening for the popstate event for browser back/forward actions, and hooking into the router's history object for programmatic navigation. Fourth, describe centralizing this logic, for example in a React useEffect hook that listens to location changes, to send a pageview event with the new path to your analytics service.

The mistakes people make

The biggest red flag is suggesting polling window.location with setInterval. This is grossly inefficient and indicates a lack of fundamental knowledge. Another mistake is only describing tracking on initial load, missing the "single page" part of the question. A less severe but still weak answer would be to only mention a specific library's feature (e.g., "React Router has a hook for this") without explaining the underlying browser mechanism (pushState, popstate) that makes the hook possible.

What usually comes next

Expect questions about implementation details. For example, "How would you avoid tracking Personally Identifiable Information (PII) that might appear in URL parameters?" (Answer: Sanitize URLs before sending them). Or, "How would you abstract this logic to be reusable across the app?" (Answer: Create a custom React hook like usePageTracking() or a higher-order component).

A concrete example

In a React application using React Router, you can create a dedicated component for tracking. This component uses the useLocation hook to get the current location object. You then use a useEffect hook with the location's pathname in its dependency array. Inside this effect, you call your analytics provider's page view function, like analytics.page(location.pathname). This ensures that every time the route changes, a new page view event is fired.

Interview question

To reliably track navigation as 'page views' in a Single Page Application, what is the most appropriate client-side strategy?

  • a.Place the analytics script in the main `index.html`; it will automatically fire on every route change within the SPA.
  • b.Use `setInterval` to periodically check `window.location.href` and send an analytics event if the URL has changed.
  • c.Listen for `popstate` events and hook into the router's history object to detect navigation and send tracking events.Correct
  • d.Attach `onClick` event listeners to all internal navigation links to manually trigger a page view event.
Why?

This is correct because it covers both programmatic navigation (via the router's history) and browser button navigation (via `popstate`). Polling with `setInterval` is a tempting but grossly inefficient anti-pattern.

Just read this? Test yourself on what you have been reading.

Read the original → developer.mozilla.org

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles