Lovable’s own analytics counts visits once you publish, and its docs say: “To track steps such as sign-up and purchase, connect a dedicated analytics tool”.
This guide applies OXVO’s documented steps for an existing website to a Lovable app you already published, and shows how to check whether a real visit and a real event arrive.
Before you start
Your website does not need to be built with OXVO Builder. Connect it to Console and install the integration in the app you already maintain.
Use a workspace you administer for setup. You’ll need access to your app’s deployment, its HTTPS website address, and a simple action you can test, such as completing signup.
Console asks for the site’s HTTPS origin: the scheme and hostname, with a port when needed, for example https://shop.example.com. It is not a page URL such as https://shop.example.com/cart. Register the address visitors actually use, including the correct subdomain.
For a Lovable app, register the HTTPS origin of your published app (by default an address ending in lovable.app, or your custom domain), not the editor preview.
For the general connection flow, see How to connect an existing website to OXVO Insights.
Step 1: Register the app in OXVO Console
Open OXVO Console and choose the workspace that should own the data.
Open Insights and use the add-site control beside the app selection.
Enter a recognizable name, the site’s HTTPS origin and the intended environment.
Submit the setup and follow its status. When installation instructions are available, copy the ones for this site.
Use the complete installation settings. A Console-managed site needs more than a project token. Keep the host, app, environment and installation settings together. Don’t swap them for a generic SDK example or for settings from another site.
Step 2: Add the installation to your Lovable app
Follow the snippet or package instructions displayed in Console for this site. Install once.
After Step 1, Console shows this site’s installation: an npm install line, a Copy installation button, and a browser module snippet that uses the installation settings Console returned for this site. It isn’t a script tag.
Run the npm install command exactly as Console shows it for this site, including any version it specifies.
Copy the module snippet exactly from Console. Don’t type in or change any token, host, ID or other setting, and don’t reuse settings from another site or a generic example.
The snippet is module code: an import, the settings Console supplied, and a call that initializes the integration and returns a client (this guide calls it analytics; use the name your snippet gives it). Don’t paste the whole module unchanged inside a function, component or React effect. Keep its import, and any export, at the top level of a module. Run the initialization once, in code that runs only in the browser: on client mount, or in the browser entry for server-rendered apps. Never run it in server code or a component’s render body. Keep the returned client where your event handlers can use it.
Let your app’s actual structure decide the exact file. For example, the snippet can live in its own module that only browser code imports, or a client-only mount hook can run the initialization and keep the returned client for your handlers.
Don’t invent or replace the values Console supplied, and don’t add requestConsent or setConsent calls. Apart from the one tracked event in Step 4, don’t add calls that aren’t in Console’s snippet.
On TanStack Start, the default for new Lovable projects, initialize only in a client-mounted effect or the browser entry, never in a route loader, server function or a component’s render body.
Ask Lovable in the project chat. Paste the npm install command and snippet Console showed you, and say where they belong, for example:
Run the npm install command below exactly as Console shows it. Then add the module snippet below once, keeping every value in it exactly as Console supplied. Keep its import, and any export, at the top level of a module; don’t paste the whole module inside a component or effect. Make the initialization run once, only in the browser: on client mount, or in the app’s browser entry point. Never run it in server code, a route loader, a server function or a component’s render body. Keep the client the snippet returns available to event handlers. Choose the placement that fits this app’s structure and tell me which file you used. Don’t invent or replace any settings, don’t add any other calls, don’t change anything else, and show me the diff. If the package can’t be installed in this project, tell me instead of working around it.
Lovable notes that saved manual changes “apply to your project immediately, just like changes Lovable makes”.
Or edit the code yourself. Open the Code tab in the project toolbar. Code editing is available on paid plans; on the Free plan the editor is read-only. Save with Save or Cmd/Ctrl+S; each save becomes a version in your project’s version history, so you can revert it.
Which file that is depends on the project’s template: TanStack Start became the default for new Lovable projects on May 13, 2026, and older projects use React + Vite. If you’re not sure where the app starts in the browser, ask Lovable which file is the browser entry point, or which root component can run the initialization on client mount, and put it there.
Add it once. Don’t combine a manual installation and a separate script snippet on the same page.
Whichever way you make the change, check that the package was actually installed for this project before you publish. A chat request or a saved code edit alone doesn’t confirm it.
If you later upgrade an older project to TanStack Start, the upgrade “moves your page titles, descriptions, social preview tags, and analytics scripts into the new template”. Re-run Step 4 after the upgrade anyway.
Step 3: Publish the change
Lovable deploys a snapshot when you publish. To push later changes, open the Publish dialog and click Publish changes.
Until you publish, the live app doesn’t have the installation, so nothing reaches Insights from real visitors.
Step 4: Verify one real visit and one real event
Follow any pending setup action first. Prepared is not the same as collecting: a saved site connection doesn’t prove that a published page sends analytics. Collection starts once Insights setup is complete and the deployed integration initializes successfully.
Check that the published HTTPS page includes the integration, not only the editor preview.
Open the HTTPS site in a clean browser session. Visit two public pages and complete one action your app tracks. Note the time and event name. Avoid personal information or secrets in test data.
For a single-page app, test a route change as well as a full page load. Check the integration before adding any extra pageview calls, so one navigation isn’t counted twice.
Return to Insights. Select the same app and environment, and a date range that includes the test. Check Web analytics for the visit and Product analytics for the event.
Once collection is active, the installation sends pageviews and page leaves automatically, even with autocapture off. These count as traffic in Web analytics. They aren’t Product analytics actions and don’t show that setup is complete.
An action such as completed signup appears in Product analytics only if the app sends a track call for it. Send it through the client that Console’s snippet already initialized (called analytics here; use the name your snippet gives it), from the code that runs when the action succeeds, for example analytics.track('signup_completed').
The managed SDK reference lists the limits for event properties, but its examples use a separate insights interface. Don’t import it and call insights.track instead: that interface sends nothing unless it was initialized itself. Don’t add a second initialization or replace the site’s settings just to copy that example.
An SDK connection check is useful, but an event visible in Console is the stronger confirmation.
Treat the app as connected only when both your fresh visit and your tracked event appear for the same app and environment.
No events? Work through troubleshooting: context (workspace, app, environment, date range), setup, deployment, installation, browser blocking, collection, then one known test event.
Counts unexpectedly high? Look for a second initialization, or both a script and a package installation.
Next step
Once your visit and event show up, continue with step 5 of the Set up OXVO Insights guide: create an analysis for the action you tested.
