End-to-end analytics links advertising, the CRM and payments into one chain, where every request has a known source and every channel has revenue and cost next to it. It answers not "how many clicks were there" but "how much money did this channel bring and did it pay for itself". You do not need a separate product for this: you need tagged links, a source field in the CRM and uploaded costs.
Key takeaways
The difference is where the chain stops. Web analytics follows it up to an action on the site — a form, a call, an item added to the basket. End-to-end analytics continues it to the deal in the CRM and to the money in the account, so in the report a channel sits next to revenue rather than next to a request count.
On their own, without CRM data, Google Analytics and Yandex Metrica do not see payments: they only record what happened on the site. Metrica, however, can accept orders from a CRM — through the API, a CRM integration or the Yandex Direct conversion centre. That is a workable way to build end-to-end analytics without buying a separate system.
The practical difference shows up in six questions a manager asks.
| Manager's question | Web analytics | End-to-end analytics |
|---|---|---|
| How many people came from the channel | Answers | Answers |
| How many left a request | Answers | Answers |
| How many requests became deals | No, deals live in the CRM | Answers |
| How much money was actually paid | Only through site events | Answers |
| Did the channel pay for itself | No, costs are unknown | Answers, once costs are uploaded |
| Where the request was lost | No | Answers: pipeline stage and owner |
The last row explains why end-to-end analytics is usually ordered by the owner rather than by the marketing team: it exposes a weak channel and weak follow-up equally well.
The order is always the same and does not depend on the tools: first the tag, then its path to the deal, then the money, then the costs, and only at the end the report. Skip any step and the report becomes a list of requests with no cost attached.
Tip Do not wait for the scheme to be complete. A report on one channel with honest costs beats a handsome dashboard where half the requests are marked "direct". Add channels one at a time and each time reconcile the number of deals in the report with the number of deals in the CRM.
The model follows the length of the sales cycle: with one or two touches last click is enough, while a long cycle across several channels calls for a linear or data-driven model. The model itself is the rule that splits a deal's revenue between the channels the customer came through. While there is only one touch, there is no question. As soon as a person sees an ad, finds you in search a week later and writes on Telegram, the revenue has to be credited to someone.
| Model | Who gets the revenue | When it fits |
|---|---|---|
| Last click | The channel of the last touch before the request | Short sales cycle, one or two touches |
| First click | The channel that brought the person in first | Judging discovery channels: display, blog, video |
| Linear | Equally across all touches | Long cycle where touches carry equal weight |
| Time decay | More to touches closer to the deal | Short campaigns and seasonal sales |
| Data-driven | An algorithm weighs actual paths | Plenty of traffic and accumulated history |
The choice in Google Analytics 4 has narrowed: since November 2023 the first click, linear, time decay and position-based models are no longer available — data-driven attribution and two last-click variants remain. Other models are calculated on your own side: in the CRM or in a report built on an export.
Important An attribution model does not change revenue — it changes the conclusion about who brought it. The same month under last click and under first click will produce different winners. So the model is chosen in advance and periods are compared only within it.
Six metrics are enough: CPL, CAC, request-to-deal rate, ROMI, LTV and payback period. All of them come from two numbers — how much was spent on a channel and how much came back from the customers it brought.
| Metric | Formula | What it shows |
|---|---|---|
| CPL | channel cost ÷ number of requests | What one request costs |
| CAC | acquisition cost ÷ number of new customers | What a customer costs, not a request |
| Request-to-deal rate | deals ÷ requests | Request quality and the sales team's work |
| ROMI | (gross profit from the channel − cost) ÷ cost | Whether the channel pays for itself |
| LTV | average order × number of purchases × margin | How much profit a customer brings over their lifetime |
| Payback period | CAC ÷ monthly profit per customer | How many months it takes to recover acquisition |
Two places where people usually get it wrong. CAC counts every acquisition cost, not just the ad budget: sales salaries, tool subscriptions and contractor work belong there too. LTV is calculated on margin rather than on revenue, otherwise the model looks more profitable than it is. Both formulas are unpacked in our article on unit economics in plain terms.
Yandex Metrica writes payback the same way: ROI = ((total revenue − cost) ÷ cost) × 100. The difference between ROI and ROMI is only scope: ROMI counts all marketing spend, not one advertising campaign.
Part of end-to-end analytics is covered by built-in tools — provided the CRM has a source field and someone uploads costs once a month.
The limits of this route are clear. It works while deals live in one CRM and payments arrive in one place. Once there are branches, several legal entities or partial payments, the report is assembled on your own side, in the CRM or in a separate data layer on top of exports.
Below is an illustrative example: the figures are made up for the sake of the example, not taken from a project. It shows why the channel with the most requests is not always the best one.
| Channel | Requests | Deals | Revenue, $ | Cost, $ | ROI, % |
|---|---|---|---|---|---|
| 210 | 12 | 9,600 | 3,200 | 200 | |
| Google Ads | 130 | 9 | 7,400 | 4,100 | 80 |
| Organic search | 64 | 11 | 18,700 | 2,400 | 679 |
| Telegram bot | 48 | 7 | 5,900 | 1,800 | 228 |
Instagram brings almost half of all requests and only twelve deals out of thirty-nine, and on payback it loses to organic search, which has three times fewer requests. A report like this changes budget allocation rather than ad copy. What to do with the findings next is covered in our article on turning analytics into a plan.
It is usually not the report that breaks but the data underneath it. Walk through the list before you trust the first numbers.
The most common failure is the second point. A person arrives from an ad, leaves to think it over, comes back a week later by typing the company name, and the whole deal goes to "direct". That is where the regular verdict "advertising does not work" comes from, while the advertising works fine.
We do not sell "end-to-end analytics" as a separate service: it is part of the CRM work, because deals and payments live there. On our service pages it comes in three formats.
Three things push the budget above the starting figure: the number of channels and ad accounts, the state of the CRM data — duplicates and empty source fields are cleaned before the report is built — and the complexity of payment accounting when one deal has several payments. What each format includes is set out on our CRM development page.
Syntra Systems starts with the path of a request rather than with a dashboard: where enquiries come from, where the tag gets lost, which CRM field holds the source and what the company counts as a payment. We then fix the design — tags, fields, events, direction of exchange — and set up the flow of data from the ad to the payment.
We tag channels under one scheme, connect forms, telephony and Telegram, write the source into the deal record, tie the deal to a payment from 1C or a payment service and assemble a channel report with costs. Separately we set up reconciliation checks so the report does not drift apart quietly. At the UzFranchise Expo the organiser's dashboard worked exactly this way: you could see which ad each guest came from and how the database grew day by day.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Not necessarily. If deals live in a single CRM and payments arrive in one place, the chain of tagged links, a source field in the CRM and uploaded costs is enough, and the report is built inside the CRM or in Yandex Metrica. A dedicated service or data layer becomes necessary once there are branches, several legal entities and partial payments.
List them as a separate line and watch their share. If it grows, fix the tagging first — consistent link tags, call tracking, a mandatory source field on the deal — and never assign a source after the fact, since that distorts the whole picture.
Costs and revenue are matched by cohort rather than by calendar month: you take the customers acquired in a given month and look at what they have brought in so far. Otherwise long deals always look like a loss, because the cost is recorded immediately while the revenue arrives later.
Yes. The source is then passed by a tagged bot link or by a separate phone number for each channel. The rest of the scheme is unchanged: the tag lands in the deal record, the deal is tied to a payment, costs are entered manually. A website is convenient but not a required link in the chain.
Each offline channel gets its own entry point: a dedicated phone number, a QR code with its own tag or a promo code. Then the enquiry reaches the CRM already tagged. Without such an entry point, offline advertising is only visible indirectly, through a rise in direct visits and branded searches.
The tag is usually the one that gets lost: someone arrives from an ad, leaves to think it over, and returns a week later by searching the company name — the deal then gets credited to ‘direct traffic’. Check whether the tag survives a return visit and whether calls are tagged with call tracking.
Reconcile the definitions, not the numbers. The usual gaps are the moment revenue is recognised (shipment or payment), the treatment of refunds and the treatment of taxes. The rule is simple: the channel report uses the same revenue as management accounts, and what counts as a payment is agreed once.
