Jump to content

Google Analytics ecommerce tracking


AlexFL

Recommended Posts

Hello,

the last 10 days i got a problem with google analytics (out of a sudden) it tracks visits and everything correctly but it has stopped track stats around ecommerce (orders, products, etc). I don't recall made any change the day it stopped working (5/12/14).

I made a little research and the only thing i found is that when i make the order on the order-confirmation page i get this error on chrome console tab

Failed to load resource: the server responded with a status of 500 (Internal Server Error) 
http://www.beautyaz.gr/el/module/ganalytics/ajax?orderid=BAZ00011758 

and this some times

GET http://www.beautyaz.gr/el/module/ganalytics/ajax?orderid=BAZ00011796 500 (Internal Server Error)
v_71_b3234a4669ce5cb4decab5687cecf0f9.js:4 

Thank in advance for any response and your time.

  • Like 2
Link to comment
Share on other sites

Got the same exact problem. It seems like the header.tpl is not included - i don't know if it is supposed to be like that in the new update?

 

As far as i remember the only thing that is getting called is GoogleAnalyticEnhancedECommerce.addTransaction("order info here") or something like that. Would this send data to analytics!?

Link to comment
Share on other sites

kermes on this thread http://www.prestashop.com/forums/topic/387238-ganalytics-e-commerce-tracking-202/?p=1900570 have it figured out, the only thing remaining is for presta team to update it and fix the rest of the bugs.

I'm a little disappointed in them, if all the problems kermes listed on his post are true then ganalytics module was POORLY updated and we are speaking for one of the most precious tool for any e-shop especially on holidays.

 

PS this is my temporary "fix" http://www.prestashop.com/forums/topic/388140-google-analytics-ecommerce-tracking/?do=findComment&comment=1900261

Edited by AlexFL (see edit history)
Link to comment
Share on other sites

I've been fixing all the issues I found since the update, you can see a summary and all the fiexd in this post http://www.prestashop.com/forums/topic/387238-ganalytics-e-commerce-tracking-202/?do=findComment&comment=1900570

I will stick with 1.8.2 for now and i will wait for the update and of course the first testings. btw great job on hunting down all of the bugs.

Edited by AlexFL (see edit history)
Link to comment
Share on other sites

In fact i recommend just that, don't upgrade or roll back to the previous release if you upgraded, although all the patches have been already working 2 days in my site and everything seems normal so far.

BTW, if any of you decide to apply the patches or if you decide to roll back to the previous version, remember to uninstall and install again the module to make sure every thing is reseted.

Edited by kermes (see edit history)
  • Like 2
Link to comment
Share on other sites

this is the status of bugs found at this point:


  • [FIXED in 2.0.4] bad controller names resulting in no transactions being recorded
  • [FIXED in 2.0.4] missing one page checkout, only 3 steps checkout are marked as "checkout"
  • [FIXED in 2.0.4] Class not found 500 error, transactions not being marked in prestashop as "sent to analytics"
  • [FIXED in 2.0.4] product footer hook not being executed, so special data from product page, such as price, name... not being sent
  • [TESTING] pageview sent many times (3 times in order confirmation, 2 times in product pages) breaking bounce rate and page/visits stats
  • missing products purchased info in order confirmation
  • missing transaction id in order confirmation
  • [TESTING] product impression missing in categories, new products, best sellers, prices drop and search result
  • not using HookOrderConfirmation so payment modules with its own confirmation controller not being recorded (paypal, some credit cards modules...)
  • [TESTING] click event being sent every time a product is viewed resulting in wrong bounce rate

As you can see, only 4 out of 10 problems found and reported and fixed proposed before 15-dec were solved on 2.0.4, published on 16-dec, and one of those problems is that payment modules with its own controller are not being tracked, but those that use the standard order confirmation are (for example, wire transfer). On 18-dec, 3 other issues were marked as "TESTING", so maybe those will be included in the next release.


 


If you think this is serious, I foud new issues 4 days ago:


  • Whenever you use your backoffice, you are being counted as a visit, breaking your visits stats, time on site, pages per visits...
  • if you get a transaction sent to analytics (because it was, for example a wire transfer), every time you see a page in the backoffice, it is sent again, so you get thousands of transactions)

So, still, my recommendation is not to use the module.


  • Like 1
Link to comment
Share on other sites

