The Setting and the Ceiling Are Two Different Objects
An attribution window is a counting rule: a conversion within N days of the click still belongs to that click. The rule assumes something it cannot supply, a durable link between the person who clicked and the person who bought.
That link is almost always a cookie, and cookies belong to the browser, not to your ad account. So the window is two numbers stacked on each other: the one you chose, and the one the browser will honour. Widening the first does nothing to the second. That catches experienced buyers, because every other lever in an ad account does what its label says.
Three ordinary things a buyer does, and the browser rule sitting underneath each one that the ad account has no way to report.
What Safari Actually Enforces in 2026
Here is the current behaviour, stated exactly, because most guides on this topic describe rules that changed years ago.
Safari deletes all script-writable storage for a site if the site has not received a click, tap or keyboard input in first-party context in the last seven days of browser use. That covers cookies set through document.cookie, localStorage, IndexedDB and service worker registrations. Seven days of browser use is not seven calendar days; a light user stretches it out. This is what people mean by "Safari's 7-day cookie limit", and it is a deletion policy, not an expiry date.
The older ITP 2.1 behaviour, a hard seven-day cap written into the expiry of every JavaScript cookie, was removed by WebKit in 2022 and folded into that deletion policy. If a guide tells you Safari rewrites your cookie's expiry to seven days, that guide is four years stale.
The shorter rule is the one that actually bites paid traffic. Since ITP 2.2, a persistent cookie set through document.cookie gets a maximum expiry of one day when two things are true at once: a domain Safari has classified as having cross-site tracking capabilities sent the user to your page, and the landing URL carries a query string or a fragment. An ad click from a large social or search platform, landing with fbclid or gclid attached, meets both conditions. Classification runs on-device and per-user, so it is not literally universal, but for the platforms affiliates buy on it is the normal case rather than the edge case.
Two more details matter. Cookies set by your own server with the Set-Cookie header on genuine first-party infrastructure are not restricted by ITP at all; they keep the expiry you declare. That exemption is exactly what the CNAME cloaking defense closes. If the subdomain doing the setting is a CNAME alias to a cross-site origin, or resolves to an IP whose first half does not match the browsed site, WebKit caps those server-set cookies at seven days too. So "we use a first-party subdomain" only holds if the subdomain is yours down to the address record.
Other browsers pull the same way by different means. Firefox has had Total Cookie Protection on by default since June 2022, which partitions storage per site rather than expiring it, and it wipes storage from known-tracker origins that go 45 days without a top-level interaction. Firefox has no CNAME cloaking defense.
Chrome is the one people keep getting wrong. Google confirmed in April 2025 that it would not run the choice prompt and would not deprecate third-party cookies, and most of the Privacy Sandbox work was shut down that October. Third-party cookies still work in Chrome. So the truth is more awkward than the slogan: your measurement is split across browsers enforcing very different ceilings on the same campaign.
The Identifier Decays. The Dashboard Does Not.
The teal row is the only one that survives all four moments, and it is the only row that does not live in the visitor's browser.
Hour 0 through hour 23, everything reconciles. From hour 24, a browser-only setup on a decorated Safari arrival has lost the thread, and every sale after that lands as organic, direct, or unattributed. Your 30-day window is still sitting in the settings doing nothing, because the thing it was counting is gone.
The Math of a Window That Cannot Reach
Here is a worked illustration, and these numbers are a shape I chose to show the mechanism, not a measurement of anyone's account. Take a considered offer where buyers split roughly in half: some decide inside the first day, the rest take four to eighteen days because the price is high enough to sleep on.
On Chrome, both halves stay connected to the click for the length of the window you set. On a Safari visitor who arrived decorated from an ad platform and never came back in between, a JavaScript-only setup holds the link for one day. The fast half reports. The slow half does not. Same offer, same creative, same intent, and the only variable is which browser the person was holding.
So this is not noise. Noise averages out over volume. A bias correlated with browser choice accumulates instead, and it points one way: against whichever part of your audience takes longer to decide. High ticket, B2B, anything where the buyer talks to a spouse first. Those are the offers the ceiling punishes hardest, and the ones where a long window was the obvious right call.
Two Opposite Failures of the Same Setting
I wrote about the other half of this a few weeks ago, in the piece on attribution window inflation. That one is a window reaching too far: widen it, let view-through in, and reported return climbs while the business stands still. This is the mirror image. Same dropdown, opposite failure. There the setting over-claims; here it cannot deliver what it claims. Run both at once and the inflation makes the number look healthy while the ceiling deletes the slow, high-value sales that number should have been built on.
It is also a different problem from the one in the GA4 measurement piece. That was about losing the event at the moment of conversion: consent denied, script blocked, tag never fired. Here the event fires perfectly. The sale is recorded, the money lands, the report renders. What decayed is the identifier that would have tied that sale to a click made eleven days earlier. One is a collection failure at a point in time. This is a memory failure across time.
Is Your Window Real?
Most setups fail on the first question and never find out, because failing it produces a report that looks entirely normal.
Why This Is Sharper Now Than It Was Two Years Ago
Three things have moved at once.
Safari 26 shipped Advanced Fingerprinting Protection on by default in September 2025, stopping scripts it classifies as fingerprinters from setting long-lived script-written storage and from reading query parameters and document.referrer in the browser. Link Tracking Protection is still off by default in normal browsing, so click IDs do arrive in the URL, but Safari already strips them in Private Browsing. The direction of travel has only ever been one way.
Meta has quietly moved its own ceiling down to meet the browser's. The click-through options in an ad set are now 7 days or 1 day, with a 1-day engage-through and 1-day view-through default. Google Ads still defaults to a 30-day click window and lets you go to 90. So on Meta your stated window sits at the ceiling by coincidence. On Google, and inside almost every affiliate tracker, it sails well past it.
And the audience keeps drifting toward the browser with the tightest rules. Safari at 52.13% of US mobile is not a segment you write off as an Apple tax. It is most of the phones your offers land on.
What Actually Lifts It
Nothing in the ad account. No attribution window setting, on any platform, extends the life of an identifier the browser has decided to delete.
What raises the ceiling is moving the memory out of the browser, which is the discipline server-side tagging is named after. Two pieces, both boring, both load-bearing.
The first is a durable server-side record created the moment the click lands. Your server sees the full request URL before any browser restriction touches scripts on the page. Write the click identifier down there, with a timestamp, in storage you own. That row does not vanish because someone skipped your site for eight days.
The second is identity captured on a page you control, before the visitor leaves for the checkout. An email address is not subject to ITP. Once a hashed email sits against a click identifier in your own database, the join between click and sale stops depending on the browser still holding a cookie a fortnight later.
Get both and the window in your dropdown becomes an instruction rather than an aspiration. Get neither and your real window is one day on decorated Safari arrivals, whatever the settings screen says.
So What Do You Do About It
Find your real ceiling before you touch another budget. Take a campaign with a long stated window, split its conversions by browser, and compare the time-to-conversion curve on Safari against Chrome. If the Safari tail falls off a cliff at day one or day seven while Chrome's keeps going, you are not looking at Safari users behaving differently. You are looking at the ceiling underneath the window.
Then fix the order of operations. Record the click server-side at landing, collect an email on your own page, and join the sale back through your own records instead of whatever the browser still remembers. That is the design behind ClickerVolt: the click identifier is written server-side on arrival and held against the conversion whenever it reports, days or weeks later. See how the server-side click record works.
Whatever tracker you run, hold on to this. A number in a settings dropdown is a request you are making of infrastructure you do not own. Until you can point at where the click is stored and how the sale finds its way back to it, you do not have a 30-day window. You have a 30-day hope.
This piece describes documented browser behaviour and platform settings verified in August 2026. The split-audience example is an illustration chosen to show the mechanism, not a measurement of any specific account.
