ASO experimentation · Reference

Glossary.

ASO experimentation has its own vocabulary — some Apple- and Google-platform terminology, some ASOLOOP-specific concepts. This is the canonical reference for both, in plain language. 29 terms across 6 categories.

A–Z index (29 terms)

Store-experiment surfaces

5 terms

ASAApple Search Ads: Apple's keyword-bidding ad network on the App Store. Often the source of CPP traffic — paid acquisition channels point at variant landing pages tuned to the campaign keyword cluster.; Related: CPP
CPPApple Custom Product Pages: Apple's variant landing-page surface — up to 35 alternate versions of a product page targeted via referral URL (Apple Search Ads, web ads, deep links). Unlike PPO they don't run as native A/B tests against organic traffic; they're the destination behind paid or curated channel traffic.; Related: PPO, ASA
CSLGoogle Custom Store Listing: Google Play's variant store-listing surface — alternate listings targeted by acquisition channel, country, install state, or pre-registration. Equivalent in role to Apple CPP, but with channel-targeting controls Apple doesn't expose.; Related: CPP, PPO
PPOApple Product Page Optimization: Apple's native A/B test surface inside App Store Connect. Lets you split-test up to three treatment variants of icon, screenshots, app preview video, or any combination against the live page. Results render as conversion-rate posteriors with confidence levels; ASOLOOP ingests them and writes them into the per-app evidence library.; Related: CPP, Bounded signal
SLEGoogle Store Listing Experiment: Google Play's native A/B test surface inside Play Console — it splits traffic across treatment variants of icon, feature graphic, video, or text, and is the Google-side equivalent of Apple PPO. Supports up to 5 concurrent localized experiments with up to 3 treatments each; ASOLOOP runs it as the default Android experiment type. One of two organic lanes on Google Play, alongside Custom Store Listings (CSL), which allow up to 5 active and up to 50 live custom pages.; Related: PPO, CSL

Metrics & attribution

5 terms

ARPUAverage revenue per user: MMP-derived per-user revenue figure — the multiplier ASOLOOP will apply on top of CVR posteriors once per-hypothesis revenue ranges ship. ASOLOOP uses operator-MMP-sourced ARPU exclusively — no operator-attested fallback per the claim-safety contract.; Related: MMP, Revenue-denominated confidence
CVRConversion rate: Impressions-to-installs ratio. The headline metric on every PPO/CPP/SLE/CSL result. Pairing every CVR delta with revenue-denominated confidence — the CVR posterior translated via MMP-derived ARPU, install-to-paid, and lifespan inputs — is in progress; revenue reads today as a workspace-level band, never a per-experiment figure.; Related: Revenue-denominated confidence, MMP
Install-to-paid: MMP-derived ratio of installs that convert to paying customers within a defined window. The second multiplier in the revenue-denomination chain (alongside ARPU and lifespan).; Related: MMP, Revenue-denominated confidence
Lifespan: MMP-derived expected duration a paying user stays subscribed or retained. The third multiplier in the revenue-denomination chain. Used to project lifetime-value revenue from a CVR posterior once per-hypothesis revenue ranges ship.; Related: MMP, Revenue-denominated confidence
MMPMobile Measurement Partner: Third-party install-attribution and post-install-event tracking platform. AppsFlyer, Adjust, Branch, and Firebase Analytics are all live as connectors; AppsFlyer is the one that feeds revenue denomination today — a workspace-level revenue band on the Teams-tier stakeholder dashboard, computed from your connected AppsFlyer revenue. The Adjust, Branch, and Firebase revenue paths, and per-hypothesis revenue ranges from the Bayesian CVR posterior, are in progress.; Related: Revenue-denominated confidence, ARPU

Mode lifecycle

4 terms

Agent: Mode 3 of the three-mode lifecycle. Signal-rich posture; ASOLOOP surfaces 1 candidate; the recommendation is committed enough to act on. Opt-in only; never auto-promoted from Classic. Required pre-condition for Autopilot.; Related: Three-mode lifecycle, Classic, Autopilot
Classic: Mode 2 of the three-mode lifecycle. Signals reliable; ASOLOOP surfaces 3-4 candidates with signal-backed rationales. The default once Learning auto-progression fires — three active signals, signal health at or above 1.5 sigma, and three qualified hypotheses, all required.; Related: Three-mode lifecycle, Learning, Agent
Learning: Mode 1 of the three-mode lifecycle. Cold-start posture. ASOLOOP surfaces 3-4 hypothesis candidates per cycle; signal weights are wide. The right mode for a new app, and wherever the evidence gates are unmet or recent evidence is contradictory.; Related: Three-mode lifecycle, Classic
Three-mode lifecycle: Learning → Classic → Agent. The mode shape of a per-app workspace. Confidence shapes commitment: Learning offers 3-4 candidates per cycle when evidence is thin; Classic offers 3-4 candidates with signal-backed rationales when evidence is reliable; Agent offers 1 candidate when evidence is rich enough to commit. Auto-progresses on threshold; operator override available any direction.; Related: Learning, Classic, Agent

ASOLOOP concepts

