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). It has three independent filter layers, all on the same graph:

• Event — view all events combined (default), split by event type (one coloured line per event on a shared scale), or toggle several event chips to compare just those lines. Values aggregate across channels.
• Channel — restrict the lines to fires sent to one destination platform (GA4, Meta, Google Ads, ...). This only affects the chart; the Configured events table has its own channel filter.
• Source — restrict the lines to events that came from one traffic source (google, direct, a referrer...). Source-scoped numbers count only fires that carried source data.

Hovering any day shows a breakdown tooltip: with the combined line it splits that day's events by source; with a source selected it splits that source's events by event type. The same grey visits reference line also appears on the daily-volume chart in client reports.

Comfortable vs Compact layout

A switch at the top of the detail page toggles between two layouts, remembered per browser. Compact (the default) widens the page and arranges sections side by side — Insights next to the activity chart, Traffic Sources next to By channel, and the funnel, top converting pages and heatmap in one row above the Configured events table — so more fits on one screen. Comfortable stacks every section full-width for focused reading.

Insights

The Insights panel surfaces small, non-alarming observations computed from your own monitoring data over the last 7 days vs the 7 before: week-over-week momentum, your biggest-moving event, your busiest weekday and hour, the traffic source driving your conversions, device mix, and conversion-rate trend. It appears on both the Monitoring overview and each domain's detail page, and hides itself when there isn't enough data to say anything meaningful. Insights are observations, not alerts — real problems still come through alerts.

Purchase funnel, top converting pages, activity heatmap

• Purchase funnel — Add to Cart → Begin Checkout → Purchase with step-to-step continue rates and an overall cart-to-purchase rate. Shows once at least one step is tracked; untracked steps offer a one-click "Track this" link into the wizard. Counts use each step's busiest channel so multi-channel setups aren't double-counted.
• Top converting pages — the pages where your conversion-type events (purchases, form fills, calls, checkouts) actually fire, ranked over the selected range.
• Activity heatmap — a weekday × hour grid of all tracked-event volume over the last 14 days, in your workspace timezone. Darker cells = busier.
• Events by device — a donut showing the desktop / mobile / tablet split of your tracked events over the selected range, from the captured device parameter. Click a device to see which events fire on it.

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. Click any source row to expand the events it drove. 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.