Posted on

Zeald does NOT support GA ecommerce tracking

Dear Zeald,

you call yourself an ecommerce website builder – but you do not support the native ecommerce tracking features of Google Analytics – certainly the most popular web analytics package available in 2013.

This is an open letter to Zeald to try to convince you to consider supporting this feature, by default, for no extra charge for your existing customers. If you did support it, the thanks page for a conversion mite include calls to _addTrans, _addItem and _trackTrans, and would allow your clients to see the last traffic source before a conversion – whether it be from any source, Bing, Facebook, Yellow etc, not just Google Adwords. Not only that, but they would be able to see a plethora of multi-dimensional reports that could show average order value, top products, and feed the conversion value easily back into Adwords to enable true ROI calculations to be made for all traffic sources.

Once you have got this working – I’ll convert this blog post into a thank you message.

Yet I see no mention of support in your help files, only this one which is about a different tracking method that only works for Adwords:

Adwords Conversion Tracking != Google Analytics Ecommerce Tracking.

To help you get going, below is an example of what the tracking scripts look like:

<html><head><title>Receipt for your clothing purchase from Acme Clothing</title><scripttype="text/javascript">

  var _gaq = _gaq ||[];
    '1234',           // transaction ID - required
    'Acme Clothing',  // affiliation or store name
    '11.99',          // total - required
    '1.29',           // tax
    '5',              // shipping
    'San Jose',       // city
    'California',     // state or province
    'USA'             // country

   // add item might be called for every item in the shopping cart
   // where your ecommerce engine loops through each item in the cart and
   // prints out _addItem for each
    '1234',           // transaction ID - required
    'DD44',           // SKU/code - required
    'T-Shirt',        // product name
    'Green Medium',   // category or variation
    '11.99',          // unit price - required
    '1'               // quantity - required
  _gaq.push(['_trackTrans']);//submits transaction to the Analytics servers

    var ga = document.createElement('script'); ga.type ='text/javascript'; ga.async =true;
    ga.src =('https:'== document.location.protocol ?'https://ssl':'http://www')+'';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);

  Thank you for your order.  You will receive an email containing all your order details.

Posted on

Bidding by ROI Percentage in Adwords

UPDATE: on August 8 this year I posted this initial blog post, now I see Google is announcing the feature! Cool –

Feature request: Dear Google, I would love to be able to bid by target ROI percentage in Adwords. The idea would be to set a target at the campaign level using a percentage ROI you would like. I have a client who doesn’t want to run ads at less than 500% ROI, and this is something I am getting done using Google Analytics, but it is kinda tricky as I need to switch between GA and AW, boosting ad groups with high ROI, and pulling back on ad groups with poor ROI, working to increase the overall campaign ROI in order to acquire an increase in budget, and turn AW into a money printing machine.

ROI = return on investment.

ROAS = return on ad spend.


Thanks, Tom.

Posted on

GA Bug: Internal Site Search tracking doesn’t work with URLs rewritten by filter

So I thought I was being cunning by putting in a filtered profile which would have an advanced custom filter to re-write incoming URLs into the format expected by GA site search tracking.

But it doesn’t work.

Here’s the incoming URLs that won’t track:

Before URL Rewrites

And here is the after they are rewritten, all nice and tidy with just the keyword:

After URL Rewrites

However, with site search tracking enabled, nothing is showing in the site search report.

Here is the filter config:

Filter Order

And the URL Rewrites are done with regex: /search/jobs/(.*)\?job

The capture group is output to a Request URI like this: /\?q=$A1

But perhaps the Internal Site Search tracking is applied before the filters: which is a bug right?

Filter Config


Thanks to Student Job Search for allowing me to publish this blog.


Posted on

Get rid of load-balanced domains with a regular expression: GA Webmail Referral Traffic Source Rollup Filter

The problem? Nasty load balanced domains in Google Analytics reports like this:

