ASO Patents

Publication number	US20230176843A1
Official title	App Store Information Page Customization
Assignee	Apple Inc.
Inventors	Timothy Huang, Nicholas Kistner
Priority date	December 6, 2021
Filed	December 6, 2022
Published	June 8, 2023
Status	Pending
Family	Filings in the US, Europe, Japan, Korea, China and under the PCT
Source	patents.google.com/patent/US20230176843A1

What This Patent Covers and Why It Matters for ASO

Feature it describes: the machinery behind product page testing and custom product pages, meaning how the App Store serves different versions of the same app’s page to different users and measures which version performs better.

This is the most directly actionable patent in the collection, because unlike the search patents it describes a feature developers actually operate themselves. The priority date of December 6, 2021 sits right alongside the arrival of product page optimization and custom product pages in the App Store, so this is not speculative infrastructure. It is the filed description of a shipped product.

One element of claim 1 deserves to be pulled out before anything else, because it is the part almost nobody discusses. The claim does not stop at the store. It requires that upon launching the application, the application is presented in accordance with the first presentation version. The treatment a user saw on the product page carries into the app’s own presentation after install.

That is a claim about continuity between store creative and first run experience, and it reframes what a product page test is. Under this design a test is not only measuring which screenshots convert better. It is measuring a promise and then keeping it.

What follows for practice:

• The patent names an 80 to 20 traffic split as its example, with 80 percent of users on the default treatment and 20 percent distributed across variations. If that reflects the platform’s defaults, the practical implication is that variant traffic is scarce and tests on low traffic apps will take a long time to resolve.
• Treatment assignment is tracked against the user or device identifier so that repeat visits stay consistent. A user does not see a different variant on their second visit, which matters for any analysis that assumes independent exposures.
• The measured metrics named in the description go well beyond conversion. Download rate, share rate, referral traffic from shared links, time spent on the information page and installation data all appear. Share rate and referral traffic are not surfaced to developers in App Store Connect reporting, which suggests Apple evaluates page variants on signals you cannot see.
• Confidence values and an estimated lift rate are named as part of performance reporting, so the platform’s own reporting is framed around predicted improvement over the default rather than raw differences.
• If the post install continuity in claim 1 is implemented, then aligning onboarding with the winning creative is not a nice extra. It is part of the mechanism the patent describes.

Note the status. This application is pending, so the claims may narrow before grant, and the post install continuity element is exactly the kind of limitation that could be added or removed during examination.

Patent Summary

An app is associated with several presentation versions of its information page, varying elements such as the icon, screenshots, media items, description and other text. When a user accesses the app store, the system detects that access along with a user identifier, selects one presentation version for that identifier, and displays the app’s representation accordingly. Selection can be randomized or governed by predefined rules, and the identifier to treatment mapping is stored so the assignment is stable across visits.

The store then collects engagement data per treatment: what share of page views turned into downloads, what share produced shares, how much referral traffic those shared links generated, and how long users spent on the page. Reporting includes confidence values and an estimated lift rate against the default treatment. When a user downloads the app, the treatment assignment persists, and claim 1 requires the app itself to be presented according to that version when launched.

A note on sourcing: the abstract shown for this publication on some patent aggregators describes holiday scoring for digital media assets, which does not match the title, the claims or the description. Read the claims and description directly rather than relying on the abstract field.

Detailed Explanation

What gets varied

The description covers variation of the information page’s constituent elements: the app icon, the description text, screenshots, other media items and text presentations. Figure 2 illustrates treatment variations side by side, and Figure 5 covers the custom product pages flow specifically.

The distinction between the two features is worth keeping straight, because the patent covers both. Product page optimization tests variants against each other on the default page to find a winner. Custom product pages serve a deliberately different page to a known audience, usually arriving from a specific campaign, with no intent to declare a winner. Both are the same underlying mechanism: multiple presentation versions of one app, selected per user by rule or at random.

How users get assigned

Claim 1 begins with detecting first access to the app store associated with a first user identifier, then selecting a presentation version for that identifier. Assignment is either randomized or determined by a predefined rule set, and the association between identifier and treatment is written into a data structure so repeat visits resolve to the same version.

Stability of assignment is not a small implementation detail. It rules out a common source of noise in store experiments, where a returning user sees a different variant and their eventual install is attributed to whichever page they happened to land on last. It also means the unit of measurement is the user, not the page view, which is the right way to run this kind of test and the reason download rate per treatment is meaningful at all.

