Our Client's NPS Went From 34 to 52 After We Fixed Their Data — Not Their Product

An NPS of 34 is a product that needs improvement. That's the standard interpretation — and the standard response is a product roadmap review, user research, and a sprint focused on addressing the most common complaints. That's what this client was planning when they hired us. We suggested running a data analysis first.

The data analysis showed the product wasn't the problem. Three data quality issues were creating experiences that users were rating as failures — experiences that weren't product design decisions but data accuracy failures. Fix the data, fix the NPS. No sprint required.

What Was Driving the Low Score

The NPS survey included an open-text follow-up for detractors (scores 0–6): "What's the main reason for your score?" Analysis of 340 detractor responses over 6 months showed three complaint clusters that together accounted for 67% of all negative responses.

Cluster 1 (38% of detractor responses): "The reporting is wrong / my data doesn't look right." Users were seeing incorrect values in their analytics dashboard — a data pipeline accuracy issue, not a product design issue. Cluster 2 (18% of detractor responses): "My settings keep resetting" / "your system loses my configurations." A caching layer bug was causing user preferences to occasionally fail to persist. Cluster 3 (11% of detractor responses): "I get notifications for things that already happened" / "your alerts are always late." The notification pipeline had a processing delay that made real-time alerts arrive 2–4 hours after the triggering event.

The Three Data Fixes

Fix 1: Analytics pipeline accuracy. The dashboard was aggregating data from a pipeline with an incorrect deduplication rule — events from a specific SDK version were being double-counted. A single SQL fix in the transformation layer corrected the counts retroactively for the trailing 6 months. Affected users received a notification explaining the correction. Timeline: 1 week including testing and communication.

Fix 2: Preference persistence. The caching layer was using user IDs as cache keys without account for session invalidation edge cases — a specific logout/login pattern was clearing cached preferences before they wrote to the database. Fixed with a write-through cache pattern and a migration script to recover any lost preferences. Timeline: 5 days.

Fix 3: Notification pipeline latency. The alert processing pipeline was running on a 2-hour batch cadence, not in real-time as users expected. Migrated the critical alerts to an event-driven architecture (Kafka consumer). Non-critical alerts remained on the batch pipeline. Timeline: 3 weeks including testing and gradual rollout.

"When users complain about a product, it's worth spending a few hours asking 'is this a product problem or a data problem?' They feel identical to the user — both result in an experience that doesn't match their expectation. But one requires a product sprint; the other requires a data fix. Always check the data first." — Pavel Siddique, CEO, Indpro AB

The NPS Recovery Timeline

Month 1 (analytics fix deployed): NPS moved from 34 to 41. Users whose dashboards now showed correct data represented the largest detractor cluster — the fastest improvement came from the largest fix. Month 2 (preference fix deployed): NPS moved from 41 to 47. Month 3 (notification pipeline live): NPS moved from 47 to 52. The compounding pattern reflects the order of impact of each fix, matching the detractor cluster analysis.

No product features were added during this period. No UX was changed. The product roadmap sprint that the team was planning was deprioritized. The developers who would have run it spent those months on other feature work. The NPS improvement was entirely data infrastructure work.

The Lesson About Product Feedback

Users don't distinguish between "the product did something unexpected" and "the data the product showed me was wrong." To the user, the experience is the experience — they scored it low because it failed them, regardless of technical root cause. This means product feedback analysis needs a data quality lens before it becomes a product roadmap. The most efficient path to NPS improvement is often the data layer.

Frequently Asked Questions

Q: How do you differentiate between data quality NPS drivers and genuine product issues?

We run a structured analysis of open-text NPS responses, categorizing each complaint into: functional failure (product didn't work as designed), design issue (product worked but the experience was poor), data accuracy (product showed incorrect information), and performance issue (product was slow or unreliable). This categorization tells you which problems require product changes vs. engineering fixes vs. data fixes.

Q: Is NPS a reliable enough metric to base engineering decisions on?

NPS is a useful signal, not a precise measurement. We use it alongside more specific metrics: support ticket category analysis, feature usage data, and direct customer interviews. The value of NPS in this context was that it prompted us to analyze the detractor responses — the open text was more informative than the score itself. The score told us there was a problem; the text told us what it was.

Q: How long does the data quality analysis of NPS drivers take?

The initial analysis — categorizing detractor responses and identifying data quality candidates — takes 2–5 days depending on the volume of responses and the complexity of the system architecture. The goal is to identify which complaints are plausibly data-related before investing in root cause investigation. This pre-analysis pays back its time investment on almost every engagement where the NPS is below 50.