If the data element value that is retrieved from the source is not
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
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
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
undefineddescribed 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 use cases like DTM:
- 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.
- 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:
- Session: Data element values are persisted to a cookie with no
expiresdirective. When the browser is closed, the value is discarded.
- Visitor: Data element values are persisted to a cookie with an
expiresdirective 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:
- 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
- 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
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
expiresdirective) 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! 🚀