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?