Overview
If your B2B SaaS product—like Loom—has public-facing elements (e.g. shared video viewers, commenters, or anonymous users), you may face a hidden challenge: analytics cost blowouts due to massive volumes of public user events.
Most analytics platforms, such as Segment, bill based on monthly tracked users (MTUs). If you send a unique user ID for every anonymous viewer, your MTUs—and your bill—can skyrocket.
Here’s how to track public end user activity while keeping costs and complexity under control.
Real-World Example: Loom
In Loom:
Paying customers are organizations (accounts), who invite internal users (admins, members).
Public users—anyone with a video link—can:
Watch videos
Comment
React or reply
These public users aren’t tied to a CRM record, aren’t targeted for onboarding or upsell, and don’t need to be tracked individually. But their actions may still emit analytics events.
The Problem: Public Usage Can Overwhelm MTU-Based Billing
If you emit a unique user ID for each public visitor, it will:
Inflate your monthly tracked user count
Pollute your analytics tools with thousands of anonymous IDs
Skyrocket costs across Segment, Amplitude, Mixpanel, etc.
Create friction when trying to segment or search through real users
Recommended Solution: Reuse the Account ID as the User ID
To avoid this:
Track all public end users under a single user ID, ideally the account (group) ID associated with the content they’re interacting with.
How It Works
For logged-out or public-facing users:
Set the user ID in your
track()call to the account ID (or shared group ID).Do not emit
identify()calls or send user traits.Optionally add a flag (e.g.
"is_public_user": true) for clarity.
Benefits
Only one MTU counted per public-facing account
No clutter in user tracking systems or CRM tools
Maintains visibility into public usage patterns (views, reactions)
Keeps costs predictable—even at high scale
Caveat: Event Volume Billing Thresholds
Analytics platforms may have event-based backstops to prevent abuse. For example:
Segment historically used a 1,000-event threshold—if a single user ID sends 10,000 events, it may count as 10 MTUs.
This protects platforms from underbilling when one ID carries massive load.
What To Watch
Track event volume per ID (especially viral content)
Use batching or sampling where applicable
Budget for a small bump in MTU counts in extreme cases
When This Pattern Is Appropriate
✅ Use this approach when:
You don’t engage with public users directly (e.g. via email, CRM, sales)
They aren’t part of your core B2B product experience
You only need aggregated insights (e.g. total views, reactions)
🚫 Avoid this approach if:
You want to track or follow up with individual public users
You’re building growth loops or login funnels tied to these interactions
Summary
For B2B SaaS products with public-facing usage:
Track all anonymous or public users under a shared account-level ID to reduce costs, simplify analytics, and stay focused on your actual customers.
This keeps your MTU counts low, your tracking system clean, and your data model aligned with how you engage your users.