Add Product Analytics to Any Web App With PostHog

Describe Your Product

Are people actually using this feature? Where do they stop? Do they come back? Your answers become a short tracking plan.

Plan Your Product Tracking

Describe your app, its success action and the journey to it, and let AI turn it into 5–10 clear product events before anything is installed.

I want to add product analytics with PostHog to this existing web app, so I can see what users actually do inside the product — whether they use the main feature, where they stop, and whether they come back. What the app does: {{APP}} The main thing a successful user does: {{SUCCESS}} The steps that lead up to it: {{JOURNEY}} The features I most want to know people use: {{FEATURES}} Whether people sign in: {{ACCOUNTS}} The flow I most want to improve: {{FLOW}} Do not change any files, and do not install anything. This task only plans the tracking. Look through the project only enough to use its real names — its features, pages and actions — so the plan describes this app rather than a generic example. Do not audit the code yet. That is the next step. Turn my answers into a short tracking plan with exactly these parts: 1. Success action: the one outcome that means a user got real value, in one sentence 2. Events: about 5 to 10 product events. For each one give: - Event name - When it fires — only after the action has actually succeeded - Useful, safe properties, such as plan, feature, project type, source or the option chosen - Why it matters — which question it answers 3. Main funnel: the events in order, from the start of the flow I want to improve to the success action — only the steps that are really needed 4. Key trend: the one number to watch over time, such as projects created per day 5. Retention: whether coming back is meaningful for this app, and if so, which event counts as coming back — or "not meaningful for this app" 6. Signed-in users: how people will be recognised after they sign in — or "the app has no accounts" 7. Never sent: the private information that must never go to PostHog for this app Rules for the events: - Track outcomes, not clicks: booking_completed, not submit_button_clicked - Use one naming style: lowercase words joined by underscores, the thing first and then what happened to it, in the past tense — for example project_created, booking_completed, file_uploaded - No vague names such as button_clicked_2, and no event that only repeats a pageview - A few meaningful events beat dozens of noisy ones. Go above 10 only if the app genuinely needs it. - Leave pageviews, traffic sources, SEO and ad attribution out of this plan — they are web analytics, not product analytics - Never plan passwords, sign-in tokens, API keys, payment details, full private form contents, private AI prompts or other sensitive personal information as properties - Do not force a typical SaaS funnel onto this app — follow what it really does - If my answers conflict with the project or leave a gap, ask me instead of guessing Finish with the plan as a compact list I can copy and keep. Then wait for my approval. Do not implement anything.

What does your web app do?

Freelancers write client proposals with AI and send them for approval.

What is the main thing a successful user does?

Sends their first proposal to a client

Which steps lead up to it?

Sign up, create a proposal, generate it with AI, send it

Which features do you most want to know people use?

AI rewrite, templates and PDF export

Do people sign in?

Is there one flow you most want to improve?

New users leave before sending their first proposal

Adjust the plan with the AI until each event answers a question you care about, and keep this conversation open — every later prompt builds on it. If you ever start a new conversation, paste the plan in first.

Approve the Tracking Plan

You should now know which few actions to track, and which questions each one answers.

Every event is a real outcome, not a button click

The plan has about 5–10 events with clear, consistent names

The funnel follows the path to my success action

It lists the private information that must never reach PostHog

I saved a copy of the final plan

Inspect Your App

Nothing changes in this step. The AI finds exactly where each action succeeds, and what tracking already exists.

Check the App

Let AI map your routing, sign-in, existing analytics and consent logic, and find the exact place each event should fire before anything changes.

