Conversion Funnel Analysis for a 1C-Bitrix Online Store

Conversion funnel analysis: where an online store loses customers

Conversion funnel analysis begins not with a report, but with reconstructing the customer's actual path: how they reached the site, what they viewed, at which step they stopped.

In an online store on 1C-Bitrix, this path is broken down by events — catalog view, add to cart, proceed to checkout, order submission.

Each event is recorded, and the gaps between them reveal exactly where money is being lost, rather than where "something is wrong with the design."

Typical funnel drop-off points on such projects repeat from store to store. A customer fills their online store cart but abandons it at the delivery selection step because they couldn't find their city or timeframe.

Another reaches the order form and leaves when the system requires registration for a single purchase. A third fails to complete payment because the payment module returned an error, and the page said nothing about it.

Losses at checkout almost always concentrate in the last two steps — where the customer is already ready to pay.

A separate category is technical drop-offs, which in reports look like "the user changed their mind." A slow catalog response during filtering, a dropped session, a cart conflict with caching, an incorrect delivery cost calculation — all of this cuts off customers before they ever see the confirmation button. Conversion to order drops, but the cause lies not in marketing or pricing.

That is precisely why we build conversion funnel analysis on end-to-end data: we link visits, cart actions, abandoned and completed orders with technical logs and store settings.

This reveals which funnel drop-off points account for the main loss and what among them is fixed by configuration versus what requires reworking the checkout logic. Next, we break down how this is resolved on projects built on 1C-Bitrix.

What funnel analysis delivers: the effect in numbers

Funnel analysis begins not with a report, but with reconstructing the buyer's real path: which steps they go through from first touch to payment, exactly where they stop, and what they see at that moment.

In 1C-Bitrix this data already exists — in order placement events, the cart, status history, payment logs. We assemble it into a single picture, and it almost always diverges from how the business imagines the process.

The first measurable result is an increase in conversion to order. When it's clear at which step the main share of buyers is lost, the work is not "on the site in general" but targeted: we remove an unnecessary field, change the order of steps, fix the payment scenario.

The share of completed orders grows not through more traffic, but through those who already arrived and were ready to buy.

The second effect is a reduction in cart abandonment and faster checkout. Often the cause of an abandoned cart is technical: slow delivery calculation, an error when applying a discount, mandatory registration, hidden cost at the last step.

We find these spots from the data and remove the friction — checkout time shrinks, and the number of interrupted orders falls.

The third is repeat purchases and average order value. The funnel shows not only losses, but also the behavior of those who returned: what they buy a second time, which products pull add-on sales along with them.

Return and related-offer scenarios are built on this data, and average order value grows on the existing customer base.

We calculate all figures before and after the changes, over identical periods and segments, so the effect is visible in dynamics rather than in a one-off export.

Where exactly the funnel breaks on 1C-Bitrix

The funnel on 1C-Bitrix doesn't break at the "customer changed their mind" stage — it breaks earlier, at the infrastructure level.

A catalog with a large number of SKUs and multi-level properties starts serving pages in seconds, and some visitors leave before the page finishes rendering.

The metric lies at this point: a bounce looks like "wasn't interested," even though the person physically never saw the product.

The second typical break is the cart. Errors in discount recalculation, stock mismatches with the actual warehouse, "product unavailable" at the final checkout step.

The customer has already made their selection, added items, and got rejected — this is the most expensive loss, because motivation was at its peak.

The third layer is the link to the ERP system. Exchange with 1C runs on a schedule, and between exports, prices and availability live in two different realities.

An order goes into processing with outdated data, a manager calls back with apologies, and some deals simply never make it through.

Session loss deserves separate mention: aggressive cookie clearing, authorization conflicts between subdomains, cart reset when switching devices. The person comes back — and their order is empty.

We work on 1C-Bitrix and see these breaks in logs, not in analytics reports.

We look at catalog response time under load, cart error logs, the exchange schedule and logs, session behavior across different scenarios — and find at which step a specific percentage of visitors is lost.

Data Collection Methods: Comparing Approaches

The collection method determines which funnel steps you will see at all. The platform's built-in web analytics quickly shows transitions across catalog sections and checkout, but some events are lost: it has its own session model, and the data resides within the system.

External trackers provide an end-to-end view across channels and ad tags, but they are cut off by blockers and cannot see what happens on the server side.

Server logs record every request without loss, but they do not know who exactly came until you link them to a session identifier.

In practice, discrepancies between systems reach double-digit percentages, and the decision is made not from a single report but from reconciliation.

