TagGovernor
Guide

A vendor is a definition that tells TagGovernor what to look for. Each vendor has:

· URL patterns — substrings or regular expressions that identify the vendor's requests
· Required parameters — must pass for the tag to be considered passing
· Optional parameters — checked but failures produce a warning rather than a fail
· Exclusion rules — conditions that cause a request to be skipped entirely
· Variants — named sub-configurations for vendors that fire differently per event type
· Event name source — where to read the event name from for display in the request row

TagGovernor normalizes every request into one of these types, which you can use in vendor rules and exclusion filters:

XHR-GET · XHR-POST · FETCH-GET · FETCH-POST · BEACON · PING · PREFLIGHT · SCRIPT · IMAGE · STYLESHEET · IFRAME · NAVIGATION · OTHER

The filter bar lets you show only requests with a specific status (PASS / FAIL / WARN / EXCL) or by vendor. The search box filters by URL, vendor name, or any parameter key or value visible in the request. Enable Known Vendors Only in Settings to hide unmatched requests entirely.

Click the export button to save the current request list as:

· CSV — spreadsheet-friendly, includes method, request type, vendor, status, and parameters
· JSON — full detail, machine-readable
· HTML — a self-contained report you can share or archive

Before the file downloads, you'll be prompted to confirm or edit the filename. The default naming pattern is configurable in Settings.

Only the active tab is monitored. Switching tabs pauses storage for the previous tab, keeping memory usage bounded. Each tab maintains its own independent event history.

In the flow detail view you can edit URLs on navigate steps (useful when promoting a flow from staging to production), values on input and change steps, per-step delays, and dynamic token references.

Use tokens in any input or change step value. They're replaced with fresh values each time the flow is replayed:

When replaying, you can configure:

· Step delay — how long to pause between steps (default set in Settings)
· Delay timing — whether the delay fires before or after each step
· Wait strategy — wait for network activity to settle (network-idle) or proceed immediately (none)

A progress bar shows which step is running. You can abort at any time.

After a replay finishes, a summary report shows how many requests were captured, PASS / FAIL / WARN / EXCL counts, and the full request list from the replay session. Export the report as JSON or HTML for archiving or sharing.

· Export as JSON — the full flow definition, re-importable into TagGovernor
· Export as CSV — a human-readable step-by-step breakdown, useful for documentation
· Import — load a JSON flow file from disk

Click + New Vendor and fill in the vendor editor:

· Name and category — used for display and grouping
· URL patterns — one per line; plain substrings or /regex/flags
· Required parameters — rules that must pass
· Optional parameters — rules that produce a warning if they fail
· Event name source — configure where to read the event name from
· Variants — optional sub-configurations for different event types
· Exclusion rules — conditions that skip the request entirely
· Include Request Types — restrict matching to specific request types

Each rule has a source (where to look), a key (parameter name), a check type, and an optional expected value. See the Rule Sources and Check Types reference sections for the full list of options.

Example: Require that a GA4 en parameter equals page_view:
Source: query · Key: en · Check: value · Expected: page_view

Exclusion rules let you ignore requests that should never be validated. Common uses:

· Exclude preflight requests — add PREFLIGHT to the exclusion request types
· Exclude 204 responses — add status code 204 to the exclusion status codes
· Exclude by parameter — exclude any request where a specific parameter equals a specific value

Configure an event name source to pull a human-readable label from the request and display it in the Live tab row. You can pull from a query parameter, a POST body field, the URL path, or the hostname.

Multi-part names: Click + Add Part to combine values from different sources with a separator. For example, combining body.category + / + body.action produces ecommerce/purchase. If any part returns no value, the entire event name is suppressed.

Regex extraction: For each part, you can add a regex like /([^/]+)$/ to extract a portion of the value rather than using the whole thing. If the pattern includes a capture group, the first capture group is used. If the regex doesn't match, the event name is suppressed for that request.

Assign color-coded Labels to vendors for grouping and filtering. Labels are configurable from the Vendors tab. The vendor list can be grouped by Category or Label — set the default in Settings.

Export vendor definitions as JSON to share with teammates or back them up. You can export all vendors or only selected ones. At export time you'll be prompted to confirm the filename. When importing, conflict resolution lets you choose to overwrite, add as copy, or skip any conflicting vendor.

1. In Chrome DevTools, open the Network tab and reproduce the user journey.
2. Right-click the request list and choose Save all as HAR with content.
3. Open the Audit tab in TagGovernor and click Load HAR File.
4. TagGovernor parses the HAR and runs every request through your enabled vendor rules.
5. Results appear in the same format as the Live tab.

The audit reads request data exactly as Chrome recorded it, including query parameters, POST body, request headers, cookies, and response status codes. It normalizes request types using the same logic as the live monitor (so XHR-POST, FETCH-GET, etc. match your vendor rules consistently).

The audit cannot capture data that wasn't recorded in the HAR, such as cookies set by JavaScript after page load or dynamically injected parameters.

Export as CSV, JSON, or HTML. The filename defaults to audit-{date}-{har} where {har} is the name of the HAR file you loaded — configurable in Settings.

Define rules that intercept and redirect outbound network requests before they leave the browser. Useful for pointing a tag to a staging endpoint or blocking specific requests. Rules can use plain string matching or RE2 regex patterns.

Toggle rules on and off individually without a page reload. When any rewrite rule is active, a warning bar appears at the bottom of the extension to signal that captured traffic may differ from production. Click the bar to jump to the Advanced tab.

Create, edit, and delete cookies that are automatically applied to pages when you navigate. Useful for maintaining a logged-in session during test replays, injecting consent flags, or testing behavior for specific user segments.

Cookie fields: Name / Value, Domain (click Fill from page to auto-populate), Path (defaults to /), SameSite (Lax / Strict / None / Unspecified), Expiration in days (0 = session cookie), and Secure / HttpOnly flags.

Export and import cookie configs to share test environments with teammates.

Generate a unique randomized email address for each test replay so form submissions don't collide with previous runs. Set an optional prefix (e.g. qa-test) and a domain, then use {{email}} anywhere a value is expected in a flow step. Each replay generates a fresh address like [email protected].

Define reusable tokens for dynamic values in flows beyond email addresses. Each token has a label, a format (e.g. UUID, random alphanumeric), and an enable/disable toggle. Use them in flow step values as {{tokenName}}.

Example: Define a token called orderId with UUID format. Set a hidden order ID field in a flow to {{orderId}}. Every replay generates a unique order ID.