Using the tracking plan we just approved, inspect this app before anything is installed. Do not change any files and do not install anything in this task. If the approved plan is not in this conversation, STOP and ask me to paste it. Find and report: - The framework, build system and routing - Authentication, if the app has it: the provider, how sign-up, sign-in, sign-out and session restore work, and the stable user ID it provides - Existing analytics tools — Google Analytics, Meta Pixel, Tag Manager or others — and how they are loaded - Any existing PostHog installation, and every place PostHog is initialized - Existing event tracking, and any shared analytics helper the app already uses - Where each event in the plan should fire: the exact file and function where the action is confirmed as successful — not the button that starts it - Actions that can happen from more than one place, such as creating a project from two different screens - Actions that only complete on the server, such as a payment confirmed by a webhook - The environment-variable convention, including the prefix the frontend needs - How and where the production app is deployed - Any cookie or analytics consent logic that already exists, and what it controls Then give me: 1. What already exists 2. What should be reused 3. Where PostHog should initialize — exactly once 4. Where each event in the plan should fire, file by file 5. How signed-in users should be identified, and where to reset on sign-out — or that the app has no accounts 6. Duplicate-tracking risks: re-renders, route changes, retries, repeated listeners, or another tool sending the same event 7. Implementation plan: the smallest set of changes, in order Rules for the plan: - Never plan a second PostHog initialization. If PostHog is already installed, extend it. - Keep existing analytics such as Google Analytics working. PostHog runs alongside it. Remove nothing unless there is a real technical conflict, and tell me first. - If the app has a consent system, PostHog must follow it - If the plan asks for an event the app cannot detect reliably, say so and suggest the closest reliable one Wait for my approval before changing anything.

Approve the Plan

Approve the plan once every event has one clear place to fire.

Each event is mapped to the exact place where its action succeeds

Sign-in and sign-out are covered, or the plan says the app has no accounts

Existing analytics such as Google Analytics stays in place

The plan names the duplicate-tracking risks and how to avoid them

Create Your PostHog Project

Sign in to PostHog, or create an account and choose your data region — US or EU Create a project for your web app Copy the project token and the host from the setup snippet PostHog shows

The project token is designed to be public: apps use it to send events, and it cannot read your data. Personal API keys are different — they can read and change your PostHog data, so they never go in your app.

Expected result

You have a PostHog project, its project token and your region’s host.

Connect the App

The AI adds PostHog once, with basic activity and privacy settings, alongside any analytics you already have.

Connect PostHog

Install the official PostHog SDK for your framework, initialize it once, separate development from production and keep private areas out of autocapture.

Now connect PostHog to the app, following the approved plan. My PostHog project exists, and I will give you its project token and host when you ask. If the approved plan is not in this conversation, STOP and ask me for it. Set up: - Use PostHog's current official SDK and setup for this framework, following PostHog's current documentation — check it rather than relying on memory, because the recommended setup and default options change. PostHog's setup wizard is fine if you review everything it changes. - Initialize PostHog exactly once, at the app's entry point. If PostHog is already initialized anywhere, reuse that instead. - Read the project token and the host from the framework's normal public configuration — for example VITE_ or NEXT_PUBLIC_ environment variables. The project token is designed to be public, so it belongs in frontend code. - Use the host for my PostHog region — US or EU — exactly as my project's setup snippet shows - Keep development activity apart from real data: add an environment property to every event — production or development — so development can be filtered out. If a separate PostHog project for development is simpler for this app, use that instead and tell me. - Capture pageviews correctly for this app's routing, including page changes that do not reload the page - Keep autocapture on for basic interaction context, but add PostHog's ph-no-capture class to areas that hold private content, such as payment forms, private messages or AI prompt boxes - If the app has a cookie or analytics consent system, start PostHog opted out, opt in only when the visitor accepts, and follow the existing banner's choices - Do not turn on Session Replay, surveys or feature flags in this step - A tracking problem must never break the app or block what the user is doing Personal API keys, project secret keys and any other PostHog management credential must never go in frontend code, a public environment variable or the repository. Nothing in this task needs one. Give me: 1. What you installed and changed, and where 2. The environment variables to set, and where — locally and in my hosting settings 3. What I should see in PostHog after I open and use the app Run the project's build afterwards.

Give the AI your project token and host when it asks Add the environment variables on your computer and in your hosting settings Let the AI finish the changes and the build

Expected result

Opening and using the app now creates basic activity in PostHog.

See Your First Activity

Open your app and move between a few pages Open Activity in PostHog Find the pageviews and clicks from your visit — they can take a minute to appear

Expected result

Your visit shows up in PostHog, tagged as development if it came from your computer.

Add the Product Events

Each event fires once, from the place where the action really succeeds.

Add the Product Events

