Overall satisfaction went up two points this quarter. Somewhere in the twelve things you asked customers to rate - product quality, support responsiveness, pricing, ease of use, and eight others - something actually moved that number, and several other things probably didn't move it much at all, no matter how their individual scores changed. The trouble is that eyeballing twelve separate scores next to one overall number doesn't tell you which is which. Key driver analysis exists specifically to answer that question: given a set of things you asked people to rate, and one overall outcome you care about, which of those things actually matters most to the outcome, not just which ones happen to be rated highly or lowly on their own.
Table of Contents¶
- What Key Driver Analysis Actually Does
- How It Works, in Plain Terms
- When Attributes Overlap Too Much
- Reading a Relative Importance Result
- A Worked Example
- What It Can't Tell You
- How Often to Re-Run the Analysis
- FAQ
What Key Driver Analysis Actually Does¶
Picture a satisfaction survey that asks people to rate ten different attributes - product reliability, price, support quality, ease of setup, and so on - plus one overall satisfaction score. A simple average of each attribute tells you how each one is currently rated, but it doesn't tell you how much each one actually matters to the overall score. Price might be rated relatively low across the board, but if it turns out satisfaction barely moves regardless of how people feel about price, it's not actually a priority to fix. Meanwhile, support quality might be rated only slightly lower than price, but turn out to be the single biggest factor separating your happiest customers from your least happy ones. Key driver analysis is built to tell the two apart - it's the difference between "what's rated poorly" and "what actually drives the outcome I care about."
How It Works, in Plain Terms¶
Underneath the hood, key driver analysis typically uses a statistical technique called regression, which looks at how each attribute's rating moves together with the overall outcome across all your respondents, and works out how much of the movement in the outcome each attribute can account for. The output is usually expressed as a relative importance score for each attribute, scaled so that all the attributes' scores add up to 100% - support quality might come out as 35% of what's driving satisfaction, price as 10%, ease of setup as 22%, and so on down the list. A few different statistical approaches exist for calculating this (relative weight analysis and Shapley value regression are two common ones, alongside more modern approaches like random forest models), and they can produce slightly different numbers, but the underlying goal is always the same: separate genuine drivers from attributes that are just along for the ride.
When Attributes Overlap Too Much¶
Driver analysis assumes each attribute contributes something distinct, and that assumption strains when two or more attributes are really measuring close to the same underlying thing - "ease of use" and "ease of setup," say, which respondents often rate similarly because in their experience the two genuinely overlap. Statisticians call this multicollinearity, and it doesn't break the analysis outright, but it does distort how importance gets divided between the overlapping attributes - the "true" combined importance of the overlapping pair might be real and substantial, while the analysis, forced to split credit between two attributes that move almost identically, can understate each one individually and make neither look like the priority it actually is.
The practical fix starts before the data is even collected: writing attributes to be as conceptually distinct from each other as the survey design allows, rather than several slightly different phrasings of the same underlying idea. If overlap shows up anyway - two attributes with unusually similar ratings across almost every respondent - it's worth treating their combined importance as the more meaningful number to act on, rather than debating which of the two nearly-identical scores is the "real" priority.
Reading a Relative Importance Result¶
The number to focus on is relative importance, not the attribute's own rating. A driver analysis result is most useful when you plot it against each attribute's current performance score side by side - an attribute with high importance and low performance is your clearest priority, since it matters a lot and you're currently doing poorly on it. An attribute with high importance and high performance is worth protecting, not fixing - it's already working, and it's a real reason people are satisfied. An attribute with low importance, regardless of its performance score, is a lower priority almost by definition, even if its own rating looks disappointing on its own. This same importance-versus-performance framing is formalized as its own technique - see our guide to importance-performance analysis if you want the full 2x2 version of this idea, including how to plot and read it visually.
A Worked Example¶
A SaaS company runs a satisfaction survey rating eight product attributes plus overall satisfaction. A driver analysis comes back showing "onboarding experience" at 31% relative importance - the single biggest driver by a wide margin - while "number of integrations available" comes in at just 4%, despite integrations being one of the lowest-rated attributes in the raw scores. Without the driver analysis, the team's instinct would have been to prioritize building more integrations, since that's what the raw ratings seemed to be complaining about loudest. With it, they redirect their next quarter's roadmap toward onboarding instead - the thing that was actually moving the number they cared about, even though it wasn't the attribute generating the most vocal, visible complaints in the open-ended comments.
What It Can't Tell You¶
Key driver analysis identifies statistical relationships, not guaranteed causes - a high relative importance score means an attribute's rating and the outcome move together closely across your respondents, which is strong evidence but not the same thing as proof that improving the attribute will improve the outcome. Our guide on correlation versus causation in survey data covers this distinction in more depth, and it's worth reading before treating a driver analysis result as a guaranteed roadmap rather than a strong, well-informed hypothesis. It's also only as good as the attributes you actually asked about - if the real driver of satisfaction is something you never included as a rated attribute in the first place, no amount of analysis on the data you do have will surface it.
How Often to Re-Run the Analysis¶
A driver analysis is a snapshot of what mattered most to the outcome during the specific period the data was collected, not a permanent, fixed truth about your product or organization. What drives satisfaction can genuinely shift over time - the onboarding-experience driver that dominated a year ago can fade in importance once a redesigned onboarding flow addresses it, making room for a different attribute to become the new binding constraint. Re-running the analysis every time you field the underlying tracking survey - typically each quarter or wave, in line with however often you're already collecting the attribute ratings - keeps the driver list current rather than working off a picture that quietly went stale.
It's also worth re-running the analysis specifically after a significant product or process change targeting a previously-identified top driver, both to confirm the change actually moved the needle on the outcome and to see which attribute has newly risen to become the next priority now that the old one has been addressed. A driver list that never changes wave over wave is itself worth a second look - it can mean the underlying drivers are genuinely stable, but it can also mean nothing was actually done about the previous findings.
FAQ¶
Do I need statistics software to run a key driver analysis?
The underlying regression calculation typically needs a statistics tool or a data analyst comfortable running one - it's not something you'd do by eye in a spreadsheet. What you can do without special tools is the simpler groundwork: comparing each attribute's rating against overall satisfaction using cross-tabs, which gets you a rougher but genuinely useful directional read.
How many attributes should I include in a driver analysis survey?
Enough to cover the real, distinct dimensions of the experience - typically somewhere between six and fifteen. Too few and you risk missing the real driver entirely; too many and individual attributes get harder to rate distinctly from each other, which muddies the analysis.
What's the difference between key driver analysis and just looking at correlations?
A simple correlation compares one attribute to the outcome in isolation. Key driver analysis (via regression and relative importance) accounts for the fact that attributes are often correlated with each other too, and tries to isolate each one's independent contribution rather than letting overlapping attributes inflate each other's apparent importance.
Can I run this on NPS instead of a satisfaction score?
Yes - the same method works with any single outcome score as the target, NPS included. Our NPS analysis guide covers finding NPS drivers specifically, using lighter-weight methods alongside this more formal approach.
What happens if two attributes in my survey are measuring nearly the same thing?
The analysis will likely split importance between them rather than crediting either one fully, understating the true combined effect of that underlying theme. Writing attributes to be conceptually distinct at the design stage avoids this; if it happens anyway, treat the overlapping attributes' combined importance as the more meaningful figure.
How often should I re-run a driver analysis?
In line with however often you re-collect the attribute ratings - typically every quarter or wave - and especially after any change targeting a previously top-ranked driver, both to confirm it worked and to see what's risen to take its place.
For the broader methodology behind analyzing survey data well, see Beyond Averages: The Professional's Guide to Survey Analysis.