AI App Builder With Google Analytics: What Connects
AI App Builder With Google Analytics: What Connects
Google Analytics is one of the built-in integrations in Zugo. You paste the measurement ID from your Google property, publish the project, and the tag travels with the live site. There is no plugin, no tag manager and no code edit. The integration delivers the traffic data. Deciding what to do with it stays your job.
That split explains most of what follows. Connecting takes a few minutes. Turning the numbers into a decision takes weeks of small judgements, and no builder does that part for you.
What does the Google Analytics integration actually connect?
The integration places your measurement tag inside the published version of the project. From that point, visits to your yourproject.zugo.run address, or to your own domain once you attach one, are reported into your Google property.
The property belongs to your Google account rather than to Zugo. If you stop using the builder next month, the history stays exactly where it is, with the same access and the same export options as any other property you own. Nothing about the data is held hostage by the tool that generated the pages.
What the integration does not do is change the nature of the measurement. Google Analytics counts what web analytics has always counted: sessions, traffic sources, landing pages, devices, and whatever events you configure yourself. A project assembled by describing it in plain text produces the same shape of data as one written by hand, because it is the same tag on the same kind of page.
One detail catches people out. The tag lives in the published site, not in the editor. A project that was edited but never republished still serves its previous configuration, which is the most common reason a correctly pasted ID reports nothing at all.
What do you need on the Google side first?
A Google Analytics account, a property for this specific project, and the measurement ID that property issues. The ID is the only value that has to travel between the two systems, and it lives in the data stream settings of the property.
Create the property before launch if you can. A property created afterwards begins counting from its own creation date and cannot fill in the past, so the first week of traffic, usually the most interesting week you will ever have, is simply missing.
One property per project is the right default. Pointing three different sites at a single property saves an afternoon now and costs you every future comparison, because you cannot separate later what you never separated at the start.
If a custom domain is planned but not ready, connect analytics to the zugo.run address anyway. The same tag keeps reporting after the domain moves, and you do not need a second property for the switch.
How do you check the tag is really working?
Open the realtime report in Google Analytics, then load your published page. If you appear in the report within a minute or two, the connection is real. If you do not, it is broken, and finding that out today is much cheaper than discovering it after a launch campaign.
Test from a phone on mobile data rather than from the browser you build in. Tracking protection and blocker extensions frequently remove your own visit from the data, and reading that absence as a broken tag sends you fixing something that was never wrong.
When realtime stays empty, work through three causes in order: a mistyped ID, a project that was edited but not republished, and a blocker in the browser you tested from. In practice the middle one accounts for most cases.
Verification is not a formality. An unverified analytics setup is the quietest failure a small site can have, because every screen involved looks correct while the number that matters stays at zero for a month.
What does adding analytics cost in credits?
Connecting the integration is configuration rather than generation, so it is not a build. Credits are spent when the agent produces something: a build costs 6 credits, an edit costs 3, and a multi-page platform costs 12 for the first three pages plus 3 for each page after that. Hi-Fi mode doubles those, so a build is 12 and an edit is 6.
Where analytics does touch your balance is in the edits around it. Asking for a consent banner or a privacy page is an edit like any other. Adding a thank-you page so that a form submission has a URL worth counting is another.
| Piece of the setup | Who handles it | What it takes |
|---|---|---|
| Measurement ID | You, in Google Analytics | One copy and paste |
| Tag in the published site | The Zugo integration | Nothing once the ID is saved |
| Republishing after a change | You | One click |
| Consent banner or privacy page | You, through a normal edit | 3 credits per edit |
| Conversion events | You, in the Google property | Setup inside Analytics |
| Reading the numbers weekly | You | The part that actually takes time |
For scale, Free includes 5 credits, Pro is $25 per month for 200 credits, and Business is $99 per month for 800. Two hundred credits is roughly 16 platforms, 33 builds or 66 edits if you spend them on one kind of action. Measurement work sits at the cheap end of that ledger.
Which numbers matter on a project this small?
Four of them, and the rest of the interface can wait. Sessions by source tells you which channel is working. Landing page tells you where people arrive. Device split tells you what to test on. Conversions tell you whether any of it paid.
Conversions are the row people skip and the only one that changes decisions. Set an event for the action the project exists for: the form sent, the booking requested, the purchase completed. Traffic without a conversion event is a number you can watch but cannot improve on purpose.
Bounce rate and time on page will tempt you, and on a small site they are noisy enough to mislead. Reacting to them produces changes that feel productive and move nothing. Leave them alone until you are seeing hundreds of sessions a week.
Compare like with like. A jump after you posted in a forum is not evidence that your page improved. Hold the source constant when you judge a change, or you are measuring the audience instead of the work. The contact form guide covers the event most small projects should be counting first.
Does connecting your own domain reset anything?
No. The tag follows the project, so a site measured on yourproject.zugo.run keeps reporting once your own domain is attached. Same property, same ID, same history.
The reporting actually improves slightly, because traffic from the temporary address and from your domain land in one place, and a switch reads as continuity rather than a cliff. The DNS side of the move is covered in the custom domain guide.
One habit is worth adopting on switch day: write down the date somewhere you will find it again. Three months later you will stare at a dip and lose an afternoon deciding whether it was the domain, a search update, or the page you changed the same week.
And republish after any integration change. It is the same rule as before, and it is worth repeating because it is the failure people hit twice.
What does analytics not tell you about an AI build?
Three limits, each of which has produced a confident wrong conclusion somewhere.
It does not tell you why. You will see that most visitors leave the pricing section. Analytics cannot say whether the price is wrong, the wording is confusing, or those visitors were never going to buy. That answer comes from asking five people, not from a chart.
It does not count everyone. Blockers, tracking protection and refused consent all remove real visitors from the data, by an amount that varies with your audience. Technical audiences under-report the most, so a developer tool always looks quieter than it is.
It does not verify the project. Every build is booted in a sandbox before it reaches you, and a build that fails to open is reported rather than delivered, which lowers the odds of publishing a blank page. That is a check on the build, not on your funnel. Analytics measures a site that works, it does not confirm that one does.
Consent is the fourth thing worth naming honestly. Google Analytics sets cookies, which brings privacy law into the picture in much of the world. Zugo can build a banner and a privacy page through ordinary edits, but which regime applies to your visitors is a question for you or your lawyer, not for a builder. If the overhead outweighs the value on a small brochure site, measuring less is a legitimate choice.
Where should you start?
Create the property, paste the ID, publish, and confirm yourself in realtime before you do anything else. Then set exactly one conversion event and leave the dashboard closed for two weeks, because daily checking on low traffic teaches you nothing except how noise looks.
The step-by-step version of the connection, including what to do when realtime stays empty, is in how to connect analytics. If you want to see how the tag behaves on a project that grows into several pages, build one first and attach measurement afterwards.
You can set the whole thing up, from the first build to a verified tag, at zugo.dev. Start with one page and one event. A small site you actually measure beats a large one you only guess about.