Bolt Web page view tracking
Table of Contents
In the upcoming Bolt Web release (6.3) we are making an improvement to our analytics implementation that affects how web page views are tracked in GA4 and Mixpanel.
What's changing?
Previously, Mixpanel and GA4's automatic page view tracking for the web reader was sometimes picking up extra page view events beyond the user's interaction. This was caused by our content preloading behaviour (which helps improve the user experience by loading pages in advance). This led to inflated page view accounts in your analytics as follows:
- Up to three page views per article (one real view and two additional ones tracking the preloading)
- Up to two page views per timeline (one real view and one tracking the timeline redirect)
In this update we are turning off automatic page view tracking and will now send page view events manually. This ensures that only one page view is recorded per page in focus, eliminating any additional events.
What you can expect:
- Editions with double page spreads: Each individual page in a spread will track one page view (two page views for a double page spread)
- Single page spreads & HTML articles: Each will send one page view
- Timelines: Each timeline view will track one page view
You may notice a drop in reported web page views in your analytics provider. However, this does not affect user volumes or other engagement metrics including session volume or duration. This does not affect iOS or Android app analytics.
FAQs
Q: When did you notice the tracking issue?
A: The bug was identified at the end of December 2024.
Q: How long have web analytics been affected?
A: As the issue is a product of using GA4 and Mixpanel's automatic page view tracking, we believe the issue arose when moving from UA to GA4 (customer dependent but at least before 1 July 2023) and since we began tracking web activity in Mixpanel in November 2024.
Q: Is there any way to confirm the correct page view numbers from the affected data?
A: Yes, there the URL path of the page view indicates whether it is a real page view or additional page view:
Timeline duplicates:
When a user navigates to a timeline, an initial redirect page view is sent before they land on the final timeline page. To identify and filter out the page views attributed to timeline redirects look for the URLs that do not capture the fill page path for example:
- Redirect page view: /t/home (records the base timeline path)
- Genuine page view: /t/home/home (captures the full timeline destination)
Article view duplicates:
We preload content in the background to allow for faster navigation and a better user experience. However this preloading can trigger additional page views. These extra page views are identified by a URL path that begins with /c/ (this is the internal URL of the preloaded content) for example:
- Preloaded page view (internal URL): /c/timeline/article/page-123456
- Real user page view (external URL): /breaking-news/content.html
To exclude the preloaded page views from your reports, filter out page paths / URLs containing /c/
. Please bare in mind that as part of this fix we will be tracking two page views per page in an edition with double page spreads to align behaviour with our native apps. Instead of tracking one real page view per double page spread we will now track two real page views per double page spread.
Q: What safeguards are you putting in place to catch future issues?
A: We know how important data accuracy is and are taking the following steps to identify similar issues in the future:
- Enhanced testing: We are improving our automated and manual testing processes to proactively detect analytics tracking inconsistencies
- Regular analytics audits: We will implement periodic audits of analytics data to catch any anomalies and ensure tracking logic is aligned with expected behaviour
We want to ensure that your data is as accurate and reliable as possible. If you ever notice anything unusual in your reports, please flag it to our support team and we'll be happy to investigate.
Q: What metrics does the tracking issue affect?
A: Total number of page views. It does not amplify the number of views per URL (as the redirect and preloading page views have different URLs).
It does not affect number of web reader users, sessions or any other events tracked by the web reader.