Personalized push notifications are an entire engineering discipline. The wrong notification produces uninstalls; the right one produces engagement. Companies like Spotify, Netflix, Headspace, and Duolingo have built sophisticated push personalization platforms that the interview increasingly probes.
Functional requirements
- Send pushes to specific user segments. Support both static segments (all premium users in Germany) and dynamic ones computed from behavior (opened the app twice this week). Interviewers probe how you compute and refresh segment membership without scanning every user on each send.
- Personalize content per user. Fill templates with per-user data — first name, the show they paused, their streak count — and keep that personalization layer separate from delivery so a copy change doesn’t require redeploying the sender.
- Cap frequency to avoid annoyance. Track how many pushes each user has received across a rolling window and drop candidates that exceed the cap. This is where most designs fall down, so be ready to explain the counter store and its eviction.
- Optimize send time per user. Pick the hour each user is most likely to open rather than blasting everyone at once. A common follow-up: how do you spread load so a 9am spike doesn’t overwhelm the push providers?
- Measure engagement (open rate, conversion). Instrument every stage from send to in-app action so you can attribute a metric move back to a specific notification. Without this you can’t tell personalization from spam.
- Respect user opt-outs and quiet hours. Opt-out state must be checked at send time and honored globally across every channel — treat it as a hard filter, not a ranking signal.
Architecture
Three pipelines: candidate generation, scoring/ranking, delivery.
Candidate generation
For a given user, generate candidate notifications:
- Triggered: based on events (new content, friend activity, calendar). Latency matters here — a “your driver arrived” push is worthless an hour late, so these fire off a real-time event stream.
- Scheduled: based on rules (Monday morning encouragement). Cheap to run and tied to a clock or cohort, but easy to over-send, so they still pass through the same capping and ranking as everything else.
- Recommended: based on ML predictions. A model picks content this user is likely to engage with and wraps it in a notification. This is where personalization does the heavy lifting.
Generate dozens of candidates per user per day; rank to a shorter shortlist.
Scoring / ranking
Each candidate has a score:
- Predicted engagement probability (will the user open?). A model estimates open probability from features like past open rate, time since last session, and content affinity. This is usually the dominant term in the score.
- Predicted business value (will this drive a metric?). Weight candidates by the outcome they move — a re-subscribe prompt may be worth more than a social nudge even at a lower open probability.
- Recency (avoid duplicate). Suppress candidates too similar to something recently sent so the user doesn’t get the same nudge twice in a day.
- User preferences (channel, frequency). Fold in explicit choices — preferred channel, muted categories, a dialed-down frequency — before the final ranking rather than after.
ML model trained on historical engagement data scores candidates. Top-N proceed to delivery.
Frequency capping
Without limits, users get spammed. Capping is a rate-limiting problem at heart — the same token-bucket and sliding-window ideas apply, just keyed per user instead of per API client. Capping rules:
- Max N notifications per user per day (typically 1–3). Going higher measurably raises uninstalls; enforce it with a per-user counter keyed on a daily window.
- Max N per category per week. Separate budgets per category stop marketing pushes from crowding out product and transactional ones.
- Cooldown between notifications (e.g., 4 hours). A minimum gap keeps two candidates that fire close together from stacking into a burst.
- Exceptions for time-critical (security alerts, real-time game). These bypass the caps, but keep the allowlist tight or every team will argue their push is “urgent.”
Send-time optimization
Sending at 3am loses engagement. ML model predicts optimal send time per user:
- Aggregate engagement by hour of day, day of week. Build a per-user histogram of when they’ve opened past pushes; cold-start users with no history fall back to a segment or global default.
- Model the user’s daily pattern. Smooth the histogram into a predicted-open curve so a single lucky Tuesday doesn’t dominate the schedule.
- Schedule pushes for the predicted high-engagement window. Queue the send for that window and add jitter across users so you don’t fire ten million pushes in the same minute.
Quiet hours
Respect platform features (iOS Focus modes, Android Do Not Disturb). Server-side, default to “no notifications between 10pm and 7am local time” unless user opts in.
Channel routing
Some users prefer push; others email; others SMS. Per-user channel preferences:
- Push for time-sensitive. Fastest way to reach an engaged user, but only when they’ve granted permission and the app is installed.
- Email for marketing. Higher tolerance for volume and richer content, and a natural fallback when push permission is off.
- SMS for security and account events. Reserve it for high-value, low-frequency messages — it costs money per send and users react badly to marketing over SMS.
Localization
Push content respects user locale:
- Translate dynamic content. Store translations keyed by locale and resolve at send time; never machine-translate a payment amount or a person’s name.
- Use locale-aware date/number formats. Render times, currencies, and numbers in the user’s locale so “10/07” isn’t ambiguous between two dates.
- Right-to-left handling. Arabic and Hebrew need RTL layout plus correct handling of mixed left-to-right content like URLs and numbers.
Measurement
Per-notification metrics:
- Sent — the push left your system and was accepted by APNs or FCM. This is not the same as delivered.
- Delivered — the device actually received it. A gap between sent and delivered surfaces stale tokens and provider throttling.
- Opened — the user tapped the notification. This is your headline engagement rate.
- Engaged (action taken in app within window) — the user did something real in-app, not just opened and bounced.
- Conversion (revenue, retention impact) — the downstream outcome like a purchase or a retained session. Tie it back to the specific notification to justify having sent it.
A/B test push variants. Treat push as a major UX surface.
Privacy
- Don’t include sensitive content in payload (it shows on lock screen). Keep message bodies, dollar amounts, and health data out of the payload since it can render on a locked device.
- Privacy mode: payload says “New activity”; user opens app to see details. Send a generic string and load the real content only after the user authenticates into the app.
- Honor user opt-outs immediately and globally. One opt-out should suppress every channel and category within seconds, not on the next nightly batch.
Common antipatterns
- Sending the same notification to everyone. Blast sends ignore the whole personalization stack and train users to swipe away anything you send.
- No frequency cap (users uninstall). The fastest route to churn — even great content, sent hourly, loses.
- Marketing pushes outside reasonable hours. A 2am promo wakes people up and gets the app deleted; respect quiet hours for anything non-urgent.
- Misleading subjects (clickbait erodes trust). Clickbait bumps open rate once, then tanks trust and long-term engagement.
- “Re-engagement” pushes that just spam dormant users. Firing daily “we miss you” notifications at someone who stopped opening just confirms their decision to leave.
Frequently Asked Questions
What is the right baseline for “successful” push?
Industry-typical open rates: 5–15%. Strong personalization can push to 20–30%. Below 3% suggests the wrong content for that user.
How do you balance engagement and annoyance?
Cap aggressively. Test in limited cohorts before scaling. Track uninstall rate as a primary signal.
How does this differ from email marketing?
Push is more intrusive; users uninstall faster than they unsubscribe. Higher bar for relevance.
Keep sharpening your system design:
