> For the complete documentation index, see [llms.txt](https://suzuna.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://suzuna.gitbook.io/whitepaper/product-metrics.md). # Product Metrics SUZUNA uses a lightweight internal analytics layer to understand how the product is being used. The system records a focused set of operational events. Enough to measure adoption and engagement, and no more. Core Data Model The internal database is organised around four entities: Users → Agents → Usage Events → Checkpoints The first three record what happens inside the product. The fourth publishes the totals to BNB Chain. Users The user record identifies a person internally and tracks activity over time. SUZUNA does not store raw Telegram user IDs. Each ID is hashed with HMAC-SHA256 and discarded in the same operation, so only the hash is retained. The hash is stable, meaning returning users are recognised, but it cannot be reversed. | Field | Purpose | | -------------------------- | --------------------------------------------------------- | | Internal user ID | Identifies the user across the product | | Hashed Telegram identifier | Recognises a returning user without storing their real ID | | Created timestamp | When the account first appeared | | Last active timestamp | Most recent activity | No Telegram username, display name, or profile photo is requested or stored. Agents Each deployed agent is bound to a single BNB Chain wallet. | Field | Purpose | | --------------------- | ---------------------------- | | Agent ID | Identifies the agent | | Internal user ID | Links the agent to its owner | | Wallet address | The wallet being analysed | | Chain | The supported blockchain | | Status | Active, paused, or deleted | | Created timestamp | When the agent was deployed | | Last active timestamp | Most recent use | Nothing in this record is a credential. A wallet address is public information, the same string anyone can paste into a block explorer. Usage Events Three event types are recorded. | Event | Meaning | | --------------- | --------------------------- | | AGENT\_DEPLOYED | A user created an agent | | AGENT\_USED | An existing agent was used | | AI\_QUERY | A user submitted a question | Each event contains an event ID, internal user ID, agent ID, event type, and timestamp. The content of a question is never stored. An event records that a query occurred, not what was asked. Question text is also excluded from application logs. Usage events are the sole source of truth for every metric below. Rows are only ever added, never edited or deleted. Product Metrics Five metrics are derived from these events. Two are cumulative and three are measured inside a single seven-day window, so the two groups are not directly comparable. | Metric | Measured how | Behaviour | | ------------------- | ---------------------------------------------------------------------- | --------------- | | Total Users | Everyone who has ever started SUZUNA, counted to the end of the period | Only increases | | Agents Deployed | Every agent ever created, counted to the end of the period | Only increases | | Weekly Active Users | Unique users active inside the seven-day period | Rises and falls | | Active Agents | Unique agents used inside the seven-day period | Rises and falls | | AI Queries | Questions submitted inside the seven-day period | Rises and falls | A period metric falling between checkpoints is normal. It reflects activity in that specific window, not a loss of users. Metrics are always computed from real usage events. They are never entered by hand or estimated. On-Chain Usage Records Every seven days SUZUNA aggregates these five metrics and publishes them to a smart contract on BNB Chain. Each publication is called a checkpoint and contains the five metrics for that window, along with the period's start and end times. | Property | Behaviour | | -------------------- | ------------------------------------------- | | Frequency | One checkpoint every seven days | | Contents | Five metrics, plus the period start and end | | Update function | None exists in the contract | | Delete function | None exists in the contract | | Previous checkpoints | Preserved, never overwritten | | User-level data | Never published | Individual user actions are never written to the blockchain. Only the aggregated counts for a completed period are published. What a checkpoint proves A checkpoint proves that SUZUNA published a specific set of numbers at a specific time and cannot quietly revise them afterwards. It does not independently verify that the underlying data is accurate. The contract records what the backend computes. The published figures are available at suzunai.xyz and can be read directly from the contract on BNB Chain. Product Usage Model SUZUNA's analytics follow the core product workflow: Users → Agents → Queries → Returning Usage This gives a clear view of adoption and engagement while keeping the internal model limited to what the product actually needs. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://suzuna.gitbook.io/whitepaper/product-metrics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.