[Stape webinar] Tracking challenges in AI browsers: what marketers and analysts should know

Yes—if your goal is ITP bypass and longer-lived cookies, I recommend using a same-origin setup for your sGTM subdomain.

For your case, same-origin is usually the best approach. Along with bypassing ITP, it also lets you load gtm and gtag.js via your CDN.

I haven’t noticed any direct impact on tracking from this yet. However, I do expect it to influence something else: the volume of organic traffic from search engines.

Bot Detection mainly relies on user agent plus a database of known bot/spam IPs. It may catch basic crawlers, but I don’t expect it to reliably detect AI/agent traffic—especially if it looks like normal Chrome/headless Chrome. If you need AI-bot identification, you’ll likely need additional tools. I see Bot Detection primarily as spam filtering, not AI-agent detection.

I recommend a file proxy approach so CMP/banner scripts load from your first-party domain. You can do this via Stape’s File Proxy Power-Up, or via the File Proxy Client template in the server container (GitHub). You configure the origin and your first-party path, and the CMP script is served from there.

Sometimes it might (especially in an “agentic” mode if you instruct it to click), but in practice I’ve seen cases where AI browsers block consent banners before they even render—so I’d assume they’ll often block it.

No—server-side GTM can receive and handle webhooks, so you won’t miss data for that reason. The bigger risk is relying on client-side GTM only, because in AI-browser flows, it may not load at all. For best coverage, I’d use server-side GTM + webhooks.

In my opinion, gateways usually cover only a small portion of what a full server-side setup can do. They’re a good starting point if you currently have nothing beyond client-side tracking, but they won’t replace a tailored server-side GTM implementation long-term.

I don’t think there’s a single clear indicator. Detection usually relies on multiple signals, and some approaches require CDN/server-log access. If there were one simple flag, this would be easy—so I’d expect ambiguity.

Yes. I’d use the same strategy as for preventing GTM/gtag blocking: proxy and obfuscate CMP scripts. Serve the banner scripts from your first-party domain and avoid obvious filenames/paths (don’t use “cookiebanner/cookiebot”; use neutral names). You can use Stape’s File Proxy Power-Up or the File Proxy Client template.

Maybe. I don’t want to prescribe specific investments, but at minimum I’d say: if you haven’t already, invest in server-side tracking.

I expect consent banners are here to stay. I’m skeptical that “omnibus” changes will remove them entirely. We’ve also done a webinar on consent—I’d recommend checking that out.

Very likely, yes. That said, if Chrome becomes “AI,” it may not create the exact same challenges as AI-first browsers. I also wouldn’t be surprised if Google introduces changes that help.

I’ll share the slides/deck afterward, and I recommend an article by Dana DiTommaso on GA4 channels for deeper context and examples.

For most businesses, I think probably not—platforms like Shopify and other CMS/inventory systems will likely adopt/support it. If you run a highly custom-built stack, you may need to adapt over time—especially if you want to sell via LLM/agent-driven flows.

You can already achieve this via the File Proxy Client (GitHub / Stape resources), and you can use it even on a free plan.

I’d use a mobile SDK—for example, the Firebase SDK. Firebase can send events into a server-side GTM container, and from there you can route events to destinations (Meta, etc.).

Conceptually, I can treat agent fetches as top-of-funnel signals. But tracking is complicated: if agents fetch assets directly (like images via direct URL), there’s no HTML load, so no pixels/tags. You might track via middleware/proxy/CDN logs, but I don’t see a clear general solution here—with Stape or without Stape—under typical conditions.