The Top 5 Reasons that Launch is Better for Single Page Applications

Single-page applications (SPAs) have historically presented a number of challenges for tag management systems. In general, SPAs do not rely on traditional browser page loads, or traditional analytics page views to present the user with an entirely new set of content. The underlying structure and behavior of the HTML and the data layer in an SPA is much more dynamic than in static web pages.

Launch, by Adobe, contains a number of enhancements that dramatically improve flexibility and control for implementing tags and responding to events in an SPA. Here is a quick outline that pulls together some of the most important improvements that Launch provides for SPAs compared to DTM. A more general view of the benefits of Launch over DTM, not specific to SPAs, is available here. Thanks to Jenn Kunz for providing some earlier details on this topic here and here. We have received a number of requests for a comparison of Launch to DTM when using SPAs so I thought that it would be helpful to get a summary list out to everyone.

For specific implementation examples, Adobe Consulting Services also has reference implementations for the Angular and React frameworks here.

1) Multiple Triggers for a Rule

A user’s visit to an SPA typically begins with a single browser page load event. Every subsequent view of the SPA is triggered in a way that the browser does not detect a page load.

Launch allows you to specify multiple triggers for a rule. This allows you to manage one rule containing multiple actions that should be triggered when any of several events are detected . One example would be to trigger a rule at Library Load OR on any History Changes.

2) Send Analytics Beacon is an Action that you control

In DTM, if you use the Analytics tool, an Adobe Analytics beacon is sent with every browser Page Load. Anyone that wanted to suppress that beacon was forced to use a variety of workarounds.

Additionally, in DTM, Direct Call Rules and Event-based Rules have a 1:1 relationship with beacons being fired. If you trigger one of those rules, a beacon is fired.

In Launch, the Send Beacon action for Adobe Analytics is a discreet action that is only taken when specified (as defined by Rules). You will not get any Analytics beacons on Page Load, Direct Call, or Event-based Rules unless you specifically add the Analytics — Send Beacon action. This gives you more precise control over data collection, especially in SPAs.

3) Clear Variables Action

When a page is loaded, the Analytics object is instantiated on the page. Any variables you set are persisted on that object until the browser refreshes the page and a new Analytics object is instantiated on that new page.

Within SPAs, this causes problems because you interact with the same object for multiple beacons that need to be sent. Data that was important for one beacon call frequently needs to be cleared before the next beacon call.

This was difficult to manage with custom code in DTM, but in Launch, the Analytics Extension provides a simple Action to clear variables, so you can make sure that there are no issues with unwanted persistence.

4) Conditions on All Rule Types

DTM has 3 different types of rules:

1. Page Load Rules — fires on each new browser page load when the DTM library is loaded
2. Direct Call Rules — fires when you call _satellite.track(“eventName”) with a matching Direct Call Rule looking for “eventName”
3. Event-based Rules — fires when the specified browser event (examples: Clicks and Key Presses) occurs on the specified page elements defined by CSS selectors

In DTM, Page Load Rules and Event-based Rules can define conditions, however, Direct Call Rules are the most commonly used rule type in SPAs. This means that in DTM, unless custom events are used, SPAs can’t make very effective use of conditions.

In Launch, all rules are treated the same. A Page Load can trigger a rule, but so can a direct call or any of the other Events that are defined by any available Extensions. Additionally, all Rules can specify Conditions, Exceptions, and Actions.

This means that developers can tag SPAs with one _satellite.track() call in all the appropriate places and the Launch user can create multiple rules with the same Event, then use Conditions to determine context, like which “page” is selected, and take the appropriate actions.

In Launch, users or developers can also hook into any existing or added custom event types, without adding additional direct call rules throughout an SPA. Since Launch can leverage these existing events, it reduces the work of tagging while providing more flexibility and more precise data collection in your SPA or other dynamic pages. Launch also uses more modern event-detection approaches, see here for details. These custom event types also enable more efficient tagging and more effective data collection when using modern front-end frameworks like React, Angular, Meteor, etc.

5) Rule Ordering

As the number of rules in use increases, it becomes more likely that multiple rules will use the same Event as a trigger. The implementation approach in #4 above would make this happen all of the time.

When multiple rules share a single trigger, it is often important to specify which rule should run first. As an example, if two rules set Analytics variables based on the conditions on the page, and one rule sends a beacon, then the beacon rule should certainly run after the rules that set Analytics variables.

Launch allows you to specify the order of the execution of rules when they share an event. This is a simple priority order so that a rule with Order = 1 runs before a rule with Order = 2, etc.

In this example, 1 will happen first, 5 next, then 10.

If you have been using Launch for a while then this list should not be surprising to you. If you are using DTM and have been delaying your move to Launch because you haven’t been sure how your SPAs will be affected, then I hope that you will consider trying out the suggestions in this list and start your move to Launch today!