An answer must show its work
Every number in Alitycs can be opened: the events it counted, the window it used, the population it started from. A metric you cannot inspect is a rumour with a chart around it.
// about
Small teams deserve analytics they can actually trust
Alitycs exists because the tools that answer product questions well were built for companies with a data team, and the tools priced for everyone else answer the questions badly.
// the problem
The dashboard nobody trusts
Almost every product team we talk to has the same artefact: a dashboard somebody built during a push for "more data-driven decisions", still loading every Monday, and no longer cited in any argument. Not because the numbers are wrong, but because nobody can say precisely what they mean, and a number whose definition is unavailable cannot settle anything.
That failure is usually blamed on discipline. We think it is mostly shape and price. Serious analytics platforms assume an analyst in the loop: someone to define the metric layer, model the events, and tell you which of three retention curves you are looking at. Teams of eight do not have that person. They get a tool built for the analyst, without the analyst, and the result is a lot of charts and very little evidence.
The cheap end fails from the other direction. It is easy to install, gives you a real-time counter, and stops exactly where the interesting questions start — cohorts, funnel windows, segmenting the thing that moved. Meanwhile per-seat pricing means the designer who most needs to see where users drop off is the first person cut from the licence.
So we built the thing we wanted: correct defaults instead of a modelling layer, an agent that writes the query and shows you the query, and pricing on events rather than seats so the whole team can look at the same screen.
What we optimise for
- Time to first answer
- Minutes from install, not a modelling project
- Definitions
- Attached to every metric, in the product
- Who can look
- Everyone on the team — no per-seat gate
- Leaving
- Raw event export, on demand
- The agent
- Always shows the query it ran
These are the trade-offs we make when a decision is close. They are also the ones to hold us to.
// what we believe
Six things we are not flexible about
Operating principles are only useful when they rule something out. Each of these has cost us a feature, a pricing model or a shortcut at some point.
Defaults over configuration
The right cohort anchoring, the right funnel window, the right exclusion of your own team — decided once, correctly, and applied by default. Configuration is what you reach for when the default is wrong, not the price of entry.
Your data stays yours
Full export of raw events, on demand, in a format you can load somewhere else. Lock-in earned by being hard to leave is not a product strategy we are interested in.
Price should track value, not seats
Charging per seat makes teams ration access to their own numbers. We price on events, so the analyst, the designer and the founder can all look at the same thing.
Speed is a feature
A question that takes forty seconds to answer gets asked once. One that takes two seconds gets asked five times, and the fifth is usually the one that matters.
Say what the number means
Retention is three different curves; conversion depends on five hidden choices. We write the definition next to the figure, in the product and in our writing.
// how we got here
The arc of the product
We build in the order that makes each layer trustworthy before the next one is allowed to depend on it: ingestion before analysis, analysis before the agent, and the agent before anything that hides a query from you.
Capability milestones, not funding events
We have not raised a round we can point at, hired a hundred people or won an award, so there is nothing of that kind to list here. What follows is the order the product was actually built in — which is the part that explains why it behaves the way it does.
Deliberately loose on dates: the sequence is what matters, not the calendar.
The beginningFirst event ingested
An HTTP collector, a columnar store and one page that listed events as they arrived. Nothing else. It was enough to prove the part everyone underestimates: getting events in reliably, cheaply, and without losing them under load.
Shortly afterFunnels and cohorts
The first real analysis. We spent longer on the defaults — window handling, cohort anchoring, excluding truncated periods — than on the builder itself, because the defaults are what stop a funnel from lying to you.
NextThe agent
Plain-English questions translated into the same queries the builder produces, with the generated query always visible. Deliberately not a black box: if you cannot read what it ran, you cannot trust what it returned.
ThenSDK coverage
JavaScript and JVM first, then the HTTP API documented properly so any language is a fifteen-line integration. The event schema is shared across all of them, so a property means the same thing wherever it was sent from.
NowRegions and retention windows
Data residency options and longer retention for teams whose compliance reviews ask about both. Unglamorous work that decides whether a company can adopt you at all.
// the team
A small distributed team, organised by what it owns
We are deliberately vague about headcount and specific about responsibility. Every discipline below owns its surface end to end, including the support load it creates.
Product
Decides what a screen leaves out. Owns the analysis surfaces — funnels, cohorts, saved reports — and the definitions attached to every number they show.
Ingestion
Owns the write path from SDK to storage: batching, deduplication, schema-drift detection, replay after an incident. Judged on how boring it is.
Query engine
Owns latency and correctness. Funnel, retention and cohort maths, the materialisations that keep common questions cheap, and the cost per query that our pricing rests on.
Design
Owns density and legibility: what a chart looks like with six hundred rows, what an empty state says, and how an answer admits it is uncertain.
Support
Answers instrumentation questions properly, reproduces integrations against real SDKs, and turns every recurring answer into a documentation change.
Hiring for several of these right now — see the open roles.
// contact
Where to reach us
Mailboxes, not a contact form. Each one is read by the people who own that area.
Sales and evaluations
Pricing for larger workspaces, migration questions, security review packs, or a walkthrough with your own data in front of you.
sales@alitycs.comSupport
Instrumentation help, events that are not arriving, anything that looks like a bug. Include your workspace name and roughly when it started and you will get a useful first reply.
support@alitycs.comSecurity
Vulnerability reports and coordinated disclosure. We acknowledge reports and will tell you what we are doing about them. See the security overview for how we handle data.
security@alitycs.comCareers
Applications and speculative introductions. Open roles and how our hiring process actually runs are on the careers page.
careers@alitycs.comCurious what teams do with it? The customer stories walk through three worked examples, and the blog is where we write up the analysis practice behind them.
Point it at your product and ask something
Free while you are small, with the full analysis surface from the first event. No sales call in the way.
No credit card required. Raw event export available from day one.