Tracking based on user and role specific settings

If I check "authenticated user," does that include all user-defined roles (because all users with user-defined roles are authenticated)?

Currently, yes.

I'm going to write a patch that will work completely the same like blocks visibility and add consistency with core and hopefully remove some confusion.

Yep

Here are the patchs for D5 and D6 testing.

Marking this case critical as this code should go in before the next release.

Here are new patches for upgrading missing roles tracking.

Hm, I am not sure what's the use case behind pushing in a user setting for user profile pages, except that it allows you to implement uid 1 inclusion and exclusion in a different way. Why would people set their own tracking options? Otherwise the new setting based on a single variable with a role list sounds much better then the custom variables used now.

We have had some reports that people like to not track users... and finally i really tried to rebuild the block visibility logic to remove the confusion that seems to be there today. It looked much cleaner to follow the core way then doing something else that makes people asking how it works...

We get an edge case feature with the user specific setting and I'm with you why a users should be able to opt out them self, but I'm sure it is useful on the end of the day. I never understood why admin (user 1) should have a special user setting and other users should not. Maybe you have some users with admin permission and they shouldn't be tracked, too. Sounds not wrong to me and therefor i limited this user settings with a extra permission for more edge cases.

I never understood why admin (user 1) should have a special user setting and other users should not. Maybe you have some users with admin permission and they shouldn't be tracked, too.

Well, those admins would definitely have a user role for them. I think this user 1 setting was just for smaller sites, where people are lazy to set up a user role for admins, since they would be the only admin as uid 1. I think less features are useful, so I'd rather see the user 1 special case go then a complete new permission and feature set get in for people to opt-in or out of tracking (unless of course this was requested or there is a good use case for it). Anyway, this is just my opinion, and it is in no way direction setting if you disagree :)

Visibility priority:

1. URL match have the highest priority at all and will overrule role and user settings. If you don't get TRUE here, code is not added to the current page. Otherwise we are not able to archive what this setting is for... limiting visibility on some paths.

2. Additional role visibility must give TRUE to get the tracking code, if FALSE no code is added.

3. Additional user visibility rely on roles visibility. If the user is not in a role that should be tracked the tracking code isn't added. Additional the user cannot opt-in to tracking in such a case. Otherwise the user is able to overrule it's own visibility and set it to FALSE nevertheless one of his role should be tracked.

I'm not 100% sure, but this is how blocks visibility seems to work and took me some good time to figure out. I hope there is no bug in the roles function, but this is why I'd like to get someone else on the tests.

Clarification needed. Does checking "authenticated user" in the "Add tracking for specific roles" track all authenticated users, no matter if that user belongs to a role that is unchecked?

I thought, based on this discussion, that by checking anonymous and authenticated users on the settings page and leaving the other roles unchecked, I would get what I need. But I just checked the view source and the google script is included for any authenticated user, even for the roles that I don't want it to track.

I'm using the May 7 dev version. Do I need to apply the patch to the 1.4 release?

Or am I misunderstanding something.

Thanks for all the hard work on this important module.

Shai

Well, how it works is that if the user has any of the roles you set up, it will have tracking. If you mark anonymous and authenticated, that covers all users. If it would only track users who have all the roles checked, then your setting would not track any users, since there is no user who has both anonymous and authenticated roles set. This indeed needs a note to be clear: "If a user has any of the roles checked, that user will be tracked." or something along these lines IMHO.

Gabor, thanks for responding.

The problem is that the module now doesn't have the ability to deal with what I would consider to be a very typical use-case, especially for a small organization or business:

The use case is:

* site tries to recruit authenticated user-base, for commenting etc.
* site has staff user roles. Those users are quite active on site, can skew stats, and shouldn't be counted by GA.

Google 1.3 handled this quite easily.

It seems the workaround for me will be to create a new role like "regular user." Anyone who signs up on the site will be automatically assigned that role. Then I can have "authenticated user" and "staff" unchecked and have "anonymous" and "regular user" checked.

If you anyone has a better idea, do tell!

We made this to be 100% in sync with blocks visibility logic...

One workaround is to build a PHP snippet for this functionality and another one your "regular user" idea above. The PHP feature was not possible in past, but it is now - for the advanced users with special requirements like you... We could add the above comment from Gabor for clarification into the roles description text, but I hoped to reuse the core description text here! Blocks configuration doesn't clarify this too - why should we do this here?

Additional we should provide an example PHP snippet for your typical case.

I'm using the May 7 dev version. Do I need to apply the patch to the 1.4 release?

No, simply use the latest dev

Hass,

We made this to be 100% in sync with blocks visibility logic...

Good work. Helps Drupal usability all around.

Blocks configuration doesn't clarify this too - why should we do this here?

Flip that logic... Assuming you use help language suggested by Gabor for g-a , you should submit it as a patch to Drupal. It's confusing to folks in the blocks context as well, let's make that better.

Here is a php code snippet that can be used with the new php enabled visibility settings you've awesomely created for google_analytics 1.4. This snippet returns the module functionality to the old logic (designating roles to opt-out instead of designating roles to opt-in). The code comes (slightly modified) from the section, "Don't show block set of roles" on the Overview Approach to Block Visibility page of the Drupal handbook.

<?php
global $user;
// These are the roles that should not get the Google Analytics tracker code on pages they visit. Replace 'staff' etc. with your own roles you want to opt out.
$hide_ga = array('staff','webmaster','editor');

// Assume all roles will have Google Analytics code.
$show_ga=TRUE;

// Check the user to see if she is assigned a role which is in the hide_ga array. If so, set show_ga to FALSE.
foreach($user->roles as $role){
  if(in_array($role, $hide_ga)) {
    $show_ga=FALSE;
  }
}

// If no roles were hit that aren't allowed to embed the GA code, this will still be true. Otherwise it will be false.
return $show_ga;
?>

Shai
content2zero

I've submitted a documentation patch to the README.txt file that deals with these issues. It's:

http://drupal.org/node/258981

Shai

Your above example does not add the standard path filter... this is very risky for privacy...

Hass, re:

Your above example does not add the standard path filter... this is very risky for privacy...

Can you point me in a direction on this so that I can upgrade that snippet -- and maybe even update the original snippet that I adapted. I don't believe I know what you are referring to.

Thanks,

Shai

Check out the logic inside function _googleanalytics_visibility_pages(). The match_path is one important change in the next release. It gives you the ability to remove the tracking from your node edit pages, admin and so on and so on. Hope this helps.

I have added the text If a user has any of the roles checked, that user will be tracked. to the roles settings description.

Yes, we follow the block visibility logic. See #260367: Roles Opt-Out Sample PHP Script With Path Settings Functionality Preserved how to change the logic with a custom PHP snippet to what you'd like to achieve.

I was just wondering why we would not simply put the same kind of setting as for the blocks; just propose people to select the way the criteria applies, either "Do not track all the roles below" or "Track only the roles below", hell you could even add a textarea to put some PHP code for people who may want to filter things in a bit more complex way.

If that sounds reasonable, I can write a quick patch.

The visibility work 100% the same way how blocks. There is nothing to do!

Hi hass,

What I meant was; for the role settings, not the page visibility, you could have as well a radio menu preceding the set of checkbox that allows you to define how you want to handle these roles, something along the lines of:

* Add tracking for these specific roles only
* Add tracking for every role except the following specific roles

Allowing you to define roles that should have tracking but also roles that should not. The most common problem I have when using GA is that I want to be able to avoid tracking for admin/webmaster users, by having the choice I just described I could do so.

Compare with blocks visibility. GA works 100% this way. For admin/webmasters see #548290: Disable analytics code for administrator