A demo site for an invented coffee shop. The chat in the corner is real Fixorix support.Fixorix demoExamples

Help centre

What the product does, where it stops, and what support answers to the questions it gets. The knowledge base the bot answers from is generated from this same text — you are reading what it reads.

Collecting data

It all starts with events arriving and being named consistently. The second half is harder than the first.

  • Autocapture

    Page views, clicks on buttons and links, form submissions — from the moment the snippet is on the page, with no extra code. It can be switched off per project: some teams want nothing but their own events and the noise gets in their way.

    From plan: Start

  • Custom events and properties

    One line of code gives you an event with any set of properties: strings, numbers, dates, lists. Nothing has to be declared in advance — new properties turn up in the filters on their own.

    From plan: Start

  • User profiles

    Before sign-in, events collect against an anonymous id; after it, they are stitched onto yours. A profile holds only what you sent us — we add nothing from anywhere else.

    From plan: Start

  • Event dictionary

    A list of approved events, each with a description and an owner. Anything not on the list lands in a separate bin instead of polluting the reports. It cures the classic disease of analytics: forty spellings of the same click.

    From plan: Team

Analysis

Every report is built from the same event table, so two metrics on two dashboards cannot disagree with each other.

  • Dashboards

    Charts, numbers and tables on one page, sharing a period and a set of filters. A dashboard opens by link and remembers the state you left it in.

    From plan: Start

  • Funnels

    Up to eight steps, with a conversion window and a breakdown by any property. You see not just how many dropped out but how long it took them, which is usually the more useful half.

    From plan: Start

  • Retention

    Weekly and monthly cohorts: who came back, after how long and how often. It can be built on any event rather than just sign-in, because "came back" and "came back and did something" are different questions.

    From plan: Team

  • Segments

    A saved set of conditions over event and profile properties that can then be dropped into any report. Defined once, and no longer something to argue about.

    From plan: Team

  • Shared dashboard link

    A read-only public link that needs no sign-in and no seat. The link can be revoked, and it stops working for everyone at once.

    From plan: Team

  • User paths

    A tree of what people do before and after a chosen event. A heavy report: it is built over the selected period rather than the whole history, and the report says so on its face.

    From plan: Business

People and access

Who is inside, what they can see and what they have done. Questions nobody asks on day one and everybody asks eventually.

  • Roles

    Four roles, from owner to viewer. A role applies to the whole workspace: there is no "this project only" access, which is worth knowing before you invite a contractor.

    From plan: Start

  • Two-factor sign-in

    A code from an authenticator app. Any member can turn it on for themselves, and it can be made mandatory for the whole workspace.

    From plan: Start

  • SSO sign-in

    SAML: people sign in through your corporate provider, and switching someone off on your side closes our interface to them too. Usually a security requirement rather than a team preference.

    From plan: Business

  • Audit log

    Who signed in, who was invited, what was deleted and when the collection settings changed. The log cannot be cleaned from the inside, which is the point of it.

    From plan: Business

How events reach a report

Events are accepted around the clock and show up in reports after a short delay: we compute in small batches rather than on the fly. The delay is the same on every plan and does not depend on volume — it is a schedule, not a queue.

Report delay
3 minutes
  • There is a live stream: everything received in the last hour is visible in the project settings straight away, before it reaches any report. It is the first place to look while you are wiring things up.
  • We use the timestamp you send, not the moment we received it. Events that sat offline on a phone therefore land in the reports retroactively.
  • Events older than three days are accepted but marked as an import and kept out of the "today" reports. Otherwise one history backfill would ruin the daily charts for a week.
  • Duplicates are dropped by event id, if you send one. If you do not, a retried request becomes a second event — and a billable one.
  • We do not sample anything. A report contains exactly the events that reached us and fitted inside the plan limit.

Getting data in and out

