URL Redaction

Page URLs often carry more than the page. A quote journey can put the answer to “Do you have any unspent convictions?” in the query string, a search page puts the search term there, and some forms echo every field into the URL on submit. By default Datafly Signal sends the full page URL, search string and referrer with every event, so any destination that reads them receives those values too.

A per-pipeline URL redaction policy removes them. It is applied twice:

In the browser. The collector redacts context.page.url, path, search and referrer before an event is built, including the referrer recorded on single-page-app route changes. The GA4 session beacon, which goes straight from the browser to Google, is redacted too.
At the ingestion gateway. Anything that can reach the gateway can skip the collector, so the gateway applies the same policy to every event on every ingestion endpoint (browser, batch and server-side /v1/events) before the event is stored or delivered. The event store, the live event feed, the Event Debugger and every destination only ever see redacted values.

URL redaction is off by default. A pipeline without a policy behaves exactly as before.

Click IDs (gclid, fbclid, msclkid and the rest) and UTM campaign values are captured from the page before redaction, so they still reach click_ids and context.campaign and attribution keeps working even if you remove them from the URL.

Configure it

Open the pipeline, go to Settings → URL Redaction, switch it on and save. The first time you switch it on, Signal suggests an allowlist that keeps UTM parameters, Google Ads parameters and every click ID the collector recognises, and removes fragments.

The gateway enforces a saved policy within seconds. The collector picks it up when it is rebuilt: automatically if Signal hosts your tag, otherwise rebuild and redeploy the script from the Collector tab.

Use the Preview box to paste a real URL from your site and see exactly what destinations will receive for each field. The preview runs the same engine the gateway uses.

Query parameters

Mode	Behaviour
Keep all parameters	The query string is not changed. Use this if you only need path patterns.
Allowlist	Only parameters whose name matches the list are kept. Recommended: a field added to a form later is removed without anyone remembering to add it.
Denylist	Parameters whose name matches the list are removed; everything else is kept.
Remove the whole query string	Nothing after `?` is sent.

Matching rules:

* matches any run of characters: *email* matches email, user_email and EmailAddress. Any other character is literal.
Names are compared ignoring case, after percent-decoding, so e%6Dail is treated as email.
Every occurrence of a repeated parameter is judged on its own.
Kept parameters are sent exactly as they appeared, with their original encoding.
If no parameters survive, the ? is removed too.

Path patterns

Some sites put the sensitive value in the path instead: /quote/convictions/drink-driving/step-3. Add a path pattern: a regular expression and a replacement, applied in order to the path as it appears in the URL (percent-encoded). Every match is replaced.

Pattern	Replacement	Path	Becomes
`(/convictions/)[^/]+`	`$1[redacted]`	`/quote/convictions/drink-driving/step-3`	`/quote/convictions/[redacted]/step-3`
`/claims/\d+`	`/claims/:id`	`/claims/123456/documents`	`/claims/:id/documents`

$1 to $9 insert a capture group and $$ inserts a literal $. Everything else in the replacement is literal. An empty replacement deletes the match.
Use the Ignore case option instead of (?i).
The same pattern runs in the browser and on the gateway, so Signal rejects constructs the two engines read differently: inline flags such as (?i), lookarounds, back-references, \A, \z, \Q…\E, \p{…}, \x{…} and POSIX classes such as [[:alpha:]].

Fragments

Query parameter rules do not look inside the fragment (#…). Tick Remove the fragment unless your site uses hash routes (/#/claims/123) that you need in reports, in which case check with the preview that the fragment carries nothing sensitive.

Referrers

Option	Behaviour
Apply this policy to every referrer	The referrer gets the same query, path and fragment rules, whichever site it came from.
Same host: apply this policy. Other sites: send only the origin	A referrer from exactly the page’s host and port gets the policy. Any other referrer is reduced to `https://host/`. A sibling subdomain (`quote.example.com` referring to `www.example.com`) counts as another site.

Traffic-source attribution uses the referrer’s host only, so both options keep it.

What it does not cover

The page title is not changed.
Event properties are not changed. If your own code, the dataLayer bridge, or enhanced measurement puts a URL into a property (for example page_location, link_url or form_destination), redact it at source or with your data governance rules.
Campaign values (utm_term and the others) are captured before redaction by design. If a UTM value itself can be sensitive, do not put it in your campaign links.
Client-side vendor SDKs loaded through hybrid mode read the browser’s address bar directly and are outside Signal’s control.

API

The policy is stored on the pipeline as identity_config.url_redaction:

{
  "url_redaction": {
    "enabled": true,
    "query_mode": "allowlist",
    "query_params": ["utm_*", "gclid", "fbclid"],
    "path_patterns": [
      { "pattern": "(/convictions/)[^/]+", "replacement": "$1[redacted]" }
    ],
    "strip_fragment": true,
    "referrer_mode": "policy"
  }
}

query_mode is keep (default), allowlist, denylist or drop. referrer_mode is policy (default) or origin_cross_site. An invalid policy is refused when the pipeline is saved.

Trusted Proxies Exporting Your Data