Full Answer

CDNs sit between the visitor and your WordPress origin, and how they treat query strings is a configuration choice, not a fixed behaviour. Caching is the first risk. To serve more requests from the edge, a CDN can be told to ignore query strings when building its cache key. That speeds up delivery, but depending on the setup it can also mean the cached response is served and the utm_ parameters never propagate to the origin or to the analytics that reads them.

The second risk is edge logic. Page rules, edge redirects, and URL-rewrite features run before your server does, and if any of them rebuild the request URL without reattaching the query string, the campaign tags are gone at the edge. Because this happens upstream of WordPress, no plugin can recover what never arrived.

The fix is to make the CDN parameter-aware. Most platforms let you preserve specific query parameters in the cache key or exclude tagged URLs from query-stripping rules, so you keep the performance benefit without losing attribution. Test it the same way you'd test any hop: click a tagged link through the live CDN and confirm the UTMs reach the final page. And because edge behaviour can change with a config update you didn't make, storing first-touch source server-side gives you an attribution record that doesn't depend on the CDN getting it right every time.