What is the new gbraid parameter?
Google Ads uses the gbraid query key to measure ad conversions, impression data, and other important metrics. This is critical for marketers in assessing the effectiveness of their campaigns and making data-driven adjustments. Without this function, tracking conversions in the post-cookie world could be difficult, especially on Apple devices with enhanced privacy features like IOS14+.
The addition of this query is a strategic move by Google to adapt to the privacy-focused updates of IOS14+, including Apple's App Tracking Transparency (ATT) policy, which requires apps to obtain user permission before tracking their activities.
The impact on performance
While this appears to be a positive development, there may be a problem for online stores that use a CDN (Content Delivery Network) like Cloudflare or Varnish cache. The gbraid query may interfere with caching, resulting in slower load times and a decrease in Time to First Byte (TTFB), Largest Contentful Paint (LCP), and First Contentful Paint (FCP).
Avoid performance impact with gbraid
It is critical to exclude the gbraid query (and its variants) from your caching strategies. This is especially important because Google Ads will officially integrate this query on June 1st. Don't let your visitors of IOS14+ mobiles wait longer than necessary!
The limitations of tracking performance on Safari
Unfortunately, it's not as easy to track performance on Safari, because it isn't a Chromium based browser. Safari doesn't have Core Web Vitals because they are created by Google and not (yet) adopted by Apple. So, for example, we can't see how the gbraid affects things, but we do know that it will be a problem if you don't whitelist it in your caching strategy.
Other parameters causing a high TTFB
Still, to show the possible impact a parameter can have on the TTFB, here we have an example of the gclid, which basically works the same way.
In the screenshot, you can see that a visitor who comes in through the?gclid has a TTFB of 1.5 seconds, while someone who comes in without a parameter has a TTFB of only 500 milliseconds. This is because the ?gclid parameter is not stored in a cache. Also, since the page is always the same, it could be cached. Also, you can see that the gbraid parameter has a value of 0ms. This is because Core Web Vitals measurement through Safari has some limitations.
Conclusion and solution
Every time you find out about a new parameter or RUMvision data shows that a certain parameter makes TTFB and FCP worse, you should add it to your whitelist in your caching strategy. So, you can nost likely add the gbraid and wbraid parameters to your caching strategy so that ad traffic has a good user experience and you don't have to pay twice.
