You may have noticed that we price our subscriptions based on the number of page views monitored. We occasionally get questions about this metric or why we track it.
When is a Page View Counted?
Why Count Page Views At All?
Why Price Based on Page Views?
Many services price their subscriptions based on the number of errors you send. If you don’t have many errors, the price looks cheap. But what happens if you have a bad release, causing thousands or millions of unexpected errors? You’ll either be paying huge surprise bills, or your data will get cut off and you’ll lose access at the most critical time. We don’t think either of those are good options!
We believe metered pricing by number of errors is anti-developer, so we chose a different metric. We found that page views are often reasonably consistent month over month, and we want to be sure we have enough infrastructure to handle your worst releases (and help you fix them)!
Going Over Your Page View Limits
If you go over your page view limits once or twice, it’s no problem. If you go over month over month by a significant amount, you will get an email from us asking you to curtail usage, or upgrade to the next tier. We’re nice folks, and either option is fine. We will not cut off your data ingestion for overages.
How Come Google Analytics Has A Different Page View Count Than TrackJS?
We count a page view only when our script is initialized. In a single page application (SPA) it’s likely our script will initialize only once, but the user will visit many pages. Google Analytics (or other tools) are often configured to count each pushState change as a page view. We don’t do this because our main goal with page views is to provide a traffic-normalized way (errors per page view) to analyze your site’s script quality, not be the user activity analytics source of truth.