Can attribution windows or time zones explain an install discrepancy?
They can produce different reported totals or daily groupings, but a difference alone does not establish its cause. Record each report’s metric, population, attribution window, calendar timezone and extraction time. Re-export comparable data where possible; use aggregate comparison as evidence to investigate, not as proof of the settings in either account.
- What you need: Two exports plus a separate record of source reporting settings and extraction times.
- What you get: A settings checklist and comparable daily or segment differences in Parity.
- Limits: Daily totals cannot recover event timestamps, identify an actual attribution setting or verify a provider’s configuration.
Attribution and reporting dates answer different questions. An attribution window controls whether an eligible interaction can receive credit; the reporting timezone determines the calendar day used to group an event. Check both before treating two install columns as the same measurement.
Record settings before interpreting a pattern
| Setting | Record from each source | Why it matters |
|---|---|---|
| Metric and population | Install, re-install, re-attribution, purchase or another explicit event | Different definitions can produce different valid totals. |
| Interaction and lookback | Click/view type and actual configured window | Eligibility for credit can differ. |
| Calendar timezone | Named timezone or offset, including applicable daylight-saving rules | One timestamp can belong to different dates. |
| Freshness | Export time, update cadence and recent-date completeness | Snapshots may cover different available evidence. |
| Filters and coverage | Campaigns, sources, countries, operating systems and missing dates | Scope and absent rows must remain visible. |
Obtain these values from the account or provider documentation. Do not infer them from a chart or assume the default window still applies to an existing account.
Illustrative example: one timestamp, two calendar dates
The synthetic timestamp 2026-10-01T00:30:00Z is October 1 in UTC. At a fixed UTC−07:00 offset, it is 17:30 on 2026-09-30. This demonstrates a calendar-date distinction; it does not identify which timezone either of your exports used. A named region can change offset during daylight saving.
Select the same reporting timezone when exporting. If that is unavailable, use event-level timestamps and a justified rebucketing method outside this aggregate comparison. Moving a complete daily total by one day does not reconstruct the events that crossed midnight.
Illustrative example: lookback eligibility
Suppose an eligible click occurs on October 1 at 12:00 UTC and an install on October 3 at 12:00 UTC. The gap is 48 hours. Under a simplified hypothetical rule, that click falls beyond a one-day window and within a seven-day window. Other attribution rules, interactions and event definitions can still change the result. These are example settings, not a recommendation or a statement about your account.
Run a defensible comparison
- Save original files and record their settings separately.
- Align the metric, population, units and intended reporting dates.
- In Parity Reconciler, map each file’s date, metric and shared dimensions.
- Keep absent rows distinct from measured zeros; inspect coverage before percentages.
- Export the comparison and known assumptions. Label explanations as unconfirmed until verified at the source.
A candidate day shift, segment concentration or recurring multiplier is an investigation prompt. It does not prove a timezone, attribution-window, currency or provider error. See the broader MMP discrepancy workflow for the complete comparison process.
Check current provider guidance
Sources reviewed October 26, 2026: AppsFlyer’s lookback-window documentation and freshness and timezone documentation. Settings and report support vary; verify the current options before applying them to your own exports.
Use Preflight for launch-sheet checks. After reconciling reporting scope, Daily UA Report can summarize the supplied daily data.