Web analytics dashboards: making reporting simple and easy

Over the last few months I have been working with Nathan Wall finding out how agencies manage their web analytics reporting and what their needs are. We’ve now created some easy to understand dashboard reports. It’s a solution that:

  • can be automated
  • will help agencies with routine web analytics reporting
  • will encourage consistent and common reporting across government
  • will reduce the feeling some people have of being overwhelmed by data.

Creating easier to understand dashboard reports

Dashboards! Everything and everyone needs a dashboard! But what should dashboards show on them? How do we provide content owners with easy to understand information about what’s happening on their sites so they can use that information to make informed decisions and prioritise improvements.

After speaking to a number of agencies we identified 3 basic types of dashboard needed:

  • "traffic" dashboards
  • "engagement" dashboards
  • "experience" dashboards.

We’ve built examples of each of the 3 dashboard types to find out:

  • if the concept of common web analytics reporting will be useful to agencies
  • if there is a common approach to web analytics reporting we can use across different websites
  • what’s needed to automate the collection of data to build the dashboards
  • if there is an opportunity for public release of web analytics data.

A common approach to reporting

We think it’s possible to use a common approach to report basic analytics about our websites.

For the proof of concept, we created dashboards for 11 different websites across government. All websites have a purpose: some require the user to complete a task; others require the user to find information. No matter what the purpose, we found all the dashboards we built could have a common layout.

"Traffic" dashboards

Screenshot of example traffic dashboard

Full-sized version of the traffic dashboard screenshot (PNG, 87kb)

Text description of the "traffic" dashboard image

Analytics traffic dashboard

The traffic dashboard shows the total number of visits and pageviews since the site in question launched, gives averages for daily visits and pageviews and profiles the device types and browsers used by people when visiting the site. The data on the dashboard is correct up to yesterday. Each traffic dashboard gives the following information:

Visits to the example website.govt.nz

Shows the total number of visits to the site since a date specified by the site owner. In this example, the number shown is 7,079,534.

Pages viewed

Shows the total number of pageviews since the date specified by the site owner. In this example, the number shown is 30,828,770.

Visits to the site every day

Shows the average daily number of visits to the site in the past 30 days. In this example, the number shown is 7,802.

Pages visited every day

Shows the average daily number of pages viewed in the last 30 days. In this example, the number shown is 30,482.

How people access the website

Users access the website using desktop, tablet or mobile devices. The dashboard will show, using a line graph, the number of users accessing the site using what device over the last 30 days by days of the week. This example shows a slight increase in mobile device use over the weekend.

The data supporting every graph on every dashboard will be accessible as well.

Browsers that access the website

You can find out which are the top 5 browsers accessing the website over the last 30 days, and can click down into each browser type to find the version of that browser being used. In the example shown Chrome, Safari and Internet Explorer are the most commonly used browsers.

Traffic dashboards provide basic stats such as:

  • pageviews for the entire site
  • the total number of visits to the site
  • top 10 pages visited
  • the top country of origin where visitors came from
  • the types of browsers and devices visitors to the site are using.

Sound familiar? Well it should. A lot of agencies report on these high-level stats in their monthly and quarterly reports. We think we can make that reporting a bit easier, giving people more time to look a little deeper into what the data reveals.

"Engagement" dashboards

Screenshot of example engagement dashboard

Full-sized version of the engagement dashboard screenshot (PNG, 73kb)

Text description of the "engagement" dashboard image

Example engagement dashboard

Engagement dashboards show what proportion of users are interacting with a particular website. The definition for engagement differs for each website.

The dashboard shows the engagement rate:

  • over the last 3 months (in this example, 75.3%)
  • over the 3 months prior (in this example, 69.8%)
  • the  resulting change  (in this example, 7.9%).

It also shows the number of engaged visits:

  • in the last 3 months (in this example, 1,696,874)
  • in the three months prior to those (in this example, 1,478,020)
  • the resulting change in the number of engagement visits, expressed as a percentage (in this example, 14.8%).

The dashboard shows two graphs:

  • The first shows the overall engagement percentage, plotted over the months of the year, comparing year on year. In this example the graph shows engagement increasing slightly in 2015 to 75%.
  • The second shows the number of engaged visits and the number of overall visits to the site plotted over months comparing year on year. In this example the number of engaged visits is fewer than the number of overall visits to the site, and over time the numbers decline.
  • The data supporting both graphs is accessible as well if the user would like to view that information.

Engagement dashboards and what they report on varies from site to site, however the way in which the engagement is presented on a dashboard can be consistent. We’ve measured engagement by looking at key user journeys and measuring the proportion of users that did tasks on a site, such as:

  • downloading certain documents
  • working step-by-step through collections of content pages
  • clicking on external links needed to complete a specific task
  • returning to the site within a set number of days.

Working out what to report on means site managers and content owners need to be clear about what success means for their site. Not such a bad thing if you ask me!

