DEV Community: Anthony Yerhot

From Traffic to Behavior: Why I Built Shape Beacon

Anthony Yerhot — Tue, 18 Aug 2026 01:05:30 +0000

I deployed my first public domain earlier this year. I learned something very quickly: traffic according to Cloudflare is defined by something as small as a wispy breeze coming from a crawling script, not the stampede of human feet.

I got pretty pumped up by the stats Cloudflare was feeding me. But I was skeptical and wanted more.

I started with a simple KV counter. It just counted how many views my splash page had.

Then I put those numbers next to Cloudflare's.

My worker: 23 page views.

Cloudflare: 649 unique visits.

Same site. Same week. A very different story.

I still wanted more data.

Not bounce rate, clicks, or page views.

I wanted something that actually measured the physical interaction happening on my site.

So I created my own layer of analytics: Shape Beacon.

With this tool, I can look at that same week and get a different picture. Shape Beacon detected meaningful behavioral interaction in only 10 sessions during that same period.

So what is it actually doing?

Shape Beacon temporarily collects browser interaction, reduces it into behavioral signals, and then throws away the raw event buffer.

_handleChunkLimit() {
    const events = this.collector.getRawEvents();
    this.chunkHistory.push(this._analyzeBuffer(events));

    this.collector.reset();
}

The important part isn't the event counter. It's what happens afterward: the raw interaction is used as input to the calculation, not retained as the analytics product.

From there, the engine looks at the physical characteristics of the interaction.

const dx = ev.x - prev.x;
const dy = ev.y - prev.y;
const dist = Math.hypot(dx, dy);

totalDist += dist;
velocities.push(dist / dt);

Distance, velocity, timing, and directional changes become behavioral signals.

Shape Beacon doesn't need to know what the user is looking at to describe how they interact with the page.

Those signals are reduced into four behavioral dimensions:

Intensity
Rhythm
Exploration
Coherence

The engine compares the four-dimensional point against tuned behavioral shapes.

for (const [shape, ideal] of Object.entries(this.tune.shapes)) {
    const dist = Math.hypot(
        metrics.intensity - ideal[0],
        metrics.rhythm - ideal[1],
        metrics.exploration - ideal[2],
        metrics.coherence - ideal[3]
    );

    distances[shape] = 1 / (dist + 0.0001);
}

The session is treated as a point in behavioral space and compared against the shapes that exist within that space.

The result is a small behavioral fingerprint.

What gets sent?

When the session ends, Shape Beacon sends a <1KB JSON payload containing the processed behavioral signal.

No raw coordinates, clicks, or keystrokes are stored.

It's a lightweight JavaScript SDK that can also be routed through a first-party proxy.

The goal is to extract more meaning from less data.

The problem I'm exploring with Shape Beacon is:
What did that interaction look like?

I've recently deployed Shape Beacon as a free tool. I'm also exploring where this approach fits within modern edge platforms and have submitted Shape Beacon for consideration to Cloudflare, Vercel, and Netlify. Those applications are currently pending, so we'll see where this experiment goes.

The goal was simple: respect the end-user's browser while still giving developers meaningful behavioral data.

Cheers,
Anthony

Shape Beacon

Behavioral Analysis: The Challenge of the Tab

Anthony Yerhot — Tue, 11 Aug 2026 12:02:52 +0000

Currently working on a Saas that reads a user’s behavior on a site. The goal is keeping it lightweight and privacy centered.

All interactions are recorded in the browser. When the browser hides the page, a compact summary is calculated and sent to a cloudflare worker for insertion into a D1 DB.

The exit events are strictly bound using this function.

// Bind exit triggers strictly once
if (this.config.endpoint && !this._hasSetupTriggers) {
    const handleExit = (event) => {
        if (this._hasSent) return; 
        if (document.visibilityState === 'hidden' || event.type === 'pagehide' || event.type === 'beforeunload') {
            this._hasSent = true;
            this.forceSend();
        }
    };
    document.addEventListener('visibilitychange', handleExit);
    window.addEventListener('pagehide', handleExit);
    window.addEventListener('beforeunload', handleExit);
    this._hasSetupTriggers = true;
}

2 attempts are made to send.

1st

const success = navigator.sendBeacon(this.config.endpoint, payload);

And 2nd fallback

if (!success) {
    fetch(this.config.endpoint, { method: 'POST', body: payload, keepalive: true }).catch(e => console.error(e));
}

But what about if the user returns to the tab?

The function keeps recording when they return. But it won't fire again because of the way I set up handleExit.

const handleExit = (event) => {
    if (this._hasSent) return; // <-- THE LOCK
    if (document.visibilityState === 'hidden' || event.type === 'pagehide' || event.type === 'beforeunload') {
        this._hasSent = true;      // <-- LOCKING IT
        this.forceSend();
    }
};

Because it locks hasSent to true I can't fire another beacon for the session.

I need to turn this._hasSent = false when they return so I can fire again.

const handleVisibilityChange = (event) => {
    // 1. User hides the tab, navigates away, or closes the browser
    if (document.visibilityState === 'hidden' || event.type === 'pagehide' || event.type === 'beforeunload') {
        if (this._hasSent) return; // Prevent duplicate immediate fires
        this._hasSent = true;      // Lock the beacon
        this.forceSend();          // Fire navigator.sendBeacon
    } 
    // 2. User returns to the tab
    else if (document.visibilityState === 'visible') {
        this._hasSent = false;     // Unlock the beacon so it can fire again later
    }
};

document.addEventListener('visibilitychange', handleVisibilityChange);
window.addEventListener('pagehide', handleVisibilityChange);
window.addEventListener('beforeunload', handleVisibilityChange);

But this creates another problem, multiple writes for the same session ID (primary key).

I use write or replace for duplicate session IDs. This takes the latest data and scrubs the old.

// --- 7. DATA INGESTION (shape_db) ---
// Force the Project ID to be the securely retrieved domain_whitelist.
const permanentProjectId = authData.domain_whitelist || 'unknown_domain';

// UPDATED: INSERT OR REPLACE handles tab-switching updates for the same sessionId
await env.DB.prepare(`
    INSERT OR REPLACE INTO sessions (
        id, project_id, schema_version, url, timestamp, 
        session_duration_ms, event_count, engine_version, tune_version, device, metrics, shapes
    ) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
`).bind(
    data.sessionId, 
    permanentProjectId, 
    data.payloadSchema,                 
    data.url || '',
    data.timestamp || new Date().toISOString(),
    data.sessionDurationMs,
    data.eventCount || 0,
    data.engineVersion || '',
    data.tuneVersion || '',
    data.device || 'unknown',
    JSON.stringify(data.metrics, null, 2), 
    JSON.stringify(data.shapes, null, 2)
).run();

Full project here:

Repository: View the code on GitHub
Live Site: Check out the SaaS

Hopefully my experience with users and their desire to open tabs and jump around like jack rabbits help.

Cheers