Cookie Policy

A cookie is a small named string that a site asks the browser to keep. The defining property of a cookie is that the browser itself attaches it to every subsequent request to the same domain: the server receives it without asking and without running any code.

A cookie is not the only storage a browser offers. There are also localStorage and sessionStorage: what goes into them stays on the device, is read only by the page's own code and travels nowhere automatically. In privacy terms these are different mechanisms, and the difference works in your favour here.

This document deliberately describes both. Your decision about analytics is kept in localStorage rather than in a cookie — and a “cookie policy” that spoke only about cookies would be silent about the most important entry on your device: the record of your own choice. So what follows is about cookies and similar technologies, and the list names where each entry is kept.

cookie

A name-value pair with a lifetime and a scope (a domain and a path). The browser sends it to the server on every request that falls inside that scope — including requests for images and scripts.

localStorage

Key-value storage bound to a domain. An entry has no expiry: it sits there until the site's code or you delete it. The browser attaches it to no request — only code running on a page of the same domain can read it.

First party and third party

A first-party entry is set for the site you opened; a third-party entry is set for another domain embedded in the page. Every entry in the list below is first-party, set for this site's domain. Two embedded domains are used, both belonging to Yandex — the counter and the captcha — and any entries of their own follow those services' rules.

Lifetime

For a cookie it is set when the cookie is written: either until a given date or until the browser closes. A localStorage entry has no expiry at all — it goes only when deleted. That is why the list below states lifetimes in words rather than in numbers alone.

The list is exhaustive. It is split into the two categories the banner shows: strictly necessary entries, and analytics. There is no third category, because there is no advertising, no personalisation and no profiling for one to describe. An empty category in a banner is not harmless: it teaches the reader that the list is a formality.

The site is a static build: the pages, scripts and stylesheets are served by a cloud platform, and the data from the contact form never travels through it. The one cookie — langPinned — is set by the site's own routing layer and not by the platform; it appears before you have chosen anything, and why that is legitimate is explained below.

The strictly necessary entries — there are two:

langPinned

A cookie. It stores the language of the page you opened — ru or en — so that a choice in the language switcher survives navigation and your next visit. Lifetime: 365 days from the moment it is written, and it is rewritten only when the language actually changes. Scope: the whole site, SameSite=Lax, HTTPS only in production; it is readable by page code because the language switcher itself reads it.

odin337.consent

An entry in localStorage. Three fields: the decision about analytics, the version of the text you agreed to, and the time of the choice. Deliberately not a cookie: a cookie would go to the server on every request, which means the record of your refusal would itself travel the network and land in logs. It stays until the decision is withdrawn or the site's data is cleared.

No consent is required for these two, for two reasons that are independent of each other. First, neither contains an identifier: a two-letter language code and the word “denied” identify nobody. Second, even treated as processing, it is necessary for precisely what you asked for — a page in the language you chose, and not being asked the same question twice (Article 6(1)(5) of Federal Law No. 152-FZ; in the vocabulary of cookie banners such entries are called strictly necessary).

Analytics is off by default. Until you explicitly agree, not one of the entries below exists: they are set by the counter script, and the counter script is not loaded.

_ym_uid

A cookie. The identifier the counter assigns to the browser so a repeat visit is not counted as a new visitor. The value is a random number, not derived from anything about you. Lifetime: up to a year.

_ym_d

A cookie. The date of the first visit from this browser — what tells a new visitor from a returning one. Lifetime: up to a year.

_ym_isad

A cookie. A housekeeping entry of the counter: whether ad blocking was detected. The site has no advertising and the operator makes no use of it; it is named here because you will see it. Lifetime: a few days.

_ym_visorc

A cookie. The technical entry for Webvisor: it ties the events of one recording session together. Lifetime: about half an hour, refreshed while the session continues.

All four are set by the counter, not by the site's code, and which ones exist and for how long is decided by the analytics service. The names are given rather than the phrase “analytics cookies”: entries with the _ym prefix are visible in the browser in ten seconds, and a claim that can be checked is worth more than a smooth one. If the service changes the set, this document changes with it.

