Pro monitoring

Pro monitoring gives you a real-time count of every TrackingCoder-generated event firing on your monitored domains. The dashboard reads from a per-minute counter table the ingest endpoint writes to as events arrive — no daily-cron lag.

How it works (high level)

• You enable monitoring on a domain in your dashboard. We mint a per-org signing key and generate a small Monitor container (one GTM Custom HTML tag + one trigger).
• You import the Monitor container into your GTM workspace and publish — same flow as installing any TC container.
• Your TrackingCoder-generated events automatically push a tiny tc_monitor dataLayer signal alongside their normal channel send. The Monitor tag catches it and POSTs to /api/pro/ingest.
• Ingest writes a row to the raw events table and increments the minute-bucketed counter. The dashboard reads the counter directly.

What gets tracked

Every scenario TrackingCoder generates, on every channel, can be monitored. The Monitor tag is generic — it doesn't care what channel the event went to, just that one fired.

How fast is "real-time"?

An event fired on your site shows up in the count within ~1 minute, usually faster. The detail page's Refresh button forces a refetch if you don't want to wait for the auto-poll.

Quota

TC Pro includes 20 monitored domains per workspace, and 250 scenarios across all of them. The dashboard shows your current usage on the Monitoring overview header.

Install-check ping

When you publish the Monitor container, the first pageview on your site fires a one-off _install_check ping. It marks the domain as "Verified · receiving events" without you having to fire a real tracked event first.

The install-check is excluded from event counts, top-events, Recent Activity, and goal calculations — it never inflates your tracked numbers. It does two jobs: it powers the green "Verified" pill, and (bot-filtered) it's the source of the Visits metric below, since it fires once per browser session.

Visits & conversion rate

Alongside event counts, each monitored domain shows a Visits number — TC's own first-party traffic measure, ≈ unique browser sessions. It comes from the install-check ping (which fires once per session) after a bot filter strips crawlers and headless agents. It is not a GA4 session — it's a deliberately simpler, first-party number so you have a denominator without wiring up anything extra.

From Visits we derive a per-event Conversion rate = events ÷ visits over the same window. It's shown only for conversion-type scenarios (purchase, form_submission, add_to_cart, begin_checkout, phone_click, email_click, file_download, hubspot_form_submission) and only when visits > 0 — otherwise it reads "—". Engagement scenarios that fire many times per visit (scroll depth, video milestones) are excluded by design so the rate can never exceed 100%.

The activity chart

The chart at the top of the detail page plots your events over the selected range, with a dimmer grey visits line overlaid (toggle it off if you only want events). The "Filter chart" row lets you view all events combined (default), split by event (one coloured line per scenario on a shared scale), or isolate a single event. The same grey visits reference line also appears on the daily-volume chart in client reports.

Events by traffic source

Below the activity chart, the Events by traffic source section breaks your tracked events down by where the visitor came from — one line per source over time, plus a ranked bar list. Where GA4 shows traffic source for sessions (and makes you build an explore to see it per conversion), this shows it for the actual events you care about: which sources drive your purchases, form submits, and clicks.

Source is resolved in priority order: ad-platform click IDs in the URL (gclid, fbclid, msclkid, ttclid and more — proof the visitor came from that platform), then an explicit utm_source, then the referring site's hostname normalised to a recognisable label (google_organic, chatgpt, etc.), then direct. The busiest sources each get their own line; the rest roll up into a single Other line.

It's session first-touch. The entry URL + referrer are snapshotted once, on the first pageview of each browser session, and reused for every event in that session — so a conversion on a deep page still credits the channel that actually brought the visitor in, instead of collapsing to direct. URL query strings are stripped server-side (no PII or campaign secrets stored); your GA4 / Meta / Ads destinations still receive everything unchanged.

It draws on the same per-event parameter capture as the Recent fires panel, so if your events predate parameter capture the panel will tell you none of your fires carried a source yet — re-import the Monitor container once to switch it on. History follows the raw-events retention window (about 90 days).

For the full detail — the exact detection order (ad-click IDs, UTM, referrer labels), how session first-touch works, and how events are counted — see Traffic source tracking.

Recent fires panel

Every event row has a "View details →" link that opens the Recent fires modal — the last 20 times that event fired, each with a curated, no-PII set of parameter values (pathname, device, traffic source, scroll %, time on page). The per-fire timestamp renders in your workspace timezone so it lines up with the chart axis. It's the fastest way to confirm an event is firing with the context you expect, without opening GA4 DebugView.

Common questions

I see "Verified" but my real events aren't counting. 99% of the time this means the event was generated before the Monitor co-ping was added to TC's codegen. Go to /dashboard/monitoring/backfill — your pre-co-ping scenarios will be listed there, and the regen is free.

I disabled monitoring on a domain — what happens to historical counts? They stay visible (you can re-enable later and resume). New events from a disabled domain are silently dropped at ingest — no error to the customer's site, no count.

Do I have to re-import the Monitor container after every codegen change? No. The Monitor container is one-time per domain. Re-importing is only needed if you rotate your signing key.

How private is this? Every monitored event carries only {scenario, channel, eventName} — no parameter values, no PII. The JWT binds the request to your org + domain so a leaked token from site A can't fabricate events for site B. IP addresses are stored as a daily salted hash, not raw.

Troubleshooting

• Install-check fired but real events don't. Backfill page — see above.
• Counts are double per submission. Some form plugins fire two success signals on different paths. TC's code has a sliding-window dedup guard that catches this — if you're still seeing doubles, regenerate the affected scenario (codegen ships fixes via regen).
• Counts stopped after a GTM republish. Did your republish remove the Monitor tag? Open GTM → Tags, check for TC Monitor - <hostname> in the workspace. Re-import if missing.