Add the planned events after each action succeeds — never on the click — with safe properties and no duplicates.

Now add the product events from the approved tracking plan. If the approved plan is not in this conversation, STOP and ask me for it. Events: - Keep every event name in ONE small shared helper or list, so each name is written once and stays consistent. Use the exact names from the plan. - Fire each event only after the action has actually succeeded — after the save, upload, generation or booking is confirmed — never when the button is clicked. If the action fails, fire nothing, or a separate failure event only if the plan has one. - Where an action can happen from several places, fire the event from the one shared place where it succeeds, so it is captured exactly once - Where an action only completes on the server — for example a payment confirmed by a webhook — capture it there with PostHog's official server SDK and the same user ID, or tell me the simplest reliable alternative - Never fire an event from rendering code, or from an effect that can run twice. Guard against re-renders, route changes, retries and repeated listeners. - If the app already sends the same moment to another analytics tool through a shared helper, add PostHog there rather than creating a second call path Properties: - Attach only the useful, safe properties from the plan, such as plan, feature, project type, source, success state or the option chosen - Never send passwords, sign-in tokens, API keys, payment card details, full private form contents, private AI prompts or sensitive personal information. Send an ID, a category or a length instead of private content. A tracking call must never block, slow down or break the user's action. If PostHog fails or is blocked, the app carries on normally. Give me: 1. Each event, the file and function where it fires, and its properties 2. How duplicates are prevented Run the project's build afterwards.

Expected result

Each planned event fires from the one place where its action succeeds.

Identify Signed-In Users

If your app has no sign-in, the AI confirms that and changes nothing.

Identify Signed-In Users

Link each signed-in user by their account ID, keep their anonymous journey, and reset on sign-out so a shared browser never mixes people up.

Now make PostHog recognise signed-in users correctly. If the approved plan is not in this conversation, STOP and ask me for it. If the app has no sign-in, tell me that anonymous tracking already covers it, change nothing, and stop. Otherwise, following PostHog's current identify and reset documentation: - After sign-in or sign-up succeeds, call identify with the stable internal user ID from the existing auth system — never an email address as the ID - Also identify when a signed-in session is restored, for example after a page reload, so returning users are not counted as new anonymous visitors - Identify only once the sign-in is confirmed, never with a guess or a temporary value - Let identify link what the person did anonymously before signing in, so their journey stays in one piece. Do not create a separate alias or a second ID for the same person. - Add only a few safe person properties where useful, such as plan or account type. Ask me before sending an email address, a name or anything more personal. - Call reset on every sign-out path — the sign-out button, an expired session and a deleted account — so the next person on the same browser starts fresh and never inherits the previous user's identity - Never identify a second account without a reset first - Server-side events, if any, use the same stable user ID Give me: 1. Where identify and reset are called, and what each sends 2. What happens to someone who browses first and signs in later Run the project's build afterwards.

Expected result

Signed-in users are recognised by their account ID, and signing out starts a fresh visitor.

Test With a Real Test User

No sign-in in your app? Check your anonymous visit in Activity instead.

Open your app in a private window and use it briefly without signing in Sign up or sign in with a test account, and complete the main journey Find the test user under People in PostHog and open their events Sign out, reload the app, and check you now appear as a new anonymous visitor

Expected result

The test user’s important actions appear once each, in order, on one person — including what they did before signing in.

Plan Your Insights

A trend, a funnel, retention where it fits, and one small dashboard — nothing more.

Plan the Insights

Turn your events into exact settings for a trend, a funnel, retention where it fits and one small dashboard.

Now turn the events into a few useful insights. I will create them in PostHog myself — tell me exactly what to set. If the approved tracking plan is not in this conversation, STOP and ask me for it. Check PostHog's current documentation for insight settings rather than relying on memory. Use only events from the plan. Design: 1. Trend: the key number to watch, such as projects created per day — the event, how it is counted and the time range 2. Funnel: the main funnel from the plan, in order, with only the steps that are really needed — plus the step order and conversion window that fit this app 3. Retention: only if coming back is meaningful for this app — the event that starts it, the event that counts as coming back, and the period, such as weekly. If it is not meaningful, say so and skip it. 4. Features: one trend comparing the features I most want to understand, if the plan has them 5. Dashboard: one name, and the insights above — no more than about six 6. Test filter: what to add under Filter out internal and test users in my PostHog project settings — for example events whose environment is not production, and my test accounts by user ID For each insight, say which question it answers: - Are people reaching the core value? - Where do they stop? - Do they come back? - Which important features are used? Keep it small. Do not add charts that answer none of these questions.

