Analytics for an app you built with Lovable, Bolt, v0 or Cursor

A visitor counter, and it barely matters which one. PostHog is the usual pick for a product because it records which element somebody pressed as well as which page they were on. Plausible is lighter and simpler if you only want page views. Google Analytics is free and everybody already knows the shape of it.

1. 1Make an account and copy the snippet it gives you.
2. 2Paste it into your app. In Lovable, Bolt or v0 you can ask the builder to add it and it will put it in the right place.
3. 3Open your own site once, then check the tool shows one visitor. That is the whole test.
4. 4Leave it a week. A day of data mostly tells you about the people you told about it.

That is genuinely it for the first half. You do not need a tracking plan, a naming convention, or a spreadsheet of events. Anybody selling you those is selling to a company with an analytics team.

No, and this is worth knowing because it is the step that stops people. PostHog and tools like it capture clicks automatically and record what was pressed: the text on the button, where it sat, what kind of element it was. You do not have to decide in advance which buttons matter.

That matters more than usual on a generated codebase. If a builder wrote your screens, you did not name the buttons, so a system that required you to name them all up front would be asking you to go and read code you have never read.

Because of what you do not know about your own product. When you write every screen by hand you carry a map of it in your head. When a builder writes them, you carry the map of the four screens you have looked at.

Two things happen routinely in that situation, and neither shows up in a visitor counter.

Screens nothing links to. You ask for a settings page, you get one, and nothing in the product ever takes anybody to it. It exists, it works, it is unreachable. A visitor counter reports this as no data, which looks identical to a screen that is fine.

Buttons that go nowhere. A control that renders and does nothing when pressed. People press it, it does not respond, they leave. If nobody wired an event to it, nothing recorded the press.

Both are visible in the code, which is the thing you have and have not read.

It means reading the app itself: every screen, every route between them, everything a person can press, and every rule that can refuse somebody. Then setting that against the visitor numbers you started collecting in the first half.

Where the two disagree is where the interesting things are. A screen your code says people can reach and your traffic says nobody has. A button that exists in the source and has never once been pressed. A form that asks for six things when four would do.

You can do this by reading the repository yourself. Or userdrift does it reads your code, draws your product as a map, and puts your own visitor numbers on every screen. It reads your app and never changes it.

You can still know what is in your product. It is a reason to be careful about what you change.

Everything above is a fact about your app that can be stated in ordinary words: this screen asks for these things, nothing links to this one, this many people got here and this many got through. None of that requires you to read a line of code. It requires something to read the code and tell you in English.