CRO consultation: why there is traffic but no leads
The typical picture looks like this: impressions and visits are growing, while the share of target actions remains flat.
Each new hundred visitors brings the same number of leads as the previous one, and website conversion growth is limited not by reach but by the path between the first screen and lead confirmation.
The problem is almost never a single one — it is scattered across several points, and each quietly takes its share of people.
The first point is the first screen. The ad's promise does not match what the person sees on the page: the ad mentions the term, package, or warranty, while the headline has generic words about the company.
The visitor does not find confirmation within a couple of seconds, leaves, and the bounce rate grows in the most expensive area — where the traffic has already been paid for.
The second is losses in forms and submission steps. Hidden required fields, a strict phone format, an error without explanation, an extra confirmation screen — all this is visible only in measurements: the field is filled in, but the button is not clicked.
People are also lost between the second and third step when the lead form is split across several screens.
Funnel audit is the first step of a CRO consultation, and it begins not with edits but with step-by-step measurement: how many people reach each element, where the path breaks, which fields are abandoned.
Next come hypotheses and testing on a portion of traffic so that the decision relies on numbers, not taste. We break down how this works below.
What changes after working on website conversion
Conversion is not a single number but the product of step pass-through rates.
Therefore, after working on it, what changes is not «the site as a whole» but five measurable indicators: the share of those who reach the target action, the share of abandoned forms, the speed of hypothesis testing, lead quality, and the sustainability of the result — how long it holds after changes are released.
We take baseline values for each funnel step — usually 4-6 screens from entry to lead. We keep events and goals in Yandex Metrica so that the dispute «it got better» is settled by the before-and-after difference, not by opinion.
The economics of target actions without traffic growth
Reducing the share of abandoned forms from 68% to 41% with the same traffic yields almost twice as many leads — without additional investment in acquisition, because we work with visitors who have already arrived.
Next comes the pass-through rate of individual screens: there the typical increase is 10-25% per step, and it adds up with the effect on forms.
Classes of losses that stop recurring
What goes away is not one-off errors but entire classes: required fields that are not needed for lead qualification; loss of form state when a session breaks; a slow first screen on mobile.
The speed of hypothesis testing is a separate lever: with one split every two weeks, a dozen tests are completed per quarter; with orderly tracking, a hypothesis is tested in days.
Sustainability comes from the fact that a change lives in configuration, not in a one-off script: rollback is a setting switch.
Work formats: diagnostics, hypothesis sprint, ongoing support
The choice of mode is determined not by the scope of work but by how quickly the interface can be changed in the product and whether the team has a person who makes priority decisions. The three formats below differ in the frequency of change delivery and in who owns the task queue.
| Option | When it fits | Limitations |
|---|---|---|
| One-time diagnostics | Need to understand where users are lost and get a ranked list of edits with rationale | No testing cycle: you evaluate the effect of implemented changes yourself |
| Hypothesis sprint | Traffic is sufficient, there is enough to split into groups, need a stream of A/B tests with prioritization | Requires regular access to releases and analytics, several weeks of intensive work |
| Ongoing support | The product evolves continuously, conversion growth is a permanent metric | Justified with stable traffic: on small numbers, tests do not reach significance |
Modes with a continuous flow of changes
In the hypothesis sprint and in ongoing support, one mechanics works: analytics audit, then prioritization of hypotheses by potential contribution and testing cost, then A/B tests and analysis of results.
The difference is who owns the queue: in the sprint we manage it, in ongoing support we share it with your team, and changes go into releases along with other tasks.
When one-time diagnostics is enough
If traffic has not yet been accumulated or the site is being changed entirely, it is too early to run A/B tests — the sample will not be enough for a significant conclusion, and parallel edits will interfere with each other.
Then diagnostics covers the analytics audit and funnel analysis: the output is a prioritized list of changes with expected effect, which you implement at your own pace.
How implementation proceeds: stages of work from audit to handover
We start with data, not hypotheses: the audit shows where the funnel loses users and which analytics numbers can be trusted. Next is a sequence of stages, after which the team is left with working measurements and a test plan, not a one-off report.
Agreeing on the measurement scheme
- Analytics data reconciliation: we compare the tracker with CRM exports and logs, explain and eliminate discrepancies before testing starts.
- Funnel map: we mark up steps from entry to target action and find places where user drop-off is not explained by price or interface error.
- Test scheme: the hypothesis, target metric, minimum sample size, and deadline are fixed in writing so that the result cannot be interpreted loosely.
Ensuring experiment purity
- Event tracking: we set up events, goals, and parameters, checking them in debug mode before launch, not after.
- Launch: we split traffic, monitor group evenness and the technical state of variants — if there is a failure, we stop the test rather than finish calculating it.
- Significance check of the result: we calculate at the pre-selected level and look at segments — overall conversion growth often hides a drop on mobile.
- Documentation handover: the funnel map, event specification, test log, and plan for next checks remain with your team.
The stages proceed sequentially but with feedback loops: if the significance check shows that tracking does not capture all steps, we return to the measurement scheme — the result must not be built on incomplete data.
Artifacts and regulations that remain with the client
A consultation on conversion growth makes sense when the result remains with the client's team, not in someone else's reports.
Therefore, we reinforce each conclusion with working artifacts: from them, a new analyst or developer can reproduce the decision logic without retelling or repeated questions.
- Funnel map: steps from the first visit to the target action and the contribution of each transition to overall drop-off.
- Tracking scheme: events, parameters, and goals with exact names — after any interface update, data is collected consistently.
- Hypothesis log: formulation, success metric, testing period, and outcome for each entry.
- Access rules: roles, permission levels, procedure for granting and revoking access for analysts and contractors.
- Report template: a fixed set of cuts so results read the same across different periods.
- Test stopping policy: conditions for early termination and the threshold after which the result is recognized as significant.
- Test documentation: variant configuration, period, sample size, decision made.
The hypothesis log and how to maintain it
The log is a working document, not meeting minutes. Each entry contains a hypothesis in a testable formulation, the main metric, the expected effect, and the closing date.
Failed tests remain in the log: they cut off repeated attempts and show which mechanics have already not worked on this audience.
Rules for access to analytics data
Access is granted by role and to the minimum necessary extent: the contractor sees aggregates and events but not personal customer data.
Each grant is recorded with the date and responsible person, and when the executor changes, access is revoked the same day — no open channels to data remain.
Case study: how conversion grew in a long choice cycle
The client is a service company where 3-4 people make the decision, and several months pass from the first visit to the site to signing the contract. The «visit → lead» metric was almost flat, although traffic and the number of inquiries did not change.
Losses accumulated not at the top funnel step but further along — between the lead, the follow-up contact, and agreement on terms.
What turned out to be the bottleneck
Events were tracked only upon form submission: a return to the site, reading the calculation section, and a repeat visit two weeks later were not reflected in reports.
The manager received the inquiry without context, the first call went to clarifying basic things, and the person who left to «think» received no touchpoint.
Tracking was rebuilt through Yandex Metrica: events for key steps, segments by number of visits, a separate goal for return.
| Funnel step | Before | After | Eliminated class of losses |
|---|---|---|---|
| Lead → contact | 1-2 days, without context | on the day of inquiry, with an interest map | inquiries lost in the queue |
| Return to «think» | no touchpoints | 2-3 touchpoints at the right moment | cooled interest |
| Agreement | one contact | materials for the second participant's role | refusal at the choice stage |
| Measurement | last click | events by funnel steps | blind spots in reports |
Hypotheses were tested in waves of 2-3 weeks, and a sustained shift began by the ninth week.
The share of leads reaching agreement grew from 19% to 32%, the time to first contact decreased from a day and a half to four hours, and «think» returns stopped being a blind spot — each such contact is now visible in the report and enters the workflow.
How CRO consultation differs from ordinary analytics
Analytics and conversion consultation answer different questions. Web analytics describes what has already happened: how many people came, at which step they left, what share reached the target action.
This is an accurate retrospective, but it does not answer the question «what exactly to change on the site».
Consultation begins where the report ends. We formulate a hypothesis immediately as a testable change on the site: move the delivery terms block higher, shorten the form, remove an extra submission step.
Then the hypothesis turns into a parallel test of two page versions, not an argument about tastes on a call.
The main difference between the approaches is in hypothesis testing. The report captures the current funnel and stops there. Growth work requires that each hypothesis receive a measurable answer: did the share of those reaching the goal grow or not.
If the shift is within statistical noise, we do not roll out the change — otherwise we optimize random traffic fluctuations rather than visitor behavior.
The second difference is responsibility for the result. The analyst is responsible for data correctness and clarity of the summary.
We are responsible for a measurable shift in target actions after changes are made on the site, so the work includes not only analyzing visitor behavior but also implementation, monitoring the correctness of measurements, and deciding what to keep and what to roll back.
The difference is visible in what remains with you after the work. After analytics — a report on the past period. After collaborative conversion work — implemented and verified changes on the site plus a queue of next hypotheses with clear priority.
Common doubts before starting conversion work
Doubts before conversion work are usually technical: whether there is enough data, whether trackers can be trusted, how to separate the effect of an edit from a seasonal spike. Below are answers to the ones asked most often.
We have low traffic — will a test show anything?
We calculate the sample size before launch — based on current conversion and the minimum effect that makes sense for the business.
If there is not enough traffic for two parallel groups, we proceed with sequential tests adjusted for seasonality, relying on micro-conversions: form steps, adding to cart.
Analytics is not set up or we do not trust it — can we still test?
First we check the reliability of the test: we compare Google Analytics data with logs and CRM, look for duplicate goals and lost sources, and run a test lead. Until the tracking reconciles, any A/B test turns into an argument — first we fix measurement, then we change pages.
How do we avoid confusing the effect of an edit with seasonality?
We keep parallel groups: some visitors see the old version, some see the new one, so seasonal growth lands in both. We take the test duration as a whole number of weeks, do not start on peak promotion days, and compare the result with the same period of the previous cycle.
Past changes gave a controversial result — should we repeat?
We analyze past measurements: whether edits overlapped, whether the sample was sufficient, whether the version changed midway. Often a «negative» result is explained by broken tracking — then we restart the hypothesis cleanly, and record a sustained zero in writing.
Let's discuss the task and come back with an estimate and plan
So that the estimate and implementation plan rely on facts rather than assumptions, we need access to current analytics and an understanding of which scenarios on the site are considered target.
The more accurate the initial picture, the faster we will come back with a timeline calculation and sequence of steps.
- The goal in understandable actions: what we consider the result — a lead, order, registration, call — and how it is recorded now.
- Access to reports on sources, behavior, and user steps for the last few periods, with viewing rights.
- Map of key routes: where traffic comes from and at which step the path to the goal most often breaks.
- History of tested hypotheses: what has already been tested, with what outcome, and what was rolled back — so as not to repeat what has been done.
- Constraints: legal requirements, regulations, mandatory blocks and texts that cannot be changed.
- Traffic volumes by channel — they determine how long it will take for an A/B test to accumulate comparable groups.
- Points of contact: who confirms priorities and accepts the result for each edit on the client side.
Describe the task — we will come back with a work estimate, a stage-by-stage implementation plan, and the criterion by which we will measure the result.
After approval, we open access and start: first of all, we capture baseline metrics so that there is something to compare changes against.
