website

twitter

Infrastructure

Bloom Trading Bot

# Bloom Trading Bot Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user of the Bloom Trading Bot on Solana. This metric answers the business question: "How much revenue does each active user generate on average per day?" The calculation divides daily revenue (derived from trading fees) by the number of daily active users, providing insight into user monetization effectiveness.

## 2. Data sources

- **Solana native token transfers**: SOL transfer events to specific fee collection addresses on the Solana blockchain
- **End-of-day price feeds**: Token price data for converting SOL amounts to USD values
- **Token metadata**: Information for handling token decimal places and conversions

## 3. Step-by-step calculation

### Component A: Fee collection identification
- **Purpose**: Identify all fee payments made to the Bloom Trading Bot
- **Logic**: Extract native SOL transfers directed to the fee collection address `7HeD6sLLqAnKVRuSfc1Ko3BSPMNKWgGTiWLKXJF31vKM`. Filter out self-transfers where the transaction signer is the same as the fee collection address to avoid internal transfers. Each transfer represents a trading fee payment from a user to the bot service.
- **Key fields**: `block_timestamp` for timing, `transaction_signer` for user identification, `amount` for fee value, and `to_address` for fee destination validation

### Component B: Daily fee aggregation and USD conversion
- **Purpose**: Calculate total daily fees in USD
- **Logic**: Group fee transfers by day using timestamp truncation. Sum the transfer amounts and convert from lamports to SOL by dividing by 1e9. Apply end-of-day price conversion to transform SOL amounts into USD values. This creates the daily revenue component needed for ARPU calculation.
- **Key fields**: `timestamp` for daily grouping, `fees` for aggregated SOL amounts, and USD-converted `fees` for revenue values

### Component C: Daily active user counting
- **Purpose**: Count distinct users who paid fees each day
- **Logic**: Identify unique transaction signers from fee payment transactions on each day. Use HyperLogLog aggregation to efficiently count distinct users across multiple dimensions including project level, chain level, user type, and product level. This scalable approach handles large user volumes while maintaining accuracy for distinct counting.
- **Key fields**: `user_dau` containing distinct transaction signers, `timestamp` for daily boundaries, and dimension fields for different aggregation levels

### Component D: Revenue metric preparation  
- **Purpose**: Standardize revenue data for ARPU calculation
- **Logic**: Transform the USD-converted fee data into a standardized revenue metric format. Apply the finalize metric process with a fill_zeros strategy to ensure complete daily coverage without gaps. This ensures consistent data availability for the ARPU calculation.
- **Key fields**: `revenue` containing daily USD fee totals, `timestamp` for date alignment, and dimension fields for matching with user data

### Final aggregation
- **Combining components**: The `calculate_arpu` macro joins the revenue metric with the daily active user metric on matching date and dimension fields
- **Currency conversion**: Revenue values are already converted to USD in the fee aggregation step using end-of-day price feeds
- **Time aggregation**: Both revenue and user counts use daily timestamp truncation with consistent boundary logic
- **Final calculation**: ARPU is calculated by dividing daily revenue by daily active users for each day. The `finalize_metric_arpu` macro applies a fill_zeros strategy to handle days with missing data, ensuring complete time series coverage for reporting and analysis

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

Bloom Trading Bot

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape