Analytics for your first real users

Name one decision you want the data to inform

For a fictional image-resizing tool, the question might be: “Do visitors get from selecting an image to downloading a resized file?” That leads to a clear sequence: tool_viewed, resize_started, resize_succeeded and download_clicked. A button click is not a successful resize. Place the success event after a real result exists.

You may also need resize_failed, with a small controlled error category such as unsupported_format or file_too_large. Avoid sending filenames, uploaded images, form contents or raw error messages. The event should describe the behavior, not copy the person’s work into an analytics service.

Scroll to see all columns →

Choose a provider you will actually use

GA4 can measure events and acquisition; PostHog supports explicit events and product funnels. Either can be useful for a small project. Using both creates more work to keep definitions consistent, so do it for a reason. Define a shared event plan first rather than letting each integration invent a different meaning for completion.

Check current provider guidance for your framework. Configure only the capture you need. Automatic capture and session replay are separate choices, not prerequisites for understanding a three-step task. Minimize collected information, disclose your actual data practices and honor the privacy choices your product supports. If identifiers are necessary, design them deliberately instead of sending email addresses because they are convenient.

Prove that the event reaches the right project

Use a fresh browser session and perform one identifiable test sequence. Confirm you are viewing the right analytics property, hostname and time range. GA4’s Realtime or DebugView and PostHog’s received events can help confirm ingestion. A script loading successfully does not establish that your custom success event arrived.

Inspect event names and properties for duplicates or accidental private data. One completed resize should not create two success records because two listeners fired. A user cancelling a native share sheet should not count as a successful share. A failed form should not count as saved just because its submit button was clicked.

1. Write down the exact UI sequence you will test.
2. Perform it once on the production address.
3. Find the received events in the intended provider project.
4. Confirm order, names, safe properties and expected counts.
5. Repeat a failure or cancellation path and check it is not recorded as success.

Build a funnel around a real task

Create an ordered funnel from tool_viewed to resize_started to resize_succeeded. Choose a conversion window that fits the task, such as the same short session or a specified day, and document it. Permit irrelevant intermediate actions unless your question requires a strict sequence. A funnel measures its defined sequence; it does not reveal every reason someone left.

Add a separate view for failures and break down by a small useful dimension such as device class. If mobile visitors start but do not finish, try the task on a phone before assuming the audience is wrong. If no successes exist yet, distinguish “no real attempts,” “attempts failed” and “tracking unverified.” Those lead to different actions.

• PostHog funnel definitions ↗

Learn without pretending a tiny sample is a verdict

Your first few visits may be you, your agent, friends or a link-preview crawler. Mark test sessions using a supported filter or maintain a testing note; do not report them as organic demand. Review individual task attempts with voluntary user feedback before making broad claims about conversion rates.

Combine the dashboard with a few observations. A person may finish the action but find the result unhelpful. Another may leave because the page did not explain the input. Keep a decision log: what you changed, why and what outcome you expect. Recheck the event plan when the product changes so an old event name does not quietly acquire a new meaning.