Skip to content
Under Development Frontier tech — early market

BeeRouter

Agentic Session Revenue Router

Stop optimizing pageviews. Start optimizing every visit.

Your loyal daily reader and a drive-by search visitor get the same six banners and the same three prompts today, because nothing decides between them. BeeRouter looks at who this session actually is and picks the one play worth making — and enforces a hard limit on how often anything interrupts.

RPS Revenue Per Session, not RPM — the metric changes before the number does benchmark 1
session loyal reader review page mobile 🇮🇳 IN

Decision · with reasons

  • BeeLink emphasis on commerce-intent page
  • BeeBid standard density loyal reader — not a drive-by
  • BeeWall skipped prompt shown 3 days ago
  • BeePush skipped UX budget already spent
  • BeeMail skipped already a subscriber

UX budget

0 of 1 used

Three modules wanted to ask. None did — the reader dismissed something this week.

RPS · routed vs holdout

Routed ₹13.10
Holdout ₹11.40

a slice routed by nothing, so we can be measured

Concept preview · illustrative data

The problem

What this is costing you right now

01

Your best reader is treated like a stranger

Someone who visits every morning and someone who arrived from a search result and will leave in nine seconds see exactly the same page, the same ad density and the same asks.

02

Three modules asking at once

The push permission prompt, the membership offer and the newsletter popup all fire in the same visit because none of them knows the others exist.

03

Commerce intent, generic banner

A reader on "best phone under ₹15,000" is minutes from a purchase decision, and the page serves them the same generic display it serves everyone.

How it works

What BeeRouter actually does

No black box. Here is the whole mechanism, step by step.

BeeRouter — how it works

  1. 1

    The session gets a description

    New, returning, loyal or bot. What kind of page this is. Device, geography, and which BeeOS modules you actually have running. Consented signals only, evaluated at the edge.

  2. 2

    One play is chosen for this session

    Heavier ad density for the drive-by. Affiliate emphasis on the review page. The membership ask for the reader who comes every day. A toll for the crawler. And for the reader who has already dismissed something today — nothing extra at all.

  3. 3

    The interruption budget is enforced

    One interruption per session by default, with cool-downs shared across every module. This is the layer that stops the pile-up, and it is the reason the router exists at all rather than being a nice-to-have.

  4. 4

    Frustration throttles the router

    A rapid close, an immediate back — the session gets marked as annoyed and the router stops asking for anything. Revenue that costs you the audience is a loss, which is the same principle BeeLab applies to layouts.

  5. 5

    Outcomes are measured against doing nothing

    Every decision and its outcome is logged, and a holdout slice of traffic is routed by nothing at all. Comparing the two is the only honest way to find out whether the router is earning its place.

The decision table is readable, and every routed session records why it went the way it did.
  • One play per session not one stack for everyone
  • Max 1 interruption shared across all modules
  • Readable decision table no black box
  • Holdout measurement routed vs not routed

In context

Where BeeRouter sits on your page

hindinews.example
leaderboard 728×90
below-nav
in-content 336×280
below-article native grid

BeeRouter acts on the whole visit, not on any one slot — which module gets to speak, how dense the ads are, and whether anything asks the reader for something.

On a page like this it might raise ad density for a drive-by visitor, or stay completely quiet for someone who dismissed a prompt yesterday.

Concept preview · illustrative data

Specifications

Full technical specification

Publishers compare specifications, not adjectives. Everything is here, including what depends on partners we do not control.

Context & decisions

Context & decisions
Session context Visitor classification (new, returning, loyal, bot), page intent taxonomy (news, review, tool, evergreen), device and geography, and a map of which modules are available on this site. Evaluated at the edge, privacy-scoped, consented signals only.
Decision engine v1 Transparent rules with a publisher-visible decision table — every routing rule is readable, and every decision records why. Structural: a system that quietly decides what your readers see, and will not tell you its reasoning, is one you cannot hold to account.
Conflict resolution A priority ladder across modules with explicit tie-breaks. This is the anti-pile-up layer — the thing that decides push OR wall OR newsletter, never all three, and remembers which one it already used.
Overrides Per-site and per-section overrides. A rule you disagree with is a rule you can change, without leaving the router.
Decision engine v2 Roadmap — learned policies from outcome data, with champion/challenger testing. Explainability is a hard requirement even then: "why this unit" must stay answerable, or it does not ship.