Is “engagement” the “right” word to use for these reports? Well to be honest we’re not completely sure, but haven’t been able to come up with something else. If you can think of a word that says “Did your users actually do what you wanted them to do?” in a simpler way, let us know.

“Experience” dashboards

Screenshot of example experience dashboard

Full-sized version of the experience dashboard screenshot (PNG, 123kb)

Text description of the "experience" dashboard image

Example experience dashboard

The experience dashboard is created by mapping out a specific user journey in Google Analytics. The data will automatically be extracted from Google Analytics and loaded into the dashboard. The user journey is defined by the business owner of the website. The dashboard shows the number of users starting and completing the journey and what devices they are using over time.

In this example for year to date in 2015, 313,337 visits started the task (4.9% up on the same period last year), 18.3% used a mobile device (up 56.2% on the same period last year) and the task completion rate is 61.3% (56.2% on the same period last year). In 2014 the number of visits starting this task is 654,993, mobile device use is 20.2% and task completion rate is 41.6%.

The completion rate

The completion rate is plotted on a line graph, showing comparison between 2014 and 2015. In this example the completion rate is increasing in 2015.

Visits starting and completing this task

The number of monthly visits starting and completing this task in 2014 and 2015 is plotted on the next line graph. In this example the number of visits in 2014 starting and completing the task remained consistent, but declined over time. In 2015 the number of visits starting the task remained consistent with the prior year figures, but the number of visits completing the task increased.

Visits by desktops, tablets and smart phones

The number of visits over the past 12 months per device is plotted on a column chart. In this example, the volume of visits using a desktop is far greater than The number of tablet and smart phone visits. however, smart phone visit numbers is gradually increasing.

Desktop, tablet and smart phone usage

This area line chart shows the percentage of desktop, tablet and smart phone usage is plotted over the last 12 months. In this example, the percentage of smart phone usage is increasing by approximately 20% over the past 6 months, with tablet usage remaining constant and desktop usage declining.

Notes

At the bottom of the dashboard there is a place where the user journey is defined, from where the user starts this particular journey to where they complete the journey. Unlike Google Analytics goals, this dashboard only shows how many people are completing the user journey, it cannot show where they may drop off during the process.

You can use Google Analytics goals to provide this information, but this dashboard allows site owners to look backwards in time, providing that all the basic data they need is already being tracked. Goals only work from the moment they are created in the GA tool and can't be used to explore historical data.

We think “Experience” dashboards are where the real value starts to be shown. Using a feature in Google Analytics called segments, we map out specific user journeys and then measure the completion rate – meaning, how many users got to the end of the user journey.

This technique doesn’t confirm things like users were able to find what they were looking for, or that they understood they were reading, but it’s an indicator at least in broad-terms that the site was meeting at least some of their needs.

In addition to an overall completion rate, we can segment users by things like the type of device they used, and see if that had any impact on their ability to complete the task or journey.

Automating the dashboards

We’ve built the proof of concept dashboard interface using the Common Web Platform (CWP). If the dashboards are turned into a live service, this does not mean your website needs to be on CWP to take advantage of the easier reporting. You just need to have Google Analytics running over your site and you’d need to give the dashboard tool we’ve built access to your analytics data. We’ll use Google’s API to pull in the data to the dashboard, so once the initial set up is complete the dashboard will update automatically.

We have used the free Google Analytics tool, and the Google Analytics API for the proof-of-concept. We are looking at what the extra features Google Analytics Premium would give us, including:

  • access to the raw data
  • guaranteed retention of data
  • the ability to analyse user journeys across government websites.

What agencies are telling us

When showing website owners the reports we created, they could quickly and clearly see whether users are finding their site easy to use. They could also see if their content (not just their transactions) was being used effectively. The dashboards would give them knowledge and evidence to help prioritise and measure site improvements.

The automation of reporting is extremely appealing to agencies. They can’t wait to spend less time copying and pasting numbers into spreadsheets, and more time actually improving the quality of their websites.

How much time do you spend collating data rather than analysing it? Would an automated dashboard by useful to you?

Public release of web analytics data

We think our dashboards can help us create better public services for everyone. The dashboards would also promote more openness in government. It’s not about pointing fingers and blaming agencies for things that aren’t working. It’s about finding the things we’re doing right, and doing more of it.

If we keep building these dashboards and offering a service to agencies, we don’t yet know where the dashboards would be published. We could publish them on:

  • psi.govt.nz so the dashboards remain accessible to government employees, but not to the general public (psi.govt.nz is not accessible outside the public sector).
  • a site such as data.govt.nz making the data open to all.

Where would you feel happy having your website data published? What would stop you from releasing the data in a more open way?

There are a few things we need to do to get the show on the road

We need to:

  • refine the dashboard designs to ensure they are accessible
  • update some of our code to ensure we comply with web standards
  • show our prototypes to more agencies and get feedback so we can make the reports even easier to understand
  • decide where we should publish the dashboards
  • investigate what other tools are needed, including the possibility of Google Analytics Premium, to support an all-of-government service
  • define an operating model that would support agencies long-term – and this includes working out how to fund the service, and what agencies would (probably) need to pay to use it.