The traffic split

The description gives a concrete example of user distribution: 80 percent of users may view a default treatment while 20 percent view one of the additional variations.

Take that seriously as a planning constraint. If three variants share 20 percent of traffic, each variant is receiving under 7 percent of your page views. An app with modest daily impressions on its product page will need weeks to accumulate enough exposures per variant for a difference of a few percentage points to be distinguishable from noise. The patent gives no test duration, which is consistent with duration being a function of traffic rather than a fixed window.

The asymmetry also has a rationale worth naming. Holding most traffic on the default limits the downside of a bad variant. That is a sensible platform choice and a slow one for developers, and both things are true at once.

What gets measured

Signal	Definition as described	Visible to developers
Download rate	Share of page views resulting in downloads	Yes
Share rate	Share of page views resulting in a share action	No
Referral traffic	Traffic arriving from links that users shared	Partially, through source type reporting
Time on information page	Duration of the page visit	No
Installation data	Install outcomes following download	Partially
Confidence value	Reported alongside treatment performance	Yes, as improvement confidence
Estimated lift rate	Predicted performance improvement over the default	Yes

The third column is an interpretation, not a quotation from the patent, but the gap it exposes is real. Share rate, referral traffic and dwell time are named as things the system collects per treatment, and none of them appear as first class test metrics in developer reporting. Two readings are available. Either they inform Apple’s own evaluation of page quality, or they are simply collected and unused. The first is more likely for signals a company bothers to enumerate in a patent.

Dwell time is the one to think hardest about. A variant that wins on download rate while losing badly on time spent is a variant that persuades faster, which is good, or persuades more superficially, which may show up later as worse retention. The patent does not connect dwell time to any downstream judgment. It just records it.

Statistical treatment, and what is missing

Confidence values appear as part of performance reporting and an estimated lift rate expresses predicted improvement against the default. Beyond that the document does not describe how significance is computed, what test is used, or what threshold justifies declaring a winner.

That absence is worth stating plainly rather than filling in. Anyone claiming to know whether the platform uses a frequentist test, a Bayesian posterior or a sequential method is not getting it from this patent. What the patent does establish is that lift is framed relative to the default treatment, which means the default’s own performance drift over the test window is baked into every reported result.

The post install continuity claim

Figure 3 is titled for consistency after download, and claim 1 closes on it: the app is downloaded and, upon launching, is presented in accordance with the first presentation version.

Mechanically this requires the assignment to travel with the install, so the app can learn which treatment its new user saw. That is a real integration, not a store side nicety, and it is the element that makes this claim distinctive rather than a description of ordinary split testing.

Strategically it points at something most teams treat as two separate disciplines. If the store page and the first run experience are one continuous surface, then testing them separately measures the wrong thing. A variant promising a specific outcome should be paired with an onboarding flow that delivers it, and the pairing, not the screenshot, is the treatment.

How completely this is implemented today is not something the patent answers. Treat it as documented intent.

What is claimed

Claim 1 covers detecting first access to an app store associated with a first user identifier, selecting a first presentation version of an app that has multiple presentation versions, causing the app’s representation to be displayed according to that selection, detecting selection of the app for download, and causing the download such that on launch the app is presented in accordance with that same presentation version.

Notice what is not in the claim. No metric, no traffic split, no confidence calculation, no winner selection. The claimed invention is the assignment and its persistence through install. The measurement apparatus, which is what developers actually interact with, sits in the specification.

How to use this in practice

• Plan test duration from your own product page impressions and the assumption that each variant receives well under 10 percent of traffic. Fewer variants tested for longer beats more variants tested inconclusively.
• Pair each creative variant with the onboarding it implies, and measure retention by treatment where your analytics allow it. The patent’s own architecture assumes that continuity.
• Do not read a close result as a small true difference. With this traffic allocation, a close result usually means insufficient exposure.
• Treat custom product pages and product page tests as the same system used for different purposes, and do not run both in ways that fragment your traffic further than necessary.

Family and related patents

Apple filed this family in the United States, Europe, Japan, Korea and China, and under the PCT. Broad international coverage on a feature this commercially central is expected, and it contrasts with the search classification family, which lapsed.

For the surfaces that decide who ever reaches a product page, see WO2023235143A1 on suggested results and US20240086412A1 on personalized recommendations.