9 terms

Auto-apply-winner: Optional automation: ASOLOOP applies the winning variant to the live listing autonomously after PPO/CPP/SLE finalisation; winning CSL treatments are send-for-review staged for you. Available in any mode. Operator still picks, reviews, and approves the candidate; auto-apply removes the manual click after the test concludes.; Related: Autopilot, Reversibility
Autopilot: Agent-mode-only opt-in. ASOLOOP runs the experimentation loop end-to-end with no per-step approval — selects candidates, drafts content, runs claim-safety validation, applies winners. Implies auto-apply-winner. Suspendable any time; effect on next cycle.; Related: Agent, Auto-apply-winner, Claim-safety validator
Bounded signal: An ASOLOOP-written signal that traces to a source experiment, can be inspected, and can be revoked within a 7-day window. The architectural commitment behind bounded AI — you never have to believe it, only check it. Every recommendation surface anchors to one or more bounded signals; you can question or revoke any one.; Related: Claim-safety validator, AI evidence trail
Evidence library: Per-app, per-Workspace store of signals contributed by historical experiments. Each library is scoped to one app; signals from one Operator's app do not feed another Operator's recommendations. The substrate that compounds: every experiment writes contribution; every recommendation reads from it.; Related: Bounded signal, Programs
Hypothesis card: The unit of an ASOLOOP recommendation surface. Carries the candidate change, the signal-backed rationale (with source experiments cited), and the underlying deterministic evidence. Operator inspects, edits, accepts, or rejects. A per-hypothesis revenue range on the card is in progress.; Related: AI evidence trail, Revenue-denominated confidence
Locale scopeThe storefront languages an experiment runs in: Every experiment carries a locale scope. When you don't set one, ASOLOOP derives it from the app's detected storefront — a Mexico storefront defaults to es-419, a Germany storefront to de-DE (es-ES and es-419 are never merged). Analysis, generated creative, and claim-safety checks run in that listing language. Around 30 storefronts are mapped today; outside the mapped set, generation degrades to guarded prompts with a review flag rather than proceeding silently.; Related: Claim-safety validator
Programs: Cycle/scheduled experimentation surface (/programs route, ExperimentSchedule entity). Recurring rotations on daily / weekly / biweekly / monthly / quarterly cadences (e.g., weekly hero rotation, monthly seasonal banner, biweekly subtitle refresh). Each iteration writes contribution to the per-app evidence library; the next iteration starts from accumulated signals.; Related: Bounded signal, Three-mode lifecycle
Revenue-denominated confidence: Revenue-denominated reporting. Today: a workspace-level revenue band on the Teams-tier stakeholder dashboard, computed from your connected AppsFlyer revenue as a run-rate range bucket — never a point estimate, per the claim-safety contract. In progress: translating each hypothesis's Bayesian CVR posterior into an expected revenue range (MMP-derived ARPU + install-to-paid + lifespan), rendered on the card as ~$X–$Y/month at N% probability with assumptions disclosed inline.; Related: MMP, ARPU, Claim-safety validator
Reversibility: Architectural commitment that every action — including AI-autonomous ones — has an undo path. Suspend any experiment; revoke any signal within 7 days; turn Autopilot off (effect on next cycle); roll back applied winners. One of ASOLOOP's founding trust commitments.; Related: Autopilot, Bounded signal

AI surface controls

3 terms

AI evidence trail: Every LLM-rendered surface in ASOLOOP keeps its deterministic evidence in view: the model-written text sits alongside the source data it summarizes, every claim traces to its source experiment, and any signal can be inspected, suppressed, or revoked within a 7-day window — all gated by the claim-safety validator. The architectural answer to AI-trust skepticism: you never have to believe the AI, only check it.; Related: Claim-safety validator
Claim-safety validator: Mandatory gate on every generative content output. Rejects un-sourced revenue claims, regulated-category claims without evidence, and point-estimate revenue projections. Triggers deterministic-template fallback when an LLM output is rejected; nothing reaches the operator that hasn't passed validation.; Related: AI evidence trail, Bounded signal
Connect Your AI ModelBYOK LLM keys: Operator-owned LLM API credentials (Anthropic, OpenAI, fal.ai) used to power generative surfaces. Required at Starter and Pro; optional alongside managed AI at Teams per executed contract. Keys are encrypted at rest with workspace-scoped envelope encryption and never logged.; Related: AI evidence trail

Workspace & roles

3 terms

Operator: The company or individual that owns the Workspace and is the named subscriber of record. Operator owns all Customer Data submitted; ASOLOOP acts as Processor for Customer Data and Controller for account metadata.
Rights Administrator: Workspace-level Teams role authorised to approve regulated-claim attestations (healthtech, fintech, gambling, children's apps). Required for any generative output that triggers a regulated-claim policy. Available at Teams tier only.; Related: Claim-safety validator
Workspace: The ASOLOOP environment scoped to one Operator (legal entity). Each Workspace is isolated from every other Workspace at the data layer. Workspace boundaries are enforced at every API endpoint and every algorithm-layer read path.

See also: How it works · Programs · Features