Multiple custom variables

Google Analytics for mobile!

Mobile Apps tracking seems not related to Drupal, see http://code.google.com/intl/en/apis/analytics/docs/tracking/mobileAppsTr.... It's more for Apps on Phones...

Multiple custom variables sounds very helpful and promising...

Ah, ok. Lets split this in two issues, please.

Google Analytics for Mobile should not be implemented on the pages which already have ga.js. See known issues in the readme.pdf

More important, GA for Mobile adds server load, therefor, it should be used only on the pages that are for mobile access/traffic. Otherwise, too much overhead.

Having said that, it's very hard for GA module to decide whether to generate ga.js or to include php.snippet on a specific page, since GA module won't know how a page is accessed.

But, we have Services Module, which is used for mobile and flash access. It would make much sense, if GA module could develop a Services include, so the Services Module could call GA for Mobile.

We can use the browser detect module (cannot remember the module name) and only use the mobile GA tracking in such a case. I'm often surfing on sites with my iPhone and I think there are good reasons not to limit this to directories... Never thought much about this yet, but at least the iPhone shouldn't have issues and require a real change to logic. Not 100% sure, but it sounds like this only stops downloading of the JS stuff and that's it. This wouldn't add much more load the ga module as today.

We should nevertheless split this in a new case. This one here for the setVar stuff (we need a patch), and the other case for implementing the (optional) mobile feature.

I'm really asking me who is using a browser that is not able to use javascript... iPhone, Windows Mobile can execute JavaScript. Not sure about Blackberries, but they should also work or the internet on mobile devices makes really no sense... many years the mobile phone manufacturers thought they can get us on to bad WAP bad stuff... but the customers haven't used it - why should we waste time for a feature used by 0.000001% (I may have missed a few more zeros) of the internet users???

All browsers on modern phones support JS; GA for Mobile is developed for service based application or other cloud computing sites; the remote client access those remote services Not through browsers, therefore javascript won't be executed. That's where the GA for Mobile should come in and shift the burden to the server. As I proposed earlier, it would make more sense, if GA module could make a GA for Mobile include file for Drupal Services Module.

This is not logic. Cloud sh** or not the JS ga tracking works. I do not see any real world drupal example...

Hi,

This thread seems to have gone off topic a bit but to bring it back to multiple variable support...

Does anyone know if there are any plans to add support for _setCustomVar? I've seen a number of requests for adding hooks to provide more flexibility to the current _setVar implementation. I think with _setCustomVar it's essential that it's hook based - I can't see that the "one size fits all" approach currently employed for _setVar will ever work for _setCustomVar.

I need this new feature fairly quickly. Would there be any interest in me providing a patch to add support for this? If nothing else at least it might start the ball rolling....

Hi idontknowtheanswer,

A patch to start the ball rolling on Custom Variables support for GA sounds great.

I'm not sure which variables you were thinking of tracking.

Reading this page by google:
http://code.google.com/apis/analytics/docs/tracking/gaTrackingCustomVari...

Some Potentials i can think of are:

"Page-level Custom Variables" would fit well as Taxonomy of the drupal node being viewed.

"Visitor-level Custom Variables" could parrallel user role.

As a convention i'd suggest maybe making the custom variable name the same as the drupal database table name for consistency across installations.

So the role variable would look something like this when triggered:

pageTracker._setCustomVar(
2,
"role",
"anonymous user",
3
);

You'd want to loop through the role table to pick up all potential custom user defined roles.

Just brainstorming pseudo code. Hope someone gets round to this one as it will be powerful. (if not i hope to soon myself.)

This may be some good ideas, Thank you for sharing them.

Non of the custom variables seems to work out of the box only by pushing the data to google if I have read the docs correctly. This would be a major issue with Custom Variables as the user needs to configure Google Analyics (on google.com) in such a fine grained way only to get this working that I do expect hundreds of thousands of support requests in here... If we get this in, we need to write a very detailed documentation how to configure Google before a release having this features.

It's comparable to how many people followed the Google tracking code documentation and tried to enter the standard GA code to the advanced JS script boxes in past. The requests have dropped to 0 after I've added some basic form validation to catch this.

We need to brainstorm about a list of what to track before we start implementing.

1. Tracking taxonomy terms sounds like a great idea to me. I also need this myself, too.

I'm thinking about implementing Google's new custom variables like this:

1. Adding the appropriate code to the "Custom JavaScript code" section ("Code snippet: before") of admin/settings/googleanalytics - something like:

pageTracker._setCustomVar(1, "variable1", Drupal.settings.custom_module.variable1,  1);
pageTracker._setCustomVar(1, "variable2", Drupal.settings.custom_module.variable2,  1);

