A business model that moved three times

To understand why the attribution layer stopped working, you need the commercial history underneath it. The marketplace changed what it sold twice in a few years, and each change altered what a "conversion" even means.

Attribution built for stage 1 handles stage 3 badly. The pipeline had grown a separate lineage of models for each revenue type — one chain for enrollments, another for memberships, a third resolving users at signup — each maintained independently as the business changed shape around them.

Three chains, three answers, no reconciliation

"Which channel won this customer" had two or three different answers depending on which model you happened to query, and no defined way to settle between them. There was no concept of a customer's first purchase spanning both revenue types — so the most basic acquisition question had no single owner in the data.

And the honest caveat, because anyone who has done this work knows it: none of this makes the platform numbers agree with ours. That gap is structural — each platform measures inside its own walled garden, on its own attribution window, counting conversions it touched. Reconciliation isn't a problem you solve once; it's one you manage continuously. What a rebuild like this buys you is a single internal number that's consistent, explainable, and defensible enough to argue from — which is why the incrementality work sits alongside it as the independent check.

Three structural problems underneath it

From parallel chains to one spine

The core decision: collapse every attribution-bearing event into one table at touchpoint grain, then apply dedup, enrichment, and ranking once. Downstream models select and filter; they never re-derive attribution.

Two decisions I spent the most time on

Six stages

The ID convention

Event IDs are namespaced by type, so synthetic touchpoints — ones with no clickstream event behind them — stay visibly distinct from real ones:

Warehouse-level choices

This runs on Redshift, so physical layout mattered as much as logic.

Four levels, classified once

Every touchpoint has to become a channel, and "channel" means different things to different people. Finance wants paid versus organic. A channel manager wants to know which Meta campaign type. The CMO wants paid social as one line. Serving all three from separate logic is how a taxonomy starts drifting.

So the hierarchy has four levels — and the critical design decision is that only the deepest one is derived from raw signals. The three above it are composed from that leaf, never re-classified independently.

The judgment calls underneath it

The interesting part wasn't the code. It was that several of these categories have no technically correct answer, and the business had never written one down:

• Is word of mouth organic? Settled as organic at L1, while preserving WOM as its own L2 — so existing reporting kept working and the roll-up became correct.
• Are community, friend and insider referrals organic? Yes at L1, grouped under WOM at L2. They behave like word of mouth even though they arrive through different mechanics.
• Where do educator outreach coupons belong? Classified as referral at L3 — a teacher sharing a code is a referral, not a discount campaign.
• A referral link posted on Reddit? Genuinely ambiguous, and the case that took longest. Referral and organic social are both defensible; what mattered was picking one and writing it down.

I drove this to written closure in a shared doc with marketing, then encoded the agreed mapping in the macro. The point of that sequencing: get the decision made by the people who own the definition, then make the code the single record of it — so the argument can't quietly restart in six months.

One customer, all the way through

Every rule on this page is easier to see applied to a single person. Here's a parent who finds the marketplace through paid search, takes a month to buy, answers the post-purchase survey, and uses a coupon — traced through each stage of the pipeline.

What that example demonstrates

• Consecutive repeats collapse, separated ones don't. Two google visits on day 1 become one. Had google reappeared on day 20 after the facebook touch, it would have counted again.
• The lookback window is a real constraint. That day-1 google touch survives dedup and enrichment, then falls outside the 28-day window before the purchase and earns nothing. Window length is a business decision with direct consequences for which channels get credit.
• Email before signup is discarded — you can't have been emailed by a product you hadn't joined, so those touchpoints are mis-stamped.
• Direct survives but can't earn. It stays in the table as a record of what happened and is excluded from weighting, because "we don't know" shouldn't quietly absorb credit.
• Two of four credited touchpoints never existed as clickstream events. The survey answer and the coupon redemption carry real attribution signal, and the synthetic-row mechanism is what lets them participate in an event-based model at all.
• The conversion is the anchor, not a recipient. The enrollment defines the window and the scope; it doesn't take a share of its own credit.

