By Sharply Labs Editorial Team
The direct answer: choose the growth job, not a universal winner
Use In-App Events for a qualifying, time-bound experience that deserves discovery or renewed attention. Use Custom Product Pages (CPPs) for a product-page narrative matched to a particular audience, campaign, or search context. Use both when a genuine event needs discovery and incoming campaign traffic needs a relevant store destination. Neither is a substitute for a working app experience or a measurement plan.
Apple describes In-App Events as timely moments within apps and games, discoverable through event cards and details pages. They can reach new, current, and previous users. CPPs are additional versions of a product page with distinct assets and unique URLs; current rules also allow keyword-based search visibility. Those are different customer jobs, even when the same seasonal theme appears in both (Apple In-App Events; Apple CPP configuration).
The buyer decision is therefore not “which feature converts better?” It is “what must this audience understand or do next?” An existing user may need a reason to return to an event. A new visitor may need to see why the app fits a particular use case before downloading. One surface announces a moment; the other explains the relevant product promise.
For teams evaluating the whole journey, the primary commercial context is our evidence-first mobile app growth service. This guide stays narrower: event discovery versus audience-specific store destinations, their sequencing, and their measurement. It does not prescribe a complete user-acquisition program.
Comparison matrix: what each surface is responsible for
Choose by the missing job in the journey. Shared imagery does not make the surfaces interchangeable, and a page-level result does not prove the event caused it.
Decision dimension In-App Events Custom Product Pages --- --- --- Buyer job Explain a real, time-bound in-app moment and make participation discoverable Explain a feature or content proposition relevant to a routed audience Eligibility A qualifying challenge, competition, special content launch, or other supported event; not generic promotion An eligible app and approved page; confirm current account and distribution state Discoverability Product page, search, and potential curated or personalized placements Unique links, approved keyword assignment in search, and potential editorial inclusion Timing Scheduled start/end and promotion window Persistent page URL until changed, disabled, or deleted; campaign relevance still needs maintenance Audience New, active, and lapsed users; purpose informs recommendations, not exclusive access Visitors arriving through a specific link, relevant assigned keywords, or supported ad use Routing Event details link for promotion; event Open action deep-links to event content Unique page URL and optional supported Open-action deep link Assets and metadata Event badge, name, short/long descriptions, card/detail media, availability and purpose Screenshots, previews, promotional text, keywords, and localizations Deep links Event content or suitable pre-event/onboarding destination Specific in-app destination on iOS/iPadOS 18 or later Apple Ads role Event promotion does not establish a CPP-style search-results ad variation capability Search-results custom ads use CPP creative and land on that page Review Event submission can be independent of a new app version Page metadata and deep link need approval; updates can be independent of an app update Measurement Event impressions, detail views, opens, notification interest, and downloads Page impressions, downloads/redownloads, conversion and available downstream dimensions Main failure mode Generic promotion dressed as an event, or an event path that does not work Relevant-looking assets sent to the wrong audience, stale content, or confounded comparisons
Platform rows above summarize Apple's event guidance, CPP configuration, CPP overview, and search-results ad variations. Buyer jobs and failure modes are this article's decision framework, not Apple performance claims.
What qualifies as an event rather than a promotion?
A limited-time experience must exist inside the app. Apple lists challenges, competitions, and special content launches as good candidates. Repetitive daily tasks or rewards, price promotions without new content/features/goods, and general app-awareness promotions are not good candidates. Permanent content can be introduced through an event, but the event itself should focus on a related limited-time moment (Apple event candidate rules).
Write the experience before the headline. What happens, when does it happen, and what would a participant actually encounter? If the answer is only “our subscription is discounted” or “our app has useful features,” stop the event brief. A campaign deadline does not transform an evergreen sales message into an eligible event.
Apple currently permits up to 15 approved events in App Store Connect and up to 10 published simultaneously. An event can last up to 31 days and be promoted up to 14 days before its start. These are platform limits, not a recommended content cadence or a promise of visibility (Apple event configuration and timing).
Are CPPs only destinations for paid links?
No: current CPP discovery includes more than paid routing. Apple permits up to 70 pages per app, with unique URLs, localizable assets, and approved keyword assignment. Keywords come from the latest approved app version; a page becomes searchable only after approval and visibility are enabled. Without a CPP link or chosen keyword visibility, the default page appears under the documented configuration rules (Apple CPP configuration).
Apple's overview also describes possible editorial stories and collections and paid/owned communication uses. None is guaranteed placement. Do not label every CPP “invisible organically,” but do not plan as if assigning a keyword guarantees a rank or editorial selection (Apple CPP overview).
Treat the page as a maintained message contract. A stable URL is useful only while its promise remains true. A campaign-specific page can survive a campaign, but its content owner must decide whether to refresh, repurpose, or disable it. Disabled or deleted CPP links redirect to the default page under Apple's documented behavior (Apple CPP configuration).
Decision tree: discovery, relevance, both, or repair first?
Start with the unresolved audience problem, then check eligibility and delivery. This decision tree is an operating tool, not a platform recommendation or forecast.
Is there a real, qualifying limited-time in-app experience? If no, do not manufacture an event. Continue to the landing-page question. If yes, record its start/end, participation requirements, and reason for each audience to care.
Is discovery or renewed attention to that moment the missing job? If yes, consider an In-App Event, subject to review, regional availability, working routing, and measurement. If the event already reaches its audience through other means, discovery may not be the immediate bottleneck.
Does a specific audience receive a promise the default product page does not explain well? If yes, consider a CPP with a precise message-to-destination mapping. If no, multiplying pages may add maintenance without resolving a problem.
Are both jobs present? Use separate briefs: an event brief describing the moment and a CPP brief explaining the relevant product proposition. They can share a theme without sharing an evaluation metric.
Can the app deliver the promise and can owners inspect the journey? If no, repair first. Do not let a launch calendar override an unresolved deep link, inaccessible content, missing entitlement path, or absent measurement owner.
The adjacent CPP-versus-PPO decision guide owns personalization/routing versus controlled treatment testing. This article does not recreate that comparison. A CPP audience comparison is not automatically randomized; traffic selection and timing can explain an apparent difference.
The two-ledger measurement framework
Maintain two surface ledgers and a downstream quality check. The point is not to force all reports to match. It is to know which observation supports which decision and where attribution stops.
Ledger one: event exposure and engagement
The event ledger asks whether people encountered the moment and took relevant steps toward participation. Apple describes event impressions, event details page views, app opens, notification interest, downloads filtered by event, and acquisition sources in App Analytics (Apple event measurement).
Record the event reference, region, localization, publication and live windows, purpose, content version, and any owned/paid promotion dates. Beside each available metric, preserve its source definition and reporting period. Distinguish interest before the start from opens while the event is live. A notification request is not participation; an app open is not completion.
The product team should define participation independently: for example, entering the relevant experience or completing its meaningful action. Only report that action if your permitted instrumentation actually measures it. Do not imply that a store dashboard automatically supplies a joined person-level journey from impression to participation.
Use missing data as a limitation, not as a zero. If region filtering, reporting timing, or instrumentation prevents a comparison, state that the event decision remains unresolved. Do not quietly substitute total app downloads for event-specific evidence.
Ledger two: product-page acquisition and conversion
The page ledger asks whether a defined incoming context reaches the intended narrative and what follows. Apple documents CPP impressions, downloads, and conversion reporting after at least five first-time downloads for that page. This is a reporting availability threshold, not enough evidence to declare a winner. Its overview also names redownloads, retention, and average proceeds per paying user as available page evaluation dimensions (Apple CPP configuration; Apple CPP measurement overview).
Record page identifier, asset version, URL, localization, assigned keyword set, campaign/ad-group mapping, launch date, and any assignment changes. Keep new downloads and redownloads conceptually separate. Explain the denominator behind each conversion rate rather than copying a percentage without its reporting definition.
Compare only with an explicit caveat about audience, source, geography, device, timing, and creative differences. A higher reported page conversion rate can be consistent with a more suitable audience rather than a better page. It can also hide a change in what users do after downloading.
Downstream quality: the shared decision check, not a third attribution claim
For each relevant cohort, ask whether the app delivered the promise: activation, participation, retention, or an appropriate monetization action, where legitimately measured. Define the business action before looking at results. Preserve consent, missingness, and reporting limitations; aggregate responsibly rather than assuming access to individual user paths.
Store-page conversion can affect observed downstream acquisition economics through the customer journey: the same traffic may produce a different volume or mix of downloads. That does not establish the page as an auction input, prove that an event reduced auction cost, or isolate a causal CPI/CPA change. Acquisition costs also vary with media conditions and audience composition. Attribution reports allocate observed outcomes; they do not prove incrementality.
Decision Primary evidence What must not be inferred --- --- --- Keep or revise event presentation Event exposure, detail engagement, opens and measured participation context Notifications alone prove participation or incremental returns Keep or revise audience routing Page/source mapping, page acquisition metrics, message continuity Different CPP audiences constitute a randomized test Continue combined use Separate surface evidence plus downstream quality and operational cost One blended conversion rate identifies which surface caused an outcome
Implementation workflow: gates, owners, QA, and stopping conditions
Launch only the surface whose promise, delivery, and evaluation can be checked. The gates below are qualitative readiness requirements, not universal traffic or spend thresholds.
Gate 1: approve two distinct hypotheses
Product marketing owns the buyer problem and audience context. The event hypothesis should explain why a timely experience deserves attention. The page hypothesis should explain why a particular incoming audience needs a different narrative. Write the observation that would cause revision before commissioning assets.
Stop if both briefs say only “increase conversion.” That statement does not distinguish the jobs. Also stop if an event lacks a genuine participation experience or the page has no identifiable incoming context. A useful brief makes disagreement visible before teams commit production effort.
Gate 2: verify eligibility, account access, review, and localization
The store owner checks current configuration availability, app status, regions, localizations, and review workflow in the actual account. Apple's CPP help lists Account Holder, Admin, App Manager, or Marketing as required roles and a Ready for Distribution state in at least one country or region for the documented creation flow. Its overview separately mentions pre-order use; teams planning that state should verify the current account path rather than assume identical controls (Apple CPP configuration; Apple CPP overview).
Both surfaces require review. CPP metadata can be submitted independently of an app update; approved edits replace the existing page upon approval without changing its URL. Events can also be submitted independently of a new version (Apple CPP review behavior; Apple event submission).
Stop if approval is unresolved, a required localization misrepresents the experience, or regional access is uncertain. Approval and potential discovery are separate facts. Do not promise an editorial slot, a review deadline, or universal market availability.
Gate 3: build assets around the promised experience
The creative owner pairs event card and detail media with a precise name and descriptions. Apple limits event names to 30 characters, short descriptions to 50, and long descriptions to 120, and asks for event-specific metadata and licensed content. Review both card and detail crops rather than assuming one composition fits every surface (Apple event metadata guidance).
The CPP owner aligns screenshots, previews, and promotional text with the incoming audience's problem. Use the store-screenshot journey guide for the complementary asset-continuity job, not as evidence for Apple rules. Maintain an asset/version register so a later report can identify what users actually saw.
Stop if content rights are unclear, important information is lost in a crop, or assets describe functionality unavailable to that audience. Seasonal relevance is not permission to misstate the product.
Gate 4: verify deep links and paid routing independently
Engineering owns the in-app destination. Apple recommends universal links for event deep links and says to test the proper destination; before an event starts, a preparatory page may be appropriate, and new users may need onboarding first. A route back to the main experience should remain available (Apple event deep-link guidance).
CPPs are supported on iOS/iPadOS 15 or later, but their optional Open-action deep links require iOS/iPadOS 18 or later and approval. Do not collapse page availability and deep-link support into one version claim (Apple CPP configuration).
The UA owner checks Apple Ads assignments separately. Search-results ad variations use CPP assets and land on that CPP; an ad group can have only one active custom ad. Assignments can change. Apple says a default ad runs where no variation is created and when a custom ad is placed on hold for compatibility issues (Apple Ads ad variations). This is not a claim that an In-App Event supplies the same ad variation.
Test installed and not-installed journeys, signed-in and signed-out states, supported and unsupported OS behavior, region/localization, pre-event/live/ended content, and participation requirements. Preserve the destination through necessary onboarding only if the implemented flow does so; do not assume deferred routing works automatically. Check the default fallback as well as the preferred path. Stop or pause affected routing if users receive a stale promise or cannot reach the advertised content.
The Apple Ads keyword operations guide is complementary to this mapping task. It does not replace account-level verification of CPP keyword assignment or paid ad selection.
Gate 5: agree reporting and rollback ownership
Measurement owns the two ledgers; product owns downstream definitions; UA owns campaign history; the store owner owns page/event status. Agree who can pause routing, revise assets, and communicate a limitation. Record review dates, reporting delays where observed, and the next decision meeting rather than inventing a fixed evaluation window.
Stop expansion when reporting is unavailable, changed assignments cannot be reconstructed, or a surface-level result conflicts with downstream quality and no explanation is established. Missing evidence is a reason to narrow the decision, not to declare success from whichever dashboard looks favorable.
Combined-use example — fictional, not a Sharply Labs client result
Both tools can support one theme while answering different questions. Imagine a fictional language-learning app launching a limited-time live conversation challenge. The experience has scheduled sessions and genuinely new event content; product and store owners still need to confirm its eligibility and review outcome.
An In-App Event describes the challenge, participation conditions, and dates. Its purpose is discovery and renewed attention, including previous users who may want to return. A CPP for a particular language-learning audience explains the app's conversation feature with relevant screenshots. Campaign links and a supported Apple Ads variation route that context to the appropriate page.
The event ledger records available event exposure, detail engagement, notification interest, opens, and measured challenge participation. The page ledger records its incoming contexts, approved asset version, acquisition metrics, and available downstream quality. The team does not add both ledgers together as if they described independent people or perfectly joined journeys.
If event attention exists but users cannot enter the challenge, engineering repairs delivery before increasing promotion. If the CPP attracts downloads without the intended activation, product marketing revisits the promise and product checks the experience. If the event ends while the page remains linked, the owner removes the expired promise or pauses that routing. No performance numbers, causal conclusions, or Sharply Labs experience are implied by this fictional example.
When neither is ready
Repair the underlying promise or journey before producing another store surface. Neither tool is ready when an app cannot deliver the highlighted experience, cannot distinguish its intended audience, lacks approved/accurate assets, or has no owner capable of interpreting the available evidence.
A generic discount is not enough to justify an event. An undifferentiated audience is not enough to justify a CPP. A broken onboarding handoff is not fixed by a deep-link field. If the actual decision is new-user acquisition versus returning-user activity, use the complementary install-versus-re-engagement campaign framework; this guide does not assume every lapsed user should receive the same campaign or event.
Keep the default page honest and the app usable while readiness improves. A smaller, inspectable launch is preferable to a larger collection of assets whose routing and reporting cannot be explained. That is an operating judgment, not a guarantee of better economics.
Limitations and the next decision
These mechanics support implementation decisions, not forecasts. The four official sources were accessed on October 20, 2026. Rules can change; OS support, app status, region, review, visibility, and account availability must be checked before execution. Potential search or editorial discovery is not guaranteed reach or ranking. Apple's promotional conversion statistics and developer performance stories are deliberately not used because their methodology and applicability are not established here.
Search Console, qualified-conversion evidence, Semrush, and Ahrefs are unavailable for this run. There is no claim about keyword volume, difficulty, CPC, market share, existing ranking, or commercial performance. Any Lovable analytics observation would be directional rather than qualified-conversion or causal evidence. This framework is not an incrementality experiment and does not promise CPI, CPA, ROAS, or revenue change.
For live-app founders, growth leaders, UA leads, and product marketers with a specific event or audience-routing decision, review Sharply Labs growth support and request a scoped audit through the mobile app growth service linked above. Sharply Labs will examine store assets, paid routing, deep links, and the event/page measurement handoff. You receive a prioritized readiness and routing decision agenda, with evidence gaps, owners, and recommended next checks; access and deeper analysis are agreed separately. No ranking, conversion, CPI, CPA, ROAS, or revenue outcome is promised.
Sources and evidence scope
Apple Developer — In-App Events: event eligibility, surfaces, timing, purpose, metadata, deep links, review and App Analytics. Accessed October 20, 2026. Potential visibility is not guaranteed distribution or performance.
Apple Developer — Configure multiple product page versions: current page limits, roles, assets, keywords, review, URLs, OS/deep-link support and reporting threshold. Accessed October 20, 2026. Confirm account/app state; reporting availability is not statistical sufficiency.
Apple Developer — Custom Product Pages: audience routing, potential discovery, Apple Ads use and measurement dimensions. Accessed October 20, 2026. Promotional averages and developer case results omitted; not evidence of this team's outcomes.
Apple Ads — Create ad variations: search-results CPP creative/destination alignment, assignment changes, one active custom ad per group and documented default fallback. Accessed October 20, 2026. No universal account/region availability or unsupported placement behavior inferred.