Analytics only earns a place in the workflow when it answers a question the team actually has. “How many visitors complete signup?” is a question. “Show me engagement” is not.
OXVO Insights brings web and product analytics into OXVO Console, alongside replay, AI Guide, and customer messaging. This guide keeps the starting scope deliberately small: connect one app, verify one real event, and turn one question into a saved analysis your team can review together.
Verify the connection before reading the charts
There are three supported ways to connect an app:
An OXVO Builder app: enable the OXVO Insights switch and complete the setup action Builder prepares for that app.
A supported JavaScript or TypeScript app: run the Insights Agent from the project root, approve it in Console, and review the changes it proposes before deploying.
A manual integration: register the site in Console and install the managed browser SDK using the complete installation object Console provides — not a token-only guess.
Whichever path you choose, treat “prepared” and “collecting” as different states. A switch that is on, a saved site connection, or a successful build does not prove events are arriving. Collection starts once setup is complete and the deployed integration initializes successfully on the approved HTTPS site.
The verification ritual is short: open the live site in a clean browser session, visit two public pages, complete one action your app tracks, then confirm the visit in Web analytics and the event in Product analytics for the same app and environment. An SDK connectivity check is useful, but a fresh event visible in Console is the stronger confirmation.
Choose the view that matches the question
Web analytics: where visitors come from, and which pages they use.
Product analytics: which actions users complete.
Funnels and retention: where a journey loses people.
Dashboards: how the team reviews the same metrics.
Ask OXVO: investigating in plain language.
AI Observatory: how instrumented AI requests perform.
Picking the view first keeps reports honest. A busy landing page is not a conversion result, and an analytics session is a reporting unit — not a replay recording.
Instrument outcomes, not clicks
Good analytics starts with a small set of events that describe real outcomes:
Fire the event where the action actually succeeds, not where the button is clicked. A failed request should never look like a completed signup.
Keep properties deliberate: short, predictable values such as plan, source, or method. Never send form contents, credentials, or entire user objects.
Identify signed-in users with a stable, opaque application ID, and reset analytics identity at sign-out so the next person on the same browser does not inherit it.
Give every event one owner. A Builder integration, a manual SDK, and a tag-manager snippet should not all initialize analytics for the same page.
Turn the answer into a shared habit
When a result matters, save it. Create an analysis in Product analytics and name it after the question it answers — “Completed signups by day” beats “Signup chart 2.” Add it to a dashboard only when it belongs in a recurring review.
Build dashboards around decisions, not collections. For signup performance, a traffic trend, completed signups, the signup funnel, and one useful breakdown tell a coherent story: who arrived, who succeeded, and where to investigate. Record the app, environment, date range, and filters alongside any finding you share — and remember that sending a teammate a link does not grant them access.
Ask OXVO, then read the evidence
Ask OXVO lets the team investigate with questions instead of building every report by hand. The useful habit is to read the data checks attached to each answer: which queries or recording references were used, the time window, and data freshness. Confirm the answer addresses the app and period you selected, and separate an observed result from an explanation that still needs investigation. When an answer includes a replay reference and your role has replay access, open the actual recording before making visit-level claims.
Keep collection proportionate
Insights works best with restraint:
Send only the events and properties that answer real questions.
Keep the allowed public-path list focused; other paths are intentionally grouped as
/:path.Use the supported opt-out API where your site offers an analytics preference, and never silently undo a visitor’s choice on the next page load.
Treat AI tool connections as read-only, per-app access, and revoke the ones you no longer use.
A first week that works
Connect one app and verify one fresh event in the correct environment.
Define two or three outcome events with names, triggers, and owners.
Save your first analysis and share it with the question it answers.
Build one small dashboard around a recurring decision.
Run one Ask OXVO investigation and check its evidence before acting.
Start with one question, prove the data path end to end, and let every chart earn its place.