Collapsing repeat touchpoints without losing the real ones

If someone arrives eight times through the same Facebook campaign before converting, linear attribution hands that campaign 8/9ths of the credit. High-frequency channels — email, retargeting — systematically over-earn against channels people touch once.

The obvious fix is to collapse repeats. The trap is collapsing too much: if someone sees a Facebook ad, then gets an email, then comes back through Facebook a week later, that second Facebook touch is a genuine, separate re-engagement. It should survive. Only consecutive repeats are noise.

So the rule I needed was "collapse each unbroken run of the same channel into one touchpoint" — which means the logic has to know where runs start and end.

One deliberate exclusion: I dropped the channel-level cooldown windows I'd originally sketched — a 7-day window for email, 1 day for everything else. Fixed cooldowns collapse touchpoints that are genuinely separate whenever a campaign's natural cadence happens to sit inside the window, and the run-based rule already handles the case they were meant to solve.

Which row survives each run

That convergence problem is ultimately why this model is materialized as a table rather than incrementally. I built and kept the incremental version — it's still in the file, commented, with a note explaining the switch — but correctness across the full touchpoint history was worth more than the runtime saving.

Inputs that change after the fact

Two attribution inputs are mutable. A self-reported survey gets answered late or reprocessed. A coupon-code-to-channel sheet is maintained by hand, and marketing recategorizes codes retroactively. A fixed-lookback incremental model misses both silently — remap a code in September for codes used in March, and March is now wrong with nothing to trigger a rebuild.

The trade-off I'd defend: this deliberately spends more compute than a pure append. The alternatives were worse. A nightly full refresh is correct but doesn't scale with event volume; a pure incremental is cheap but silently wrong the moment a coupon mapping changes. The impacted-list approach targets exactly the rows that can be stale and leaves everything else alone.

Fitting non-events into an event stream

Survey responses and coupon redemptions are real attribution signals, but they aren't clickstream events — they have no natural position in a touchpoint sequence. Two questions had to be answered.

Where do they sort?

A survey answer describes how someone first found us, so it has to rank first. A coupon is redeemed at checkout, so it has to rank last. Rather than special-casing the ordering logic in every downstream model, I emit synthetic rows at engineered timestamps — and correct sort order then falls out of ordinary chronological ordering.

When should they be ignored?

If someone answers "I found you on Facebook" and a Facebook touchpoint already exists in their 28-day window, adding a synthetic row double-counts the same channel. So enrichment is conditional — expand only if the channel isn't already represented. This is the highest-risk logic in the pipeline, and it's what the unit tests target.

"Direct" is not a channel

direct is the absence of information. Treating it as a channel lets it absorb credit that belongs somewhere else. The rules I landed on, after stakeholder alignment:

• Excluded from linear weighting entirely — it can't earn a share of credit
• Last touch means last non-direct touch
• Fallback: if someone genuinely has no non-direct touchpoint in the window, attribute 100% direct. The real signal is "we don't know," and that should be visible rather than quietly redistributed to whatever else is nearby
• Email before signup is dropped — you can't have been emailed by a product you hadn't signed up for yet, so those are mis-stamped touchpoints
• Transactional email excluded from entity attribution — a receipt is not marketing (a post-launch refinement)

Click IDs, narrowly scoped

UTM parameters get stripped by redirects, mangled by link shorteners, and dropped by in-app browsers. Platform click identifiers — gclid, gbraid, wbraid, fbclid, msclkid, ttclid — survive where UTMs don't.

I added them as an override tier with a deliberately narrow precedence rule. Click IDs override UTM attribution only when a click ID is present but UTM claims organic, direct, or a non-target platform — or when no click ID is present but UTM claims paid.

Why narrow: "click ID always wins" is simpler, but it would override legitimate organic attribution any time a stale click ID lingers in a URL someone shared.

The projected correction: my exploratory analysis put it at a few percent for paid Google and a substantially larger double-digit shift for paid Meta last-touch signup attribution. Meta is far worse because iOS link handling strips UTM parameters much more aggressively — meaning a meaningful share of paid social signups had been credited to the wrong channel entirely.

