Free regeneration backfill

Bring pre-existing tracking code into monitoring at no charge.

Free regeneration backfill is the bridge between your existing TrackingCoder generations and Pro monitoring. Codes generated before the Monitor co-ping was baked into the codegen (or codes from before a behaviour fix landed) can be re-generated at zero credit cost so they start reporting to your dashboard.

What the backfill page detects

/dashboard/monitoring/backfill scans the latest stored output for every scenario on your monitored domains and lists the ones whose code does not contain the tc_monitor co-ping. Those are the ones invisible to monitoring — they fire to GA4/Meta/etc. fine, but we can't see the firing on our side.

How the free-regen works

  • Click Regenerate (free) on a row.
  • Server validates the request — single-use waiver, org-scoped, can't be replayed across scenarios.
  • The wizard's last-stored inputs (scenario name, channel, advanced params, etc.) are reused — no re-discovery needed.
  • A new container is generated. Your credit balance doesn't move. The credit_transactions row shows [Free Regen] with amount 0.
  • You re-import the new container into GTM, publish. Once the next event fires, the row drops off the backfill list — auto-confirmed.

The Awaiting re-import nudge

After you regen, the row moves to an "Awaiting re-import" section. It stays there until a fresh event arrives, at which point the system auto-confirms the new container is live. If you forget to re-import + publish, the nudge will stay visible so you know there's an unfinished step.

Anti-abuse guarantees

The waiver protects against turning the free-regen into a free codegen for anything you want:

  • Each waiver is bound to one specific (domain, scenario, channel) tuple.
  • Submitting regenerationWaiverId with a different scenario / channel charges normally.
  • Replayed waivers (already consumed) charge normally.
  • Forged or cross-org waivers charge normally.
  • The waiver only fires when the LATEST output for that signal is genuinely missing the co-ping — once you've regenerated, the row drops off the eligible list.

Common questions

The backfill page says "Everything is monitorable" but my events don't count. Two possibilities. (1) The Monitor container isn't published — install-check would fail too. Check the green "Verified" pill on the domain. (2) The published main container is stale and needs republishing — open GTM, check the last publish time matches your most recent import.

I regenerated but the row didn't move to "Awaiting re-import". The detection runs on the stored output — refresh the page. If still stuck, the regen flow surfaces errors in the row itself; check for a red status message.

I have 50 scenarios needing backfill. Is there a bulk action? Not yet — each regen is a separate user action so you can review + verify in-flight. Bulk regen is on the roadmap; until then, scenarios on your highest-value domains first is the right order.

💡 When does a regen NOT need a re-import?

The container output for any given inputs is deterministic. If an unrelated codegen change (e.g. a Consent Mode tweak) updated the output, but the tag names are the same, GTM's Merge mode replaces the HTML in place. Still — publish afterwards.