Revenue attribution is usually filed as an integration problem: three tools hold three pieces of the answer, so join them. Checked against each vendor's own documentation, that framing misses two of the three failures. Identity is the easy one. Google's own support pages say a standard Analytics property keeps event-level data for a maximum of 14 months, and two months for large properties, so on a sales cycle longer than that the first touch is deleted before the dollar arrives. The same pages say data thresholding is system defined and cannot be adjusted, so the small segment you need may never appear in a report at all. ChartMogul's own product page describes subscription billing data and no pageviews. You cannot stitch what one system has already erased and another never held. HockeyStack, the named point solution for this job, published no dollar figures on its pricing page when checked in July 2026.
Revenue attribution gets filed as an integration problem, and that framing is comfortable because it implies a fix. Three tools hold three pieces of the answer, so wire them together and the dollar becomes traceable. Checked against what the vendors themselves publish, the framing misses most of the problem. Revenue attribution fails on three separate axes, identity is the easiest of the three, and it is the only one an integration touches.
The default stack for this job is Google Analytics for web, Amplitude or Mixpanel for product, and ChartMogul or Baremetrics for revenue. Three tools, zero connection. Every post about this says the tools do not talk to each other, which is true and also the shallowest version of the problem. They do not agree on who a person is, they do not keep data for the same length of time, and they do not report at the same grain. Fix the first and the other two are still there.
The short version
- Identity is one of three failures, not the whole thing. It is also the only one a join fixes.
- Retention: Google's own support page caps event-level data at 14 months on a standard Analytics property, with two months for large and XL properties.
- That means on a sales cycle longer than the retention window, the first touch is deleted before the revenue arrives. There is nothing left to stitch.
- Grain: Google states data thresholding is system defined and you cannot adjust it. A segment small enough to be interesting can be withheld from the report entirely.
- ChartMogul's own product page describes subscription billing data, CRM and CDP connections, and no pageviews or feature-usage events.
- So the revenue tool never held the behavior, and the behavior tool has already deleted the early part of it. The join has nothing to work with at both ends.
- The BigQuery export is the real escape hatch and it is available on free properties, capped at 1 million events per day. It returns raw rows and a warehouse to run.
- HockeyStack, the named point solution, published no pricing on its own page in July 2026. Vendr's dataset puts the median contract at $29,702 per year across 33 purchases.
- Call it the three-clock problem: identity, retention, and grain. A stack has to pass all three or attribution ends up in a spreadsheet.
Clock one: three tools, three ID spaces
The same human is three different records in the default stack, and joining them is a mapping table somebody has to build and then maintain forever. Google Analytics reasons about a client ID tied to a browser. A product analytics tool reasons about a user ID you assign at signup. A subscription analytics tool reasons about a customer or account ID that came from the billing system. Three ID spaces, one person, and no shared key between them.
This is genuinely solvable. Send a user ID to all three, keep the mapping current, and you get a workable join for the accounts that made it all the way through. It is tedious rather than impossible, which is exactly why the whole category treats it as the problem. It is the part you can win. The two clocks below are the part you cannot win by wiring anything, and they are the reason attribution across a stitched stack keeps disappointing teams who did the integration work correctly.
Clock two: the data expires before the deal closes
Google's own support documentation sets event-level data retention on a standard Analytics property to either two months or 14 months, which is the failure nobody puts in the attribution post and the only one with a hard number attached. Analytics 360 adds 26, 38, and 50 month options. The same page states that large and XL properties are limited to two months, which means a property can lose the longer window by getting more traffic.
Read that against a real sales cycle and the consequence is not subtle. A deal that takes 16 months from first anonymous visit to first invoice has already had its first visit deleted from the tool that recorded it. Not aggregated, not sampled, not hard to query. Gone. The revenue lands in the billing system, which keeps its records permanently because accounting requires it, and the touch that started it is no longer available at event level to attribute anything to.
So the three tools do not merely fail to connect. They fail to overlap in time. Billing data is effectively permanent. Product event data lasts as long as the retention setting on the plan you pay for. Free web analytics data expires at 14 months, or at two if the property is large. Any attribution question that spans a period longer than the shortest clock in the stack is unanswerable from the stack, and no integration changes that, because the rows are not hidden or unjoined. They have been deleted.
This is also why the problem gets worse as a company gets better. Longer contracts mean longer cycles. More traffic can push a property into the two-month bucket. The quarter where attribution would have paid for itself is the quarter the data no longer reaches back far enough to produce it. Anyone comparing analytics tools for a SaaS team should read the retention row before the feature list.
Clock three: the grain you need may never appear
The third failure is that even inside the retention window and even after a clean join, the report can decline to show you the row. Google Analytics applies data thresholding to prevent a viewer from inferring the identity of individual users, and it applies to reports containing demographic data, to search query rows without enough users, and to narrow date ranges with low user or event counts. Google's wording on control is direct: data thresholds are system defined, and you cannot adjust them.
For revenue attribution this is precisely backwards from what the work needs. The segments worth finding are small by definition. A channel that produced six customers who each pay $2,000 a month is one of the most valuable rows in the business and one of the most likely to be thresholded out of a report that would have named it. The tool is not broken. It is doing privacy protection correctly, and privacy protection and small-segment revenue analysis are in direct tension.
Grain fails on the other end too, and here the vendor states it plainly. ChartMogul's own product page describes what it ingests: subscription billing platforms, API and CSV imports, customer enrichment, and CRM or CDP connections including HubSpot, Intercom, and Segment. It describes what it reports: MRR, churn, LTV, growth, ARR. It does not describe pageviews or feature-usage events, because that is not what a subscription analytics tool is for. It is very good at the money and holds none of the behavior.
| Tool in the default stack | What its own documentation says it holds | Shortest clock | The question it cannot answer alone |
|---|---|---|---|
| Google Analytics, standard property | Web sessions and events, subject to system-defined thresholding that cannot be adjusted | Event-level data at two or 14 months, and two months for large and XL properties | Which channel produced the revenue, once the cycle runs past the retention window |
| Google Analytics 360 | Same, with longer retention options at 26, 38, and 50 months | Up to 50 months | Same question, at enterprise pricing, and still thresholded |
| Amplitude or Mixpanel | Product events you instrument, with revenue present only as a property you send | Whatever the plan's retention setting is | What the dollar figure actually was, since the billing system is the only place that reconciles |
| ChartMogul or Baremetrics | Subscription billing data, plus CRM and CDP connections. No pageviews, no feature-usage events | Effectively permanent, because it is accounting | Why the money moved, because the cause lives in a system it does not read |
| HockeyStack | Marketing and account intelligence across GTM tools and CRMs. No published rate as of July 2026 | Not stated publicly | What it costs, before a demo call |
| The BigQuery export | Raw Analytics event rows, on standard properties, capped at 1 million events per day | As long as you pay to store it | Anything, until somebody writes the SQL and maintains the schema |
Every claim in that table is checkable against a primary source rather than a comparison site. The retention and threshold rows come from Google's own support pages on data retention and data thresholding. The export limit is on Google's BigQuery export page. The ChartMogul row is from its own subscription analytics page. The HockeyStack row is what its pricing page actually contained when opened in July 2026.
The escape hatch, and what it actually costs
The strongest objection to everything above is one word: BigQuery. Google's BigQuery export is available on standard properties rather than being an Analytics 360 feature, exported rows sit in your own project outside the Analytics retention window, and a daily standard-property limit of 1 million events is generous for most companies at this stage. So the retention clock is beatable, and any honest version of this argument has to say so first.
What it does not do is answer the question. The export hands back raw event rows. Turning those into revenue attribution means designing a schema, joining on a stable identity to a billing system that speaks a different ID space, deciding an attribution model, writing the queries, and maintaining all of it as the tracking changes. That is a data engineering project with an ongoing owner. For the team this post is about, a founder or Head of Growth at a seed to Series B company with no analyst on staff, the owner does not exist. The escape hatch is real and it is gated behind a hire that has not happened.
The honest summary of the counter-argument is this: the three-clock problem is solvable with a warehouse and a person. Most of the companies with the problem have neither. That is the actual gap, and it is a much narrower and more defensible claim than saying the tools cannot be connected.
What the point solution charges, and why nobody can tell you
HockeyStack's pricing page, opened directly in July 2026, carried no dollar figures, no plan names, and no tiers. It is the named competitor for this exact job and a serious product, and it offers a demo request and lists what all plans include: GTM and CRM integrations, a dedicated success team, custom setups for complex data, and real-time ROI tracking. This is normal for B2B revenue intelligence and it is worth naming rather than treating as a scandal.
It does mean the numbers in circulation are third-party contract data rather than list prices. Vendr's buyer guide, drawn from anonymized HockeyStack transactions in its dataset, reports a median of $29,702 per year across 33 purchases, a range from $24,040 to $77,500, small deployments at $12,000 to $24,000 a year, mid-market at $30,000 to $60,000, and enterprise between $75,000 and $150,000 or more. Those are real numbers from a real dataset and they are not a published rate. An earlier version of this post quoted a $1,399 to $2,200 per month figure sourced from a competitor's blog post. It has been removed, because a rate a competitor attributes to a vendor that publishes no rate is not a citation.
There is a smaller finding sitting next to the pricing one. Pulled from DataForSEO on July 31, 2026, the term revenue attribution runs 140 searches a month in the United States at a $34.41 cost per click, and attribution tools runs 110 a month at $167.54. That second figure is unusually high, higher than most sales and marketing terms, which is a decent proxy for how much margin the vendors in this category are working with. A keyword nobody searches, priced like that, describes a small market of expensive contracts rather than a broad one. The pricing structure of a GTM stack behaves the same way once you count the meters.
What one identity graph changes, and what it does not
The honest claim for a single platform here is structural rather than magical. If web behavior, product behavior, and revenue are recorded against the same profile in the same system, there is no ID mapping to maintain, there is one retention policy rather than three unaligned ones, and the grain of a small segment is a product decision rather than a privacy threshold you cannot see or adjust. That is what one identity graph means in practice, and it is the whole of the argument.
This is why the agentic GTM platform framing is a data-model claim before it is a feature claim. Intempt records traffic and revenue, product usage, and subscription metrics against one profile, which is what makes marketing attribution a query rather than a project. The Data Analyst then reads that graph, names the specific driver behind a metric movement, and ranks fixes by dollar impact. You review the ranking and decide what to do. That division of labor is the point: you are the person with the strategy, and the missing specialist is the one doing the reconstruction work.
What it does not change: attribution is still a modeling decision, first touch and last touch and multi-touch still disagree with each other, and one system holding all three data types does not make any particular model correct. Nor does it retroactively recover the 14 months your web analytics already deleted. Starting to record on one graph fixes the question going forward. It does not rebuild the past, and a vendor telling you otherwise is selling.
An illustration of the question shape
What follows is a constructed example, not a customer result. No account, dollar figure, or finding below describes a real Intempt customer. It exists to show the shape of a question that requires all three data types at once, which is easier to see in a concrete case than in the abstract.
Suppose net revenue falls three percent in a month while signups hold flat. The subscription analytics tool reports the drop accurately and holds nothing that explains it. The product analytics tool shows overall feature usage flat, which looks like a dead end. The web analytics tool shows traffic mix shifting slightly toward one paid channel, which looks unrelated. Each tool, read alone, produces a shrug.
The answer that would resolve it has to cross all three at once: accounts acquired through that one channel in a specific window adopted one particular feature at a lower rate than accounts from every other channel, and accounts that skip that feature churn at a higher rate two billing cycles later. That is a three-way question. It needs the channel from web data, the feature adoption from product data, and the churn timing from billing data, joined on the same accounts, reaching back further than one billing cycle.
In the three-tool default that question is a manual export project, and if the window reaches past the web retention setting it is not answerable at all. On one identity graph it is a question you ask. That is the difference the three clocks describe, and the reason a Data Analyst agent is useful here is narrow: the reconstruction work is mechanical, repetitive, and the exact thing nobody on a five-person team has time to do by hand.
What this post does not claim
- Not that Google Analytics, Amplitude, or ChartMogul are bad tools. Each does its own job well. The argument is about what happens at the seams, and about clocks rather than quality.
- Not that the retention limit is a flaw. It is a documented product decision with real privacy and cost reasons behind it. It is only a problem for a question that spans more time than the window.
- Not that thresholding is wrong. It protects user privacy and it is doing what it says. It just happens to hide exactly the small high-value segments revenue attribution exists to find.
- Not that the three-clock problem is an industry framework. It is this post's own model. The three underlying facts are from vendor documentation and are checkable. The framing is an argument.
- Not that BigQuery cannot solve this. It can. It requires a warehouse, a schema, and somebody who writes SQL, which is a real cost rather than a rhetorical one.
- Not that HockeyStack is overpriced or hiding anything. Quote-based pricing is standard in its market. The narrow point is that a buyer cannot compare a rate that does not exist publicly.
- Not that any specific customer result described this. The scenario above is explicitly constructed, and there is no dollar figure in this post attributed to an Intempt customer.
How to test your own stack this afternoon
- Open your web analytics admin and read the event-data retention setting. Write down the number of months. Check whether the property is classified large or XL, which caps it at two.
- Write down your median time from first anonymous visit to first payment. Not your sales cycle from opportunity creation, the whole thing, including the research phase before anyone filled in a form.
- Compare the two numbers. If the second is larger than the first, first-touch attribution on your closed deals is already impossible from your current data, and this is the finding that matters most.
- Check whether the BigQuery export is switched on. If it is not, switch it on today regardless of what else you decide. It costs nothing to start and the rows you do not export are gone permanently.
- Pick your three most interesting customer segments and try to pull each one in a report. Note which ones come back thresholded. Those are the segments your current stack structurally cannot analyze.
- Ask whether your revenue tool holds any behavioral data at all. Check its documentation rather than assuming, since CRM and CDP connectors can look like behavioral coverage without being it.
- Only now build a shortlist. Score candidates on identity, retention, and grain before scoring them on dashboards, because a tool that fails any of the three cannot answer the question you are buying it for.
Step three is the one that reframes the purchase. Most teams shopping for attribution assume the problem is that their tools do not talk to each other, and go looking for a tool that talks to more things. If the retention window is shorter than the sales cycle, the missing integration was never the constraint, and buying a better connector cannot fix a deleted row.
The version that holds up
Read the documentation rather than the comparison posts, this one included. Google publishes the retention windows, the threshold policy, and the export limits on pages anyone can open in a minute. ChartMogul publishes what it ingests. HockeyStack publishes no rate at all, which is itself a finding worth writing down. Between them those pages describe the whole failure without any vendor needing to characterize a competitor.
The defensible claim is narrow and does not need an invented statistic. Identity is the easy clock and the only one an integration touches. Retention deletes the evidence on any cycle longer than the window. Grain hides the segments small enough to be worth finding. So stop scoring attribution tools on how many sources they connect, check your retention setting against your sales cycle first, and judge revenue attribution on whether one system holds the behavior and the money on the same profile for the same length of time. That is the whole test, and one platform recording all three from the start is the shortest way to pass it.
Frequently asked questions. Answered.
Revenue attribution is the practice of connecting a specific dollar of revenue back to the web visit, campaign, and product behavior that produced it. It differs from marketing attribution in where it stops. Marketing attribution ends at a conversion event, usually a form fill or a signup. Revenue attribution ends at the money, which means it has to survive the whole sales cycle and reconcile against what billing actually collected.
