Cookie Policy

What this policy covers

This Cookie Policy explains the cookies and similar technologies we use on everiq.co and in the Ever IQ website — the public website, the documentation, the signed-in application, and any desktop or mobile application we publish for it. The product-specific section below lists what is actually in use on each of those surfaces.

It sits alongside our Privacy Policy. The two documents answer different questions, and it is worth knowing which one you are reading:

• This policy is about your device. What we store on it, what we read back from it, why, and how you control that.
• The Privacy Policy is about the information itself. What we do with personal data once we hold it, the lawful basis for each purpose, who receives it, how long we keep it, and the rights you can exercise over it.

Where something described here involves personal data, the Privacy Policy governs that processing. Nothing in this policy narrows the rights that document gives you.

What this policy does not cover

Other people's sites and services. Our pages link to third-party sites, and our Service connects to third-party tools when you ask it to. Once you are on someone else's site, their cookie notice applies, not ours. We have no control over what they store on your device.

Your own workspace, your own site, your own people. Where you use the Service as a customer to run something of your own — a workspace for your organisation, or a site we provision for you — the pages you publish and the people you invite are yours. This policy is not your cookie notice to your own visitors or personnel, and our banner is not your consent mechanism. Providing those is your responsibility, on your own domain, under your own control.

A copy you run yourself. Where the software behind the Service is published as open source and you run your own deployment, this policy describes the service we operate — not yours. You choose what your deployment loads and what it stores on your users' devices, and only you can describe it to them.

Cookies and the other technologies that behave like them

A cookie is a small text file that a website asks your browser to keep and hands back to a server on later requests. It is the oldest way of doing this, and the best known — but it is only one of several, and the rules that matter here do not turn on which one is used.

The law we work to attaches to storing information on your device or reading information back from it, whatever the mechanism. So wherever this policy says "cookies", read it as covering all of the following.

The technologies

• Cookies — as above. Set by the site you are visiting, or by another provider whose code runs on the page.
• Local storage and session storage — key-value storage inside your browser. Larger than a cookie, not sent automatically with every request, and it can hold exactly the same kind of identifier.
• IndexedDB and the browser cache — structured storage and cached files. Ordinarily used to make pages load faster and to let parts of the Service work offline, but capable of holding an identifier too.
• Pixels, beacons and tags — a tiny image or a short script whose only job is to load. The act of loading it tells the provider that a page was opened, or an email read, along with your IP address and browser details. A pixel often stores nothing at all and still reports on you.
• Tracking parameters in links — identifiers added to a URL so that a click can be attributed to the campaign or message that produced it.
• SDK identifiers in desktop and mobile applications — an installed application has no cookie jar. It stores identifiers in its own application storage instead, and may use identifiers the operating system provides: an advertising identifier, an installation identifier, or a push notification token.
• Device and network characteristics — your IP address, screen size, language, time zone, fonts and browser version. Individually unremarkable; combined, they can form a fingerprint that recognises a device without storing anything on it.

First-party and third-party

First-party means we set it, on our own domain, and it goes to our servers.

Third-party means it belongs to another company whose code we have chosen to run on the page — an analytics provider, an embedded video player, a bot-protection service. Their technology reports to them, not to us, and they decide what it does. Note the awkward part plainly: a third-party resource embedded in our page discloses your IP address, your browser and the page you were on to that provider, even when it stores nothing on your device at all. Loading it is the disclosure.

Some third-party technologies are deliberately set up to look first-party — served from a subdomain of ours, or routed through our own servers. Where we do that, we say so in the table below rather than letting the appearance stand.

Session and persistent

Session items are discarded when you close the browser or the application. They are typically what keeps you signed in and moving through a single visit.

Persistent items survive until they expire or you delete them, which is what lets us recognise a returning visitor, remember your preferences, or remember that you refused something. Each entry in the table below states how long it lasts.

Why we use them

There are six reasons, and each one maps to one of the categories in the next section. We have written the category next to each so you can see immediately which ones you control.