The doors data comes in and goes out through. Each one says what is awkward about it, because hearing that from us is fairer than finding it on your second day of debugging.

  • JS SDK for the web

    A snippet on the page or a package from npm. Ten minutes to install, after which events go out on their own; the project key is public and sits in the page source, which is by design.

    Worth knowing. Some events will not arrive: ad blockers drop requests to third-party domains without a sound. Serving collection from your own domain helps — that is a change on your side, and the docs walk through it.

    CollectionFrom plan: Start

  • iOS and Android SDKs

    Native libraries for both platforms with the same set of methods. Screen autocapture is a flag; everything beyond that is your own events.

    Worth knowing. Offline events queue on the device and arrive in a batch at the next launch, keeping their original timestamps. Yesterday’s number can therefore creep up overnight.

    CollectionFrom plan: Start

  • HTTP ingest API

    Send events from your backend, from a queue or from a script. The only way to count what a browser never sees: payments, cancellations, refunds, background jobs.

    Worth knowing. Up to a hundred events per request. Once the monthly limit is gone on a plan without paid overage, ingest starts refusing: those events are not stored and cannot be recovered later.

    CollectionFrom plan: Start

  • Reports API

    Pull the computed numbers to your side: into your own dashboard, your own spreadsheet, your own weekly report. It returns exactly what the screen shows, by the same formulas.

    Worth knowing. A token reads every project in the workspace; there is no per-project token. Hand it out as carefully as you would hand out access to the interface itself.

    ExportFrom plan: Team

  • CSV export of a report

    A button on any report: what is on the screen leaves as a file, with the filters and breakdowns you applied.

    Worth knowing. It exports aggregates, not raw events: the rows of the report rather than what they were computed from.

    ExportFrom plan: Start

  • Raw event export

    Every event for a period with all its properties, one file per day. For teams that keep their own warehouse and do their own maths in it.

    Worth knowing. Prepared in the background, and a long period arrives in parts. You can only export what is still inside your plan’s retention window: nothing brings back what has been deleted.

    ExportFrom plan: Business

  • Digest into a team chat

    Once a day a dashboard is posted into a Slack or Telegram channel: an image and a list of numbers with the change since yesterday. It works through both messengers’ own public interfaces.

    Worth knowing. One schedule per dashboard: the whole thing, once a day, on the project’s timezone. A single chart cannot be sent on its own.

    Chat digestFrom plan: Team

Data and access

We store behaviour rather than people: which events happened and with what properties. Who is behind them is your knowledge — all we see is your identifier.

Where the data lives
The data lives in two data centres in Russia: the main one in Moscow, the standby in St Petersburg. Events never leave the country, and we use no third-party processors.
Full deletion, backups included
30 days
  • You choose the user identifier. Send an email address and we will be holding one; send an internal id and we will not. We recommend the second, both in the docs and in the chat.
  • The IP address is used to work out country and city and is not stored in full: the last octet is dropped at ingest.
  • The SDKs carry no third-party scripts and no advertising pixels. We do not sell your users’ data, do not enrich it from anywhere and never mix it between projects.
  • HTTPS only, encrypted disks, staff access on a need-to-work basis with a mandatory second factor. Who looked at what is recorded in our own internal log.
  • A single user’s data is deleted by their identifier, from the interface or through the API. The events are removed from storage and disappear from reports at the next recompute.
  • You can delete a workspace yourself from the settings. After that the data goes from the backups too, and not even we can bring it back.

Roles

Owner
Everything: billing, plan, members, deleting the workspace and handing ownership to somebody else. There is exactly one owner per workspace.
Admin
Invites and removes members, creates projects, changes collection settings and maintains the event dictionary.Cannot: Cannot see invoices and cannot delete the workspace.
Analyst
Builds and edits reports, dashboards and segments, and exports data.Cannot: Cannot invite people and cannot touch project settings.
Viewer
Looks at existing dashboards and reports, and changes the period and filters on their own screen.Cannot: Creates nothing and exports nothing. Takes up a seat exactly like everyone else, which is the part people forget.

What people bring to support

The conversations that happen most. Each one lists what you can check on your own: at three in the morning that is faster than waiting for a person.

I have installed the SDK and nothing is showing up

  • The #help channel on Discord

Start by waiting a few minutes and looking at the live stream: if the event is there but not in a report, nothing is wrong — reports are computed in batches and it is about to appear. If the stream is empty, the request never reached us: either it did not leave, or it left with the wrong key.