And finally… a big thank you

A huge shout out to the team at the Digital Transformation Office in Australia. They’re on a similar journey and the conversations we’re having with them, the information they’re sharing, and their awesome collaborative approach to working with us is really going beyond the call. From us here in New Zealand, a huge thank you!

6 comments

  1. Comment #1. luciane:

    it would be great to have written instructions on the available on how to create those boards.

  2. Comment #2. Nathan Wall

    Hi Luciane – more guidance material, tips and even some screencasts on how to get better use of tools like Google Analytics is something we’re now looking at. When it comes to these dashboards though, we’re thinking it might be easier to work with agencies to design the boards they need, and then we’d build them. Using the code we’ve already created, we can just configure the reports and they’d be hosted centrally.

    We’re not quite at the stage to do this – not all the code is written yet 🙂

    Is there something specific you’d like to see on one of these dashboards? Also, if you’ve got questions about something you’d like to do in Google Analytics itself but you need some help to do it, let me know, we’re looking for ideas on what tips and guidance material would be most useful.

  3. Comment #3. Mary Hay:

    Hi Nathan and Sarah

    This is really interesting work. Thank you for sharing it.

    Not sure if you have seen the USA Govt analytics site. Summary of that site is “This data provides a window into how people are interacting with the government online. The data comes from a unified Google Analytics account for U.S. federal government agencies known as the Digital Analytics Program. This program helps government agencies understand how people find, access, and use government services online. The program does not track individuals, and anonymizes the IP addresses of visitors.”

    https://analytics.usa.gov/

    Again thanks for sharing.

    Mary

  4. Comment #4. Nathan Wall

    Hi Mary

    Yes, both Sarah and I looked at what governments around the world are doing, and we’ve been fortunate to be able to speak to people in the USA, Canada, the UK, and Australia. What do you think of the US site Mary? On one hand I think it’s fantastic that they can see how users interact with government as a whole, but their aggregate stats quoting “we’ve had a billion visits in the last 90 days” makes me say “So what?”. They’re a big country with a big population, so of course they’re going to get lots of visits. But were those visits worthwhile? Did the various sites and services meet user needs? That’s perhaps a little harder to see in the big numbers.

    Sarah and I started looking at how we can report on services and specific user journeys, it was the information we had ready access to. We were able to map out things like, “How many users completed task [x] in a single visit.”, and “How many users followed this specific pathway through the site?”. We think looking at how these metrics change over time might make it easier to spot opportunities to improve a site, or to measure the success of changes agencies have already made. Just counting pageviews isn’t really good enough these days.

    Getting a Premium Google Analytics account for NZ government agencies to use will give us the same unified view the US now has. It comes at some considerable cost though, so we need to work out if it’s actually viable for us to use it. We will need to work together to figure out the best way to fund the work. If your agency would like a demonstration or even just a coffee and a catchup let me know, I’m more than happy to arrange it.

    Cheers

    N

  5. Comment #5. Patric Lane:

    Hi team – awesome idea, great work. A few thoughts:
    With the traffic dashboards, I’m always interested in referral sources, and would love it if we could easily filter out visits from within our own agency (ie so we can get a truer view of what our customers are looking at).
    Meanwhile, I also get the sense that a fair number of government agencies aren’t (or don’t know how) to use UTM codes to help determine the effectiveness of their efforts to pull people to their websites via email and social media campaigns, news releases, online advertising etc.
    If it’s possible, maybe creating a UTM-code related dashboard (ie that allows people to pull in UTM-code results so they can easily see how different campaigns, sources, mediums and content are performing) would help address this?
    Knowing what happens once people get to our websites is one thing – but figuring out what actually works best to get them there is just as important, IMO. Regards, Patric

  6. Comment #6. Nathan Wall

    Hi Patric

    It would be really easy for us to show referral information on the traffic dashboards, we didn’t do that during our early experiments as we had just adapted the Govt.nz dashboard to start with.

    To filter or not to filter? That is always an interesting question. I tend not to do it though, as internal staff members can often be legitimate users of our sites. If you know the IP address your corporate network uses to connect to the Internet, it’s easy enough to set up a parallel view of your analytics data that only shows “external” customers. If you’re not in charge of your Google Analytics account, you’ll need to speak to whoever is to request that.

    I completely agree with you about agencies not maximising the value of the data that’s available to them. But that’s something we can work on over time. The web analytics “clinics” I ran recently highlighted a number of areas where skills and knowledge are missing. The challenge now is finding effective ways of closing those skill gaps with the limited resources available.

    The “experience” dashboard we created could be easily adapted to show traffic coming from a particular campaign or channel. We know we haven’t identified all the features the boards would need yet, and I think that’s actually a good thing. We can make small iterative improvements over time.

    Cheers

    Nathan W

Navigate Posts