By Leonid Malysh
The fix for fragmented revenue sits upstream of your models
I run analytics for a platform where thousands of businesses sell to their own customers, which means I watch the same revenue problem break in thousands of variations at once. The reflex to fix it tends to miss. When the revenue number stops adding up, teams reach for a better attribution model. The fault sits upstream, in how the business defines revenue and identifies the people who generate it.
The context has shifted fast. In 2026, revenue for a single product arrives through the app store, a direct web shop, and external checkout links, often from the same user in the same week. After the Epic settlements and the EU’s Digital Markets Act, Apple and Google let developers route purchases off-platform, and companies moved fast to capture the margin. Apple’s App Tracking Transparency had already made user-level ad attribution harder in 2021. Now the revenue side is fragmenting too, and most data teams have not budgeted for it.
The number under everything
Revenue carries more weight than any single metric your team ships, because it is the base your models learn from. Predictive LTV, propensity scores, marketing-mix models, the forecast that sets acquisition budgets: each trains on historical revenue. Feed them a base that double-counts web buyers and drops app-only ones, and the model learns the distortion as signal. It then bids, targets, and forecasts against a pattern that never existed. A wrong number in a dashboard misleads one meeting. A wrong number in a training set misleads every prediction it drives, until someone retraces the pipeline to its source. Finance cannot fix this for you. It lands on the data team.
When one user pays in two places
The stack underneath assumes a single rail: one user, one identifier, one receipt. When the same person buys a subscription in the app on Monday and a bundle from your web shop on Thursday, two systems log two events with two identifiers, and nothing tells them the events belong to one person. The pipeline then does one of two things. It counts the revenue twice, or it drops the web purchase because it cannot match it to a known user. Both corrupt the figure every model reads.
A quick illustration. Say a third of your revenue now runs through the web shop, and one in ten of those buyers also shows up as an app user. Count each of them in both systems and your total overstates by that overlap, while your app-only cohort reads weaker than it is. Tune acquisition against either distortion and you move budget in a direction you cannot see.
Fix identity before attribution
The reflex goes wrong here. The instinct is to buy or build a smarter attribution model, but a better model on a broken identity graph gives you a more precise wrong answer. The work that pays is identity resolution: mapping every payment, wherever it happened, to a single person. Use deterministic matching where a shared key exists, such as an account ID you pass through the web funnel. Fall back to probabilistic matching where it does not, with a confidence threshold your team sets and defends. Set it too loose and it merges two people; set it too strict and it splits one person into two. That threshold is a business decision wearing a technical costume, and it deserves an owner.
The failure you will not see coming is silent loss. A web buyer who never logged in becomes an orphan record, real money the pipeline cannot attribute, so it lands in an “unknown” bucket that grows until warehouse revenue stops reconciling with the bank. By the time the gap is large enough to notice, it has already been feeding your models for months.
One definition, and someone who owns it
Identity gives you the who. You still need agreement on the what. I treat revenue as a single balance: one canonical definition that every team and model reads from, rather than each team computing its own. That definition has to answer the awkward questions before they arrive. What counts as recognised revenue. When a refund reverses it. How you treat a chargeback that lands 40 days after the sale. Whether you book gross or net of platform fees. Write it down, and give one team the authority to own it.
I learned to insist on this the hard way. On one product, finance, growth, and my own analytics team each reported a different revenue figure for the same month. Every number was correct under its author’s rules, and none of them reconciled. The data was never the problem. We had never agreed on the definition. Settling it took a week of arguments and a single document, and it did more for forecast accuracy than any model change we shipped that quarter.
What to do before you rebuild the models
If your revenue is fragmenting, a few moves pay off before you touch a single model. Pass your account ID through the web checkout so off-store purchases return with a key you can join on. Reconcile warehouse revenue against the payment processor and the bank every week, and treat a growing “unknown” bucket as a defect rather than a rounding error. Agree the canonical definition across finance, data, and growth before you rebuild LTV or ROAS on top of it. Rebuild on an unreconciled base and you pay for the work twice.
The next two years will sort data teams into two groups. One keeps optimising models on a revenue number that fewer and fewer people can vouch for. The other spends the unglamorous months on identity and definition, and comes out with a figure the whole company trusts. The second group looks slower this quarter and wins the next eight. I would rather be in it.
Leonid Malysh is a data, analytics and growth leader with extensive experience building data-driven growth systems for technology companies. He has held senior roles in analytics and growth at Xsolla and is a contributor to GoPractice, with expertise spanning marketing attribution, product analytics, growth strategy and applied AI. He is also Co-Founder and Head of Analytics & Growth at SpeechStart.
