Sign inJoin

Spyglass360

Behavior analytics, heatmaps, feedback, and CRO — in one pla

Visit Website
March 5, 2026 I Built a Full Hotjar-Style Behavior Analytics Platform in PHP (Heatmaps, Replays, Funnels, Forms, Surveys, A/B Tests)

Most analytics tools tell you what happened.

I wanted a tool that tells me:

  • what visitors did

  • where they got stuck

  • why they dropped off

  • and what to change next

So I built Spyglass360 — a full behavior analytics + CRO platform (Hotjar-class, but broader) using:

  • PHP

  • MySQL

  • Vanilla JavaScript

  • Bootstrap

  • Square for subscriptions

This post breaks down how it works end-to-end and the engineering tradeoffs.

The one rule: install must be stupid simple

If setup isn’t one snippet, you lose people instantly.

So Spyglass360 installs with a single script tag:

<!-- Spyglass360 Tracker -->
<script>
(function(){
var s = document.createElement("script");
s.src = "https://spyglass360.com/track.js?api=YOUR_API_KEY";
 s.async = true;
document.head.appendChild(s);
})();
</script>
<!-- End Spyglass360 Tracker -->

What is this?

Lesson learned: never expose internal asset paths in customer snippets.
Always ship a stable public endpoint like /track.js.

What the tracker collects (the minimum data that unlocks everything)

To power heatmaps, replays, funnels, form analytics, feedback, and experiments, the client collects structured events such as:

  • page views + navigation events (including SPA changes)

  • clicks/taps (x/y normalized)

  • scroll depth + viewport size

  • form focus/blur/submit attempts (no raw PII values)

  • custom events (API/event tracking)

  • identifiers to correlate sessions and visitors

The goal is not surveillance — it’s answering:

“Where is the friction, and what should we fix?”

The backend design: raw events + fast aggregates

The main challenge isn’t PHP — it’s volume and query shape.

So the architecture is:

  1. Receive batched events

  2. Validate API key + normalize fields

  3. Store append-only raw events

  4. Update aggregate tables for fast dashboards

Typical approach:

  • events_raw (append-only, JSON payload + core fields)

  • sessions (session index + metadata)

  • pages / daily_aggregates (fast reporting)

  • additional tables per feature: funnels, forms, surveys, experiments, feedback

This keeps “deep analytics” possible while keeping dashboards fast.

Heatmaps are the “cheap win,” but still easy to mess up

Heatmaps work well if you normalize coordinates:

  • store x/y as percentages of viewport

  • bucket and aggregate

  • render as overlays

If you store raw pixels, everything breaks across device sizes.

Session replay: you’re not storing video

Replay is an event stream + snapshots.

A practical replay system includes:

  • an initial DOM snapshot / sanitized structural representation

  • incremental events (clicks, scroll, input focus, mutations)

  • a player that reconstructs the session timeline

Hard parts:

  • performance + batching

  • sanitization and masking

  • replay fidelity vs storage cost

Funnels and form analytics: the features businesses actually pay for

Heatmaps impress. Funnels convert.

Funnels:

  • define steps (URLs/events)

  • compute step completion per session

  • show drop-off + time between steps

Form analytics:

  • field focus/blur

  • time spent per field

  • submit attempts + error flags (optional)

  • “where do people give up?”

These are the “fix conversion” tools.

Surveys + feedback widgets: the “why” layer

Behavior tells you what. Feedback tells you why.

Spyglass360 includes:

  • surveys (targeted triggers, rules)

  • feedback widgets

  • qualitative notes tied to behavior context

This is where you close the loop:
watch what happens → ask why → change the page → measure again

A/B testing and experimentation

If you already capture behavior + conversion outcomes, experiments become natural:

  • variant assignment per visitor/session

  • goal events

  • results analysis by segment/traffic source

Even a simple experiment engine provides huge value if it’s integrated with the behavior dashboard.

Segmentation + customer intelligence

Once you have unified data:

  • segment by page patterns, referrers, device, geography, behavior, conversions

  • view “who converts” vs “who bounces”

  • identify high-friction cohorts

This is where a product becomes a platform.

Billing gotchas: Square subscription plan variations

One nasty launch-day bug:
Square subscriptions require using a SUBSCRIPTION_PLAN_VARIATION id when enrolling users.

If you pass the plan id instead of the variation id, it fails.

Fix:

  • create plan and variation on plan creation

  • store both in MySQL

  • always use variation id for subscription enrollment

The other launch bug: don’t activate users before payment success

It’s easy to accidentally do this:

  • user picks paid plan

  • account is created and logged in

  • dashboard loads

  • payment never happens

The fix is a proper state machine:

  • pending_payment

  • active

  • failed/canceled

And dashboard access is gated on active (unless free plan).

Why I built it anyway (when Hotjar exists)

Because a lot of builders want:

  • a clearer “all-in-one” workflow (behavior + feedback + testing)

  • fast setup

  • pricing they can live with

  • less tool sprawl

  • a platform that feels designed for iteration, not enterprise ceremony

Spyglass360 is now working end-to-end:
install → dashboard → behavior + feedback → optimize → upgrade path.

If you’re building in this space…

What’s the hardest part for you?

  • replay fidelity?

  • privacy/masking?

  • funnels that don’t lie?

  • A/B testing infrastructure?

  • scaling event storage?

And if you were choosing a Hotjar alternative, what’s your #1 deciding factor:
price, privacy, fidelity, funnels, speed, or workflow?

jamie

Comment

People

jamieFounder