Collecting data
It all starts with events arriving and being named consistently. The second half is harder than the first.
- Autocapture
- Custom events and properties
- User profiles
- Event dictionary
- In business since
- 2019
- Report delay
- 3 minutes
- Things it does
- 14
- Ways to connect
- 7
About the product
Zamer started as a studio tool: we counted events inside other people’s products and got tired of explaining why two reports disagreed. It is built around a single event table that everything else is derived from, so that the analyst and the developer argue about the product rather than about whose numbers are right. There are fourteen of us now, the product sells by subscription, and half the teams who wire it up work in English.
What it does
Three parts: one collects events, one computes reports from them, and one decides who gets to see the result. What each item does is in the docs; which plan it starts on is in the pricing.
Analysis
Every report is built from the same event table, so two metrics on two dashboards cannot disagree with each other.
- Dashboards
- Funnels
- Retention
- Segments
- Shared dashboard link
- User paths
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
- Two-factor sign-in
- SSO sign-in
- Audit log
Who it is for
The plans differ in their limits and in what they include, not in the level of service: there is one support queue for all of them, the trial included.
Start
One product and a small team: your first dashboards, your first funnels, your first argument about what counts as a sign-up.
Team
A product team that already decides by the numbers and wants its events to be named consistently.
Business
Several products, dedicated analysts, and a security team with questions about who can see what.
Where to ask
Support is one team: the person answering the site chat also reads the community channel. There is no first line and no separate engineering queue — there are too few of us for that.
Chat on the site
- The bot answers here
Best for
Money and access: invoices, plans, limits, invitations, data deletion. Here you can name a project without wondering who else is reading.
Usual language
Usually Russian: the people who pay and run the project write here.
The #help channel on Discord
- The bot answers here
Best for
Wiring up the SDK, event properties, numbers that look wrong — anything easier to discuss with a screenshot and a snippet, and useful to the next person with the same question.
Usual language
Usually English: the integration is normally done by developers, half of whom do not speak Russian.
- Whoever is on shift answers; nobody is assigned to you personally, because we have no account managers. The whole shift can see the thread, so you will not have to tell the story twice.
- The bot answers from the same knowledge base the site documentation is built from. When there is no answer in it, it says so and calls a human instead of inventing something plausible.
- A long thread is folded into a short summary before it is handed on: the next person reads six lines rather than forty messages.
- There is no paid priority support. One queue for every plan, the trial included, and that will not change as the price list grows.
When a human is around. People are around on weekdays from 10:00 to 19:00 Moscow time (UTC+3). That is when a human is nearby, not a promise to reply within so many minutes: at night and at weekends the bot answers, and anything that needs digging starts in the morning.
Community server
We keep an open Discord server. The developers who wire Zamer up are there, and so are we — mostly in English, because that is how it turned out.
- Discord server
- Zamer Community
- The channel is public and every answer is visible to everyone. Do not post an API token or your users’ data there — the site chat exists for that. The public project key is fine: it already sits in your page source.
- We never write to anybody in DMs first. If a "member of the Zamer team" messages you privately asking for a key, it is not us.
- We answer in the thread where the question was asked. There is no need to repeat it in the site chat: that makes two conversations about one thing, both worse than one.
- Asking in Russian in #help is fine and gets a Russian answer. The language of the reply follows the question, not the channel.
- The bot stays quiet in the other channels: people are talking to each other there, and an automated reply has no business in it.
We answer in the language you asked in
We keep one knowledge base and it is written in Russian. Questions arrive in two languages, so the answer gets translated — and it is worth saying so plainly rather than pretending support is multilingual.
The rule
We answer in the language of the question, not the language of the channel. A Russian question on Discord gets a Russian answer; an English question in the site chat gets English.
- Russian
- They ask in the site chat: workspace owners, product managers, accountants. This is the language the knowledge base is written in.
- English
- They ask in #help: the developers wiring up the SDK, often on teams where nobody speaks Russian at all.
What a translated answer says about itself
This answer comes from our Russian knowledge base and was translated automatically. If any of it reads oddly, say so and I will put it another way.
Ask in the chat
The chat bubble sits in the bottom right corner. Ask about limits, invoices or wiring up the SDK, in English or in Russian. It is the same bot and the same people as in the community channel, answering from the same knowledge base these docs are built from.