How to add analytics to an AI-built app

The short version of how to add analytics to an AI-built app: pick four events before you write any code, give each one a question it answers, then instrument them one at a time. The order matters more than the tool. Ask an AI builder to "add analytics" and you will get a provider script in the head tag, a dozen automatically captured page views, and no way to answer the only question you actually have, which is whether anyone is finishing the thing your app does.

Page views are not analytics. They are traffic. This guide is about the other kind.

The four events to start with

Every app has a spine: someone arrives, tries the thing, succeeds at the thing, comes back. Four events, four questions.

Name core_action for your app specifically. For an invoicing tool it is invoice_sent. For a booking app it is booking_confirmed. Resist the generic name: in six months, "core_action_completed" in a dashboard will mean nothing to you, and every event you cannot interpret at a glance is an event you will stop looking at.

Four is not a starting point you graduate from quickly. Most small apps never need more than about ten. Every additional event is a thing to maintain, and unmaintained events are worse than no events because they produce numbers that look real.

Where the events go

Server side, wherever you have the choice. Client-side tracking is blocked by extensions, dropped by flaky networks and inflated by bots, so your numbers are systematically wrong in a direction you cannot measure. If the action results in a database write, fire the event next to the write, in the same request, after it succeeds.

The exception is anything that never touches your server: a button that opens a modal, a step abandoned before submission. Those have to be client side, and you should treat their counts as directional rather than exact.

Fire on success, never on intent. A click on Save is not a save. If the write fails, you have logged a completion that did not happen, and your success rate quietly overstates reality forever.

How to add analytics to an AI-built app without duplicates

The failure mode is predictable. Ask for analytics in general terms and the model adds tracking in a scattering of plausible-looking places, some duplicated, some in components that render twice, none in the one code path you cared about. It is not being lazy. "Add analytics" has no correct answer, so it produces an average of everything it has seen.

Specify the event, the exact trigger point, and the properties. One event per request:

Add a single analytics event called invoice_sent.
Fire it in the POST /api/invoices handler, immediately after the
database insert succeeds and before the response is returned.
Properties: user_id, invoice_total, currency, line_item_count.
Do not add tracking anywhere else. Do not add a client-side script.
Show me the diff before applying it.

Then check the diff yourself. This is the step people skip, and it is where duplicate events are born. The pattern generalises well beyond analytics, which is the whole argument in stopping AI from changing code you did not ask it to.

After each event, test it. Trigger the action once, confirm exactly one event arrives with the right properties. Doing this per event takes a few minutes. Doing it after adding eight events at once takes an afternoon of guessing which one is double-firing.

Properties: enough to segment, no more

An event without properties tells you a count. An event with properties tells you which kind of user, doing what, with what result. That is the difference between knowing conversion dropped and knowing it dropped for people on the free plan using the import feature.

Useful defaults on every event: user id, plan or tier, and whether the account is under a week old. Then one or two properties specific to the event, describing the thing that happened.

Do not put personal data in event properties. No email addresses, no names, no message contents, no uploaded file names. Analytics providers are third-party processors, event streams get replicated into warehouses, and this is exactly the kind of leak that turns into a disclosure obligation. Send an opaque user id and join to your own database when you need the identity. If your app handles anything sensitive, the reasoning in how to write a privacy policy for an AI app applies to your analytics pipeline too.

Picking a tool without overthinking it

For a small app the choice matters much less than the instrumentation. Three broad options:

• A privacy-focused page analytics tool, if you genuinely only need traffic. Fast to add, no consent banner in most configurations, no funnels.

• A product analytics tool with an events API, which is what the four-event model above assumes. Free tiers are generous enough for early apps.

• Your own database. A single events table with timestamp, user_id, name and a JSON properties column costs nothing, never gets blocked, and answers most questions with a SQL query. Underrated for apps that already have a database.

The third option is the one AI builders rarely suggest and small apps most often should take. You already have a database. Adding a table is a one-line migration, and your data stays where your other data is. Our note on how to choose a database for an AI-built app covers the underlying storage decision.

The three mistakes that make the data useless

Double counting. A component that renders twice fires twice, and React strict mode in development will do it for you as a courtesy. If a number looks suspiciously round or suspiciously large, this is the first thing to check.

Renaming events halfway through. The moment you rename signup_completed to user_signed_up, your history splits in two and every comparison against last month silently becomes wrong. Pick names you can live with, write them down in one file, and treat that file as the contract.

Tracking things you will never act on. Scroll depth, time on page, mouse movement heat maps. Each one is interesting once and never again, and collectively they bury the four numbers that matter. If you cannot name the decision a metric would change, do not collect it.

There is a fourth that is less a mistake than a habit: not looking. Instrumented apps whose owners never open the dashboard are extremely common, and the fix is a recurring fifteen minutes in the calendar rather than a better tool.

Consent, briefly

If you have EU or UK users and your analytics sets cookies or fingerprints devices, you need consent before it runs. The UK regulator's guidance on cookies and similar technologies is the readable version, and the important detail is that the rule is about storing or accessing information on the user's device, not about whether the data is personal. Server-side event tracking tied to an account you already have a lawful basis to hold sits in a different place from third-party client-side cookies, which is one more reason to prefer server side. Read the guidance rather than a blog post, this one included, before deciding you are exempt.

What to do with the numbers

One review a week, fifteen minutes, three numbers: how many people started the core action, what fraction finished it, and how many came back. Write them down somewhere you can see the previous weeks.

The value is entirely in the trend. A completion rate of 40% means nothing on its own. A completion rate that was 55% last month means something specific, and it means it now rather than at the end of a quarter. That is the only thing analytics gives a small app that intuition does not, and it is worth the afternoon it takes to set up properly.

FAQ

Can I ask AI to add analytics to my whole app at once?

You can, and you will get duplicated and misplaced events. One event per request, with the trigger point named, is slower to ask for and much faster overall.

Do I need a cookie banner for analytics?

It depends on whether you are storing or reading anything on the user's device and where your users are. Server-side event tracking on an existing account is the least entangled option.

How many events should a small app track?

Four to ten. Beyond that you are collecting rather than measuring, and the extra events tend to be the ones that silently break.

Why are my analytics numbers lower than my server logs?

Client-side tracking gets blocked, most often by browser extensions and privacy settings. Expect a meaningful gap and instrument server side where you can.