Spices & Masala Brand Intelligence for an FMCG Player
The Client
A quick-commerce business competing in India's brutal instant-delivery market — the world of Flipkart Minutes, Amazon Now, Zepto, and Blinkit, where a customer's loyalty is measured in minutes and a single bad experience sends them to a rival app that's one tap away. Their problem was the defining problem of the category: churn was rising, and their churn model could see that customers were leaving but not why. Their data-science team had built a capable churn-prediction model on their own first-party data — order frequency, recency, basket value, complaint history — but it kept hitting a ceiling. It could flag an at-risk customer; it couldn't explain the external reason they were about to leave, and therefore couldn't tell the retention team what to actually do about it.
They came to Actowiz Solutions with a sharp, well-scoped question: can external competitive data supply the churn signals our own data can't see?
The Challenge — and an Honest Framing
This engagement is worth documenting partly because it began with a correct understanding of what external data can and cannot do for churn — a distinction many teams get wrong.
Churn prediction is mostly a first-party problem. The core of any churn model is the customer's own behaviour — how often they order, how recently, how much, whether they've complained, how their app engagement is trending. This data is private, first-party, and belongs to the platform. No external provider can or should supply customer-level churn data; that would be personal data the client already owns and that no one should be scraping. Actowiz was explicit about this from the first conversation: we do not and cannot provide your customers' private behavioural data — you have it, and it's the heart of your model.
But churn has external causes the first-party data can't see. Why a customer churns is frequently about the competitor, not the customer: a rival undercut your price on the customer's regular basket, you were out of stock when they needed something, your delivery times degraded in their area while a competitor's improved, or a competitor ran an aggressive acquisition offer in their pincode. These causal signals are external and public — and they're exactly what a first-party model is blind to. A model that knows a customer is at risk but not that Zepto just undercut you by 15% on their staples in their pincode is missing the actionable half of the picture.
The scope, therefore, was precise: external, public, competitive-environment signals — resolved to the granularity (pincode, category, time) where they could join to the client's first-party model as features, strengthening it rather than replacing it. This is the honest and genuinely valuable role for external data in churn: not the prediction itself, but the external features that explain and sharpen it.
The Actowiz Solution
1. Public competitive-signal collection.
Across the client's competitive set (the major q-commerce platforms) at pincode granularity: price positioning on comparable baskets, stock-out frequency and availability, delivery-time and ETA indicators where publicly shown, assortment presence, and promotional intensity — the public environmental signals that drive churn, collected at the thrice-daily-plus cadence quick commerce demands (the infrastructure from our q-commerce work).
2. Churn-signal feature engineering.
Raw competitive data engineered into model-ready features aligned to the client's needs: competitor price gap on the customer's typical basket in their pincode, your stock-out rate in their pincode over the trailing window, your delivery-time position versus the best competitor locally, competitor promotional intensity in their area, and assortment gaps for their frequent categories. These are the external features a churn model can consume — each one a plausible external reason for departure.
3. Pincode-and-time resolution for joinability.
Every signal resolved to pincode and time window, so the client could join external features to their first-party customer records (a customer lives in a pincode; the external environment in that pincode at that time becomes their feature set) — the join key that made external data usable in the model at all.
4. The retention-action layer.
Beyond features, the signals were structured to be actionable: when the model flags an at-risk customer, the external features suggest the lever — a targeted offer if the driver is a competitor price gap, an availability fix if it's stock-outs, an ETA improvement if it's delivery. External signals turn "this customer is at risk" into "this customer is at risk because of X, so do Y."
5. Delivery into the client's ML pipeline.
Feature feeds delivered in the client's schema on the cadence their model retrains on, with history retained so the relationship between external signals and actual churn could be learned over time (did customers in pincodes where we were undercut actually churn more? the data let the client's team validate and weight each signal).
6. Strict compliance — the foundation.
Public competitive data only; no personal data, no customer data, no first-party data of any platform — the external signals are environmental (prices, availability, delivery times in a pincode), not personal. PII-at-the-edge, per-record lineage, DPDP-mapped — and a clear contractual and architectural line that the client's private customer data stays entirely on their side and is never mingled with collection. This separation is not just compliant; it's the only correct design.
Sample Structure (Illustrative)
External churn-signal feature record (sample, pincode × time):
{
"pincode": "560001",
"window": "2026-08-11_morning",
"competitor_price_gap_basket_idx": -12,
"own_stockout_rate_7d": 0.08,
"delivery_time_position": "slower_than_best_by_4min",
"competitor_promo_intensity_idx": 78,
"assortment_gap_flag_categories": ["dairy", "snacks"],
"captured_at": "2026-08-11T07:30:00+05:30",
"note": "environmental signal only — no personal/customer data",
"lineage_id": "lin-9921-churn"
}
How external features join the first-party model (illustrative):
Order recency / frequency / value
Source: First-party
Owner: Client (private)
Complaint history, app engagement
Source: First-party
Owner: Client (private)
Competitor price gap (pincode)
Source: External signal
Owner: Actowiz (public)
Own stock-out rate (pincode)
Source: External signal
Owner: Actowiz (public)
Delivery-time position (pincode)
Source: External signal
Owner: Actowiz (public)
Competitor promo intensity (pincode)
Source: External signal
Owner: Actowiz (public)
Illustrative — the external features (public, environmental) join the first-party features (private, client-owned) on pincode and time. The two data sets stay architecturally separate.
Engagement Metrics (Representative)
Scope: Public competitive signals, pincode-level
Competitive set: Major q-commerce platforms
Signal cadence: Thrice-daily+ (q-commerce rhythm)
Feature types: Price gap, stock-out, delivery-time, promo intensity, assortment gap
Join key: Pincode × time window
Personal/customer data: None (environmental signals only)
Delivery: Model-ready feature feed, client schema
Time to first feature feed: 4 weeks
Representative engagement figures — illustrative of project structure.
The Outcome
The client's churn model got what it had been missing: the external half of the story. Their data-science team incorporated the external features and found several of them carried real predictive lift — competitor price gaps on typical baskets and local stock-out rates, in particular, correlated with subsequent churn in ways their first-party-only model couldn't have surfaced. The model didn't just predict better; it predicted explainably — flagging not only that a customer was at risk but the likely external reason, which is what the retention team needed to act.
That actionability was the real return. Before, an at-risk flag triggered a generic retention offer. Now, the external signal routed the response: a competitor price gap triggered a targeted basket offer; a local stock-out pattern triggered an availability escalation rather than a discount (fixing the actual cause); a delivery-time gap fed the ops team. The retention effort got cheaper and more effective because it was aimed at the real, external driver rather than blanketing every at-risk customer with the same discount.
The engagement's defining feature, though, was its discipline about the boundary. The client owned the customer; Actowiz supplied the environment. The two never mixed — architecturally, contractually, and compliantly. That separation wasn't a constraint on the value; it was the value, because it let a q-commerce brand strengthen its most sensitive model with external data without a moment's exposure on customer privacy. In a DPDP world, that clean line is what makes external churn signals usable at all.
The engagement continues as a standing feature feed, expanding the signal set as the client's model identifies which external drivers matter most.
Why This Pattern Repeats
Every subscription, marketplace, and quick-commerce business fighting churn eventually hits the same wall: their first-party model sees that customers leave but not the external reason. The transferable design: keep the first-party behavioural data where it belongs (with the client, private), and supply the external, public, environmental signals — competitor pricing, availability, delivery, promotions — engineered as model-ready features, resolved to a join key (pincode and time), delivered into the ML pipeline, with an absolute architectural separation between public external signals and private customer data. External data doesn't predict churn; it explains and sharpens the prediction — and that's exactly where its value is.
Frequently Asked Questions
Can external data predict customer churn?
Not on its own — churn prediction rests on first-party behavioural data the platform owns. What external data does is supply the environmental reasons for churn (competitor price gaps, stock-outs, delivery-time and promotion signals) as features that strengthen and explain a first-party model.
Does this involve collecting customer data?
No — absolutely not. The external signals are environmental (prices, availability, delivery times, promotions at a pincode level), not personal. Customer data stays entirely with the client; the two data sets remain architecturally separate. This is DPDP-compliant by design.
How do external signals join a churn model?
On pincode and time — a customer lives in a pincode, and the public competitive environment in that pincode at that time becomes a feature set that joins to their first-party record.
What actions do external churn signals enable?
They turn "this customer is at risk" into "at risk because of X, so do Y" — a price-gap driver suggests a targeted offer, a stock-out driver an availability fix, a delivery driver an ops escalation. Contact Actowiz Solutions to scope external churn-signal features for your retention model.
Comments
Post a Comment