Conversion rate optimisation starts with the decision, not the button

The campaign dashboard shows more clicks on “Book a demo”. Sales says the enquiries are harder to qualify. The website team is already discussing the button colour. Everyone has a number. Nobody has yet explained what the visitor needed.

That scene is illustrative, but the question is real: which part of the journey is failing, and what decision would better evidence change?

Conversion rate optimisation (CRO) is the work of finding and removing barriers between a visitor's goal and a useful outcome for the business. The rate matters, but it is only one signal. A higher click rate can hide a weaker offer, a confusing form or leads who were never a good fit. A good CRO programme connects the action on the page to what happens afterwards.

The useful output of a CRO programme is a better decision about the experience. A steady stream of tests means little if the team never learns which barrier it removed.

Start with the job, then define the outcome

Before changing a page, finish this sentence: “The visitor has come here to ___, and we will know we helped when ___.”

On a comparison page, the job may be to decide whether a product fits an existing system. On a pricing page, it may be to understand which plan covers a particular use case. A call to action (CTA) is the button or link asking visitors to do something. Clicking it is rarely their reason for coming to the page; it is a step the business hopes they will take.

Name two outcomes:

1. The immediate action: a completed form, a booking or a purchase.
2. The quality signal: a qualified enquiry, an attended meeting, an activated account or a purchase that remains sound after the first click.

Then choose a guardrail: a warning sign that the change is causing a new problem. If an experiment increases form submissions but also increases form errors, support requests or poor-fit leads, the apparent win needs another look. The same is true if a persistent CTA makes the final page action hard to reach on a phone.

This is a commercial choice as much as a measurement choice. If sales cannot agree what counts as a useful enquiry, a page test will not settle the argument for them.

Diagnose the break before you prescribe the fix

When a CTA underperforms, the button is the easiest thing to see. It may not be the problem.

Look for four different breaks:

• Visibility: Did the right visitors have a fair chance to notice the action? Check the page on real screen sizes, not only in a wide desktop preview.
• Comprehension: Could they tell what the offer means, what happens after clicking and what commitment they are making?
• Motivation: Was the page's proof strong enough for the size of the decision? An unfamiliar product may need more than a reassuring headline before asking for a sales call.
• Completion: Did the destination, form, booking flow or checkout work? Test errors, keyboard use, mobile input and the return path after submission.

Bring different evidence together. Search queries and ad creative show the promise that brought someone in. Page and event data show where activity changes. Customer questions, sales objections and consented usability observations explain what a chart cannot. A technical check can reveal that the journey simply breaks.

One signal is a clue, not a cause. A low form-completion rate might mean the form is difficult. It might also mean the page attracted people who needed an answer that the form could never give. The distinction changes the treatment.

A worked example: a demo page with the wrong kind of success

The following example is illustrative. It describes no Barrava customer, actual campaign or measured result.

Suppose a software team selling to other businesses (B2B) sends paid traffic to a product comparison page. The ad promises a clear answer about working with an existing customer relationship management (CRM) system — the software the buyer uses to manage customer records. The page makes “Book a demo” prominent, but its integration copy is vague. The dashboard records CTA clicks. Sales keeps hearing the same question: “Will this work with our current data setup?”

It would be tempting to make the demo button bigger. That would make the request more visible without answering the question behind the hesitation.

Diagnose

The team first checks the ad and page side by side. It reviews the queries and audience, the first screen on mobile, the integration explanation, the booking path and the questions raised in sales calls. It checks whether enquiries marked as qualified are genuinely aligned with the advertised use case.

Suppose those checks point to an evidence gap: visitors can find the demo button, but cannot judge the integration before committing to a call. That is a working diagnosis, not yet a proven cause.

State a testable hypothesis

“For visitors comparing CRM compatibility, replacing the vague integration paragraph with a concise, product-verified explanation beside the existing demo action will increase qualified demo requests per eligible visitor, without increasing form failures or making the mobile page harder to use.”

The wording matters. It names the audience, the barrier, one coherent change, the outcome and the guardrails. It also allows an uncomfortable result: raw demo requests may fall if clearer information helps poor-fit visitors opt out. That could still be a better commercial outcome.

Choose the right test

If the page has enough relevant traffic for a sound comparison, use an A/B test: randomly show the current page to one group and the revised explanation to another. The current page is the control — the version you compare against. Keep the ad promise, destination, form and other major page elements steady. Agree the primary measure, eligible audience, run length and decision rule before looking at results. GOV.UK's A/B testing guidance explains the value of a control, a hypothesis, random allocation and sufficient users.

If traffic is too low, do not dress a handful of visits up as a statistically proven winner. Use interviews, task-based usability checks and a carefully monitored release to learn whether the explanation answers the real question. If the team finds a broken form or an inaccessible control, fix it directly; the defect does not need an A/B test to earn attention.

Decide, rather than celebrate a click

