Upgrading to Universal Analytics Without Losing Events

The code pasted in years ago

Many small business sites still carry the classic Google Analytics code, added when the site was built and not looked at since. It loads a file called ga.js.

Universal Analytics, Google's current version, uses a different file and a different way of sending information. New features are being added to Universal Analytics, not to the classic code.

Swapping the main code takes a few minutes. The visits graph carries on, the reports look normal, and the job appears to be done.

What breaks is everything else the old code was doing on buttons, forms and downloads, and it breaks without warning.

What the old code was quietly recording

• Events on buttons, such as taps on the phone number or a booking link.
• Downloads of brochures, price lists, menus and forms.
• Virtual pages, recorded when a form sends without loading a new page.
• Outbound links to a booking system, a map or a supplier.
• Custom variables marking members, staff or logged-in customers.
• Ecommerce lines on the order confirmation page.

The third does the most damage. A goal built on a virtual page simply stops completing, and the goal report shows fewer enquiries, as if the month had been slow.

Why the old lines stop

Each of those pieces is a short line of code written for the classic version. Event lines, for example, usually contain _gaq.push and _trackEvent, with the event's names inside.

Once ga.js is removed, nothing on the page reads those lines any more. They cause no visible error. The button still works, the download still opens, and the event is never sent.

Universal Analytics expects the same information written in its own format. Until each line is rewritten, the new code records page views and little else.

Nothing in the reports announces the gap, which is why it often goes unnoticed for months.

Make the list before touching anything

The most complete record of what the old code sends is in Analytics itself.

Open the Events report for the past year and export it. Every category, action and label listed there was sent by a line somewhere on the site, including lines nobody remembers adding.

Then note every goal in the view settings, with its type and exactly how it is defined: a destination page, a virtual page or an event.

Finally, search the site's theme, templates and plugins for _gaq, _trackEvent and _trackPageview. Each match is a line that will need rewriting.

Rebuild each piece

Every event line gets rewritten in the Universal Analytics format, keeping the same category, action and label wording, so that goals built on those events still match.

Virtual pages are rewritten the same way. Custom variables become custom dimensions, which have to be set up in the property settings before any code can use them.

Ecommerce tracking needs new code on the confirmation page, and many shopping carts have a setting that switches it over.

Google Tag Manager is worth considering here. It can record clicks and form submissions from one place, rather than through code scattered across every page.

A worked example

A woodworking school runs evening and weekend courses in a shop with a dozen benches: furniture making, joinery, turning and a one-day introduction for beginners.

Its site was built in 2011 with the classic code. The developer added events for downloads of the course calendar and for clicks on each register button, which opens an outside booking system.

Last spring the school's administrator pasted in the Universal Analytics code after reading that the old version was out of date. The visits graph carried on as before.

Register clicks dropped to nothing that week, and the goal built on them stopped too. Nobody looked until the autumn planning meeting, when the owner asked which courses drew the most interest.

The old event lines were rewritten, a test click on each register button appeared in the Real-Time report, and an annotation marked the gap.

Six months of clicks were gone for good. The booking system's own records filled part of the hole, and that year's planning leaned on those.

Test the same day

Put the main code and the rewritten lines in together, then test before anyone forgets what changed.

Open the Real-Time report in one window and the site in another. Click each tracked button, download each tracked file and send a test enquiry, and watch each one arrive.

Use a view without filters for this. A filter that removes the office's own visits will hide the test too, and make working code look broken.

Check the ordinary reports again a week later.

Mark the date

Add an annotation on the day of the switch. Anyone comparing this year with last will then know why a line in a report changed shape.

Some figures can shift for technical reasons. An event that fires by itself, such as a video starting as the page loads, counts as an interaction unless it is marked otherwise.

If a rebuilt event loses that setting, the bounce rate drops overnight. Keep it as it was, and let the annotation explain anything that still changes.

Who should make the change

The swap touches the theme, the plugins, the forms and sometimes the shopping cart. It is a small job for someone who knows both versions, and a risky one for someone working from a forum post.

Whoever does it should hand over the list, the rewritten lines and the test results, so the next person knows what the site records and why.

The counter-case

A small brochure site with no events, goals or downloads has nothing to lose. For it, the upgrade really is a code swap, done in minutes.

A site due to be rebuilt within a month or two can wait, since the classic code still reports today. Make the list now anyway, while the old setup is there to read.

For every other site, the order matters: list what the old code records, rebuild each piece, and test it all on the day of the swap.

The order to do it in

1. Export the Events report for the past year.
2. Write down every goal and how it works.
3. Search the site's code for the old lines.
4. Rewrite each line for Universal Analytics.
5. Swap the main code on the same day.
6. Test every event in the Real-Time report.
7. Add an annotation marking the switch.

Step one is the safety net. The Events report is the only complete record of what the old code was sending, including lines added years ago by someone who has since moved on.

Annotations, and why a graph needs context before anyone judges a month, are covered in a cold snap in the visits graph.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.