users, average session duration
1000, 8
1500, 8
2000, 8
3000, 8
5000, 8
22000, 12
32000, 12
52000, 12
140000, 15
300000, 15
400000, 15
380000, 15
500000, 15
700000, 15

To estimate your cloud infrastructure costs using e-commerce metrics, you must translate business traffic and user activity into computing resources like compute instances, database storage, and network bandwidth. [1] The core bridge between these two worlds is your peak traffic volume and your compute-to-db resource consumption per user action.

Before calculating technical resource requirements, map your core conversion funnel to determine the total volume of different user interactions. Using your known e-commerce metrics, map out:

• Total Monthly Sessions: Your baseline traffic volume.
• Add-to-Cart Volume: $\text{Sessions} \times \text{Add-to-Cart Rate}$.
• Total Checkout Actions: $\text{Sessions} \times \text{Conversion Rate}$. [2]

Traffic numbers alone are insufficient for cloud capacity planning because different user actions place vastly different loads on your servers. You need to assign an infrastructure cost weight to different activity states:

Cloud infrastructure is priced based on provisioning for peak demands, not averages. Use your web traffic and activity metrics to find your Peak Concurrency.

1. Find Peak Hourly Traffic: Identify your busiest hour of the year (e.g., Black Friday or marketing drops). Typically, peak hourly traffic can be $5\times$ to $10\times$ your average hourly traffic. [8]
2. Calculate Concurrent Users ($CU$): Use the equation: $$CU = \frac{\text{Peak Hourly Sessions} \times \text{Average Session Duration (in seconds)}}{3600}$$
3. Determine Server Capacity: If your target application server instance (e.g., an AWS t3.medium or Google Cloud e2-medium) can safely handle 150 concurrent browsing users, your baseline server requirement is:

$$\text{Required Instances} = \frac{CU}{150}$$

Data transfer out (egress) from your cloud provider to the public internet is a major variable expense. Use your traffic and page weight metrics to calculate this cost.

1. Determine Average Page Weight: Look up your average site page size (e.g., 3 MB due to high-res product images).
2. Track Pages per Session: Use your analytics tool to find the average number of pages viewed per visit (e.g., 5 pages).
3. Calculate Total Monthly Egress Data:

$$\text{Total Data (GB)} = \frac{\text{Monthly Sessions} \times \text{Pages per Session} \times \text{Page Weight (MB)}}{1024}$$

4. Apply Provider Rates: Multiply the total gigabytes by your cloud provider’s egress rates (typically around $0.08 per GB on major clouds like AWS).

Unlike application servers that can dynamically scale down to zero when traffic stops, your transactional databases must store data permanently and require high performance for write actions.

• Database Sizing: Calculate total monthly transactions ($\text{Sessions} \times \text{Conversion Rate}$). Multiplied by the metadata payload size per order (usually around 10 KB to 50 KB), this determines your storage growth rate.
• Database IOPS (Input/Output Operations Per Second): High conversion periods trigger massive concurrent database writes. To prevent checkout bottlenecks during high-volume spikes, provision database IOPS based on your peak purchase transactions per second, rather than average monthly sales. [19, 20]

To estimate your monthly cloud bill based on e-commerce metrics, combine the cost segments:

$$\text{Estimated Cloud Cost} = \text{Compute Costs (Peak Concurrency)} + \text{Database Costs (Transaction Volume)} + \text{Network Egress Costs (Traffic } \times \text{ Page Weight)}$$

To calculate your Firebase Cloud Costs using your specific user metrics and Firestore Enterprise Edition paired with Cloud Storage, you need a formula that maps business activity to exact cloud infrastructure billing units. Under the Firestore Enterprise Edition model, operations are billed via Read Units and Write Units (where 1 unit = 4 KiB of data), rather than a flat per-document count like the Standard edition. [1, 2] The comprehensive cost formula and its application across your traffic tiers are broken down below.

The total monthly bill is the sum of your Firestore compute operations, Firestore data retention, Storage usage, and Network data transfer out (Egress). $$\text{Total Monthly Cost} = \text{Firestore Reads} + \text{Firestore Writes} + \text{Firestore DB Storage} + \text{Storage Disks} + \text{Network Egress}$$

To tie this directly to your list metrics (Monthly Sessions and Average Customer Duration in minutes), we must project how many operational events occur per minute of an active session.

• Firestore Read Cost: (Note: Firestore Enterprise starts at $0.05 to $0.30 per million read units depending on your committed use discounts). $$\left(\text{Sessions} \times \text{Duration} \times \text{Reads per Min} \times \text{Avg. Read Units}\right) \times \frac{$0.05 \text{ or } $0.30}{1,000,000}$$