Check these yourself

  1. Check that the key in your code belongs to the project you have open in the interface. Events landing in the neighbouring project is the commonest cause by a distance.
  2. Open the live stream in the project settings: it shows everything received in the last hour, before any report does.
  3. Look in the browser console to see whether the request left at all. An ad blocker cancels it silently, and it shows up as a cancelled request rather than an error.
  4. If the event comes from your backend, check the response code: 401 means the wrong or a revoked key, 429 means ingest has stopped because the plan limit is gone and that plan has no overage.

Have this ready

The first six characters of the project key — not the whole key — and roughly when you sent the event.

When a human takes over. The event is in the live stream but still missing from reports an hour later. That one is ours: name the project and the time and we will look from our side.

Events are duplicated: one action gives me two or three

  • The #help channel on Discord

We accept whatever arrives and never guess what a duplicate is: two identical requests are two events, and both are billed. The one reliable fix is your own event id, which also covers retries after a flaky network.

Check these yourself

  1. Check whether the SDK is installed twice — a second tag in the template, or once more through a tag manager.
  2. If the event fires from a UI handler, make sure the handler is not being attached again on every render.
  3. For server-side events, send an event id: a retried request carrying the same id is dropped by us automatically.

Have this ready

The event name and a couple of examples: the timestamps and properties of two records you believe are duplicates.

When a human takes over. The ids differ, there is definitely only one SDK, and the duplicates persist — send two examples and we will work through it together.

The numbers in Zamer do not match our own database

  • Both channels

A few per cent between client-side analytics and your own database is normal, and it is nearly always in the same direction: we show fewer. A gap of several times over is not noise but a cause: a different timezone, the wrong project, or events that only fire for some users.

Check these yourself

  1. Compare timezones: reports are computed in the project timezone, while your database most likely lives in UTC.
  2. Check the period boundaries. Our "today" starts at midnight in the project timezone, not in yours.
  3. Be clear about what you are counting: events or people. One person on two devices is two anonymous profiles until they sign in.
  4. Account for blockers. Some events never reach us from the browser, so your database will always show slightly more orders.

Have this ready

Which report, which day, and what you are comparing against: your admin panel, your database or another analytics tool.

When a human takes over. Timezones and period line up and the gap is still multiple times — send both numbers and the period and we will compute the same thing on our side.

We have used up the events on our plan — what now

  • Both channels

It depends on the plan. Where overage exists, collection does not stop: events keep arriving and the started blocks above the limit are added to the end-of-month bill. Where it does not, ingest halts until the first of the month and those events are gone for good. If you run out every month it is worth comparing: a small overrun is cheaper than the step up to the next plan, a consistently large one is not. Where the line falls depends on your numbers.

Check these yourself

  1. Open usage in the workspace settings: it shows not just how much has gone but which event is driving it. Nine times out of ten it is autocaptured clicks nobody looks at.

Have this ready

The workspace name. We can see the plan and what is left ourselves.

When a human takes over. Working out which is cheaper in your case, or switching overage on right now, is a job for a person.

We want to add a colleague and there are no seats left

  • Chat on the site

The entry plan does not sell extra seats, so the only way is up a plan. On the others an extra seat costs a fixed amount per month and is added straight away, with the difference charged for the rest of the paid period. No mental arithmetic needed: tell us how many people and we will give you the total.

Check these yourself

  1. Look through the member list: viewers take up a seat exactly like analysts, and there are usually more of them than the owner remembers.

Have this ready

How many people you need to add, and which role they need.

When a human takes over. When the seats actually have to be added: the owner does it in the settings, and if the owner is away, support does.

How do we change plan, and what happens to the data

  • Chat on the site

Moving up happens immediately, with the difference charged for the rest of the paid period, and nothing happens to your data. Moving down happens at the next period, and here is the part that matters: retention shrinks, and events older than the new window are deleted. Not hidden — deleted, with no way back. Export anything you would miss before you move down.

Have this ready

Your current plan and the one you want to move to.

When a human takes over. If the lower plan has too few seats or projects, the extras have to go before the change — support helps with that.

We need an invoice, a delivery act and a contract

  • Chat on the site

You raise the invoice yourself in the billing section, at any time and for any period. Closing paperwork follows the payment. A contract is not always needed — the site carries a public offer — but if your company works differently, send your template to the documents address and our lawyer will read it.

