End-to-end analytics in Bitrix24: where the data chain breaks
The chain “advertising → lead → deal → payment” almost never runs inside a single system. The ad account knows about the click and spend, the form or messenger — about the inquiry, CRM — about the lead, accounting — about the payment.
End-to-end analytics in Bitrix24 assembles these links into a single line, but only as long as the customer identifier is preserved at every junction. As soon as it is lost, the gap between advertising and deals turns into a blind spot.
The first break is the loss of lead sources. The tag does not arrive if the transition goes through a redirect or messenger, if the phone number is dictated during a call and the manager enters it manually, if the form on the page does not pass parameters to the record.
CRM is left with “direct entry” or an empty field, and there is no longer anything to attribute the inquiry to a campaign with.
The second junction is lead and deal accounting. Duplicates appear with repeat inquiries, with parallel work of the sales department and an auto-secretary, and with imports from spreadsheets.
The payment may then go through in 1C as a separate document without a link to the deal, and manual data transfer becomes the norm: the register is exported, matched by company name, and the source is entered by hand.
The price is management decisions based on incomplete data. A channel with expensive but rare deals looks unprofitable next to cheap leads without payments. We will look at how this is closed.
What changes after implementation: the effect in measurable terms
Before implementation, the source was known only for part of the deals: phone leads, messenger inquiries, and repeat inquiries went into “unmarked,” and the share of unattributed deals stayed around half of the funnel.
Customer acquisition cost was calculated as an average — channels with a long cycle looked more profitable than they actually were.
After the link is assembled, the share of deals with an identified source reaches 85–95%: the touch is recorded on the first visit, linked to the lead by phone or email, and carried over to the deal when it is created in Bitrix24.
Payments and shipments from 1C are pulled into the same chain, so deal attribution does not break at the closing stage.
The time to prepare a summary is reduced from several hours of manual sampling to a regular report: data from ad accounts, CRM, and the accounting system is collected on a schedule, and the manager views a ready-made breakdown by channel and manager. Manual consolidation remains only for reviewing disputed orders.
A separate effect is discrepancies between systems.
Reconciliation by order number and amount removes a whole class of errors when a paid order exists in the accounting system but is not visible in CRM, or vice versa: such records surfaced at the end of the month and distorted both the number of deals and customer acquisition cost.
Ways to link advertising to deals in Bitrix24
Advertising can be linked to a deal in several ways, and they are not mutually exclusive. The choice depends on the number of channels, the presence of calls, and whether you are ready to maintain the link on your own.
| Option | When it fits | Limitations |
|---|---|---|
| Manual link tagging (UTM) | One or two channels, all traffic goes to the website | The tag is lost when moving between devices and on offline touches, and breaks when campaign names change |
| Uploading reports from ad systems | A breakdown of spend and clicks is needed without custom development | Data arrives with a delay and is not linked to a specific deal — only to an ad group |
| A ready-made analytics module inside the system | A quick start with a standard scenario is needed | Rigid attribution logic: non-standard funnels and custom matching rules are not supported |
| Telephony with call source detection | A significant share of inquiries are calls | Covers only calls; messenger conversations and form submissions remain outside the link |
| Custom data exchange via an application | Many channels, custom attribution and matching rules | Requires maintenance: changes in external systems and exchange errors need to be monitored |
In practice, a combination is more often assembled: tagging provides the primary source, a module or custom application carries it through to the deal, and telephony covers calls.
There is one criterion — whether the source reaches the deal record rather than remaining in the inquiry report.
How we implement: from source audit to regulations
End-to-end analytics in Bitrix24 breaks not at the reporting stage but at the input: if an ad click did not reach the deal, no dashboard will restore the source.
Therefore, the cycle goes strictly bottom-up — first data and access, then the linking logic, and only then the revenue dashboard.
- Data source audit. We collect all inquiry entry points: forms and chats on the website, telephony, messengers, manual manager requests, deals in CRM, invoices and payments in 1C, and ad system accounts. For each source, we record which identifiers it provides and at which step they are lost.
- Designing the linking scheme. We choose an end-to-end identifier — click tag, phone number, or e-mail — and describe the rule by which the inquiry, deal, and payment are assembled into a single chain. We separately define behavior with incomplete data and with disabled tags.
- Setting up entity matching. We bring reference data to a unified form: phones and emails into one format, duplicates, different spellings of campaign names, and repeat inquiries from the same customer. This is the most labor-intensive stage — without it, the report starts splitting one customer into three.
- Test run on closed deals. We take historical deals with an already known outcome and compare: the system must show the same source and the same amount as the actual payment. We resolve discrepancies to zero until the logic matches across the entire sample.
- Testing on live traffic. We run real campaigns and observe how tags, redirects, and identifier retention behave. We monitor the share of inquiries without a source — it should go to a minimum rather than “dissolve” in the report.
- Handover of regulations. We provide instructions: how to tag new campaigns, what to do when the tag scheme changes, who is responsible for data quality, and how to reconcile the report with payments monthly. We also upload history so analytics does not start from scratch.
After this, the report can be read as a financial document: each campaign is tied to revenue, and discrepancies are explained by a specific rule rather than a “data peculiarity.”
Configurations, schemes, and regulations: what remains with you
After delivery, the settings remain not in a chat thread or in the engineer’s head, but in your environment: each link has an owner, a description, and a rollback point. Below is the tangible result that we hand over following an end-to-end analytics project in Bitrix24.
- Matching rules. Which advertising tagging parameters are attached to the deal, how inquiries without a tag are processed, and what to do with a repeat request from a second source.
- Data flow scheme. Sources, intermediate storage, destinations, and points where the flow may break — with notes on where to look when there is a discrepancy.
- Export and schedule settings. Exchange frequency, historical data depth, behavior when a source is unavailable, and catch-up of a missed interval.
- Role-based access rights. Who sees summary breakdowns, who can change matching rules, who only reads reports — without a single shared account for everyone.
- Instructions for employees. Short guides for marketing, the sales department, and management: what to check in their area and whom to contact when there is an anomaly.
- Reconciliation regulation. How often we reconcile data with primary sources, who is responsible for the procedure, and at what discrepancy threshold a review is triggered.
- Change log. History of edits to rules and settings with date and author — it is clear after which change the numbers shifted and how to roll back.
Case study: how the share of unattributed deals was reduced
The client had leads coming from several channels — contextual advertising, social networks, messengers, and partner referrals.
Some deals were entered manually by managers in Bitrix24, while others came through forms without tags, so the source was either missing or set “by eye.” In this picture, advertising costs could not be linked to revenue.
What was the situation
At the start, we measured three indicators. The share of unattributed deals was a third of all closed deals: from them it was impossible to tell which channel brought them.
Manual summary by source took the marketer two working days per month, and reconciliation of data between ad system exports and CRM produced discrepancies on roughly every eighth deal.
We assembled a unified accounting loop: all entry points — website forms, calls, chats, manual creation — pass through common source assignment rules.
The system saves the transition identifier, and if the tag is lost, substitutes the last-touch source and marks the deal for review.
Data reconciliation with ad systems runs on a schedule, matches dates, amounts, and transition identifiers, and places discrepancies into a separate queue for review.
Metrics before and after
The share of unattributed deals fell from a third to 4% — only isolated inquiries without an incoming touch remained, such as a call from an old business card. The summary is built automatically: the marketer spends 15–20 minutes on review instead of two days.
Reconciliation discrepancies are less than 1%, and each is reviewed on the day it is found, not at the end of the month. Channel reports from marketing and the sales department now match, so decisions are made based on a single picture.
What to do if the funnel is already deployed but the data is dirty
A deployed funnel does not prevent embedding linking — it prevents cleaning your own data “head-on.” Therefore, the loops run in parallel: new deals are written to the clean loop, accumulated history is processed separately, and sales do not stop.
During the transition period, we build reports with a cut-off date — otherwise the numbers change before the sales department’s eyes, and trust in them is lost faster than it is restored.
The review order is from reference data to deals. First campaigns and tags: duplicate sources, variant spellings, empty values. Then contacts and companies — this is where most deal duplicates sit, when a customer is created through different emails or phones. And only then the deals themselves: merging top-level entities changes their links.
We look for deal duplicates by a set of attributes: matching contact, closeness of creation date, overlap in amount.
We do not delete deals but merge them into a master deal with touch transfer and preservation of the change log — deletion erases history, and rollback becomes impossible. For lost sources, the rule is strict: no data — we set “source not identified,” not a guess by analogy. One incorrectly assigned source damages the report more than an empty field.
Before mass processing, we fix two rules: the merge key and field priority in a conflict — which value is considered correct. In Bitrix24, this is set by links and processing logic in advance, before the first pass.
If the rules change on the fly, repeated cleaning breaks the links already built, and the work has to start over.
Technical concerns and frequently asked questions
At this stage, technical concerns usually relate to junctions rather than the link itself: where revenue accounting is kept, how inquiry channels converge, what to do with untagged traffic, and who is responsible for data correctness after launch.
Revenue accounting is kept in 1C — will data have to be duplicated manually?
No. The deal and payment are closed in the accounting system, and the status and amount are returned to Bitrix24 — revenue is calculated based on the actual closing, not a manager’s mark, so no discrepancies with accounting arise.
Telephony and request forms run on different services. Will this get in the way?
No, if the inquiry has a merge key — phone number, email address, or dialogue number. A call, a website request, and a chat message are assembled into one deal, and we bring different field structures to a unified schema on the integration side.
Can it be implemented in stages without stopping sales?
Yes. First tagging and channel intake, then merging with the accounting system, then reporting: each stage delivers a working result, and the next one starts without department downtime.
Part of the traffic comes without tags — will reports distort the picture?
Untagged inquiries are not lost but fall into a separate group where their share and dynamics are visible. For messengers and offline points, we set up substitute numbers and short links — the share of unrecognized sources remains within a few percent.
Who is responsible for data correctness after handover?
We hand over a regulation: required fields, the procedure when a channel changes, and reconciliation of discrepancies with the accounting system.
For the first weeks, we support and adjust settings as needed; later we get involved for changes — a new channel, branch, or accounting scheme.
Let’s discuss the task: what data is needed for an estimate
For the estimate to rely on facts rather than general considerations, we need a minimum of initial data about how your customer journey is structured. Cleaned-up documents are not required — lists, screenshots of settings, and exports in working form will do.
Based on this set, we will return with an estimate, scope of work, and the order of implementing end-to-end analytics in Bitrix24.
- List of traffic sources — ad accounts, search engines, social networks, email campaigns, offline channels. It shows which tags are already in place and where tagging will have to be built from scratch.
- Systems for accounting inquiries and deals — CRM, website forms, telephony, messengers, email, sales department spreadsheets. This shows where the link between inquiry and sale breaks.
- Funnel structure — deal stages, their names, and the rules for moving between them. Without this, it is impossible to match a stage in CRM with a specific customer action on the website.
- Customer touchpoints — website, individual landing pages for advertising, chat, personal account, repeat inquiries. These are exactly where tags are placed and events for reports are collected.
- View access — ad accounts, CRM, web analytics systems, website control panel. Read-only mode is sufficient; settings do not need to be changed at this stage.
- Integration scheme and responsible parties — who owns the accounts, who confirms attribution rules, how data moves between systems now. This removes half the questions at the estimate stage.
- Constraints and preferences — which reports management needs, with what frequency, and whether there are requirements for history retention. We take these into account before work begins, not after.
If some data is missing, that is not a problem: describe how the process is structured now. We will suggest what needs to be added and show which reports can be assembled from the available sources.