R is a programming language designed for statistical analysis and graphical data visualisation. It's a command line language, similar in many ways to Python, but can also be used from graphical applications, too. 

R is becoming popular with analysts who want to do a bit more with the data they export from Google Analytics. While the learning curve is initially a bit steep, there's an R package for Google Analytics which can make working with, and visualising, API data a little less challenging.

I've recently been dabbling with R and Google Analytics and thought I'd share some pointers on how to get started with some simple projects. 

1. Install R and R-XML

Besides R itself, the R for Google Analytics code also uses a couple of extra extensions for fetching the data from the webservice and for parsing the resulting XML. 

I'm a Linux user and on Ubuntu/Debian you can install these by entering: sudo apt-get install r-base r-cran-xml libcurl4-gnutls-dev libxml2-dev

2. Start R and install RCurl and XML

To install the required RCurl package you need to start R by opening a terminal and typing R then entering a command to download the package from one of the CRAN mirrors. These are much like the CPAN mirrors used in Perl, but contain R packages rather than Perl packages.

The Google Analytics R documentation and code comments suggest using the www.omegahat.com mirror, however, this domain appears to no longer be in use, so I went for Imperial College's CRAN mirror, which is at http://cran.ma.imperial.ac.uk.

You can download RCurl from your chosen mirror by entering the following command in the R command line interface: install.packages("RCurl", repos = "http://cran.ma.imperial.ac.uk")

Once you've done that, issue the command below to install the XML libraries in R: install.packages("XML", repos = "http://www.omegahat.org/R")

3. Install R Google Analytics

There's a pre-built package for using R with Google Analytics, but it's not in Cran, so you'll need to download it the RGoogleAnalytics code libraries from Google Code.

