Scalable Notification System for 1M+

We Sent Fewer Notifications. Revenue Went Up.

The counterintuitive result came in on a Tuesday. The experiment had been running for 3 weeks: Group A got our standard notification cadence (11 per month), Group B got our new intelligent system (4.2 per month on average). The rule of thumb says more touchpoints equals more engagement.

Group B had 28% higher click-through, 34% higher revenue per user, and 61% lower unsubscribe rate. We'd been spamming ourselves into lower performance for over a year.

Notifications aren't engagement tools. They're trust tokens. Every notification you send that isn't relevant is a withdrawal from the trust account. When you overdraw, users unsubscribe — permanently. You don't get a second opt-in.

The rebuild wasn't about sending fewer notifications. It was about building a system that only sent notifications that were genuinely worth interrupting someone for.

The Problem State

What Our Notification System Actually Was

Before the rebuild, our "notification system" was a collection of trigger scripts written by 7 different engineers over 18 months, each optimized for their individual feature's engagement metric. Nobody owned the full notification experience.

Notification Type	Frequency	Open Rate	Click Rate	Contribution to Unsubscribes
Weekly digest (generic)	4/month	14.2%	3.1%	28%
Product feature updates	2/month	8.4%	1.8%	19%
Price change alerts (all changes)	3.2/month avg	41.2%	22.4%	11%
Re-engagement nudges	1.5/month	6.1%	2.2%	31%
Promotional offers	0.8/month	9.8%	4.1%	11%

The generic weekly digest had a 3.1% click rate and contributed 28% of all unsubscribes. We were sending 4 notifications per month that were generating 3 clicks per 100 users and destroying our ability to reach 28% of users who received them.

Contrast: price change alerts had 22.4% click-through and low unsubscribe contribution. The pattern was clear — event-driven, specific, relevant notifications performed 7× better than calendar-driven generic ones.

The Notification Quality Spectrum

Not All Notifications Are Equal

We classified every notification type across two dimensions: relevance specificity (generic → personalized → event-triggered) and user value (low → medium → high). The matrix was revealing.

Classification	Example	Click Rate	Unsubscribe Rate	Strategy
Generic + Low Value	Weekly digest (all users)	3.1%	High	Eliminate
Generic + Medium Value	Feature update	1.8%	High	Eliminate or in-app only
Personalized + Medium Value	Rate changed for your category	12.4%	Low	Optimize and keep
Event-triggered + High Value	Your alert: Hdfc rate dropped ₹340	22.4%	Very Low	Scale
Behavioral + High Value	You left a quote mid-way — here it is	31.2%	Very Low	Expand

The decision matrix was stark: the bottom two rows (event-triggered and behavioral) produced 7–10× better click rates at a fraction of the unsubscribe cost. The top two rows were actively harming our deliverability and user trust while contributing almost nothing to business metrics.

Design Principles

The New Notification Philosophy

We wrote a one-page notification philosophy that every engineer working on the system had to sign off on. It sounds dramatic. It was necessary — because without explicit principles, the default behavior is always "add more notifications."

A notification is an interruption. Every interruption needs to justify itself against the question: "Is this worth stopping what this user is doing right now?" If the answer isn't a confident yes — it doesn't send.

Three rules that governed every notification decision: (1) No calendar-based sends — only event or behavior triggers; (2) Every notification must be specific to something in the user's own data, not general market data; (3) Frequency limits per user are hard limits, not guidelines — the system enforces them, engineers don't override them.

The New System

What the Rebuilt System Does

Relevance Scoring

Every potential notification scored before sending: user data match, time since last notification, channel fatigue level, user segment, historical engagement with this notification type for this user. Score < 60/100 = don't send.

Hard Frequency Caps

Maximum 2 push notifications per 7 days per user. Maximum 4 emails per month. Per-channel, per-user. System-enforced. The highest-priority notification wins the available slot if multiple are queued. No override except manual customer success.

Content Personalization Engine

Every notification body generated from user-specific data: their plan name, their savings amount, their comparison. Not merge tags in a template — a content generation layer that produces genuinely personalized copy per notification instance.

Negative Signal Learning

Unopened notifications for a user type → reduce send probability for that type for that user. Clicked: increase. Dismissed without opening: minor decrease. Unsubscribed: permanent kill for that channel. Preference signals respected, not re-asked.

Technical Implementation

How the System Was Built

Notification Eligibility Engine

→Central service: every notification request passes through eligibility check before queuing
→Checks: frequency cap, channel preference, relevance score, time of day, recent engagement
→If ineligible: request rejected with reason code (for analytics)

Content Generation Layer

→Templating system replaced with dynamic content generation per user
→User data injected at generation time: plan name, amount, comparison data
→Fallback logic: if user data unavailable, notification held (not sent with generic content)

Engagement Feedback Loop

→Delivery, open, click, dismiss events all fed back to user preference model
→Model updates user-level engagement history per notification type
→Weekly model refresh: frequency cap adjustments per user segment based on engagement patterns

Results

A/B Test and Outcomes

Weeks 1–3 · Audit

Mapping the Existing System

→ Identified 6 notification types to eliminate immediately; 3 to redesign; 2 to scale.

✓Catalogued all 14 notification types across the platform
✓Measured click rate, unsubscribe contribution, revenue attribution per type
✓Classified each notification on the relevance-value matrix

→ Identified 6 notification types to eliminate immediately; 3 to redesign; 2 to scale.

Weeks 4–8 · Build

New System Implementation

→ New system running in parallel. A/B test initiated at 50/50 split.