Five layers, each catching something the others can't

Attribution fails quietly. There's no exception, no null pointer — just a number that's slightly wrong in a direction nobody notices until someone questions a channel's budget months later. So the testing had to be layered, with each layer aimed at a different kind of wrong.

1 · Schema tests — is the shape still right

Uniqueness and not-null on the primary key of every model in the DAG. Unglamorous and the first thing to catch a bad join — a duplicate row at the touchpoint grain silently double-counts credit downstream.

Where one table holds two source types with different keys, the tests are conditional:

- name: user_id
  data_tests:
    - unique:   { where: "source = 'hdyhau'" }
    - not_null: { where: "source = 'hdyhau'" }
- name: entity_id
  data_tests:
    - unique:   { where: "source = 'coupon'" }

And where a key can legitimately be null, the yml records why. Absence of a test should be a decision someone wrote down, not an oversight nobody noticed.

2 · Domain tests — did something new appear

Accepted-values on the survey response set (19 options) and the coupon channel set (12). These exist because of a specific failure mode: someone adds a new option in a product form or a new partner channel in a spreadsheet, it arrives with no mapping rule, and it quietly lands in other. Attribution for that channel simply never appears, and nothing anywhere signals a problem.

3 · The invariant — is the logic self-consistent

I wrote a custom generic test asserting that for any conversion, the attribution weights across its eligible touchpoints sum to 1. It's applied to both scope models, and it's the highest leverage test in the project.

It works because it doesn't check any specific behaviour — it checks a property that must hold if every behaviour is correct. Dedup dropping a row it shouldn't, enrichment expanding a survey twice, ranking mis-scoping a window: all of them break the sum. One assertion standing in for a whole class of bugs.

4 · Unit tests — do the edge cases still behave

Three scenario-named cases on the survey overlap logic, which is the riskiest rule in the pipeline — fixed input rows in, expected output asserted:

• survey_search_matched_by_enrollment_organic_google — the survey channel already appears at conversion, so it must be suppressed
• survey_facebook_matched_by_prior_visit_paid_facebook — matched by an earlier visit instead, also suppressed
• survey_reddit_no_match_expands — genuinely new channel, so it must expand into a synthetic touchpoint

Naming them as scenarios rather than test_1 matters: when one fails, the failure message already tells you which business rule broke.

5 · Monitoring — is the world still what we assumed

Tests assert what should be true of the code. Monitoring watches things that change without anyone touching the code at all.

And the one that isn't automated

Before/after validation. At every milestone I compared pre- and post-change distributions of attribution channel for signups, new buyers and enrollments, plus paid CAC shift — then wrote a note for stakeholders explaining what moved and why.

No test suite can tell you whether a 6% swing in paid Google's share is a bug or the correction you were aiming for. That judgment is the work; the tests just make sure nothing else moved while you were making it.

Swapping the engine without stopping the car

Replacing the attribution backend is only half a project. Everyone downstream — marketing, finance, leadership — reads this through dashboards, and those dashboards had to keep answering the same questions the whole way through. A migration that leaves people unable to pull their own numbers for two weeks has failed, regardless of how clean the models are.

That last one mattered more than it sounds. Two independent copies of a channel taxonomy will always drift, and when they do, the argument isn't about the data — it's about whose dashboard is right. Collapsing them to one definition removed a recurring class of meeting.

Four phases, ten weeks

I chose milestone-based validation over strictly isolated merge requests. Each milestone was validated by comparing signup attribution before and after. In a DAG this interconnected, small isolated MRs would have left it in inconsistent intermediate states for longer, not shorter.

By the numbers

Roughly 3,000 lines of attribution SQL, built inside a ~900-model dbt monorepo. GitLab merge-request flow with CI/CD, developing against production state with deferred runs so every model change could be validated on real data before it merged.

The actual work

Write-ups are easy to make sound good. These are the source documents — my design diagrams at full resolution, the tech spec structure, and the code. Locked because they're real internal work product; the password is in my email signature and I'll hand it out in any conversation.

