A paid re-engagement campaign should not begin with a media budget. It should begin with a written decision about who is eligible, who must be excluded, why the remaining people have a credible reason to return, where the click should land, and what evidence would show that advertising changed behavior.
That decision is the audience contract. It prevents a dormant-user campaign from becoming “everyone we can upload,” protects active customers from irrelevant ads, and makes the eventual measurement question answerable. It also exposes a basic constraint: an installed base is not the same thing as a targetable, behavior-defined, sufficiently large audience.
Google currently documents specific prerequisites for its own App campaigns for engagement: at least 50,000 installs, an app-user audience list, deep links, mobile conversion tracking through Firebase or a supported App Attribution Partner, and a privacy policy that sufficiently discloses re-engagement use (Google Ads Help). Those are Google product requirements, not universal thresholds for paid re-engagement. Apple Ads uses a different construct: its Returning users setting is App Store reacquisition targeting for people who previously downloaded the app, not a custom segment of users who became dormant after a defined behavior (Apple Ads Help). Treating those products as interchangeable produces a plan that is wrong before the first impression.
The audience contract: seven fields that must agree
A useful audience contract fits on one page. It gives growth, lifecycle, analytics, product, engineering, and privacy teams the same operational definition.
Contract field The question it must answer Example specification --- --- --- Eligibility What observable state creates candidacy? Completed onboarding and performed the core action at least twice Exclusions Who must never enter or must leave immediately? Active in last 14 days, current subscriber, refunded user, employee, unresolved consent state Recency When does eligibility start and expire? No qualified session for 30–90 days; remove after day 90 Message What state-specific reason justifies the interruption? New inventory in the category previously saved, not a generic “come back” Destination Which authenticated in-app state should open? Saved-category results; preserve destination through login Event What first-party action represents a meaningful return? Qualified session plus saved-item view, not app open alone Measurement What comparison changes the media decision? Treatment-assigned versus randomized holdout on qualified return and 30-day contribution
Every field constrains the others. If eligibility says “lapsed payer” but the message promotes first-purchase onboarding, the contract is incoherent. If the destination is a generic home screen, the promised reason to return disappears after the tap. If measurement counts an app open while the business question concerns renewed payment, the campaign can look successful without resolving the commercial question.
The contract should also name an owner and a version date. Audience logic changes as events, consent rules, products, and platform capabilities change. A segment named dormantusersfinalv4 is not governance. A dated specification with owners, source events, windows, exclusions, and tests is.
Write eligibility as a decision rule, not a label
“Dormant users” is a label. A decision rule is testable:
Eligible = known app user AND onboarding complete AND last qualified session between 30 and 90 days ago AND at least two historical core actions AND consent state permits the intended advertising use AND reachable identifier is available MINUS active users, current subscribers, recent purchasers, support-risk accounts, employees, test devices, and every concurrent campaign audience that would create conflicting treatment.
In set notation:
E = (Known ∩ Onboarded ∩ HistoricallyQualified ∩ Dormant30–90 ∩ ConsentOK ∩ Reachable) − (Active14 ∪ CurrentPayer ∪ RecentBuyer ∪ Suppression ∪ ConflictingCampaign)
This is not mathematical decoration. It forces the team to define the source of every term. “Last qualified session” might come from the product warehouse, while “reachable” may depend on an advertising identifier, linked analytics audience, or platform-defined customer type. Their refresh schedules and populations will differ.
A person can satisfy the product definition today and remain absent from the activation platform because consent is unavailable, the identifier was reset, the device changed, the audience has not synchronized, or the platform does not accept that segment type. Conversely, a platform list may still contain someone who returned organically after the last export. Eligibility therefore needs both an event-time rule and a freshness rule.
Lifecycle states need different decisions
The following matrix is a planning tool, not a universal recommendation. Each app must replace the examples with its own value event, economics, consent basis, and product risks.
Lifecycle state Default paid decision Required evidence before inclusion Typical exclusions or safeguards Suitable destination --- --- --- --- --- Active Exclude None; they are already doing the desired behavior Recent session or core action Not applicable Newly converted Exclude or hold A separate, justified cross-sell job Conversion cooling-off window; current campaign exposure Relevant post-purchase utility only Incomplete onboarding Repair first; test only if the blocker is understood Stable step event and a specific recoverable next action Users blocked by defects, eligibility, or policy Exact unfinished step with state preserved At-risk Usually hold Evidence that owned lifecycle messaging is insufficient and paid contact is proportionate Recent high-value action; notification/email responders Personalized value moment, not the home screen Dormant Candidate Behavior-defined inactivity window, historical value signal, sufficient reachable volume Active users, payers, recent organic returners The product state that supplies a reason to return Lapsed payer Separate test Clear lapse event, allowed use, and an offer consistent with policy and margin Current subscribers, refunds, disputes, support cases Account or renewal path with terms visible Uninstalled or unknown Do not describe as ordinary in-app retargeting Platform-specific reacquisition eligibility and destination behavior Users whose current install state cannot be established Store or supported reacquisition path
Two mistakes are common. First, active users are left in because they are easy to match; the campaign then claims actions they were likely to take anyway. Second, several lifecycle states are merged to obtain scale. An incomplete-onboarding user and a lapsed payer do not share a reason to return, a message, a destination, or a success event. Combining them creates volume by destroying interpretability.
Platform eligibility is not product eligibility
The product team knows whether a user completed onboarding, saved an item, paid, or became inactive. The advertising platform decides whether a corresponding audience can be activated under its product rules. Keep those layers separate.
For Google App campaigns for engagement, an app-user list and deep link are explicit requirements, alongside conversion tracking and the documented install threshold (Google Ads Help). Google also documents ways to create app-user segments using action windows and exclusions. Its current audience guidance says lists can take roughly 24–72 hours to populate after creation or synchronization, and only active users with ad personalization enabled count toward targeting minimums (Google Ads Help). Those statements describe Google’s system. They do not prove how many of your product-defined dormant users will become reachable, or whether reaching them will be incremental.
Google’s audience-management guidance notes that an audience may be smaller than expected because people uninstalled the app, changed devices, or because targeting narrowed the segment (Google Ads Help). That is why the contract needs a reconciliation from warehouse eligibility to exported records to platform-ready audience, rather than one headline audience count.
Google separately allows eligible audience exclusions at campaign level, not account level, and currently lists Google Play, Firebase or App Attribution Partner rule-based segments, device ID and contact-info Customer Match lists, and Google Analytics audiences among eligible exclusion sources (Google Ads Help). A global suppression assumption is unsafe when the actual control is campaign-specific.
Apple Ads defines Returning users as customers who previously downloaded the app. They may have deleted it, have it on another device, or currently have it on a device. Apple also says ads with specified audience criteria require more than 5,000 customers to run. Its New users setting can still produce some redownloads, including because prior-download information is unavailable in certain cases or a very recent download has not yet been identified (Apple Ads Help). This is App Store reacquisition logic. It does not implement your warehouse rule for “no qualified session for 30–90 days,” and it should not be reported as if it did.
Freshness, consent, and identifier loss change the real denominator
The correct denominator is not total installs. Track at least six counts:
Product-eligible: users who satisfy the lifecycle and recency rule in first-party data.
Policy-eligible: product-eligible users whose consent and permitted-use state allow activation.
Exported: policy-eligible records successfully sent to the destination.
Platform-ready: records the platform accepts into a usable audience after matching and product rules.
Assigned: platform-ready users randomized into treatment and holdout before delivery.
Exposed: treatment-assigned users who actually receive an impression during the test.
The gaps are diagnostic. A large product-to-policy loss may be expected and correct. A sudden export loss may indicate a pipeline failure. A stable export with a falling platform-ready count may reflect matchability, identifier changes, delayed synchronization, or eligibility rules. None of those gaps should be “solved” by weakening consent or silently widening the lifecycle definition.
GA4 supports audiences built from dimensions, metrics, and events, including inclusion and exclusion logic. Google says audience membership is reevaluated as new data arrives and users are removed when they no longer meet the criteria. Export to Google Ads depends on linking and personalized-advertising settings; corresponding Ads lists can be prepopulated with up to 30 days of data when available (Google Analytics Help). That does not make an audience instantaneous. Record the event latency, warehouse refresh, audience evaluation, export, and platform population times separately.
Consent is not a one-time checkbox copied forever. The audience job needs a current permitted-use signal, a deletion path, and a defined response when consent state is missing or contradictory. Identifier loss is also not fraud or a data-quality defect by default. Device changes, resets, privacy controls, and account-linking gaps can make a real user unreachable. Report “not reachable under this activation path,” not “not a real user.”
Validate the audience in seven steps
1. Name one business state and one paid job
Choose one state, such as “historically activated, no qualified session for 30–90 days.” State why paid media, rather than product repair or owned messaging, might change it. If the only reason is that a platform offers retargeting, stop.
2. Freeze the contract before building the list
Write the seven fields, owners, source events, time zone, refresh expectation, and expiration. Have lifecycle, analytics, product, engineering, and privacy owners challenge it. Resolve whether “purchase” means order created, paid, fulfilled, or not refunded; those definitions produce different exclusions.
3. Reconcile lifecycle counts
Start with mutually exclusive first-party states. Every known user should land in one state or an explicit unknown bucket. Compare daily transitions. If dormant users jump because an event stopped arriving, repair measurement before buying media.
4. Test inclusion, exclusion, and freshness
Use synthetic or authorized test records where policy permits. Verify a qualifying event adds a record, a suppressing event removes it, and membership expires on schedule. Measure end-to-end delay. GA4’s own documentation distinguishes static from dynamic evaluation and explains that membership changes as data arrives; your QA must test the behavior actually configured (Google Analytics Help).
5. Verify the message-to-destination contract
Test installed and absent-app states, logged-in and logged-out states, cold and warm starts, supported operating systems, and expired sessions. The broader paid-ad deep-link QA guide owns the routing mechanics. For this audience decision, the narrower question is whether every eligible state receives a coherent message and reaches the promised value moment.
6. Establish the counterfactual
Randomly withhold a defensible portion of the activation-ready audience where feasible. Keep eligibility, time window, and outcome definitions identical. An attributed reactivation is a user credited under a platform rule. An incremental reactivation is an outcome above what a comparable untreated group would have produced. Only the second answers whether media changed behavior.
If a holdout is not feasible because the cohort is too small or platform controls do not permit a clean design, say so before launch. A directional test may still teach the team about deliverability, destination integrity, and post-return quality, but it cannot support a confident lift claim.
7. Set the decision rule in advance
Choose the observation window and downstream event before seeing results. Define four actions:
Stop: consent, policy, eligibility, or user-harm risk makes the audience inappropriate.
Hold: volume or counterfactual power is too weak for a paid conclusion.
Repair: audience logic, event delivery, exclusions, or deep links fail QA.
Test: the contract passes, reachable volume is meaningful, and the comparison can answer a business question.
Do not replace these gates with a platform-reported CPA threshold after launch.
Fictional example: 120,000 installs are not 120,000 prospects
The following numbers are invented solely to demonstrate reconciliation. They are not benchmarks, forecasts, or Sharply Labs client results.
A subscription app records 120,000 lifetime installs. Its proposed audience is users who completed onboarding, performed the core action at least twice, have no qualified session in the last 30 days, were last active no more than 90 days ago, and are not current subscribers.
For this fictional example, the exclusions are applied sequentially in the order shown, so each person is removed only once. First-party state assignment yields:
120,000 lifetime installs
minus 31,000 users who never completed onboarding
minus 22,000 who lack two historical core actions
minus 18,000 active in the last 30 days
minus 9,000 whose last activity was more than 90 days ago
minus 7,000 current subscribers
minus 3,000 in other suppression states
equals 30,000 product-eligible users
Current consent and permitted-use checks retain 24,000. The export job successfully sends 23,400. The platform reports 15,600 ready for activation after matching and its own rules. The team randomly assigns 3,120 users, or 20%, to a holdout and the remaining 12,480 to treatment. Assignment, not actual ad exposure, defines the comparison.
During the fixed observation window, 12% of the treatment-assigned group completes the qualified return event, versus 10% of the holdout. The raw treatment count is 1,498 after rounding, but the estimated incremental difference is 2 percentage points across 12,480 treated users, or about 250 incremental qualified returns. Calling all 1,498 “caused by ads” would confuse attribution with incrementality.
Suppose only 90 of those estimated incremental returners complete the downstream paid event within the agreed window, producing $5,400 in contribution before media. If media cost $7,000, this fictional test does not clear its stated economic gate. A platform dashboard could still display an attractive attributed reactivation cost because it credits many users who would have returned without ads. The contract prevents that reporting result from overruling the counterfactual.
The example also reveals where operational work belongs. The drop from 30,000 product-eligible to 24,000 policy-eligible is a privacy constraint, not media underdelivery. The drop from 23,400 exported to 15,600 platform-ready needs investigation but not automatic accusation; identifier loss, audience rules, and synchronization can all contribute. Each denominator has a different owner.
Control overlap before interpreting performance
Paid re-engagement can overlap with acquisition campaigns, CRM messages, promotions, and organic return behavior. Suppress recent actives and current payers from the re-engagement campaign. Where supported and appropriate, exclude existing users from acquisition at the campaign level rather than assuming an account-wide rule. Google explicitly documents campaign-level audience exclusions for eligible App campaigns (Google Ads Help).
Also record concurrent email, push, in-product messaging, and major product releases. A holdout that receives different owned-channel treatment is not a clean counterfactual. If lifecycle marketing sends a win-back offer to everyone on day three, either coordinate assignment or treat the test as a combined intervention.
Frequency deserves its own guardrail. A small dormant list can be exhausted quickly, and repeated exposure may create annoyance without increasing qualified returns. Define a monitoring rule tied to reachable audience size and post-return quality, not merely clicks.
When not to buy paid re-engagement
Do not fund the campaign yet when:
the dormant cohort is a label rather than a reproducible behavior-and-recency rule;
lifecycle states overlap or the qualifying event is unstable;
owned channels have not been used appropriately against the same recoverable state;
there is no state-specific reason to return;
active users, subscribers, purchasers, or unresolved consent states cannot be suppressed;
the reachable audience is below the chosen platform’s eligibility threshold or too small for a readable test;
deep links lose the promised destination or login destroys context;
an app open is the only observable outcome;
the team cannot distinguish platform attribution from a counterfactual;
retention or activation is so weak that reacquisition only returns people to the same unresolved failure.
The allocation question remains separate. The install-versus-re-engagement guide decides which campaign job deserves the next dollar. The user-acquisition-versus-retention framework addresses the broader marginal investment choice. This page begins only after paid re-engagement is a plausible job and asks whether there is a defensible audience to buy.
Limits that belong in the decision memo
Audience overlap can make multiple campaigns claim the same user. Privacy choices and identifier loss reduce reach unevenly. Small segments create noisy comparisons and may fail platform minimums. Export and membership delays mean campaign delivery can operate on stale state. A working deep link can still fail after authentication or app version changes. Platform eligibility can differ by account, market, audience source, and product.
Lifetime value adds another uncertainty. A returned payer may have high historical value but little remaining incremental value; a low-value historical user may return for a newly relevant feature. Historical value is a prioritization input, not proof of future contribution.
The largest limitation is counterfactual uncertainty. Even a randomized holdout can be contaminated by cross-device exposure, owned channels, household effects, or product changes. Report those limits. Do not convert a directional estimate into a universal promise.
Official vendor documentation is useful for understanding requirements and controls. It is not independent evidence that a platform will create lift for a particular app. Google’s 50,000-install requirement belongs to Google App campaigns for engagement. Apple’s Returning users control belongs to Apple Ads reacquisition. GA4 audience behavior belongs to the configured Analytics and Ads connection. The audience contract must preserve those boundaries.
What a decision-ready handoff contains
Before media approval, the team should be able to hand a reviewer:
the dated audience contract and owner;
executable eligibility and exclusion logic;
counts for product-eligible, policy-eligible, exported, platform-ready, treatment-assigned, and exposed users;
freshness and deletion expectations;
consent and permitted-use review;
message and deep-link test evidence;
overlap and frequency controls;
treatment and holdout assignment;
primary outcome, downstream value event, window, and decision threshold;
known limitations and the stop, hold, repair, or test recommendation.
If any item is missing, the gap is part of the decision—not an implementation detail to discover after spend begins.
Get the audience and measurement decision reviewed
For app teams with a meaningful dormant cohort, Sharply Labs offers a bounded audience-and-measurement QA conversation. We examine lifecycle event definitions, eligibility and exclusions, audience overlap, data freshness, deep-link destination, and whether a credible holdout is feasible. You receive a prioritized audience contract and test plan showing what to repair, what to validate, and what evidence should govern the media decision.
This is not a promise of paid retargeting eligibility, lift, lower CPA, or any performance outcome. It is a scoped decision and QA deliverable.
See how we support app growth teams and our broader growth services.