Expected result

You have the exact settings for each insight, and the question each one answers.

Create the Insights and Dashboard

Product analytics New insight

1. Trend

Choose Trends, add the event and the counting from the plan, and save it.

2. Funnel

Choose Funnels, add the steps in order, set the conversion window from the plan, and save it.

3. Retention

Only if the plan includes it: choose Retention, set the starting event, the returning event and the period, and save it.

4. Dashboard

Create one dashboard with the name from the plan, and add each saved insight to it.

Dashboards New dashboard

Expected result

One small dashboard answers your questions: are people reaching the core value, where do they stop, and do they come back?

Optional: Add Session Replay Safely

Watch real sessions to see why people get stuck. Add it only once your analytics works, with private content masked.

Add Session Replay With Privacy First

Record sessions only where they help, with inputs and private text masked and nothing sensitive captured.

I want to add PostHog Session Replay to this app, now that product analytics works. Set it up with privacy first. - Follow PostHog's current Session Replay documentation for this SDK, and tell me which setting to turn on in my PostHog project - Keep every input masked — PostHog masks inputs by default. Never turn that off. - Also mask text that can be private, such as names, email addresses, messages, AI prompts and results, and payment or account details — or mask all text if most of the app is private - Add PostHog's ph-no-capture class to anything that must never be recorded at all - Do not record network request headers or bodies. If network recording is useful, keep only URLs and status codes, and remove tokens from URLs. - Record only where it helps — for example the flow I want to improve — if PostHog's current options allow it - If the app has a consent system, recording follows the same consent as analytics Give me: 1. What you changed 2. What is masked or blocked, and where 3. How to open a recording in PostHog and confirm private content is hidden Run the project's build afterwards.

Test the Live App

A clean private window and a test account prove the whole chain on the real site.

Test Product Analytics

Walk the main journey on the live site and check events, identity, funnel, dashboard, private data and existing analytics.

Help me prove product analytics works on the live app. Events showing up locally is not enough. If the approved tracking plan is not in this conversation, STOP and ask me for it. Test on the production site in a clean private browser window, with test accounts — never a real customer's. Walk me through the main journey, then tell me what to check for each of these: 1. Basic activity from the visit reaches PostHog 2. Each important custom event appears exactly once 3. Events fire only after the action succeeded — a failed attempt creates no success event 4. Event names are clear and match the plan exactly 5. Event properties are correct 6. Anonymous activity is recorded before signing in, where the app allows it 7. Signing in links the visit to the test user 8. Signing out resets the identity 9. A second test account in the same browser does not inherit the first user's identity 10. The main funnel receives the real events 11. The trend and the dashboard update 12. No password, token, key, payment detail or private content appears in any event or property 13. Existing analytics, such as Google Analytics, still works if it was there before 14. PostHog is initialized only once 15. Production sends to the correct PostHog host for my region 16. The app works normally, including when an ad blocker blocks PostHog If the app has a cookie or analytics consent system, also check that PostHog captures nothing before consent and follows the visitor's choice. Do not make claims about legal compliance — only check that the app does what its consent system says. Report expected versus actual for every test, then finish with exactly one verdict: ANALYTICS READY or NEEDS ATTENTION If NEEDS ATTENTION, list only what is still failing.

Continue when the AI reports ANALYTICS READY. If it reports NEEDS ATTENTION, fix the listed issues and run the test again.

Keep Test Data Out

So your own testing never distorts the numbers.

Settings Project

Find Filter out internal and test users Add the filters from your insight plan — for example non-production events and your test accounts Turn the filter on in your trend, funnel and retention insights

Expected result

Your dashboard now counts real users only.

Your web app now tracks the product actions that matter, so you can see what users do, where they drop off, and whether they come back.