Technical
Virtual pageview
Also called history pageview.
Virtual pageview is a pageview event a script sends when an app changes the screen without loading a new document. It lets a route change count as a page view.
How it is measured
Count pageview events that have no matching document request in the server log. Each should carry the new path and title. Verify by clicking through and watching for one POST per route in the Network panel.
Compare the number of virtual pageviews with the route changes you can list in the router. They should match one to one.
Worked example
A booking app has the routes `/search`, `/room/12`, and `/checkout`. A guest who searches, opens two rooms, and checks out makes four route changes after the first load, which already counts, so five events are expected. The tracker records 5. After a framework upgrade it records 9, because the router now calls `pushState` twice per change.
Adding a 50 ms debounce and ignoring consecutive identical paths brings the count back to 5.
How it differs
A virtual pageview is sent by script for a route change. A pageview comes from a real document load. A visit can contain both, one real load followed by many virtual ones, and the sum is what the report shows.
Common errors
Firing on load and again on the first route. Double firing on pushState and a framework hook. Sending the previous title. Counting scroll anchors. Counting redirects done with `replaceState`. Naming them differently from real pageviews so reports split.
In practice
Send virtual pageviews with the same event name and fields as real ones. Test every router transition, and debounce and deduplicate on path.