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!

Advertisements
Standard
Analytics & Insights, Science

Getting to Magic: Facebook’s Negative Feedback Data

I’ll never stop harping on looking deeper into analytics for deeper insight. Too often we just look at positive triggers (Likes/Comments/Shares) as an indication of how well content is performing. But wouldn’t it be nice to know how often people Unliked or Hid our content too, to get an idea of how well it actually resonated?

Enter: Negative Feedback. This is every Hide, Report as Spam, and Unlike for the page, and if you have access to the New Insights is found under the Reach tab:

Where to find Negative Feedback.

Where to find Negative Feedback.

And here’s what the graph looks like:

Negative Feedback Graph

Negative Feedback Graph

If you don’t have access to New Insights, pinging your Facebook Account Manager should get it for you, otherwise it’s buried deep in the data extract Excel sheet (columns BB to BG in my report).

Going Up-Data

Per the post on the Criticality of Great Analytics, the question I’m typically trying to answer with this data is “Which Posts are Resonating Best?” If I had access to web data, I’d make this “Which Posts are Adding the Most Value?” by tracking the entire clickstream to the site, conversion points, etc, but for now we’ll keep this purely in Facebook.

Thankfully, Facebook gives us some great datapoints to make this a largely math-driven equation. We basically want to measure Net Reaction divided by Net Reach. In order to do this, we simply do:

((Daily Comments + Daily Likes + Daily Shares) – Daily Negative Feedback) / (Daily Total Reach / (Daily Total Reach – Daily Count of Fans Online))

There are some simpler ways to do this, that may be just as valuable, but I like to do Net Reach because it factors in how many people were online on Facebook that day. Ultimately what math like this (typically done in Excel) should show is how people are responding to your content day by day. If you run this at Post level, and compare it to content types or narrative arcs, you can also see how your audience is responding to various types of content.

The last time one of my clients had a significant spike in Negative Feedback Rate, we produced content and then segmented it out by audience to try and see which audiences were driving NFR, and found that all folk under 35 skewed negative, while those over 35 skewed positive. This data led towards a market survey which fundamentally changed the positioning for the brand.

Conclusion

Great data is always hard, but now that Facebook is exposing this data directly via Insights, making use of it is easier than ever. Though, to be fair, building Macros into the Data Export will yield some pretty epic data too. More on that in a future post!

Think I’m off base, just like Dave? Let me know in the comments belowwww.

Standard