The Yandex Metrica counter exists for one purpose: to see which pages are read and where visitors leave. It records the addresses of the pages opened, the referring source, time on the page, screen size, browser and operating system, an approximate region derived from the IP address, and whether the visit is a return. The IP address and the identifier assigned to the browser are part of that set — which is exactly why consent is asked for here rather than assumed.

The counter is configured on this site with the following on:

• the click map — where on the page people click;
• outbound link clicks — which links lead away from the site;
• accurate bounce measurement — a short visit is distinguished from one where the page was actually read;
• session recording (Webvisor) — covered separately below;
• deferred loading — the counter does not hold up rendering.

And with the following deliberately off:

• URL fragments — the part after the hash is not tracked: the browser never sends it to a server anyway, and visitors rightly treat it as their own business;
• e-commerce — the site has no cart and no purchases, so there is nothing to report;
• the pixel for visitors without JavaScript — the stock counter ships a beacon image inside a noscript tag, which cannot be asked for consent, so it is absent from this site entirely.

Webvisor records not merely that a page was opened but how you moved around it: pointer movement, scrolling, clicks, window resizing, interaction with elements of the page. From those events a session can be replayed like a screen recording — materially more than a page counter, and the reason consent here has to be explicit.

The contents of form fields are not recorded. What you typed into the name, address, phone and message fields is not kept by Webvisor: the recording shows that a field was clicked and that something was typed into it, but not what. The text you submit does go into the enquiry database — that is separate processing, described in the privacy policy and in the consent text — and it has nothing to do with the session recording.

The data the counter collects is also processed by the service itself, as an independent operator, under its own rules. If you have consented, two sets of rules apply to your visit at once: this document and the service's. Its privacy policy is published at https://yandex.ru/legal/confidential/. That address is deliberately not a link — the legal documents on this site carry no external links, so it is given as plain text.

There is no transfer of data outside Russia in this arrangement: both the counter and the captcha are Russian services. There is no other analytics system on the site. Google Analytics was removed when the site was rebuilt and will not return: it transfers data out of the country, and such a transfer requires its own prior notification under Article 12 of Federal Law No. 152-FZ.

The counter loads only after an explicit affirmative action — a click on a button in the banner, or on the switch in the settings on this page. Before that click the counter script is not in the document at all: not loaded, not executed, and it has set no cookie.

Continuing to browse is not consent. Neither scrolling, nor moving to another page, nor ignoring the banner counts as agreement. Nor can the banner be closed without deciding: it has no cross — the control that on many sites quietly means “yes”. It does not cover the page or stand in the way of reading it either: you are free to make no decision at all. Under Article 9(1) of Federal Law No. 152-FZ consent must be specific, informed and conscious, and inaction is not an action.

While no decision has been made, analytics does not run. The absence of a decision is read as a refusal, never as a default permission, and the same rule governs every unclear case: if browser storage is unavailable and the decision cannot be read, the counter does not load. The only direction in which this can fail is the one that collects less data.

Refusing means the script is never loaded at all. Not “loaded and asked not to count”, not “loaded in an anonymised mode”, not “loaded but without Webvisor”. Nor is refusal compensated for elsewhere: there is no second counter, no beacon image and no server-side analytics collecting the same thing by another route.

What happens at the moment you choose: an entry appears in localStorage under odin337.consent, holding your decision, the version of the text and the time. Nothing is sent to a server — the decision stays on the device, and the operator does not know what you chose unless a visit turns up in the statistics.

The version in that record is not a formality. If this document changes materially — a new service, a new category, a new kind of collection — the version number of the text is raised and any decision stored earlier stops counting as valid: the banner asks again rather than carrying a permission forward to words you never read.

The decision is not final, and you may change it as often as you like. This page shows the current state — whether analytics is on and when the choice was made — and this is where you switch it. Every page of the site links here from its footer, so there is nothing to hunt for.