2. Writing a small custom module that will set the values of variable1 and variable2 using the drupal_add_js() function.

Does this seem like a reasonable plan?

-mike

+1

subscribe

re #15, i think a simple table in the setting page will do the job, as GA only allow 5 custom var per page

also, that table need token support, to pop taxonomy there, if applicable.

did a patch

need review state

At least uninstall is missing and t() strings need to use placeholders. I have not reviewed the logic.

uninstall added. t() placeholder added

Has anyone successfully sent taxonomy data from node hits to Google Analytics with this patch?

re #22
you have to set correct token in GA module settings in advance settings -> custom variables

i use sth like vocab:test as name, value as [term]

make sure you have token module installed.

i have further tested on my blogging site, which custom var works with only node pages, but only top term due to token limitation.

if you need all taxonomy listed in custom var, you may look at http://drupal.org/node/185446 for token workaround. (untested)

Subscribing.

re #26, thx for the catch

There are many code style issues, bugs in t() function and drupal_to_js is missing and missing periods in sentences.

coding style passed coder module.
t() fixed, periods, too.

what do you mean by "drupal_to_js is missing"?

Ok, code style looks better, but don't use double qoutes in t() if not required.

You allow users to input some values. This values are added to the page content without being filtered for arbitrary code. Only add a double quote to such a value and you will end up with js errors. Drupal_to_js prevent this and surround the code with double qoutes...

Does the code apply to D7 1.x, too? We also need a patch for the async version 6.x-3.x (not avaiable yet)

Example that allows code injection (security bug):

+        else {
+          $custom_var .= 'pageTracker._setCustomVar('. $i .',"'. $custom_var_i .'","'. variable_get('googleanalytics_custom_var_'. $i .'_value', '') .'",'. variable_get('googleanalytics_custom_var_'. $i .'_scope', '') .');';
+        }

Secure code with filtered user input:

$custom_var .= 'pageTracker._setCustomVar('. $i .', '. drupal_to_js($custom_var_i) .', '...

lucky you provide example...
t("") fixed.
drupal_to_js() fixed

p.s. this time netbeans is used to create patch, let me know if the format does errors

There seems to be a collision problem... as setVar() is deprecated. Therefore we also need to use the _setCustomVar() for segmentation tracking. There is also a request in #378550: Segmentation by Organic Groups for OG. If I understood this _setCustomVar() correctly, we may loose the first two "slots" for this features and we can use max 5 per request..

pageTracker._setCustomVar(1, "Segmentation", "Foo, bar", 1); 
pageTracker._setCustomVar(2, "OG Groups",  "group1, group2, group3", 1);

On sites where we do not have OG installed we only loose one slot, with OG we loose two slots... as more modules as we get as fewer slots are available for custom code snippets and this could also be dynamic... not sure how we should solve this with the above static configuration.

Any ideas?

dynamic configuration still cannot solve the "5 slot limit" problem?

i think we can provide api to other modules, but the api can only warn user if system need more than 5 slots, and thus ask user to disable some?

and i do not know how OG will make use of custom vars, but custom vars mainly focus on user related vars, otherwise, event tracking should be used. http://code.google.com/intl/zh-TW/apis/analytics/docs/tracking/gaTrackin... (in recommended practices)

Subscribe

Subscribe

Fixed Unix LF's and the wrong path's in the patch.

@joetsuihk: #35, OG group memberships are used based. The implementation idea provides a list of the users group membership. By this statistics you can gain the popularity of groups... :-)

I do not plan to commit code to 2.x. Needs an API upgrade for D6 3.x and D7.

