Skip to content

Roadmap

What’s shipped, what’s in flight, what we’ve considered and decided against. Updated as the project moves; if you’re depending on something here for a buying decision, ask on the issue tracker for a status check.

  • @trackbridge/browser — browser-side tracker. Captures gclid/gbraid/wbraid, persists in first-party cookies, fires gtag conversions and events with hashed userData.
  • @trackbridge/server — server-side tracker. GA4 Measurement Protocol, Google Ads API conversions with OAuth refresh-token management, hashed userData matching the browser side byte-for-byte.
  • @trackbridge/core — shared normalization and SHA-256 hashing utilities.
  • Consent Mode v2ad_storage gating for click-identifier cookies, in-memory deferred persistence on consent grant.
  • The Trackbridge skills bundle — Claude Code skills for setup, OAuth, conversions, consent.
  • The examples/nextjs-demo — end-to-end dual-send dogfood, runnable against a Google Ads sandbox.
  • Documentation site (this site). Public at docs.trackbridge.dev. Author-pass on every page completed; brand alignment in progress.
  • Skills loader CLI. Replaces the current git clone ~/.claude/skills/trackbridge install path with a project-local, lockfile-based install. Targeting first half of 2026.
  • GitHub release → docs PR action. The SDK repo will push release notes to this repo on every published release; the Changelog page regenerates automatically. Dependent on v0.1.0 publishing.
  • Meta CAPI adapter. Same dual-send pattern, Meta’s Conversions API as the server transport. Likely a @trackbridge/meta package; the existing browser SDK can stay as-is.
  • TikTok Events API adapter. Same shape as Meta: separate package, same dual-send invariants.
  • Cross-domain linker. Sharing click identifiers across example.com and paymentprovider.com (real third-party domains, not subdomains). Currently out of scope; revisit when a customer needs it.
  • Trackbridge Dashboard. A small SaaS surface that ingests SDK telemetry and shows you which conversions Google accepted, which it rejected, and what your dual-send dedup rate looks like. Post-v1.
  • Versioned docs (/v1.0/..., version switcher). Single rolling version + a Changelog page. Revisit if real users start pinning to old SDK versions in production.
  • Auto-generated API reference from TypeScript types. The reference is hand-written. Auto-gen tools produce reference that reads correctly but explains nothing; we’d rather maintain prose. Revisit if the maintenance cost gets unreasonable.
  • i18n. English only at launch. Revisit when the corpus is large enough to be worth translating.
  • A “growth platform” surface. Trackbridge is an SDK and a small dashboard product. We are not adding email, attribution UI, audience segmentation, or anything else that would push the project toward “marketing automation”. Hard line.
  • Algolia DocSearch. Pagefind is built into Starlight, fully client-side, no SaaS. Revisit when search quality stops being good enough.
  • Comments / discussion widgets in the docs. The GitHub issue tracker is sufficient.

The SDK uses semver. Breaking changes go in major versions. Pre-1.0 (the current state), the API may change between minor versions if we find something we want to fix before locking it in — but the dual-send invariants documented in the reference section won’t break.

The roadmap above is what we plan to build. If you have an integration that needs something not on this list, open an issue. We read every one. The list above isn’t a contract.