To install RGoogleAnalytics start R (just type R in a terminal) and then enter this command (with the location and file name replaced with where ever you've put the RGoogleAnalytics tarball): install.packages("/home/matt/Downloads/RGoogleAnalytics_1.1.tar.gz",repos=NULL,type="source") 

4. Install RStudio

Next, I'd recommend installing RStudio, a very powerful graphical client available for R, which is free and open source and available for Linux, Mac and Windows. You candownload it from www.rstudio.org as a package for your OS. 

Not only does it provide simple access to the command line, but it will also display any visualisations generated within the application itself, which is nice. The full documentation for RStudio will tell you more. 

5. Load the RGoogleAnalytics library 

If you wish to install any additional packages, click the Packages tab in the lower right hand corner of the RStudio GUI and RStudio will automatically install the selected package and its dependencies with a single click. This makes extending R really, really easy. In order to use one of the packages, you need to tick the checkbox so the libraries are loaded. 

When you load the RGoogleAnalytics library, you should see it fire up the dependencies in the console window.

> library("RGoogleAnalytics")
Loading required package: RCurl
Loading required package: bitops
Loading required package: XML

6. Connect to the Google Analytics Core Reporting API

Using the source editor window at the top right of RStudio write a few lines of code to start up RGoogleAnalytics in R, pass your login credentials to the Google Analytics Core Reporting API and fetch your profile data. 

ga <- RGoogleAnalytics()
ga$SetCredentials("you@yourdomain.com", "qkjshdjkdsksk")
profiles <- ga$GetProfileData()

Highlight the text you've written and then click the "Run" button to execute this chunk of code - you should see some results in the Workspace window pane.  

Click the "Profiles" option and you should get a pop-up window containing all of the profiles for your ID and all of the table IDs for your GA tables. You'll need to grab one of the table IDs to use to query GA. 

7. Running basic GA queries

Once you have an open connection to GA, you can now compose a Google Analytics API query to pass to the Core Reporting API using the QueryBuilder() function. Here's a basic example to fetch visitors and pageviews for a given date period. 

When the query runs you should see it pause for a second while it queries the Google Analytics servers and then display the results in the console window on the bottom left had corner of RStudio.

While handy, at the moment, this isn't anything you couldn't achieve either via the Data Feed Query Explorer or via the Core Reporting API in any other language that takes your fancy. 

8. Plotting data

R has tons of features for quickly plotting data and applying statistical calculations to data sets. Basic plots are achieved using the plot() function while trend lines can be added using lines(). You can do this on your GA data with:

require(stats)
plot(ga.data$data)
lines(lowess(ga.data$data))

This is only really scratching the surface and the quick plot I did obviously isn't ideal for this data set, but hopefully it's enough to give you a rough idea of how it's done.  

If I get a spare moment, I'll do a follow-up to explain how you can do more useful stuff with R, as soon as I figure it out myself!

Google sets strict criteria on data quality and error limits and if you don't monitor these you risk having your feed penalised and some or all of your products de-listed.

In September 2011, Google started gradually enforcing new feed specification requirements and if you didn't update your feed then it's possible you may have experienced a traffic and revenue drop from this source.

Among the new additions were the requirement to provide data on product availability, the Google Product Category and images.

If you sell clothes and shoes there are additional things you need to provide too.

Step 1: Examine the Dashboard

Login to the Google Merchant Centre and open the Dashboard for the site you want to examine.

The Dashboard shows some charts outlining the number of products that are active, awaiting review, disapproved or expiring for the Product Search and Product Ads; the number of search clicks; a summary of data quality and the total number of items inserted.

We're concerned with three main things: the number of items inserted, the overall data quality and the number of errors in the data feeds. The more effort you put into the data quality and errors, the more products you'll get listed.

Step 2: Submit a test feed

Step 2: Submit a test feed

While the standard Google Merchant Center web interface will show you errors and warnings, it won't show them all on one page and there's no immediate option to download them all in an easily digested spreadsheet.

Therefore, the first step I'd suggest is to download your existing feed from the Data feeds page and rename it under a new name in order to create a test data feed.

On the Data feeds page click "New Test Data Feed" and upload the copy of the feed you downloaded to create a new test data feed which will allow you to check your changes and download all errors and warnings in a CSV file.

After a few minutes, if you click the list of errors on the Data feeds > Status section, you should find an option to "Download full report". Click the link and you should receive a huge CSV file to open in Excel allowing you to search for errors and warnings.

Step 3: Examine data quality  

The next step is to look at your data quality, which covers things like missing or invalid product identifiers, or long titles. The issues Google discovers in your feed will be separated into Critical Errors and Suggested Optimisations.

Critical Errors are obviously really bad and you must fix them quickly to prevent your feed being suspended.

Typical reasons for critical errors are products that have been added without the required product identifier or GTIN, which is usually a product code or barcode.

Rather unhelpfully, Google doesn't inform you by email when it discovers such issues, so you'll need to check the Data quality report regularly.

It's also worth setting up an alert in Google Analytics to inform you of traffic drops from this source. If you click the "How to fix" links, you'll find details on how you can resolve the problem.

You'll need to work through the errors one by one, examine your feed data for similar issues, and then upload it to assess what's left to fix.

Step 4: Examine data feed errors

Data feed errors are the next issue to tackle. You can examine these by viewing the reports at Data feeds > Status > View errors.

If you need to download a copy of your XML feed to examine, you can use the link on this page and then open it up in a text editor.

You can also find individual errors by using Ctrl + F within the full report you downloaded in Step 2 and searching for "error".

The item errors report on the web interface will show any products that have errors and have been de-listed. None of these will be shown on Google Shopping or Google Ads, so you'll want to rectify these first.

Typical reasons for errors are "non-unique items", which are usually different products with the same product code; image URLs which contain unusual characters such as square brackets, or items with product descriptions that contain too much text.

Step 5: Testing your changes 

Once you've edited your product content to resolve the issues the Google Merchant Center has flagged, you'll need to use your e-commerce platform to regenerate the feed.

Once you've done this, go to Data feeds > Daily upload and click the "Update and fetch now" button.

After a few minutes, you should see the new data appearing in your Status report and you'll be able to work out what work is left to complete.

Solving common errors

Any products in your feed that throw an error won't be displayed in Google Product Search or Product Ads, so fixing these should be your top priority.

"Item too big"

The item is too big error is caused by product descriptions which are over 10KB in size. Flash or JavaScript code, or just shedloads of text can push you over this limit, so you'll simply need to cut the length of the copy in the description field to fix it.

"Invalid URL in attribute"

The Invalid URL in attribute error is triggered by dodgy URLs and filenames present in the Google Merchant Centre feed. Typical causes for this are spaces in URLs that haven't been escaped with "%20", the presence of backslashes instead of forward slashes, the use of relative URLs (ie. file.html) and missing http:// at the start of the URL.

"Duplicate item"

Duplicate item errors are usually caused by product administrators inadvertently using the same product code for multiple SKUs. This is easily fixed by identifying the duplicates and adding the correct product codes, or the additional EAN/GTIN for the SKUs.

"Missing required attribute: title"

Oh dear, one of your staff has added a product without a page title, which isn't very clever, but thankfully it is easily fixed.

Solving common warnings

Warnings won't prevent products from being listed, but they do affect your overall feed quality, so might feasibly have an impact upon ranking. It makes sense to improve these where you can.

"Invalid UPC value"

The Universal Product Code (UPC) is a US barcode based on 12 numerical digits. Check that yours meets these criteria if you're supplying one. Make sure there are no non-numerical characters present. All barcodes passed to Google get validated, and it will throw an error if it finds an invalid code, which means the product won't be displayed.

"Invalid string value in attribute: description"

The description field in the feed contains the product copy for the item you're promoting. The usual reason for the "invalid string value" error is that the description is completely missing, or contains an invalid character. If the description is completely missing you'll also get another warning for "Missing recommended attribute: description".

"Missing recommended attribute: google_product_category"

The Google Product Category is a string which tells Google Shopping how to categorise the item. It's typically something like "Media > DVDs & Videos" and is based on Google's taxonomy, not yours.

However, although it's wise to add it to every item you list it's only essential for feeds in the UK, US, Germany, Japan and France which sell products in certain categories listed here.

"Missing recommended attribute: product_type"

Unlike the google_product_category, the product_type field is based on your site's taxonomy for the given item. You'd usually use this in conjunction with google_product_category to place the item in Google's taxonomy, and then provide additional breadcrumb information to further categorise the product.

"Missing recommended attribute: image_link"

The image link is a recommended field to provide, so you'll need to source an image and include the URL in your feed to get rid of this notice.

7 helpful tips for troubleshooting feeds

1. Check the Google Merchant Center Dashboard regularly to ensure your feeds are working optimally. Google won't tell you when your products or feed gets de-listed and you'll lose money if you don't check regularly.

2. Keep a close eye on the Google Merchant Center Announcements blog. This is where you'll find more information on forthcoming changes to feed requirements and how they might affect you.

3. Track the revenue you're getting from Google Merchant Centre feeds using Google Analytics campaign tracking parameters in your URLs. You can create dashboards (above), custom reports, advanced segments and alerts to help you can an eye on things.

4. If you need help diagnosing problems with your feed, check out the Google Merchant Center forums at Google Groups.

5. The errors and warnings which apply to you will depend on what you sell, and in which countries you operate. You'll need to check the guidelines at Google Merchant Center Help to find out which ones matter to you.

6. You can find GTINs that Google recognises by searching for the product in Google Shopping and clicking the "Compare Prices" button which usually appears on the first result. Scroll to the bottom and you should find the EAN you need.

7. Dodgy GTINs are among the trickiest issues to solve and your item will be rejected if you supply an invalid code. Fortunately, you can validate them yourself directly within your platform using code like this. 

8. Provide as much detail as possible and make sure content editors always maintain high standards of data quality. Miss out your EANs, for example, and you'll get far less exposure.  

Why bother? 

Here's what can happen to your performance if you optimise properly! A 200%+ performance boost. Simply fixing the errors and warnings and improving taxonomy helps increase the clicks. 

We're now seeing a huge increase in revenues from this channel which is making a massive financial contribution.  

Knowing which 20% of your products are having the greatest impact on your revenues can help you reduce the revenue you lose to stock outs and help you optimise your product sales for the slower turning lines.

It's not directly possible to do a Pareto analysis in Google Analytics, but you can use the Google Analytics Data Feed Query Explorer to extract your annual sales data and pull it into Excel for further analysis. 

Step 1: Fetching the data 

Log into the Data Feed Query Explorer and create a query to fetch the product name and item revenue for every product you've sold over the past 12 months, and order the results by descending item revenue. 

You can save time by clicking here and then authenticating your Google Analytics account. If you highlight the data produced with your cursor, you can just copy and paste it from the Data Feed Query Explorer straight into Excel. 

Step 2: Sorting the data

Now that we've got our revenue data for all of the products we've sold over the past year, we need to count the number of products and split them into three classes, A (the top 20% of sales), B (the next 75% of sales) and C (the bottom 5% of sales). I'd recommend placing each class on its own sheet so you can go over them more easily.  

You should find that approximately 80% of your revenue comes from the top 20% of products sold (it was 75% in the case of my site), while the other two classes (80% of your stock) make up the remaining 20% of your revenue.  

Step 3: Analysing the class data

The products in class A are the ones that are currently of the greatest importance to your revenue. These are the ones you need to keep a really close eye on in terms of your inventory control as stock outs will lose you sales. 

However, if anything, the really interesting stuff lies within the B and C classes. If you spot products in here that you'd expect ought to really be fast-moving products that shift in large quantities worthy of class A, then you've spotted a potential problem. Are they priced too high? What's stopping your customers purchasing them as often as you'd expect? 

If everything is definitely in order regarding pricing and other on-site issues, then perhaps you could reduce your inventory levels of these slower moving items, make them special order items or get them drop-shipped to free up working capital? 

The other really useful information lies in what you can't see. Google Analytics will obviously only tell you about the products you have sold.

If you compare the total number of products you've exported to the actual number of products in your range you may spot a number of products that haven't sold at all - so called class D items. In this case, there's something very wrong and you definitely ought to consider clearing these, unless they're simply range completers.

The next step is to display your data.

However, if you're creating different queries to run which have varying numbers and types of metric and dimension selected, you need a flexible way of formatting data without the need to code a new table each time you modify your API query.

The Smarty templating engine for PHP is ideal for this. 

Step 1: Install Smarty and set it up

Firstly you'll need to install Smarty and get it set up so you can use it within your Core Reporting API application. You can download it from www.smarty.net and check the excellent Smarty Crash Course for some tips on set-up and basic usage. 

Once you've set it up, you'll want to assign a title variable to pass to Smarty: $smarty->assign('title','Data for ');

Then you need to get the column headers, which are your metrics and dimensions, and add them to an array to pass to Smarty so we can use them as the table headers: $smarty->assign('headers',$data['columnHeaders']);

The rest of the data can be passed to Smarty as $data: $smarty->assign('data',$data); and then you can send it all to the display template with $smarty->display('../templates/table.tpl');

Step 2: Create your flexible table template

In order to get your content to display clearly, with the right column headings and the right number of columns, we need a flexible structure that works for any combination of metrics and dimensions. 

Create the basic table structure using the standard tags and then create a loop construct within your first set of table row tags to add the headings based on the selected dimensions and metrics.  

The next step is to loop through the actual data. I used a foreach to loop over all of the results and display them in the appropriate table cells. 

There are some tweaks that are worth making to make the data more presentable.

I used the Smarty cycle value to add a class "on" or "off" to each table row and then added CSS to change the colour to create a zebra-table effect of alternating row colours. 

I also used is_numeric and stristr to check to see whether the value was a string or an integer and rounded the values that had lots of trailing decimal places, and truncated long strings, such as URLs, to make the data a bit cleaner.

Add some CSS to style it up and you've got a quick and easy way to display lots of data from the Core Reporting API, without the need to edit anything other than your original query.  

Next time I'll explain how you can use refresh tokens to create applications that can run without user interaction.  

It relies upon two key bits of data held in the e-commerce platform's database: the current stock holding for each product, and the low-stock level for each product.

When an item is sold, the stock holding goes down according to the number of units sold. Each product is then re-ordered when its stock level reaches its low-stock level or re-order point (ROP).

The stock holding level is manually increased when the ordered goods arrive from the supplier and stock levels are replenished to the maximum stock level.

This technique works but its success is dependent upon a number of things, and there are various business considerations to take into consideration to ensure it works optimally.

Here's a textbook representation of what happens to stock levels.   

The problem?

Well, two main things can go wrong.

You can run out of stock because your stock holding isn't large enough to meet the demand, or you can have a low-stock level which is too low, which means you run out of stock while waiting for the goods you've re-ordered to arrive.

These things need checking continually, because demand for products can rise (and fall), causing you to run out of popular products (or have a surplus of slow sellers you need to turn).

I've explained before how I have used Google Analytics to identify the revenue you lose to stock-outs, and it's well worth implementing this if you suspect stock control needs improving.

However, looking at stock-outs only gives you part of the picture.

What you really want to see, is how close you get to your buffer inventory, how much stock you have, what the demand is like, and how much working capital you have tied up in your stock in relation to sales.

Most e-commerce platforms don't tell you this, and our systems don't report it, so I spent a day devising a hack to obtain the data and pull it into Google Analytics for monitoring, reporting and analysis. 

What will this hack provide?

Step 1: Setting up server-side analytics

In order to obtain data on these things you need to query the database at a particular time each day and send the data to Google Analytics.

However, that's not feasible using the standard client-side tracking code - you need to do it on the server-side from a command-line application.

To achieve this I developed a command-line application in PHP which runs on the PHP-CLI and queries a SQL database to obtain the metrics required.

It then injects them into Google Analytics using the excellent PHP-GA class. If you've not used this before you can get some general usage tips from my post on the hack I made for testing a cookie-less Google Analytics implementation.

Using a command-line application with server-side analytics allows you to run the code from a server and can bypass the 10 event limit imposed for the client side GATC. 

You could also use SSGA server-side Google Analytics if you prefer, but it's not been updated for a while and, annoyingly, it encodes spaces in event category, action and label strings. 

Step 2: Obtaining aggregate daily totals

The first thing I wanted to obtain was aggregate daily totals on various metrics to give an overview on the inventory not provided by our e-commerce platform.

This includes metrics like the daily levels for: total categories, total products, total SKUs, total stocked SKUs, total drop-shipped SKUs, total inventory units and total inventory value.

I wrote a PHP class containing a series of functions which ran SQL queries against the e-commerce platform's database and returned the required data in variables I could pass to GA and echo to the command line output.

If anything, this was the most complicated bit, due to the nature of some of the joins required to query the database. These will obviously vary according to your platform, so I've skipped them out here.  

Step 3: Configuring your events

Once I had the metrics, I then used server-side event tracking to add the data to GA to a separate profile - the latter point is important, for reasons I'll explain in a minute.

Here's the format I used for the PHP-GA events to ensure data is placed in the correct place in GA for easy analysis. These events place all data in an event category called 'Aggregate daily totals'. Drilling-down to action and label levels gives you access to the rest of your data.

Categories
Event format: _trackEvent('Aggregate daily totals','Category','12',12).
Goal: Monitors the total number of categories over time.

Products
Event format: _trackEvent('Aggregate daily totals','Products','1234',1234).
Goal: Monitors the total number of products over time.

SKUs (stocked)
Event format: _trackEvent('Aggregate daily totals','SKUs (stocked)','12345',12345).
Goal: Monitors the total number of SKUs stocked over time.

SKUs (direct)
Event format: _trackEvent('Aggregate daily totals','SKUs (direct)','1234',1234).
Goal: Monitors the total number of drop-shipped SKUs over time.

SKUs (out of stock)
Event format: _trackEvent('Aggregate daily totals','SKUs (out of stock)','123',123).
Goal: Monitors the total number of out of stock SKUs over time.

Inventory units
Event format: _trackEvent('Aggregate daily totals','Inventory units','1234567',1234567).
Goal: Monitors the total number of units of stock held over time.

Inventory value
Event format: _trackEvent('Aggregate daily totals','Inventory value','8787878',8787878).
Goal: Monitors the total value of units of stock held over time.

Customers
Event format: _trackEvent('Aggregate daily totals','Customers','1234567',1234567).
Goal: Monitors the total number of customers over time.

Newsletter subscribers
Event format: _trackEvent('Aggregate daily totals','Newsletter subscribers','123456',123456).
Goal: Monitors the total number of newsletter subscribers over time.

Here's an example of the code required to create the new session in PHP-GA and to send the event tracking data. Again, there's more information and sample code in my other post on PHP-GA. 

Providing you're sending fewer than 499 events in a single PHP-GA session, you should be able to use a single $tracker->trackPageview($page,$session,$visitor); call.

Send more and you risk hitting the 500 hit limit for a session, and you'll need to split events over multiple sessions in the same script.

Echoing the output of the application to the terminal is useful during testing because it allows you to see that the data are being obtained correctly and gives you the opportunity to look for PHP-GA's errors, since PHP-CLI applications don't run through Apache and errors, warnings and notices don't appear in its error logs.

Once you've sent some test data, you should see it appearing in the GA web interface within about 10 minutes.

It's then possible to look at the charts produced showing the daily event values to see how they change over time. Some of the other totals obviously won't be usable, but that's easily fixed by creating custom reports.

Step 4: Analysing inventory by category

Now that I had an overview of the entire inventory, the next thing I wanted to examine was the inventory at a product level. 

The data should be useful for finding out which categories were underperforming and should show what return we were getting from the stock held, when you compare sales revenue to inventory.

How many products and SKUs were in each category? How much stock were we holding? How much working capital was tied up in stock? What return did we get from our inventory for the category?

If we had £2000 of working capital tied up in our stocks of purple mohair ties but monthly sales were only £100, did we really need so much stock? Would it be better to drop-ship these instead?

Extracting these data is achieved in similar ways, but obviously involves a bit of looping and for my e-commerce platform some of the database queries involved some complicated joins and concatenation.

However, the principle is easy. First you need to get your list of categories, then for each category you need to obtain the total number of products, SKUs, inventory held and its value. Here's an example of the event tracking code used.

Subcategories in category
Event format: _trackEvent('Aggregate daily totals','Subcategories in category','Tablet PCs',3).
Goal: Monitors the total number of subcategories in a category over time.

Products in category
Event format: _trackEvent('Aggregate daily totals','Products in category','Tablet PCs',123).
Goal: Monitors the total number of products in a category over time.

SKUs in category
Event format: _trackEvent('Aggregate daily totals','SKUs in category','Tablet PCs',3234).
Goal: Monitors the total number of SKUs in a category over time.

Inventory units in category
Event format: _trackEvent('Aggregate daily totals','Inventory units in category','Tablet PCs',39393).
Goal: Monitors the total number of units of stock in a category over time.

Inventory value in category
Event format: _trackEvent('Aggregate daily totals','Inventory value in category','Tablet PCs',123456).
Goal: Monitors the total value of stock in a category over time.

If you have lots of data to send, consider using sleep(1) to pause for a second between the POSTing of data to prevent hammering the GA servers with a shed-load (that's English for a lot) of traffic all at once. 

You'll also need to ensure you use PHP-GA to create a new session for each set of related events you send, otherwise you'll hit the 500 hits per session limit and execution of the script will stop. 

It's worth making sure that error messages are set to display to standard out because you may get "MySQL has gone away" timeout messages if your data takes a long time to crunch. Opening a new connection for each chunk of data should solve this.  

Step 5: Sending product-level data

Now that we've done with collecting the aggregate data and the category-level data, it's time to do the bulkier task of obtaining the product-level data which provides your actual inventory profile timelines. 

The principle for this bit is the same as for the category-level data. You run a SELECT query against your database to get a full list of your SKUs and return the product name, SKU code, cost price, quantity of stock being held and then create a while loop. 

Within the while loop you need to create a new PHP-GA session for each SKU returned and then send four events containing the data we want to send to Google Analytics.

It's vital to create a new session for each one, because you'll otherwise hit the 500 hit limit in no time. You'll also want to use a sleep() function to minimise the speed at which data is sent to Google's servers.

Since we're adding a bit more data to these, and allowing more drilling-down, these data are going in separate event categories. 

Inventory units
Event format: _trackEvent('Inventory units','Apple Macbook Pro 15','AMBP15',5).
Goal: Monitors the total holding of a SKU over time.

Inventory value
Event format: _trackEvent('Inventory value','Apple Macbook Pro 15','AMBP15',4500).
Goal: Monitors the total value of SKU inventory over time.

Re-order level
Event format: _trackEvent('Re-order level','Apple Macbook Pro 15','AMBP15',1).
Goal: Monitors the re-order or low-stock level over time.

Step 6: Automating data collection

In order for the data to be accurate you need to ensure that the queries are only run once per day. 

I configured a cron job to run my script as a scheduled task on my Linux server every night at one minute past midnight with this command: 01 00 * * * php /var/www/stockprofiler/profiler.php

Every morning when I check GA, I have fresh data from the previous day. I don't need to touch the code again - it just keeps sending me new data on the inventory just as the client-side code does. 

Step 6: Accessing your inventory data

Once you've followed the above steps, you'll be able to access the data in your new profile via the following event categories. You can drill-down among them to see aggregate totals for each day, category or product.

Don't forget that because we're sending daily totals to GA, the only field that will really make sense if the event value and the timeline for the metric.

The total event value metrics will be calculated based on the combined sum of daily events, so won't mean much. It's best to create some custom reports. 

Handy tips

• Put this data in a separate Google Analytics profile to prevent the large quantity of hit level data sent pushing you over your data limit. It would be nice to have the data in the same account as your web data, as you'd then be able to compare web metrics to inventory metrics, but there are risks to that if you have a large site.

• Don't send more than 10 million bits of hit level data per month, otherwise you'll hit Google Analytics' data limit. If you have a big product range, calculate the number of events your script will be firing to determine whether this could be an issue.

• Don't exceed more than 1 million hits per day, otherwise your data will only be refreshed once a day, and you'll exceed your monthly data limit.

  

• Use the new real time reports in Google Analytics 5 to get an idea of the amount of data being sent and the rate, and to check that everything is working as intended during testing.

• If you're using this hack with Google Analytics Premium there is no data limit, so theoretically you could use this with quite a big product inventory. 

• Don't send more than 500 bits of hit level data in a single session. If you're looping over data, use PHP-GA to start a new session in each loop, which will increase the number of sessions and prevents you hitting the 500 hit limit. 

• Use a sleep() function to pause the sending of session data by your script for a second to prevent it hammering the GA servers. 

• Make sure your cron job only fires once a day, as most of these are daily totals which will be ruined if you inadvertently send the data multiple times.

• Create custom reports to make the data more meaningful, since some of the metrics won't apply with this hack. 

Avinash Kaushik has confirmed that analytics providers have been discussing the legislation, but hasn't said whether they have a solution to the problem, and if they do, what it will entail. 

If you're affected, your options are to get users to opt-in to being tracked using cookies (in which case you can kiss goodbye to 90% of your web analytics data and rely on sampling), do nothing in the likely event that the ICO don't bother to prosecute you simply for using GA, or switch to a server-side tracking system which doesn't rely on cookies. 

While I'm aware of other cookie-less tracking systems, I haven't used any since the pre-GA/Webtrends days. 

Personally, I'd be extremely surprised if they came anywhere close to the functionality of Google Analytics, and like many other people in the industry, I've got data in the tool that I want to keep and features I rely upon for my work.

GA does what I need it to do, and it's tightly integrated into my sites so I can capture additional data to help me make the right decisions. 

If browser manufacturers aren't going to step-in to allow this issue to be handled on the browser side, the best solution for me seems to be the development of a server-side Google Analytics tracking system.

That could be one that has official backing, or one that's been built from scratch to help overcome the legislation in a legal and responsible manner.

Server-side Google Analytics?

The current Google Analytics tracking solution is a client-side system and the JavaScript code is executed by the browser.

Tracking data is sent to GA via GIF image requests generated by the code, with certain items of data, such as timestamps and unique identification hashes, being stored in a number of first-party cookies in the visitor's browser.

Google does not yet provide a cookie-less or server-side alternative to this client-side tracking system, although its mobile tracking code comes close.

I'd be really surprised if its engineers weren't working behind the scenes on a server-side API. Indeed, the client-side code probably already interfaces with something a server-side solution could connect to as well.

Thankfully, given the lack of an authorised API, there are at least two fairly robust solutions which achieve the same thing: Server-Side Google Analytics (SSGA) and PHP-GA. 

These are both PHP classes which pass similar data back to the GA server by faking the GIF requests, which trick Google Analytics into thinking the data is coming from a client-side tracking tag.

While some things don't work, and while some actions are harder to track and require more coding effort, they're both actually quite decent and it is possible to get quite a bit of the core tracking data into GA without relying on cookies.

Server-side GA isn't cookie-less by default...

You can use either SSGA or PHP-GA for this. Both work in very similar ways.

I've used SSGA on a couple of projects and it works really well, but unlike PHP-GA it hasn't been under active development for quite a while (since April 2009) and it supports fewer features. 

PHP-GA is more modern (it's written in fully namespaced OOP PHP), it supports pretty much all of the main features (including new ones like trackSocial) and is probably the best choice of the two.

It is server-side, rather than client-side, so the code is hidden from source code viewers and is triggered by PHP on your server, however, it can use cookies for some features. They're just created by PHP, rather than by JavaScript.

It hasn't been designed to be a cookie-free alternative to GA. It's been designed to replicate the functionality of Google Analytics ga.js JavaScript tracking code in PHP. As a result, if you use it as-is, it could create cookies. Most of the main features don't use cookies, though.

Example 1: Basic page tracking

For really basic pageview tracking you can use the code below. Don't forget to replace your own UA profile ID, otherwise you'll fill my test account with your data!

This example simply adds the user IP address (required by GA but not shown or accessible) the user agent (ie. Windows Vista, Internet Explorer 6) and the details on the page title and file accessed. (Use REMOTE_ADDR, not REMOTE_ADDRESS, as I stupidly did!)

You can pass additional data to GA using the Visitor() function, which I'll explain in more detail later. This code doesn't set any cookies whatsover and will provide only basic tracking. 

Example 2: Event tracking

Event tracking, probably the best overall feature of Google Analytics, is also very easy to achieve and again doesn't use any cookies.

You simply call the GoogleAnalytics\Event() function and then pass it the required data using setCategory(), setAction(), setLabel() and setValue() - even the new opt_noninteraction feature is supported via setNoninteraction().

The data can then be passed to the tracker using trackEvent(). Interestingly, the client-side version of GA prevents you from sending more than 10 events at once, but you can send 20 or more simultaneously with both PHP-GA and SSGA.  

Example 3: Ecommerce tracking

Ecommerce tracking works much like the client-side equivalent. First you need to populate the order ID with a random number which is used as the transaction ID. Then you call Item() and set the orderId, the SKU, the name, quantity and price.

You can then create the transaction, pass the items, the basket total and any details you have on the customer location and shipping charges and it populates the ecommerce tracking data in exactly the same way as the client-side version. Again, no cookies are used.

Other features

There are many more things you can do with PHP-GA, including passing additional visitor data (such as screen resolution, Flash version, Java enabled etc), setting custom variables (with cookies), and using trackSocial.   

This only really scratches the surface of testing what you could do with PHP-GA without the need to use cookies, and what you'd probably need to do to get close to the full features sans cookies.

Granted, it falls short of client-side GA if you don't use cookies, but it provides the basics of page tracking and ecommerce tracking which could be enough to get by if the worst does happen. 

Sadly, it isn't capable of recognising repeat visitors, presumably because GA only uses the ID stored in the __utma cookie, and not a combination of other visitor features.  

It's not going to solve every problem, but it could record most activities without cookies and it's certainly going to be a lot better than having 90% of your data missing. Obviously it needs more work, though... 

However, at the moment, it's currently not very easy to produce reports within Google Analytics to allow you to analyse these data because GA's custom report and dashboard tools lack dimensions for ecommerce data.

Thankfully, you can access these data using the Google Analytics Data Feed Query Explorer, or via the underlying Google Analytics Core Reporting API itself.

The Google Analytics Data Feed Query Explorer's web interface provides a much greater range of dimensions and metrics than the standard web front-end to GA, so it's a very powerful tool and you don't need to do any coding to use it.

Brand performance reporting

Let's say for example that you want to find out how well your individual Apple products have been selling over the past month.

You simply need to log into the Data Feed Query Explorer, select the desired account and profile and customise the following settings, or click here to add them automatically:

dimensions = ga:ProductName
metrics = ga:itemQuantity,ga:revenuePerItem,ga:itemRevenue
filters = ga:productName=~Apple
sort = -ga:itemRevenue

If you want to automate your report, pull it out via the Google Analytics Core Reporting API, or pull it into a spreadsheet using a tool like AutomateAnalytics or NextAnalytics, you need to use a URL which looks something like this:

https://www.google.com/analytics/feeds/data?ids=ga%3A1234567&dimensions=ga%3AproductName&metrics=ga%3AitemQuantity%2Cga%3ArevenuePerItem%2Cga%3AitemRevenue%2Cga%3AitemsPerPurchase&filters=ga%3AproductName%3D~Apple*&sort=-ga%3AItemRevenue&start-date=2011-12-01&end-date=2011-12-30&max-results=500

You'll just need to create a separate report for each of the brands you want to monitor by changing the value you pass to the productName filter.

Category performance reporting

Measuring category performance is a bit easier, because it's more feasible to merge data on multiple categories into a single report, so if you want to compare sales of laptops to tablets and mobiles, it's all possible from one query.

You need to customise the following settings, or click here to add them automatically:

dimensions = ga:ProductName
metrics = ga:itemQuantity,ga:revenuePerItem,ga:itemRevenue
filters = ga:productCategory=~laptops|tablets|mobiles|netbooks
sort = -ga:itemRevenue

This will create a single report containing data on laptops, tablets, mobiles and netbooks, so you can see which categories are driving the most revenue.

Basic report extraction

If you want to pull this custom report data out of the Data Feed Query Explorer's underlying API, you don't necessarily have to do any programming to extract it.

There are several plugins available for pulling data out of the API and into Excel or Google Docs, including:

• Next Analytics ($199)
• GA Data Grabber ($299)
• Analytics Canvas ($49 per month)
• Excellent Analytics (free)

Using the tool of your choice, you can replicate the API queries above and get the data pulled into an Excel spreadsheet for further analysis.

I recently asked a question on the GA team's Web Analytics TV series, which is hosted by Google Analytics Evangelist Avinash Kaushik and Nick Mihailovski from the GA team, which has been answered in the latest episode.

I asked "It's now a legal requirement in the EU to get permission before sending cookies. Google Analytics without accurate ecommerce tracking would be useless. Does Google have plans for a server-side working around, since PHP APIs for POSTing data already exist."

Avinash replied: "This is a good question, Matt. Along with other companies, like Microsoft and Yahoo, and Omniture and Webtrends, the team at Google is working with the various entities in the EU to figure out what the implications are.

"Because some clarity is missing as to what applies in individual countries across the entire EU. At the moment that process has not concluded, but when the process is concluded we will post guidelines on the Analytics blog, analytics.blogspot.com. So stay tuned there. 

"I did want to emphasise that the word 'workaround' is very sensitive in this scenario, so hopefully there are no 'workarounds'. Google as well as all the other companies are going to follow the laws that are applicable in the individual countries.

"But as to what they are, and what the implications are, we'll post them on our blog. As will our peer companies in the industry, so watch out for that."

I'm really pleased with this, so thanks to Avinash and Nick for responding. Hopefully it might mean that the EU cookie law is going to be a little less painful than we were originally anticipating. 

It's now REST-based and provides outputted data in JavaScript Object Notation format, or JSON, rather than the old-style XML, which Google reckons means the output is 10 times smaller - making it much faster.

1. Set up your OAuth credentials

The Core Reporting API now uses Open Authentication 2.0, or OAuth 2.0, and requires that you register your application before use.

Once set up, your application will need to request an access token from Google which it needs to use in the URL it sends to the relevant API in order to obtain data. No token means no data, so this is a crucial step.

On the plus side, all of the Google APIs have standardised on this, so you only need to learn how to do OAuth once, and it's much more secure.

You'll need to go to the Google APIs Console and register to get hold of your client ID, client secret and API key. You'll also need to define the URI for your callback page.

Importantly, the URIs (you can provide one per line) all need to be fully qualified domain names pointing at the file with the OAuth code in it. You can now also use a localhost server for this, which makes development easier.

The token is returned as a GET parameter, so your OAuth code needs to grab that and append it to the REST request string.

2. Set up your server for Curl

Since you now need to connect using OAuth 2.0, you'll need additional software to handle this as the connection requires the Curl extension for PHP.

On Debian-based servers you can install the dependencies by entering sudo apt-get install php5-curl curl and then re-starting Apache to load the module with sudo service apache2 restart.

You can test your configuration by checking out the latest copy of the Google API PHP Client from the Google Code Subversion repository. Don't download the tarball, as it's currently missing the vital apiAnalyticsService.php file!

You can grab a copy of the latest google-api-php-client by entering: svn checkout http://google-api-php-client.googlecode.com/svn/trunk/ google-api-php-client-read-only

If you've downloaded the google-api-php-client from SVN (you won't find this in the tarball at the moment) you should find a directory of examples/analytics/, which includes a file called simple.php.

Put the google-api-php-client on your server, edit the example file using the credentials you added to the Google APIs Console, make sure you've referenced the simple.php as your callback in the APIs Console and open in your browser.

You should see a screen like the one below, which is requesting permission to connect via OAuth.

If everything works, you should see a sample application. You might have some server alterations to make if you're using security features such as open_basedir restriction which can block access to certain required functions depending on the directory in which you installed your test code.

You might also need to set the include path for the library directory. You can find out whether this is required by opening a terminal and entering tail -f /var/log/apache2/error.log and re-loading the page.

There are instructions here on how to fix your include path so you don't need to include the client libraries in every application on your server.

Or, you can download a copy of the demo file I created here, which includes a modification to the include path to make it work on an Ubuntu server.

3. Accessing the Google Analytics Core Reporting API

Inside the /examples/analytics/simple.php file you'll find some example functions which allow you to access a list of web properties (that's the list of sites you have in your account), a list of accounts, a list of all the advanced segments you've created and their settings and a list of all your goals.

The data are returned as PHP arrays, which means they're easy to manipulate from the server side, or directly within a templating engine like Smarty, if you use one. This is much better than the old method of using multiple APIs and the data are easier to handle.

You can access your web properties array by using the following code:
$props = $service->management_webproperties->listManagementWebproperties("~all");

You can access your accounts array by using the following code:
$accounts = $service->management_accounts->listManagementAccounts();

You can access your advanced segments array by using the following code:
$segments = $service->management_segments->listManagementSegments();

You can access your advanced segments array by using the following code:
$goals = $service->management_goals->listManagementGoals("~all", "~all", "~all");

4. Obtaining your profile ID

When it comes to running Google Analytics queries against your data, things get a little challenging. Not because it's difficult, but because for some inexplicable reason, Google requires you to use what it describes in the code comments as the "analytics profile ID".

Now, if you examine the output from the management functions, which return the data on the web properties, accounts, segments and goals, you'll see that they reference id, accountId and internalWebPropertyId. None of these work.

In fact, the ID you need isn't even available in the API data. To obtain it you currently have to go to the Google Analytics interface and look at the URL of the page when logged into the desired account. In version 5 of GA, you'll find the required code after the "p".

Update: I (cleverly) managed to miss a function tucked away in the API which does indeed allow you to obtain this ID computationally, so I take back my criticism! You need to use the code: 

$profiles = $service->management_profiles->listManagementProfiles("~all", "~all"); 

4. Running API queries on your GA data

Queries are running using the get() function which is part of the ga method in the apiAnalyticsService.php class.

This is called using the following code:
$data = $service->data_ga->get($ids,$start_date,$end_date,$metrics,$optParams);

The get() function requires five things:

$ids contains the ID of the profile you extracted from the URL of your account (ie ga:123456789
$start_date is a date in YYYY-MM-DD format
$end_date is a date in YYYY-MM-DD format
$metrics is a comma-separated list of metrics (ie ga:visits,ga:pageviews)
$optParams is an array, which I'll explain below

The $optParams array has six possible keys:

'max-results' => is an integer containing the maximum number of results to return
'sort' => is a comma-separated list of dimensions or metrics to sort by
'dimensions' => is a comma-separated list of dimensions to use
'start-index' => is an integer used to index the first item returned, which is used for paginating large data sets
'segment' => is the analytics advanced segment to apply to the data
'filters' => is a comma-separated list of metric or dimension filters to apply

$optParams = array('dimensions' => $dimensions, 'filters' => $filters, 'segment' => $segment, 'sort' => $sort, 'max-results' => $maxresults, 'start-index' => $startindex);

Here's a simple example which retrieves visits and pageviews by browser:

$ids = "ga:123456789";
$start_date = "2011-01-01";
$end_date = "2011-11-30";
$metrics = "ga:visits,ga:pageviews";
$dimensions = "ga:browser";
$optParams = array('dimensions' => $dimensions);
$data = $service->data_ga->get($ids,$start_date,$end_date,$metrics,$optParams);


5. Sorting data

To sort data you need to add the sort key to the $optParams array and provide one or more dimensions or metrics to sort by.

To sort by ascending pageviews, for example, you'd add 'sort' => 'ga:pageviews' to the array. This would return data with the lowest number of pageviews first.

To achieve a descending sort, in which data is returned from the highest to lowest numbers, you prefix the ga: part with a hyphen. For example, 'sort' => '-ga:pageviews'.

You can combine multiple sort dimensions or metrics by separating them with commas like this: -ga:pageviews,-ga:visits and put them in different orders to give certain items precedence.

6. Filtering data

Adding filters is much like adding dimensions, in that you just provide a comma-separated list of filters with your chosen operators or regular expressions and add them to the $optParams array using the key 'filters' => $filters, with the filters in $filters.

Filters are divided into metric filters and dimension filters, as they achieve slightly different things. The metric filters work against integer values to handle things like less than and greater than, while the dimension filters work against strings using regular expressions and operators which identify a substring.

Metric filters

You can use a single filter or use a combination of filters using either AND or OR logic. Separating filters with a comma counts as an OR statement, so the filter ga:pageviews>=100,ga:visits>=10 will return all pages which have more than 100 page views or more than 10 visits.

For the AND operator you use a semicolon instead of a comma. So ga:pageviews>=100;ga:visits>=10 will return all pages which have more than 100 page views AND more than 10 visits.

If you attempt to combine AND and OR in a single filter, OR will always take precedence.

The operators for selecting dimension based filters work in much the same way, but you can't currently combine AND dimension and metric filters in a single filter.

Dimension filters

So, for example, if you want to modify your $optParams array to include a filter to select all pages on your site which have had more than 1000 visits during a given period, but exclude that to only the posts containing the word "analytics" in the title, your filter might look like this:

$filters = "ga:visits>=10;ga:pageTitle=@analytics";

I'll cover more in the next part of this series.

6. Using advanced segments

One of the really nifty things you can do in GA is use existing advanced segments you've created using the web interface.

You can get segment ID data by running this command: $segments = $service->management_segments->listManagementSegments();.

The data returns a combination of your own custom segments, and the many advanced segments Google Analytics provides by default, such as New Visitor and Returning Visitor.

Helpfully, the array of data also includes a definition of the segment so you can see how to set up similar ones yourself via the API. Here's some example output for the default Paid Search Traffic segment.

[3] => Array
(
[id] => -4
[kind] => analytics#segment
[selfLink] => https://www.googleapis.com/analytics/v3/management/segments/gaid::-4
[segmentId] => gaid::-4
[name] => Paid Search Traffic
[definition] => ga:medium==cpa,ga:medium==cpc,ga:medium==cpm,ga:medium==cpp,ga:medium==cpv,ga:medium==ppc
)


You can select a specific segment by id, passing the value gaid::-4 to the $segments value of the $optParams array. Or, you can create your own segment dynamically.

What do dynamic segments achieve? Well, pretty much the same thing as filters. However, unlike filters you can boolean OR operators with both dimensions and metrics. Unless you need to do that, you may as well just use filters.

Miss a quote off, or do something which GA doesn't allow, and you don't get any error messages, which makes debugging a little challenging.

I've recently been working on a large analytics implementation in which I'm creating a module for an ecommerce platform which handles all of the Google Analytics events, custom variables and ecommerce tracking. 

This code sends a load of ecommerce data, a couple of custom variables and about 14 separate events, which I'm using as a way to extend the functionality of GA, by recording additional useful things, like purchase latency, cohorts and customer lifecycle data. 

Debugging Google Analytics tracking code issues  

All was going well until I spotted that not all of the expected data were appearing in GA. 

I'd been debugging the UTM GIF requests with the Firebug Firefox extension, so could see from the UTM GIF request data that the custom variables, ecommerce tracking data and 10 of the events were being added to GIF requests, but four of the events weren't. 

Code wise, everything looked OK, so I figured this must be a limit, something which the analysts from Guava kindly confirmed.  

According to this thread on the Google Analytics support forums, there is indeed an undocumented feature in the tracking code which prevents you from sending more than 10 events at once.

Apparently, the code uses something called the Token Bucket algorithm to limit the rate at which event data are accepted by the service to prevent it from being flooded with events. 

Basically, you get a token when you connect and you can send up to 10 events with that token. A new one won't be issued for another five seconds, so if you want to send more than 10 events in a short space of time you're stuffed.  

The workaround...

I've been using the PHP class SSGA quite a bit recently to send GA data from server-side code without it being displayed in the JavaScript tracking tag, and was keen to see whether it might be the solution. 

It was! I've successfully sent up to 20 events in a single page load, and I am guessing that it might even handle more, should you need it.

I am guessing that there's something in the GATC which handles the Token Bucket algorithm that's missing when you pass the data directly to GA using a server-side POST. 

Client side version?

If you want to do something similar in the client-side GATC, it's still possible. Eduardo Cereto wrote some very clever code in JavaScript which can handle this. 

Dan's technique is designed for content sites, so it runs some queries on logged-in users to find out when they signed up and uses Ruby on Rails to add the data to two custom variables for the join month and join year using the visit level scope.

He then uses the advanced segments in the Google Analytics interface to create custom segments for each cohort, say "November 2011 signups", and then selects a cohort to see how it differs in its conversion rates for his goals. 

That's a neat way of achieving it, but with only five custom variables available in the free version of GA, their use needs careful monitoring and most of mine are already full. So I've come up with a similar solution which uses event tracking instead. 

Using event tracking for cohort analysis

While event tracking probably wasn't designed to do stuff like this, I find it lends itself well to this kind of hack.

Essentially, you can use GA's event tracking feature like a database with four fields (category, action, label and value) and it will neatly store your data, crunch your numbers and allow you to segment against it. 

You'd have your work cut out to produce a similar application so easily if you weren't using Google Analytics, particularly for the data charting. Plus, it's all in one place for analysis with the rest of your data, which makes it really powerful. 

However, event tracking isn't perfect and if you use it in this way you'll need to think ahead about how the data will be displayed in GA.

It used to be the case that setting events affected your bounce rate, but the new opt_noninteraction value now overcomes this. To me, the greatest annoyance is the fact that, for no apparent reason, the value field needs to be an integer (ie. 1) and not a float (ie. 1.4).

This means you'll need to use rounding to ensure any values passed are integers, which makes the event value and average value metrics approximate.

On the plus side, if your events are purchase related, you'll still get e-commerce data for each event, so you can still get at the data, just not quite so neatly. 

How it's done

I work on e-commerce sites, so I'm running my event tracking code only when a purchase is made. I trigger the code to run only on the payment confirmation page and run a quick SQL query using PHP to get the date of the user's first order. 

I then apply that date to a PHP function which re-formats the date to provide three different values: the cohort year (ie. 2011), the cohort month (ie. 09) and the cohort quarter (ie. Q3). 

I then send these values to my Google Analytics tracking code and assign them to three different _trackEvent calls, one for "Monthly cohorts", one for "Annual cohorts" and one for "Quarterly cohorts".

It's vital that when using this technique that you don't try to send more than 10 events at once - since Google Analytics has an undocumented feature in place to prevent the server getting flooded with event tracking data.

If this is an issue for you, you might like to know I've developed a workaround for this. 

Accessing the data

As with all event tracking data, you'll find this (in version 5 of GA) under Content > Events > Overview > Cohort analysis. 

When you've had this up and running for a few months you'll develop a good picture of what your customer base looks like, which will give you the potential for more insight. 

Chart your cohorts over a period of months to see how many of the customers have returned, then see if you can use lifecycle marketing techniques to target certain cohorts and get them to return. 

Update: If you want to try the alternative way of doing this, using custom variables, then do make sure you check out Jonathan Balogh's excellent detailed guide. 

Maybe internal campaign tracking tools will be the next in the long line of new features the GA team seem to be giving us nearly every month?

It goes without saying (but I'll say it anyway, given some of the dodgy advice going around) that using the utm_campaign tracking parameters to track internal campaigns is a really bad idea, because when a user clicks an internal link that's been tagged in this way it overwrites their original source, ruining the historical GA data. 

There's also a risk that the additional campaign parameters appended to your URLs might create duplicate content issues. The Google SERPS are full of examples of this. Google probably ignores these but the same might not apply to other search engines. 

Advertising metrics

If you think about it, internal campaigns are effectively on-site advertising so I reckon they should really be measured using the same kind of metrics and KPIs we use to monitor the performance of paid search marketing. 

What GA really needs, but currently lacks, is a simple solution for monitoring internal campaigns so marketers can see the total impressions served, the click-through rate, the coversion rate, the revenue per click, total campaign revenue, average order value and numerous other metrics. 

Having the ability to see all of these would mean we're better able to optimise our on-site marketing.

However, it's really not that easy to do this without writing some code to extend the default tracking and send the data to GA, and (arguably) writing some additional code to export the data out of GA for external analysis. 

What should we be aiming to measure?

Total impressions
In order to measure the click-through rate (CTR) of our internal campaigns, we're going to need to measure how many times it's been shown to visitors by recording each time an ad is displayed.

Click-through rate
To determine how well our ads are enticing customers to click we're going to need to measure the gross clicks for each ad unit and then calculate the click-through rate for the individual ad shown. 

Transactions
To allow us to see how many transactions an ad has resulted in, we're going to need to record all transactions which resulted from an ad click or which should be attributed to the ad. 

Campaign revenue
We'll also need to know how much revenue the campaign creative drove in total. That needs to be based around similar criteria to those we set for the transactions measurement. 

Average order value
What was the average order value across all of the transactions for this creative? We can work this out from the total value of the transactions and the total number of transactions. 

Conversion rate
To get our conversion rate, showing us the effectiveness of the ad in converting people who clicked it into purchasers, we'd simply need to know the number of unique clicks and the number of transactions.  

How can we measure it?

In terms of implementing a system to record all the required data in Google Analytics we've really got three main options: virtual pageviews, site search and event tracking.

Virtual pageviews would also allow us to capture some of the data, but they're a bit limited for stuff like this.

Justin Cutroni's site search method is another option. This works by adding an additional custom parameter to each campaign URL and then parsing this data out in a separate profile using Google Analytics' built-in site search feature. 

However, event tracking allows you to capture pretty much everything in the list above but in a much neater way than the other two methods.

It can be used to track the impressions on the ads, the clicks and the resulting purchases and their values.

It's also easily built into your e-commerce platform, so you can set-up a permanent tracking implementation without the need to configure anything in your GA account. It's the hands down winner for implementing this, in my opinion.

Let's assume we're using a slider promotion on our home page and want to set up event tracking to record all of these data. How could we set that up?

Step 1: Recording ad impressions

In order to calculate the number of impressions served, we need to add event tracking to the JavaScript code which displays each frame of our promotional slider.

We want to record an event in Google Analytics each time the campaign slide is shown on the page so we can record the total number of impressions for each slide in our slider widget.

It used to be the case that using event tracking for such passive events would cause a non-bounce, thereby affecting the site-wide bounce rate and messing up your data.

However, a new _trackEvent parameter called opt_noninteraction now makes it feasible to do passive event tracking without affecting bounce rate.

Each time a new slide is displayed you need to fire some code like this: _gaq.push(['_trackEvent','Campaign impressions','Home page slider','Summer sale','',true]);

Here we're creating an event category called 'Campaign impressions' for all of our impressions data, adding an action called 'Home page slider', setting the label to the name of the slide 'Summer sale', passing a null value, and importantly, setting the non-interaction value to true. 

This will record all of the impressions served on the slider as a whole, and the Summer sale slider specifically, from which we'll be able to calculate a number of other metrics.  

There is a risk to this, though. You're only able to record 500 bits of hit-level data per session, and it's feasible that if you use this heavily, you could reach the limit, and lose important bits of transactional information. Consider the risks before implementing it, or consider sending the data to a separate tracker.  

Step 2: Recording ad clicks

Recording ad clicks is pretty straightforward, since we can just attach our code to an onclick handler in the href for the campaign. For example, onclick="_gaq.push(['_trackEvent','Campaign clicks','Home page slider','Summer sale','',false]);" 

Besides the event which records the original click on the event, I'd also recommend firing a _setCustomVar() function with a session level scope.

If a user clicks on the 'Summer sale' slide of the 'Home page slider' we'll be able to see whether they purchased as a result of the click, allowing us to get a conversion rate for each slide. 

Step 3: Calculating the metrics from the data

Total impressions: The total impressions for each slide in a slider will be available from Content > Event tracking > Categories > Slider name > Slide name. You'll be able to use the date selector tool to find the number of impressions for a given period for your reporting.

Total clicks: We can find the total number of clicks for a slide by going to Content > Event tracking > Categories > Campaign clicks > Slider name > Slide name.   

Click-through rate: To calculate the CTR for the slide, divide the total impressions by the total clicks. 

Campaign revenue: Go to Content > Event tracking > Categories > Campaign clicks > Slider name > Slide name and look in the e-commerce tab under revenue. 

Average order value: You'll find the average order value for a given slide at Content > Event tracking > Categories > Campaign clicks > Slider name > Slide name under Average Value.   

Conversion rate: Divide the total clicks by 100 then multiply the value by the total number of transactions to get the conversion rate for the individual slide.  

How can we further improve performance?

Now you've got access to these important metrics, you'll be able to look at the performance of your promotional sliders and slides and see which ones work, and which ones don't.

You can then start tweaking them to see if you can improve their performance.  

A/B testing or multivariate testing is a really obvious way of trying out different variants, and if you integrate Google Website Optimizer with Google Analytics, you can also take advantage of segmentation to look for trends beyond the bottom line. 

If you know that customers from a certain segment are more likely to respond to a different creative, then you'll need to try and target that at them.

That's relatively straightforward for individual products and gives you some insight into which products you ought to be promoting as cross-sells and up-sells on particular pages. 

However, you need to automate the process using the Google Analytics Data Export API in order to make it really useful.

Using the Data Export API

The Data Export API currently provides read-only access to authenticated users, allowing you to query your Google Analytics data in much the same way as you would through the graphical web interface. 

The Data Export API queries are based around often complex URLs containing the desired query parameters, so there's a URL structure to determine for each request.

Helpfully, there's a useful tool available in Google's Data Export Labs called the Data Feed Query Explorer which simplifies the process of fine-tuning your API query URL so you can use it in your application.

There's also an excellent guide you'll want to refer to.

I'd recommend using the graphical interface to GA first of all and then trying to replicate your query via the Data Feed Query Explorer to help make the URL, and check that it works as intended. It really makes life a lot easier when you're working with the API.

Some examples to try

There are loads of different ways in which you could use this data in product or content recommendations.

These are just the basic ones I can think of, but if you start using it with event tracking or custom variables there's even more potential for getting even more detailed data out of GA to help you with recommendations.

1. People who view this page ultimately purchase

The classic Amazon-style product recommendation which tells you what customers ultimately purchase after viewing a given page is quite easy to achieve via the API.

The only dynamic data you need to pass to GA is the relative URL of the page (as it will be shown in GA) and the date range you want to select data for. You can restrict the number of results returned to speed things up. Try it here.

https://www.google.com/analytics/feeds/data?ids=ga%3A123456789&dimensions=ga%3AproductName%2Cga%3AproductSku&metrics=ga%3AuniquePurchases&segment=dynamic%3A%3Aga%3ApagePath%3D%3D%2Fyourpage.html&sort=-ga%3AuniquePurchases&start-date=2011-10-08&end-date=2011-10-22&max-results=50

2. People who bought this product also purchased

Unlike some of the server-side recommendation engines, which look at purchases made by customers from historic data, this one only uses items from the same transaction, because GA doesn't link transactions to individual customers across multiple visits.

It's therefore only any good for providing basic cross-sell recommendations.

If you want to do a more sophisticated cross-sell, based on products other owners own, you'll need to export the data and link them to the customer ID and do the analysis and recommendation outside the GA API.

You need to select the ga:productName dimension, the ga:uniquePurchases metric, and the dynamic segment dynamic::ga:productSku=~ and then order by descending uniquePurchases using -ga:uniquePurchases.

You'll also want to add the filter ga:productSku!=YOURSKU so the recommendations exclude the SKU you passed to the API. Here's a live example.

https://www.google.com/analytics/feeds/data?ids=ga%3A31234567&dimensions=ga%3AproductName%2Cga%3AproductSku&metrics=ga%3AuniquePurchases&segment=dynamic%3A%3Aga%3AproductSku%3D%3DYOURSKU&filters=ga%3AproductSku!%3DYOURSKU&sort=-ga%3AuniquePurchases&start-date=2011-10-11&end-date=2011-10-25&max-results=50

3. Best-selling products this period

Want to show your customers a dynamically-generated list of your best selling products this week, today or this month? This is also quite easy to achieve.

You need to provide the ga:productName and ga:productSku dimensions, the ga:uniquePurchases metric and then sort by descending number of purchases by using the parameter -ga:uniquePurchases.

You can set the start-date and end-date to whatever period you want your best sellers to cover, ie this week, this month, today, this year. Here's an example.

https://www.google.com/analytics/feeds/data?ids=ga%3A1234567&dimensions=ga%3AproductName%2Cga%3AproductSku&metrics=ga%3AuniquePurchases&sort=-ga%3AuniquePurchases&start-date=2011-10-11&end-date=2011-10-25&max-results=50

4. Best-selling products for visitors from this referring URL

If you sell a diverse range of products and receive reasonable levels of traffic from niche sources only interested in certain product ranges, you might want to target them with the most relevant offers.

For example, if you sell mountain bikes, skis and surfboards and want the visitors coming from the surfing sites to see recommendations only for surfing stuff, you could target them based on their referring URL.

To do this you'd simply add the name of the referring site to a dynamic segment and get back a list of products most visitors from this source have purchased.

You could also combine a list of related sites using regular expressions, so all of the surfing URLs result in the same recommendations. Here's an example.

https://www.google.com/analytics/feeds/data?ids=ga%3A1234567&dimensions=ga%3AproductName%2Cga%3AproductSku&metrics=ga%3AuniquePurchases&segment=dynamic%3A%3Aga%3Asource%3D%40somesite.com&sort=-ga%3AuniquePurchases&start-date=2011-10-11&end-date=2011-10-25&max-results=50

5. People who arrive via this keyphrase ultimately purchase

This one works in much the same way, but instead of using a page path you use the keyword phrase the user arrived with, ie "lenovo laptop".

This one might be scuppered by Google's recent introduction of SSL searching by default, as that now strips off the keywords from the URL when the user is logged-in to their Google account, but it should still work for quite a lot of searches.

However, although it seems trivial, to get more accurate results you're going to need some fancier querying.

You'll need to parse out the referring keywords from your search URL, use explode() to break up the keywords and then add them to a filter.

I've used the filter ga:keyword=@lenovo,ga:keyword=@laptop to do this. The comma between the first and second filters acts as an OR. There's more about this in the data feed guide. Here's a live example.

Automating it...

Obviously these are just a starting point.

You can apply the same techniques to getting recommendations for other articles readers may want to read based on the page views of other users; the typical products users purchase after making an internal search, or countless other things.

To automate these queries and turn them into a working recommendation engine, you'll need to do a bit of server-side coding and make sure you take advantage of caching.

The queries take a second or two to execute so you'll want to make sure they only get executed every now and then, with the result being cached and subsequent recommendations made from the cached data to improve performance.

If you can't be bothered with any of this, check out LiftSuggest, a product recommendation engine designed specifically for doing this using the GA API. There are both free and paid versions.

Using the client-side method, the data is sent in the clear to Google so inquisitive developers can look at the JavaScript code or the GIF query string to see what data you're sending. 

I'm a big fan of using event tracking to extend the functionality of GA and find it a really useful tool for recording useful e-commerce metrics such as purchase latency, which GA doesn't record by default. (Check out my post for Econsultancy on such "passive events", which explains how that's done.)

I also wanted to take advantage of passive non-interactive event tracking to record some other business critical metrics, such as item profit, item margin, basket profit and basket margin so they could be integrated into my reporting and analysis directly through the GA interface.

However, I don't really want customers or competitors finding profit or margin data in the JavaScript code or GIF data.

I've therefore been looking for an effective server-side solution for sending event tracking data to the Google Analytics server without the need to use either JavaScript or the GIF - and now I've found one. 

Server-Side Google Analytics

The Server-Side Google Analytics class (SSGA for short) is an open source PHP class available from Google Code which aims to tackle precisely the problem I've been facing (and a few others I'll outline later).

The Server Side Google Analytics (SSGA) class relies on the Zend framework's HTTP client to send data to the GA servers, which means you'll either need to install Zend on your server or include a local copy and manually set its include_path. If you don't mind getting your hands dirty you could replacing this dependency with cURL instead, but Zend HTTP works well enough. 

Like the current JavaScript and mobile server-side code, SSGA works by constructing a query string containing the various name=value pairs, but rather than loading a GIF it uses the Zend HTTP client to make the request from the server side.

This means that data can be sent to GA without the need to load up either the JavaScript tag, GIF or cookies keeping the data away from prying eyes. It also means you can use the class in situations where there's no physical page view, such as via a cron job or other server-side process. 

How it works

All you need to do is include the SSGA class, pass your account ID (ie UA-1234567-8) to the setAccountId() function, pass your hostname to setHostName and include a page title and page name for setPageTitle() and setPageView(). These last two can be fictitious if you like, as this then won't skew your existing data.

For each event you want to record you need to provide four values to the setEvent() function, and then use createEvent() to send the data.

The values passed to setEvent() are the same category, action, label and value used by the client-side _trackEvent function and the data you pass to them needs to be in a similar format. 

Unlike the client-side API, SSGA converts spaces in the category, action or label to + so you'll want to bear this in mind when categorising your event tracking data. Like the client-side API, the value needs to be an integer, not a float, so don't you'll need to use round() or ceil() to get rid of the decimal point. 

Once the code is executed, you should see your event tracking data appearing in Google Analytics under Content > Event tracking > Categories, usually after an hour or so. 

I've used this method to record the item profit and item margin of each item purchased, the basket margin and basket profit, and other metrics such as the overall product rating and the number and percentage of negative reviews.

However, there are many ways in which you could use the same or similar techniques. You could use it to enhance mobile tracking (in which the current server-side solution doesn't provide functionality for event tracking or other sophisticated features), record cron-based scripts, track redirects or use this as a back-up in the event of the EU cookie directive preventing you recording e-commerce tracking data.

Using SSGA also helps overcome the Token Bucket algorithm limitation of event tracking, which prevents more than 10 events being sent for a given token.  

3 key reasons why server-side GA is useful

1. You can send more confidential data, such as profit and margin, to the GA servers without it being seen in your source code.

2. You can send additional data, bypassing things such as the 10 events per token limit.

3. You can send data when cookies and JavaScript are disabled, making it useful for mobile sites and for those affected by forthcoming EU cookie legislation. 

If server-side Google Analytics are your cup of tea, you might also be interested in this more recent guide to using the related PHP-GA PHP class to hack a cookie-less GA implementation.

If you're using paid search to acquire customers, you're also throwing money away and the customers are much more likely to bounce when they land on a page containing products they can't purchase. 

I'm told that not many companies measure this and unfortunately Google Analytics doesn't measure this sort of thing by default. However it's quite easy to add this functionality yourself via a relatively straightforward hack.

You'll need to do a spot of coding, but the results are really useful and it's a quick and easy job for the average developer. I implemented this on three e-commerce sites in just a few hours.

Once it's up and running, you'll be able to see which products have fallen out of stock, examine the products that you regularly run out of, and also see which ones are being seen the most by your customers - indicating the greatest loss of revenue.

You could set up automated reporting so the data gets emailed to you every day or week, allowing you to beat your stock control manager with a stick for dropping the ball and losing you sales.

With a bit more effort you can also create some code which allows you to record the actual value of sales you lost because you sold out of certain items, which can be a really useful KPI to help drive improvements in stock management. 

Step 1: Querying the database

First, you'll need to create a database query to determine whether the item on your product page has fallen out of stock.

Everyone's database will be different, but basically, you need to run the query and then get a true or false value indicating whether the product is in-stock or out-of-stock.

Your query might look a bit like this: SELECT stock_level, product_name, sku, price FROM products WHERE id = '1234'

If your query returns zero, indicating that the product is out of stock, you'll need to get the product name, SKU and price and write the information to the Google Analytics tracking code (GATC).

Step 2: Modify your GATC

Precisely how you need to modify your GATC will really depend on how much you've already pimped up your Google Analytics implementation.

On the average site in which you're just using the default tag the Google Analytics Tracking Code (GATC) will just be included in the bottom of the page.

For more sophisticated sites, the GATC will be being created dynamically and the server will be writing in additional data into extra variables depending on the page being viewed.

Within your GATC, you'll need to write the following trackEvent code and push it to the Google Analytics server. It will add the data to a category called "Out of stock items", along with the product name, the SKU and the price.

_gaq.push(['_trackEvent','Out of stock items','Apple iPad 2','2528',399]);

Oddly, Google Analytics won't allow you to use a decimal point in a value passed in the trackEvent, so you'll need to round up the price of the product to the nearest whole number.

You can do this easily using a ceil() type function in your server-side language or the database query itself.

Step 3: Accessing the raw data

Every time a page is viewed, the server will check to see whether it's in stock. If it's out of stock a line will be written to the GATC which sends the additional data to Google.

This obviously works most reliably when you have a single product or SKU per page. You could use it with multiple SKUs per page, but the data might not be so clear and it's going to be trickier to interpret.

To access the data, using the older version of Google Analytics go to Content > Event Tracking > Categories > Out of stock items.

The basic report will show you Total Events (the number of times a page with an out of stock product has been viewed), Unique Events (the number of times those pages have been viewed by unique users), Event Value (the price of each product viewed multiplied by the number of page views) and the Average Value (the average value of each product viewed).

Step 4: Calculating the approximate total value of lost sales

The quick and dirty way to calculate the total value of sales lost due to running out of stocks of the products you sell is fairly easy to do. 

Take the total event value, say £1,234,567 and divide it by 100 and then multiply the value by your overall site average conversion rate, say 5%, to get the total estimated value of lost sales, which is £61,728.35.

This really only works accurately on sites in which there's a single product/SKU per page, and doesn't take into account differing conversion rates for different products, but it's interesting nonetheless.

Step 5: Calculating the precise value of total lost sales

If you want greater precision, you'll need to use the actual conversion rate for each product, and not the overall site average conversion rate.

This is because many products differ greatly in their conversion rates. Those items which are on sale might be selling quickly with high conversion rates, while other items might be less keenly priced and sell more slowly.

Complicated products which require lots of prior research also tend to have lower conversion rates than cheaper commodity items. 

For example, let's say we're looking at an iPod Touch, which has an average value on our site of £184. 744 visitors viewed it over our selected period, and it was out of stock several times for quite long periods, resulting in total event value of £175,904. 

The product has a 2.3% conversion rate, so we can therefore see that by running out we lost around £4045.79.

 Click the product name in the Content > Event Tracking > Categories > Events tab and you should see a report which shows how many times over your selected time period your chosen product has fallen out of stock.

We can also see from the individual product's charts that it was in stock for several weeks, then sold out, then came back in and sold out after a few days, and did the same thing several times. 

If a product is falling out of stock regularly, customer demand might be exceeding your supply, which suggest you need to increase your stock levels, which should allow you to sell more. You definitely shouldn't be running out of stocks of your best selling lines. 

Step 6: Automating it

If you're happy with an approximation, you can set up Google Analytics to send you an automated report every day or week to let you know which products are out of stock, and to report the total value of lost sales. You'll need to manually calculate the estimated revenue loss by using your average conversion rate. 

If you want to get more detailed results, you'll need to write an application using a server side language, such as PHP, which queries the Google Analytics server to retrieve the data via the API, and then uses the conversion rate for each product to determine the actual value of lost sales.

That's a bit of a time consuming task and too lengthy to explain here, but it's probably worthwhile if you've got stock control issues that need to be monitored carefully. 

KPIs

There are a few KPIs I've found useful to report with this data:

1. Total visits encountering stock-outs

2. Total revenue lost per visit due to stock-outs

3. Percentage of visits encountering stock-outs

4. Total revenue lost 

Caveats

1. Of course, this will only work when products that are out of stock are viewed. If you've got some obscure products that have fallen out of stock without being noticed, and their product pages don't get viewed for a while, there's going to be a delay in spotting the trend via GA.

2. It's a hack and GA wasn't designed to do this, and when you view the data in GA it doesn't mean that much, particularly when you view the colour coding when different time periods are compared. 

3. Using a site-wide average conversion rate is risky and only gives a rough approximation. To get detailed figures you'll need to use the individual product conversion rates, which requires much more effort.

4. This won't tell you when a product is going to sell out, or make any predictions on how you need to adjust stock levels. If you want to do that you'll need to build the functionality into your ecommerce platform.  

Unsurprisingly, one of the first to implement an opt-in was the ICO itself - a whole three days before it became law.

It added a box to the top of its site which informed the user that parts of the site used cookies and that it wished to track users with Google Analytics.

It then asked them to check a box to opt-in to providing their consent to do so. 

Freedom of information

In a very clever move, web analyst Vicky Brock contacted the ICO and requested data on their site visits before and after they implemented a cookie opt-in system at the top of every page using the Freedom of Information Act.

The data she obtained are fascinating.

They show that only around 10% of site users provided their consent to the ICO to allow it to use cookies. 

It's a worrying indication of where we're heading, but it's not altogether surprising.

Opt-in versus opt-out

Rather than the current situation in which users opt-out of being tracked, such as by blocking cookies, using existing global cookie opt-outs provided by web analytics firms, or by using the 'do not track' feature of their browser, we're being forced to get users to opt-in. 

However, benign and anonymous the tracking may be, I can't really imagine that too many people are going to opt-in to providing their consent to being watched - particularly given some of the sensationalist stuff printed in the mainstream press about both cookies and web tracking.

After all, tracking provides little value to the customer, so why should they bother? Indeed, asking customers if we can track them might even turn some of them off, maybe even acting as something which drives abandonment or reduces purchase conversion rates.

That 10% figure the ICO recorded might well prove to be better than many other sites manage.

Once analysts were concerned mainly with monitoring the conversion rates of getting users to complete purchases or sign up to email newsletters, now it seems we might also need to start considering the conversion rate of how many customers allow us to track them. 

Perhaps not the sort of conversion rate optimisation many would prefer to be doing...

What's the solution?

Given the incredibly small number of sites who appear to have implemented an opt-in system so far (I reckon I've seen less than half a dozen sites attempting to fully comply with the new regulations), there's no definitive answer on which solution works best. Indeed, before the data Vicky obtained, we were all completely in the dark.

Personally, I can't really see conventional cookie-based web analytics tools continuing to provide much value to those operating within the EU unless they change.

If we really are going to be forced into getting permission from our users in order to track them and manage our sites efficiently then maybe we really need to move away from cookies. 

I know that I'd struggle to do my job if I only had access to data on 10% of my customers' behaviours, so unless the web analytics providers help us out by implementing an alternative solution, I think many of us are going to have some challenges ahead to face.

I'm already working on an in-house server-side solution which will handle much of our e-commerce analytics, but when it lacks cookies it really only scratches the surface of what's already possible and commonplace with tools like Google Analytics and Site Catalyst.

However, it's certainly going to be a lot more useful than incomplete data covering maybe 10% of our customers. It's an unfortunate position to be in, when the EU could have simply laid down the law in other ways, such as allowing users to opt-out via their browser.

If you're interested in this do check out this excellent post on Brian Clifton's site. 

Since QR codes are readable by both dedicated QR code readers and the barcode scanners available freely for most smartphones, including iPhone and Android devices, they're fast becoming popular. 

Already used in industry, they're now catching on with marketers who want to give users easy access to URLs via their customers' smartphones.

Thankfully, QR codes are fairly easy to generate and you can even track their usage in Google Analytics.

Step 1: Generating a trackable URL

Since we're including a URL in our QR code, we want to be able to easily track how many people have visited our site as a result of following this specific code.

We can do that very easily with Google Analytics' campaign tracking parameters.There's a detailed guide to using campaign tracking here.

All you need to do is take your existing URL, append some tracking parameters so the visits are automatically labeled and segmented in Google Analytics.

Take your original URL and add a value for utm_medium, utm_source and utm_campaign using values that have been URL encoded.

If you've got no ? in the URL, add the first tracking parameter with a ? and add ampersands for the subsequent ones. For example, http://yoursitenamegoeshere.com would become http://yoursitenamegoeshere.com?utm_medium=QR+code&utm_source=Billboard&utm_campaign=Product+launch

If a ? is already present then just append the tracking with ampersands. For example, http://yoursitenamegoeshere.com/page.php?id=1234 would become http://yoursitenamegoeshere.com/page.php?id=1234&utm_medium=QR+code&utm_source=Billboard&utm_campaign=Product+launch

Step 2: Shorten the URL

Since there's a limit to the number of characters you can fit in a QR code, it makes sense to use a URL shortening service to turn your lengthy trackable URL into a shortened version.

If you're manually generating your QR code you can simply enter your trackable URL into a URL shortening service such as bit.ly or goo.gl and it will make it into a much shorter version.

When the user clicks the URL they'll hit the URL shortening service which then redirects them to your longer URL with the tracking appended to the end.

Step 3: Generate a QR code

Now you've got your URL, you need to convert it into a QR code. You can do this very easily, and automatically, using the Google QR code API or you can use my QR Code Generator which will also add the Google Analytics tracking parameters of your choice and shorten the URL for you.

If you want to use the API, as I am doing with my QR Code Generator, you'll need a little PHP function to handle the data and get the URL of the QR code image. 

function generateQrCode($text,$size){
  $url = "http://chart.apis.google.com/chart?cht=qr&chs="

   . $size . "x" . $size . "&chl=" . urlencode($text) . "&chld=H|0";
  return $url;
}

Combine your string of text and the URL into the $text variable, define a size (say 400) and the function will pass this to the Google API and return the URL of your QR code. 

The text you pass to the API needs to be UTF-8 and URL encoded. There's a 2K limit on the URL, which is another reason why it makes sense to use a URL shortener.

Step 4: Test the QR code

Once you've put it all together you should have a QR code containing your string of text and the shortened URL.

Use the barcode scanner on your smartphone (the Android Barcode Scanner is great), point it at the screen and it should recognise the code and display the text and URL on the screen of your phone. 

Click the shortened URL and it should redirect you to your target site, complete with the Google Analytics tracking codes appended to the end of the URL. 

Step 5: Track the QR code in Google Analytics

When a user clicks the link in your QR code to follow it to the target site they'll first hit the shortened URL, which will subsequently redirect to your longer URL featuring the Google Analytics tracking parameters. 

Your Google Analytics tracking code will automatically detect the presence of these in the URL of the landing page and will pass them back to your GA profile.

When you next visit your account profile, look under Traffic Sources > Campaigns and you should see your QR Code campaign listed.

Or...

Simply use my QR Code Generator which takes care of the URL shortening and adds the tracking parameters of your choice.