analysis Archives - The Data Co

Context Matters

As always, my posts begin with a seemingly simple problem posed to me in my day-to-day: Why is X rate up year over year??

This can be any kind of rate… I’m sure you have had the same question posed to you, even if you’re not an analyst. One thing you always need to provide, along with the answer to that question, is the context. Without it you will never be serving up the truth.

What do I mean by “context”?

Say I decide to measure my heart rate on a Saturday morning. I check my Apple Watch, press the Heart Rate icon, and see I’m running at about 140 bpm. (The idea is around 60 bpm, or roughly 1 beat per second.) All of a sudden I panic – WHY IS MY HEART RATE TWICE AS HIGH AS IT SHOULD BE??? Is it a heart attack? Am I dying? What do I need to do?

Well what if I told you on that particular Saturday morning I am running a marathon. Changes the way we look at a particular number, doesn’t it?

This is the same level of context we need when we report on or analyze changing rates.

For example, when trying to analyze why a customer sentiment score had recently fallen, I took a look at the number of people being measured. The volume of positives had decreased overall, while the negatives stayed steady. This means the negative volume skewed the positive volume, not that the sentiment was necessarily down.

Another example is when the average handle time for a customer service department slowly ticked up month over month for a year. After digging into the problem, other teams had been implementing proactive solutions aimed at fixing the simple issues, and the results were dramatically decreased calls and handle time. The calls left were the more difficult issues, which took (on average) longer to solve.

How do I provide context in my next analysis?

The solution is simple: Include volumes for context when reporting on rates. In the past business have been focused on setting measurable KPIs and OKRs, most often as rates or averages. As we get more sophisticated in our efforts, including automating or eliminating the ‘easy’ issues, targeting the right people at the right time, and shifts in consumer behaviors (ie, survey fatigue), our measurements should also change to allow for context.

Now back to my marathon.

The infuriating relationship between analytics and data management

By: Heather Lamb The Technology Comments: No Comments

If you’re an analyst, you already know exactly what I’m talking about: analysts need data, but they may not know what data they need. Turn that undefined need into a request to the data management team and you will get the well-tuned response of, ‘Well just tell me what you need.’

Here’s why that question is so hard to answer.

Analysts are often asked to figure out open-ended problems such as

Why are the average handle times increasing in our call centers?
Who are the best customers to target for our marketing campaign?
How can we decrease cheating across testing locations?

The real problem with all of these requests is that the answer is unknown. Had the questions been more Business Intelligence/Reporting questions, then the data needs would be clear. Using the previous questions, here are the same asks but more for BI-level answers:

Are average handle times correlated with agent tenure?
What are the demographics of our current customer base for a new campaign?
Can we compare test scores across students from the same high school that took the test in different locations?

These questions are well-defined, and have specific data needs. For example, the data needed for the handle times are agent tenure and respective call volume and total handle times for each.

But when analysts are trying to answer open-ended questions, there may be elements that are unknown that contribute to the potential answer. For example, in order to try and decrease cheating across test centers, first an analysts must be able to find cheaters. This (obviously) includes test scores, but it also may be related to their high school, the payment method used, or the prep tests taken and resulting scores.

The main point here is, analysts don’t know what data they need until they see all the data. Then they can bring the various features in and investigate for patters and correlation. This level of detail can be accomplished from the data management team as follows:

Sample data sets

By giving an analyst a sample of all the data available, they will be better equipped to skim them and come back with a more defined request.

Read-only access

This level of access means the analyst can see and export any and all of the data they need, without disrupting the data management team or underlying data. The issue here may be unencrypted data and/or PII concerns. Analysts should be well-versed in concerns with customer privacy, as well as have already taken internal customer privacy certifications.

Secondary Environment

A lift-and-shift of the data into another, analyst-friendly environment will alleviate data requests all together. This solution alleviates privacy concerns as non-identifiable data (such as customer IDs) can be used instead of names or PII. However, this may be the most cost prohibitive option.

Using these options will alleviate the infuriating relationship between analysts and the data management team, because they all give the analyst a way to review the data initially prior to making a full-fledged request.

analysis