• To sign you in and keep you signed in. Your session has to be attached to the right account, the right workspace and the right organisation as you move between pages, and it has to be protected against being replayed or forged by someone else. → strictly necessary
• To keep the Service secure. Telling a person apart from an abusive script, protecting forms against automated submission, enforcing rate limits, and detecting fraudulent sign-ups and payments. → strictly necessary
• To make the Service work at all. Routing your request to a healthy server, keeping you on the same one where a feature requires it, balancing load, and serving the right version of the application. → strictly necessary
• To remember what you decided about cookies. Your choice has to be stored somewhere, or we would have to ask you on every page. → strictly necessary
• To remember your preferences. Language, time zone, theme, layout, a panel you collapsed, a message you dismissed, and whether you want the support widget open. → functional
• To understand how the Service is used. Which pages and features people actually use, which paths fail, and where things are slow — so that we improve the right things rather than the ones we happen to notice. → analytics
• To measure our marketing. Whether a campaign reached anyone, which content leads to sign-ups, and which organisations show interest in the product. → marketing

Two things follow from that list, and we would rather state them than leave them implied.

Only the first four are needed for the Service to function. Everything in the last three groups is optional. If you refuse all of it, every feature you are entitled to still works, at the same price.

Where we can achieve a purpose without storing anything on your device, we do. That is the whole reason our own analytics is built the way it is — see the section on analytics without consent below.

The four categories we use

Every entry in the table below belongs to exactly one of these four categories. The banner and the preference centre use the same four names, so what you agree to and what this policy describes are the same thing.

1. Strictly necessary — no consent, because the Service cannot run without them

These are the ones we set because you asked for a service that cannot be delivered otherwise. They are not optional, they are not used for analytics or marketing, and there is no switch for them in the preference centre. If you block them at the browser level, parts of the Service will stop working.

• Session and authentication — signing you in, keeping you signed in, refreshing your session, and binding it to the correct account, workspace and organisation.
• Security — protection against cross-site request forgery, detection of abusive automated traffic, rate limiting, and fraud prevention on sign-up and payment.
• Load balancing and routing — sending your request to a healthy server and keeping you there where a feature needs it.
• Your consent choice — storing what you decided, so that we can honour it and stop asking.

Error and crash diagnostics are not in this category by default. Where we use a diagnostics tool that records more than a technical error — a reconstruction of what was on your screen, for example — it is listed under analytics and it waits for your consent.

reCAPTCHA is in this category, and here is our reasoning

We use Google reCAPTCHA — and on some surfaces an alternative provider, named in the table below — to stop automated abuse of forms such as sign-up, password reset and contact. We treat it as strictly necessary, which means it loads without asking you first.

The reason is that it protects the specific form you are trying to use. You cannot meaningfully ask for the form and refuse the protection on it: without it, those endpoints are abused within hours, which is a security failure that harms you as much as us.

What that means in practice, stated plainly:

• It collects device and behaviour signals from your browser — mouse and touch movement, timing, browser and device characteristics, and your IP address — and sends them to Google, which acts as its own controller for that data under its own privacy notice.
• We load it only on pages carrying a protected form. It is not present across the whole site.
• Where an equivalent provider is available on a surface, we prefer the one that collects less.

Not every data protection authority accepts that a bot-protection service belongs in the strictly necessary category. We think it does, for the reason above, and we would rather publish the reasoning and let you judge it than bury the tool in a list. If you would prefer not to submit a form protected this way, write to privacy@ever.co and we will take it from you another way.

2. Functional and preferences — consent required

These remember choices you have made so that the Service behaves the way you left it: language, time zone, theme, layout, dismissed messages, and support or chat widgets where we offer them.

Refusing this category costs you convenience, not access. Everything still works; it simply forgets your preferences between visits and you set them again.

3. Analytics — consent required

These tell us how the Service is used: which pages and features are used, which paths people abandon, what is slow, and what fails. Depending on the surface this may include a provider's own persistent identifier and, where the table says so, a masked reconstruction of a session.

Third-party analytics tools are off until you turn them on, and nothing in this category loads before you choose.

There is one deliberate exception, and it is the subject of the next section: our own analytics, running on our own servers, is designed to operate without a consent requirement — cookieless, with no persistent identifier and aggregate reporting only. The next section sets out exactly what that involves and the conditions it depends on.

4. Marketing — consent required

These measure whether our marketing works and help us understand who is interested in the product: attribution of a sign-up to the campaign that produced it, and business-audience identification tools.

