Custom Definitions in Universal Analytics: A Case Study

In this post, I will cover some of the benefits of using Custom Definitions in Universal Analytics, as well as have a look at how they are leveraged in practice by startup The Beta Family, a crowdsourcing platform for beta testing apps. In short, Custom Definitions are a way of sending custom meta data from your website or application to Google Analytics. I will not go into more details about the foundations of Custom Definitions here, except to mention that they are really easy to implement once you get the hang of it. You can read more about them at the help center available here.

Ever got stuck contemplating what Google Analytics methods to use in your implementation? Or how to best present them in a report so that your colleagues will understand the data? An inherent limitation of many analytics tools is, unfortunately, a layer of complexity that is the jargon of the tool itself. The usage of different hit types, how data is surfaced in reports, and all the particular quirks which only the most eager Analytics-fanatic learn over time can really stop you in your tracks in communicating data clearly.

The availability of Custom Definitions in Universal Analytics is a big step in the right direction for this particular issue. They enable highly customized reports that will make sense to people on a larger scale. It may sound trivial, but the implication of being able to name your own metrics and dimensions can be huge. It means that you remove an obstacle which can obstruct the effectiveness of data to an organization simply because people don’t understand it fully.

For example, instead of knowing what an event or a unique pageview represents in Google Analytics, and how they should be interpreted, what if you could simply call things for what they are as you create reports?

Custom Definitions need to be attached to Google Analytics hits (such as Events or Pageviews) when implemented, but by simply including them in these hits you can actually avoid the usage of the actual Google Analytics terminology in reports. The implementation, and the understanding of methodology, should be your problem, the specialist, not your less savvy colleagues.

With the main goal of creating comprehensible Google Analytics reports, for potential investors as well as for internal use, we decided to rely heavily on Custom Definitions throughout the implementation on The Beta Family.

Case Study: The Beta Family

The Beta Family is a crowdsourcing platform for beta testing and finding testers to iOS and Android applications. Developers can test apps on real people and get an honest opinion on the user experience. Testers can try new apps, and get rewarded if they write a good test report.

The website is a typical showcase for when the ability to slice and dice customized data will be beneficial. Each test, developer, and tester can be categorized in a variety of different ways, and attempting to capture all of these dimensions solely with standard Google Analytics Events and Pageviews would get messy very soon. Perhaps above all, potential investors would likely have a hard time understanding precisely what they are looking at unless presented with simple, straight forward reports that really show how the business is performing in relation to its main KPIs.

It is very important for us, and likely for all SaaS product owners, to get the full picture of the traffic, funnels and conversions. We are using Google Analytics to get a deeper knowledge of how our product is used and what we need to change to make the product better and make more money. The data is also used to motivate our team in making a better product and used in discussions with potential investors.

– Axel Nordenström, CEO & Founder, The Beta Family

Some of the Custom Definitions implemented are demonstrated in this post. Each one serves its purpose in introducing granular segmentation power and satisfying stakeholder requirements in terms of reporting and allows us to create highly customized reports, such as exemplified in the dashboard below.

Sample Custom Definitions

Plan Type (Dimension): When running tests, a developer can choose between the Free option, a Pay-As-You-Go plan, or a Monthly Subscription.
Test ID (Dimension): Each test is given an ID, and obviously we want to pass this to GA to be able to drill down and connect the dots between individual tests and the abundance of GA data available to us for deeper analysis.
Timestamps (Dimensions): We leverage several types here, such as user Registration date, or the Test creation date, to enable us to perform various cohort analyses without advanced querying.
Test created (Metric): This allows us to measure the number of tests created, using a Custom Metric incremented on each occurrence.
Test started (Metric): This allows us to measure the number of tests started.
Apply to test (Metric): This allows us to measure the number applications to each test.
Accept applicant (Metric): This allows us to measure the number of accepted applicants to each test.
Invite to test (Metric):This allows us to measure the number of invites to each test.
Invite accepted (Metric):This allows us to measure the number of accepted invites to each test.

Sample Reports

On The Beta Family, users can apply to participate in tests, or developers can invite users. In both cases, the other party needs to accept the invitation or application.

We wanted to surface this for each plan type to be able to carefully monitor the trend for these actions, incrementing Custom Metrics for test creation, invite, accepted invite, application, and accepted application. In combination with setting a Custom Dimension containing the plan type for each test, we will be able to, for example, create a report like the below to monitor the activity around applications for each plan type:

Or, we can surface the number of invites and accepted invites for each test. Since we are capturing an ID for each test, we can also drill down to a test-level for each plan type, as such:

We can tie our custom KPIs, captured through Custom Definitions, to an essential metric such as advertising spend to see where we get the most bang for our buck:

Or see how our test applicants are spread out geographically:

Drilling down to our tests with a Test Details dimension for each metric, we can segment by demographics, the reward amount, etc.

With all these dimensions and metrics available to us, we are also able to set up customized advanced segments to slice and dice our user base further. How about users who have applied to participate in more than five tests, yet have never submitted a report?

How about our most ambitious developers: how do users who have created more than ten tests, since registering in May this year, behaving over time?

As you can see, you will be able to create an abundance of various combinations to answer whatever business questions you might have, as long as you have the data presented in a way that is reasonable to understand and by extension, actionable.

Summary

The above examples exhibit some of the custom data now available to us when working in Google Analytics, reports that would have been more time consuming to get right without the Custom Definitions at hand. And, more importantly, these custom reports are more straight forward than standard reports in that they mirror what is actually going on on the website, using the same terminology.

Custom Definitions enable us to create highly customized reports that will make sense even to the non-Analytics-savvy. For The Beta Family, they allow for the creation of almost any report that potential investors could ask for, a very useful resource for a startup looking for financing. You do not need to be an Analytics wizard to fully grasp the data presented to you if the tool’s jargon is minimized. The use of Custom Definitions will therefore ultimately benefit both the specialist providing the report, as well as its end consumers.