How bad that there is a 64-byte character limit for the name and value combined. Not sure if we need to cut off or Google does it. I guess it could have something to do woth the URL lenght... :-(

I'm considering using this, so I've updated the patch for the 6.x-3.x branch. I didn't see #42 and #43 until just now--I'll update my version of the patch with those things in mind shortly.

I have added a patch to #916314: Segmentation requires Custom variables update that needs reviews very soon. Would be great to see you there, too.

I've updated my patch to reflect #42 and #43, and re-rolled it against DRUPAL-6--3. In summary, this patch adds:

• adds administration features to configure custom variables, with token support
• encodes and sets google analytics variables using "setCustomVar" within gooleanalytics_footer()

Do you think this we can get this into the module? Would it help if I also provide a D7 patch?

subscribe

Nothing goes in before there exists a D7 patch.

+    $form['advanced']['custom_var']['#description'] .= t("<p>If you install the !token module, you can use Tokens as custom variable values.</p>", array('!token' => l('Token', 'http://drupal.org/project/token')));

Never use P inside translatable strings and never use l() to for placeholders.

@hass -- Here's a fresh patch for Drupal 6, and a new one for Drupal 7. I've fixed instances where I used <p> inside of t(), and where I used l() in placeholders. I've also updated the token_replace() call so that it provides global and user tokens as well as node tokens.

@jmesam -- Token in Drupal 6 won't remove empty tokens, but token_replace() in Drupal 7 does provide an option to clear empty tokens, which I am now using in the D7 version of this patch.

TW urls are not really usefull for non TW people... For labels, uppercase first word and all other words lowercase, please.

Marked #378550: Segmentation by Organic Groups as a duplicate of this issue.

Also marked #916314: Segmentation requires Custom variables update as duplicate as we need to upgrade the profiles segmentation with _setCustomVar() as per Googles recommendation. Case #916314: Segmentation requires Custom variables update has a patch where we can use parts of it for an upgrade hook if profile segmentation is already configured.

subscribing

#51: ga_custom_var-d7-609892-51.patch queued for re-testing.

Currently working on a better user interface...

Can someone shed some light on me please, how the custom variable feature make any sense without having tokens module installed?

Need feedback for #1012190: Extend token API to support flag for personally identifying information

We also need #1012202: Add 'Roles' token like [current-user:roles] and [user:roles].

Removed

Here is an updated D7 patch. It adds:

1. An user interface based on a table (*important* usability impovement)
2. Input validation if a value in name/value field is missing
3. Input validation now blocks illegal tokens with personal identifying information (may need improvement and testing)
4. Only one setting variable for all custom variables (less DB stress)
5. A few textual improvements.
6. Other minor code style issues fixed.
7. Added token tree view
8. Added DEPRECATED comment to segmentation (segmentation will be removed, after the open to-do's are solved)

Open to-do's:
1. #1012202: Add 'Roles' token like [current-user:roles] and [user:roles] has been confirmed not to be available (will currently break upgrade path for very many people). May add googleanalytics:user:roles and googleanalytics:current-user:roles tokens to GA module to archive the goal.
2. Implement an upgrade path for "User roles" to custom variables
3. Profile module is deprecated in D7, #691078: Field tokens needs testing

Created a tokens file with [user:roles] and [current-user:roles].

Solved the remaining issues. This patch is really big and does not remove profile segmentation stuff for now.

1. Upgrade path implemented
2. Google Analytics module provides [user:roles] and [current-user:roles] with comma separated item list.

This patch also removes the profile segmentation UI if not in use.

Committed to D7, thank you very much for your help.

Follow up in #1017384: Fix use of token_replace()

D6 patch attached. This also requires an additional upgrade path patch for D7 update_7000.

Missed the readme and an token check in update hook.

This needs fixes to token handling. Because the token replacement only replaces node + global token types, the use of array('all') is incorrect here.

Well, I also am not sure exactly what happened here. Looks like token support was turned optional, but the code is pretty ugly. :/

I don't like the how, too. Have not found a clean way yet without depending ga on token. I'm open minded to better ideas and fighting with me for 2 days if i make ga dependent on token to cleanup the code, but many people may not need custom variables... Not sure where to go

Why can i not use 'all' in the form validation? I may like to validate all tokens and not only node tokens??? I'm confused about the parameter...

You can't use array('all') because that will show all token types including comments, taxonomy terms, vocabularies, etc. plus the global token types. But you're only performing token replacement with array('node' => $node). So you're not providing a comment object, or a term object, or a vocabulary object (which is correct), so therefore those types of tokens won't be able to be replaced.

@Dave: For save validation of the custom variable values I need token module. This code is ugly, but if you know a better way I'm very open minded. The bad is if '#element_validate' => array('token_element_validate', 'googleanalytics_token_element_validate'), is used in a form element and the token module is not installed it throws me a 'token_element_validate' function not found error on form save. My ugly code in D7 works fine, but for D6 it is much more ugly as core does not have token_scan() function and I need to run two different validation ways or duplicate token_scan().

At least D6 element validation is horrible. Two different validation ways... D6 code has not yet committed. However if you have a better/cleaner idea for element validation without token installed - let me know, please!

Simple

  $form['myelement'] = array(
    '#type' => 'textfield',
    '#element_validate' => array('mymodule_function'),
  );

  if (module_exists('token')) {
    $form['myelement']['#element_validate'][] = 'token_element_validate';
  }

D6 code has not yet committed

Huh?

Yeah, this looks cleaner :-)

I mean the much more ugly D6 code has not committed. I will post here if it's ready.

Ah, I thought you were referring to the Token module for D6 code. :)

@Dave: This is the D6 patch and it validates with two logics the same values. The used logic depends on token enabled/disabled. Only for the reason that token_scan() is not available if token is not installed in D6. I dislike it, but it seems to be the only way to make sure nobody can circumvent the validation process.