Introduction

Dotyc is an analytics abstraction SDK. You define your product's event catalog once — typed, declarative, living in your codebase — and route every event to one or more adapters: product analytics (PostHog, Matomo, …) or your own business logic (usage counting, billing quotas, internal notifications).

Dotyc is the typing and orchestration of your events. The wiring is yours: we expose the bricks.

Think of it as the ORM of analytics — you define the schema once, then plug in whichever providers you want.

The problem

Analytics instrumentation rots. If you have shipped a product past its first quarter, you know the shape of the debt:

• Scattered string events. track("featureUsed") here, track("feature_used") there, a payload shape that drifted three times, and nobody can say what an event means anymore. The truth about your tracking lives in a provider's UI — or nowhere.
• No single source of coverage. What does the product actually track? The answer is grep. There is no artifact a human, a reviewer, or an AI can read to know your analytics surface.
• Analytics vs business logic duplication. A feature_used event should feed your product analytics and increment the account's usage counter that drives billing. Today those are two code paths with two definitions that silently diverge. With Dotyc they are one event, one definition, two consumers.
• One reliability contract for unequal data. Analytics pipelines are fire-and-forget by culture — fine for page views, unacceptable for the events your billing depends on. So teams keep business facts out of analytics entirely, and the duplication above becomes permanent.
• Vendor coupling at every call site. Switching or adding a provider means touching every track() call. In Dotyc, the code that emits never knows who consumes — routing is declared in one place, server-side.

The model

Four decoupled stages:

catalog  →  emitter  →  ingest  →  adapters
(typed,     (dumb:      (your      (PostHog,
 shared)     track() +   endpoint:  Matomo, …
             transport)  validate,  + your own
                         identify,  business
                         route)     logic)

1. Catalog — every event defined once: name, typed properties (any Standard Schema validator — Zod, Valibot, ArkType, …), free-form tags, and a delivery class.
2. Emitter — a typed track(), inferred from the catalog. It knows nothing else: no adapter SDKs, no secrets, no routing.
3. Ingest — a first-party brick mounted on your domain. Strict validation, verified identity resolution, durable persistence where declared, then a pure parallel fan-out. Invisible to ad-blockers, because it is your endpoint.
4. Adapters — the consumers. Official packages for analytics providers, five-line objects for your own logic.

Routing is declarative matching on tags and event names. A new event tagged feature is automatically consumed by everything listening to feature — zero wiring edits, zero call-site changes.

Delivery guarantees, per event

"Analytics and billing share the same truth" only holds if the pipeline can be trusted with billing. So reliability is declared on the event, not assumed globally:

• delivery: 'best-effort' (default) — logs, marketing, traces: fire-and-forget, zero overhead.
• delivery: 'durable' — business facts: at-least-once delivery through a persistent outbox, acks, per-consumer retries with backoff, dead-lettering.
• source: 'trusted' — events with monetary consequence are emitted server-side, where the fact happens; the client emitter cannot even name them (a compile error, not a runtime check).

Best-effort noise and durable facts never share an envelope, and under pressure the ingest sheds the noise first. More →

What Dotyc is not

Dotyc is deliberately not an analytics platform:

• It stores nothing and has no dashboards. It routes your events to the destinations that store and visualize them.
• It has no autocapture, no session replay, no heatmaps. These are client-native provider features, out of scope by design: Dotyc routes the declared events of your catalog. If you want session replay, install that provider's SDK alongside — the two coexist fine.
• It is not another SaaS to adopt. It is a TypeScript SDK, 100% open source, that lives in packages/analytics of your monorepo.

The trade is explicit: everything Dotyc handles is typed, reviewable, and versioned with your code. Everything it does not handle stays with the tools built for it.

Start here

Concepts