Custom Bitrix24 report development: cohorts, LTV, ABC analysis

Why standard Bitrix24 reports do not answer business questions

Standard Bitrix24 analytics answers the question "how many deals were closed in a period," but almost never the question "which clients bring profit over the long haul." The funnel and sales total are calculated at the moment of closing, while repeat purchases, refunds, and long-stretched cycles remain out of frame: one client's deal is not linked to their next deal, and the retention picture falls apart. This is the first limitation of built-in analytics — aggregates without cohorts.

Cohort analysis is not built into Bitrix24 as standard: the system does not group clients by the month of their first purchase and does not show how each group behaves afterward.

Without this, it is impossible to calculate client LTV by segments — by source, by manager, by product type.

The average order value is visible, but it is not visible that clients from one channel return three times more often, while those from another bring a one-time deal and leave.

ABC sales analysis hits the same wall: standard reports do not rank clients and products by their contribution to revenue with cumulative shares, do not single out the group that provides the bulk of turnover, and do not highlight the tail that consumes support resources. A manager sees the total amount but does not understand whom to rely on and whom not to depend on.

A separate problem is data lag and fragmented sources.

Part of the activity lives in the CRM, part in the accounting system, part in external services, and bringing them together into a single report with built-in tools is not possible: the numbers arrive late and do not reconcile between sections.

Custom Bitrix24 reports close exactly this gap — they collect data from the CRM and the accounting loop, link one client's deals into a single history, and calculate cohorts, LTV, and ABC where built-in analytics stops.

What custom reports deliver: the effect in numbers

Standard Bitrix24 reporting answers the question "how much did we sell," but not "which clients bring profit and which eat it away." A custom report gathers data from deals, invoices, and touch history into a single data mart — and turns scattered tables into a management picture you can make decisions on rather than guess about.

Reporting speed

Manual export and reconciliation in spreadsheets means hours of analyst work for every request and a constant risk of copy errors.

A report built on regularly refreshed data delivers an up-to-date snapshot in minutes: cohorts by month of first purchase, retention dynamics, average order value by segment. A manager gets an answer at the moment of the question, not by the next planning meeting.

Segmentation accuracy and LTV

Segmentation by industry, deal size, and acquisition channel is built on uniform rules rather than manual filters — the same client won't fall into two overlapping groups.

LTV is calculated from the actual history of repeat purchases, taking into account customer lifetime, so priority goes to channels that bring in long-term clients rather than one-time buyers.

Identifying unprofitable clients

ABC analysis by revenue and margin reveals groups that are invisible in the total sum but demand a disproportionate amount of resources: frequent rework, lengthy approvals, low margins.

Such clients stop being "background" — they show you where to change the terms of engagement or revise the pricing tier.

Analytics automation

Reports refresh on a schedule and go to the responsible people in a convenient form — a summary by email, a dashboard in the workspace. The analyst stops being a "report factory" and focuses on interpretation rather than gathering numbers.

Approaches to Building Reporting: Comparing the Options

Standard reports cover the basic slices: funnel, activity, workload by employee.

As soon as you need cohort-based calculations, cumulative LTV, or ABC segmentation of the customer base, the report builder falls short — it cannot join deals with payment history and data from the accounting system.

From there, the choice comes down to three scenarios, and each runs into its own class of limitations.

Where the line is drawn

An external BI system wins when a dedicated team handles analytics and there are many sources. But data arrives there with a lag, and access permissions have to be synchronized manually — a manager sees the numbers somewhere other than where they make decisions.

Why on-portal development is chosen more often

Developing reports inside the portal keeps the calculation next to the data: cohorts, LTV, and ABC are calculated based on the current state of deals, integration with 1С pulls in payments and cost of goods, and permissions are inherited from employee roles. Heavy queries go into precalculation, so the interface stays responsive.

Let's figure out which option solves your task.

Stages of custom reporting implementation

Implementation of custom Bitrix24 reports begins not with a dashboard, but with an inventory of sources: deals, smart processes, tasks, calls, invoices, reference books.

