Social

Story Protocol

# Story Protocol Active users (daily) Methodology

## 1. Overview

The Story Protocol Daily Active Users (DAU) metric measures the number of unique addresses that initiated transactions on the Story blockchain within a given day. This metric provides insights into daily user engagement and platform adoption by tracking distinct transaction senders. The calculation uses HyperLogLog (HLL) sketches for efficient approximate counting and provides breakdowns across multiple dimensions including chain-level, user type, and product-level aggregations.

## 2. Data sources

- **Story blockchain transactions**: Complete transaction records from the Story blockchain including transaction metadata, timestamps, transaction hashes, and sender addresses
- **Chain availability data**: Configuration data that defines when Story blockchain data becomes reliably available for analysis

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Extract and standardize user activity data from raw Story blockchain transactions
- **Logic**: Read all Story blockchain transaction records and extract key fields including transaction timestamps, transaction hashes, and sender addresses. Cast all data types to standardized formats and assign protocol metadata including chain identifier ('story'), market sector ('blockchains_l2'), and business segment ('blockchain'). All users are classified as 'Transaction sender' type since the metric focuses on transaction initiation activity.
- **Key fields**: `block_timestamp` (transaction timing), `transaction_hash` (unique transaction identifier), `from_address` (transaction sender/user address), `chain` (set to 'story'), `user_type` (set to 'Transaction sender')

### Component B: Daily user aggregation
- **Purpose**: Calculate daily unique active users by counting distinct addresses per day
- **Logic**: Group transaction data by day using timestamp truncation to daily granularity. For each day, identify all unique user addresses that initiated at least one transaction. Apply incremental processing logic to only process recent data when updating existing calculations. Store the distinct user addresses along with their associated metadata for downstream aggregation.
- **Key fields**: `timestamp` (daily truncated date), `user_address` (unique user identifier for DAU counting), `timestamp_grain` (set to 'day'), `chain`, `user_type`, `product_id`

### Component C: HyperLogLog aggregation setup
- **Purpose**: Initialize HyperLogLog sketches for efficient approximate distinct counting across dimensions
- **Logic**: Convert the daily user data into HyperLogLog sketches using a precision parameter of 15 bits for balancing accuracy and memory usage. Group data by timestamp, chain, user type, and product dimensions while initializing HLL sketches for each unique user address. Apply incremental filtering to process only recent partitions when updating existing data.
- **Key fields**: `hll` (HyperLogLog sketch containing user addresses), `timestamp`, `chain`, `user_type`, `product_id`

### Component D: Dimensional breakdowns
- **Purpose**: Create multiple aggregation views across different dimensional cuts
- **Logic**: Generate four distinct dimensional breakdowns from the HLL data: 1) Overall project-level aggregation combining all users regardless of dimension, 2) Chain-level breakdown (though Story is single-chain), 3) User type breakdown (currently only 'Transaction sender'), and 4) Product-level breakdown (currently null as no product differentiation exists). For each breakdown, merge HLL sketches using `hll_count.merge_partial()` and extract final counts using `hll_count.extract()` to get approximate distinct user counts.
- **Key fields**: `dimensions` (breakdown type identifier), `chain_id`, `product_id`, `user_type`, `user_dau` (final distinct user count)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with standardized schema including dimension type, optional dimension values (chain, product, user type), and the calculated DAU metric
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundary logic uses timestamp truncation to day level, with incremental processing supporting month-level partitioning for efficient data management
- **Final calculation**: The final DAU value represents the approximate count of distinct user addresses extracted from merged HyperLogLog sketches, providing scalable distinct counting across potentially large user populations while maintaining acceptable accuracy levels for reporting purposes

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Unique revenue-generating users over a fixed 24-hour window.

Story ProtocolIP

Active users (daily)

Active users (daily)

Competitive landscape