Glossary/Attribution mechanics
Attribution window
Definition
An attribution window is the length of time after an ad click or impression during which a resulting install or conversion is still credited to that ad interaction.
It is the single setting that most often explains why your ad network reports more installs than your own analytics does. Windows differ by network, differ between clicks and impressions, and on iOS are not yours to set at all — SKAdNetwork's are fixed by Apple. Comparing two reports without first comparing their windows is comparing two different questions.
Click windows and view windows are not the same setting
Every network keeps two separate clocks. A click-through window starts when someone taps the ad; a view-through window starts when the ad was merely rendered on screen. View windows are always shorter, because the causal claim is weaker — see view-through attribution for why that gap exists and how it inflates reporting when the two are summed into one number.
| Channel | Default click window | Default view window | Set by |
|---|---|---|---|
| Meta | 7 days | 1 day | Advertiser, per ad set |
| Google Ads | 30 days | 1 day | Advertiser, per conversion action |
| TikTok | 7 days | 1 day | Advertiser, per campaign |
| Apple Search Ads | 30 days | Not offered | Apple; fixed |
| SKAdNetwork | Fixed activity windows | Fixed, fidelity-type 0 | Apple; not configurable |
| Your own links | Whatever you choose | Whatever you choose | You |
Confirm the numbers in the network's own UI before you quote them
Default windows move. Meta, Google and TikTok have all changed theirs, and a window set two years ago on an existing ad set does not necessarily match today's default for a new one. The table above is a starting point for a conversation with your own account settings, not a substitute for reading them.
Why the same campaign reports different install counts
Three mechanisms produce almost every discrepancy, and they compound. Once you can name which one you are looking at, the numbers usually stop being mysterious.
| Cause | Symptom | Check |
|---|---|---|
| Different window lengths | Network reports more installs than you do | Compare click and view windows on both sides |
| Different last-touch priority | Two networks both claim the same install | See self-attributing networks |
| Different time zones | Daily totals differ, weekly totals match | Network reporting time zone vs your warehouse's |
| Different install definitions | Small constant gap | First open vs store download vs first session |
| Re-attribution windows | Existing users counted as installs | Whether re-engagement is folded into the install number |
The time-zone one is the most embarrassing and the most common. A network reporting in America/Los_Angeles and a warehouse reporting in UTC will never agree on a Tuesday, and both are right.
-- Last-touch attribution with an explicit 7-day click window.
-- The window is a predicate, not a property of the data: change the
-- interval and the same rows produce a different answer.
WITH candidate AS (
SELECT
i.install_id,
i.installed_at,
c.click_id,
c.campaign,
c.clicked_at,
ROW_NUMBER() OVER (
PARTITION BY i.install_id
ORDER BY c.clicked_at DESC -- last touch wins
) AS rn
FROM installs i
JOIN clicks c
ON c.device_match = i.device_match
AND c.clicked_at <= i.installed_at
AND c.clicked_at > i.installed_at - INTERVAL '7 days'
)
SELECT campaign, COUNT(*) AS attributed_installs
FROM candidate
WHERE rn = 1
GROUP BY campaign
ORDER BY attributed_installs DESC;Two things are worth noticing in that query. The window is a WHERE clause, which means re-running last month's report with a 30-day window instead of 7 legitimately changes history. And ORDER BY clicked_at DESC encodes last-touch; swapping it to ASC gives first-touch, and neither is more correct than the other — see multi-touch attribution.
On iOS, the window is Apple's
SKAdNetwork does not have a lookback window you configure. It has fixed activity windows measured from install, and postbacks that arrive after each one closes with a deliberate random delay. The consequence is that a SKAN report and a click-window report are not two views of the same measurement — they answer different questions on different clocks.
| Click window | SKAN window | |
|---|---|---|
| Clock starts at | The ad interaction | The install |
| Length | Advertiser's choice | Days 0–2, 3–7, 8–35 |
| Configurable | Yes | No |
| Result timing | Immediate | Delayed 24–144 hours after the window |
| Granularity | Per install | Aggregated, subject to crowd anonymity |
| Re-runnable on old data | Yes | No — the postback is the only record |
Never sum a SKAN number and a click-window number
The same install can appear in both, and frequently does — a StoreKit-rendered click produces a SKAN postback and, if your own link carried a click ID, a deterministic match as well. Report them as two columns and reconcile the trend, not the total.
The Android side stays under your control. The Play install referrer carries referrerClickTimestampSeconds and installBeginTimestampSeconds, which means you can compute the actual elapsed time for every install and choose a window from the observed distribution rather than from a default. If most of your genuine installs land inside four hours, a 30-day window is not measuring patience — it is collecting coincidences.
That distribution is also a fraud signal in its own right. A window wide enough to hide a click-spamming campaign is a window wide enough to pay for one, which is why click-to-install time belongs on the same dashboard as the window setting.
Choosing a window you can defend
- Plot your click-to-install time distribution first. The window should cover the bulk of real conversions and stop, not extend to a round number someone liked.
- Keep click and view windows separate in every report, always, even when a network hands you one merged figure.
- Write the window into the report itself. A number labelled "installs" with no window attached is not reproducible.
- Change windows rarely, and never mid-quarter. Every change rewrites the comparison you were about to make.
- Accept that SKAN sits outside all of this and report it in its own column.
The honest position is that a window is a business decision wearing a technical costume. Widening it does not discover installs that were always there; it changes the standard of evidence you accept for a causal claim. Networks default to generous windows for a reason, and the reason is not accuracy.
SKAN conversion value builder
The one window you cannot configure is SKAdNetwork's, so the lever you do have is what the postback carries inside it. This maps revenue or funnel events into the conversion values each window can report, and shows what survives when the coarse fallback applies.
Open the skan conversion value builder →Frequently asked questions
- What is an attribution window?
- It is the period after an ad click or impression during which a subsequent install or conversion is still credited to that ad. If someone clicks an ad on Monday and installs on Friday, a seven-day click window credits the ad and a one-day window does not — the same event, counted differently because the window is a rule you chose rather than a fact about the user.
- What is the difference between a click window and a view window?
- A click window starts when the user taps the ad; a view window starts when the ad was merely displayed. View windows are typically much shorter — one day is the common default against seven or thirty for clicks — because an impression is much weaker evidence of causation than a tap. They should never be summed into a single install figure, since one install can qualify under both.
- Why does my ad network report more installs than my own analytics?
- Usually because the network is applying a longer window than you are, is counting view-through conversions you are not, or is reporting in a different time zone. Check those three before assuming a tracking bug. A fourth cause is a different definition of install — store download versus first app open versus first session — which produces a small, constant gap rather than a variable one.
- Can I set my own attribution window on iOS?
- For your own first-party links, yes. For SKAdNetwork, no — Apple fixes the activity windows at days 0–2, 3–7 and 8–35 measured from install, and adds a randomised delay before each postback is sent. That is why SKAN results and click-window results cannot be reconciled row by row and should be reported as separate columns rather than added together.
- What is a good default attribution window?
- There is no universal answer, but seven days for clicks and one day for views is a defensible starting point for most apps because it matches the common network defaults and so minimises reconciliation work. The better approach is to plot your own click-to-install time distribution and pick a window that covers where real conversions actually land.
Related terms
- View-through attribution — View-through attribution credits an install or conversion to an ad impression the user saw but never clicked, provided the conversion happens inside a view window that is usually much shorter than the click window.
- Multi-touch attribution — Multi-touch attribution distributes the credit for a conversion across several of the marketing touchpoints that preceded it, rather than assigning all of it to a single first or last interaction.
- Click-to-install time — Click-to-install time is the elapsed time between the click on an ad and the first open of the installed app, measured per install and analysed as a distribution rather than an average.
- Self-attributing network — A self-attributing network is an advertising platform that performs attribution on its own servers and reports the installs it claims to have caused, rather than passing a click identifier for a third party to match.