Closed (works as designed)
Project:
Google Analytics
Version:
5.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
9 May 2007 at 04:18 UTC
Updated:
9 Feb 2008 at 20:54 UTC
Jump to comment: Most recent file
Comments
Comment #1
buddaSee http://drupal.org/node/97191 and http://drupal.org/node/134163
Comment #2
brmassa commentedMike,
A ecommerce tracker should not be in the GA core. it can be a new extra module inside GA project. Ecommerce users and normal users will have the optimized system.
A second option is to create a new project just for a small piece of code. I believe its a waste.
regards,
massa
Comment #3
buddaIts been a while since I've used the ecommerce package. Does something need to be done at their end to expose the cart items on the transaction success page?
Any thoughts on how best to implement it?
Maybe hook_nodeapi() could be used to inject the javascript into the success page?
Comment #4
brmassa commentedMike,
i have a good experience with programming ecommerce module. i created 3 modules related and i oftem help them on patches. its going to need a little intervention on their code, i think. im trying to imagine a way to less invasive, maybe using, yes, nodeapi or form_alter hooks.
cheers,
massa
Comment #5
brmassa commentedMike,
im in a very good progress with integration. im gonna start a testing phase.
note i require the modifications on the code shown on other issues.
regards,
massa
Comment #6
brmassa commentedGuys!
i did it! after some days testing, the ecommerce integration is there! its pretty simple in fact. I did several tests and its capturing transactions fine. I also changed the readme file to warn that the transaction ID from google analytics will not be the same Transaction ID from Drupal/Ecommerce. The reason is the TxnID to GA should be created before the TxnID created by Drupal. GA needs only a unique number, so the module uses a combination of time() and cart_get_id() functions. it works like a breeze.
As long it requires the patchs i did on http://drupal.org/node/134422 and http://drupal.org/node/101509, im gonna post a patch to cover all these. JavaScripts as well. I changed the install file to perform all needed changes on database.
It requires jquery, so its only useful for Drupal 5. I think its possible to port to 4.7.
best regards,
massa
Comment #7
brmassa commentedNow the javascript.
I recommend to use a JavaScript compressor (http://dean.edwards.name/packer) and keep a original version as ga_developer.js or something like this. Since its a small script, it wont get much smaller, but every help is a help.
(rename to googleanalytics.js)
Comment #8
gordon commentedI have taken a quick look at this, and it seems that it records with Analytics no matter what the outcome of the order is.
Shouldn't it only record completed transactions.
Comment #9
brmassa commentedGordon,
you are right! i forgot to post here a modification i wrote on my testing site:
1* textarea is now, of course, hidden.
2* __utmSetTrans(), the function that tell google about the transaction, is called when the "place the order" button is pressed only instead on the page load.
these changes seems to work fine here. i will publish the mod soon.
regards,
massa
Comment #10
brmassa commentedGordon,
one thing should be considered: there is no perfect solution about this tracking, coz GA uses javascript. if you click on "place the order" and some validation fails, GA will consider it as done.
i thought about recording a session variable and only when the page reloads (the "thanks for purchasing with us" page), the transaction would be recorded. but some payment systems delete the session variables to avoid stealing credit card numbers and private data.
GA overwrites data when the transaction id was used before, so might have a good solution here.
for now, the best solution is: submit button having a "onclick:__utmSetTrans();" attribute.
regards,
massa
Comment #11
brmassa commentedGuys,
as promissed, the new patch. Mike, i suggest to commit to dev at least. many users will be needed to test it.
i wont submit the new javascript > the only line changed from last update is the removal of the last line.
regards,
massa
Comment #12
erlendstromsvik commentedHi
I've taken this module and made it compatible with Ubercart so to provide Google Analytics E-commerce tracking.
But wouldn't it be better if the "original" Google Analytics module invoked a hook, which E-Commerce, Ubercart and/or any other commerce-package could implement to insert the needed code for e-commerce tracking?
The only thing need in this module is a _hook-call and just append any output to the $script variable in uc_googleanalytics_footer(). For example hook_googleanalytics()?
I don't see an option in using hook_footer to just append the extra code for e-commerce tracking because this code must be inserted after the tracker code.
Comment #13
buddaWhy can your Ubercart module not just define the GA JS variable in the pages header as inline JavaScript? It doesn't need to be after the Google Analytics function code in the footer as you are just defining a variable to describe the transaction contents.
To make it neater only output the inline JavaScript if the GoogleAnalytics module is installed/activated.
No hooks required then.
Comment #14
johnalbinHi Bruno,
It’s a bad idea to include fixes for several issues in one patch.
Please break up your patch into several smaller patches and post them to the appropriate issues. Thanks!
Comment #15
brmassa commentedJohn,
i know about patches, its because i did it all at once and i dont have time/energy to do it on the right way.
its not that big patch, its possible to study it.
but.. if someone slipt it, fine.
regards,
massa
ps: I already use it on my site.
Comment #16
johnalbinBruno, without a proper patch your work is unlikely to be committed and you’ll have to re-write your customized-GA module each time the code base changes; it’s a waste of your time to write a patch that has no chance of being committed. It’s ultimately easier for you (and less time consuming in the long run) to provide proper patches from the beginning.
Comment #17
buddaIs my suggestion in comment #13 a possible solution to this for uber and ec? or am i barking up the wrong tree here?
Comment #18
hass commentedSubscribing, i think #13 sounds like a good idea, but does not prevent duplicate variable names - what might cause some side effects in special situations.
Comment #19
hass commentedNo activity / feedback for more then one month - closing as the maintainers think it doesn't need to be fixed by the GA module them self.