Source Visits / referral 149 / referral 131 / referral 43 / referral 25 / referral 23

The solution? Clean nicely segmented source lines that “roll up” into one:

Source/Medium Visits
Webmail ( / email 643
Webmail ( / email 258
Webmail ( / email 105
Webmail ( / email 13
Webmail ( / email 12
Webmail ( / email 23

To clean these up requires two filters:

  • Webmail Source Rollup (search and replace with Webmail (brand])
  • Webmail Medium Rollup (swap / referral with / email as medium for further rolling up!)

Both these filters will use the core regex code I’ve figured out that consolidates 99% of the worlds webmail systems without pulling in any false positives in theory.

The Magic Regex Code

Here is the filter regex that I’ve been currently using in my production Google analytics advanced filters since 15 Feb 2012 to cleanup these – or to roll up the load-balanced domains that you often get in referrals:

My starting point:


This grabs any domain with say “mail” in it, but runs a check on the ending of the domain: it needs to have at least 2 dots after it and a TLD between 2 and 4 chars long. It will miss and It will also miss “Mail Campaign \ email” because this is not a proper domain. So far so good 🙂

My improvement with exceptions (This is the one to use!):


Domain of webmail platform is in capture group $A2.

My improved regex has a new exception section at the end to allow some special cases (,, to get through the filter using a hard-coded approach that skips the safety net and autonomy provided by the wide open keyword matching paired with a domain name restriction ensuring “two more dots and a TLD”.

Maybe that is excessive use of regex, but at least you can be sure you can now see your word of mouth / word of email traffic nice and tidy!

How does it work?

I’ll break the formula down in sections:


This looks for the really obvious and common keywords in webmail services, the main one being mail. This will match but it will also grab and a huge number of others that you really don’t want to catch with this filter. If we were looking for live (but we aren’t in this case), then a site like would get picked up in the crossfire. I use a ^ in front of imp so that domains like don’t get caught.

Basically the first part of the domain name (sn124w.snt124.mail) will be getting deleted by this filter so you could stand to lose quite a lot of data with the “mail” and “imp” keywords if this were the only parts of the expression! So the next bit of filter is designed to pass the domain through another difficult test involving the dots and TLDs…


This makes sure that the domain bits after mail or zimbra or whatever always have two dots and a TLD (top level domain extension eg .nz .jp). Which matches the end bit of and  the end of:

The (.*) part means match anything including nothing, and the \. means there must be a dot, so (.*)\.(.*)\. means there gotta be at least two more dots in this domain name coming up after the live”. Which is how Answering Oliver gets through the test for live. The next part .{2,4} is all about the top level domain or TLD. These can be 2, 3, or 4 letters long like .co, .com. and .mobi. The curly braces specify how many times the previous character . (which means single char you like except nothing) can appear like {min,max}.

Then in the middle is a pipe | which cuts the regex open and allows some really hard to match exceptions through for smaller webmail systems. Only reason you see the one also appear on the left of the central | is because this is such a whacky domain name that it doesn’t match the “mail” which gets most of the webmail systems on the planet. Germans aye? 🙂

* (Hi Devon! Thanks for sending traffic to Stray Travel I found you researching this post)


Campaign Source Filter

Advanced filter.

Field A -> Extract A: Campaign Source:


Field B -> Extract B: [leave both blank]

Output To -> Constructor: Campaign Source: Webmail ($A2.$A3)

GA Webmail Rollup Filter
GA Webmail Rollup Filter

Medium Rollup Filter

Advanced filter.

Field A -> Extract A: Campaign Source:


Field B -> Extract B: [leave both blank]

Output To -> Constructor: Campaign Medium: email

GA Webmail Rollup Filter
GA Webmail Rollup Filter


Additional reference domains to check:

The domains below are the really rare webmail clients that are hard to extract:

This is why I needed to grab the full domain with (.*\..{2,4}) versus the first versions (.*)\.(.*)\..{2,4} which would have only grabbed “sinamail”. Now we get

These can be checked with: sina\.com\.cn|go\.mail\.ru|mail\.com|promail\.co\.nz|web\.de|outlook\.com

Errors and Issues

Currently the filter is incorrectly tracking as word of email the following referrals:

I will update the filter to address this issue at some point.


Thanks to Olivier Resoneo for the original inspiration (French). His code was:

Grouper tous les webmail francophones sous le nom de domaine principal
Custom filter
Champ A : Campaign Source : (messag|courrie|zimbra|ima?p|mail|prd[0-9]+)(.*)\.(.*)\..{2,4}
Champ B : (rien) –
Output To -> Constructor : Campaign Source : Webmail – $A3
On peut aussi décliner pour forcer le medium à ’email’ quand match sur Campaign Source, ET Campaign à email-non-taggue par exemple, pour avoir le triplet medium/source/campagne
Posted on

How to track conversions across browsers, people and into eCommerce and CRMs!

Maybe this should be called cross-person conversion tracking, because the problem is normally caused by conversion funnels that traverse across human operators – job recruiter, reservations staff, car rental phone operator etc. Or even pure online companies but which for some reason require a staff member to complete or confirm the applications internally, or even an automated system which completes in the dark after a period when the customer has long since closed their browser window. Cross person tracking helps to see the source of conversion even if someone else carried out the action which triggered the tracking codes to run by a terrible hack of the GA system to pull out the cookie, store it, and return it at the end on the other machine.

Getting Access To the Cookie

Cookies are integral to tracking systems like Google Analytics. However they can’t move from the browser that created them which makes it impossible to use them to track “offline” conversions, or deep conversions. An example of a deep conversion is not just when a potential client fills out a contact form, but when a sales rep has actually phoned them back and converted them into a customer. The point of conversion in that case would not lie with the customer it would be the sales rep operating the companies CRM or backend accounting setup to process the order.

So here is my idea: when the first conversion occurs (lead form, booking enquiry etc) and a bunch of stuff is stored in the database with a unique ID and so forth, also grab the Google Analytics cookie and store that against the booking/purchase whatever. You can easily pull this using the cross domain tracking feature which neatly forms a URL-encoded string to grab.

Here is a sample that I just generated to make it really freaking obvious what I’m talking about. The following string was generated by GA (Google Analytics) using the cross domain tracking functions (_link and _linkByPost), and can be used to show that I started my browsing session from the web directory (referral) even showing the page I was on.


So you grab this string on the conversion page, store it in the database alongside the order, call it “GA Cookie”. Then you make it so that in your deep conversion page or actual conversion page you dynamically pull out this cookie from the db and have it served alongside the normal tracking of that actual conversion. This effectively turns the the sales reps browser into the customers browser in terms of how GA sees it (sure the browser and screen resolution etc will suddenly change), but most importantly, the Goals and Conversions in the reports will show where the sales came from.

This would allow call centre operator based conversions that occur to be tracked in Google Analytics.

Potential uses: In recruitment. When a potential job seeker signs up and converts using their Safari on Mac say, you store the traffic source cookie during the conversion. Then when the person is say actually placed in a job – many months later in some cases – the recruitment system see’s his record being manipulated by the recruitment agent, pulls out the GA cookie string from his db record, appends it to the URL of the status or confirmation page, and triggers a Goal in GA say called “placed”. GA will think the conversion was sourced from it’s actual source, rather than say http://CompanyInranet/ or where ever that employee used to navigate to the content in his work day (info that’s not important basically). This way you can see if different forms of advertising bring in different levels of qualities of candidates. You could compare the performance of Facebook traffic compared with Seek and other job sites, and against Google organic and PPC ads, and make up your mind better about which forms of advertising are working.


Note: the system should probably delete this cookie when it’s done since it’s effectively like cookie hijacking.