Have this ready

Your company details, and which of the three you actually need.

When a human takes over. Edits to a contract, unusual company details and anything that gets signed are not for the bot.

Where is last year’s data

  • Both channels

Raw events are kept for the period your plan states, and it is not retroactive: anything older is deleted nightly. Moving to a bigger plan extends the window for future events but resurrects nothing — we keep no copies for that. If you need the data long-term, export it while it is there.

Have this ready

Your plan and the period you are looking for.

When a human takes over. If it looks like data vanished early, give us the project and the period and we will check the log.

What we do not do

A short list, so that none of it turns up in week three. Each entry says why, and where to go instead.

Session replay
We do not record the screen and we do not show where the mouse went. That is a different product with a different storage bill, and a half-hearted version is worse than none.Instead: For "why did they not click", use a dedicated replay tool and watch it alongside our funnels.
A/B testing
We measure what already happened; we do not assign variants and we do not compute significance. A "variant B wins" button without honest statistics is a way to reach the wrong decision faster.Instead: Send the variant as an event property and compare segments by hand — the statistics remain your job.
Alerts when a metric drops
The digest goes out on a schedule, but there are no rules of the "tell me if conversion drops by a third" kind. Thresholds nobody revisits start firing for nothing within a month, and then they get muted along with the useful ones.Instead: Pull the numbers through the reports API and compare them on your side, where your on-call setup already lives.
Importing history from another analytics tool
You cannot pour years of history over from someone else’s service: every tool has its own event model, and stitched-together data lies more convincingly than missing data does.Instead: If you have your own raw log, you can load the history through the ingest API; it lands marked as an import.
Running it on your own servers
Cloud only. There is no on-premise build: fourteen people cannot support one, and a badly supported box is your downtime rather than ours.Instead: If the requirement is that data stays in Russia, it does: the servers are here. If it is that the data lives with you, take the raw export and keep it in your own warehouse.
Documentation in Russian only
The interface is translated into English; the documentation is not. So on Discord the bot builds the answer from the Russian base and translates it, and says as much in the reply.Instead: Just ask in English in the channel — it works better than running the Russian docs through a translator, because the bot has a glossary of our terms and your browser does not.
One timezone per project
The timezone is set on the project and applies to all of its reports. You can change it, but everything is recomputed and yesterday’s figures will stop matching the screenshots in your deck.
A mobile app
There is no app. Dashboards open in a phone browser and read well enough there, and writing an app so that somebody can glance at a chart once a week is not what this team should spend itself on.Instead: The digest into a team chat covers most of what "check it from my phone" means in practice.

Answering in two languages

Questions arrive in two languages and the documentation is written in one. Below are the rules that follow from that, and the glossary that keeps the terms in place.

  • Both halves are translated: the question so that the Russian search finds anything, the answer so that it can be read. Two translations are two places to lose a term, which is why the glossary exists.
  • Numbers are neither translated nor converted. Prices stay in roubles: the bot has no exchange rate, and an invented dollar figure is the worst thing that can happen in a conversation about money.
  • Channel names, key names and menu items stay as they are. A translated menu item is a menu item that does not exist, and somebody will hunt for it until the end of the day.
  • When the bot is unsure, the hedge is written in the language of the answer. A stray Russian line in the middle of an English reply reads as a glitch rather than as candour.
  • The reply says that it was translated. Pretending the knowledge base is English is pointless: the first long explanation gives it away, and being found out costs more trust than saying so up front.

A question in a third language. The model will happily handle German or Spanish, but nobody here has proofread that output. So a question in a third language gets an English answer and a plain note saying why, rather than a pretence that we support ten languages.

Glossary

Pairs the translation is not allowed to replace with something of its own. On the left, what the Russian docs and the invoice call it; on the right, what the English interface shows.

