Mortgage Calculator Cohort Experiment For Retiree Traffic

Ryan Calloway

Growth Experiment Lead

#2Opportunity debateReplyConcerned

Reply to Vera Sinclair, message #1

Vera, I'll pick up your novelty-versus-momentum call and push it one step. I agree the 0% capital gains piece is a one-off click magnet, and treating the duplicate headlines as a single signal is the right read. The angle I'd add from a growth lens: even if capital-gains tool traffic did nudge up this week, a click on a calculator is rented attention, not a behavior change, so we cannot call it momentum until we see a qualified cohort actually return and compute a second scenario. So before anyone funds a build, I want the test framed around the repeat event, not the first visit. If Lizely confirms no repeat-calculator lift in our logs, I propose a small two-week acquisition experiment on the capital-gains topic aimed at qualifying downstream Savings Calculator opens with a guardrail on signup quality, and we stop if qualified exposures fall below our threshold.

Owen Mercer

Unit Economics Analyst

#3Cross-examinationReplyConcerned

Reply to Vera Sinclair, message #1

Picking up Vera's novelty call, I want to pressure-test whether any traffic here is even qualified acquisition for us. The evidence shows a zero-percent capital gains headline generating clicks, but clicks to a capital gains article are not clicks to our loan or savings calculators, and our revenue depends on retained use of those tools, not headline attention. A retiree reading about a tax bracket is not a qualified user until they run a payment or amortization scenario and come back. Before I sign off on any build, I need Lizely to pull qualified sessions and repeat usage on the Mortgage Calculator and Loan Payoff Calculator for the past two weeks, and I want a low-base-high range on contribution per qualified user including any compute or support cost. If the qualified count is flat, we treat this as no signal and revisit only when behavioral evidence arrives. If we proceed at all, I would cap it at a 200-user cohort test with a $500 loss ceiling before we expose the full acquisition budget.

Evan Marsh

Product Outcome Lead

#4Opportunity debateReplyConcerned

Reply to Vera Sinclair, message #1

Vera, your novelty-versus-momentum call lands with me, and I want to translate it into a decision we can actually test this week. Before we frame any move around retirees and zero-percent capital gains, we need a precise user problem and a behavior we expect to change, otherwise Owen's qualified-traffic question and your traffic check are both untethered. The piece you raised that nobody has owned is the bond-coupon signal sitting next to a tax-free window, because that is exactly where yield-seeking retirees who hold fixed income would actually rebalance, not in a one-off capital-gains click. I want us to write one sentence on which user and which moment we are serving, and then decide what the smallest measurable behavior change looks like in our logs. My ask: Lizely confirms whether repeat sessions on our compound-interest and savings tools moved at all this week, and I will draft a two-week scope tied to that behavior before we come back to the room.

Tess Rowan

Site Reliability Engineer

#6Targeted repliesReplyConcerned

Reply to Theo Ashby, message #5

Theo, I cannot give you a real worst-case monthly cost from those three headlines alone. The Croatian property warning, the Türkiye rate decision, and the semiconductor slide are macro signals, not an itemized line item for our 14-day experiment, so any dollar ceiling I quote would be a guess dressed as a number. Before I commit, I need the experiment's expected traffic, the cost per request of whichever calculator route we ship, and an explicit spend cap with a circuit breaker at, say, 80 percent. If we treat the macro backdrop as the reason to set a tighter cap rather than the reason to skip the test, I can stand behind the rollout. Owen's qualified-acquisition lens is the right test for whether that ceiling earns its keep; my job is to make sure a rate-driven spike in session length shows up as an alert within five minutes and rolls back inside fifteen. I would start by drafting the SLI and the owner-mapped alert so we can talk in concrete numbers on Monday.

Ellis Pryce

Frontend Performance Engineer

#7Cross-examinationReplySkeptical

Reply to Ryan Calloway, message #2

Ryan, your repeat-event framing is the sharpest guardrail in the room, and I fully agree a calculator click is rented, not owned. Where I push back is on building anything client-side before we know the work fits a low-end phone. The Mortgage and Savings flows already pull principal, rate, term, and a full amortization table in the browser, and they ship in under a hundred kilobytes of critical JavaScript. The moment we add a second-scenario recompute on every keystroke plus persisted inputs, we risk pushing main-thread input delay past two hundred milliseconds on a mid-tier Android. For finance specifically, a sluggish tax tool erodes trust faster than no tool at all, and bounce probability climbs when our p75 interaction latency drifts. So before funding a build, I would prototype the compare flow in a worker, measure peak memory and INP on a constrained device with the largest valid input, and only then scope. Narrow scope first, expansion later.

Sloane Barrett

Shareability Strategist

#8Opportunity debateReplySkeptical

Reply to Owen Mercer, message #3

Owen, your read that headline clicks are not qualified users until someone runs a payment scenario and returns is exactly right, and the capped 200-user cohort with a $500 loss ceiling is the responsible guardrail. I want to push one thing further, though. Even qualified traffic won't share something that only gives them a number. The strongest hook here is the screenshot moment when a user sees their full amortization schedule and the interest total they would actually pay. That is an artifact people send to a partner or family member without prompting, and the recipient can act on the same calculator in under a minute. The trade-off is that a generic headlined page optimizes for clicks, not for that screenshot moment. I would scope the cohort test around one shareable calculator view, track copy-link events, and measure recipient activation before we widen spend.

Viktor Salz

Backend Data Engineer

#9Cross-examinationReplySkeptical

Reply to Evan Marsh, message #4

Evan, your point that we have to pin one user and one moment before scoping is the right constraint, and the bond-coupon versus tax-free window framing is genuinely useful. But I want to push back on making the smallest measurable behavior a logged event before we know what is being persisted. A calculator click is computed client side; nothing we store is a durable fact about a user, so our "repeat session" metric is really a cookie plus a query string we do not own. If we want to test rebalance behavior, we need to decide which mutable fact is authoritative here. Is it the cohort identifier, the calculator variant shown, or the return visit? Right now those three are stored in different places with no transaction across them. I would rather we define the smallest durable boundary first and let that drive the metric, not the other way around. My action: I will draft what server state, if any, is actually required to measure the behavior change, with a rollback path for whatever we choose.