How do you improve conversions with low traffic?
If your site gets a handful of inquiries each week, an A/B test can take a long time to tell you anything useful. You can still improve the site. Start by checking whether people can finish the task, understand the offer, and get their request through to the business.
Fixing a failure, making a better-supported design choice, and measuring a conversion improvement are different achievements. You don't need to call every improvement a proven lift.
Decide which kind of uncertainty you are reducing
What would you need to learn to make the next decision? Be specific before opening the testing tool. “We need more conversions” describes a goal, but it doesn't tell you what to investigate.
| Question | Useful evidence | Decision you can support |
|---|---|---|
| Can visitors complete the task? | Reproduction, accessibility checks, technical logs | Repair a demonstrated failure |
| Do visitors understand the offer? | Task-based conversations, observed misunderstandings | Clarify the message and check it again |
| Where do recorded visits lose momentum? | Funnels, replay, error events | Choose a specific problem to investigate |
| Does this alternative improve conversion? | A suitably designed controlled experiment | Estimate a causal effect with uncertainty |
If a recording leads you to a broken submit button that you can reproduce, fix it. You still don't know how many additional customers that repair will bring next month.
“Which of these offers should we sell?” deserves more investigation than “Can we stop hiding the booking button behind the cookie controls?” The second problem may already be clear enough to resolve. Don't make the team wait for a conversion experiment to repair a demonstrated failure.
Turn the percentage back into people
Consider an illustrative site with 40 eligible visits and two accepted inquiries this week: a 5% conversion rate. Next week, four inquiries from 40 visits would be 10%. “Conversion doubled” sounds impressive. The difference is two inquiries, and the visitors may have come from entirely different sources.
Keep the counts beside the rate so nobody has to reconstruct that context. Define eligibility and the time window. Say whether returning visits count separately. And if you only observe consented visits, don't quietly present their results as the experience of everyone who arrived.
Uncertainty calculations matter too. NIST explains interval estimates for proportions and cautions that a simple normal approximation can be inaccurate for small samples or extreme proportions. Use an appropriate interval method, not a percentage with an implied guarantee. NIST on binomial proportion intervals.
There's no magic recording count that makes every decision reliable. A few visits may reveal a defect while leaving its frequency and conversion impact uncertain. Keep those questions separate.
Follow one journey all the way through
Choose an outcome the business can use: an accepted inquiry, a booked appointment, or a completed purchase. A click on “Contact” leaves plenty of work unfinished. If the team only acts on qualified inquiries, make sure your definition of success preserves that distinction.
Map the shortest useful journey to that outcome. Check it yourself on mobile and desktop, with slow responses and plausible errors. Confirm that the request reaches the destination, not merely that the interface displays a pleasant message.
Then review visits around that journey, including the ones that finished successfully. Look for barriers you can investigate. A frustration filter can help you find candidates, but spending the whole review watching the most dramatic sessions gives you a selective view of the site.
Keep page version, device context, and acquisition source with the finding. A pause on an old pricing page shouldn't become a task for the redesigned one.
Ask people to do something, not admire something
Ask people who plausibly need the service to do something realistic. For example: “You need a bike repaired before Friday. Find out whether this shop can help and what to do next.” Leave out the button name. You want to learn whether the page helps them find their way.
Observe the path before asking for opinions. Where do they look for turnaround time? What do they think happens after submitting? Which information do they need from you because the page does not provide it?
Spend time understanding each misunderstanding. If three people read “Reserve” as a confirmed booking, you have a useful reason to examine the wording. You haven't learned what percentage of all customers would interpret it that way. Putting a percentage on a few interviews doesn't make the finding more useful.
After changing the page, give fresh participants the same underlying task. Repeated success on that task strengthens the usability evidence. It still does not substitute for measuring acquisition quality or conversion over time.
Make changes with a reason and a way back
Write down why you're making a meaningful edit while the reason is still clear. Otherwise, a reasonable hunch can become a “proven win” simply because nobody remembers the original conversation.
Decision: Explain the response time beside the inquiry form. Evidence: Task participants could not tell when to expect an answer. Change: State the real business response window. Expected behavior: Visitors can describe what happens after sending. Verification: Repeat the task and check accepted submissions. Guardrail: Do not increase expectations beyond what the team can deliver. Rollback: Restore the previous copy if the promise cannot be maintained. Uncertainty: Conversion impact has not been established.
It's tempting to combine every improvement into one release. You may ship a better site that way. But if you replace the offer, pricing, navigation, and form together, be honest about how difficult it will be to determine which change helped.
Design the experiment before deciding to run it
Start with the smallest effect that would change a real business decision. Microsoft's experimentation guidance emphasizes planning hypotheses, metrics, power, and the affected population before launch. Microsoft pre-experiment guidance.
Consider a team planning to compare two inquiry pages. These hypothetical inputs describe one experiment, not recommended defaults:
- Baseline: 4% accepted-inquiry rate as a planning estimate. Limited history makes it uncertain; repeat the calculation at plausible 2% and 6% baselines.
- Worthwhile effect: An absolute increase of two percentage points, from 4% to 6%, chosen because smaller gains would not justify this change's operating cost.
- Assignment: Eligible visitors, randomized equally between two pages, with returning visits retaining their assignment.
- Outcome: At least one service-accepted inquiry within seven days of assignment, counted once per assigned visitor.
- Statistical plan: A fixed-horizon, two-sided comparison of proportions, with 5% significance and 80% power to detect the chosen effect under the model's assumptions.
Give those inputs to a calculator or analyst using that test method. Obtain required sample per group, translate it using eligible visitor arrivals, and allow the final seven-day outcome window to finish. Neither the assumed baseline nor the power target guarantees a conclusive result.
If the plan can't answer your question within a useful period, reconsider the question or the method. A meaningful difference between offers may deserve the effort. A barely visible adjustment may not. Don't increase the expected effect in the calculator just because you prefer the shorter runtime.
Define the decision rule before looking at results. Include a meaningful business outcome, checks for data quality, and guardrails such as errors or inappropriate inquiries. Use a method that supports any planned interim analysis rather than repeatedly stopping when a convenient result appears.
Don't split sparse traffic into a garden of variants and select the prettiest number. An inconclusive result doesn't justify a winner.
Keep a useful weekly decision habit
Start the week with accepted outcomes and any failures. Pick one question, inspect relevant visits, and decide what action the evidence supports. Give someone ownership of the change and agree on what they need to check afterward.
When the numbers move, investigate the context: campaigns, returning customers, seasonality, stock, and changes in what visitors are offered. Keep observational comparisons labeled as observational. A week with more conversions is welcome news, but it does not automatically validate the latest headline.
You should be able to explain what got better: requests now reach the business, visitors can explain the price, or mobile users can finish the form. Keep the larger conversion question open until you have the evidence to answer it. There's useful work to do in the meantime.