Analytics & Insights

Front-End vs Back-End Reporting

I’ve written before about how important great analytics are. But even if you know you need great analytics, and have the capacity, there are a few big challenges:

  1. Clients not using your impeccable insights
  2. The transition from what strategy feels are important, and what is feasible and gets delivered
  3. Great analytics can cost more (and/or take more work)

I’m going to leave the “how to get clients to pay” for a future post, as I want to outline my approach for going from “we need to collect data” to “whoa, that insight helped shape our business” in a meaningful way.

The Process

For many teams and agencies, the process whereby we decide what data to collect and what to report are the same. This is a fundamentally broken process. The data you collect can serve three purposes:

  1. Spot issues with the campaign/project (eg: dropoff at registration page could show a bug)
  2. Ensure performance is on par, and adjust media/content strategies accordingly
  3. Send data to the client on the value the campaign delivered

The truth is, there is a significant amount of data required for #1 and #2, and very little of that adds any value at all to the client and, realistically, probably confuses the situation. The flipside to this, which I’ve said manytimes, is that #3 requires very little data to be reported, but often requires significant data in order to arrive at what gets reported.

An example at how the sheer amount of data that sometimes gets pulled together might look like this:

Metrics We Collect

Metrics We Collect

Front-End vs Back-End Reporting

This is where what I call Front-End vs Back-End Reporting comes into play. Back-End Reporting is what we are all largely familiar with: all the data, KPIs, metrics, flows, user info, performance info, app info, etc. Sometimes agencies can collect upwards of 100 different data points, based on those “what should we collect” meetings I mentioned above. And this Back-End Reporting is great. In fact, there’s a view that it’s hard to collect too much data in this, as long as collecting and storing data is effectively free (which it may not be for you and your team).

The challenge is that for many teams, they take all this data, throw away a handful of data points, and then try and figure out how to shove it all together into a big report to present to the client. We then try and simplify it with dashboards, exec summaries, etc… but the truth is, this report (if we’re lucky it’s 10 pages, more often it’s significantly longer) doesn’t actually do what the client needs it to do.

What Clients Need

As a reminder, there’s a significant difference between what clients say, what clients want, and what clients need. From reporting, 95% of clients simply need to know “how much value did this campaign / program / period generate for my business, how close can we get that to a dollar value, and what does that mean for ROI”. They also likely need reporting on their annual KPIs, just so they can track against them. Most of the other stuff we add (because we’re collecting it, so we believe the client should see it) is not only superfluous, it can be destructive because it distracts from the core questions the client needs answered.

While a lot of datapoints are often necessary to answer the big question, the flipside is you also don’t need a 10-40 page report to answer it. In fact, answering that question intelligently comes down to understanding your client, understanding their business, and simplifying the actual report to how you answer the question(s) the client needs answered. And, conversely, it can often be answered by only showing 3-5 specific data points, in an intelligent way.

Real Front-End Reporting

Based on all of the above, real Front-End Reporting is about something we, sadly, don’t do enough of: taking complex data and spending time thinking about how to visualize it for our clients. At the end of the day, Back-End Reporting is pulling together the best data, and Front-End Reporting is about visualizing it in a way that is actionable. Too often, we present Back-End Reporting to clients, when what they really need is Front-End Reporting.

As far as what an example of this looks like, all of my previous examples are confidential to clients, but I am planning on pulling this post into a deck, including generating sample data, for a fictitious client. In the meantime, if any of my readers have examples they’d like to share, send them in or comment below!

Pulling It Together

The biggest thing to remember when thinking about reporting is that it is a two-step process (at least) for (at least) two different audiences. If smart analytics is about getting the right data to the right people, then it’s obvious that the data internal teams/devs/strategy needs can often be very different from the data clients need (or want, or say they need/want!).

Having a process to go from client KPIs and Objectives, to questions we need to answer helps answer the Front-End Reporting question. You can then break those out into specific metrics, reporting timelines, alerts and notifications, etc. Those data points go into your Back-End Reporting process. The “sit the entire team down to brainstorm on data we should collect” is just as important, but typically simply goes into Back-End Reporting (with periodic data extracts).

Agree or disagree with this approach? Think it’s too simple/too complex? Pfft, let me know in the comments section belowww!


Educate Us - Leave a Comment!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s