scalpel@labs: ~/glossary/tag-provider-decoder.mdx5 sections

What is a tag provider, and how does decoding work?

A provider is the vendor behind a request, such as GA4, Google Ads or Meta. Scalpel Tags tests each request URL against a set of known endpoint patterns, and when one matches it decodes the parameters into named, readable fields, all in the browser.

extension: Scalpel Tagsupdated: 2026-08-14read_time: 2 min
less tag-provider-decoder.mdx

Why it matters

When a page fires a marketing request, the URL and its parameters are a coded message only the vendor understands. A tid=G-XXXXXXX parameter means nothing until you know it belongs to GA4. Decoding turns raw requests into readable data so you can see what your page is actually sending and to whom. Local decoding means nothing leaves your browser.

How it works

Scalpel Tags maintains a registry of endpoint patterns, one for each vendor. When a request fires, the tool checks its URL against each pattern in order. The first match wins. Once a vendor is identified, a parameter map translates the request's query string and body fields into human-readable names and groups. A request to /g/collect with tid=G-XXXXXXX becomes "GA4 → Measurement ID: G-XXXXXXX". The whole operation runs in the browser tab, never touching any server.

Endpoint patterns are a fast pre-filter: most requests don't match GA4, so the tool eliminates them cheaply before expensive parameter decoding. Patterns use domain matching (e.g. facebook.com/tr) and path segments (/g/collect). A request must pass both to be considered.

Parameter maps group logically related fields. GA4 event parameters live under "Event parameters"; session data under "Session"; consent signals under "Consent Mode". This grouping turns a flat list of twenty query parameters into a scannable table.

What does not matter

The order of parameters doesn't matter; decoding is position-agnostic. Your browser sends tid=G-XXXXXXX&cid=...&en=page_view or cid=...&tid=G-XXXXXXX&en=page_view; either decodes to the same result. Trailing slashes and query-string order are noise.

It is also easy to assume decoding means validation. It doesn't. If a request uses a GA4 endpoint but passes a malformed tid, the decode will still show the bad value as-is. Decoding reveals what was sent; it doesn't judge whether it was sent correctly.

Code example

Here's a live GA4 request Scalpel Tags decodes:

GET /g/collect?v=2&tid=G-12345ABCDE&cid=123456.789012&en=page_view&ep.page_type=product HTTP/1.1

After matching the endpoint pattern and applying parameter maps, this becomes:

Vendor: Google Analytics 4
Collection: POST /g/collect
Core:
  - Measurement ID (tid): G-12345ABCDE
  - Client ID (cid): 123456.789012
  - Event (en): page_view
Event parameters:
  - page_type (ep.page_type): product

A Meta Pixel request like https://facebook.com/tr?id=123&ev=Purchase decodes to:

Vendor: Meta Pixel
Endpoint: facebook.com/tr
Account: 123
Event: Purchase

How Scalpel shows it

Every row in the Scalpel Tags panel starts with a vendor badge. Clicking a row expands its decoded parameters into the sidebar, grouped by logical section. The parameter names come from the vendor's own documentation: Google's tid becomes "Measurement ID", Meta's id becomes "Account". If a request doesn't match any known pattern, Scalpel Tags shows it as UNKNOWN and displays the raw parameters; nothing is lost, and you can file the pattern as a feature request.

Sources