Retention & Monetisation
Building a retention loop and a contextual monetisation system around observed user behaviour
Role: GTM Product Lead / Growth PM · Product: CloudHire B2C Candidate Platform
The problem
CloudHire's growth model was primarily sales-assisted. Candidates could enter the product, experience the platform, and move through a sales-led purchase journey if they qualified.
Two gaps were going unaddressed.
First, there was no systematic mechanism to bring candidates back after their first session. Retention was happening, but passively — nothing was actively pulling users back to the surface where the product delivered value.
Second, a meaningful segment of users were slipping out of the commercial journey with no fallback. Some had abandoned the booking funnel before paying. Others had gone through a consultation but didn't convert to a higher plan. And a segment of free users were experiencing the product without any clear, structured path to upgrade.
I ran a growth audit to understand the retention behaviour first, then designed and built a system that addressed all three — retention, sales-funnel recovery, and self-serve upgrade — without disrupting the existing sales motion.
The retention signal
I analysed approximately 2.5 months of Mixpanel data and found a sharp, consistent behavioural threshold.
Users who reached the Job Board retained at a fundamentally different rate than those who didn't:
| Cohort | W1 | W2 | W3 | W4 | W7 |
|---|---|---|---|---|---|
| Job Board users | 46% | 40% | 35% | 32% | 22% |
| Aha-only users | 4–9% | — | — | — | — |
This held consistently across the full window. The Job Board wasn't just another product surface — it was the clearest behavioural threshold associated with sustained usage.
A second data point reinforced this: Aha → Job Board conversion had improved from ~20% to ~50% during the period. Moving users into that surface was already a working lever. The question was what happened once they got there — and what pulled them back if they left.
What retained users were actually doing
Among Job Board returners, the recurring behaviour was clear: find matching jobs → apply. ~49% applied in W1, 45% in W2, 41% in W3.
One thing I checked: did applying create a separate, higher-retention tier above Job Board reach? It didn't. The Board cohort retained slightly better than the Applied cohort, which meant applying was part of the Job Board behaviour — not a separate mechanism to optimise for independently.
The conclusion: the retention threshold is reaching and engaging with matching jobs. That's the surface worth engineering a re-entry loop around.
The retention loop
The product has a continuously renewable source of value: new matching jobs arrive regularly for every candidate. The strategy was to make that the re-entry trigger.
New matching jobs → Contextual email → Job Board → Relevant jobs → Apply → More matches → Return
The email is the re-entry mechanism. The Job Board is where the value is experienced. The loop feeds itself because the supply of new matches is continuous.
Each re-engagement email contains 2–3 of the user's actual matched roles — title, company, location — with individual deep links directly to those jobs, and a primary CTA back to the Job Board. The email needed to be useful on its own: a reason to return, not a generic nudge. A candidate who opens it and sees a relevant role clicks almost automatically.
One hard guardrail built into the system: if a user's live match count is zero, the matching-jobs email is suppressed and a value email is sent instead. Sending "here are your new matches" to someone with no matches would immediately break trust.
The monetisation system
The monetisation work covered two connected surfaces, built together as a single coherent system.
Surface 1 — State-based lifecycle emails (sales funnel recovery and retention, segmented by user state)
Surface 2 — In-product contextual upgrade prompts (feature-gating across all plan tiers)
Both surfaces share the same design principle: users experience value first. The upgrade ask comes after — at the exact moment when the user has felt the limit of their current plan, or after the lifecycle email sequence has established value.
Understanding the plan structure
CloudHire operates four plan tiers:
Free → Blue → Gold → Gold Elite
Blue is self-serve. Candidates can start with a ₹1 / 7-day trial, then convert to ₹2,999/year.
Gold and Gold Elite are sales-assisted. Any upgrade path toward Gold or Gold Elite routes users to book a call with the sales team — preserving the existing sales motion and never bypassing it.
This distinction shaped every commercial decision in the system. Self-serve monetisation (Blue) and sales-assisted monetisation (Gold, Gold Elite) run as entirely separate tracks, and the system never conflates them.
Surface 1 — State-based lifecycle emails
How user state was determined
The booking funnel passed a status flag — paid or unpaid — into the product for every candidate. This became the primary signal for which commercial experience each user should receive.
Inside the product, two additional sub-states refined the routing:
- Whether an unpaid user had started the ₹1 Blue trial
- Whether a paid user's consultation had completed, and with what outcome
The full state logic:
| User State | Sequence | Commercial Action |
|---|---|---|
| Consultation Unpaid · no ₹1 trial | Value-led emails → Job Board | Introduce ₹1 Blue trial after value |
| Consultation Unpaid · ₹1 active | Blue value track | Convert to ₹2,999 annual near trial end |
| Consultation Paid · active | Pure product experience emails | No monetisation — protect the sales pipeline |
| Consultation Paid · consultation done · no purchase | Recovery sequence | Introduce Blue ₹2,999 self-serve as fallback |
| Gold / Gold Elite purchased | Suppress all promotional email | Handoff to CS / onboarding |
The Consultation Paid row was a hard constraint. Showing any commercial ask to a candidate already inside the sales pipeline would have undermined the sales relationship and the trust the team had built. That pipeline was protected by design — no Blue offers, no ₹1 prompts, no University positioning, and no reference to any consultation or call in any email copy the user receives.
Email strategy — one spine, three jobs
Every email does exactly one primary job, and the sequence moves through them in order:
- Return — re-trigger a Job Board visit with fresh matching jobs. This is the majority of sends and the retention lever.
- Value — deepen understanding of CloudHire's capabilities and career relevance. Builds trust without selling.
- Convert — only after value, only for the right user state. ₹1 for unpaid users without a trial; Blue ₹2,999 for unpaid users who've completed their trial or post-consultation non-buyers. Paid users never receive a conversion ask.
One decision worth explaining: I didn't default to selling in every email. How many conversion emails to include is itself a test — offer fatigue can kill a lifecycle program, but the right conversion load is determined by data, not assumption. I designed a value-led default variant and a conversion-led variant to test this directly.
The post-consultation recovery track
For paid users whose consultation completed without a higher-plan purchase, Blue becomes the appropriate fallback — but only after the sales outcome is confirmed. This sequence doesn't re-pitch the sales journey. It introduces Blue as a self-serve option for candidates who want to keep their search moving on their own terms, at ₹1 to start.
Role-based personalisation
The career-value emails within the unpaid sequence are personalised by the candidate's role pulled from their profile. A product manager sees how AI is changing PM workflows. A developer sees how AI is changing engineering work. A designer sees how AI is reshaping design. The course and product are identical; the framing and subject line change to match the candidate's actual context. If the role field is missing, a fallback version is sent rather than guessing.
The ₹1 pricing decision
Freemium was the obvious alternative. The problem with freemium is that it captures usage without establishing purchase intent, and it creates a long, cold path to the annual conversion. The ₹1 trial captures payment details upfront and filters for candidates with genuine intent. Every email referencing the trial states the renewal terms plainly — ₹1 for 7 days, then ₹2,999/year, cancellable within the trial. No invented discounts, no fake deadlines, no implied outcomes.
Surface 2 — In-product contextual upgrade prompts
Beyond the lifecycle emails, a significant portion of the user base was on free or lower-tier plans, actively using the product and hitting limits with no clear path forward.
The problem with most paywalls is that they interrupt. They block users before value is experienced, which creates friction rather than purchase intent. The design principle here was the opposite: let users experience the feature fully, surface the upgrade prompt at the exact moment they've reached their limit — when motivation to upgrade is highest and the value of what they're being asked to pay for is most tangible.
The upgrade triggers built across the product:
Resume Generation
Free users can generate a set number of résumés. When they reach that limit, a contextual upgrade prompt appears as a smooth overlay — showing what they've used, what the next plan unlocks, and what it costs. The session isn't broken; it extends into a purchase decision.
Job Applications
Free users have an application credit limit. When credits are exhausted, the prompt surfaces on the next application attempt — in-moment, contextual, never a pre-emptive block before they've understood the value.
AI Interviews
Interview sessions are gated by plan tier. When a user reaches their limit, the prompt explains what they've used and what additional sessions are available at the next tier.
University (Video Content)
The University section contains a mix of free and plan-gated content. When a free user reaches a gated video, the prompt explains which content they'll unlock and on which plan — not a generic "upgrade" message, but one specific to what they're trying to watch.
The plan tier logic
The upgrade prompt is always plan-specific and always points to the next tier up:
Free user → upgrade prompt shows Blue (self-serve ₹1 trial)
Blue user → upgrade prompt shows Gold (book a call)
Gold user → upgrade prompt shows Gold Elite (book a call)
Gold Elite → no upgrade prompt (ceiling plan)
For Blue, the upgrade is self-serve — the prompt takes the user directly to the ₹1 trial. For Gold and Gold Elite, the prompt routes the user to book a sales call, preserving the sales-assisted motion for those tiers without bypassing it.
Each user can also see their current plan limits before they hit them — surfaced in their plan or account view. Transparency about limits before they're reached reduces frustration. The upgrade prompt at the limit converts that intent into action.

