{"id":135,"date":"2016-04-20T21:22:10","date_gmt":"2016-04-20T21:22:10","guid":{"rendered":"http:\/\/www.digitaldatatactics.com\/?p=135"},"modified":"2018-03-01T19:53:24","modified_gmt":"2018-03-01T19:53:24","slug":"how-do-i-use-dtm-for-a-single-page-app","status":"publish","type":"post","link":"https:\/\/www.digitaldatatactics.com\/index.php\/2016\/04\/20\/how-do-i-use-dtm-for-a-single-page-app\/","title":{"rendered":"How do I use DTM for a Single Page App?"},"content":{"rendered":"

The question of how to use DTM on Single Page Apps (SPAs) is a VERY hot item right now. By Single Page App, I’m referring to\u00a0a full user flow contained on a single web page, so as to provide the user a more seamless experience. Often, these pages act like typical web pages, but they don\u2019t always change URLs or load new resources.\u00a0Many common web development technologies, such as Angular.js, Ember.js, and AJAX use SPA principles.<\/p>\n

Unfortunately, there isn’t a single great answer for how to deploy DTM- it depends on many things. I’ll work through some of the options and the limitations to be aware of.<\/p>\n

Suppressing Page View Beacons<\/h3>\n

Whatever method you take for tracking page views in a SPA, keep in mind most SPAs\u00a0do<\/em> have one true “page view” when the DOM first loads. If you are going strictly with the DCR or EBR route, you may need to suppress the initial page view beacon<\/a> the Analytics tool will want to set by default. Otherwise, in the example below where the developers are firing a direct call rule on all page views, you’d get TWO beacons on the first page and 1 on all subsequent pages.<\/p>\n

\"Picture1\"<\/a><\/p>\n

Data Layer Considerations<\/h3>\n

You’ll need to make sure that whatever the sources of your Data Elements are (CSS selector, javascript objects, cookies…) have the correct values BEFORE your rule is triggered. I have an example site showing one way you might do this <\/a>for a data layer\u00a0(though you’ll need to look in the source code), but ultimately it’s going to depend on your site.<\/p>\n

Variable Persistence<\/h3>\n

One last consideration is that once your Analytics object exists (as in, the “s” in “s.pageName”), variables set on it will continue to exist unless specifically overwritten. In most cases, you’d overwrite s.pageName with a new value so it isn’t a problem, but something like s.eVar5 may be set on the first beacon in your SPA, and not desired on subsequent beacons. You can use s.clearVars() to “refresh” your “s” object, but you have to make sure it fires at the right time- for example, after the beacon on Page A, but before DTM starts mapping Data Elements to variables for the beacon on Page B.\u00a0How you do this will depend on the overall deployment method you choose.<\/p>\n

Deployment Methods<\/h3>\n

1) Direct Call Rules<\/h4>\n

Perhaps the most straight-forward approach is to have developers fire a Direct Call Rule, like _satellite.track(“page view”) on every thing YOU consider a page view, whether it’s a fresh new DOM or not.<\/p>\n\n\n\n\n
Advantages:<\/strong><\/th>\nDisadvantages:\u00a0<\/strong><\/th>\n<\/tr>\n
\n
    \n
  • You have ultimate control over when a page view in considered a page view.<\/li>\n<\/ul>\n<\/td>\n
\n