Take the 2-minute tour ×

I use Facebook JSSDK (i.e client-side) to verify who the current user to my web-app is.

Code looks something like this:

    ... inited google analytics ...

       //events *before* authentication
       _gaq.push(['_trackEvent', 'TEST', 'EVENT BEFORE AUTH', 1]);   

       //events *after* attempt at client-side authentication
       // callback might return after, say, 7 seconds
        authenticateUser(function(userInfo) {
             // setting visitor-level custom var
            _gaq.push(['_setCustomVar', 1, 'AUTHED-USER', userInfo, 1]);
            _gaq.push(['_trackEvent', 'TEST', 'EVENT AFTER AUTH', 1]);   

(If you try simulating this, please make sure you run "setCustomVar" quite a while after the first event fires - as you want to give GA "enough time" to already send the first event)

This creates the following "Issues" with tracking events under custom variables:

  1. The response from Facebook, with the user's info might return after other events were already sent to Google Analytics - A visitor-level custom variable seems to "solve this" because it seems like even events that were tracked previously in this session (before the custom var was set) are listed "under" the custom var value (that was set after them).

  2. A different user might use the same browser to use the app. The behaviour of "over-writing" the visitor-level custom variable is problematic - it seems that ALL pre-auth events that were issued from this browser are listed/grouped under the LATEST custom-var value. I tried issuing a _deleteCustomVar call before overwriting - but this did not solve the issue.

To differently "solve" the first issue - I thought of not using a visitor-level custom var (but rather a page/session one) - but this would mean all the pre-auth events would not be listed under the custom var - To solve this I thought to somehow defer all the event-tracking to after the auth has been done - but this seems.. umm.. weird.

Another solution would be to use my own "visitor-cookie". But GA already does that so I am reluctant to re-invent the wheel.. (and also after a user-switch, the visitor's cookie will be "lying" for pre-auth events)

Any suggestions to how to tackle this scenario?

share|improve this question
Notice that sending Personal Identifiable Information to Google Analytics is against their terms of service. –  Eduardo Jun 7 '12 at 3:14
of course - but the above is a problem even if i just log the visitor's gender, user-type etc... –  ayal gelles Jun 7 '12 at 7:07

2 Answers 2

up vote 3 down vote accepted

Maybe a little explanation of each customVar scope will help you.

Visitor Level CV

The visitor level CV will apply to all visits from the moment you set the CV on. If you ever change the CV during a single visit that visit will be listed in GA under the old value, but future visits will have the updated CV.

Session Level CV

The session level CV is only valid in the current session. In a future session it's empty. If you ever change a Session level CV during a visit the value reported in GA is the last one.


The last session-level variable called in a session is the one used for that session. Example: If login=false for slot #1 at the beginning of the session and login=true for slot #1 later on, the session is set to true for login.

Over-rides any previously-set page-level variable called in the same session. Example: If slot #1 is first used for category=sports and then for login=true for a session, category=sports will not be recorded for that session.

Page Level CV

You have to be careful with this one in your case. When you use a Page Level CV never look at visits as a metrics, always use pageviews (or totalEvens if you fire an event immediately after setting the CV).

Which one to use?

Now answering your question. I would first ask myself if there's any reason to believe that multiple users would be using the same browser. I've seen systems that were made for kiosk like computers, and in that case it's a totally valid point. But other than the ammount of users you might have using the same browser might be irrelevant for your metrics.

Even in the case of using the same browser If you use the session level CV it will always be blank until the user sets it, and if he changes it during a visit you will get the lates one which is probably what you want. The only down side of using a session level CV is that if the user never signs-in you will have no CV for that visit.

So if you have any reason to believe that your audience has a good chance of sharing the same browser with multiple users than I'd go with a session level CV. Otherwise I'd keep a user level CV since the value has a low chance of changing and because that way you'd have a CV even if the user decides not to login during a specific visit.


I don't know if the events in your code are just examples but they are wrong. The first 3 arguments in an event are strings, and it seems you're passing 2 strings and an integer.

You definitivelly need an event or pageview after you set a CV, setting a CV doesn't send a hit to GA, so its strictly necessary that you send a hit. If you're sending an event just for the sake of having the CV registered, you better send an event like this:

_gaq.push(['_trackEvent', 'CV', 'set', '', 0, true]); 

this will fire a non-interactive event, and it won't impact metrics like bounce-rate.

share|improve this answer
Thanks for your answer. In most countries the scenario of two (or more) people sharing a browser is still very probable. Though you are right that for most websites having their metrics "grouped" under the same CV shouldn't so much affect the conclusions I draw from my metrics. A session-level CV would not be good enough as any pre-auth event (hence pre-setCV) would not be "grouped" under that CV (try it). My solution is to delete the __utma cookie on page-load and use a visitor-level CV (that does updates all pre-auth events) seems complete. oh yes, the event-label should be a string :) –  ayal gelles Jun 12 '12 at 7:39
I tried it and pageview and events sent before setting the session level CVs are grouped under the last set value for that CV. I edited my post to include a snippet from the docs that explain this and a link. developers.google.com/analytics/devguides/collection/gajs/… –  Eduardo Jun 12 '12 at 7:48
I was just retesting it myself and you are correct - the pre-CV events are indeed grouped under that CV. Now I just have to decide if i want to make the session expire when the app loads. Thank you. –  ayal gelles Jun 12 '12 at 8:41
It's written plainly in your answer, but kind of off-hand, so I would just like to ask again for direct confirmation: If I have a visitor CV (say, CV1="unregistered"), and they visit the site 10 times. Then they register and I set CV1="registered" and they visit the site 10 more times... The first set of hits are not updated? So if I searched for visits from visitors who are registered, I would only get 10 results, even though that registered visitor has visited 20 times? Thanks. –  Ipsquiggle Oct 12 '12 at 22:01
@lpsquiggle - no, I think in both scopes, as long as the scope is valid (i.e for session - until it is over and for visitor - until cookies are deleted) the previous events under that CV will appear under the latest CV value (overwritten). –  ayal gelles Oct 21 '12 at 11:18

So Google thought about this issue but decided this is not so important:


I did find a solution though: to delete the __utma cookie before loading GA.

share|improve this answer
see @Eduardo Cereto 's answer and comments. –  ayal gelles Jun 12 '12 at 8:42

Your Answer