One of these deserves a plain sentence rather than a euphemism. Visitor identification tools resolve a visitor's IP address to the organisation it belongs to, so that we can see which companies have looked at the product. They do not tell us your name, but most people do not expect a website to work out their employer, so we would rather say it here than let you find it in a table. It is off unless you consent.

No cookie walls, ever

We do not use cookie walls, and we never make access conditional on consenting to non-essential cookies.

You can refuse everything except the strictly necessary category and the whole of the Service remains available to you — the same features, the same content, the same price. We do not offer a "consent or pay" alternative. We do not degrade the experience, hide content, or nag you on every page because you said no. Refusing is a decision we record and respect, not a negotiating position.

Annex: Ever IQ

Where this applies, and how short the list is

This policy covers everiq.co, which today is one page and a form. There is no signed-in application, no desktop client and no mobile app for this product yet.

On an ordinary visit, Ever IQ sets no cookies at all. That is not a drafting flourish — the responses from the live site carry no cookie of any kind. What follows is the complete list of what can be written to or read from your device, and why.

There is no consent banner on this site, and here is why

We do not show a cookie banner on everiq.co, because there is nothing on it for a banner to gate. No analytics tool, no marketing tag and no third-party script runs on this page in any circumstance. A banner asking you to accept things that do not exist would be theatre.

The one entry in the table that sits in a consent category deserves a straight answer rather than a category label. The theme choice is written when you click the toggle and not before. It holds one word, it is read only by the page you are on, it is never sent anywhere, and clearing site data in your browser removes it. If you never touch the toggle, nothing is written.

The moment anything in the analytics, marketing or preferences categories is added to this site, the banner and the preference centre ship in the same change — before the tag, not after it. That is the commitment, and the table above is how you check we kept it.

We run no analytics here at all

Some of our products run our own analytics software on our own servers, designed to need no consent. Ever IQ does not run that, or anything else. There is no first-party analytics tool on this site, no third-party one, and no measurement of your visit beyond the request logs any web server keeps. The core section describing our consent-free first-party analytics is deliberately not published for this product, because it would not be true here.

When the Portal opens, this table changes

We are building a messaging portal for Ever IQ. It has not launched, and nothing about it appears above because nothing about it is running. When it does open, the surfaces that come with a signed-in application will be added here in the same change that opens it:

• A session and device identifier, so that you stay signed in and so that your encrypted messages reach the right device. That is strictly necessary — an encrypted messenger cannot work without knowing which device you are on — and there is no version of the Portal in which it is optional.
• Your interface preferences, in the preferences category.
• Crash and product diagnostics, if we run them at all, in the analytics category and behind a real choice.

None of that is present today, and the day it is, this table names it before you can create an account.

Where the detail lives

This annex names what runs. It does not repeat what happens to the resulting data — the Privacy Policy covers purposes, retention and transfers, and the Sub-processor List names the two companies involved and what reaches each of them. Keeping the detail in one place is how three documents avoid drifting apart.

Third-party cookies and the providers behind them

Some of what runs on our pages belongs to other companies. We chose to include it, so we tell you it is there — but the provider decides what its own technology collects, and for that collection it is usually acting in its own right and under its own privacy notice rather than ours. Where that is the case, the table below links to their notice.

These are the kinds of provider involved, and what each kind does.

Analytics providers

Measure how the Service is used: page views, feature use, funnels, errors and performance. Most set a persistent identifier of their own so a returning visitor is recognised, and some can record a session replay — a reconstructed, masked playback of what happened on the screen. Where a tool on a surface can do that, the table says so explicitly.

Consent required. They do not load until you agree.

Tag management

A tag manager is a container we load once, through which other tags can then be delivered without shipping new code. That flexibility is exactly what makes it worth describing carefully: a container is a delivery mechanism, so what it delivers matters more than the container itself.

Every tag we deliver through a container is declared in the table below, in its own category. The container is consent-gated as a whole, and we do not use it to deliver anything from a category you have refused.

Consent required.

Marketing and visitor identification

Campaign measurement and attribution — which advertisement, email or article led to a visit or a sign-up — and business-audience identification, which resolves a visitor's IP address to the organisation that holds it so we can see which companies are interested in the product. It gives us a company, not your name. Most people still do not expect it, which is why it is named here as well as in the table.

