---
title: "Marketing query parameter impact (Help Center / Health checks / Recommendations)"
ai_context: "Use this article for questions about the RUMvision Marketing Query Parameter Impact Health Check, slow campaign URLs, query-string related TTFB regressions and caching problems caused by tracking parameters. It covers comparing requests with and without parameters such as `utm_source`, `utm_medium`, `utm_campaign`, `gclid`, `fbclid` and `srsltid`, detecting statistically meaningful p75 slowdowns, and common causes such as CDN cache misses, cache fragmentation, backend processing, personalization, SSR rendering differences and edge configuration. Relevant for questions about marketing parameter performance, paid campaign landing pages, TTFB increases, cache key normalization, ignoring query parameters in CDN caching, URL normalization, duplicate cache entries, browser caching, `No-Vary-Search`, Chromium-only cache behaviour and monitoring whether parameter-related fixes improve performance over the following days."
canonical: "https://www.rumvision.com/help-center/health-checks/recommendations/marketing-parameters/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Health checks](https://www.rumvision.com/help-center/health-checks/?format=md) > [Recommendations](https://www.rumvision.com/help-center/health-checks/recommendations/?format=md) > Marketing query parameter impact

# Marketing query parameter impact

This health check detects **marketing query parameters that significantly slow down requests** based on real user data.

It compares requests **with and without specific query parameters** and flags cases where parameters (e.g. `utm_*`, `gclid`, `fbclid`) cause noticeably worse performance.

Each todo represents a **single query parameter** that is associated with slower responses.

## About this check

### When this check is triggered

You’ll see this check when:

- A query parameter consistently increases response time (TTFB)
- The impact is visible in real user data (p75)
- There are enough events to validate the pattern
- Requests with the parameter are significantly slower than those without it
 
### What you’ll see

Each todo includes:

- **Query parameter**
- Performance impact compared to requests without parameters
- Based on real user sessions
 
Example:

> Investigate slow marketing query parameters for `utm_campaign`  
>  Pages with the marketing query parameter "utm\_campaign" are experiencing slower load times compared to requests without parameters.

### Why this matters

Marketing parameters are often appended to URLs for tracking, but they can unintentionally:

- Break caching (CDN or server)
- Trigger unnecessary backend logic
- Increase Time to First Byte (TTFB)
 
This leads to slower page loads for a large portion of traffic, especially from campaigns.

## How to fix it

Most issues come from:

- Cache misses due to unique query strings
- Backend logic triggered by parameters
- Personalization or tracking logic executed server-side
- CDN not configured to ignore marketing parameters
- Duplicate cache entries per parameter variation
- Newly introduced parameter keys ([like srsltid](https://www.rumvision.com/blog/srsltid-impacting-core-web-vitals-via-ttfb-caching/?format=md)) by third parties
 
Possible causes and fixes:

### 1. Ignore marketing parameters in caching

Ensure tracking parameters do not create separate cache entries.

#### What to do

- Configure CDN to ignore query parameters like:
- `utm_source`, `utm_medium`, `utm_campaign`
- `gclid`, `fbclid `(and other [ad-related query string keys](https://www.rumvision.com/blog/google-ads-impacting-core-web-vitals/?format=md))
- Use cache key normalization
 
#### Example (conceptual)

Instead of:

 ```
/page?utm_source=google  /page?utm_source=linkedin
```

Cache as:

 ```
/page
```

### 2. Prevent backend processing of tracking parameters

Marketing parameters should not trigger heavy logic.

#### What to check

- Avoid parsing query params unnecessarily in controllers
- Do not trigger database queries based on tracking params
- Strip parameters early in the request lifecycle if not needed
 
### 3. Normalize URLs early

Handle parameters before they reach expensive parts of your stack.

#### What to do

- Redirect to a clean URL (optional, depends on tracking needs)
- Or internally normalize request handling
 
### 4. Improve CDN configuration

Many regressions are caused at the CDN layer.

#### What to check

- Cache key settings
- Query string handling (ignore vs include)
- Edge caching rules
 
### 5. Avoid duplicate rendering paths

Different query params should not create different HTML responses unless required.

#### What to check

- SSR frameworks rendering unique pages per query string
- Static generation fallback behavior
- Cache fragmentation in edge functions
 
### 6. Browser cache

Allow pages to come from browser cache, even when query strings are suddenly involved

#### What to check

- Prefetched and prerendered pages without query strings, while actually clicked links do include query string keys
- Visitors landing on homepage from ads, and clicking on the logo which does not contain query string keys
- Both pagehits could be served from cache with [No-Vary-Search](https://www.rumvision.com/blog/no-vary-search-fixing-cache-breaking-tracking-parameters/?format=md) response header (Chromium-only)
 
## Further debugging

### How to approach this in RUMvision

1. Open the todo
2. Identify the **query parameter**
3. Compare: 
    - Requests with the parameter
    - Requests without the parameter
4. Check caching behavior: 
    - CDN cache hit rate
    - Server response time
5. Apply fixes (usually caching or normalization)
6. Monitor improvement over the next 7 days
 
### Pro tip

Focus on:

- High-traffic parameters (e.g. `utm_campaign`, `gclid`)
- Landing pages from paid campaigns
- Mobile traffic (often more sensitive to TTFB)
 
Fixing one parameter at CDN level can improve performance across **all campaign traffic instantly**.