trackbridge

The entry point. When you mention Trackbridge, @trackbridge/browser, or “Google Ads dual-send” in Claude Code, the router activates first. It states the three SDK invariants up front, asks where you are in the integration, and dispatches to the appropriate sibling skill.

It does not write code itself. Code-writing is delegated.

Frontmatter

name: trackbridge
description: Use when the user mentions Trackbridge, @trackbridge/browser, @trackbridge/server, or wants to add Google Ads / GA4 dual-send conversion tracking. Routes to the specific Trackbridge skill for the task at hand.

When it triggers

“Add Trackbridge to this project”
“Wire up Google Ads conversions”
“Set up dual-send tracking”
“What is Trackbridge?”
Mentions of the package names @trackbridge/browser or @trackbridge/server
Reading code that imports either package

What it does on activation

Surfaces the three non-negotiables (see below).
Asks where you are in the integration.
Dispatches.

The non-negotiables are loaded into context immediately because they’re the failure modes that bite hardest if you miss them, and they apply across every sibling skill.

The three non-negotiables

Same transactionId on both sides. Browser and server trackConversion calls must pass the same string (typically your order ID). Different IDs cause Google to count the conversion twice. See Deduplication & transactionId.
Server secrets never reach the browser. GA4_API_SECRET, GOOGLE_ADS_DEVELOPER_TOKEN, GOOGLE_OAUTH_CLIENT_SECRET, GOOGLE_ADS_REFRESH_TOKEN, GOOGLE_ADS_CUSTOMER_ID belong to createServerTracker only. Never expose via NEXT_PUBLIC_* / VITE_* / PUBLIC_* prefixes.
Never re-implement normalization or hashing. Pass raw userData to trackConversion; the SDK normalizes and SHA-256 hashes identically on both sides. Hashing in your code will diverge from Google’s expectations and silently degrade enhanced-conversion match rates.

The routing table

If you’re doing…	Router dispatches to
Installing Trackbridge for the first time, creating tracker instances, wiring env vars	`trackbridge-setup`
Firing a conversion in checkout success, server webhook, order-confirmation handler	`trackbridge-conversions`
Setting up the Google Ads API (developer token, OAuth, refresh token, conversion-action mapping)	`trackbridge-ads-oauth`
Integrating with a CMP (Cookiebot, OneTrust, Iubenda, custom) for Consent Mode v2	`trackbridge-consent`

If your task spans multiple categories (a new integration usually does), the router moves you through them in order: setup → oauth → conversions → (consent, if applicable).

Prerequisites

None. The router is the entry point — every other Trackbridge skill assumes you’ve passed through the router (or its equivalent).

What it touches

Nothing. The router doesn’t write or edit files. It loads context and hands off.

What it won’t do

It won’t write code. Every code-writing path is delegated.
It won’t obtain Google Ads API secrets. That’s trackbridge-ads-oauth’s job (and even then, the manual steps stay manual).
It won’t pick a CMP. It wires whichever one you have.

Example

You: I want to add Google Ads tracking to my Next.js checkout.

Claude (with router): Trackbridge fires Google Ads and GA4 conversions
from both browser and server, deduping via a shared transaction ID.
Three rules:

  1. Same transactionId on both sides.
  2. Server secrets stay server-only.
  3. Never pre-hash userData.

Where are you in the integration?
  - Just starting → I'll use trackbridge-setup.
  - Firing conversions → trackbridge-conversions.
  - Google Ads API setup → trackbridge-ads-oauth.
  - Consent / GDPR → trackbridge-consent.

You: Just starting.

Claude: → loads trackbridge-setup ...