Question

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?

Answer 1

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.

https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingCustomVariables#usage

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.

PS

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.