Замер → Zamer
The product name. In an English answer it stays in Latin letters and is not inflected: a translated or declined name matches nothing in the interface and nothing in the docs search.
Старт → Start
A plan name. The pair is fixed: the Russian name is what the invoice says, the English one is what the interface shows, and an invented third variant matches neither.
Команда → Team
A plan name. The pair is fixed: the Russian name is what the invoice says, the English one is what the interface shows, and an invented third variant matches neither.
Бизнес → Business
A plan name. The pair is fixed: the Russian name is what the invoice says, the English one is what the interface shows, and an invented third variant matches neither.
событие → event
The unit of data you pay for. Not an "action" and not a "hit": both the plan limit and the invoice are counted in events.
свойство события → event property
Not a "parameter" and not an "attribute". The tab in the interface matches the field in the API, and this is the word people scan for.
воронка → funnel
Plain "funnel", with no adjective: a "sales funnel" is about deals, while this report is a product one and its steps usually stop short of money.
удержание → retention
In a Russian answer the report is called «удержание», exactly as the interface labels it. The transliterated form is fine only if the customer used it first.
рабочее пространство → workspace
The thing that is paid for as a whole. Plan limits apply to a workspace rather than to a project, and confusing the two answers the customer’s limit question wrongly.
проект → project
A separate product with its own key, living inside a workspace. Not a "workspace" and not an "app": the interface treats them as two different levels.
участник → seat
Use "seat" when the sentence is about the limit or the bill, because that is what the pricing calls it, and "member" when it is about a person. Mixing them turns "you are out of members" into something faintly menacing.
ключ проекта → project key
The public key that sits in the page source. Never call it a token: swap the words and somebody cheerfully posts the wrong one into a public channel.
токен API → API token
The secret that can read every project in the workspace. Any answer about it is worth ending with a reminder that it does not belong in a public channel.
режим только чтения → read-only mode
What a workspace becomes after an unpaid trial or a failed payment. Not "blocked" and not "deleted": the data is still there, and that is the first thing the person wants to hear.

Short answers

  • What happens when the trial ends?

    Nothing is charged: we never asked for a card. The workspace goes read-only — reports still open, new events are refused. Pay within the window and everything continues with the same data; do not, and the workspace is deleted along with it.

  • Our team works in English. Will support understand us?

    Yes. Write in English either in the site chat or in the community channel: we answer in the language of the question. Our documentation is in Russian, so the answer will be translated, and it says so. Plan names, key names and menu items are left untouched by the translation so that you can still find them on screen.

  • Where should I ask — the site chat or Discord?

    Money, access and invoices belong in the chat, where the conversation is not public. Code, events and numbers that look wrong belong in #help, where the answer helps the next person too. Keep API tokens and user data out of the public channel; the public project key is fine there.

  • Am I talking to a bot or to a person?

    The bot first, answering from our own knowledge base, around the clock and at weekends. When the base has no answer it says so and calls a human. During working hours a person joins the same thread and can see all of it. Nobody is assigned to you personally: whoever is on shift replies.

  • Can we pay in dollars or euros?

    No, invoices are in roubles only, which is a limitation on the bank’s side. We do not quote a converted price anywhere, and the bot will not either: it has no exchange rate, and an invented figure in a conversation about money is worse than a plain no.

  • How many events do ad blockers eat?

    Anywhere from a few per cent to a third, and worst of all for developer products, whose audience blocks everything. Serving collection from your own domain reduces it, and the docs explain how. Nobody can remove it entirely — not us and not anyone else — and claiming otherwise would be a lie.

  • Do you sample data at higher volumes?

    No. A report contains exactly the events that reached us and fitted inside the plan limit. Heavy reports such as user paths take longer and are computed over the chosen period, but never over a sample — the report itself says so.

  • We have three products. One project or three?

    Three, if they have different users and different events: that is what the project limit on the plans is for. One, if it is a single product on three platforms — then everything lands in one funnel and the platform travels as an event property. Splitting later is possible; merging back is not.

  • A user has asked us to delete their data. What do we do?

    Delete them by identifier, from the interface or through the API, or ask us in the chat. The events are removed from storage and drop out of reports at the next recompute. If you never sent us an email address or a name in the first place — which is what we recommend — there is usually nothing to delete at all.

  • How long does it take to get started?

    The snippet on the site takes about fifteen minutes, first custom event included. The slow part is not the code but agreeing inside the team on what events are called. Budget an evening for that and start the event dictionary on day one rather than six months in, when the reports hold four spellings of the same click.

No answer here — where to ask