Weekly Aria credit limit, surfaced mid-conversation

Elite-gated University module
Build and implementation
I built the paywall UI, the feature-gating logic, and the upgrade prompt system directly in Cursor, using the existing component library and Figma design token system throughout — so every new surface was visually consistent with the rest of the platform from day one.
What was built:
- State-reading logic — the frontend reads
consultation_statusfrom the booking funnel andplan_tierfrom the user record, dynamically rendering the correct commercial experience: lifecycle email sequence, in-product upgrade prompt, or no commercial surface for active paid users - Limit-tracking per feature — résumé generations, application credits, interview sessions, and videos watched are tracked per user and compared against plan-tier thresholds in real time
- Contextual prompt rendering — each surface has its own upgrade trigger that fires at the threshold, pulling the correct plan comparison, feature list, and CTA for that user's current tier
- Sales-routing logic — Gold and Gold Elite upgrade prompts route to a call-booking flow rather than a self-serve checkout, so the sales team's pipeline is never bypassed
- Zero-match suppression — matching-jobs emails are suppressed when live match count is zero, swapping to a value email automatically
- Purchase suppression — ₹1 purchased → stops ₹1 emails; Blue purchased → stops all acquisition messaging; Gold/Elite purchased → stops all promotional email and hands off to CS
- Mixpanel instrumentation — full event coverage across both surfaces, shipped alongside each feature:
Email: email_sent → delivered → open → click → product_return → Job Board → applied
In-product: limit_reached → upgrade_prompt_viewed → plan_selected → payment_initiated → conversion_completed
The instrumentation shipped with each surface, not after it. Without per-feature, per-tier, per-state event data, there would be no clean way to read what was working and where intent was dropping off.
How the full system connects
Retention and monetisation aren't separate tracks — they run through the same product surface and reinforce each other.
Retention loop:
Matching jobs → Email re-entry → Job Board → Apply → More matches → Return
Monetisation loop:
Product value → Reach plan limit → Contextual upgrade prompt → Next tier → More value
The growth system in full:
Bring users back → let them experience recurring product value → identify their plan state and commercial status → surface the right upgrade path at the right moment, through the right channel.
This lets CloudHire run three commercial motions simultaneously — sales-assisted (Gold, Gold Elite) for high-value pipeline users, self-serve (Blue) for candidates converting through product usage, and lifecycle recovery for users who fell out of the sales funnel — without forcing the same experience on anyone, and without any motion interfering with another.
Reflections
Starting with behaviour, not assumptions. The 46% vs. 4–9% W1 retention gap made the loop design clear. The strategy wasn't built around engagement mechanics — it was built around re-entry to the surface the data said was already working.
Value-first as a hard constraint, not a principle. Every upgrade prompt across every feature was built so users experienced the product before any commercial ask appeared. That was enforced in the build. A user who hits a limit having already experienced value is in a fundamentally different state than one who hits a paywall before they understand what they'd be paying for.
Protecting the sales pipeline by design. Gold and Gold Elite upgrade paths route to the sales team, not a self-serve checkout. Paid users in the active sales sequence receive no commercial messaging at all. The state logic made that a system constraint, not a policy to remember.
Instrumenting before launching. The Mixpanel events across both email and in-product surfaces were built in alongside each feature. The experiments are only readable because the telemetry was there from the start.