Hi everyone,

 

I have/had the same problems. If i check the source code the header.tpl is not used anymore and there is no transaction code on the confirmation page

So i checked whether the module was hooked to the displayTop position, it wasn't cause it used to use the header.tpl

Now at least i see transaction code on the confirmation page, now just waiting for incoming data

 

* To track transactions
*/
public function hookTop()
{
// Add Google Analytics order - Only on Order's confirmation page
Link to comment
Share on other sites

Why kind of clowns are pretending to be Prestashop module programmers. There are bugs in almost every module update causing more problem than what are fixed. I am sure that soon there will be malware added since there is no one in the PS group that validates what is being release.

SHAME ON  YOU PRESTASHOP TEAM for releasing CRAP!!!

  • Like 1
Link to comment
Share on other sites

 

this is the status of bugs found at this point:

  • [FIXED in 2.0.4] bad controller names resulting in no transactions being recorded
  • [FIXED in 2.0.4] missing one page checkout, only 3 steps checkout are marked as "checkout"
  • [FIXED in 2.0.4] Class not found 500 error, transactions not being marked in prestashop as "sent to analytics"
  • [FIXED in 2.0.4] product footer hook not being executed, so special data from product page, such as price, name... not being sent
  • [TESTING] pageview sent many times (3 times in order confirmation, 2 times in product pages) breaking bounce rate and page/visits stats
  • missing products purchased info in order confirmation
  • missing transaction id in order confirmation
  • [TESTING] product impression missing in categories, new products, best sellers, prices drop and search result
  • not using HookOrderConfirmation so payment modules with its own confirmation controller not being recorded (paypal, some credit cards modules...)
  • [TESTING] click event being sent every time a product is viewed resulting in wrong bounce rate

As you can see, only 4 out of 10 problems found and reported and fixed proposed before 15-dec were solved on 2.0.4, published on 16-dec, and one of those problems is that payment modules with its own controller are not being tracked, but those that use the standard order confirmation are (for example, wire transfer). On 18-dec, 3 other issues were marked as "TESTING", so maybe those will be included in the next release.

 

If you think this is serious, I foud new issues 4 days ago:

  • Whenever you use your backoffice, you are being counted as a visit, breaking your visits stats, time on site, pages per visits...
  • if you get a transaction sent to analytics (because it was, for example a wire transfer), every time you see a page in the backoffice, it is sent again, so you get thousands of transactions)

So, still, my recommendation is not to use the module.

 

 

Kudos Kermes!! Great job with this posts and pull requests on GitHub!

 

Personally I am getting back to old module (1.8) after 1 day wasted to make it working. It is astonishing how low quality is delivered by PrestaShop team. 

Link to comment
Share on other sites

Where can I download the previous version? I desperately need a working solution until a fix is pushed.

EDIT: Found it in a previous post in this thread, thanks! :)

 

With these quite common module bugs, Prestashop ought to make an easy way to revert to previous versions.

 

Your answer is on the first page of this thread :)

 

 

as many Prestashop users contacted me to get the previous version i put it on my site you can download the V 1.8.2 here :

 

http://www.ventesites.com/ganalytics.zip

 

Felices fiestas !

 
Link to comment
Share on other sites

The Google Analytics module is working fine.

Just make sure that the Property Settings for your PS store are pointing to the correct URL in Google Analytics.

I had mine configured to look for an http site whereas my site is https. So it did not record any stats until I updated the Property settings to the proper URL. It's working fine now.

  • Like 1
Link to comment
Share on other sites

I wonder how this is possible as for now I am even scared to install module updates.

They seem to bring more and more problems.

 

a few weeks ago same module 

http://www.prestashop.com/forums/topic/386003-ganalytics-module-crash-after-update/

 

If prestashop wants to keep his name they should focus on stability and reliability.

For now it seems again if nothing is tested.

 

It will be a mather of time until malware will be released trough the update system.

 

Prestashop please !!!!! why??

Link to comment
Share on other sites

  • 2 weeks later...

Today a new module update: 2.0.6

 

The ecommerce datas appears again with the 2.0.5 of ganalytics that i tested...BUT, the datas are not correct... i see many wrong transaction on prices for example, for me something doesn't works correctly.... i hope in this new 2.0.6

 

Any other feedback who use ganalytics on PS 1.6 ? Any problems, errors or strange things ?

 