The UX budget

The UX budget
UX budget Maximum 1 interruption per session by default, with cool-downs shared across every module so they cannot each spend the budget separately. Frustration signals — rapid close, immediate back — throttle the router automatically for that session.

Measurement

Measurement
Measurement RPS (revenue per session) by visitor cohort, a per-decision outcome ledger, and holdout mode: a slice of traffic routed by nothing, so routed and unrouted sessions can be compared directly. That is us measuring ourselves against doing nothing, which is the comparison that matters.
Module dependency Works with whatever you have running. With two modules there are few plays to choose between and the router is close to pointless; with eight it is doing real work. Be honest with yourself about which situation you are in.

Some capabilities depend on third-party approvals and platform policies that are not ours to promise. Where that is the case, the spec above says so explicitly.

Expected impact

What the industry reports

Every number below is an industry benchmark published by a third party. BeeOS has not shipped, so none of these are results we have produced.

1 interruption range per session, shared across every module

The hard limit that stops modules from talking over each other

Cool-downs are shared, so no module can spend the budget separately. A reader who dismisses something is not asked again that session.

Without BeeOS

What decides the stack
Nothing
Loyal reader vs drive-by
Identical treatment
Prompts per session
As many as modules
Commerce-intent page
Generic display
Can you audit a decision
—

With BeeOS

What decides the stack
Session context
Loyal reader vs drive-by
Different plays
Prompts per session
One, capped
Commerce-intent page
Affiliate emphasis
Can you audit a decision
Readable table + per-decision log

Expected difference

One stack for everyone → one play per session

No percentage, because the honest answer depends on how many modules you run. Holdout mode is there so you can measure your own number instead of trusting ours.

RPS

The metric this product optimizes — revenue per session, not per thousand impressions

RPM asks "what did this pageview earn". RPS asks "what did this visit earn".

1

Interruptions allowed per session, by default

Shared across every module. This is the point of the product.

Holdout

A slice of traffic routed by nothing, so we can be measured

If routed sessions do not beat unrouted ones, you should know.

Being straight with you: No uplift figure here, and the reason is structural rather than shy: this product's effect depends entirely on how many plays it has to choose between. Routing between two modules and routing between eight are different products with different ceilings, so a single range would be meaningless. That is also why holdout mode exists — rather than quote you a number, we would rather give you the mechanism to measure the real one on your own traffic.

Works with

Fits into the stack you already run

Platforms BeeOS integrates with — not customers, partners or endorsements.

  • Google AdSense
  • Google Ad Manager
  • AdX (via partner)
  • Prebid.js
  • Amazon APS
  • PubMatic
  • Magnite
  • Index Exchange
  • Sharethrough
  • Sovrn

Glyphs are generic shapes, not brand logos — these are platforms we integrate with, not endorsers.

Questions

BeeRouter — frequently asked

No, and that was a design constraint rather than an afterthought. The v1 decision engine is transparent rules in a table you can read and edit, and every routed session logs why it went the way it did. The v2 learned engine on the roadmap keeps explainability as a hard requirement — if "why this unit" stops being answerable, it does not ship.

The opposite — it exists because your modules already do. One interruption per session by default, with the budget and cool-downs shared across every module so they cannot each spend it independently, and automatic throttling when a reader shows frustration signals. Without a router, three modules asking separately is the default behaviour.

No, but be honest about the arithmetic. A router choosing between two plays is barely a router. If you run Module 1 and nothing else, this will not do much for you and we would rather say so now. It gets genuinely useful somewhere around four or five active modules.

Holdout mode. A slice of your traffic is routed by nothing at all, and you compare RPS on routed sessions against unrouted ones. That is us submitting the product to a test it can fail, which is the only version of this claim worth anything.

Because RPM asks what a pageview earned and this product acts on the whole visit. A decision that shows fewer ads to a loyal reader and converts them to a member looks like a loss in RPM and a win in RPS. Optimising the wrong metric is how you end up with a great dashboard and a shrinking audience.

Under active development as part of BeeOS Module 5, and realistically it lands after the modules it routes between. Join early access for priority onboarding.
Under Development

Be first in line for BeeRouter

BeeRouter is under active development. Early-access publishers get priority onboarding, founder-level support on WhatsApp, and locked-in launch pricing.

No spam — we write only when something real ships.