Short answer. Metrica is a behaviour counter: it shows what the people who actually reached your site did there. Its session recording module captures cursor movement, scrolling, clicks and form input. That last part makes it both the most useful and the most dangerous module: without field masking you are shipping your visitors' personal data into a third-party system.
What analytics shows — and what it never will
The counter fires in the visitor's browser, so it sees exactly what happened after the page loaded successfully. Anything that happened earlier, or prevented the load, does not exist for it.
| Question | Analytics answers | Analytics does NOT answer |
|---|---|---|
| Is the site up at all? | — | Outage, 5xx, expired certificate: the visitor never arrived, so there is no event |
| Where visitors came from | Sources, campaigns, search queries | — |
| What they did on the page | Scrolls, clicks, forms, session recordings | What the server was doing at that moment |
| Why the form was not submitted | What the person did before leaving | The server response and the backend error |
| How fast the site is | Load time for real visitors | Load time for those who left before it finished |
Hence a simple rule: analytics and availability monitoring answer different questions and do not substitute for each other. A dip in the traffic chart is a symptom, not a diagnosis — the cause can be seasonality, a downed server or a broken redirect. The difference between real-user data and synthetic checks is covered in real user monitoring and synthetic vs RUM.
Installing the counter: where it goes and how to verify
The counter code belongs as early in the markup as practical, usually in the head. The later it executes, the more short visits never make it into the statistics: the person left before the script sent its first event.
Verify the installation by fact, not by eye:
# Is the counter code in the HTML the server actually returns
curl -s https://example.com | grep -o 'mc\.yandex\.ru[^"]*' | head
# Is the page served at all, and with which status
curl -sI https://example.com | head -n 3One caveat: on a client-rendered site the counter may live in the JavaScript bundle rather than the initial HTML — curl will not see it while the browser will. In that case check the network tab: does the counter request fire on load, and does it get a response?
Two counters on one page is the most common way to corrupt your own data. It happens after a contractor or theme change: the old snippet stays in the template while the new one arrives via a tag manager. Visits are double-counted, bounce rate halves, and the reports look suspiciously good. Before celebrating growth, grep the source for every occurrence of the counter.
The counter usually goes missing not on the homepage but on the "secondary" templates: a product page, the cart, a standalone landing. Check them as a list — and catch duplicates while you are there, because a count of two means more than one counter on the page:
# Is the counter present on every page type, and is it duplicated
for u in / /catalog/ /catalog/item-1/ /cart/ /contacts/; do
code=$(curl -s -o /dev/null -w '%{http_code}' "https://example.com$u")
hits=$(curl -s "https://example.com$u" | grep -c 'mc\.yandex\.ru')
printf '%s %s counter:%s\n' "$code" "$u" "$hits"
doneHow the counter affects page speed
Any third-party script means an extra connection, a download and work on the main thread. The counter itself is light, but it has two unpleasant properties.
- It drags session recording along. With recording enabled the volume of transmitted data grows: movements, scrolls and DOM changes are all captured. On simple pages this is invisible; on heavy interfaces it is not.
- It competes for the main thread at the worst possible moment — during first render. That hurts interactivity, meaning INP, and indirectly LCP if the script is included in a blocking way.
The practical conclusion is not "remove analytics" but "do not let it block": load it asynchronously and never ahead of render-critical resources. Measure the actual effect with the speed test, and work out which metric suffered using the Web Vitals guide and INP. If numbers dropped right after installation, compare two loads — with and without — before blaming the host; the method is in website speed test tools.
Session recording: what it captures and what it cannot
Session recording does not store video. It stores a stream of events — DOM mutations, cursor movement, scrolls, clicks, input — and replays your own page from that log. Every limitation follows from this design.
- Dynamic content replays approximately. If data arrives via a request, it may be missing or different during playback.
- Third-party frame content is not recorded. Chat widgets, payment forms and maps typically appear as empty areas.
- Graphics drawn in code (canvas, some animations) replay poorly or not at all.
- Recordings are kept for a limited time. Check the exact retention in the interface: it changes, and articles quoting a specific number go stale faster than they are written.
Why recordings are missing
| Symptom | Likely cause | What to check |
|---|---|---|
| No recordings at all | The module is not enabled in counter settings | Recording is switched on separately from the counter itself |
| Recordings appear with a long delay | That is how processing works | Wait; "nothing right now" is not a fault |
| Recordings are empty or fragmented | Heavy dynamic interface, third-party frames | Compare against a simple page of the same site |
| Parts of the page are invisible | Content sits in a frame or is drawn in code | A limitation of the method, not a misconfiguration |
| Nothing recorded on some pages | The counter is missing from some templates | Check product pages, cart, standalone landings |
| No data from certain devices | Ad blockers and privacy extensions | Normal: a share of your audience never enters analytics |
That last row is worth accepting as a fact of life: some visitors block counters and this cannot be fixed. Analytics is therefore good for comparing periods and testing hypotheses, but poor as a source of exact absolute numbers — and useless as an availability indicator.
Goals: why they do not fire
A goal is an event you declared valuable. Until goals exist you have traffic numbers but no answer to "how many leads did this channel bring".
- The goal targets a "thank you" page that no longer exists. Modern forms submit without a reload, the URL never changes, and the condition is never met. You need a goal on an event the site sends itself.
- The goal targets a button that gets re-rendered. When markup changes dynamically, binding to a class or id breaks with the next front-end release.
- The goal exists but the event is never sent. The classic hand-off gap: the analyst created the goal in the interface, the developer never added the call. Confirm by watching network requests during a real submission.
- The goal counts, but with a delay. Conversions do not surface instantly, so "nothing right now" proves nothing.
- The form submits but no email arrives, and you conclude the goal is broken. Different systems: the goal records a browser action, delivery happens on a mail server. How to separate the two is in emails not arriving.
Test a goal the way a visitor reaches it. Not "click the button while logged into the admin", but walk the whole path on a phone, in a private window, with realistic data. Half of all "broken goals" are goals nobody ever tested in a real scenario.
Session recording and privacy law: where the risk starts
This is the part setup tutorials tend to skip. Session recording captures form input by default. The moment a name, phone number, address or email lands in a field, you are transferring a visitor's personal data into a third-party system — as a data controller, with everything that implies under GDPR and comparable regimes.
- Mask fields containing personal data. The recording settings include a mechanism to exclude field contents; phone, email, address, identity document and payment fields must be closed from day one, not "when we get round to it".
- Describe analytics in your privacy policy: which data is collected, who processes it, why, and for how long. How to assemble one is covered in privacy policy for a website.
- Collect consent where it is required and do not start collecting before it arrives.
- Restrict access to recordings inside the team. Session replays are not slides for a stand-up: they show what visitors typed, and access belongs to the people who need it for work.
What your site actually places in a visitor's browser, and with which flags, is visible in the cookie analyzer; which flags are mandatory and why is covered in cookie security flags.
What analytics will never show you
The counter goes quiet at exactly the moments that matter most:
- The site is down. No load, no visits. The report shows "low traffic", not "outage".
- The certificate expired. The browser warns before the page loads, so the counter never fires.
- A redirect broke and part of your URLs lead nowhere: visitors are lost silently.
- Some pages return 5xx. The server sees the error; the visitor simply leaves.
- The domain stopped resolving. Indistinguishable from "nobody came".
So close the loop with external checks: uptime monitoring, certificate checks, the redirect checker and header inspection. Then a traffic drop is explained by facts instead of guesswork.
How to verify the setup
- Header check — is the page with the counter served, and with which status code.
- Speed test — did loading get more expensive after adding the counter and recordings.
- Cookie analyzer — which cookies are set, with which flags and lifetimes.
- Uptime monitoring — so a dip in the report is explained by a fact, not a hypothesis.
- SSL check — an expired certificate zeroes your statistics before you notice.
Frequently asked questions
Do I have to enable session recording?
No. It earns its place when you have a specific hypothesis: people abandon the form halfway, get lost in filters, never see the button. Turning it on "just in case" means accumulating personal data with no purpose — hard to justify on either usefulness or liability grounds.
Why does analytics report fewer visits than my server logs?
That is normal and expected. Logs count every request, including bots and people who left before the script ran; the counter only counts browsers that executed the code and did not block it. A gap of tens of percent is not a misconfiguration.
Can I tell from analytics that the site was down?
Only indirectly and after the fact: you will see a dip, but not the cause and not the duration. Answering that requires external monitoring, which checks availability whether or not anyone visits.
Does the counter slow the site down?
Slightly, like any third-party script. It becomes critical in two cases: when the script is included in a blocking way, and when the page already carries a dozen third-party scripts. Measure the effect rather than argue about it — compare a load with and without.
What do I do when a goal does not fire?
Walk the scenario as a visitor and watch the network panel: is the event sent at the moment of the action? If it is not, the problem is on the site, not in the goal configuration. If it is sent and the report is still empty, wait for processing and re-read the goal condition.
Do I need consent for session recording?
It depends on what ends up in the recording and how you process it, so the wording is worth agreeing with a lawyer. The technical minimum is the same everywhere: mask fields with personal data, describe the collection in your policy, and do not collect more than the stated purpose requires.
Setup checklist
- The counter is present on every template, not just the homepage.
- Exactly one counter per page — no duplicates.
- The script loads non-blocking, and its effect on speed has been measured.
- Goals target real events and were tested in a live scenario from a phone.
- Session recording is enabled deliberately, for a specific question.
- Fields with personal data are masked before recording is switched on.
- Analytics is described in the privacy policy, and consent is collected where required.
- Access to recordings is limited to the people who need it.
- Availability, certificate and redirects are watched by external monitoring, not by the traffic report.