Metrica, What Are You Doing?! Why Site Reorganization Breaks Analytics — and How to Fix It

For anyone who manages a website, few phrases cause as much panic as "Metrica, what are you doing?!" It usually appears after a redesign, a platform migration, or a major site restructuring — when all the counter code looks correct, but the reports show impossible numbers. A recent article on Habr describes exactly this situation, and it carries an important lesson: the data may be right, but the tracking structure still needs explicit reorganization.

The story begins with a common mistake. After moving a site to a new engine or changing its URL hierarchy, an analyst checks the counter and sees that it is installed on every page. Sessions are recorded, pageviews are counted, and yet the reports seem wrong. The article's author explains that the root cause isn't the counter — it's the forgotten reorganization. When a website changes its structure, all the old markers, goals, and segment conditions that depended on URLs or page paths become outdated. The result is a bizarre mix: the counter works, but the analytics silently break.

Web analytics platforms like Yandex Metrica rely on a logical map of your site. Reorganization is the process of updating that map — adjusting goals, funnels, and reports to reflect the new structure. Without it, even a perfectly working counter produces misleading data. This material examines why that happens, which scenarios trigger the problem, and what a proper reorganization looks like.

The Counter Works, the Data Lies: What Actually Happens

To understand the issue, it helps to break down how Yandex Metrica connects a web page to a business event. The counter sends a hit every time a user opens a page. The hit contains the page URL, the referrer, and other parameters. On its own, that hit is correct. The problems begin when the platform tries to interpret the hit using the rules stored in your account.

For example, a site might have a goal called "Order Completed" that fires when the URL contains /order/success. After a site reorganization, the e-commerce section moves from /order/ to /checkout/. The old goal never fires because the new URLs are unrecognized. Meanwhile, a segment that filters traffic from the /blog/ section suddenly mixes together news and product pages. The article on Habr highlights exactly these kinds of oversight — the counter still transmits data, but the analytics layer is no longer aligned with the real site.

The author of the Habr material recounts a specific case. During a scheduled redesign, the team transferred the site to a new CMS, migrated the SSL certificate, and updated all internal links. They also copied the Metrica counter code to the new template. The code worked — the "works" indicator literally showed "found and active." Yet the dashboard revealed an absurd drop in conversions. Only after checking the goal paths did they notice that all goals pointed to the old URL structure. They had forgotten to reorganize, not to install.

The phrase "Metrica, you're right, but I forgot about reorganization" is thus a perfect summary. The system does exactly what it was configured to do. The human responsibility is to update that configuration whenever the site itself changes.

Common Scenarios That Break Analytics

Reorganization isn't only about redesigns. Several everyday situations can turn an analytics account into a black box. The following table shows the most typical triggers and their consequences:

Not every modern web analytics platform handles these changes automatically. Yandex Metrica gives you a lot of control, but that control comes with responsibility. The Habr article emphasizes that any structural change to a site should trigger a parallel reorganization of the analytics account.

The Forgotten Check: What a Correct Reorganization Includes

A proper reorganization is more than just editing a goal. It is a systematic audit of every part of the analytics setup. The author of the Habr material suggests a consistency check between the old and new site structures. In practical terms, that means performing the steps below.

1. Remap the main pages

Take the old sitemap and the new sitemap, then compare page-by-page. Every URL receives a new address. If the site uses a CMS with automatic redirects, create a list of redirects and make sure Metrica tracks the final URLs — not the 404 pages. The same applies to key landing pages.

2. Update goals and funnels

Goals can use URL conditions, event conditions, or custom JavaScript. After a reorganization, all goal types need a review. For URL-based goals, update the mask or the exact address. For event-based goals, check whether the event names and parameters from the new code are being sent to the counter. A popular mistake is keeping a "click on button" goal while the developer changed data-metrica-event to a different value.

3. Audit segments and filters

Filters are a common hidden trap. For example, an IP filter that excluded the office network becomes irrelevant if the team now works from a different connection. Segments that group pages by URL pattern should be reconstructed according to the new site architecture. The Habr article points out that this step is often skipped because it is not visible in the main dashboard — yet it silently distorts all comparisons.

4. Test the data layer

If the site sends additional data to Metrica via a data layer (for example, product names, prices, or user roles), verify that the new frontend code still populates the same keys. A small difference in naming — price versus product_price — is enough to empty all reports.

5. Use the built-in verification tools

The browser debugger extension and the real-time report are indispensable. Open several pages of the new site, trigger a few goal actions, and confirm that hits appear with the expected parameters. Wait about 30 minutes, then compare the data with the old reports. Any odd discrepancy points to a missed step.

Why an API Integration Helps You Catch Mistakes

Reorganization is not only a human task. The automation around an analytics platform can make the process far less painful. Yandex Metrica provides an API that allows external systems to read reports, fetch goal settings, and even manage data in bulk. That is exactly where a data platform becomes useful.

ASI Biont supports connection to Yandex Metrica via API — more details at asibiont.com/courses. With such a connection, the accounts data can be exported into a unified marketing dashboard, where sudden drops in key metrics are automatically visible next to the dates of site changes. Instead of discovering a data quality problem a month later, an analyst can review the situation on the day after the redesign and catch the forgotten reorganization before the reports are presented to management.

A practical example: after moving a company's blog from /blog/ to /articles/, the marketing team uploaded a list of all new URLs into a data platform and connected it to Metrica. The system immediately flagged that the "Form Lead" goal was recording zero conversions for three days. The cause was the old goal mask. The platform did not fix the goal, but it made the anomaly impossible to miss. For many teams, that kind of early warning is the difference between a smooth transition and an embarrassing report.

Lessons from the Habr Story: Documentation and Planning

The main lesson of the Habr article can be formulated simply: never touch the site structure without touching the analytics structure. The author recommends documenting every goal, segment, and filter before a redesign. That documentation becomes the basis for a reorganization plan. A website launch day should have two checklists — one for developers and one for analysts.

The article also advises to treat the counter not as an isolated script but as part of the site's architecture. When the architecture changes, the counter's environment changes too. A healthy practice is to schedule a "Metrika health check" after every significant release. That check does not require deep technical skill: just inspect the real-time report, verify a few goal conversions, and compare segment data for two adjacent days.

Another useful tip from the material is to use versioning. If possible, keep a copy of the previous counter settings or a backup of the analytics account. In a worst-case scenario — for example, when a developer accidentally overwrites goal conditions — the backup lets you quickly roll back to a known good state. Many teams ignore this until they lose a crucial dashboard.

Conclusion

"Metrica, what are you doing?!" is a phrase that hides a much more accurate thought: "I forgot to reorganize." The counter never lies, but it can never replace the missing structure. A website reorganization, a CMS migration, or a simple change in URL patterns demands a parallel reorganization of goals, segments, and funnels.

The Habr article is a good reminder for every analyst and marketer: after changing the site, open the analytics settings before opening the reports. Take the time to compare the page structure, update the masks, verify the event names, and test everything in real time. That half an hour of careful work saves days of confusion later.

And when the next redesign comes, remember that human error is inevitable. The more automated the connection between the analytics platform and a data processing system, the sooner a discrepancy becomes visible. Updating the tracking structure is still your job — but with the right tools, you will always know when that job needs to be done.

Source: Метрика, ты что?! Всё верно, но я забыл про реорганизацию — Habr