• Firestore Write Cost: (Note: Enterprise write units cost roughly $0.208 per million). $$\left(\text{Sessions} \times \text{Duration} \times \text{Writes per Min} \times \text{Avg. Write Units}\right) \times \frac{$0.208}{1,000,000}$$

• Network Egress Cost (Data Sent to User) (Note: Firebase network egress is $0.12 per GB) $$\left(\text{Sessions} \times \text{Duration} \times \text{Data Payload Transferred per Min in GB}\right) \times $0.12\text{/GB}$$

• Firestore Database Storage: $\text{Total GB Data Retained} \times $0.00032\text{ per GiB hour}$ (~$0.23/GB/month).
• Cloud Storage (Assets/Files): $\text{Total GB Files Stored} \times $0.026\text{ per GB/month}$. [7, 8, 9]

To ground the formula in reality for an active, high-engagement application (like a live tracker or dashboard environment mirroring your 8–15 minute durations), we apply these standard baseline activity multipliers per user session:

1. Reads per Minute: 20 document reads/min (polling or initial feed hydrations).
2. Writes per Minute: 2 document writes/min (saves, status updates, or clicks).
3. Average Document Payload Size: $\le$ 4 KiB (counts as exactly 1 Read/Write unit).
4. Egress per Minute: 0.002 GB (2 MB) of background asset syncing/data streams per minute.

Applying the formula using the multipliers above reveals how costs grow with your provided data:

Note: These estimates cover the runtime activity. You must add your base data retention to this bill (e.g., if your 700,000 users leave behind 500 GB of permanent data in the Firestore database, add an extra $115.00/month for static database storage).

The total monthly cost framework is adjusted as follows: $$\text{Total Monthly Cost} = \text{Firebase Base Stack} + \text{Cloud Semantic Analysis Cost} + \text{Vertex AI Cost}$$

• Google Cloud Natural Language API (Semantic Analysis): Billed per “Text Unit”. A unit is a document (or portion of text) under 1,000 characters sent to the API.
• Standard Rate: $1.00 per 1,000 units (with a monthly free tier of 5,000 units).
  • Formula: $\left(\text{Sessions} \times \text{Semantic Triggers per Session}\right) \times \frac{$1.00}{1,000}$ [6, 7, 8, 9]
• Google Vertex AI (e.g., Gemini & Text Embeddings): Billed per 1 Million Tokens. Assuming a combination of Gemini Pro/Flash features and Vector search embeddings:
• Standard Rates: $0.15 per 1M input tokens (Gemini Embedding 001) or $0.075 per 1M input tokens (Gemini Flash).
  • Formula: $\left(\text{Sessions} \times \text{AI Queries per Session} \times \text{Tokens per Query}\right) \times \frac{\text{Token Price}}{1,000,000}$ [2, 10, 11]

To keep calculations uniform with your traffic cohorts, assume a baseline where user activity triggers the backend to analyze text and fetch AI results:

1. Semantic Analysis Interaction: A user performs 2 text submissions per session (e.g., leaving comments, processing
2. product feedback, searching complex strings), averaging 1,500 characters per submission. This equals 4 Text Units per session.
3. Vertex AI Interaction: A user makes 3 distinct prompts/queries to a Gemini-powered feature per session.
   1. Each query averages 500 input tokens (including context windows or system instructions), totaling 1,500 input tokens per session. [2, 12, 13]

Combining your original Firebase calculation with the added Google Cloud Natural Language API and Vertex AI workloads shows how your costs scale:

Notice that Semantic Analysis via the Natural Language API adds significantly more cost at higher volumes than standard text embeddings. This occurs because the Natural Language API operates on a flat per-character unit structure, whereas modern models (like Gemini on Vertex AI) offer highly competitive token pricing. If you use Vertex AI for semantic vector indexing (via Vertex AI Vector Search), you will also introduce a static cost for keeping the search index running continuously in the background (typically around $150 to $300/month per active index node depending on shard sizes)

Based on a 4% Conversion Rate (CVR) and a $10 Average Order Value (AOV), the revenue is calculated using the formula:

$\text{Revenue} = \text{Users} \times 0.04 \times $10$

(or simpler, each user generates an average of $0.40). The session duration metrics show high user engagement but do not directly change the revenue outcome since the CVR and AOV are held completely fixed.

users = [1000, 1500, 2000, 3000, 5000, 22000, 32000, 52000, 140000, 300000, 400000, 380000, 500000, 700000]
durations = [8, 8, 8, 8, 8, 12, 12, 12, 15, 15, 15, 15, 15, 15]
cvr = 0.04
aov = 10

results = []

for u, d in zip(users, durations):
    orders = u * cvr
    revenue = orders * aov
    results.append((u, d, orders, revenue))

for r in results:
    print(f"Users: {r[0]:,}, Duration: {r[1]} mins -> Orders: {int(r[2]):,}, Revenue: ${r[3]:,.2f}")