Prebit Analytics is not just a chart on a dashboard. Every important thing that happens in your store — an order getting paid, a refund, a catalog update — gets recorded once, in one place, as the single true record of what actually happened. Everything else, including any marketing tool you connect, reads from that same record.
Without clean analytics, teams misread campaigns, over-credit channels, and struggle to tell whether the problem is traffic quality, page experience, or checkout.
Developers need one shared definition of what a "purchase" or a "page view" means, so product, marketing, and engineering are never arguing about whose number is right. A marketing tool only ever gets handed an event that already happened — it never gets to decide on its own that a sale occurred.
Browser-only scripts, duplicate provider events, and fuzzy purchase definitions make it hard to answer even basic revenue questions with confidence.
If one team says "purchase" and another means "payment started" or "thank-you page loaded", optimization work breaks down. Prebit is opinionated about the vocabulary for that reason — a purchase is only ever recorded from the one place that actually knows the order went through: the order confirmation page itself.
Core Web Vitals, page flow friction, and paid attribution are all part of the same funnel story. Analytics should let teams see that connection more clearly.
Page views, product views, searches, add-to-carts, checkout starts, and purchases are all tracked under the same fixed set of names everywhere, most of it happening automatically as a shopper browses — nothing custom to wire up for the basics.
Merchant impact: Reports become more understandable across growth, operations, and leadership.
Developer impact: Engineers instrument once against stable event names rather than translating between multiple vendor models. Unknown event names are treated as custom events, subject to the same name/property validation as standard ones.
Example: A brand compares campaign traffic, add-to-cart rate, checkout-start rate, and paid purchase count using the same event language across dashboards and provider exports.
Every real purchase gets one single, permanent ID the moment it happens. Every place that purchase gets reported to — Meta, GA4, your own dashboard — reuses that exact same ID, so nothing ever gets counted twice.
Merchant impact: Teams get fewer mysterious gaps or inflated conversions in external platforms, because a browser report and a server report for the same order are recognized as the same sale, not counted twice.
Developer impact: A canonical `DomainEventEnvelopeV1` is recorded once, atomically, when the commerce event happens (for example when `markOrderPaid` succeeds). The event router selects connected subscribers and enqueues one outbox delivery per provider, reusing that same `eventId` as the dedupe key; a provider only transforms and delivers what it's given.
Example: Meta receives both a browser and a server Purchase tied to the same `eventId` for one order and correctly treats them as one conversion, not two.
Real page-speed measurements and live session tracking give a fuller picture than conversion counts alone — so you can see whether a slow page or a confusing flow is actually costing you sales.
Merchant impact: Teams can spot when page quality or device behavior is hurting revenue before running a full redesign.
Developer impact: Real Web Vitals (LCP/INP/CLS) reporting and 60-second, Page-Visibility-API-gated heartbeats are delivered via `fetch(keepalive: true)`, not `sendBeacon`, so delivery survives a tab close mid-navigation — frontend work can be evaluated against measurable vitals instead of just subjective perception.
Example: A landing page with strong traffic but weak conversion is correlated against worse LCP and higher abandonment on slower devices.
If Meta or GA4 stops receiving your data properly, you're not left guessing. The real delivery status — last success, last attempt, and what went wrong — is visible directly in your dashboard.
Merchant impact: Operators can catch broken tracking integrations faster, from a real health block in Settings → Marketing rather than a third-party debugger.
Developer impact: Delivery health is tracked from real outbox delivery records — last success, last attempt, recent success rate, error category, reconnect state — not inferred indirectly. A worker claim/lease prevents two dispatch cycles from double-sending the same due delivery.
Example: A merchant notices purchase events are fine inside Prebit but failing in an external provider because the destination connection needs re-authorization — visible directly in the health block instead of discovered days later in Meta's own reporting.
Every layer feeds the next: Analytics sits inside this chain rather than bypassing Commerce Engine's data contracts.
`window.prebit.analytics` (browser) and Boron's `<AnalyticsProvider>` / `track()` / `subscribe()` capture page, product, cart, and checkout behaviors with the standard event vocabulary.
Money-critical transitions (like an order becoming paid) record a `DomainEventEnvelopeV1` and enqueue outbox delivery rows in the same operation as the order state change — with a deterministic, bounded repair cron patching the narrow window where atomic recording alone can fail, since this codebase has no cross-collection Mongo transaction to lean on for every path.
A `MarketingProvider` registry (Meta, GA4 today) transforms the canonical envelope into each provider's own payload shape and delivers it, reusing the same `eventId` for dedupe. Providers never decide whether an event occurred — they only format and deliver one they were handed.
Dashboards summarize the event stream, vitals, session heartbeats, and delivery health in a way that supports decisions instead of vanity metrics.
Teams spend less time arguing about what the numbers mean and more time acting on them.
Growth and product teams can pinpoint whether problems start with traffic quality, page quality, or checkout behavior.
One stable `eventId` shared across browser and server deliveries reduces duplicate-counting noise in external platform reporting.
Commerce teams can connect orders, performance, and campaign activity into one picture instead of reading three separate tools.
Instrumentation is easier to maintain when the platform defines the vocabulary and the envelope shape explicitly, versioned (`schemaVersion`) from day one.
Developers transform a known event envelope for each provider instead of allowing providers to define the source-of-truth event model.
Vitals, heartbeat, and event-delivery layers expose more context when something goes wrong, backed by real per-delivery status (`pending`/`processing`/`sent`/`failed`/`dead`) rather than a black box.
Boron ships `server/analytics.ts` and `client/analytics.tsx` as real equivalents of every tracking mechanism the rest of the platform runs — not a copy-pasted third-party script.
A founder wants to know whether poor sales come from traffic quality or checkout loss before increasing ad spend.
Outcome: More grounded decisions with less guesswork.
An agency standardizes event instrumentation across multiple clients so reporting is comparable.
Outcome: Less analyst cleanup and easier performance reviews.
A growth team aligns paid media reporting with storefront and order truth during a major campaign push, trusting that Meta and GA4 dedupe the same purchase correctly.
Outcome: Better optimization loops and more confidence in ROAS analysis.
Developers use vitals and session data to prioritize page-quality improvements with measurable business impact.
Outcome: Performance work tied back to commerce outcomes.
Tracking should add context without becoming a major source of page bloat or duplicate work.
Money-critical events are tied back to backend state (the `DomainEvent` record) so teams are not left trusting browser-only heuristics.
Performance numbers become more useful when they are stitched into the same system as conversion behavior, using the real `web-vitals` package rather than a vendored, stale copy.
When events flow into downstream providers, a worker claim/lease and retry/backoff/dead-letter model let teams reason about failures cleanly instead of silent drops.
Teams can see whether search-facing pages are being held back by poor frontend behavior rather than content alone.
SEO pages and paid landing pages benefit from the same funnel diagnostics when traffic arrives but conversion lags.
When everyone uses the same product, search, and conversion definitions, optimization work compounds more effectively.
Consistent data models make it easier to scale programmatic reporting and performance reviews across many pages.
A direct, factual read on where each platform is strong, and where Prebit takes a different approach.
Directional and factual. Validate against your own catalog complexity, channel strategy, and budget before deciding.
Plain answers to what merchants, agencies, and developers actually ask.
Start free. No credit card required. Explore the rest of the Prebit platform once you're in.