At this step, we record which fields are actually filled in, where duplicates and gaps are, and how entities are related to each other. Without this, any report is built on sand — the numbers add up in the demo and diverge on production data.

Next, we design the reports themselves: we agree on metrics (LTV by cohorts, ABC by customers and products, funnel by managers), the calculation period, and the rules for assigning to a group.

Only after the logic is approved do we move on to the technical part — exports, aggregates, and the update schedule. This order saves weeks: edits to the logic at the design stage cost hours, while reworking a finished report costs days.

1. Data audit. We check the completeness and quality of fields in the CRM, smart processes, and the accounting system, find duplicates, empty required fields, and discrepancies between sources. The output is a data map and a list of what needs to be cleaned up before the start.
2. Report design. We agree on the set of metrics, dimensions, filters, and frequency. We formalize the calculation formulas so that the business and the development team have the same understanding of each number.
3. Setting up exports. We collect data from Bitrix24 and 1C, set up regular updates and storage of aggregates. We move heavy calculations out of the interface so that reports open quickly even on large volumes.
4. Development and visualization. We build reports in the Bitrix24 interface or in an external panel — depending on who uses them and how often. We set up access rights by role.
5. Testing the reporting. We reconcile the numbers with primary data and manual selections, and check edge cases: empty periods, new customers, returns. A report is considered ready when discrepancies are explainable, not "roughly similar."
6. Handover of solutions and training. We hand over documentation on metrics and the update schedule, and show the team how to read the reports and what to do when there is a discrepancy. After that, the reporting lives on without the constant involvement of the development team.

Describe which metrics your business needs — we will come back with an estimate and a work plan for each stage.

What the client receives: composition of deliverables

The result is not "access to a dashboard," but a complete package that works without us: reports in your portal, a documented data schema, and a regulation according to which they are updated. Below is exactly what we hand over and why each artifact is needed.

• Ready-made reports in Bitrix24 — cohort analysis by month of first deal, LTV by customers and segments, ABC breakdown by revenue and margin. Each report opens from the portal interface; filters by pipeline, responsible person, and period are configured without editing code.
• Data schema — a map of sources: which fields of deals, invoices, and reference books participate in the calculation, how entities are related, where the date of first purchase comes from, and how revenue is calculated. Using it, a new analyst or your developer will understand the logic in an hour, not a week.
• Update regulation — the recalculation schedule, the launch window, behavior in case of failure, and the procedure if data for a period has changed retroactively. We separately document what happens to already-built cohorts when a deal is canceled.
• Metric documentation — the definition of each figure: what goes into LTV, how retention is calculated, which deals are excluded from ABC. This eliminates the main dispute in reporting — when two departments show different amounts for the same customer.
• User guide — how to build a slice for yourself, which filters to change, and where to look for discrepancies with the source data.
• Accesses and roles — who sees the full report, who sees only their department, and how export is restricted.
• Support plan — what we check after portal updates and how we add new metrics when the sales model changes.

We hand over the package in your environment: the calculation source code, configuration, and documentation remain with you. Describe the task — we will come back with an estimate and a plan for your set of metrics.

Case study: how cohort analysis revealed customer churn

The client is a wholesale company with repeat sales and a deal cycle starting at two weeks. Reporting in Bitrix24 showed only revenue for the period: the numbers were growing, but the share of customers returning for a second purchase was falling.

It was impossible to connect these two facts in the standard reports — there was no breakdown by the month of the first purchase.

What we did

We built a custom report that groups customers into cohorts by the month of the first deal and calculates for each one: the share returning for a second, third, and subsequent orders, the average interval between purchases, and LTV by segment.

We pull data from deals, invoices, and payments, so the cohort is recalculated every time a deal is closed, rather than manually once a quarter.

Separately, we broke customers down by ABC: segment A generated the bulk of revenue, but it was precisely in this segment that the drop in repeat sales turned out to be the deepest — customers left after the second purchase, and in terms of revenue this was masked by the influx of new ones.

What changed

Churn stopped being an abstraction: it became clear in which month after the first purchase a customer goes silent, and working with them becomes a routine — a reminder, an upsell, a personalized offer before that deadline arrives.

