Start with a definition of useful usage
Before a metrics table, pick one task the user wants to complete. Write down what output will be produced and what will be checked in it. A suggested example: the user asked for a comparison, received a document with sources, and checked that every threshold condition appears in it. The act of sending the message to the agent is an earlier stage.
Task completion should fit the type of work. Downloading a file doesn't prove its content is right. Connecting an account doesn't prove the agent performed a permitted action. If human approval is needed, define upfront whether "completed" includes the approval or stops at the draft.
Separate events from interpretation
Build a clear stage list. A synthetic illustration for an onboarding flow: joined, completed a permitted connection, chose a task, received an output, checked a result, and returned for another task. Every stage needs an entry condition you can see, not a feeling from whoever is guiding.
In the Google Analytics documentation, an event measures an interaction on a site or app, and you can define a custom event when no existing event fits. That helps plan collection, but the event name is not business proof. An event called task_completed must be sent only when the agreed definition actually holds.
This guide does not recommend installing Analytics in every system. You can also start with minimal consented manual logging, without copying the task content or the conversation.
Keep a base group and a measurement period
The total number of joiners and the number of this week's finishers are not the denominator and numerator of one measurement. The finishers may have joined earlier, or new joiners haven't had time to perform a task yet.
Choose a cohort of joiners and a follow-up window. A suggested example: everyone who joined in a given week, and whether they reached a checked output within the following seven days. This is an experiment proposal, not a window that fits every product. A task of a few hours and a task dependent on an external vendor need different time frames.
Also note in the report when the data was measured. An old snapshot doesn't become a fresh data point because the post was published again or later. The data date and the publication date should stay distinct.
Look for the stopping point
A funnel report can show where people move between stages and where they drop. The Google Analytics documentation distinguishes between an open funnel, which allows entry at different stages, and a closed funnel that starts at the first stage. The choice changes who gets counted.
Even without an analytics tool, ask whether a person stopped because of connection, not choosing a task, an unclear output, or waiting for approval. Those are different problems. Sending everyone another reminder message doesn't automatically fix any of them.
The number of events is not the number of people. A repeated attempt can create several events for the same task. Define how you identify an attempt, how you handle duplicates, and what you count when a task is reopened.
Add a small quality check
Check a sample of outputs against the agreed criteria, with permission to use the data. You can ask the user to mark what helped and what needed fixing without sending a whole private document.
Example: if ten documents were produced and sources were checked in only some of them, don't merge them into one line called "ten successes". You can report separately output that was returned and output that was checked. When there's no evidence of quality, write what's missing instead of completing the number to match expectation.
End with one change you can test
Pick the prominent blocker and suggest a small change: clearer connection instructions, a shorter first task, or a result check that's easy to understand. Compare the same success definition in the next period, and note what changed.
Measurement should help people reach a result, not collect more information about them. Keep only what the question you defined requires, with proper consent and a clear retention period. A successful onboarding flow is useful usage you can explain, not growth in a number on a card.