What shipped

• Subscriptions became a first-class conversion — enrollment and membership unified at entity grain with first-purchase flags, so a customer has one defined acquisition moment regardless of which way they first paid
• One stream feeds everything — user, signup, enrollment, and membership attribution all derive from the same ranked events, so they reconcile against each other
• Taxonomy centralized into a single 606-line macro layer — one mapping change, one place
• Retroactive reprocessing supported via an impacted-user strategy

What changed, and what it set up

A rebuild like this pays off in three places: questions the business can suddenly answer, work that stops being expensive, and options that open up afterwards.

What it set up

• Calibrating attribution against incrementality. Because weighting is centralized, the measured lift from geo holdout tests can be layered into the channel report rather than living in a separate deck nobody reconciles.
• Better weighting models. Time decay, or a data-driven approach like Markov, become a change to one macro instead of a rewrite — the sequencing and weighting are already isolated.
• A trustworthy denominator for CAC. The blended CAC work only means something if the attribution underneath it is consistent; this is what made that true.

The thing I'd point to above any single metric: good attribution infrastructure changes what a marketing meeting is about. When four models disagree, the meeting is about whose number is right. When there's one answer everyone trusts, the meeting is about what to do with it — which is the only version of that meeting worth having.

Why any of this is necessary

Everything in projects 01 and 02 produces a correlational answer. Attribution observes that a customer touched a channel and then converted, and distributes credit according to rules I chose. Those rules can be reasonable, documented and consistent — and still not tell you whether the channel caused anything.

That distinction has a price tag. A retargeting campaign shown to people already intending to buy will look magnificent in any attribution model, because it genuinely was the last thing they touched. Whether it changed a single decision is a different question, and attribution structurally cannot answer it.

Holding out half the country

The design: a geo-lift test with a 50% US holdout. Primary metric New Buyers, secondary Signups — deliberately anchored on payment rather than signup, the same principle driving the attribution rebuild.

Reading the result

The output isn't "the campaign drove 4,000 conversions." It's the gap between what happened in test geos and what the control geos say would have happened anyway — with an interval around it, because it's an estimate.

Designing one so the answer means something

Most failed incrementality tests fail at design, not analysis. Four decisions do the damage:

The vendor migration

The incumbent measurement vendor had an existing export pipeline in our warehouse. We moved to a new vendor — and I built the replacement data model a week before the old pipeline was sunset. Successor shipped before predecessor retired, so there was no gap in measurement coverage across the transition.

Tests designed and run

How this was meant to feed back into attribution

The second-phase plan was to calibrate attribution channel weights against measured incrementality. That's the right division of labour between the two: attribution allocates credit across touchpoints, incrementality tells you whether the channel caused anything at all. Layering measured lift into the monthly channel report was the roadmap item.

Evaluating a vendor that optimizes itself

A vendor offered AI-optimized email content — subject lines, copy, recommendations. The question wasn't whether their emails performed better than nothing. It was whether they drove genuinely incremental conversion over our standard emails, whether any lift decayed, and where the cost-benefit break-even sat.

Why this was harder than a standard A/B test

The vendor's algorithm uses Thompson Sampling — it explores early and exploits later. Users were randomly assigned, tests ran on two sends a week with multiple variants each, and the same test could run for several weeks.

That breaks the two obvious ways to read the result. Looking at early periods understates true performance, because the bandit is still exploring. Pooling the entire window mixes exploration with exploitation, so the average describes a system that no longer exists by the end of the test. Evaluating a non-stationary bandit against a fixed control needs the lift curve over time, not a single number — which is also the only way to answer the decay question that was asked.

What I built: the Python evaluation, plus the dbt model producing the metric file sent back to the vendor, joined against user-attribute models for segmentation.

What testing changed

The strategic value isn't any single result. It's having a mechanism that can settle "is this channel actually working" with evidence — so that question stops being decided by whoever argues most confidently in the meeting.

