The tracking pixel: your first-party signal
The Mass pixel is a first-party tracking script you own. It captures every meaningful event on your funnels and pages — page views, clicks, form submits, scroll, video plays, and conversions — writes them to your own event store, stitches anonymous visitors to CRM contacts, and feeds the CRM journey, automations, the self-healing engine, and AEO. No third-party black box; the data is yours.
16 min read · The complete pixel guide
What the pixel is
A first-party script that turns visitor behaviour into structured events you own.
The pixel is a lightweight script served from your platform domain as `/tracker.js`. Funnels and published pages get it automatically; anywhere else you drop a small snippet that loads the script and initializes it with your pixel id. From then on it records what visitors do and posts those events to your own ingest endpoint, where they land in the `pixel_events` table scoped to your tenant.
Because it's first-party — your domain, your endpoint, your table — it isn't subject to the same blocking and data loss as third-party trackers, and the raw events stay under your control. Every downstream surface in Mass, from the CRM timeline to the self-healing rules engine, reads from this one event store.
- First-party — served from your domain as /tracker.js and posting to your own ingest endpoint.
- Your data — events land in the pixel_events table, scoped to your tenant — not a third-party's silo.
- Auto-installed — funnels and published pages carry the pixel automatically; everywhere else uses a snippet.
- One source — the CRM, automations, self-healing, and AEO all read from the same event store.
Installing the pixel
Auto-injected on your funnels, or a copy-paste snippet anywhere else.
Inside Mass, the pixel is wired in for you. When tracking is set up, the script tag is injected into your funnels' head scripts automatically, so a page you build and publish on the platform is tracked from the moment it goes live. The tracking-setup flow mints a pixel, injects it, and confirms it's live without you touching code.
For external sites, copy the install snippet from the pixel settings: a small loader that pulls `/tracker.js?id=<your-pixel-id>` and calls init and trackPageView. The same `MassPixel` command queue is then available for custom events — for example, firing a conversion with a value, currency, and product when someone buys.
- Auto-inject — the tracking-setup flow mints a pixel and injects the script into your funnels' head.
- Snippet for external sites — a copy-paste loader pulls /tracker.js?id=<pixel-id> and starts tracking page views.
- Command queue — MassPixel('trackEvent', …) lets you fire custom events and conversions from your own code.
- Ad-block fallback — events post to a primary path and retry an alias path that filter lists are less likely to block.
What the pixel captures
Page views, clicks, forms, scroll, time-on-page, video plays, and conversions.
Each pixel configuration decides what to track. Page views, form submits, purchases, and time-on-page are on by default; clicks and scroll depth are opt-in. Every event carries a rich payload: the visitor and session ids, event type/category/action/label/value, the page url, title, and path, the referrer, full UTM attribution, device, browser, OS, screen size, scroll depth, and time on page.
Video plays are first-class. A `content_view` event carrying a video id records that a VSL or lesson was watched, and bridges from the deep player, hub pages, and funnel/lesson players all emit it — deduped per visitor, video, and session so a refresh or replay doesn't inflate the count. There's also a GET beacon fallback (an image-pixel style call) for environments where a POST can't run.
- Standard events — page_view, click, form_submit, purchase, scroll, and time_on_page — each toggleable per pixel.
- Rich payload — visitor/session ids, UTM attribution, device, browser, OS, screen size, scroll, and time-on-page.
- Video plays — content_view events with a video id record watched VSLs and lessons, deduped per session.
- Beacon fallback — a GET image-pixel path captures events where a POST can't run.
Visitor identity & stitching
Anonymous visitors get a stable id, then connect to a CRM contact on form submit.
On first visit the pixel assigns a stable visitor id (persisted in local storage) and a session id, so an anonymous visitor is tracked consistently across pages and visits before you know who they are. Every event carries those ids, building a pre-conversion behavioural history under one anonymous identity.
When that visitor submits a form, the submission carries the same visitor and session ids — so the form handler can stitch the anonymous history to the new (or existing) CRM contact. The page views, video plays, and clicks they made before converting aren't lost; they become part of the contact's journey the moment they identify themselves.
- Stable visitor id — assigned on first visit and persisted, so anonymous behaviour is tracked consistently.
- Session id — groups events within a visit for accurate session-level analytics.
- Form-submit stitching — the visitor/session ids travel with form submits to connect history to a contact.
- No lost history — pre-conversion behaviour becomes part of the contact's journey on identification.
Scoring & configuration
Weight events into a lead score and control exactly what each pixel tracks.
Every pixel configuration carries scoring rules — a weight per event type, so a page view, a form submit, a purchase, and an identify each contribute a different number of points toward a contact's lead score. That turns raw behaviour into a single sortable signal: the more high-value actions a visitor takes, the hotter they rank in the CRM.
Configuration also controls which events fire, which domains are allowed, privacy options (IP anonymization, respecting Do-Not-Track, cookie-consent gating), and forwarding — events can optionally be forwarded to Google Analytics, the Facebook pixel, or GHL alongside your first-party store, so you keep your data and your existing ad-platform signals.
- Event scoring — per-event point weights (page view, form submit, purchase, identify) roll into the lead score.
- Per-pixel toggles — choose which events fire, restrict to allowed domains, and set custom events.
- Privacy controls — IP anonymization, respect-DNT, and cookie-consent gating are configurable.
- Optional forwarding — mirror events to Google Analytics, the Facebook pixel, or GHL while keeping your own store.
Feeding the CRM, automations & self-healing
One event store powers the timeline, triggers automations, and drives optimization.
The pixel is the platform's behavioural backbone. Its events populate the CRM journey timeline directly, so everything a contact does on your funnels shows up on their record — and through that, sharpens the CRM's AI features. The same events fan out to automations: a tracked video play can fire a `video_watched` workflow, and crossing an engagement threshold can trigger a contact-scoped action, all fire-and-forget so a downstream hiccup never blocks the event write.
The self-healing engine reads this same stream. Live KPIs — conversion rate, drop-off, time-on-page — are computed from pixel events, and the rules engine watches them to notify you, suggest a fix, or auto-apply one. The pixel is what makes self-healing possible: you can't optimize what you can't measure, and the pixel measures everything.
- CRM journey — events land on the contact timeline and feed Next Best Action, summaries, and campaigns.
- Automations — video-watched and engagement-threshold events trigger workflows, fire-and-forget.
- Self-healing KPIs — conversion, drop-off, and engagement metrics are computed from the event stream.
- Resilient writes — downstream dispatch is fire-and-forget so a failed automation never loses the event.
Self-healing deep dive
The rules engine that acts on pixel KPIs — notify, suggest, or auto-apply — has its own guide. This page covers the capture side; see the Self-Healing Pixel guide for the optimization side.
The pixel & AEO: closing the loop
Behavioural signal and AI-citation tracking combine into one optimization loop.
Answer Engine Optimization (AEO) tracks how AI engines cite your content and how AI crawlers hit your pages. Bot hits are rolled up daily and AEO produces recommendations from what it learns. The tracking pixel complements that with the human side of the story: once an AI engine surfaces your content and a real person clicks through, the pixel records what they do — and whether they convert.
Together they close the loop. AEO gets you cited and brings the visitor; the pixel measures what that visitor does and feeds the CRM and self-healing engine; self-healing improves the page; and better pages earn better citations. The pixel is the measurement layer that turns AEO's reach into attributable outcomes.
- Bot vs human — AEO rolls up AI-crawler hits; the pixel records what human visitors do once they arrive.
- Attributable outcomes — the pixel ties AEO-driven traffic to real conversions and revenue.
- Closed loop — cited → visited → measured → optimized → better cited, with the pixel as the measurement layer.