Christopher - www.prestalia.it

Edited by Prestalia (see edit history)
Link to comment
Share on other sites

It does solve a bunch of thouse bugs with wrong data being sent.

That's what was missing from 2.0.5, and they finnally added in 2.0.6

Although it has 2 more known errors that I was hoping they would have solved in 2.0.6 because I already gave the solution to them, as I did with almost every bug since 2.0.2, but I supose we will have to wait to 2.0.7. I also added carrier and payment method tracking and I hope that that will be  added in 2.0.7 too.

Edited by kermes (see edit history)
  • Like 1
Link to comment
Share on other sites

It does solve a bunch of thouse bugs with wrong data being sent.

That's what was missing from 2.0.5, and they finnally added in 2.0.6

Although it has 2 more known errors that I was hoping they would have solved in 2.0.6 because I already gave the solution to them, as I did with almost every bug since 2.0.2, but I supose we will have to wait to 2.0.7. I also added carrier and payment method tracking and I hope that that will be  added in 2.0.7 too.

 

As I can see in GitHub you look like the main dev for this module  ;) thank you a lot for this !

By the way, I have a stupid question, but since there's no doc or manual explaining how to configure properly this module, I ask it to you :

In Google Analytics, do we have to enable the switch called "Enable Enhanced Ecommerce Reporting" ?

 

Again thank you for your great and appreciate work on this module.

Clément

Link to comment
Share on other sites

Clement - Yes, you need to enable enhanced ecommerce so that you can see all data being registered. Note that it needs to be done for each profile.

 

Kermes - kudos for your great work!

 

I have adjusted module code to track user-id. You may want to add it as well to official module distro as it adds a nice functionality :)

My code below:

	private function _getGoogleAnalyticsTag($back_office = false)
	{
		$user_id = null;
		if (in_array($this->context->controller->controller_type, array('front', 'modulefront'))) {
			$user_id = $this->context->customer->isLogged() ? $this->context->customer->id : null;
		}

		$tracking_code =  '
		<script type="text/javascript">
			(window.gaDevIds=window.gaDevIds||[]).push(\'d6YPbH\');
			(function(i,s,o,g,r,a,m){i[\'GoogleAnalyticsObject\']=r;i[r]=i[r]||function(){
			(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
			m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
			})(window,document,\'script\',\'//www.google-analytics.com/analytics.js\',\'ga\');';
		
		if ($user_id) {
			$tracking_code .= 'ga(\'create\', \''.Tools::safeOutput(Configuration::get('GA_ACCOUNT_ID')).'\', {\'userId\': ' . $user_id . '});';
		} else {
			$tracking_code .= 'ga(\'create\', \''.Tools::safeOutput(Configuration::get('GA_ACCOUNT_ID')).'\', \'auto\');'; 
		}
		
		$tracking_code .= $back_office ? 'ga(\'require\', \'ecommerce\');' : '';
		$tracking_code .= 'ga(\'require\', \'ec\');';
		
			
		$tracking_code .= '</script>';
		
		return $tracking_code;
	}

Link to comment
Share on other sites

Thank you both. I started fixing it for my own shop and seeing they were doing nothing to fix the fiasco it was the 2.0.2 release, decided to commit my development. I'm glad every one is beneffiting of my work now.

gloomybear, Thanks for the suggestion, I was already working on something similar, only that userId is not needed to be sent everytime. According to the documentation if you send it only once, analytics will apply that userId to the whole session, so I thought it would be nice to send it when the user logs in and send an event, so we'll also have that action tracked.

Something like this hooked to the login action:

ga('set','&uid','<?php $this->context-customer->id ?>');
ga('send','event','Login Action','login');

I'm currently testing it in my site. If there are no errors after some days, I'll propose the pull request in github.

 

It is not exacty the same and I don't know if analytics would treat the data send with this method and yours the same way. All of this came to my mind when I wanted a better way to track login actions

Edited by kermes (see edit history)
Link to comment
Share on other sites

You are correct, Google specified setting user-id on login page. I did it for every pageview because it was easier to me  and because I use 3-rd party module which creates user account. This implementation allowed me then to track users regardless of how they login and how they create an account.

 

My testing is in progress as well. For now everything seems to work fine.

Link to comment
Share on other sites

×
×
  • Create New...