Built-in Tag Manager variables can read the text of what a visitor clicked, the text and ID of a form, the full page URL and the referrer. Any of these can contain personal or sensitive data. Enable only the variables a tag needs, and check what each tag sends.
What the documentation lists
Google's help page for built-in web variables describes groups of variables set by triggers. Examples from that page:
| Variable | What it holds |
|---|---|
| Click Text | The text of the clicked element |
| Click URL | The URL associated with the click |
| Click ID and Click Classes | The id and class attributes of the clicked element |
| Form Text | Text associated with the form |
| Form ID and Form URL | The form's id and target URL |
| Page URL | The full URL of the current page |
| Page Path and Page Hostname | Parts of the URL |
| Referrer | The full referrer URL |
| Error Message | The message from a JavaScript error trigger |
The Click Element and Form Element variables hold a reference to the DOM element itself, which is a reminder that these triggers observe the page, not a curated list of fields.
Where the risk comes from
A button can contain a name, an account number or a diagnosis term in its label. A link can contain a token in its URL. A form target can carry a query string. A referrer can carry the previous page's address and parameters. If a tag sends one of these values as an event parameter, the value goes to a third party, often on every click.
Google's Analytics policy page warns that PII is often sent inadvertently in URLs and titles. See personal data in URLs sent to analytics.
An audit in five steps
- In the container, open the variables list and note which built-in variables are enabled.
- For each enabled one, find the tags and triggers that use it.
- In preview mode, click through key flows and read the values shown for each variable.
- Look for names, emails, long IDs and free text in those values.
- Disable unused variables, narrow triggers to specific elements, and use a fixed label for events instead of Click Text where the label could vary.
Safer patterns
Use a constant event name such as signup_click rather than the visible text. Fire click triggers on a specific element ID, not on all clicks. For form events, send that the form was submitted, not what was typed. Keep sensitive pages out of tag firing altogether, which the pages that should not run marketing tags covers.
Review on every release
A newly added trigger can switch a variable on again. Make the variable check part of the release review.
Quick check
Is Click Text safe to send to analytics?
Only if the labels never vary with the user. Where they might, send a fixed event name instead.
Does disabling a variable remove past data?
No. It stops future use. Past data stays with the vendor, so ask the vendor about deletion.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep dated records of reviews like this one, and its dependency scanning covers shipped code. Try the free scan.
Sources
- Google Tag Manager Help: built-in variables for web containers
- Google Analytics Help: best practices to avoid sending PII
Last reviewed: 19 October 2026.
