Running an experiment is only half the job. The real value comes from understanding what the results mean and knowing what action to take next.
This guide shows you exactly how to read and analyze an Experiment Analytics page in GemX and decide what to do next.
If you’ve opened your test results and are wondering, “So… is this test good or not?”, this is for you.
Before You Analyze: Make Sure Your Data Is Ready
Before opening analytics, confirm that your experiment is actually ready to be analyzed. Looking at results too early is one of the most common causes of wrong decisions.
First, check the experiment status.
Experiments that are still running can be analyzed, but conclusions should be treated as directional unless the test has run long enough and has collected sufficient traffic. Paused or completed experiments are more reliable for decision-making.
Next, do a quick data sanity check. Your experiment should have:
-
A reasonable number of sessions on each variant
-
Traffic is distributed evenly according to your split settings
-
Enough runtime to cover normal traffic fluctuations
If a variant only has a small number of sessions, any apparent “winner” is likely noise rather than a real improvement.
Access Your Experiment Results in GemX
To view results, go to your GemX Dashboard > Experiment.
Then, select the experiment you want to analyze, and click on the chart icon to open its analytics.
This is the main workspace where GemX aggregates all performance data for that experiment.
At a glance, click View all metrics to see overall experiment performance and a breakdown by template (Control vs. Variant).
How to Read and Analyze Your Test Results Correctly
Step 1: Start With the Top
At the very top of the Experiment Analytics page, GemX shows you:
-
Experiment's advanced settings (winning metric, traffic segmentation)
-
Control template (version A)
-
Variant template (version B)
-
Page or template being tested
Before looking at any metrics, confirm one thing: Both variants are testing the same intent and traffic context.
For example, if both A and B are landing pages coming from paid social traffic, then comparing the conversion rate makes sense.
If traffic sources or page purposes differ, stop here. The data will be misleading, no matter how good the numbers look.
This quick check prevents most false conclusions.
Step 2: Use Journey Analysis to Find the Real Bottleneck
The Journey Analysis section is where you should spend most of your time.
Read it from left to right, exactly as users move:
-
Entry page
-
Next page
-
Added to cart
-
Reached checkout
-
Completed checkout
Do not jump to conversion rate yet.
Instead, ask:
-
Where do users drop off the most?
-
Does the drop happen early (page-to-page) or late (checkout)?
In your example, the biggest loss happens between the first landing page and the product page. That tells you the experiment is not primarily a checkout or pricing issue, it’s a message match or intent clarity problem.
Key takeaway: If drop-off happens early, iterate on hero copy, value proposition, or CTA clarity, not checkout UX.
Step 3: Check Performance Over Time to Validate Stability
Next, look at Performance over time.
You’re not analyzing growth here. You’re checking consistency.
What you want to see:
-
Control and Variant curves move in a similar pattern
-
No sudden spikes caused by traffic anomalies
-
Both variants received traffic during the same periods
If one variant gets traffic only during a short window, do not trust its performance yet.
Important note: If performance curves are unstable or traffic is uneven, keep the experiment running. Do not declare a winner.
Step 4: Read Conversion Rate Together With AOV
Now move to the Conversion rate, Average order value, and Revenue per visitor cards.
This is where most users misread results.
In the example:
-
Variant B has a higher conversion rate
-
Control A has a higher average order value
-
Revenue per visitor is very close
This means the experiment changes buying behavior, not demand.
For instance, Variant B converts more users, but those users spend less per order. So, you should not pick a winner yet.
This is a signal to:
-
Segment by product mix
-
Or run a follow-up test focused on upsell or pricing presentation
If revenue per visitor is flat, applying the variant will not move the business needle.
Pro tip: You can click on any metric's name to reveal its detailed analytics. For example, if you want to deep dive into the Revenue per visitor, click on it to open the metric analytics page.
Step 5: Segment Results by Visitor Type, Device, and Traffic Source
Scroll down to:
-
Visitor type
-
Sessions by device
-
Sessions by traffic source
These sections explain who the experiment works for.
For example, in your data:
-
Most traffic is paid social
-
Majority of users are new visitors
-
Mobile dominates
This tells you the experiment result is mobile-first and acquisition-driven.
Pro tip: If the variant wins, apply it only to paid social landing traffic first, not globally.
If it loses, don’t generalize the failure to all channels.
Step 6: Validate With Real Orders
At the bottom, GemX shows Orders from experiment.
This is your reality check. Look at:
-
Which variant generated each order
-
Order value
-
Device and traffic source
In the example, each variant generated one order, both from paid social and mobile. That confirms:
-
The test has low absolute volume
-
Results are still directional, not conclusive
Furthermore, you can track the full shopping journey of each order, revealing the timestamp from when users visited your page to completed checkout.
Pro tip: If total orders per variant are under ~20, treat all conclusions as exploratory.
Step 7: Decide What to Do Next
After reading the page, you should end with one clear decision, not a feeling.
Use this decision map:
-
Apply the variant: When revenue per visitor is clearly higher and journey drop-offs improve.
-
Iterate with a new experiment: When conversion rate improves but AOV drops, or when funnel insights reveal a specific weak step.
-
Stop and archive: When both variants perform similarly and insights do not justify another iteration.
If you can’t make one of these decisions, the experiment is not done yet.
Related Articles