Consent required.

Video, maps, fonts and other embedded content

Where a page embeds something served from another provider's network — a video player, a map, a code sandbox, a font, a script from a public content delivery network — your browser fetches it directly from that provider.

That fetch discloses your IP address, your browser and the page you were on to the provider, whether or not anything is stored on your device. There is no way to embed a resource and hide the request for it.

We handle this in two ways: where we can serve the asset ourselves, we do, which removes the third party entirely; and where an embed stores or reads anything on your device, we treat it as consent required and it does not load until you agree. Embeds that store nothing but are still fetched from a third party are listed in the table so you can see the disclosure even where no cookie is involved.

Security and delivery

The network in front of our sites — the proxy and content delivery layer that terminates the connection, absorbs attacks and filters hostile traffic — along with bot protection on forms and fraud checks on payment. These see connection metadata and may set their own security cookies.

Strictly necessary, and therefore not consent-gated. Our reasoning for putting bot protection in that category, including what it sends to its provider, is set out in the categories section above.

Where these providers are, and where to find the full list

Some of these providers are established outside the European Economic Area, and using them involves an international transfer of personal data. The transfers section of our Privacy Policy sets out the destinations and the safeguards we rely on for each, and you can ask us for a copy of those safeguards.

Two lists keep this current, and between them they are the authoritative answer:

• The table in the product-specific section below names every cookie and similar technology in use on this product's surfaces — the provider, whether it is first- or third-party, its category, its purpose, how long it lasts, and a link to the provider's own notice.
• Our Sub-processor List covers the wider set of providers that process personal data for us, including the many that never touch your device at all. You can obtain the current version at any time from privacy@ever.co, and it names the sub-processor, what it does, and where it processes.

We update both when a provider is added, removed or changed. If you find something on our pages that is not in either list, tell us at privacy@ever.co — that is a defect and we will fix it.

Consent, and how to withdraw it

How the banner works

On your first visit we show a consent banner, and nothing in the functional, analytics or marketing categories is written to or read from your device until you have made a choice. The strictly necessary items load, because the page cannot be delivered otherwise. Everything else waits.

The first layer of the banner — the one you see without clicking anything further — carries both a Reject all and an Accept all control, presented with equal prominence. Refusing everything takes one click, exactly like accepting everything. Alongside them is a route into per-category choice, so you can accept analytics and refuse marketing, or any other combination.

Three things that some banners do and ours does not:

• No pre-ticked boxes. Every category except strictly necessary starts switched off.
• Closing the banner is not consent. Neither is dismissing it, scrolling past it, or carrying on browsing. If you do not make a choice, nothing optional is set — you simply have not decided yet.
• No dark patterns. We do not make the reject control smaller, greyer, slower or harder to find than the accept control, and we do not hide it a layer down.

Changing your mind

Withdrawing consent is as easy as giving it, and you can do it at any time.

There is a persistent Cookie preferences link in the footer of every page, and an equivalent entry inside the application's settings. It opens the same per-category controls you saw in the banner, showing what you currently allow. Change a switch and it takes effect immediately: we stop, and where we can, we remove what was stored.

Two honest limits on that:

• Withdrawal works forwards, not backwards. It does not make lawful past processing unlawful, and it does not reach into data a third-party provider already received. If you want that deleted too, ask us at privacy@ever.co and we will tell you who holds it and how to ask them.
• Your choice is stored on the device and browser you made it on. A different browser, a different device or a private window will ask again, because there is nothing there to read. Clearing your browser storage deletes the record of your refusal as well, which is why the banner reappears afterwards.

The record we keep

When you make a choice we record what you chose, when you chose it, which categories it covered, and which version of this policy was in force at the time. That record exists for two reasons: so that we honour your choice, and so that we can show what you were asked and what you answered.

You can ask us for a copy of your own consent record at privacy@ever.co.

How long a choice lasts before we ask again

We store a consent choice for six months. After that the banner appears again so you can confirm or change it. We will also ask again sooner if we add a purpose or a category your earlier choice did not cover, or if this policy changes in a way that materially affects what you agreed to.

