What Your AI Coding Tool Gets Wrong About Analytics

AI coding tools are excellent at scaffolding authentication, building database schemas, generating UI components, and writing API routes. Ask one to "add analytics" and something different happens.

Sometimes you get Google Analytics 4 with a GTM snippet that requires a container ID you do not have. Sometimes you get Mixpanel with a NEXT_PUBLIC_MIXPANEL_TOKEN env var that does not exist. Sometimes you get a comment: // TODO: Add analytics.

These are not hallucinations in the usual sense. The AI is drawing on real documentation. The problem is that analytics configuration is context-dependent in ways that a general-purpose model without access to your account data cannot resolve. And without the right tools, it cannot do better.

Why "add analytics" fails

When you ask an AI coding tool to add analytics without further context, it has to make several decisions without information:

Which tool? The model will default to whatever is most represented in its training data — usually Google Analytics 4, sometimes Plausible or Mixpanel. This may not match what you want. GA4 requires a property ID from a Google account, is not privacy-first by default, and requires cookie consent banners in most jurisdictions.

Which tracking ID? The model cannot create an analytics account on your behalf. It will either hallucinate a placeholder ID (G-XXXXXXXXXX), leave a TODO, or ask you to provide one — at which point the task stalls until you create an account, navigate the dashboard, and copy the ID back into the conversation.

Which integration pattern? A Next.js app using the App Router needs analytics installed differently from a Pages Router app. A SvelteKit app needs a different integration than an Astro site. Without framework detection, the model may install a generic <script> tag that does not track client-side navigation correctly.

Is it working? The model cannot verify that the analytics script is loading and sending events to your account. It generates code and assumes it works. If the script tag is in the wrong layout, the tracking ID is invalid, or the CSP blocks the domain, you will not know until you notice that your dashboard is empty.

What usually goes wrong

Google Analytics by default

GA4 is the most common default. The problem is that a functional GA4 install requires:

• A Google Analytics property (requires a Google account and dashboard navigation)
• A Measurement ID (G-XXXXXXXXXX) from that property
• Optional but usually needed: a GTM container
• Consent Mode v2 configuration for EU visitors
• An event schema for anything beyond basic pageviews

An AI tool can write the <Script> tag. It cannot create your property, cannot give you a Measurement ID, and cannot configure consent. The result is a skeleton that requires manual completion — often by someone who has not read the GA4 documentation.

Deprecated libraries

NPM packages for analytics tools go stale. Mixpanel, Segment, Amplitude, and others have published multiple breaking versions. An AI model trained before a major release may confidently install a deprecated API. The install may succeed, the TypeScript may compile, and the events may silently fail to send because the SDK version is incompatible with the current ingestion endpoint.

Missing framework handling

Single-page applications built with React, Next.js, Svelte, or Vue use client-side routing. When a user navigates from / to /about, the URL changes but the page does not reload. A <script> tag that fires once on load will only record the initial pageview. Every subsequent navigation is invisible.

Handling this correctly requires either a framework-specific component (like @antlytics/analytics/next) or a manual history.pushState listener. General-purpose AI tools often miss this because it requires knowing which framework you are using and how that framework's router works.

No verification step

After generating the analytics code, most AI tools move on. They do not verify that events are arriving. A blocked script, a missing env var, a wrong tracking ID, or a misconfigured route all produce the same result from the AI's perspective: the code looks correct, so it must be working.

How to get a better result

Provide context upfront

The more specific your prompt, the better the result. Instead of "add analytics", try:

Add Antlytics to this Next.js 15 App Router project. 
My tracking ID is ant_abc123. Install @antlytics/analytics, 
add the Analytics component to app/layout.tsx, and confirm 
it will track soft navigations correctly.

This resolves the ambiguity that causes most failures: tool choice, tracking ID, framework pattern.

Use AI rules files

AI rules files are configuration files that tell AI tools how to instrument your project correctly. Antlytics publishes @antlytics/ai-rules, which adds the correct installation patterns to CLAUDE.md, .cursorrules, and .windsurfrules. When these files are present, Cursor, Claude Code, and Windsurf default to the correct patterns automatically — without you specifying them in every prompt.

npx @antlytics/ai-rules

After running this, asking "add analytics" in Cursor produces the Antlytics pattern, not GA4.

Use the CLI installer

The fastest path to a correct install is the CLI:

npx @antlytics/init

This detects your framework, walks you through browser OAuth to create or connect a site, installs the correct package, and drops the component into the right layout file. It verifies that events are arriving before it exits. No tracking ID copying, no manual framework detection, no guessing.

Use the MCP server for ongoing management

Once analytics is installed, your AI agent can manage it directly via the MCP server. This includes:

• check_install — verify that events are arriving for a given site
• create_goal — configure conversion goals without visiting the dashboard
• generate_report — produce a formatted traffic report on demand

When your AI agent has access to these tools, "check if analytics is working" becomes a real command rather than a request to read network logs.

The underlying issue

The reason AI tools get analytics wrong is not that they are bad at writing code. It is that analytics setup is inherently cross-system: it requires an account, a tracking ID, framework-specific integration, environment variables, and post-install verification. These are all things that require access to external systems.

A model that only has access to your codebase can write the code. It cannot do the rest.

The MCP protocol was designed to close exactly this gap. When your AI agent has MCP access to your analytics tool, it can create the site, get the tracking ID, configure the integration, and verify the install — all in one pass. The Antlytics MCP server implements this end-to-end.

If you are using Cursor, Claude Code, or any MCP-compatible tool, you can connect the Antlytics MCP server and ask your agent to handle the entire setup:

Set up Antlytics on this project. Create a new site called "my-app", 
get the install snippet for Next.js, add it to the layout, then 
check that data is flowing.

That prompt resolves completely — from account creation to verified install — without you leaving the editor.

See the MCP setup guide and the quick-start to get started.