A galley proof is the copy you pull off the press to check before you commit to the print run. That is the job here.
Testing platforms are built to run experiments. They are not built to interpret them. Most dashboards show an uplift percentage, a confidence figure, and a colour, and leave you to work out what to do about it. If you have a statistics background that is enough. If you run an ecommerce store, it is not.
The result is a familiar pattern. A test looks like it won, the change ships, and the revenue line does not respond. Sometimes the uplift was noise that would have evaporated with another week of data. Sometimes the conversion rate genuinely rose while revenue per visitor quietly fell. Sometimes the traffic split was broken from the start and none of the numbers meant anything.
Galley exists to catch those three cases before the change goes live.
The output is a sentence, not a wall of figures. Ship it, keep running, or call it flat. The statistics are all there underneath for anyone who wants to check the work, but the answer comes first and it comes in words.
Revenue is. A variation that lifts conversions while dropping revenue per visitor has not won anything, and that combination is common enough that Galley reports both every time rather than making you ask.
Most tools are enthusiastic about wins and quiet about everything else. A result that is not conclusive should say so clearly, and a variation that is losing should be described as losing. Being told to keep running is a useful answer, not a failure.
You should be able to paste in some numbers and get an answer. Your CSV is parsed in your browser and never uploaded. There is no account to create before you find out whether the tool is any good.
Under the plain language, Galley uses the standard toolkit for experiment analysis:
None of this requires configuration. The tests are chosen for you based on what you have entered.
I'm a CRO Strategist with a UX design background. CRO is my calling, UX is my passion, and most of my best work happens where the two overlap.
I look at CRO as a systems problem first, a behavioral problem second, and a tactics problem last. The sequence matters.
Day to day, that means running A/B and multivariate experiments, analyzing behavioral data through tools like Google Analytics, Clarity, and Heatmap.com, and collaborating with design and development to build landing pages that convert. A growing part of my work involves building internal tooling and processes that make optimization faster and more consistent at scale.
My earlier years were spent inside iGaming, which taught me to move fast, think in systems, and make data-backed decisions under real pressure. One of the most formative projects I led was building an in-house A/B testing tool from scratch to replace a third-party solution that wasn't flexible, private, or secure enough. Owning that kind of problem end-to-end, from identifying the gap to shipping the fix, is still what I find most interesting.
The pattern is consistent: I do the work, notice where the process breaks, and build something to fix it.
Galley is the current instance of that pattern. The privacy position elsewhere on this site is not a marketing line; it is the same requirement that made the last one worth building.
Accounts and saved tests are next, so you can keep a record of what you ran, what it said, and what you decided. Everything that works today will keep working without an account.
There is no account, nothing is uploaded, and there is no plan to change either. If Galley has been useful, a coffee is a kind way to say so.