Adobe Launch — sessionStorage?
I came across a question on the Adobe Experience League community forum where user “chischa” wanted to know how to: Grab a query string parameter, stash it in browser storage, then pick it up to include as a parameter on a marketing beacon on their order confirmation page. At first, I thought, “Easy. Just create a data element that grabs the parameter value from the URL, tell Launch to remember it for the rest of the session, and be done with it.” That’s when things went off the rails.
In chischa’s case, the order confirmation page was on a different subdomain from the main site. Because of this, when they referenced the data element, it was empty. There was no value. Back on the main site, though, the data element returned what they wanted.
Why did that happen? Is this not possible with Launch?
It turns out that Adobe Launch uses the browser’s sessionStorage feature to store data elements configured with “session” storage duration. And, if you know anything about sessionStorage, you know that it’s loyal to the subdomain it lives on.
Unfortunately, Adobe Launch’s view on this is simply: You can have any storage you want, so long as you want sessionStorage. But if I want to use a cookie instead? No dice.
Well, this post offers a way around this sessionStorage limitation. It’s not pretty. It’s not ideal. But, it does work. Here’s the solution I offered up to chischa. (Note that the query parameter name we were working with is “ex_id”.):
You’ll need to create TWO separate data elements:
1. The first data element pulls the value from the query parameter. For the sake of conversation, let’s name it “qsp:ex_id” and set storage duration to “None”
2. The second data element uses custom code to reference the the “qsp:ex_id” data element, set a cookie on your root domain (.example.com), and return the query param value. For the sake of this conversation, name it “cookie:ex_id”. Use the code from the above GitHub link for this data element.
This example sets a cookie with session expiration, and should be accessible across subdomains.
Once both are created, make sure to reference the “cookie:ex_id” data element on load of every page. If you don’t, the code won’t execute, and the cookie will not be created. (You don’t have to use the information, but you have to execute the logic. In my testing, I just triggered a _satellite.getVar(“cookie:ex_id”) in a rule that fires on load of every page.)
To populate the parameter on your marketing tag, just reference the “cookie:ex_id” data element...
That was it. It seems like an unnecessary workaround, but it works. The custom logic is minimal, and we’re able to leverage the power of cookies over sessionStorage to persist information across subdomains.
What do you think about the solution? Best you’ve ever seen? Laughable? Something in between?
