Google Analytics

[CardsForCraft]

Is there any way I can use Google Analytics through the check out process :rolleyes:

Adrian

[dferguson]

Not at this stage. You can however use google's ROI tracking (for adwords)
[Edit: Google Analytics code can be added to the final page of the checkout - The Order Confirmation page]

[CardsForCraft]

Thanks David ..... I am using Google's ROI tracking which works fine .... I was just looking for that extra info to see if my customers are following through with their order, or dropping out during the process... Maybe in the future ;)

Adrian

[edward]

Yep it would be an awesome feature as then we can see what conversion rates per visitor. Maybe have an option in the next version to supply our analytics "UA" number ;)

http://www.google.com/support/googleanalytics/bin/answer.py?answer=55532

[crown]

Hello all,

Just a note on analytics: what I can do with GA/ezi at the moment, and some ideas on improving the current situation. Google Analytics is a very popular (and free) tool that provides the capability to produce some detailed and insightful reporting. The limitations of eziMerchant mean that much of this important functionality is lost, and there isn't a real alternative.

First of all, thanks to the support for javascript on the Thanks page, it is possible to either register a hit on the page or, in a slighly more complicated fashion, show purchases. The purchases facility is limited - the best possible is to register the total of the purchase, no other details are available. The amounts will register in the eCommerce section of GA.

To implement, create a checkout action to display a message and insert the following code (note this hasn't yet been updated to the latest version of GA tracking, ga.js):

<!-- google analytics tracking -->
<script src="https://ssl.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-insertcodehere";
_udn="none";
_ulink=1;
// this is the url that will appear in reports
urchinTracker('/shop/checkout/receipt.html');
</script>
<form style="display:none;" name="utmform">
<textarea id="utmtrans">UTM:T|[eziGTS_OrderNumber]||[eziGTS_Total]|0|0|none|none|none UTM:I|[eziGTS_OrderNumber]|UNKWN|See details of order number|(none)|[eziGTS_Total]|1</textarea>
</form>
<script type="text/javascript">
__utmSetTrans();
</script>


This is better than nothing. There are a few things that really lack though:

Can't register details of orders (server or client side)
Can't see progress of purchase funnel (server side)
Can't have GA session persist across to the secure site (client side)


I regard all these items as important, but I've listed them in increasing order of implementation complexity.

Firstly, GA allows you to register the individual products bought by each customer, the amount each cost, and also some stats on the total order. All that is possible at the moment is to register the total of the order.

Implementation of this feature could take one of two forms: in custom JavaScript or baked-in server support. The first, less reliable option would be to embed some JavaScript code in the thanks page that would scrape the screen for the details. This wouldn't be all that robust unless (for example) the Thanks page used some form of custom microformat to mark up the items; that is, tag the order, item, order summary and item details with specific classes so it can be more easily navigated and parsed. I can dive deeper on this if necessary.

The client would then have to embed the parsing and GA code themselves into the page, using established techniques. If this is the only way you'll do it, I'll provide a free implementation of this.

The better option (in terms of reliability but also in the context of the other possible improvements) is to make the GA code an available configuration item, then produce the necessary GA code on the server. This will be far, far more robust.

This leads to my second item - visualising the sales funnel. This feature allows you to analyse where customers are dropping out of the sales process, which you can then feed back into site improvements. At the moment though, there's a black hole from the moment the customer hops onto the secure server, and forms one of the key reasons that we would look elsewhere. However, by embedding the GA code in the checkout pages, a world of options open up. This would have to be implemented on the server side, with a user-supplied GA code.

And last, but definitely not least - persisting GA sessions across to the secure server. GA can do this but it requires the GA account to be set up in a particular way, and it also requires that the 'Proceed to Checkout' button be annotated with some extra GA code. Problem is, unless one resorts to funky JavaScript again, this can't be changed by the theme designer.

There are a couple of ways around this: change the output when generating the site if the account has a GA code, or provide an XML output format that allows theme designers ultimate control (and ultimately, a lot more ways of getting it wrong).

There's a lot here, but hopefully this will feed into the development of the product.

Cheers,
JT