DTM – Data Elements that persist

Who here can explain to me what exactly it means to set the “Remember this value for” setting of a Data Element in DTM to anything else but “Page View”?

I can confidently tell you that right now, I have no idea.

Which is of course a perfect excuse to a) find out and b) blog about it.


Rather than just walking up to one of my DTM-savvy colleagues and asking them, I prefer the “let’s hit this thumb with a hammer and see if it hurts approach” as shown in xkcd’s The Difference strip.

So here’s my theory: maybe setting “Remember this value for” to “Session” or “Visitor” means that wherever it gets its value from, it’ll retain that value for the remainder of the session or forever? That the DE will not even check again in that time frame and just play back the latest value? Or maybe that it does check, but if the check returns empty, the DE returns the cached value?

Having theories is great. It means I can now plan experiments to prove those right or wrong! We’re doing science here, people!

What do I need?


  • I need a Data Element, of course
  • I need to query that DE once, because that’s what will set it. (The way DEs work. The value is calculated when the DE is used.)
  • I need to be able to see what the DE did, when I queried it. Did it calculate it’s value or not?
  • I need a second query to the DE. This second time will answer my question “does it calculate the value again or not?”

The easiest way of doing that might be a DE set to “session”, then using the console in Chrome and query it manually. Let’s do it!

Setup of our Test Data Element
The Data Element is configured to get its value from a Javascript object. I have not defined that JS object on my site at all.

Let’s load the test page:

First Test – Overwrite the Data Element
We can see that the DE behaves just like any DE. The switch to “session” makes no difference here, the DE reads the JS object each time it is queried and delivers the current value. Ok.

Let’s reload the page, killing the JS object:

Second Test – Persistence

We do get a value out of the DE even though the JS object does not support that.

New theory: setting a Data Element to “session” or “visitor” allows the DE to fall back on the last value it determined in situation where getting a value wouldn’t work. How about that?

The obvious question: how?

Well, when you set a DE to anything but “pageview”, DTM stores the last value it got into a cookie named “_sdsat_”, as we can see here:

Value of Data Element in Cookie
So now I know. And so do you.

And setVar()?

Completely separate beast.

Given that I query Data Elements using getVar(), I would sort of expect to be able to set them using setVar(), but does that work?

Third Test – Writing a Data Element
The answer is no, it does not work. I can not set the value of a DE using setVar().

I can, however, set the value of a “custom variable”, that is if I put a name into setVar() that does not exist as a DE, the system will store the value that I provided and hand it back in a corresponding getVar() call. Useful if I want to temporarily store information!

DTM customVars
This does not persist! If you want persistence, write a cookie using the setCookie() method. Jim Gordon’s excellent DTM Cheat Sheet has the syntax.

16 thoughts on “DTM – Data Elements that persist

  1. If you want persistence, write a cookie using the setCookie() method.

    Or use sessionStorage and/or localStorage, where you can save up to 5mb data and stringify JSON and …. 🙂

    I do love sessionStorage and localStorage since i get to know about it a while back. It is much more usefull then cookies are (in my opinion).


    1. Agreed.

      The only issue I have with localStorage and sessionStorage is that “people don’t know about it”, as in, the normal visitor has heard of cookies but not storage. That makes me slightly less transparent when I use storage.

      Minor issue, of course.


    2. The only problems with localStorage/sessionStorage is they do not cross http/https, and they cannot be used across subdomains. This is where cookies have an advantage.


      1. I Adam,

        It can be done with the proper approach by using iframes. You even can share itemstorage across domains easily.


  2. Hi Jan,

    Unfortunately either ‘persistence’ Data Element or _satellite.setCookie() method are not able to store the cookie at a domain level, which makes this functionalities aren’t worth it (as prevent to read the cookies across subdomains). Cookie managing is something that Tag Managers, in general, are not handling properly, reason why we have to develop functions that do it properly.

    I’ve wrote about this in my blog http://bit.ly/24HH9O9, it could help people that are facing with this problem, as I faced back in a days.



    1. No, unfortunately not.

      It works well for passing values into DCRs, but for anything “more durable”, it is better to use cookies.

      I’d go with Jim Gordon’s DTM Cheat Sheet” and use _satellite.setCookie() and _satellite.readCookie() for this.


  3. I created web property for my website and now i want to track the individual user’s details that is, to other which websites user is visiting. How to track that in adobe analytics report? Like amazon follows every user on other website showing Ads related what we searched on website.
    Can you tell me steps to do it ? do i need to maintain cookie for this ?
    if yes how to do it ?
    Thank you


    1. Hi ketan,

      I thought long about answering this, because frankly, the Internet doesn’t work like this at all.

      The only way you can track people on other sites is if that other site allows you to. Google does it by placing ads in lots of places, Amazon probably does it by buying data (google “DMP data management platform”).

      In short: you can’t.



  4. Hi Jan,
    Thanks for sharing this post. It is really informative. However, I still have one question in mind – How can I set the value of a Data Element in the custom code of a Rule. Say for example, I want to reset it, can you please help me understand how that can be done ?

    Thank you,


    1. Hi TJ,

      The somewhat surprising answer is: you don’t.

      Data Elements are not meant to store things, really. Cookies, LocalStorage, or SessionsStorage are good at that. Data Elements are there to make it easy to access data, nothing more.

      So, store the data somewhere, and use a DE to read it.

      Does that make sense?


Leave a Reply to Adam Haining Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.