Web and product analytics, set up by your coding agent. Your tracking plan lives in your repo and powers typed events, charts, funnels and CI checks. Understand visitors and revenue, measure anonymous traffic without cookies, and start free.
Your agent reads your codebase, adds tracking for meaningful actions, and works through verifying the first events. You approve sign-in and review the changes.
The part I’m most excited about is what happens after setup. Your tracking plan lives in analytics.yaml, alongside your code. That file powers typed event helpers, charts and funnels. CI checks help catch mismatches as your app changes, so tracking can be reviewed with the features it measures.
You also get traffic analytics, customer journeys, Stripe revenue tracking and a live visitor globe. Anonymous traffic uses no tracking cookies, and you choose which dashboard widgets to make public.
The public beta is open to everyone. The free plan includes one project and 25,000 events per month.
What’s the first question you’d want Analytiics to answer about your app?
Report
Tracking plan in the repo with CI checks is the part I'd actually use — every analytics setup I've had drifted from the code within a month. Practical question: I just moved my pricing page to an embedded checkout that runs in a cross-origin iframe (the payment provider's domain), so the "purchase" event never fires on my page — I only learn about it from a webhook later. Can Analytiics take a server-side event from that webhook and stitch it back to the anonymous visitor who clicked "Go Pro", without cookies? That's the funnel step I'm blind on today.
@lucas_centomo Good question, and that setup is actually the one the tool assumes. The browser endpoint ignores revenue on purpose (anyone can post to it), so a purchase event was never meant to fire on the page. The purchase comes from the provider, and the only job for the page is to leave a join key behind.
Two ways to do that:
1. Signed-in users: call window.analytiics.identify(user.id) after signup/login, then pass that same id as client_reference_id (or metadata.analytiics_user_id) when your server creates the checkout session. Embedded checkout still creates the session server-side before the iframe loads, so the cross-origin part doesn't matter.
2. No sign-in: read window.analytiics.session() on the pricing page, send it along with your create-checkout request, and put it in the session's metadata.analytiics_session_id. That credits the entry source of the visit that bought.
If the provider is Stripe, you don't need any webhook code. Paste a restricted read-only key in project settings and it imports payments, refunds and renewals every few minutes, reads that metadata, and credits the first visit. Add integrations: [stripe] to analytics.yaml so the repo says where revenue comes from, and analytiics check will warn if the manifest and the connection disagree.
For any other provider, your webhook handler sends the purchase with the server SDK (revenue() with eventId: event.id, so replays don't double count). The drift check scans server-side track({ name }) calls too, so a purchase event marked revenue: true in the manifest is satisfied by the webhook code, not the page. Codegen won't even give you a browser call for it.
One honest limit: anonymous ids rotate daily, so a visitor who browses Monday and buys Wednesday without ever being identified gets credited to Wednesday's session, not Monday's. Docs: analytiics.co/docs/stripe and /docs/sdk.
Liinks
Hey Product Hunt! I’m Charlie, the maker of Analytiics 👋
The idea behind Analytiics is simple: analytics should be part of the way you build your app.
Give your coding agent this prompt:
Your agent reads your codebase, adds tracking for meaningful actions, and works through verifying the first events. You approve sign-in and review the changes.
The part I’m most excited about is what happens after setup. Your tracking plan lives in analytics.yaml, alongside your code. That file powers typed event helpers, charts and funnels. CI checks help catch mismatches as your app changes, so tracking can be reviewed with the features it measures.
You also get traffic analytics, customer journeys, Stripe revenue tracking and a live visitor globe. Anonymous traffic uses no tracking cookies, and you choose which dashboard widgets to make public.
The public beta is open to everyone. The free plan includes one project and 25,000 events per month.
You can explore real traffic on the Thiings dashboard before connecting anything.
What’s the first question you’d want Analytiics to answer about your app?
Tracking plan in the repo with CI checks is the part I'd actually use — every analytics setup I've had drifted from the code within a month. Practical question: I just moved my pricing page to an embedded checkout that runs in a cross-origin iframe (the payment provider's domain), so the "purchase" event never fires on my page — I only learn about it from a webhook later. Can Analytiics take a server-side event from that webhook and stitch it back to the anonymous visitor who clicked "Go Pro", without cookies? That's the funnel step I'm blind on today.
Liinks