Custom Variables, Part III: Slots/
July 23, 2010
This is the third post (at long last) in a series about custom variables. We’ve already written about why to use custom variables and how the code works. This last part is about a subtlety of how custom variables operate called “slots”.
Slots and Scope
You’ll remember from Part II that the “slot” or “index” is the first argument in the _setCustomVar function, and we glossed over it at the time because it deserved a whole post of its own.
You can think of the slots like little mailboxes to Google Analytics. You write the name/value pair on a slip of paper and stuff it in the hole, and the Google Analytics mailman pulls it out the other side and notes down the value. There are 5 slots, numbered 1-5, and each slot can only hold one slip of paper at a time.
“So,” you might say, “that means I can have 5 custom variables, right?”
Well, not exactly, because remember each variable has a scope: visitor-, session-, or page-level. Each one of these works slightly differently.
With a page-level variable, the Google Analytics mailman takes the slips of paper out of the box on every page. The boxes are empty again, and available for you to put another slip of paper in on the next page.
With a session-level variable, the Google Analytics mailman takes the slips of paper out of the box at the end of a visit. You are allowed to put a new piece of paper in the slot, but you have to throw the old slip away first.
With a visitor-level variable, the Google Analytics mailman takes the slip out, writes down the value, and puts the slip back in the box (it stays in the __utmv cookie). Again, you can put a new piece of paper in, but you have to throw the old slip away first.
In any slot, the last value recorded wins.
OK, that was a nice story. Just the executive summary, please.
So what’s the upshot here?
- You can reuse a slot on different pages for a page-level variable.
- If you reuse a slot for a session- or visitor-level variable, the last value wins. So make sure you really, truly want to overwrite the slot when you’re doing this. Sometimes this makes sense (someone changes status from “member=gold” to a “member=platinum”). Mostly, you want to dedicate a slot to each mutually exclusive session- or visitor-level variable.
- You should always put variables with the same key in the same slot. You don’t want “member=gold” appearing in 2 different slots, or worse yet, “member=gold” in slot 1 and “member=platinum” in slot 2.
- The most important lesson is that managing the way the variables is stored is up to you. If you have a complicated situation with lots of variables, make sure you create a chart of slots and scopes to keep track of it all.
Knowing the slots
Being aware of the slots is important, even if you throw this over the fence to your developer and assume they can sort it out. The reason that slots are important is that, to use a custom variable in an Advanced Segment (or in cross-segmentation in reports, or Custom Reports), you need to know what the slot is:
The Google Code site has some fairly good documentation on custom variables. But the very best thing you can do is watch this webinar in which Phil Mui (the product manager for Google Analytics) walks through exactly how these things work. Straight from Phil to you; it doesn’t get better than that when you want to know something about how GA works.