Offline conversions don't make it to analytics: where the link breaks
Most often, the link breaks not at the setup stage, but at the matching stage: there's a deal in the CRM, a visit in analytics, and no common identifier between them.
A client came from an ad, submitted a request, and the manager created the deal manually a day later — and that's it, the chain is broken. Google Analytics sees only a session without a result, while Bitrix24 sees a result without a source. In channel reports, such deals end up in "direct traffic" or aren't counted at all.
The second gap is temporal. An offline conversion inherently lags behind the visit: a call is handled an hour later, a deal is closed a week later, payment — a month later.
By the time the event reaches analytics, the attribution window is already closed, and the system attributes the conversion to the wrong channel that actually brought it.
This is especially noticeable with long B2B deals, where months and several touchpoints pass between the first touch and payment.
The third source of distortion is manual statuses.
If the funnel in Bitrix24 isn't rigidly tied to the stages "qualified, approved, paid," and managers move cards at their own discretion, then what goes into analytics isn't the fact of a sale but a subjective assessment.
End-to-end analytics starts counting as a conversion something that isn't one, and channels receive false attribution — budget goes where there are many requests but no money.
The fourth layer is technical: the click identifier (gclid, client_id) isn't saved in the deal, and without it Google Analytics can't stitch an offline event to a specific visit.
The Bitrix24 Google Analytics integration at this point requires not a plugin but discipline in passing identifiers from the form to the CRM and sending statuses back via Measurement Protocol. Let's break down how this gets closed.
What the integration delivers: measurable effects for the sales department
When a deal from the CRM lands in analytics as an offline conversion, the sales department stops working blind. Previously, the customer journey broke off at the lead: the form was submitted, but what happened to it next — whether the deal closed or not — analytics did not know.
Now every closed deal returns to reporting tied to the source, campaign, and keyword, and decisions are made based on actual money, not on the number of clicks.
Deal attribution changes the picture of channels. A channel that generated many cheap leads but almost never brought in payments is finally visible in the report alongside a channel that brought in fewer leads but with a high closing rate.
This makes it possible to redistribute effort and budget toward where leads turn into revenue, not just a row in the CRM.
Lead quality becomes measurable rather than a matter of opinion. It is clear which campaign brings in customers who reach payment, and which one brings in inquiries that the sales department closes with a rejection on the first call.
The cost of acquisition is calculated by deals, not by leads, so it reflects the real economics of sales rather than an intermediate metric.
Channel reporting stops diverging between marketing and sales: both sides look at the same data, where offline deals are reconciled with online sources.
The argument "marketing brings in garbage" or "sales can't close" is replaced by an analysis of specific channels and funnel stages.
Data Transfer Methods: Comparison of Options
Transferring offline conversions from Bitrix24 to Google Analytics is based on one principle: an event in the CRM is matched to a session on the website via a client identifier, and that match is then sent to analytics.
What differs is the delivery method — from near-instant transfer via webhooks to regular batch data exports. The choice determines how quickly a conversion appears in reports and how much manual work remains on the team's side.
| Method | When it fits | Limitations |
|---|---|---|
| Event-based webhooks | Offline conversions need to be transferred almost immediately after a deal stage changes; the event stream is moderate | Requires reliable ingestion on the analytics side: if unavailable, events are lost, so a retry queue and delivery log are needed |
| Scheduled data export | Large volumes, once-a-day reporting is acceptable; important not to load the CRM during peak hours | Delay between the deal and its appearance in the report; if an export window fails, data is caught up by the next run |
| Manual export from CRM | One-off audit, reconciliation of historical deals, hypothesis testing | Does not scale, high risk of duplicates and discrepancies with the automated stream |
| Transfer via an intermediate storage | Multiple sources and analytics systems, a single point for identifier normalization is needed | More expensive to maintain: another service appears that must be monitored and updated |
What to look at when choosing
The key risk is client identifier desynchronization: if it is stored in one form in the CRM and collected in another on the website, matching produces false positives or misses.
That is why in any option we first fix the normalization rule and only then choose the delivery method.
The second factor is idempotency. Re-sending the same event must not double the conversion, otherwise reporting loses its meaning. Webhooks and exports are configured so that each event has a unique attribute and re-delivery does not create a duplicate.
What this gives in practice
When offline conversions are transferred via webhooks, data in reports lags by minutes; with a scheduled export, by hours.
The difference is critical if ad management relies on analytics: fresh data allows channels to be reallocated faster, while a daily delay leaves decisions based on an outdated picture.
We usually combine methods: webhooks for current deals and a scheduled export as a safety net that catches up on what was missed. Describe your funnel and deal volume — we will come back with an estimate and a plan for each method.
How we implement the integration: stages of work
We start with an audit: we look at which goals are already set up in Google Analytics, how forms and buttons on the site are tagged, and which deals in Bitrix24 are closed manually and therefore never make it into analytics.
At this stage we identify the gap between marketing data and actual sales — that is exactly what distorts channel evaluation.
Implementation stages
- Audit of the current integration. We reconcile the list of goals with the deal funnel, check the correctness of identifiers (Client ID, User ID) in web forms and leads from messengers, and find the sources where the connection is lost.
- Designing the transfer scheme. We determine which deal stages should count as offline conversions, how to match an event with a session, and which CRM fields go into the report. We agree on the rules with your sales team so that "qualified lead" means the same thing to everyone.
- Setting up data transfer. We configure the export from Bitrix24 into analytics: we link closed deals to the original visit, set up the schedule and retries in case of failures, so that not a single conversion is lost.
- Testing. We run control deals through the entire funnel — from lead to payment — and check that the event arrived with the correct source and amount. We separately test the rollback: if the transfer failed, the data should be reloaded, not duplicated.
- Reconciliation with CRM. We compare the number of conversions in the report with the number of deals in Bitrix24 for the same period. If the discrepancy exceeds the acceptable threshold, we look for the cause until the numbers match.
- Documentation. We hand over the data flow scheme, the list of goals and stages, the verification procedure, and instructions for the marketer: how to add a new goal or change a rule without a developer.
What you get as a result
After implementation, reports show not leads but money: you can see which channel brings deals that reach payment, and which one brings only clicks. From there, the integration can be expanded — adding new sources and stages without rebuilding everything from scratch.
What you keep after implementation
After implementation, you are left not with "a set of settings in someone else's account," but with working documentation that any of your engineers or marketers can use to maintain the Bitrix24 and Google Analytics integration.
We hand everything over within your environment: the repository, access credentials, descriptions — nothing remains on our side.
- Integration diagram — the data flow from a deal in the CRM to uploading an offline conversion into Google Analytics: which events and at which funnel stages are sent, how customer identifiers are matched, and exactly where mismatches are lost.
- Transfer configuration — the working export settings: the list of deal stages and fields, mapping rules to goals, the schedule, and the conditions for resending on failure.
- Maintenance procedure — who does what when the funnel changes, a new stage is added, or attribution rules change: step by step, with responsible parties and checkpoints.
- Diagnostics guide — how to figure out within 10-15 minutes why a conversion didn't arrive: where to look at the send log, how to reconcile a deal in the CRM with an event in analytics, and which errors are typical.
- Data mapping map — a table matching CRM fields to event parameters, so that during further development you don't have to guess what maps where.
- Acceptance checklist — a set of checks by which you accept the work: a test deal goes through the entire path, the report shows the conversion, and a rollback restores the previous behavior.
- Access and roles — what and to whom it is granted, which keys and tokens are used, where they are stored, and how they are changed without downtime.
All of this is described so that six months later, when the funnel changes, you won't have to figure out from scratch how the transfer works. Describe the task — we'll come back with an estimate and a plan, including the composition of the artifacts to be handed over.
Case Study: How Offline Conversions Changed Reporting
The client is a chain of several showrooms with online inquiries and in-store sales. Deals in Bitrix24 were closed by managers manually, while web analytics system reports only accounted for inquiries from the website.
Because of this, the channel that brought in inquiries with a long decision-making cycle appeared unprofitable, and activity on it was cut back.
We mapped the customer journey: website inquiry → call → showroom visit → deal. We linked the CRM and web analytics by click identifier: when a visitor landed on the website, they were assigned an identifier, which was also saved in the deal card.
When a manager moved a deal to successful, the system sent an offline conversion to analytics with that identifier and the deal amount. We separately configured the transmission of returns and cancellations — so that reporting would not overstate results.
What Changed in Reporting
Before implementation, reports showed 38% of actual sales — the rest was "lost" between the inquiry and the deal being closed in the CRM.
After configuring offline conversion transmission, coverage grew to 94%: reports began accounting for deals closed weeks after the first contact as well.
The channels reshaped into a different picture. The share of inquiries with a long cycle nearly doubled in reports, and one of the channels that was considered weak emerged as the leader by number of closed deals.
Decisions on allocating activity began to be made based on actual sales rather than the number of inquiries.
What the Link with Return Accounting Delivered
Cancellations and returns now reduce a channel's result instead of remaining out of the picture. The discrepancy between analytics reports and CRM data shrank from 40% to 6% — the figures in the report for management and in the CRM became comparable.
Repeat sales to existing customers were also attributed to the original channel. This showed that part of the revenue comes from customers who arrived via channels previously considered ineffective — and their contribution became visible in reporting.
The project was implemented on Bitrix24 with data transmission to web analytics systems.
How is offline conversion tracking different from end-to-end analytics?
End-to-end analytics answers the question "which channel brought the customer," while offline conversions answer the question "what happened to that customer after they left the site." These are two different layers of data, and confusing them means building reporting on an incomplete picture.
End-to-end analytics links the traffic source to an action on the site: an ad click, a transition from search, a visit via a link from an email.
An offline conversion records an event that happened outside the browser: payment by invoice, signing a contract, a call to the sales department, a repeat purchase through a manager.
The difference shows up at the moment when the deal is closed not on the site. The customer submitted a request, a manager worked with them for a week, the payment arrived in the settlement account — for the web analytics system, this path breaks off at the form.
End-to-end analytics will show the source of the request, but will not show that the deal took place and how much it brought in. The offline conversion closes this gap: the event from the accounting system returns to analytics and is tied to the original traffic source.
Technically, it works like this: in Битрикс24, the deal stage is recorded; upon transitioning to the target stage, the system generates a customer identifier and sends the event to analytics. The identifier links the closed deal to the ad click or visit that generated it.
Without this link, advertising channels are evaluated by requests rather than by revenue — and the decision to reallocate budget is made on incorrect data.
When each approach is needed. End-to-end analytics — if the deal cycle is short and closes on the site: an online store, online payment, a quick purchase. Offline conversions — if between the request and payment there is a manager's work, an invoice, a contract, lengthy approval.
In practice, both layers work together: end-to-end analytics provides the upper part of the funnel, offline conversions provide its monetary completion.
The integration of Битрикс24 with Google Analytics specifically sets up the transmission of these events so that reporting relies on actually closed deals rather than on the number of submitted forms.
Common technical questions
Integrating Bitrix24 with Google Analytics most often comes down not to the data exchange itself, but to correctly transmitting offline conversions — events that happen outside the website: payment by invoice, deal confirmation by a manager, repeat purchase. Without them, analytics sees only clicks and leads, and does not show actual revenue by channel.
Below are answers to technical concerns that arise before setup begins.
What data actually needs to be sent to Google Analytics?
At minimum — the click identifier (gclid or an equivalent from the ad system), the conversion amount and time, and the deal status.
Without gclid, the event will not be attributed to a traffic source and will fall into "direct visits." We save the identifier in the lead card on the first visit and keep it until the deal is closed — otherwise it is lost by the time of payment.
What happens if the setup is configured incorrectly?
Duplicate conversions distort reporting more than their absence: a single deal can be counted twice when the status changes. We set up transmission based on a specific final status and protection against resending — the report keeps one record per deal.
How is transmission from Bitrix24 set up?
Through business processes and webhooks: when a deal moves to the target status, the system sends an event to the Measurement Protocol. Setup takes several days, including a test run on real deals and reconciling the numbers with the CRM.
Can changes be rolled back if something goes wrong?
Yes. The logic is moved into a separate business process that can be disabled with a single setting without modifying the core. Before launch, we make a backup of the configuration — returning to the previous state takes minutes.
Do the website itself and 1C need to be touched?
Usually not: the click identifier and statuses are already in the CRM. We only modify the website if it does not pass the tag when a lead is created. With 1C, the setup works through exchanging payment statuses — a separate integration is not required.
Let's discuss your task
We gather the inputs for your setup: which entities in Bitrix24 are considered target ones (deal, payment, repeat purchase), which sources are tagged in Google Analytics, and where the link between a lead and a closed deal is currently lost.
That is enough for us to come back with an estimate and a plan — without a preliminary "three-hour technical interview".
- We analyze the current scheme: how leads get into the CRM, which fields capture the source and click identifier, and where the chain breaks before the offline conversion.
- We reconcile the reference data: deal statuses, rejection reasons, product and service categories — we bring them into a form suitable for passing to analytics without manual edits.
- We design the transfer of offline conversions: matching a deal with a visit, rules for sending on status change, handling repeat and canceled deals.
- We set up the export and test it on test deals: checksums, duplicates, delays between deal closure and the appearance of data in reports.
- We consolidate reporting: linking sources, campaigns, and actual revenue by closed deals, not by submitted forms.
- We establish the procedure: who changes statuses and when, what happens when a client declines, and how an erroneous transfer is rolled back.
- We hand over the documentation and train your team — so that edits in the reference data do not break the data transfer.
To come back with a plan, we need a little from you: access to the CRM with rights to read the reference data, a list of target deal statuses, and an understanding of which reports you look at today.
Describe the task in two or three paragraphs — what is already set up, what does not add up in the numbers, and what result is needed. After that we will propose a scheme, timelines, and the order of work.