A spreadsheet, half automated

The daily CAC tracker was an Excel sheet. Part of it pulled automatically through Supermetrics; the rest was copied by hand each morning from dashboards, agency spend exports, an affiliate portal, and influencer contracts. Roughly 60% of it was manual.

That arrangement has a specific failure pattern. It works — until the person maintaining it is on holiday, or a platform changes an export format, or someone pastes into the wrong column. It also couldn't refresh over weekends, so Monday began with a two-day gap in the number leadership steers spend by. And the effort scaled linearly with channels: every new platform added another manual pull to somebody's morning.

The daily pacing dashboard

The output was a daily CAC and pacing dashboard in Omni. The metric design matters more than the layout, so here's the structure rather than a screenshot.

Deciding what counts as an acquisition cost

Automating the pipeline is the easy half. The half that generates actual disagreement is the numerator: which costs belong in CAC at all. Every inclusion decision moves the number, and each one has someone with a reason to argue the other way.

None of these has a universally right answer. What matters is that the rule is written down, applied consistently, and the same in the dashboard as in the warehouse — otherwise every CAC conversation restarts from first principles.

Campaign naming is load-bearing infrastructure

All of this depends on one unglamorous thing: the join key between what a campaign spent and what it produced. That key is the campaign naming convention, and when it's inconsistent the entire cost side silently degrades — spend lands in "unattributed", channel CAC is wrong, and no error appears anywhere.

It's the least interesting artifact I've worked on and one of the highest-leverage. A convention nobody enforces is just a document; enforcement has to live in the pipeline, where an unparseable campaign name fails loudly rather than quietly bucketing to other.

Three numbers, three different jobs

"What's our CAC" is an ambiguous question, and answering with a single number is how teams end up arguing past each other.

And a reporting detail that causes real confusion: platforms restate spend retroactively. Yesterday's number is not final — invalid traffic credits and late conversions land days later. A pipeline that appends rather than reprocesses a trailing window will slowly drift out of agreement with the platform's own UI, and the first anyone hears of it is someone asking why the dashboard disagrees with Meta.

The spend model layer

The dashboard needed a spend layer that didn't exist yet. Built and iterated over eight months:

• A daily ads fact model built from scratch, then iterated to cover every channel's new buyers and signups, then a third version adding Microsoft and TikTok
• Campaign hierarchy models — campaign, ad set, and ad structure, so spend could be cut at any level rather than only in total
• A dedicated ads model folder with independent scheduling, including moving the spend job earlier in the orchestration so it lands before downstream CAC models run
• Geo campaign models supporting both the CAC dashboard and the geo-lift tests
• An outbound data-sharing model feeding warehouse data back out to an ad platform
• Ongoing cost-model corrections — affiliate cost, re-engagement CAC, referral credits as marketing cost, fixed cost allocation, and excluding spend that wasn't acquisition

Attribution nobody looks at changes nothing

This is the least architecturally interesting project here and arguably the most valuable. A correct attribution pipeline terminating in a spreadsheet somebody rebuilds by hand every morning has not changed a single decision.

The broader point I'd make about this kind of work: the constraint on most marketing teams isn't analytical sophistication, it's latency. A perfect answer that arrives on Wednesday about Monday's spend is worth less than a good answer available Monday afternoon.

Browser-side tracking loses conversions before you ever see them

A conversion pixel firing in someone's browser has to survive a long series of obstacles before it reaches an ad platform. Most discussion of attribution assumes the event arrives. Often it doesn't — and the losses aren't random, which is the part that damages measurement.

Server-side events are the structural fix: fired from your own backend when the payment actually records, so they don't depend on the user's browser cooperating. But they introduce two problems browser pixels don't have — identity matching and deduplication.

Aligning server-side events to product truth

A set of "golden" server-side conversion events underpinned both marketing optimization and product analytics — and they weren't firing reliably. We audited each one against the core product tables that represent ground truth.

The framework was the same for every event, four questions in order:

Success criteria we set

