Integration with Google analytics plugin

-- url of the page with the problem -- : www.artistpapers.co.uk
-- HikaShop version -- : 2.5.0
-- Joomla version -- : 3.4.3

Hi,

I have a problem with the attribution of sales as reported in Google analytics. I am using the Hikashop analytics plugin. All my sales are showing as coming direct (ie not by search or social) with the source being the payment processors website ( paypal or sagepay).

I assume this is because the sale is only reported once the payment is confirmed and that this action is coming from the payment processor, however this is rendering analytics useless as I can't see the real sources of my sales.

There are some settings on the plugin which aren't documented, would any of these affect this issue? Is there a way I can report the correct source of sales?

Many thanks,

Ian

Hi,

It depends on how you configure the Google Analytics plugin and what the client does.

There is basically two ways for HikaShop to notifies GA of a sale:
1. Display some javascript code on a page displayed by the browser of the customer. Obviously, that page can only be after the payment is done, when the customer returns on your website from the payment gateway. There are problems with that: The customer could close the browser before going to that page, or if you didn't configure PayPal to automatically redirect back the customer to your website, he would have to click on a button to go back to the website and thus a lot of sales wouldn't be taken into account. With that method, the current URL is the shop, the previous page is the payment gateway, and the user sending the notification is the customer himself.
2. HikaShop sends a direct call to GA in PHP. This is thus done during the payment notification process when the payment gateway server notifies HikaShop of the payment. With that method the sales are always registered, so in that respect, it is better.
However, the current URL is the payment notification, there is no previous page, and the user sending the notification is your website server.

One mode or another might help with the source of the sale, but it might also give you less accurate analytics on the sales. Testing would be required to see if one mode works better than the other for you.

Hi Nicolas,

I'm returning to this topic because I still don't have this working correctly. What you have described sounds fine in theory but I'm finding myself having to guess what the various configuration settings for the plugin do.

I have two problems ...

1. If a user checks out and is transferred to a payment processor, when the payment processor returns that is seen by Google analytics as a new session, so I am getting an inaccurate session count (two instead of one)

2. The source of sales are all being recorded as "Direct", ie coming as direct links from the payment processor, and are not being attributed correctly to the true source of the sale (Organic . CPC etc). This makes it impossible for me to demonstrate how well my clients adwords campaign is working as I don't have any usable data.

Could you please recommend settings for the Google analytics plugin that will correctly attribute the source of sales and do not distort the sessions count, I am happy to assume that users will complete the payment process correctly and return to the site from payment.

Thank you,

Ian

Hi,

That's right ; each time the plugin use the Measurement Protocol ; it uses a different "Client ID" which is generated dynamically.
Because we do not have any information about the "Client ID" used by the customer when he created the order ; we only can generate a random one.

Now if you have an idea in order to be able to get that customer "Client ID" and if we can store it into the order ; in the plugin it won't be too complicated to use the information from the data instead of the random one.

Why we're using the Measure Protocol ?
Because when the order is confirmed thanks to the IPN system ; there is no javascript processed.
And there is no page displayed by the customer.
Because we can't be sure that the customer will ever return to the website (a huge number of customer had that problem) ; we use that "direct" call to keep a track of the order and his confirmation.

More about Measure Protocol :
developers.google.com/analytics/devguide...protocol/v1/devguide

Regards,

Hi Jerome,

I don't think it's the client id that's the problem, from reading the Google documentation you linked to it's the "Document Referrer" and "Campaign Name" parameters that are needed to make analytics work properly. Can't these be stored as cookies?

How do other shopping carts do it?

Regards,

Ian

Hi,

There is no "document referrer" or "campaign name" in the Measure Protocol.
And like I mentionne in my previous post ; there is no way that cookies can be use for such job...

Regards,

For the benefit of anybody else with a similar problem, the solution seems to be to exclude your payment processors from the referral traffic sources in Google analytics. Without the exclusion Google sees traffic coming from payment processor pages as a new session.

support.google.com/analytics/answer/2795830?hl=en%28

You can also increase the session time out, the default is 30 mins which would seem ample for someone to make payment but you never know!

support.google.com/analytics/answer/2795871?hl=en%29

I've been running with sagpay.com and paypal.com blocked as referral sources for a few days and ecommerce tracking seems to be correctly assigning revenue sources.

Ian

Hi,

It is indeed an excellent solution.
Thank you very much for sharing it !

Regards,

As it turns out it's not the perfect solution. I am getting revenue assigned to various sources (organic search, paid search, social etc) but I am also still getting revenue assigned to "direct" .

The value assigned to "direct" is the total value of all the successful orders which would equate to this still being the returns from the payment processors although the sources are now not identified.

The value associated with "other" sources is slightly less than the total value of all successful orders, so there is some double counting going on, but not everything is being counted properly.

It shouldn't be this hard.

Ian

Hi,

The value associated with "other" sources is slightly less than the total value of all successful orders, so there is some double counting going on, but not everything is being counted properly.

Yes, that's why we added the measure protocol into the google analytics plugin.
If the order is confirmed but the customer does not come back to your website (or getting a page and not process all javascript for example) you can "miss" them in your stats.
And about the double counting, we added an option in the plugin to avoid that ; but it would affect the customer side and you would just have the "direct" tracking.

So we go back to the interrogations that I gave you on post #225853

Regards,

Hi Jerome,

It is annoying when something doesn't work properly and you say "that's right" - it's not right!

I really don't understand your answer, I don't think Google would have made a mechanism for recording e-commerce transactions that didn't work properly so it must be Hikashop at fault. I concede it may be something to do with how I have it configured, which takes me back to my original post. Please advise on how to getting this working properly.

Thank you,

Ian

Hi,

How do you want to put the fault on HikaShop if your customer does not come back in your website after the payment ?
How do you want to put the fault on HikaShop when the tracking of the order is made using the measuring protocol and when the plugin has no information about the customer analytics "Client ID" ?

I already gave you the different problematics and told you that we are aware of suggestions and ideas.

If you do not appreciate "that's right", I can tell you "that is logical".
But it does not mean that it is our fault.

Regards,

How do other carts do it? Are you telling me every shopping cart has this problem?

Ian

Hi,

For every e-commerce solution which are using the script tag in the webpage.. Yes they all have the issue.
We added the support of the measure protocol in order to be able to catch every single order confirmation, in any case (if the user do not come back, if the order is confirmed by an IPN, if the order is confirmed in the backend or if the order is confirmed by API).

An, imagine you confirm the order in the backend and you display a page with some javascript.
So the google analytics can put his tracking code.
But, because YOU are in the backend, it will use YOUR client ID and not the client ID of the customer who made the order in the first place. So, it will track an order confirmation on YOUR tracking account and it will break your stats.

Everybody as that issue and the solution we provide with the measure protocol support is a real step forward.
Now please read my previous message about the interrogations to make it better.

Regards,