Statist: Collecting Events Is Only Half the Job

Andrey heads a department that builds tools for collecting and analysing product analytics and for running experiments. He describes himself as an engineer at heart: part of his career went into data analysis, he wrote JavaScript, managed teams, wrote Go and a little Kotlin — by now, he says, he has probably forgotten how.

He joined Tinkoff as an engineer in one of the teams and remembers an unusual vacancy with no specific stack requirements: he was interviewed on whatever he happened to be working with at the time, JavaScript as far as he recalls. Then came a project for collecting and sending performance metrics from client applications inside the base technologies department; Andrey took charge of the small team building it, and the project grew into a product that also gathered product analytics.

He essentially built the team himself: it grew, was split into teams, processes were set up, and he became the head of the product; from the new year another team joined him, the platform for experiments and A/B testing, which they agree to cover separately.

The product is internal first of all: it replaced analytics products from external vendors, and its users are colleagues inside the company, from engineers to product analysts — probably thousands of them, by Alexander's reckoning.

The hard part is not collecting data: it reflects many details of the product domain, and without knowing them the collected data may be unsuitable for analysis. So a separate strand of work is checking accuracy, removing duplicates, and giving users practical guidance. The event catalogue serves the same goal: users annotate the analytics they send, everyone else can see what exists in the system, and the metadata feeds SDK code generation.

The first diagram starts with a large and, as Andrey admits, complicated SDK box — for Android, iOS and the web. The SDKs exist so that clients never work against a bare API: they cache events to reduce data loss and help prevent integration mistakes.

Some newer languages were contributed under an inner source model: teams elsewhere in the company that lacked an SDK for their platform were given the contracts and implementation rules, and returned code that many people now use. Alexander notes that this way a team receives not only requests but finished functionality.

Andrey agrees, but warns that sustaining the culture is not easy — nobody can be forced to dig into someone else's systems, so his team helps, fills in parts and points out mistakes. The alternative would be holding expertise in Java, .NET, Go, C++ and plenty of other stacks.

Code generation also carries semantic versioning: a backwards-incompatible change will most likely break the build on iOS and Android, while on the web it shows up as a hint in the TypeScript types.

The second diagram opens up the most laborious box. Everything starts at the collector — an API that accepts telemetry: system events and whatever the person does in the application, tapping buttons, moving between screens, searching, receiving push notifications.

The upper branch came first historically: events are turned into metrics and registered in the in-house observability platform Andrey calls Sage, after which its own ecosystem takes over with dashboards, alerts and anomaly detection.

The analytics branch enriches events with the device type, operating system version, and application to help investigate errors. Geo data is collected when the user has permitted it.

Events also receive the state of the user profile at the time they occurred. This matters for experiments: analysts can identify which experiment a user was in when they performed an action.

Two storages follow: an analytics one for ad hoc scenarios — conversions, monthly active users, groupings, segmentation, user journeys, support investigations — and a cold one, used for automation, ETL pipelines, data marts and notebooks.

On technology: the collector and the pipeline are written in Go, a lot of automation is in Python, the queue is Kafka provided as a service by another team, user profiles live in Cassandra also taken from the in-house platform, geo data and device type come from a neighbouring service, and cold storage is meant to move to S3. Ad hoc analytics uses ClickHouse. At the time of the interview there is no internal managed service for it, so the team operates it themselves.

Andrey states the position plainly: they are closer to a stream-aligned team that builds its own product and consumes platform services rather than spending effort maintaining them; Alexander adds that the result is a platform-like product sitting on top of the base platforms.

Asked how he manages the workload, Andrey describes the split: every subdomain has its own lead — an SDK team with code generation and event delivery, a processing team owning the analytical mechanics, and a front-end team with their own UI on top of the data. Alexander calls it divide and conquer.

Large changes go through RFCs and ADRs: the subdomain tech leads reach consensus, and when outside expertise is needed the decision is taken to an architecture review. What Alexander values in this is the ability to come back later and see the context a decision was made in, and whether it is time to revisit it.

Andrey holds the balance between engineer and manager of some fifty people through delegation and what he calls meritocracy: he no longer makes the architectural decisions himself, and the written documents replace the one keeper of knowledge you would otherwise have to hunt down.

Immersion in the business domain matters to him: he and the platform's product manager study competing products, and he watches talks from Yandex Metrica engineers, because looking at numbers and looking at the right numbers are different things.

Andrey advises mid-level and senior engineers to choose management only if they want that role; otherwise, they can keep growing as engineers. Both paths require understanding the business domain: the aim is to improve the product, not simply complete assigned tasks. Alexander adds that demand for building systems in-house instead of buying vendor software has opened more opportunities for advanced engineering work.

Curiosity can be supported through tutorials and conference talks, then books by Tanenbaum and Kleppmann, engineering blogs, and studying working systems. Alexander adds research papers to the list. Andrey suggests reading technical books around a concrete question, such as sharding or replication, rather than always working through them from beginning to end.