How is cohort analysis different from ABC analysis in Bitrix24?

Cohort analysis answers the question "when and how customers churn," while ABC analysis answers "who is generating the bulk of revenue right now." These are two different slices of the same base: the first is built by time, the second by contribution to turnover.

A cohort is a group of customers united by the date of their first purchase or registration: for example, everyone who placed their first order in the same month.

Within a cohort, we look at what share returns in the second, third, sixth month, and how their average order value changes. This shows whether retention is deteriorating from batch to batch and at which step customers stop buying.

ABC analysis slices the base differently — by the accumulated share of revenue or margin. Category A is a small core that generates the bulk of turnover, B is the middle, C is the long tail with low contribution.

There is no time here: a customer falls into a group based on their purchases over the selected period. The method clearly shows who you cannot lose focus on and where a bloated base creates a load on managers.

The power emerges when they are used together. First, ABC divides customers by value, then each group is broken down into cohorts by acquisition date.

And then you see what is hidden when they are used separately: for example, that the core of category A was formed from customers of a single period, while recent cohorts almost never make it into A — meaning the inflow of large customers has weakened.

Or that the C tail returns steadily but with a minimal order value, and it is more profitable to move it to self-service.

In Bitrix24, such reports are built on top of deals, contacts, and companies: the date of the first successful deal sets the cohort, while the amount and stage determine the contribution to ABC.

The built-in analytics does not assemble these slices, so we move the calculation logic into a custom report with configurable periods and filters by pipelines.

Common technical questions about custom reports

A custom report is not a separate system but a layer on top of the portal's data, so all customer concerns boil down to four topics: load, data freshness, integration with the accounting system, and cost of ownership. Below is a breakdown of each without marketing.

How fresh is the data that ends up in the report?

It depends on the task: we update operational slices every 15-30 minutes, and recalculate cohorts and LTV once a day, when the data for the previous period has already settled.

We fix the schedule and the recalculation depth in settings rather than in code — if needed, we change the frequency without reworking anything. The report always shows the date of the last recalculation, so the manager understands what data they are basing a decision on.

How does the report connect to 1С, and will the accounting data diverge?

The exchange follows a defined procedure: deals, payments, and reference data are pulled from 1С, and we fix the matching keys at the start.

We catch discrepancies by reconciling control sums — if the amounts across documents do not match, the report flags the period as unreconciled instead of silently substituting incorrect figures. This way, accounting and the commercial department look at the same data.

What happens to the report when the funnel or the structure of reference data changes?

We keep the calculation logic separate from the interface and describe it in configuration, so a new field or stage is added by editing settings rather than rewriting the report.

Old periods do not "drift" in the process: historical slices are stored in the form in which they were built. Support comes down to scheduled checks and targeted edits — without ongoing developer maintenance.

If a concern is not resolved — describe the task, and we will come back with an estimate and a plan: we will show what data is needed, where it resides, and how the report will fit into the portal's current setup.

Let's discuss your custom reporting task

To make the report actually work rather than become "just another export that nobody opens," a few questions need to be cleared up at the start. They determine the data structure, the calculation method, and how the report will live on.

• What decisions are made based on these numbers: procurement planning, churn management, manager performance evaluation, funnel revision?
• What sources do we pull data from — deals, invoices, payments, calls, tasks, external systems — and are there discrepancies between them?
• How do we calculate cohorts and LTV: by the month of the first deal, by payment date, accounting for repeat sales and refunds?
• Are breakdowns needed by business lines, branches, managers, acquisition channels, and how are they linked in the reference data?
• Who views the report and how often: a manager once a month, the sales department daily, an export to an external system on a schedule?
• What data must not be shown to some employees — are role- and department-based restrictions needed?
• What already exists now: standard reports, spreadsheets, manual summaries — and what exactly is unsatisfactory about them?

Based on the answers, we determine what to calculate in real time and what to recalculate on a scheduled basis, where a separate storage layer for aggregates is needed and where a query to deals will suffice.

Then we come back with a project estimate and a work plan: stages, data scope, acceptance milestones, and the procedure for refinements after launch.