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!
Let’s load the test page:
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:
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:
So now I know. And so do you.
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?
The answer is no, it does not work. I can not set the value of a DE using
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!
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”
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).
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.
That is true. But if we never began to use it and clairify it to the visitor, nothing will change.
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.
It can be done with the proper approach by using iframes. You even can share itemstorage across domains easily.
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.
So using _satellite.setVar(), is it possible to tell it to remember this value for the session?
No, unfortunately not.
I’d go with Jim Gordon’s DTM Cheat Sheet” and use
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 ?
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.
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 ?
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?
Thanks for this blog ppost
LikeLiked by 1 person