We reduce events to a common session identifier, match orders from the platform with tracker records and logs, and break down discrepancies step by step: where exactly the user is lost — on catalog filters, in the cart, or at payment confirmation.

The combined approach is more expensive to set up, but it is precisely what delivers a funnel you can rely on when making changes.

If traffic comes from a single channel and the funnel is simple, built-in tools with targeted refinements are enough — we work out which set will cover your task without extra layers.

How we conduct a funnel audit: stages of work

We start a funnel audit not with hypotheses, but with facts: we capture current metrics for each step — from entering a product page to placing an order.

We look at exactly where the share of users is lost: on catalog filters, in the cart, on the delivery form, or at the payment stage. Without these numbers, any change is a guess, not an engineering decision.

Then we work through stages, each ending with a verifiable artifact.

1. Capturing metrics. We export data from analytics systems and server logs, and reconcile goals with actual user actions. The output is a funnel map with conversion at each step and drop-off points.
2. Traffic segmentation. We divide visitors by source, device, and behavior type: new buyer, returning visitor, abandoned cart. The same step can lose different groups for different reasons.
3. Building hypotheses. We formulate what exactly is blocking the transition to the next step: slow catalog response, extra fields in the form, opaque delivery cost. Each hypothesis has a metric by which we test it.
4. Prioritization. We select changes based on the ratio of impact on conversion to effort. First, the ones that close major losses at the upper steps.
5. Implementing changes. We modify templates, cart logic, the order of checkout steps, and enable caching for heavy queries. Each change goes out as a separate release so the effect is measurable.
6. Verifying the result. We compare conversion before and after on comparable traffic, and filter out seasonal fluctuations. If a change didn't produce growth, we roll it back and return to hypotheses.
7. Handing over recommendations. We deliver the funnel map, the list of implemented changes, and a queue of next hypotheses with an estimate of the expected effect.

We repeat this cycle: after each iteration the funnel narrows at the bottlenecks, and decisions rely on measurements, not opinions. Describe your task — we'll come back with an estimate and a work plan.

What you get from the analysis

Based on the results of the analysis, you receive not abstract "recommendations," but a working kit that you can immediately use for edits and monitoring.

Each artifact covers its own area: one shows where money is being lost, the second shows why, the third shows what to do, and the fourth shows how not to lose the result a month later.

• Funnel report — an end-to-end picture across all stages: from entering the site to a completed order, with the conversion of each transition and a breakdown by source, device, and product category. You can see not only "where it dropped," but also how much this deviation is from the norm for your traffic.
• Map of drop-off points — the specific steps where users leave: cart, checkout form, delivery selection, payment. For each point — the share of losses and the technical cause: slow response, validation error, unclear step, session break.
• List of edits — a prioritized list of changes: what will produce an effect quickly and with low effort, and what requires reworking the logic or integration with 1C. With an estimate of the expected conversion uplift for each item.
• Configured reports — ready-made views in the dashboard: funnel by day, period comparison, abandoned cart report, breakdown by source. You view them yourself, without exports or manual assembly.
• Monitoring regulations — a document with the frequency of checks, threshold values, and a list of responsible persons. A conversion deviation by a specified amount is a signal, not a discovery a quarter later.
• Data schema — how events are linked between the website, analytics systems, and the accounting system, so that the numbers in the reports match actual orders.
• Hypothesis testing protocol — the procedure for making edits and the method for measuring the result, in order to separate the real effect from seasonal fluctuations.

We hand over the kit with a walkthrough: we go through each artifact, explain the calculation logic, and show how to read the reports on your own going forward. Describe the task — we will come back with an estimate and a work plan.

How does funnel analysis differ from end-to-end analytics?

Conversion funnel analysis answers the question "where exactly are buyers lost inside the store." We mark up the stages of a purchase — browsing the catalog, adding to cart, starting checkout, payment — and count the transitions between them.

The bottleneck is immediately visible: if the cart is abandoned at the step of entering delivery details, the problem is in the form, not in the advertising. The tasks of this analysis are local: remove friction at a specific step, simplify checkout, fix the filters.

End-to-end analytics looks wider — at traffic sources and their contribution to revenue. It links an advertising channel to an order across the entire chain of touchpoints: search, social media, email campaigns, repeat visits.

The question is posed differently: which channel brings in buyers, and which one burns budget on those who leave without a purchase. The tools here are different — web analytics systems with integration of ad accounts and store accounting data.

The difference in approaches is fundamental. The funnel works with behavior inside the site and does not see where a person came from. End-to-end analytics sees the source, but without marking up the stages it will not show at which step a channel loses a customer.

That is why they work best together: end-to-end analytics says which channel is worth scaling, and the funnel — what in the store prevents that channel from bringing in revenue.