Where to press. The banner carries two decision buttons — “Accept all” and “Necessary only” — while “Manage” opens the same categories one by one. This page gives each category its own switch, with a “Withdraw consent” button underneath them. Turning analytics off with the switch and pressing “Withdraw consent” are the same action with the same result.

That result is a recorded refusal, not a return to the undecided state. The difference is practical and it is in your favour: undecided is the state the banner exists to resolve, so erasing the record would set it asking again on every page. Refusing would then cost you more than accepting, which is the asymmetry that made cookie banners unreadable. A recorded refusal satisfies Article 9(2) of Federal Law No. 152-FZ all the same: the processing stops, and the decision on record is the one you made.

Withdrawal takes effect at once, and it is not limited to the storage entry. A counter already loaded into an open page cannot be unloaded — so withdrawing deletes its cookies (every entry whose name begins with _ym) and reloads the page. After the reload the counter is not in the document. The langPinned entry is left alone: it has nothing to do with analytics, and erasing it would silently change your language.

The second route is to clear the site's data in your browser. That works too, but it has a consequence worth knowing in advance: the record of your refusal is also site data, and it is deleted along with everything else. The banner will then ask again. Your language is unaffected: the langPinned cookie only marks that the choice was made explicitly, while the language itself follows the page address — /en stays English, an address without the prefix stays Russian, and deleting the entry changes nothing about the page you are on. This is not a trick: a refusal has to be stored somewhere, and the only fitting place is your device. Keeping it on the server would mean giving a visitor an account for the sole purpose of remembering that they do not want to be counted.

The decision is bound to a browser profile, not to you: the site has no accounts at all. In another browser, on another device or in a private window the question will be asked again, and a decision made in a private window disappears with the window.

The banner on the site is not the only way to control storage. Every current browser can delete cookies and site data, block them for one site or for all sites, and discard everything when the window closes. These settings outrank the site: they apply regardless of what you clicked here.

Specific menu paths are deliberately absent. Browser interfaces change with every update, and a printed set of steps is wrong within a year — and a wrong instruction in a legal document is worse than none. The current procedure is in your browser's own help; in its settings, search for “cookies” or “site data”.

If you block storage entirely, the site will open and work. The only things that stop working are the ones that by definition have to remember something: the language switcher forgets your choice, and the analytics decision is not saved, so the question may be asked on every visit. The counter will not load in that case — unreadable storage means “no decision read”, which is treated as a refusal.

The Do Not Track signal and headers like it are not needed here: analytics is off by default without them and is switched on only by an explicit action of yours. No header can switch it on for you.

For you, nothing. The site works identically under any decision: no page, no section and no function is gated behind consent. There is no “accept cookies to continue” wall, no repeated prompting after a decision has been made, and no reduced mode.

Nothing changes in the other direction either: the content does not become different, and neither do the prices. There is no personalisation on this site for anyone: no profiling, no automated decisions taken about you, no advertising and no ad networks, and no data sold or passed to anyone for their own purposes. Language follows the page address and your choice in the switcher; price follows the language version of the page, not a region inferred from an IP address.

The difference exists only for the operator: without analytics there is no visibility into which pages are read and on which the tab gets closed. That affects how the site develops next; it does not affect what you get from it today.

The version of this text is 1.0.0; the effective date is given at the top of the document. The version refers to the text, not to the site's code: a substantive change — a new service, a new category, a new kind of collection — raises the minor number, while a typo fix or a clarification that does not alter the meaning raises the patch number.

A substantive change resets the decisions already made. The version of the text the banner shows is raised together with the document's, and every stored decision stops being valid — you will be asked again. A patch does not work that way: asking again over a comma is how the question loses its meaning.

Superseded versions remain recoverable: the text is held in the project's version history, so any earlier wording can be retrieved by its number. If you need the text that was in force on a particular date, ask for it at privacy@odin337.ru — the version number identifies it unambiguously.