Heap provides extra functionality for single-page web apps that other analytics tools don’t, such as automatically capturing all pushState and hashChange events.
Heap detects a pageview whenever the URL’s Path or Hash changes. In the past, if developers wanted to render new information on a page, they would typically redirect the user to a different path, and the user’s browser would load a new HTML page.
Modern front-end frameworks allow developers to rerender the contents of the page without having to redirect the user to a new HTML page. This is called a single page application (SPA). This minimizes the load time and greatly improves the user experience.
Tracking Path/Hash Changes
A typical Angular site re-renders the page’s content rather than navigating to a new page. This means the contents of the page change, which feels a lot faster than loading a new webpage. While this is great from a user perspective, this causes issues for data capture tools like Heap.
Because the path never changes, Heap doesn’t detect a pageview. Every event captured on this page is on the / path, even though the user is visiting a different section of the application. This can become problematic in larger applications where you will want to analyze events on specific pages.
We recommend implementing some sort of push state or routing (common in frameworks/libraries) to provide semantic/meaningful Path or Hash changes so Heap can detect that a user is navigating to a different section of the application. This will allow Heap to detect that a pageview occurred within the application.
Single-page applications are commonly developed using web frameworks. For additional consideration on things to know when using Heap in sites built with web frameworks, see Using Heap With Popular Web Frameworks & Libraries.
In addition to the pageview tracking limitation cited above, the following may occur when using Heap with a SPA.
- Snapshots may fire too quickly – this is because the Snapshot doesn’t have to wait for the pageview load, which results in the Snapshot only capturing what’s on the previous page.
- Track events will get queued up with what’s on the current page – When this happens, the event only gets captured on the current page where the event fired and not on the next page where it should. For example, if a user clicks “buy now” from a purchase page, when they click it, the track event could fire on the product page because it was already loaded.
- For autocapture, certain properties (like Title and Previous page) will only be captured from the previous page rather than the current page – This is because our autocapture event fires immediately before the routing or hash change have happened. So certain page properties will not be correct because of timing issues with the push state.
Feel free to reach out to firstname.lastname@example.org with any questions about these considerations.