Behavior analytics tells you why:

• where users clicked and hesitated

• how far they scrolled

• where they rage-clicked

• where forms broke down

• where funnels leaked

• what users said (surveys/feedback) alongside what they did

I built Spyglass360, a full Hotjar-class behavior analytics + CRO platform, using:

• PHP

• MySQL

• Vanilla JavaScript

• Bootstrap

• Square for subscriptions

This post breaks down the engineering architecture: event design, storage strategy, and the “sharp edges” you hit when you ship a real tracker.

1) The install contract: one snippet, stable endpoint

If install isn’t simple, you lose users instantly.

Your tracker needs one snippet and a stable public URL (do not expose internal asset paths like /assets/js/... in customer-facing snippets).

<!-- 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?

Rule: /track.js should remain stable forever—even if you refactor your internal structure later.

2) What the tracker collects (minimum data, maximum value)

The easiest way to lose trust in this space is to collect “too much” (PII risk) or “the wrong kind” (not actionable).

A practical base set of events:

• pageview (url, referrer, viewport)

• click (normalized x/y + small element hint)

• scroll (depth %, viewport)

• form_focus, form_blur, form_submit (never raw values)

• custom_event (for funnels/goals)

• session/visitor identifiers (to correlate journeys)

Example payload (simplified):

{
  "apiKey": "…",
  "siteId": 123,
  "visitorId": "v_abc",
  "sessionId": "s_xyz",
  "type": "click",
  "url": "https://example.com/pricing",
  "ts": 1710000000000,
  "viewport": { "w": 1440, "h": 900 },
  "event": { "x": 0.62, "y": 0.41, "selector": "button#start" }
}

Privacy principle (non-negotiable)

For forms, you log interaction, not secrets:

• field focus/blur

• time spent

• submit attempts

• optional “validation error happened” flags

Not the typed values.

3) PHP isn’t the bottleneck — query shape is

The “hard” part of analytics isn’t receiving requests. It’s turning a flood of events into fast queries.

So the backend pattern is:

1. accept event batch

2. validate + normalize

3. write raw events append-only

4. maintain aggregated tables for dashboards

Raw events give you replay and deep drill-down.

Aggregates give you fast dashboards.

4) MySQL storage strategy: raw + aggregates

A sane starting point in MySQL:

Raw events table (append-only)

• site_id

• session_id

• visitor_id

• event_type

• url

• ts

• payload_json

Session index table

• session start/end

• landing page

• referrer

• device info (lightweight)

• geo coarse (optional)

• UTM fields (if you collect them)

Aggregates

• daily totals per site

• per-page click bins

• per-page scroll depth bins

• funnel step completions

• form field drop-off

This avoids the “every page load runs a full scan of raw JSON blobs” trap.

5) Heatmaps: normalize → bin → aggregate → render

Heatmaps are basically “count points and draw an overlay,” but normalization is the difference between “useful” and “garbage.”

Store click coordinates as percentages:

• x_norm = x / viewport_width

• y_norm = y / viewport_height

Then aggregate into bins (example: 100×100 grid).

Rendering becomes resolution-independent.

This is why heatmaps can be a “cheap win”: once the event model is correct, the rest is math + UI.

6) Session replay: it’s not video

Replay looks like video, but it’s actually:

• an initial snapshot

• incremental events (scroll/click/mutations)

• a player that reconstructs the timeline

An MVP replay can be staged:

Stage 1: click trail + scroll + navigation timeline

Stage 2: DOM snapshot + simple masking

Stage 3: mutations + higher fidelity playback

The core challenge is balancing:

• fidelity vs storage

• masking vs usefulness

• performance vs detail

7) Funnels: the “this makes money” feature

Heatmaps impress. Funnels sell.

Funnels answer:

• where people drop off

• how long steps take

• which traffic sources convert

Implementation idea:

• define funnel steps by URL patterns and/or custom events

• compute completion by session correlation (not just counts)

• aggregate drop-offs and time-to-step

If you get funnels right, you can ship value even before replay is perfect.

8) Form analytics: friction without creepiness

Forms are where conversions die.

Track:

• focus/blur per field

• time in field

• abandon point

• submit attempts

• optional “error happened” flags

Then show:

• “This field causes 60% abandonment”

• “Users spend 12s here and quit”

• “Mobile users fail on step 2”

That’s actionable.

9) Feedback widgets + surveys: the “why layer”

Behavior analytics tells you what. Feedback tells you why.

Once you combine:

• funnels + dropoffs

  with:

• micro surveys at the right moments

…you get the full loop:

observe → ask → fix → verify.

The key is targeting (rules):

• pages

• behaviors

• segments

• exit intent (carefully)

• post-conversion survey

10) A/B testing is easier when analytics is unified

Once you already track:

• visitors/sessions

• goal events

• segments

Experiments become manageable:

• assign variant consistently per visitor

• track goals

• analyze results by segment

This is where “all-in-one” becomes a real advantage: your experiments don’t live in a separate tool.

11) Billing gotcha: Square plan variations

One real launch-day landmine:

Square subscriptions require the SUBSCRIPTION_PLAN_VARIATION ID for enrollment, not just the plan ID.

If you pass a plan ID where a variation ID is required, you get an error like:

object does not have type SUBSCRIPTION_PLAN_VARIATION

Fix pattern:

• when creating a plan in admin, create the plan and its variation

• store both IDs in MySQL

• enroll subscriptions using the variation ID

12) Another gotcha: never grant access before payment success

The classic SaaS mistake:

• user picks paid plan

• you create account and log them in immediately

• payment fails or is abandoned

• they still get access

Fix it with a state machine:

• pending_payment

• active

• failed/canceled

Gate your dashboard/API by active (except for legit free plans).

13) What I’d do differently if starting again

1. Make /track.js the stable endpoint from day one

2. Treat privacy/masking as a first-class UX feature

3. Build funnels + forms early (they pay the bills)

4. Add an install verification screen (“we’re receiving events”)

5. Make replay incremental so you can ship value early

Closing

Building behavior analytics isn’t about the tracker alone. It’s about:

• event design

• storage strategy

• privacy discipline

• turning data into actions

If you’ve built anything in replay/analytics/CRO tooling, I’d love to hear:

What’s the hardest part for you?

Replay fidelity? masking? storage scale? funnels that don’t lie?