Migrating to Universal Analytics: user IDs, dimensions, events

Classic Analytics ran on ga.js and stored several cookies in the browser. Universal Analytics runs on analytics.js, stores a single first-party cookie, and moves most processing to Google's servers. The practical consequences are these.

• Session and campaign timeouts, referral exclusions and search-term exclusions are configured in the property settings instead of the code.
• Custom variables are replaced by custom dimensions and metrics: 20 of each in the free version, 200 in Premium.
• A Measurement Protocol lets you send hits from any device or system, so point-of-sale, call tracking and CRM data can land in the same reports.
• The User ID feature stitches sessions from the same logged-in person across phone, tablet and desktop.
• Events, ecommerce and social interactions are sent with a simpler syntax, and a new Enhanced Ecommerce plugin, announced this spring and rolling out in beta, adds product impression, cart and checkout funnel reporting.

Reports look much the same. The underlying model has changed from "visits" to "sessions" and from "visitors" to "users", and the data is more accurate as a result.

Google splits the upgrade into two steps: a property transfer, which it will do for you, and a tracking code update, which you must do. Treat the whole thing as a project with a test view.

1. Inventory what you have. List every custom variable, event, virtual pageview, ecommerce call, cross-domain setup, goal and filter in the current property. Most of this lives in the code and in the view settings; write it down in one document.
2. Transfer the property. In the Admin section, under Property, choose Universal Analytics Upgrade and start the transfer. It takes 24 to 48 hours, during which classic data keeps flowing.
3. Create a test view. Add a new unfiltered view and a filtered one that matches production, so you can compare numbers before and after.
4. Rewrite the tracking code. Replace the ga.js snippet with analytics.js on every template. If you use Google Tag Manager, switch the tag type to Universal Analytics and reuse your existing triggers; this is the easiest path and the moment to adopt Tag Manager if you have not.
5. Re-implement custom variables as custom dimensions. Define each dimension in the property first, note its index, then send it from the code with the new syntax. Decide scope carefully: hit, session, user or product.
6. Convert events, ecommerce and virtual pageviews. The ga('send', 'event', ...) and ga('send', 'pageview', ...) forms replace the old _trackEvent and _trackPageview arrays.
7. Move settings out of the code. Session timeout, campaign timeout, referral exclusions (add your own domain and any payment gateway) and organic search sources now live in Admin.
8. Verify. Run the site with the Google Analytics Debugger extension, check Real-Time reports, then compare a week of data in the test view against the classic property. Expect small differences in sessions and bounce rate; expect large ones only if something is wrong.
9. Switch and document. Remove the old code everywhere, update annotations with the migration date, and keep the inventory document as the measurement plan.

Twenty slots are plenty if you use them for questions you will actually ask. The dimensions below pay for themselves on almost every business site.

• Logged-in status (session scope): compares behavior of members and visitors.
• Customer type or plan (user scope): new versus returning buyer, free versus paid, trade versus retail.
• Content attributes (hit scope): author, category, publish date and word count for any site that publishes.
• Form or lead type (hit scope): which inquiry form, which product line.
• Internal traffic flag (user scope): set from the office network or a cookie, so a filter can remove staff.

Custom metrics are worth adding for things that are counted rather than categorized: leads by value, articles read to the end, errors shown. Keep a single register of indexes, names and scopes; a dimension sent to the wrong index is almost impossible to untangle later.

Universal Analytics makes events easy to send, which is exactly why they turn into a mess. Agree a convention first and record it in the measurement plan.

Use Category for the type of object (Video, Form, Download, Outbound Link, Navigation), Action for what happened (Play, Submit, Click, Complete), and Label for the specific instance (the file name, form name or URL). Keep capitalization consistent; "Form" and "form" are two categories in reports. Decide which events count as interactions and which do not, because non-interaction events keep bounce rate honest for things like scroll tracking.

Then turn the events that represent business outcomes into goals, and assign goal values even if they are estimates. A site with ten well-named events and four valued goals produces more useful reports than one with two hundred events and none.

User ID is the feature that justifies the migration for any site with accounts. When a visitor logs in, you send your internal user identifier with each hit; Google Analytics then creates a dedicated User ID view in which sessions from the same person are joined across devices, with cross-device reports showing device overlap and paths.

Three rules. The identifier must be your own non-personal ID, never an email address or name, and your privacy policy must say what you collect. The User ID view only contains sessions where the ID was sent, so keep your regular views alongside it. And enable session unification so that hits before login in the same session are attributed to the user.

The Measurement Protocol extends the same idea offline: a CRM can send a "lead qualified" event with the user's client ID or user ID, and a call tracking vendor can log calls as events, so the reports finally show what happened after the form.

Running both snippets. Doubled sessions and a bounce rate near zero are the giveaway. Audit every template and every plugin that injects analytics code.

Forgetting referral exclusions. Without your own domain and your payment processor in the exclusion list, every return from PayPal starts a new session and steals the conversion credit.

Skipping the test view. Comparing against last month is not a test. Run the two implementations side by side for at least a week.

Reusing dimension indexes. Once an index has meant one thing, retire it rather than repurposing it.

Sending personal data. Email addresses in URLs, in events or in User ID violate the terms of service and can get the property terminated.

Discover: we inventory your current implementation, the goals and reports people actually use, and the systems, such as CRM, ecommerce platform and call tracking, that hold the rest of the customer story. Plan: we write a measurement plan that defines events, dimensions, goals, views and filters, and agree what questions the reports must answer. Build: our systems integration team implements the tracking through Google Tag Manager, connects offline data through the Measurement Protocol, and our web team makes the template changes, with the growth team setting up goals, dashboards and campaign tagging standards. Improve: we validate for a month, then review quarterly as the site and the business change. Because brand, growth, web and technology sit on one team, the measurement reflects the whole customer journey rather than one department's slice of it.

The Digital Transformation engagement is the representative example. A multi-site business with inconsistent classic Analytics installations consolidated onto Universal Analytics through Tag Manager, with a single measurement plan, custom dimensions for customer type and region, User ID for its account holders, and CRM outcomes sent back through the Measurement Protocol. The result was one set of reports in which marketing spend could be followed through to qualified leads and repeat purchases, which changed how budgets were set the following year.