Backed by data-quality monitoring on the percentage of initialized payments with associated conversion events, validating both event presence and field population.

Auditing what actually reaches Meta and Google

Events being correct in the warehouse and events being correct at the ad platform are two different claims. The conversions API path has its own failure modes, and this is the layer directly wired to value-based targeting — so an error here doesn't just misreport, it actively misdirects spend.

This is the direct link between instrumentation and the value work in project 05. Value-based targeting is only as good as the value it receives — and a revenue payload mapped from the wrong Segment property, or counted twice, teaches the platform something false about which customers are worth pursuing.

What changed, and what it makes cheap

The honest framing: instrumentation isn't a project you finish. It decays continuously as the product ships, platforms change their APIs, and browsers tighten privacy. What you can build is the capacity to notice — and that's the part that compounds.

Working the upstream problem instead of modelling around it

This is the clearest case in my work of an attribution problem that could not be solved in dbt. I could model payment-level attribution perfectly and the platforms would still be optimizing badly, because the events carrying that signal to the ad platforms were incomplete and their revenue payloads were wrong.

The tempting move is to build a workaround downstream. The correct move was to go upstream with my manager, audit the instrumentation against product truth, and set numeric acceptance criteria — then let the attribution work land on a foundation that could actually carry it.

The LTV work behind this

I partnered with our ML team on LTV modeling across two studies — one in 2022, and a follow-up once memberships became the growth focus. I owned the attribution and cohort definitions the channel-level cuts ran on, and the CAC side of the ratio.

Three findings shaped how I think about acquisition:

The modeling approach they used was a hurdle framework: model retention, then model spend among those retained. That shape — a probability multiplied by a conditional value — is the same one I reach for independently, and it's the backbone of the approach in the rest of this page.

Why I don't report CAC on its own

Those findings land directly on where the money goes, and they're the reason a CAC target by itself is a trap.

• The cheapest channel is often not the best channel. If one source delivers customers at a low CAC but those customers churn in month two, it loses to a more expensive channel bringing people who stay. You cannot see that in a CAC dashboard.
• The payback window silently decides the winner. Because some channels' value gap narrows over time, a 30-day view and a 12-month view can rank the same channels in opposite orders. Choosing that window is a strategic decision, not a reporting detail.
• All of it rests on channel assignment being right. Channel-level LTV inherits every flaw in attribution — which is why the attribution rebuild and the instrumentation audit are upstream of this work rather than beside it.
• Retention findings change what acquisition should optimise for. If retention drives value, then acquisition's job isn't volume of buyers — it's buyers who resemble the ones who stay.

How I'd build the predictive piece

Explanatory modeling tells you what drives value. Predicting it per user, early enough to act on while a budget decision is still live, is a different problem. Here's how I'd approach that for a freemium subscription business.

The trap: almost everyone is worth zero

Take a consumer subscription product with roughly 100 million registered users and 2 million subscribers. Around 98% of acquired users will never pay anything. That single fact breaks the obvious approach.

If you train one model to predict lifetime value directly across everyone, it learns that the safest prediction is approximately zero. It will score well on average error and be completely useless for growth decisions, because the entire point is identifying the small minority who show early signs of becoming valuable — and the model has been rewarded for ignoring them.

The input window matters as much as the model: predictions run off a user's first 14 days of behaviour — active days, activity volume, whether they subscribed early, plus acquisition cohort, channel and platform. Fourteen days is early enough that the estimate arrives while a budget decision is still live.

Defining what you're predicting

Before any feature work, two decisions do most of the damage if you get them wrong: what the target actually is, and how long you have to wait to observe it.

Justifying the proxy window

Ninety days isn't lifetime value — it's a window short enough to observe. That substitution needs evidence, not assertion, and the test is straightforward: on historical cohorts, how strongly does the short-window value track the long one?

In the marketplace's own LTV work, 4-month value correlated with 12-month value at roughly 0.87, which is what justified using the shorter target to get a signal faster and include more recent cohorts. A second check governs the input side: about 30 days of post-acquisition behaviour was needed before the features carried enough signal, correlating around 0.82 with the target. Both numbers are the kind of thing I'd re-derive rather than inherit.

