A window change can make an app campaign’s reported acquisition cost look better before the business has acquired one additional customer. It can also exclude a purchase that the product team considers entirely normal. Both problems start when a day count is discussed without specifying what starts the clock.
Choose a Google App campaign conversion window by identifying the conversion action, its starting event, the business outcome it counts and the campaigns that use it. Check observed conversion delays and reporting limitations before choosing a duration. Preserve the old settings and separate the measurement change from any claim that acquisition improved. There is no single best window for every app.
This guide is for teams deciding whether to change an active window, not for selecting the campaign’s overall optimization goal. If that decision is still open, start with the Google App campaign goals framework. The examples below concern Android app acquisition; they do not prescribe Apple measurement settings.
Which clock does the conversion window start?
Google’s App campaign window definitions distinguish interaction-to-install windows from a post-install window for subsequent in-app actions. A day count without that distinction is incomplete.
Boundary Starting event Outcome being considered What to record --- --- --- --- Click-through install Eligible ad click App install Click window and conversion source Engaged-view install Qualifying video engagement App install Format, engagement requirement and window View-through install Eligible ad view App install View eligibility and applicable window Post-install action App installation Subsequent in-app action Action definition and post-install duration
The same Google page describes the post-install window as applying to install campaigns. Do not apply that clock indiscriminately to engagement campaigns. Its app-install view-through section specifies one day; that statement is not evidence that every Google conversion source has identical controls.
Engaged view also needs a format definition. Google’s engaged-view documentation describes different qualifying behavior for skippable in-stream, in-feed and Shorts ads. It lists different app defaults for install and engagement campaigns. A general web-conversion default is therefore a poor substitute for the actual app action’s settings.
The practical requirement is simple: ask for the setting’s name, its current value and its documented scope together. A screenshot reading “seven days” cannot establish whether the team is discussing acquisition credit, post-install behavior or a separate analytics report.
A post-install window is not a reporting calendar
Suppose an eligible ad interaction precedes installation by several days, and a purchase occurs several days after installation. These are two intervals. A team evaluating the purchase needs to understand the installation’s acquisition eligibility and the subsequent action’s eligibility separately.
Do not subtract the interaction-to-install delay from an install-started interval merely because both events belong to one customer journey. Equally, do not conclude that every report now assigns revenue to installation date. Window eligibility and the date used to group a report are separate questions.
For each material export, write down whether rows are grouped by an interaction date, a conversion date or a cohort entry date. Google’s app-conversion comparison guidance distinguishes All conversions from All conversions by conversion time and recommends checking conversion settings before comparing actions.
A finance report can legitimately group realized revenue by transaction date while a UA report groups acquisition cohorts differently. The error is presenting them as the same observation. Keep the equal-maturity cohort analysis available alongside the platform report so the business can follow outcomes without treating attribution as its revenue ledger.
Inventory every campaign that consumes the action
The place where a setting is edited does not establish the limit of its impact. Google’s create-and-adjust instructions state that conversion actions can extend across campaigns. They direct window edits through the conversion action’s settings and describe selecting existing actions for campaigns.
Before saving a change, build a small dependency register. Use stable identifiers wherever the export provides them; display names alone are fragile.
Register field Question it must answer --- --- App, account and action identity Which measurement object is changing? Source and event definition What produces the action, and what qualifies? Starting event and duration Which interval will the new setting govern? Campaign consumers Which active campaigns use or report this action? Optimization use Where does it inform a bidding decision? Reporting consumers Which dashboards, agency reports and budget rules depend on it? Change owner and effective time Who can explain and verify the intervention later?
An acquisition team and a re-engagement team might share reporting dependencies even when their campaign jobs differ. A contracted reporting calculation may also depend on the existing definition. Resolve these dependencies before treating the change as an isolated media adjustment.
If the register exposes two actions measuring the same milestone, do not delete one as part of a window experiment. Follow a separate duplicate app-conversion diagnosis. Changing identity, counting rules and windows together makes the result harder to interpret and expands the intervention unnecessarily.
Use conversion delays without mistaking a cutoff for the whole journey
Google recommends its Days to conversions segmentation as an input to App campaign window selection. Its window-optimization guidance also describes the tradeoff: longer windows can include more conversions, including less incremental organic activity; shorter windows can miss incremental conversions.
Those statements do not tell you the right duration for your product. Start with the commercial endpoint. Is the campaign trying to identify a meaningful activation, a completed purchase or another validated action? Ask why its timing matters to the acquisition decision rather than choosing a duration because another account uses it.
Then inspect data maturity. A cohort acquired yesterday cannot reveal its complete later behavior. Separate cohorts old enough to observe the proposed interval from those still accumulating outcomes. Mark recent cells as incomplete rather than interpreting missing later events as zero demand.
There is a second limitation: a report may only contain outcomes eligible under its current measurement boundary. Google’s general conversion-window guidance explicitly warns that a short window also caps the time-lag information described there. Its attribution time-lag report has a stated network scope. Do not silently substitute that report for complete App campaign journey evidence.
This is a censored-data problem. If a report stops observing the relevant outcomes after a cutoff, the absence of later rows cannot prove that no later outcomes exist. Use an appropriately authorized product or revenue cohort to investigate later behavior, keeping its population and event definitions visible.
For example, a product cohort may show that meaningful purchases continue after the current advertising interval. That is a reason to investigate the interval’s fitness. It is not proof that Google Ads caused those later purchases or that every one would become attributable after an edit.
Decide what the window is supposed to accomplish
A useful recommendation explains the tradeoff it accepts. Consider three legitimate priorities.
A prompt operational signal. The team needs evidence quickly enough to make a near-term acquisition decision. An earlier endpoint may be useful if it has an established relationship to business value. A shorter reporting interval alone does not validate that relationship. If the event is a weak proxy, shrinking the clock will not improve its meaning.
Coverage of the product’s buying journey. The team has credible evidence that the selected outcome often takes longer. A longer eligible interval may fit the question better, but makes recent evaluation less settled and may change the amount of attributed activity. Keep the business payback requirement explicit rather than treating a longer attribution window as additional cash runway.
A defined promotion or operating period. The team needs a result with a stated time boundary. Record whether that boundary describes campaign eligibility, the customer offer or finance’s evaluation horizon. These may be different dates and should not be forced into one control.
If no one can explain the intended decision, retain the existing setting while repairing the brief. “More conversions in the dashboard” is not a sufficient business objective. Nor is “less disagreement with the MMP” when disagreement arises from different populations, methods or event definitions.
Google Analytics and the MMP need their own ownership checks
Google’s Analytics conversion-management guidance notes that some settings may be managed differently according to the attribution channel setting and that certain imported settings may not be editable in Google Ads. Availability also depends on the property’s supported experience.
Record where the actual conversion’s setting is controlled before assigning an implementation task. A missing edit field does not establish that the action is broken. Equally, an editable field in one product does not prove that all downstream reports have changed with it.
For an MMP, inspect the specific provider and integration documentation. Record the partner-side windows and event definitions separately from the Google Ads conversion action. Seek an explanation for each mismatch. Matching a numeric duration can remove one source of disagreement without making the two reporting systems interchangeable.
The broader click-through, view-through and engaged-view comparison is useful when the dispute concerns credit categories. Keep that investigation separate from the narrower question here: which interval should this action use for this acquisition decision?
No SDK replacement, event recreation or account relinking should be an automatic consequence of a window discussion. First establish the actual ownership boundary and the evidence that the existing configuration cannot serve the agreed job.
Does changing the window rewrite historical conversions?
Do not promise historical recovery. Google’s general window-change example says changes apply to conversions going forward. Its example includes an earlier interaction whose subsequent eligibility changes and an already excluded conversion that is not retroactively counted after another extension.
The distinction matters: “only new clicks are affected” is not a safe paraphrase of that example. “All historical conversions will return” is not supported either. Preserve the actual effective time and seek source-specific clarification when the account’s transition cannot be established from its settings and documentation.
A later export can also differ because observations are still arriving. Google’s conversion-lag reporting documentation lists install and engagement App campaigns as eligible and describes forecasts of how CPA or ROAS may change as conversions mature. A forecast remains a forecast; distinguish it from realized results.
Retain dated exports before the edit and after the agreed observation period. Label them with both extraction time and measurement version. A comparison that silently replaces the earlier export loses the ability to explain whether a change came from a new definition, normal maturation or another intervention.
A fictional sensitivity calculation: lower CPA without more customers
Consider an original, deliberately simplified example. Assume an analyst has a separate, authorized dataset of the same acquisition cohort, a reliable action definition and enough maturity to inspect two hypothetical eligibility cutoffs. This is not a claim that Google Ads offers a complete retrospective window simulation.
The cohort cost is $12,000. The shorter hypothetical interval contains 240 eligible purchases. An additional 60 purchases fall within the longer interval, for 300 in total. For this arithmetic only, the two sets are nested and have no duplicate purchases.
Shorter-interval cost per eligible purchase: $12,000 ÷ 240 = $50.
Longer-interval cost per eligible purchase: $12,000 ÷ 300 = $40.
Difference in the reported ratio: $10, or 20% of the shorter-interval figure.
No extra purchase occurred because the analyst changed a cutoff. The same underlying cohort is being described through two eligibility rules. The calculation measures sensitivity of a denominator; it does not measure an acquisition improvement, incremental customers or additional profit.
A live change could subsequently affect the information available to bidding. That would be a separate intervention requiring its own observation and evaluation. Do not use this report-only arithmetic as a forecast of that intervention.
The example also depends on facts many aggregate exports cannot establish: shared population, compatible endpoints, sufficient maturity and nonduplicated actions. If those are unavailable, present the totals separately and name the missing evidence. Do not invent the overlap or infer the number of lost customers from subtraction.
Validate a change in stages
Before implementation, write one sentence explaining the proposed interval and the decision it should support. Retain the dependency register, baseline settings, dated reports and the reason for the duration. Specify who can approve the actual account change; editorial guidance is not account authorization.
Keep unrelated bidding targets, event identities and value definitions stable where practical. If another change is unavoidable, record it rather than pretending that the test isolates one variable. Include app releases, pricing changes and promotions in the same timeline.
After the edit, check acceptance at four levels:
Configuration: the intended action shows the approved setting; capture the effective time and verify its consumers.
Data continuity: the intended event continues arriving with the expected identity, count and value meaning. Investigate a broken feed separately.
Reporting comparability: dashboards identify the measurement version and distinguish incomplete periods, forecasts and realized observations.
Business interpretation: acquisition decisions still refer to retained or paying cohorts and the agreed economic horizon, with limitations stated.
A configuration screenshot passes only the first level. A lower platform CPA does not pass the fourth by itself. A disappearance of reporting disagreement is also insufficient if both reports now share an incorrect definition.
Set the observation period from the action’s timing and collection constraints, not a universal number of days. If an exception requires support, send a bounded packet: action and campaign identifiers, redacted before-and-after settings, exact timestamps, expected behavior and the smallest export showing the unresolved difference. Exclude customer-level data and credentials from a routine agency brief.
Bring the window decision to a scoped growth review
If your team runs Google App campaigns and cannot defend a proposed window change, bring the disputed budget decision, redacted conversion-action settings, campaign dependencies and available delay reports to a Sharply Labs mobile app growth conversation.
The initial conversation can identify the evidence gaps, responsible owners and next validation questions. A detailed audit, engineering work and any account implementation are separately scoped through our growth services. This is not a promise of complete attribution, historical recovery, lower CPA, higher ROAS or a particular campaign outcome.
Contact Sharply Labs with the decision that is blocked and the measurement boundary you need to resolve. A useful next step starts with an explicit clock and a testable question.