A Billing Limit Should Never Break Your Site

The Two Ways Usage-Based Pricing Goes Wrong

Every usage-priced analytics product eventually faces the same question: what happens when a customer blows past their allowance? The industry has settled on two answers, and both punish the customer.

Fail closed: the vendor stops collecting. Your best month of the year -- a launch, a press hit, a viral post -- is exactly when your analytics goes dark. The traffic spike that mattered most is the one you can't see.

Auto-bill: the vendor keeps collecting and sends you an invoice you never agreed to. The spike still costs you; you just find out at the end of the month.

ClickStream's pricing has two packages: Explore is $0 with 5,000 human pageviews and 25,000 Signals Coverage units/month, no card, no charges, and analytics that pause at the limit (we keep counting usage so you can see what an upgrade would cost); Pro is $99/month with 25,000 human pageviews and 250,000 Signals Coverage units included. Paid overage is automatic: $50/additional 100,000 human pageviews and $200/additional 1M Signals Coverage units.

A billing limit is an accounting fact. It should never become an engineering event on your website.

Automatic Overage Billing, No Feature Trap

Fail-open collection would be a hollow promise if it silently changed feature access. Paid makes the rule explicit: automatic usage billing applies at the published overage rates after the included allowance, while the launched capability set remains available.

This is enforced at the package level, not just in policy. Explore has no charges and pauses analytics at its allowance; Pro is $99/month with automatic usage billing. Cross-channel DSP activation for ad placements is coming soon.

If you never upgrade, Explore remains $0 and pauses analytics at its published allowance, while we keep counting usage so you can see what an upgrade would cost. Paid billing is automatic: $99/month, with the published human-pageview and Signals Coverage overage rates.

CRM integrations and audience/data export are part of the launched capability set in both packages, subject to package limits. ClickStream is visitor intelligence that integrates with your CRM, not a CRM.

The One Hard Stop, and Why It's Fair

Explore's published thresholds are 5,000 human pageviews and 25,000 Signals Coverage units/month. Paid includes 25,000 human pageviews and 250,000 Signals Coverage units, with automatic billing for published overage units.

The reasoning is simple economics: Explore has no payment method and no overage path, so analytics pause at 5,000 human pageviews or 25,000 Signals Coverage units/month. The script tag loads asynchronously and an over-limit collection request is invisible to your visitors. Your pages keep rendering; only analytics pause. Pro continues under automatic usage billing at its published rates.

Explore is a bounded product demo: it includes every currently launched capability, 5,000 human pageviews and 25,000 Signals Coverage units/month, with no card and no charges.

You're Billed for Humans, Not Bots

The second trust decision sits underneath the first: what counts as usage? ClickStream bills human pageviews and tracks bot and AI classification through Signals Coverage units. That definition is published: Explore includes 25,000 units/month and Pro includes 250,000.

ClickStream's detection layer classifies traffic across 11 bot categories, drawing on a registry of 158 named bots -- including 38 named AI agents such as GPTBot, ClaudeBot, and PerplexityBot. Classified traffic uses the separate Signals Coverage allowance, never the human pageview allowance.

Why meter usage at all? Because non-human traffic still creates real compute. The published meter will keep that cost honest without turning cross-channel DSP activation for ad placements into a promise; that capability is coming soon.

And when an account exhausts its coverage budget without paid overage? Same principle as everywhere else: sites fail open through cached, sampled, aggregate, or default classifications. Your site keeps working; classification degrades gracefully instead of erroring.

The API Fails Open Too

Fail-open thinking extends into the client library your page code calls. The Signals SDK (@clickstreamhq/signals, currently a developer preview at 0.1.0-alpha) is designed so that a missing, delayed, or budget-exhausted snapshot can never take your page down with it:

• getVisitorOrNull() resolves to null instead of throwing when no snapshot is available -- render first, personalize second.
• If the API rate-limits a read with a 429, the client reuses its last cached snapshot rather than failing.
• When Signals Coverage is exhausted, the client surfaces placeholder snapshots flagged with coverageMode: 'degraded' -- so you can see you're degraded -- and those placeholders are built to fail personalization gates closed: helpers like isHighIntent() return false rather than guessing, while the page renders normally.

Collection fails open; personalization decisions fail safe. In practice that looks like this:

import { configure, getVisitorOrNull, isBot, isHighIntent } from '@clickstreamhq/signals';

// configure() must run before any visitor read
configure({ apiKey: 'cs_live_your_key' });

// Resolves to null instead of throwing when no snapshot
// is available -- your page renders either way.
const visitor = await getVisitorOrNull();

if (visitor && !isBot(visitor) && isHighIntent(visitor)) {
  // visitor.scores.intent >= 70 -- safe to show the high-intent CTA
  showDemoBanner();
}

If the snapshot never arrives -- network issue, coverage exhausted, brand-new visitor -- visitor is null, the condition is false, and the page simply ships its default experience. No error boundary required, no blank hero while a personalization call times out.

The same posture runs server-side. Every one of the behavioral scoring models executes inside an isolation wrapper at the edge: if a model crashes on a weird event, it degrades to defaults and event ingestion is never delayed. Even account suspension is engineered politely -- a suspended account's script URL serves a silent one-line comment, not console errors or a broken tag.

The Numbers, Published

Trust in billing is mostly a function of whether the vendor will write the numbers down. Here is the package model, with unresolved amount and meter decisions called out plainly:

A few details worth calling out:

• Explore has no charges. It includes visitor intelligence, audience resolution and building, realtime signals, CRM integrations, and audience/data export, subject to strict limits.
• Paid uses automatic usage billing. It is $99/month, with $50/additional 100,000 human pageviews and $200/additional 1M Signals Coverage units. Plan quotas never block collection; it stops only if you set a monthly spend cap and reach it.
• Cross-channel DSP activation for ad placements is coming soon. ClickStream resolves, builds, and exports audiences for activation through CRM integrations; it is visitor intelligence, not a CRM.

The Bottom Line

Analytics pricing is a trust exercise, because the vendor controls both the meter and the consequences of the meter. Our position is that the consequences should always land on the bill, never on your website:

• Both packages preserve the launched capability set -- package limits determine access volume, not feature gates
• Pricing decisions stay visible -- the Paid amount and human-pageview/Signals Coverage rates are published here and on the plans page
• The client fails safe -- getVisitorOrNull(), cached-snapshot reuse, and degraded-mode placeholders keep pages rendering
• The quotas are published -- prices, resolutions, seats, and replay retention are the same numbers the billing code enforces

Fail-open billing is a one-way promise: when something has to give, it's our invoice logic that bends -- not your website.