This is our own practice, not a legal requirement. There is no EU-wide statutory interval for asking again — six months follows regulator guidance we consider sensible and proportionate, and we have chosen to apply it. If you would rather not be asked at all, refusing everything is a decision we keep for the same six months, and blocking storage at the browser level stops the question permanently.

Controls in your browser and on your device

Our banner is not the only way to control this, and it is not the strongest one. Your browser and your operating system can enforce a choice on every site at once, including ours.

In a browser

Every major browser — Chrome, Firefox, Safari, Edge and the rest — offers the same set of controls, under privacy or site settings:

• Delete cookies and site data, for one site or all of them.
• Block cookies, either all of them or only those set by third parties.
• Clear storage on exit, so nothing survives the session.
• Private or incognito windows, which discard everything when the window closes.
• Per-site permissions, so you can allow storage on the sites you use and block it everywhere else.

Your browser's own help pages describe exactly where these live in your version — we deliberately do not reproduce click-by-click instructions here, because they go stale faster than this document does.

Content blockers and privacy extensions work on our sites too. Using one is a legitimate choice, and we build the Service so that it keeps working when the optional things are blocked.

In our desktop and mobile applications

An installed application has no browser settings to change, so the controls are at the operating-system level instead:

• Reset or limit the advertising identifier your device provides.
• Answer no to the app-tracking permission prompt on iOS, which stops access to that identifier entirely.
• Withdraw notification permission, which stops the push token being useful.
• Clear the application's stored data, or uninstall it, which removes everything it kept locally.

The Cookie preferences controls described above are also available inside the application, and they govern the same categories there as on the website.

What breaks if you block the strictly necessary ones

Blocking the optional categories breaks nothing. Blocking storage entirely does, and you should know what to expect:

• You will not be able to sign in, or stay signed in. Authentication needs somewhere to keep the session.
• Forms may fail their security check and refuse to submit.
• Some features will behave inconsistently, because requests can no longer be kept on the same server.
• We cannot remember that you refused. The record of your choice is itself stored on your device, so blocking storage means the banner returns on every visit — the one genuinely irritating consequence, and it comes from the mechanism rather than from us being difficult.

Do Not Track

Browsers once offered a Do Not Track header, and some still do. We do not treat it, on its own, as a refusal — and we would rather explain why than quietly ignore it.

No consistent standard was ever agreed for what a site should do on receiving it. It was never clear whether it expressed a considered decision or a default someone else had set, browsers behaved differently, and several have withdrawn it. A signal we cannot interpret is not a safe basis for deciding what you want.

Use the banner or the preference centre instead. A choice made there is unambiguous, and we record it.

Global Privacy Control

Global Privacy Control (GPC) is the later, better-specified signal, and unlike Do Not Track it is defined to express an actual opt-out rather than a preference.

Where we receive a GPC signal from your browser, we treat it as a refusal of the analytics and marketing categories on that browser, and we act on it without waiting for you to interact with a banner.

Two points of detail:

• It applies to the browser or device sending it. Another browser sends its own signal, or none.
• An explicit choice you make later in our preference centre takes precedence, in either direction. If you switch a category on there while GPC is enabled, we treat that as your decision, and we record it as such. If you would rather that never happened, leave the categories switched off.

Changes to this policy

We update this policy when what we do changes — a provider added or removed, a technology retired, a category reassigned. Every update gets its own version number and effective date, recorded at the end of this document.

Where a change materially affects what you agreed to — a new purpose, a new category, or a tool moving out of the strictly necessary or exempt group — we ask for your consent again rather than relying on the choice you made against the old text. Corrections, clarifications and provider renames are published with a new version and no fresh request.

Earlier versions stay available, with the dates each was in force, at https://everiq.co/cookies. The effective date shown with this policy tells you which version applies today.

How to reach us

Questions about this policy, about anything in the table above, or about a choice you have made — write to privacy@ever.co. That address is monitored and we answer it. Ask us for a copy of your own consent record, for the current sub-processor list, or to be excluded from our own analytics, and we will do it without asking why.

By post: Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria — registered in Bulgaria under company number 204599535. We correspond in English.

If you think we have handled your data badly, tell us first — we would rather fix it. You can also complain to a data protection supervisory authority at any time. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.0 of the Cookie Policy for everiq.co, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://everiq.co/cookies.