✓Eligibility engine built and integrated with all notification trigger points
✓Content personalization layer replaced template system
✓Engagement feedback loop implemented

→ New system running in parallel. A/B test initiated at 50/50 split.

Weeks 9–12 · A/B Results

Statistical Significance Reached

→ New system: +28% CTR, +34% revenue/user, −61% unsubscribes. Full rollout.

✓New system: 4.2 notifications/user/month vs 11 in control
✓Statistical significance at Week 9 for click-through metric
✓Unsubscribe delta significant by Week 11

→ New system: +28% CTR, +34% revenue/user, −61% unsubscribes. Full rollout.

+28%

Notification CTR

at 62% lower volume

+34%

Revenue per User

notification-attributed

−61%

Unsubscribe Rate

trust account restored

4.2

Avg Monthly Sends

down from 11

Insights

What This Changed About How I Think About Notifications

Notification volume and notification effectiveness are inversely related above a threshold

Below 4 notifications/month: users feel you're not communicating. Above 8: fatigue sets in and each marginal notification generates negative returns (unsubscribes, dismissed without reading). The sweet spot for our context was 4–6 per month.

Unsubscribes are a metric you should watch as carefully as CTR

High CTR but rising unsubscribes = you're burning your future reach to generate today's clicks. The notification system should be judged on lifetime deliverability (ability to reach users over months), not single-send performance.

Generic notifications are expensive even when they 'work'

A 14% open rate sounds acceptable. But if those opens produce 3.1% clicks and 28% of your unsubscribes — the math collapses. The correct metric for any notification type is revenue per notification, net of unsubscribe cost.

Ownership matters for cross-system experiences

The pre-rebuild system had 7 engineers adding notifications independently. No one owned the user's full notification experience. One team's engagement optimization was another team's reputation damage. Unified ownership of the notification experience is not optional.

Failures

What We Got Wrong in the Build

✕ Frequency caps initially applied at platform level, not per-channel

Why it broke

Platform-level cap of 2 per week meant a user could get 2 push + 2 email = 4 contacts in 7 days. That's too many. The cap needed to be per-channel, not total.

What fixed it

Per-channel hard caps: 2 push/week, 4 email/month. If push quota full and a high-priority notification triggered, held for next week — not overflowed to email.

✕ Relevance scoring initially had no time-of-day component

Why it broke

A price alert at 2:47am is less useful than one at 9:15am — even if the content is identical. Initial scoring model had no time component.

What fixed it

Added send-time optimization: each user has a predicted high-engagement window (inferred from historical open times). Notifications held and sent in that window where possible. CTR improved further 11%.

Future

Where the System Goes Next

Per-User Frequency Optimization

Current frequency caps are category-level averages. Next: per-user optimal frequency modeled from individual engagement history. Some users want daily; some want monthly. Let them self-select through behavior.

Channel Arbitration

When the same alert could be push, email, or SMS — current system uses default channel. Next: select channel based on user's historical engagement by channel and time of day.

Lifetime Deliverability Metric

Track per-user delivery health over time: unsubscribed channels, open rate trends, dismiss rate. Flag users whose deliverability is declining before unsubscribe — intervene with re-permission campaign before losing the channel.

We sent 62% fewer notifications and achieved 28% higher engagement. The lesson isn't to minimize notifications — it's to only send notifications that earn the interruption they're asking for.

Designing a Comparison Platform Like Monito for the Indian Market

Product

How We Built a Multi-Calculator Finance App That Drives Daily Retention

Product

Building a Real-Time Cab Fare Comparison Engine (Uber vs Ola vs InDrive)

11 min read

Product

How We Built a Multi-Calculator Finance App That Drives Daily Retention

8 min read

Product

Building a CRM That Handles 180K+ Monthly Transactions at 99.6% Uptime

12 min read

All Case Studies

Browse all 30 breakdowns

Work With Me

Let's build something together

Connect on LinkedIn

Follow for more insights

Where to go next

Consumer App Growth Consultant
The consulting work this sits inside, with the rest of the evidence behind it.
Day 30 retention benchmark, fintech & banking
Published figures, traced to their sources — and where the sources disagree.
Day 7 retention benchmark, e-commerce & retail
Published figures, traced to their sources — and where the sources disagree.
Product Growth Score
Thirteen questions that locate which part of the funnel is actually constraining growth.

Creating a Scalable Notification System for 1M+ Users (Trigger-Based)

Results at a glance

We Sent Fewer Notifications. Revenue Went Up.

What Our Notification System Actually Was

Not All Notifications Are Equal

The New Notification Philosophy

What the Rebuilt System Does

How the System Was Built

A/B Test and Outcomes

What This Changed About How I Think About Notifications

Notification volume and notification effectiveness are inversely related above a threshold

Unsubscribes are a metric you should watch as carefully as CTR

Generic notifications are expensive even when they 'work'

Ownership matters for cross-system experiences

What We Got Wrong in the Build

Where the System Goes Next

You might also like

Where to go next

We Sent Fewer Notifications. Revenue Went Up.

What Our Notification System Actually Was

Not All Notifications Are Equal

The New Notification Philosophy

What the Rebuilt System Does

How the System Was Built

A/B Test and Outcomes

What This Changed About How I Think About Notifications

Notification volume and notification effectiveness are inversely related above a threshold

Unsubscribes are a metric you should watch as carefully as CTR

Generic notifications are expensive even when they 'work'

Ownership matters for cross-system experiences

What We Got Wrong in the Build

Where the System Goes Next