A Play Store listing experiment is an A/B test on your live listing, and Google stops it after six months.
Store listing experiments are Google's own A/B tests on your Google Play listing. You supply variants of your icon, your feature graphic, your screenshots or your descriptions, Google shows them to a share of the people who arrive at your listing, and it reports which version won on a metric you picked. The page that documents them is a Play Console Help article called Run A/B tests on your store listing, and it carries the numbers you have to plan around. Read on 21 October 2026, those numbers are: one default graphics experiment or up to five localized experiments per app at the same time, up to two variants against your current listing, and an automatic stop after six months.
What follows is what each experiment type can touch, what the documentation says about how long one needs to run, and the figure it pointedly does not give. Then what has to be true before Play Console will let you start, and how to read a result that comes back as a draw.
Start hereThe short version
What is a store listing experiment?
It is a test Google runs for you, on live listing traffic, at no extra charge. Google's feature page for the product calls it running free A/B tests on your store listing text and graphics. You do not route traffic anywhere and you do not add an analytics tool. Google splits the people who reach your Play listing, shows some of them a variant instead of your current listing, and counts one metric that you choose up front.
The name has moved around, which is the main reason this feature is hard to search for. The Help article is titled Run A/B tests on your store listing. Inside Play Console the feature lives on the Store listings page, under Grow users and then Store presence, in a column headed Experiment, with its own Experiments tab. And the thing Google used to call a global experiment is now called a default graphics experiment. The Help article says so in a note, and adds that the renamed experiment works exactly as it did before.
The same article opens with a banner saying Google recently changed store listing experiments to give developers more control and statistical robustness, listing improvements to the underlying data, a calculator to estimate time to completion, and better flows for setting a test up. That matters for anything you read elsewhere about this feature. Advice written before that change may describe a console that no longer exists.
What can you test, and how many experiments can run at once?
There are two experiment types and the split between them is graphics against text. A default graphics experiment lets you experiment with graphics in your app's default store listing language, and the assets it names are your icon, your feature graphic and your screenshots. A localized experiment covers the icon, the feature graphic, screenshots and your app's descriptions, in up to five languages, and its variants are only shown to people viewing your listing in the languages you chose. You can run experiments on your default store listing and on custom store listings.
The concurrency limit is the first thing to plan around. One app can run one default graphics experiment, or up to five localized experiments, at the same time. That figure was on the page on 21 October 2026. Each experiment tests up to two variants against your current listing, so the most you can have in flight against a single default listing is two alternative icons, not six.
The rule that quietly shrinks your sample is the localized asset exclusion. If you have added any localized graphic assets in a specific language, users viewing your app in that language are excluded from your default graphics experiments. Google's own example makes the trap clear: default language English, a localized feature graphic in French, and French viewers are excluded from the experiment even when the thing you are testing is the icon. A listing available in only one language has no exclusion and the experiment is shown to all users.
Two things people expect to find in those lists are missing. Neither list mentions your app name. Neither mentions a promo video, and the word video does not appear anywhere in the Help article, which I searched in full on 21 October 2026. Google's own feature page for the same product recommends getting the biggest impact by testing icons, videos and screenshots, so the two Google pages do not agree about video. The Help article is the one that documents the console you will be clicking in, so plan on that.
Play Console Help, run A/B tests on your store listing, read 21 October 2026
Check yours
Can you test the thing you want to change?
Pick the part of the listing you want to change. The answers come from the asset lists in Play Console Help, read on 21 October 2026.
Nothing picked. Four of these seven are in the documented asset lists, one of them only in the localized experiment, and two are not in either list at all.
How long does a store listing experiment need to run?
Google does not publish a minimum run length in the Help article. That is worth saying plainly, because a lot of advice elsewhere states one as though it came from Google. I read the whole article on 21 October 2026 and it has no minimum duration in it, and no published last-updated date either, which is why the date above is the date I read it rather than the date Google changed it.
What the article gives you instead is three different timing facts. The experiment creation page estimates the time and the number of acquisitions, opens or pre-registrations your experiment will need to show a statistically significant result, so your real answer is computed from your own traffic before you start. While it runs, a result can come back as More data needed, and Google says it will advise you if you have less than a week before it expects a result to be ready. And there is a hard ceiling: store listing experiments stop automatically after running for six months, after which no new data is collected, no variants are applied, and traffic reverts to your current listing. The completed experiment stays in Play Console with the data it gathered.
The one duration number Google does publish is a best practice, not a rule, and it sits on a different page. Google's Store listing experiments feature page lists five best practices and one of them is to test for at least a week to account for weekday against weekend traffic patterns. That page is also where the old developer.android.com store listing experiments best practices URL now redirects, so if you followed the Help article's link to best practices for running effective experiments, that is where you landed.
Put together, the planning rule is a floor of a week, a real estimate from the console, and a six month ceiling you should never reach on purpose. One more lever to be careful with: Google says the default experiment settings give results in the shortest time with reasonable accuracy, and that changing them can make your experiment run for longer before it gives you anything useful. Raising the confidence level buys you fewer false positives and costs you weeks. It is the opposite shape from the timers on the Apple side of a release, where testflight build expiry runs out in days and nothing waits for a statistically significant answer.
Google Play Console, store listing experiments, best practices, read 21 October 2026
What has to be true before you can set one up?
The path first. Open Play Console, go to the Store listings page under Grow users and then Store presence, and in the Experiment column for a store listing click Set up. The other way in is the arrow at the right end of the row, which opens that listing's Details page, where there is a Set up experiment button. If that button is not there, the article tells you to follow the prompt at the top of the Details page to fully roll out your store listing and get it ready for experiments, then come back and start again.
That missing button is the whole prerequisite, and it is about the listing rather than the build. The article says that for published apps you can test variants against your current version to see which performs best on install and open data. It does not name a release track. I read the full article on 21 October 2026 and the word production does not appear in it. So the condition it describes is a rolled out store listing, and I would not claim anything firmer than that. A google play closed testing round is about who gets the build, which is a different question from whether your listing is finished.
Then the form. The experiment name is 50 characters or fewer and users never see it, so it is for your own records. You choose the type, either a graphics experiment on the default listing or an experiment on a localized listing, and for a localized one you select the languages. You pick a target metric from three options. The advanced settings are optional and cover the number of variants, the experiment audience percentage, meaning the share of listing visitors who see a variant instead of your current listing, the minimum detectable effect, and the confidence level. Visitors in the experiment are split equally across your variants.
One step catches people who expect an experiment to be a dashboard setting. After you provide the variants and save, you can go to the publishing overview page to submit your changes for review. The assets you are testing go through the same publishing flow as the rest of your listing, so a variant that would fail your listing policy fails here too, and the clock on the review is in front of the clock on the experiment. Google also recommends testing changes to one asset at a time so you can be as certain as possible about what caused the change in performance.
Play Console Help, create an experiment, read 21 October 2026
What do the results actually tell you?
Three target metrics, and you commit to one when you create the experiment. Unique user install clicks is defined as the number of users who installed your app who did not have it installed on any other devices at the time, which is narrower than an install count and will not match the number in your acquisition reports. Unique user open clicks is installed users who opened your app. Unique user pre-registration clicks is the number of users who pre-registered, which is the metric that makes an experiment possible before you have anything to install.
The Results section gives a summary against your target metric, an explanation based on the confidence interval and the minimum detectable effect, and a recommended action where there is one. Four outcomes are worth recognising before you see them. A variant performed well, and you may be offered a recommendation to apply it. More data needed, which means come back later. A draw. Or your current listing won, in which case you click Keep current listing and you have learned something cheaply.
A draw deserves a sentence of its own, because people read it as a verdict on their design. Minimum detectable effect is the minimum difference between a variant and the control required to declare which performed better, and if the difference is less than that number, the experiment is considered a draw. It is a threshold you set. A draw means the gap was smaller than the gap you asked Google to detect, which on a listing with modest traffic is most gaps.
One mismatch to know about before you promise someone a number. Google's feature page still describes seeing acquisition and one day retention rates for each version of your store listing, while the Help article's target metric list has the three click metrics above and no retention rate at all. Both read on 21 October 2026. Plan reporting on the three in the Help article. If you want to be told when a test finishes rather than checking, the notifications come from the Notifications page in Play Console, and Google recommends opting into the email alerts.
Google Play Console, store listing experiments, metrics and best practices, read 21 October 2026
The two experiment types, side by side
| The question | Default graphics | Localized | Same for both |
|---|---|---|---|
| What the asset list includes | Icon, feature graphic, screenshots | Icon, feature graphic, screenshots, descriptions | No |
| Languages it reaches | Your default store listing language | Up to five languages you choose | No |
| How many one app can run at once | One | Up to five | No |
| Who gets left out | Anyone viewing a language where you added a localized graphic | Anyone outside the languages you chose | No |
| Variants tested against the current listing | Up to 2 | Up to 2 | Yes |
| Assets go through the publishing review flow | Yes | Yes | Yes |
| Stops on its own after six months | Yes | Yes | Yes |
Every row above comes from Play Console Help, read on 21 October 2026. The page carries no published last-updated date, so check the numbers before you build a plan on them.
Where this lands if a builder generated your app
Nothing about an experiment changes because an agent wrote the code. The test runs in your Play Console account, on your listing, against your own visitors. What a builder changes is how long it takes to have a listing worth testing, and the honest shape of that is less flattering than it sounds: a generated app arrives on an internal testing track with no public listing traffic, which is the one thing an experiment cannot do without.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, and can build a standalone Android APK. It costs $25 a month and there is no free tier. It does not submit to the App Store for you, because Apple requires the owner of the app's content to submit it. The iOS equivalent of the week you spend on listing assets is the testflight external testing review, and the full submission path is in publish to app store.
The limit worth stating out loud: generating an app does not give you a second icon. An experiment needs two credible versions of the same asset, and the second one is a design decision nobody can make for you. The cheapest first test is the one Google recommends anyway. Change one asset, pick install clicks, take the console's time estimate seriously, and give it a week before you look.
Questions people ask about Play Store listing experiments
They are A/B tests Google runs on your live Google Play listing. You supply variants of an asset, Google shows them to a share of the people who arrive at your listing, and it reports which version performed best on a metric you choose. The Play Console Help article that documents them is titled Run A/B tests on your store listing. In Play Console they sit on the Store listings page, under Grow users and then Store presence, in a column headed Experiment and on an Experiments tab. Google's own feature page for the product describes them as free A/B tests on your store listing text and graphics.
Get the listing live first, then test one thing on it
An experiment needs a rolled out store listing and real visitors before any of the numbers on this page apply to you. Build the app, publish the listing, then come back and change one asset.
Start building