URL Parameter-Based Consent Transfer

The URL parameter method is the fallback approach for transferring GTM consent between sites. It appends consent settings as query parameters to the redirect URL. This method works cross-domain but can be stripped by certain redirects or tracking protection.

When to Use This Method

Use the URL parameter method when:

• Sites are on completely different domains (e.g., example.com → different.com)
• Cookie method isn't available
• You need a simple, universal solution
• Cross-domain tracking is acceptable

Not Primary Method

Don't use as primary method when sites share a parent domain (use cookies instead), URLs might be stripped/modified by intermediaries, or privacy is a major concern (params visible in logs).

How It Works

The URL parameter method follows this flow:

1. Source site builds URL with consent parameters
2. User clicks redirect
3. Browser navigates with parameters in URL
4. Destination reads URL parameters
5. GTM receives consent before container loads

// Source: Build URL
const url = "https://different.com/?analytics=1&ad=0&aduser=0&..."

// Destination: Read URL params
const consent = getConsentFromURL();
gtag('consent', 'default', consent);

URL Parameter Format

To keep URLs manageable, we use abbreviated parameter names:

Full Name	Short Param	Values
analytics_storage	analytics	1=granted, 0=denied
ad_storage	ad	1=granted, 0=denied
ad_user_data	aduser	1=granted, 0=denied
ad_personalization	adpersonalization	1=granted, 0=denied
functionality_storage	functionality	1=granted, 0=denied
personalization_storage	personalization	1=granted, 0=denied
security_storage	security	1=granted, 0=denied

Example URLs

Typical consent (mixed):

https://shop.example.com/products?
  analytics=1&
  ad=0&
  aduser=0&
  adpersonalization=0&
  functionality=1&
  personalization=1&
  security=1

With existing parameters:

https://shop.example.com/products?site=a21Pv000001PqajIAC&
  analytics=1&ad=0&aduser=0&...

Testing the URL Parameter Method

Verify URL is Built Correctly (Source Site)

// In browser console before redirect
const consentState = getCurrentConsentFromGTM();
const params = consentToUrlParams(consentState);
console.log('Consent params:', params);
console.log('Full URL:', `${redirectUrl}?${params}`);

// Should see: analytics=1&ad=0&aduser=0&...

Check URL on Destination (After Redirect)

// In browser console on destination site
console.log('Current URL:', window.location.href);
console.log('Search params:', window.location.search);

// Use receiver API
window.GTMConsentReceiver.checkURL();

Check Console Logs

On the destination site, you should see:

✅ [GTM Consent] URL parameters found and parsed: {analytics_storage: "granted", ...}
📍 [GTM Consent] Using consent from URL PARAMETERS (fallback method)
✅ [GTM Consent] Applied to GTM via gtag("consent", "default")
[GTM Consent] Method: url_parameter

Advantages

• Works Cross-Domain - No parent domain requirement
• Simple Implementation - Just append to URL, no server-side setup
• Universal Support - Works in all browsers, no special APIs
• Transparent - Visible in URL, easy to debug
• Stateless - No storage required, no expiry

Limitations

• Can Be Stripped - Server-side redirects may remove params
• Privacy Concerns - Visible in URL, appears in logs
• URL Length - Makes URLs longer
• Not Persistent - Lost on navigation within site

When Parameters Get Stripped

URL parameters can be lost through server-side redirects, URL shorteners, social media sharing, or tracking protection. Use the dual method (cookie + URL) for maximum reliability.

Common Stripping Scenarios

Server-Side Redirects

// URL with params redirects to:
https://example.com/?analytics=1&ad=0

// Server redirects to:
https://example.com/  ❌ Params lost

URL Shorteners

// Original:
https://shop.example.com/?analytics=1&ad=0

// Shortened:
https://bit.ly/abc123  ❌ Params lost

Troubleshooting

Parameters Not in URL

Check on source site before redirect:

console.log('Final URL:', finalUrl);
// Should contain ?analytics=1&ad=0&...

Solution:

• Verify consentToUrlParams() is being called
• Check URL separator (? vs &)
• Ensure redirect is using finalUrl, not redirectUrl

Parameters Lost After Redirect

Check on destination site:

console.log('URL after redirect:', window.location.href);
console.log('Search params:', window.location.search);

Common causes:

1. Server-side redirect - Check destination server config
2. URL rewrite - Check .htaccess or web server rules
3. Framework routing - Some frameworks strip params

Solution:

• Use cookie method as primary
• Configure server to preserve query params
• Use POST instead of GET

Parameters Present But Not Applied

Check console for errors:

❌ [GTM Consent] Could not read consent from URL: [error]

Common causes:

1. Missing parameters - Need at least analytics or ad
2. Invalid format - Should be 1 or 0, not true/false
3. URL encoding issues - Special characters not encoded

Security & Privacy

Privacy Considerations

URL parameters are visible to users, saved in browser history, logged on servers, included in referrer headers, and visible in analytics. Use cookie method if privacy is important.

Secure Usage:

// ✅ Good: Only consent choices (not personal data)
?analytics=1&ad=0

// ❌ Bad: Personal information in URL
?email=user@example.com&consent=yes

Only put consent choices in URL, never:

• Email addresses
• Names
• User IDs
• Session tokens
• Personal information

Best Practices

Use Short Parameter Names

// ✅ Good: analytics=1
// ❌ Bad: analytics_storage=granted

Why: Keeps URLs shorter and cleaner

Use Numeric Values

// ✅ Good: 1 or 0
// ❌ Bad: "granted" or "denied"

Why: Shorter URLs, easier to parse

Append to Existing Params

const separator = redirectUrl.includes('?') ? '&' : '?';
const finalUrl = `${redirectUrl}${separator}${consentParams}`;

Why: Preserves existing parameters

Provide All 7 Parameters

// Include all consent types, even if some are defaults
analytics=1&ad=0&aduser=0&adpersonalization=0&functionality=1&personalization=1&security=1

Why: Explicit is better than relying on defaults

Comparison: URL vs Cookie

Feature	URL Parameters	Cookie
Cross-domain	✅ Yes	❌ No (same parent only)
Can be stripped	⚠️ Yes	✅ No
Privacy	⚠️ Visible in logs	✅ Not in URL
Setup complexity	✅ Simple	⚠️ Needs domain config
URL cleanliness	❌ Makes URLs longer	✅ Clean URLs
Persistence	❌ Not persistent	✅ Lasts 5 minutes
Browser support	✅ Universal	✅ Universal
Debugging	✅ Easy (visible)	⚠️ Requires dev tools

Summary

The URL parameter method is the fallback approach when:

• Cookie method isn't available
• Sites are on different domains
• Simple implementation is needed
• Privacy is less critical

Limitations:

• Can be stripped by redirects
• Visible in URLs and logs
• Not persistent

Use Cases:

• Cross-domain consent transfer
• Quick testing/debugging
• Scenarios where cookies don't work

Dual Method Recommended

Use the dual method (cookie + URL) for maximum reliability. Cookie works for same-domain, URL params work as fallback - best of both worlds! See Method Comparison for details.