I'm getting two calls to __utm.gif. I *think* this is happening since the update to 6.x 3.1. I didn't notice this before, but it's possible that this was already happening without me noticing. The two calls each pass different GET parameters to Google, but there seems to be significant overlap in the information they're passing.

You can easily see this web WebKit's inspector or Firefox + Firebug. Or you can see it using webpagetest.org: http://www.webpagetest.org/result/110123_S4_18E1/.

Is this by design? That's quite hard to imagine. If it is, can you please point me to the corresponding docs? If it is not, just let me know what you want me to look up/test for you.

Thanks! :)

P.S.: you've made an impressive sweep through this module's issue queue! :O

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hass’s picture

Can you share a link to the site having this issue, please? I haven't seen such an issue yet...

hass’s picture

Title: Two calls to __utm.gif » Possible double tracking with deprecated profile segmentation, API function _setVar()
Category: support » task
Status: Active » Postponed (maintainer needs more info)

I guess you are talking about driverpacks.net. I've seen you are still using the deprecated profile segmentation tracking...

My tests tonight have shown that an enabled profile tracking cause two calls to __utm.gif. I'm not sure if this will cause double trackings, but I guess it will. I'm not using this feature myself in production - so I cannot speak about the statistic results. I have never noticed this before you opened this case.

I strongly suggest you de-select the user roles tracking (and maybe other profile fields) in the deprecated "profile segmentation" feature and only use the custom variables tracking to make sure _setVar() is no longer used in the tracker. In such a config I see only one utm.gif call on my site. With _setVar() in the tracking code I also see two calls to utm.gif.

I'm guessing, but this may be a bug in Googles Tracking code... I should have better removed the profile stuff with this release and not only named it deprecated... :-(. Google have deprecated the _setVar() in December 2009.

Would be great if you can share information, if you had double trackings with this settings enabled (after you have disabled the the profile segmentation now). It would give me a very good reason to immediately release a new versions with all this profile segmentation stuff removed. I really wish I have noticed this earlier...

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Active

I'm talking about driverpacks.net indeed. Sorry for not mentioning that in the post — i intended to do so, but forgot :/

I tried doing what you said. However, it seems an automatic upgrade path had already been provided: a custom variable for the "User role" tracking had already been set up (see the attached screenshot). Is it possible that *that* is the actual reason for those two calls?

Also, I cannot save the settings form after I've deselected "User role" in the "User segmentation settings". I get the following error:
Fatal error: Call to undefined function token_scan() in /data/www/svn_driverpacks.net/profiles/basic/modules/google_analytics/googleanalytics.admin.inc on line 440

Maybe this is because I'm not using the latest Token version on this site? I can't upgrade to Token 1.13 or upwards (I'm stuck with 1.12) because it breaks my own tokens. I see that the token_scan() call is only used for validation though, so I'm going to upgrade the site briefly to the latest release of Token, then save the Google Analytics settings form, then downgrade back to Token 1.12.

And that worked! The form worked, and now I have only a single call to __utm.gif.

Thanks for the support! And I hope I've answered all your questions. Please let me know if you need me to test anything else!

Wim Leers’s picture

Oops, I forgot to attach the screenshot. Here it is.

hass’s picture

token_scan() is undefined??? I need to check this... But this function should also exists in older versions. The second call comes only from the setVar() profile segmentation call... Nothing else.

hass’s picture

How about fixing the bug? You cannot expect support for stone age versions that are 1.5 years old...

hass’s picture

token-6.x-1.14 seems to be the very first version that adds the required token_scan() function.

hass’s picture

Status: Active » Postponed (maintainer needs more info)

Let us know if the tracking counters have cut in half and set to fixed if not, please.

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Fixed

I know, I'm on an old version of Token. But that's because it breaks the API somehow — I've yet to find the time to figure out why that is.

And yes, as I've said, this fixes the problem of the double tracking counters! :) Thanks again!

hass’s picture

Status: Fixed » Postponed (maintainer needs more info)

Have there really been double tracking in the stats or are you only mean two requests... I'm guessing we only see two requests, but have only +1 on hits.

If not we need a new release with all the profile segmentation removed.

Wim Leers’s picture

How can I check this?

EDIT: I mean, how can I check this reliably? There has been an increase in pageviews recorded by Google Analytics. But it's possible that this was caused by new content on the website (although an increase this sharp seems quite unlikely). So I suspect that everything was indeed being tracked double, but I can't be 100% certain. If you tell me how I can check this, I'll do so.

hass’s picture

Hm... this will be difficult... as we always have a 24 hours delay and you cannot really control your users, Not sure how many hits you have on your site, but if there are 10.000 before the settings change and now you have only 5.000, than I guess we really have an issue.

Maybe someone else can confirm if you do not have enough load... d.o is running the same issue... at least d.o have high traffic and can verify. We only need to find someone with permissions to this stats... but who!?

Wim Leers’s picture

Try contacting killes. He'll most likely have access, or will definitely know who has access if he doesn't.

I don't mind sharing my stats here. I had ± 4k visits/25k pageviews per day before, 4.8k/28k on the day I noticed it (the big jump on the right), but I still have 4.5k/28k on the day afterwards. I didn't clear the Drupal page cache, so it's likely this last day still had quite some page views which triggered two calls to __utm.gif. If the next day drops back to normal levels, I'd say there indeed is this problem.

But, it'd be better if you can verify this by using d.o's stats — at least if they're not even more variable than driverpacks.net's.

hass’s picture

With comment from http://www.google.com/support/forum/p/Google%20Analytics/thread?tid=7fd2... I guess it does not double trackings.

Trying to find more references...

hass’s picture

Title: Possible double tracking with deprecated profile segmentation, API function _setVar() » API function setVar() places a second utm.gif hit to the google analytics server
Category: task » support
Status: Postponed (maintainer needs more info) » Fixed

On http://www.googlelytics.net/using-setvar-_utmsetvarutm_setvar-for-custom... the notes on the use of setVar explains this behavior.

Bounce rate is defined by GA as being a single “hit” to the server but no further “hits” (visitor left site), however, since setVar places a second “hit” to the server, GA automatically assumes that there is no bounce when there actually is one

and:

The data collected through setVar is expressed in visits, in the reports – the tag is applied to the user only once during a visit session.

Wim Leers’s picture

Based on what I said in #13, I think the current stats I'm seeing in Google Analytics support what you are saying :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.