Services

Most funnel reporting tells you the conversion rate fell. That is a symptom, not an address. Useful diagnostics answer a narrower question: which stage, for which segment, because of which constraint — and how much recoverable volume sits behind each one.

The method is stage-level instrumentation plus segmentation on the dimensions that actually differ in behaviour, then ranking losses by recoverable volume so effort goes where the money is.

Worked example — lending. Six partner lenders, 100K+ monthly borrowers, portfolio qualification stuck around 30%. Segmenting drop-off by user tag, verification path, and new-versus-renewal, then ranking rejection reason codes by affected borrowers, turned a vague loss into a fixable list. Qualification reached 43%.

The same shape applies to a checkout, a signup flow, KYC and onboarding, or claims triage. The domain changes; the drop-off math does not.

Most dashboard problems are definition problems wearing a visualisation costume. If two teams compute “active user” or “delinquency rate” differently, no amount of chart polish will make the dashboard trustworthy — and an untrusted dashboard is an unused one.

So the work starts with definitions, agreed and written down, then builds monitoring on top: the metric, its owner, its refresh, and the validation that catches it when it breaks. Data QA is part of the build, not a later phase — checks at ingestion so bad data fails visibly rather than flowing quietly into a number someone will act on.

Worked example — lending. Executive dashboards over a ₹8–9B+ loan book with early-warning delinquency tracking across 100K+ active loans and 15+ DPD stages, plus automated recurring SQL reporting for Risk, Product, Lending and Collections, with UAT and sanity coverage.

Typical stack: SQL, Snowflake, SQL Server, Tableau.

Wherever a written rulebook decides who qualifies and on what terms, two questions recur. Does the implemented logic match the document? And are any individual rules stricter than they need to be, rejecting acceptable customers for no measurable gain?

Answering the first means treating policy as source code: versioned, reviewable, and covered by a regression test that runs before deploy rather than in production. Answering the second means benchmarking rules against comparable ones and quantifying the population each constraint turns away — so a proposed change is argued with evidence instead of instinct.

Worked example — lending. 112 distinct decision rules composed into 200+ partner-specific policy variants across six lenders, drawing on 119 decision variables, with an automated harness that replays a borrower profile against every partner and explains each pass or fail in the language of the credit policy rather than in rule identifiers.

The same problem exists in insurance underwriting, pricing and discount engines, benefits eligibility, and compliance controls.

When a metric moves, the expensive mistake is to accept the first plausible explanation. Plausible is not the same as correct, and acting on a wrong cause costs twice — once in effort, once in the real cause going unaddressed.

The method is decomposition: split the movement by segment, cohort and time until the change localises, then quantify each candidate cause so the explanation carries a number. A useful RCA is also willing to conclude that an initiative did not work — negative results are cheap to produce and expensive to ignore.

Worked example — lending. Two new lending partners were added to the stack, and qualification barely moved. The decomposition showed why: the new partners’ risk signals overlapped almost entirely with existing ones, so they qualified the same borrowers rather than new ones — roughly 41 net-new qualified users. The recommendation followed from the finding: select partners for signal complementarity, not partner count.

The same reasoning applies to ad-channel overlap, supplier redundancy, and any portfolio where adding sources is assumed to add reach.