An attribution window is the length of time a click remains eligible to be credited for a sale. Someone clicks your post today. If they buy inside the window, the post gets the sale. If they buy after it, the post gets nothing and the sale is counted as coming from somewhere else, or from nowhere at all.
It sounds like a technical footnote. It is not. The window is one of two settings that determine your entire attribution report, and changing it from seven days to ninety can double the revenue your content appears to have produced without a single extra sale occurring.
Longer windows always flatter you
This is the thing to internalise. A longer window can only ever attribute more sales, never fewer. Every sale credited by a short window is also credited by a long one, plus additional sales the short window left unattributed. So the direction is always up, and the temptation is always to extend.
Push it far enough and the report becomes meaningless. With a ninety-day window, almost every customer has clicked something of yours at some point in the preceding three months, so almost every sale gets attributed to content. The unattributed bucket empties, the dashboard looks magnificent, and the number no longer distinguishes between posts that caused sales and posts that merely preceded them.
The causal question hiding inside a long window is uncomfortable. If someone clicked a post eleven weeks ago and bought today after finding you through a Google search, did the post cause the sale? Possibly, partially. But crediting it fully is a claim about causation that the data does not support, and you will act on that claim by making more posts like it.
Match the window to how people actually buy your product
The right window is roughly the time a typical customer takes between first serious interest and payment. That varies enormously by price and by what you sell.
- Impulse purchases, under about $30 — a template, an ebook, a small tool. One to seven days. These buy in the same session or not at all.
- Low-priced subscription software, roughly $10 to $50 a month. Seven to thirty days, covering a trial period plus a few days to decide.
- Higher-priced or team purchases where someone else has to approve it. Thirty to sixty days, and treat the far end sceptically.
- Anything with a long, consultative sales process. Sixty days plus, but at that point single-touch attribution is the wrong tool and you need a CRM.
If you offer a trial, make sure the window comfortably exceeds it. A seven-day trial with a seven-day attribution window will fail to credit almost every conversion, because the payment lands on day eight when the click has just expired. Add the trial length to your consideration estimate and use that.
How to find your real number instead of guessing
You can measure this rather than estimate it. Take your last fifty or so customers and calculate the gap between their first recorded click and their payment. Sort the list. Find the point where most of them fall below — the seventy-fifth or eightieth percentile is a reasonable place to draw the line.
What you usually discover is that the distribution has a fat head and a long thin tail. The overwhelming majority buy within a few days, and a handful take months. Setting the window to catch the tail means accepting a lot of dubious credit in order to capture a small number of genuine late conversions. Setting it just past the fat head captures nearly all the real signal.
If you do not have fifty customers yet, do not overthink it. Start at thirty days for subscription software or seven for a one-off purchase, and revisit once you have enough data to look at the distribution properly.
The other windows you are implicitly setting
Two technical limits can cut your window short regardless of what you configured. The first is cookie lifetime. If the first-party cookie carrying the tracking id expires in thirty days, a ninety-day window is fiction beyond day thirty. Some browsers cap script-set first-party cookies at a shorter lifetime than you requested, so the effective window may be shorter still.
The second is that the identifier has to survive the trip into checkout. If your tracking id is not carried into the payment — via Stripe’s client_reference_id or session metadata — then the window is irrelevant, because there is nothing to match on when the payment arrives. The window only governs which matched clicks count. It cannot rescue clicks that were never connected to the sale in the first place.
Say no when you are not sure
The principle that makes windows work is the willingness to attribute nothing. When a sale arrives and no click sits inside the window, the correct output is unattributed. Not the most likely post. Not a proportional split. Nothing.
This produces a report with a visible gap, and the gap is the most honest thing on the page. It tells you what share of your revenue your tracking cannot explain, which is real and useful information. A dashboard that quietly distributes that gap across your posts is telling you a specific post earned money it did not earn, and you will spend next month making more posts like it.
seenpaid works this way deliberately. It uses a conservative default window and will not claim a sale it cannot confidently tie to a click. Fewer attributed sales, all of which you can act on, beats a complete-looking report you have to mentally discount.
Set it, then leave it alone
Whatever you pick, the thing that matters most is holding it steady. If you change the window in March, your March-versus-February comparison is measuring the setting change, not your marketing. You will not be able to tell which, and you will draw a conclusion from it anyway.
Write down the window you chose and the date you chose it. Review it once or twice a year, or when something about the product changes materially — a new trial length, a big price change, a shift from one-off to subscription. Outside of those moments, resist the urge to tune it, especially when the numbers are disappointing. A window adjusted until the report looks good is not a measurement any more. It is a mirror.