Every experiment in PressPlay moves through a defined lifecycle of statuses. Understanding these states, when transitions occur, and what you can edit at each stage is essential for effective experiment management.
PressPlay uses six distinct statuses to track experiment state:
Initial state when an experiment is incomplete or has validation errors. Experiments in this status are not eligible for the backlog queue.
Common reasons:
Missing required fields (variants, settings, etc.)
Incomplete asset uploads
Configuration errors
Manually set to NOT_READY for later completion
Experiment is fully configured and eligible for execution. READY experiments enter the backlog queue based on their priority and will run when they reach the front of the queue.
Requirements:
All required fields completed
Valid variant configurations
Proper experiment settings
No blocking errors
An error occurred during experiment setup or execution. Experiments in ERROR status are not eligible for the backlog and require investigation and correction.
Common causes:
Google Play API errors
Invalid store listing or locale configuration
Asset validation failures
Network or connectivity issues
Check the error field in experiment details for specific information about what went wrong.
Experiment is actively running on the Google Play Store. Traffic is being split between variants, and data is being collected. Only one experiment per app can be IN_PROGRESS at a time.
Characteristics:
Start date is set and in the past
Google Play experiment ID is assigned
Limited editing capabilities (see Editable Fields section)
Real-time performance data available
Experiment is in the process of stopping. This transitional status occurs when you manually stop a running experiment or when the system stops it due to auto-kill conditions.
During STOPPING:
Google Play Store is being updated to remove the experiment
No new impressions are collected
Final data synchronization occurs
No fields can be edited
Once stopping completes, status transitions to FINISHED.
Experiment has completed execution. This is a terminal status—finished experiments cannot be restarted or modified.
Reasons for finishing:
Reached maximum duration
Achieved statistical significance with auto-adjust enabled
Manually stopped (transitioned through STOPPING)
Auto-kill conditions triggered
Results remain available for review, but no further changes are possible.
PressPlay enforces specific transition rules to maintain data integrity:
From Status Can Transition To How | ||
NOT_READY | READY, ERROR | Manual edit or automatic validation |
READY | NOT_READY, ERROR, IN_PROGRESS | Manual edit, validation error, or automatic start |
ERROR | READY, NOT_READY | Fix error and manually update status |
IN_PROGRESS | STOPPING | Manual stop or auto-kill trigger |
STOPPING | FINISHED | Automatic when stop completes |
FINISHED | None | Terminal status |
Several transitions occur automatically without user intervention:
READY → IN_PROGRESS: When experiment reaches front of priority queue
IN_PROGRESS → STOPPING: When auto-kill conditions trigger
STOPPING → FINISHED: When stop process completes
Any → ERROR: When system errors occur during validation or execution
You can manually trigger certain transitions:
NOT_READY ⇄ READY: Toggle when making configuration changes
ERROR → READY: After fixing reported errors
IN_PROGRESS → STOPPING: Manually stop a running experiment
PressPlay does not support pausing experiments. Once an experiment enters IN_PROGRESS status, it can only be stopped, which permanently moves it to FINISHED status. You cannot resume a stopped experiment.
Google Play Store API limitations
Statistical integrity concerns (pausing can bias results)
Data synchronization complexity
If you need to delay an experiment that hasn't started yet (READY status):
Change to NOT_READY: Removes from queue while preserving all configuration
Lower priority: Delays start without removing from queue
Both options allow you to start the experiment later
If an experiment is IN_PROGRESS and you need to stop it:
Stopping moves the experiment to STOPPING status, then FINISHED
This is permanent - you cannot resume the experiment
If you need to run a similar test, create a new experiment
Results from the stopped experiment cannot be combined with a new experiment
What you can edit varies significantly based on experiment status. Understanding these constraints prevents frustration and helps you plan experiments effectively.
Nearly all fields are editable:
Status: Can change to READY
Experiment Title: Name of the experiment
Hypothesis: Your test hypothesis
Store Listing (csl_id): Target custom store listing
Language (locale_id): Target locale
Priority: Queue position
Target Metric: What you're measuring
MDE (Minimum Detectable Effect): Statistical threshold
Confidence Level: Statistical confidence interval
Duration: Min and max duration in days
Early Kill Settings: CVR decrease threshold, enabled flag, min installs
Auto-Adjust End Date: Whether to adjust based on significance
Apply Settings: How to apply winning variant
Variants: Full variant editing including all asset content
Most fields remain editable before execution begins:
Status: Can change to NOT_READY or IN_PROGRESS
Experiment Title: Name of the experiment
Hypothesis: Your test hypothesis
Store Listing (csl_id): Target custom store listing
Language (locale_id): Target locale
Priority: Queue position
Target Metric: What you're measuring
MDE (Minimum Detectable Effect): Statistical threshold
Confidence Level: Statistical confidence interval
Duration: Min and max duration in days
Early Kill Settings: CVR decrease threshold, enabled flag, min installs
Auto-Adjust End Date: Whether to adjust based on significance
Apply Settings: How to apply winning variant
Note: Variants cannot be edited in READY status. To edit variants, change status to NOT_READY, make changes, then change back to READY.
Same editability as NOT_READY and READY, allowing you to fix issues:
Status: Can change to READY or NOT_READY
Experiment Title: Name of the experiment
Hypothesis: Your test hypothesis
Store Listing (csl_id): Target custom store listing
Language (locale_id): Target locale
Priority: Queue position
Target Metric: What you're measuring
MDE (Minimum Detectable Effect): Statistical threshold
Confidence Level: Statistical confidence interval
Duration: Min and max duration in days
Early Kill Settings: CVR decrease threshold, enabled flag, min installs
Auto-Adjust End Date: Whether to adjust based on significance
Apply Settings: How to apply winning variant
Variants: Full variant editing to resolve errors
Severely limited editing to protect data integrity. Only these fields can be modified:
Duration: Min duration days and max duration days
Early Kill Settings: CVR decrease threshold, enabled flag, and min installs
Auto-Adjust End Date: Whether to automatically adjust end date
Status: Can only change to STOPPING
Cannot edit while IN_PROGRESS:
Experiment title or hypothesis
Store listing or locale
Priority
Target metric, MDE, or confidence level
Apply settings
Variants
Rationale: Changing most settings mid-experiment would invalidate statistical analysis. Duration and auto-kill adjustments are permitted because they don't affect the experiment design itself.
No fields are editable. The experiment is in the process of stopping and will transition to FINISHED automatically.
No fields are editable. This is a terminal state focused on preserving final results.
Keep experiments in NOT_READY status while you're still making configuration decisions. Only transition to READY when you're committed to running the experiment as configured.
Perform a final review before changing status to READY:
Verify all variants are correctly configured
Confirm experiment settings match your testing goals
Check that priority is appropriate for your backlog
Ensure store listing and locale are correct
Once READY, variant editing becomes restricted.
Set up alerts for experiments entering ERROR status. Quick resolution prevents queue delays and maintains testing velocity.
Even though some settings can be modified during IN_PROGRESS status, change them only when necessary. Mid-experiment modifications can complicate results interpretation.
Maintain notes about manual status changes, especially:
Why you stopped an experiment early
What errors occurred and how you fixed them
Why you changed an experiment from READY to NOT_READY
Change status from READY to NOT_READY
Make necessary edits (including variants if needed)
Verify all changes are correct
Change status back to READY
Experiment re-enters queue at its priority level
Review error details in experiment details page
Fix the underlying issue (update store listing, fix asset, etc.)
Update experiment configuration if needed
Change status to READY
System validates and either starts experiment or reports new errors
Navigate to experiment in IN_PROGRESS status
Click "Stop Experiment"
Confirm the action
Status changes to STOPPING
Wait for Google Play Store update to complete
Status automatically transitions to FINISHED
Next experiment in queue starts automatically
Identify experiments you want to run first
Adjust priorities so delayed experiment has lower priority
Keep status as READY
Experiment remains in queue but runs later
If an experiment remains in STOPPING for more than 10 minutes:
Check Google Play Store connectivity
Verify API credentials are valid
Contact support if issue persists
System validation may still be failing:
Review error message carefully
Verify all required fields are completed
Check that store listing and locale exist and are accessible
Ensure assets meet Google Play requirements
Check several factors:
Is there an IN_PROGRESS experiment? Only one runs at a time
What is the experiment's priority? Higher priority experiments run first
Are there errors preventing automatic start?
Understanding the Backlog - How status affects queue position and execution
Experiment Priority System - Managing priority to control timing
Troubleshooting Experiments - Resolving ERROR status and other issues
Deleting Experiments - When and how to remove experiments