What goes in, and what must not

Selection

• Domain screen before statistical screen. Drop what can't plausibly be causal or available at scoring time first, so selection isn't chasing noise across hundreds of candidates.
• Regularised logistic regression to start — L1 does selection and leaves readable coefficients, which matters when the output has to be explained to a growth team that will spend against it.
• Check collinearity within families. Engagement counts move together almost by construction; sessions, active days and volume will fight each other for the same coefficient.
• Separate drivers from controls. Cohort, channel and country go in as controls so behavioural effects are estimated other things equal — otherwise channel mix differences get read as behavioural signal.
• Only then reach for something less interpretable, and only if it earns its keep against the regularised baseline on the metrics below.

Why not something simpler

I'd still start with the two-step model rather than something more sophisticated. It's explainable to a growth team, it can be built and validated quickly, and it establishes the measurement loop. Complexity is worth adding once there's something working to improve on.

Model metrics, then business metrics

Two layers, and they fail differently. First, is each model any good on its own terms. Second, is the combined estimate good enough to spend against.

Then the business layer

Test the combined estimate on a recent holdout the model never saw but whose actual 90-day value is already known. Check two separate things — because a model can pass the first and fail the second in a way that costs real money.

What has to be true for this to hold

Stating these explicitly is part of the deliverable. Each one is a place the model can quietly stop working.

• Early behaviour predicts later value. Fourteen days should signal 90-day outcomes — but some users convert later because of a campaign, a product change, or a reminder that simply isn't visible in that window.
• Historical patterns still hold. Observing actual 90-day value takes 90 days, so even the freshest training cohort is three months stale. In a fast-moving company, that lag is itself a risk.
• User-level data is complete. Channel, platform, subscription date and early activity all have to be tracked correctly. Tracking gaps and identity-stitching failures bias the estimate — which is exactly why attribution and instrumentation work sits upstream of this.
• Acquisition channel is a fair unit of comparison. It's a usable budget view, but it misses later influence — someone acquired through Meta may return and subscribe through Google.
• Coarse flags capture behaviour. A binary web/iOS flag makes an 80/20 user look identical to a 20/80 one.

When 90 days stops being good enough

A 90-day window is a practical proxy, not lifetime value. The natural next step is survival analysis — modeling the probability a subscriber is still active at each point in time, and projecting toward full lifetime value instead of stopping at an arbitrary cutoff.

It matters because churn isn't evenly distributed. The first one to three months are the critical period, while people are still deciding whether the product fits their routine. Anyone who survives past that tends to stay much longer. It's the gym membership pattern: most cancellations happen in the first two months, and whoever is still turning up in month three rarely quits. A fixed-window model can't see that changing risk; a survival model is built around it.

Earning the right to move budget

A model being accurate on historical data isn't the same as a team being ready to spend against it.

Knowing what the model is bad at

Predicted LTV is an early directional signal, not an automatic budget rule — and it carries a bias worth naming out loud. Because it's built on acquisition channel, it will systematically over-credit lower-funnel channels and under-credit upper-funnel ones, for exactly the same reason last-touch attribution does.

So I'd use it directly for lower-funnel decisions, and pair it with incrementality testing before touching upper-funnel spend — where the model is least trustworthy and a holdout test is the only honest read.

And on value-based bidding: if the estimates prove stable over several cycles, predicted LTV could be tested as a value signal for ROAS optimization in the ad platforms. But that's the destination, not the starting point. Budget guidance first — it's lower risk, it's reversible, and it proves the number is worth trusting before an algorithm starts spending against it.

Why this is the piece that makes the rest pay off

It's also the piece with the longest dependency chain behind it. Channel-level LTV requires correct channel assignment, which requires working attribution, which requires instrumentation that fires. Getting to a trustworthy LTV:CAC number is the reason the other four projects had to happen first — and why I'd be sceptical of any unit-economics number from a team that hasn't done that groundwork.