A collection of representative B2B lead discovery scenarios, showing how AI identifies qualified sales opportunities from real-world business conversations.
How Many Users Never Opened Your Bot Again After Day Three — Building Telegram Bot Engagement Analytics From Scratch
After launching multiple customer-facing Telegram Bots, the team cannot answer the most basic questions: what does retention look like, which features are actually used, and where do conversion paths break. This article gives data product leads a practical framework from defining core events to building an analytics dashboard.
This is an illustrative scenario designed to explain the product’s judgement logic. It is not a real customer case, testimonial, contract, revenue result, or conversion claim.
01Situation
02Signal judgement
03Confidence vs priority
04Human next step
Signals considered
- multiple Bots lacking unified event tracking and definitions
- team unable to answer basic user retention questions
- per-Bot feature usage data scattered across different logs
- product iteration lacking data support, relying primarily on intuition and user feedback
Your team has launched more than one Telegram Bot. Some handle customer service, some push content, some do order lookups. Every Bot is working — messages go out, commands get responses, and user counts are gradually ticking up. But when asked “what does retention look like across these Bots,” you find yourself opening a database, running a few SQL queries, and delivering a number you are not fully confident in yourself.
It is not that you lack data — every Bot has logs, a database, and service monitoring. The problem is that this data was never organized into an analytics language.
Define What Counts as a “User” and What Counts as “Active” First
The first step in building an analytics system is not choosing a tool — it is defining concepts. In the Telegram Bot context, even the two most basic concepts — “user” and “active” — are not self-evident.
On the definition of “user”: does a unique Telegram ID that has sent at least one message to the Bot count as a user? If you adopt this definition, your user count may look large — including everyone who sent a single “/start” out of curiosity and never returned. If you tighten the definition to “a user with at least one interaction in the last thirty days,” your active user count might be an order of magnitude smaller than the total. The gap between these two numbers is itself informative.
On the definition of “active”: what counts as a “meaningful interaction”? Tapping a button? Typing text? Completing the last step of a business flow? If you only count message volume, a user who repeatedly asks the same question may appear more active than one who silently completes an order through button taps — but that clearly does not match business intuition.
The recommended starting point is defining three groups of events: activation events (the first time a user completes a business-meaningful action, not just sending /start), core action events (behaviors directly tied to the Bot’s core functionality — completing a query, submitting an order, viewing a key piece of content), and retention window events (whether a user still performs core actions on Day N after initial activation). With these three event groups defined, you can begin to answer the truly important questions about user behavior.
Data Collection Must Be Designed Into the Bot Logic, Not Added Later
A mistake many teams make is treating analytics instrumentation as a “later optimization” — get the Bot functionality running first, add tracking later. The result is that “later” never comes, or when it does, it requires changing large amounts of existing code.
Data collection should be designed into the Bot’s business logic architecture. Specifically, when a user action triggers one of the Bot’s processing flows, at key nodes in that flow — request arrival, business logic execution, response return — a structured event record should be produced synchronously. This event record should contain at minimum: event name, trigger time, user identifier, Bot identifier, and business parameters relevant to the event.
One detail that requires careful handling: what data should enter the analytics pipeline and what should not. Not all user interactions need to be recorded — private messages sent by users, sensitive data involved in authentication flows, and purely technical heartbeat requests should be excluded from analytics data. When designing instrumentation, you need to balance “analytics completeness” against “privacy minimization.”
Technically, asynchronous writes are recommended — events are written to a buffer layer (such as a message queue or log stream) after being produced, consumed by an independent service, and written to analytics storage — rather than synchronously writing to the database in the Bot’s message processing main thread. This prevents analytics write latency from affecting Bot response speed.
Data Telegram Cannot Provide and Data You Do Not Need
When planning an analytics system, an important exercise is distinguishing between “the data you wish you had” and “the data you can actually get.” Many teams initially design a long list of ideal user attributes — geographic location, device type, traffic source, and behavior within groups. Then they discover the Telegram Bot API provides none of this.
What the Bot API can provide is limited: user ID, username (optional), language code, whether the user is a member of a given group, and the user’s interaction behavior within the Bot session. You cannot get the user’s phone number (unless explicitly authorized through Telegram Login Widget), cannot get the user’s real name or any personal details beyond the display name, and certainly cannot get any behavioral data about the user outside your Bot — in other groups, channels, or elsewhere.
This limitation is not a flaw — it is a boundary. Designing an analytics system within this boundary means your object of analysis is always “the relationship between the user and your Bot,” not “the complete profile of the user as a person.” Your analytics dashboard should be organized around this relationship: how users discover the Bot, how they complete initial activation, how they use core features, and under what circumstances they churn.
At the same time, some data you cannot get is also data you do not genuinely need. For example, precise geographic location — most Bot analytics scenarios do not actually require it. What you may need is the user’s time zone to optimize message push timing, and that can be approximately inferred from the user’s language code.
Your First Dashboard Only Needs to Answer Three Questions
When data starts flowing into analytics storage, the most common mistake when building the first dashboard is trying to display every possible metric on a single page. The result is that nobody looks at it.
The first dashboard should focus on only three questions. Question one: what percentage of new users go from first contact to completing a key activation action? This metric tells you whether your Bot’s onboarding flow is effective — if a large number of users send /start and then never complete any business-meaningful action, your problem is onboarding, not a lack of features.
Question two: what percentage of activated users are still active on Day 7 and Day 30? This metric tells you whether the ongoing value your Bot provides is sufficient. Benchmarking against industry averages is not meaningful; benchmarking against your own previous week is. If the retention curve is declining, you need to identify what changed in the product before the decline started.
Question three: what is the distribution of core feature usage — which feature is used most frequently, which is barely touched? This distribution tells you not “which feature to cut” but “what users primarily use the Bot for” — and that answer is very likely different from what you intended when you designed the Bot.
The value of an analytics system is not the reports themselves — it is enabling the team to answer questions about user behavior with data rather than intuition. The build does not need to be perfect on day one. Get one Bot through the full loop of “define events → collect data → produce three core metrics” first, then expand to other Bots and more sophisticated analysis scenarios.
Frequently asked questions
What user data can a Telegram Bot actually access for analytics?
The Telegram Bot API provides a limited set of data — this is both a technical constraint and a privacy protection. What you can access: the user's Telegram ID (a numeric identifier), username (if set by the user), language code, and whether the user is a member of a given group. What you cannot access: the user's phone number (unless explicitly authorized via Telegram Login Widget), the user's real name beyond display name, the user's contact list, and any behavioral data about the user outside of their interactions with your Bot. The key conclusion: you can only analyze the interaction between the user and your Bot — not the user's overall profile on the Telegram platform.
We already have database logs. Why do we need a dedicated analytics system?
Database logs record 'what happened' — which command the user sent and what response the Bot returned. But an analytics system needs to answer 'what does it mean' — is this command a one-off curiosity test or part of an ongoing usage pattern? Database logs can tell you how many messages came in yesterday, but they cannot tell you whether this week's new users differ from last week's in their Day 3 retention. The value of an analytics system is transforming raw events into business-meaningful metrics — activation rate, retention curves, feature usage funnels — and these require dedicated event definitions, aggregation logic, and a visualization layer.