Single page applications (SPAs) are great, but it can sometimes be difficult to collect their data effectively. This is due to the fact that, as the name suggests, they do not have the typical load events (page loads, hash changes, etc.) that most analytics collection tools base their collection rules upon. Especially rules about the state of the application (i.e. what page the user is on).
So how can we use session storage to help with analytics on SPAs? First let’s look at a simple SPA.
This form steps through pages with no new page loads, hash changes, or any other URL based events. A basic setup of DTM would count the initial page load as a view, but not the subsequent “pages” as the form progresses. The user’s experience vs. the analytics collected would be different.
Looking in DTM debug mode in my console I can see that Adobe detected the initial page load and reported a page view, but did nothing on the subsequent pages as there was no other page load. At this point my analytics can tell that users are getting to my page, but I have no way of telling how far they get in through form or if they submit it.
I’ll start by using session storage to save page information. Here I am storing the current page and the previous page as you move through the form.
I will then store these session storage variables as DTM data elements. I like storing these session storage variables as custom script data elements instead of JS objects. I feel like they just work better as custom elements. They can now be used in any part of DTM.
For my new page view rule I will use the dataelementchanged event. This event is very versatile, and in my opinion, underutilized. I think one could write an entire DTM implementation using just dataelementchanged, but I digress. With a few adjustments, this event based rule can handle everything a normal page load rule can do. Now when my session storage “page” variable changes, DTM will “notice” and fire my rule.
And Adobe does the rest…
You may notice that the Data Element Changed rule does not fire on my initial page load. I think that is because DTM library code sends a page view when it (the library code) is loaded and the creation of a data element does not count as a change to it. Please correct me if I am wrong on this.
One issue that I have encountered using this method is page refreshes and other SPA navigation. Sometimes refreshing a single page app will take you back to the first “page” with a new page load. This is the case with my form. If I am on the second “page” and refresh, I will go back to the beginning of the form and a page load rule will fire along with my data element change rule. Because of a page load and a data element change (my data elements exist and changes on the refresh), respectively.
I can get around this in my page load rule conditions. Here I will make sure that no previous page data exists. If it doesn’t, its a fresh visit (no session storage data) and the generic page load rule will fire. If previous page data does exist, its likely a refresh or perhaps some SPA navigation and only my data element change rule will fire.
I don’t think it’s possible in DTM rules to check for an empty data element value so I do it with custom code:
Now, if I refresh while on the second “page” of the form flow and get returned to the first page, my generic page load rule will not fire, but my data element changed on will because I still have a previous page data element.
That’s all there is to using session storage as a source of truth for Adobe Analytics on single page apps. This example just covers page views, but could be applied to just about any event that is tricky to pick up with DTM. Just to recap I like using session storage for the following reasons:
- I don’t have to scrape any information from the page for my data elements
- The data in session storage is available for any application to use. For example, your chat vendor or marketing pixels
- It keeps Adobe code out of the core application code, i.e. _satellite.track
- Session storage is performance friendly and temporary
- Easy to maintain and explicit for DTM admins
- Developers/Engineers are very familiar with session storage
Thanks for reading!