Skip to main content
In development. 86d is being built in the open. Every capability is Experimental until it earns evidence, so check maturity levels before you rely on anything here.
The word “analytics” covers at least five unrelated things, owned by different people and sent to different places. Conflating them is how a merchant ends up reconciling their books against a browser event. 86d names each one.

​
Five kinds of data

None of it is commerce truth. A browser event never creates or repairs an Order, a Payment, an Inventory count, a Loyalty balance, revenue, or GMV. When a dashboard and the database disagree, the database is right.

​
Logs

The Store Runtime writes Next.js and application logs to standard output.
  • In Docker Compose, use docker compose logs -f store.
  • On Vercel, use the project’s log view or vercel logs.
  • On Railway, use the service log view.
There is no log shipper in the box. If you host it yourself, use your provider’s log forwarding.

​
Error reporting

Set a DSN and unhandled errors reach a Sentry project you control:
.env
The integration initializes only when the DSN exists, so leaving these unset costs you nothing. Sampling and data handling are yours to decide.
NEXT_PUBLIC_SENTRY_DSN is public by design, and the events it sends are not. Turn on Sentry scrubbing, and keep secrets, payment credentials, and Shopper personal data out of your error context and breadcrumbs.
Managed Runtime Diagnostics is a separate thing, off by default, and enabled only by the exact value managed-runtime-diagnostics-v1 in 86D_TELEMETRY. It sends a bounded health and error contract to a disclosed 86d endpoint. It does not send Shopper behavior, commerce events, or your sales figures.

​
Sending events to your own tools

Third-party Analytics pushes selected Storefront events to services you picked. Set your Google Tag Manager container:
.env
The Storefront pushes browser events to dataLayer when the container exists. Whether Tag Manager forwards them to GA4 or anywhere else is your configuration, not 86d’s. Event names include view_item, add_to_cart, begin_checkout, and purchase. Every one of them is a report, not a record. A purchase event in the browser proves a script ran. It does not prove a Payment settled or an Order exists.

​
The Analytics Module

@86d-store/analytics records Storefront Analytics events in your Store’s database and renders funnel views for you.
It reads. It does not write commerce facts and it cannot repair one.

​
Audit records

@86d-store/audit-log holds administrative records for one Store Runtime. An append-oriented table is not a tamper-evident audit trail, and it is worth being precise about that with anyone who asks. A Stable audit record needs a server-authored actor, scope, target, action, outcome, and approval provenance, with access controls that have been tested. That is not where this Module is today.

​
Health endpoint

Every Store Runtime serves one:
Use it for deployment health checks. It tells you the process is up. It does not tell you Checkout works, or that a provider Integration is reachable.

​
Local diagnosis

86d doctor reports pass, warn, or fail for runtime prerequisites, environment variables, database connectivity, generated files, and TypeScript configuration.
The CLI collects no usage data. If that ever changes it will arrive with its own name, a published data contract, a named destination, and a way to turn it off.