Track qualified demo requests against eligible page visitors as the primary outcome. Keep CTA clicks and form starts as diagnostic measures. Review form completion, meeting attendance and sales qualification when those signals become available. If the quality measure has a long delay, call the early report provisional.

Now the result can change a decision:

• Qualified requests improve and guardrails hold: consider rolling out the explanation, then monitor whether the effect lasts with different traffic.
• Clicks improve but qualified requests do not: the page became better at attracting a click, not demonstrably better at helping the right people progress.
• The result is inconclusive: keep the limit visible. Recheck the hypothesis, the traffic and the size of change the team could reasonably detect.
• Fewer poor-fit requests arrive with no loss of good ones: discuss the result with sales before calling it a failure. The page may have helped visitors self-select.

That last outcome is easy to miss when a dashboard rewards volume alone.

Measure the hand-off, not just the on-page action

A tracking plan should follow the journey's meaning. In Google Analytics 4 (GA4), an event is a recorded action. Google's recommended generate_lead event represents a submitted request for information; qualify_lead can represent a lead marked as a fit if the business sends that later CRM state back to Analytics. These events require deliberate setup and the right parameters; they are not proof of lead quality by themselves. See Google's recommended events.

A rate compares completed actions with the people or visits you measured. The completed actions are the numerator; the people or visits are the denominator. Is the rate based on all page views, unique visitors, eligible visitors from a campaign, or people who reached a particular step? Document how repeat visits and duplicate enquiries are handled. Otherwise two teams can report different “conversion rates” from the same journey and both appear correct.

Before trusting a test, make the event fire in a test journey and check its name and details in GA4 DebugView, which shows test events as they arrive. Google recommends DebugView and the Realtime report for confirming collection. Then check whether the form actually succeeds and the CRM receives the record. An event firing is not the same as a successful customer outcome.

Measure within the site's consent choices and privacy setup. Where analytics is unavailable or incomplete, record that limit instead of treating missing data as visitor behaviour.

Protect the page while you improve it

Conversion work can create friction when every team wants a persistent route to its own goal. A mobile page has limited space. A sticky CTA, chat launcher and consent control may each make sense alone and still compete with the form or final action together.

Test the complete page at narrow widths, with keyboard navigation and with the on-screen keyboard open. The Web Content Accessibility Guidelines (WCAG) set out checks that help people with disabilities use websites. In WCAG 2.2, the Focus Not Obscured (Minimum) criterion requires a focused control not to be entirely hidden by author-created content; W3C explicitly identifies sticky footers and similar layers as a common risk. The Target Size (Minimum) criterion sets a minimum size or enough space around things people tap or click, with exceptions. These are checks on the experience, not a certificate that a page is fully accessible.

Sometimes the best CRO change is to remove an action that does not earn its space. Sometimes it is to make an existing action easier to find. The page, audience and visitor task decide which.

A one-page CRO worksheet

Use this before opening an experiment tool or asking for a redesign:

1. Visitor job: What are people trying to decide or complete on this page?
2. Business outcome: Which completed action has value, and how will its quality be checked later?
3. Evidence: What do queries, page data, customer questions, usability checks and technical QA actually show? Mark assumptions separately.
4. Likely barrier: Is the issue visibility, comprehension, motivation or completion? What else could explain the same signal?
5. Hypothesis: For which audience will which change help, and why?
6. Comparison: Is this an A/B test, a usability study, a staged release or a direct defect fix? What is the control if there is one?
7. Measures and guardrails: Set the primary outcome, supporting events, denominator, data checks and mobile/accessibility checks before release.
8. Decision rule: What would make you ship, revise, stop or keep learning? Who owns that decision?

If the worksheet exposes a missing answer, that is useful progress. It is cheaper to find a weak premise on paper than after a page has been rebuilt.

Give the right action a place to live

Barrava brings selected CTAs, navigation, feedback and useful shortcuts into one configurable website toolbar. Teams can preview their chosen actions in Admin before explicitly publishing the bar. That gives marketers a controlled way to keep an appropriate next step available across a journey.

The toolbar does not decide which action is right, supply the evidence a page is missing or guarantee a conversion lift. Use the same worksheet on the bar itself: does this action help this visitor, on this page, at this moment? Does it remain usable on mobile? Does the resulting action lead to a useful outcome?

Explore the Barrava website toolbar if you want a more deliberate place for the actions that pass that test.

Sources and further reading

• Google Analytics: recommended events — definitions for generate_lead and qualify_lead.
• Google Analytics: verify and troubleshoot your setup — DebugView and Realtime verification.
• GOV.UK: A/B testing comparative studies — hypothesis, control, random allocation and inconclusive results.
• W3C: Focus Not Obscured (Minimum) and Target Size (Minimum) — relevant checks for persistent controls.
• Barrava: The Website Toolbar — current public product description and module examples.