In practice, we first build a funnel by purchase stages, find gaps in checkout, and only then connect end-to-end analytics to allocate efforts across traffic sources.

This order saves time: it is pointless to fix advertising while the cart is losing half of the buyers for no apparent reason.

Case Study: How Conversion Grew After Eliminating Drop-offs

What It Was Before

An online store on 1С-Битрикс with an assortment of several thousand items and live traffic. Analytics showed a flat picture: people come in, add items to the cart — and that's it.

The share of completed orders hovered around 1.2%, and out of every ten carts, nine remained abandoned. Checkout took an average of 6 minutes 40 seconds: the buyer went through registration with confirmation, a separate delivery step, and payment on the last screen.

The owner only saw the final sales figure and blamed the failure on "weak traffic." We broke the funnel down step by step and saw that the problem wasn't acquisition: people reached the cart but didn't make it through checkout.

What We Changed

First, we built an end-to-end funnel by events — from product page view to confirmed order, broken down by source and device type. The drop-offs were concentrated at two transitions: between the cart and the data form, and between delivery selection and payment.

Then we worked on specific points. Registration was replaced with checkout without a mandatory account — the buyer's data is saved in the order, and the account is created automatically.

The delivery and payment steps were merged onto a single screen, saved addresses and payment methods were pulled in, and re-entry was eliminated. The cart was made editable right during checkout: changing the quantity no longer throws you back to the previous step.

Separately, we set up abandoned cart recovery — an email with the saved order contents goes out after an hour and again the next day.

What It Became

The share of completed orders grew from 1.2% to 2.1% — nearly double the conversion on the same traffic. Average checkout time dropped to 2 minutes 10 seconds, and the number of abandoned carts over a comparable period fell by roughly 40%.

Some of the recoveries came from the emails: buyers who had left at the payment stage returned and completed their orders.

The result of the implementation rests not on a one-time fix but on a continuous cycle: the funnel is broken down step by step, each transition has a metric and an owner, and changes are tested on a portion of the traffic. Such a loop allows new drop-offs to be found before they eat into revenue.

Common technical concerns

Collecting data for conversion funnel analysis almost always comes down to three technical questions: will it break the current store, will it handle the load, and will it create risks for customers' personal data. Below is how we address each of these concerns in practice.

Will the server load increase and will the site slow down?

Event collection happens asynchronously and does not block page delivery: data is sent in a separate stream, not at the moment the catalog is rendered.

Heavy reports are calculated from aggregated slices, not from "raw" logs for every request, so peak traffic does not turn into a queue of requests to the database. We take a load profile before and after implementation — and compare the response time of key pages.

How is customer data security ensured?

Personal data does not leave the store's perimeter in an open form: anonymized identifiers and events go into analytics, not names, phone numbers, and addresses. Access to reports is role-based — marketing sees the funnel, but not personal data. All changes are recorded in a log, so it is clear who viewed or exported a slice and when.

How long does implementation take and is it possible to roll back?

We assemble the basic funnel in iterations: first the key checkout steps, then the secondary scenarios. Each stage is implemented separately and tested on real traffic, so an intermediate result is visible after the first iteration.

Rollback is safe: event collection is disabled independently of the store's logic, and the previous settings are preserved until the result is confirmed.

Let's discuss your task

To come back with an estimate and an implementation plan, we need context: how the store is set up now and exactly where customers are being lost.

Conversion funnel analysis doesn't start with reports — it starts with your description of the task: what steps a customer goes through from entry to payment, at what stage the drop-off is noticeable, and what you've already tried changing.

The more specific the inputs, the more accurate the estimate of work and the fewer iterations for approval.

Describe the task — and we'll come back with an implementation plan that shows which data we collect, which hypotheses we test, and in what order.

If during the review an engineer's consultation is needed on a contentious point, we'll bring them into the discussion so the decision is based on facts, not guesses.

What's useful to send in the first message:

• which funnel steps are already instrumented and how conversion between them is calculated;
• where, based on your observations, the main drop-off is — entry, cart, checkout, payment;
• which events are tracked and whether there is end-to-end analytics by source;
• how the cart and order checkout are set up, and whether there are abandoned carts;
• which integrations are tied to the order — payment, delivery, warehouse, CRM;
• what you've already changed and what result that produced;
• what constraints there are on timelines and on access to systems.

This is enough to estimate the scope of work and propose a phased implementation plan. Then we'll agree on the order: first we collect data and test hypotheses, then we make changes and measure the effect on the same metrics. Describe the current situation — we'll come back with an estimate and a plan.