Data Persistence: From DTM to Launch

In my previous post, we talked about differences in event detection between DTM and Adobe Experience Platform Launch. Today, let’s talk about differences in data persistence.

First, it’s important to understand when data is persisted in DTM and Launch. The most prominent case we’ll cover is the persistence of data element values. When creating a data element, a user can choose among the following storage durations: Pageview, Session, or Visitor. Regardless of which option has been chosen for the storage duration, every time a data element is used on a website, its value will always be retrieved from the source. Every time. That source can be a JavaScript variable, DOM element, query string parameter, or something else depending on the data element type that was used for the data element.

If the data element value that is retrieved from the source is not null or undefined, the data element value will be used, but the value will also be placed in data element storage (more on this in two shakes of a lamb’s tail). If the data element value is null or undefined, the runtime library will look inside data element storage to determine if a value was previously stored. If a value is found in storage, that value will be used instead of null or undefined. If no value is found in storage, the data element’s default value is used (the default value is configured by the user). This process occurs each time a data element is used.

Fine print: The check for null or undefined described above is applicable to Launch. In DTM, the check is slightly different.

For those who like to take a peek under the hood, here’s the code for this logic in the Launch runtime.

The persistence mechanism for “data element storage” differs between DTM and Launch. Let’s see how they differ.

DTM + cookies: Delicious, but high in fat

Cookies — the web variety — have been around for quite some time. At its core, a cookie is a piece of data that gets passed to the server from a user’s browser on each request. Without cookies, the server would have a really hard time remembering anything about you as you browsed around a website or perhaps left the website and came back some time later. For example, you would have a really difficult time staying logged in as you browsed through social media, because the server would lose track of who you are.

Unfortunately, cookies have some fairly significant downsides for uses cases like DTM:

  1. Cookies are sent on every request, assuming the domain, path and other parameters match those defined in the cookie. This means every HTML request, every image request, every script request, every AJAX request, and so on.
  2. Cookies have a maximum size of roughly 4KB (depending on the browser) and there’s a limit on the number cookies that can be stored per domain. Customers have run into these limits, which can lead to unexpected behavior.

DTM leverages cookies for persistence. Here’s how DTM persists data element values for each data element storage duration:

  • Pageview: Data element values are held in a JavaScript variable inside the library. If the user navigates to a new page or refreshes the page, the value is discarded.
  • Session: Data element values are persisted to a cookie with no expires directive. When the browser is closed, the value is discarded.
  • Visitor: Data element values are persisted to a cookie with an expires directive two years in the future. The value will ideally persist for two years and then be discarded.

Launch + Web Storage: Even the kids will enjoy it

With Launch, it was out with the old and in with the new. Support for old browsers was dropped, allowing Launch to target browsers that fully support Web Storage (Session Storage and Local Storage). Web Storage was designed for the Launch use case: persisting client-only data on the user’s device.

Unlike cookies, Web Storage data does not get passed to the server unless you actively pull the data out of storage and send it. It also has a much higher size limit of 5MB (again, depending on the browser) and theoretically an unlimited number of items. These are great qualities for persisting data in Launch.

Here’s how Launch persists data element values for each data element storage duration:

  • Pageview: Data element values are held in a JavaScript variable inside the library. If the user navigates to a new page or refreshes the page, the value is discarded.
  • Session: Data element values are persisted to Session Storage. When the browser tab is closed, the value is discarded.
  • Visitor: Data element values are persisted to Local Storage. The value will be persisted indefinitely.

Other persisted data

Both DTM and Launch also persist whether debugging is enabled. Debugging can be enabled by running _satellite.setDebug(true); in the browser’s developer console or by using one of the various browser extensions that support DTM or Launch. DTM and Launch store whether debugging is enabled so that as you debug different pages of your website or refresh the page you don’t have to repeatedly turn debugging on.

Both DTM and Launch also persist data for some of the conditions related to visitor tracking:

  • Landing Page
  • New/Returning Visitor
  • Page Views
  • Sessions
  • Time On Site
  • Traffic Source

In Launch, these condition types are provided by the Core extension.

The underlying data that powers the above functionality has all moved from cookies to Web Storage.

Where does Launch store data in Web Storage?

You can find contents of Web Storage using the developer tools in any of the major browsers. In Chrome, you’ll find Web Storage under the Application tab. In Firefox and Safari, you’ll find it under the Storage tab. In Edge, you’ll find it under the Resource Picker.

Each data item in Web Storage consists of a key (or name) and a value. Every data element value that Launch stores has a key that begins with com.adobe.reactor.dataElements.. The flag noting whether debugging is enabled can be found with the com.adobe.reactor.debug key. Data items related to the visitor tracking conditions have a key that begins with com.adobe.reactor.core.visitorTracking..

What’s “reactor” all about, you ask? It was Launch’s code name before our branding department blessed the name “Launch.” We continue to use it inside our technical bits so that it’s divorced from any potential branding changes.

Cookies vs. Web Storage: Other notable differences

When making the move from cookies to Web Storage, there are a couple additional differences to keep in mind:

  • While there is some flexibility in declaring the scope of a cookie (e.g., which subdomains may access it), Web Storage is always scoped to the combination of protocol, hostname, and port number (as defined in the same-origin policy) of the page the user is currently on. In other words, the Web Storage for one subdomain is separate from that of another subdomain. The Web Storage for a site delivered over HTTPS is separate from that of a site delivered over HTTP (another reason to always redirect HTTP URLs to HTTPS).
  • Session cookies (cookies without an expires directive) are accessible across browser tabs and live as long as the browser stays open. Meanwhile, Session Storage data is scoped to the browser tab and lives as long as the browser tab stays open.

We hope you enjoy the new and improved data persistence in Launch! 🚀