Session logs
Getting an insight to how users use your application allows you to find ways to improve the application and its experience. This is why we have session logs.
From the session logs page, you get analytics based on completion or network.
For each session entry, you get to see the network, how the user interacted with the app, whether the user completed the session and also responses from your hooks. This offers full transparency into how your application is being used.
Traffic
At the top of the sessions page, USSDK shows a traffic chart for the selected date range.
You can stack the chart by:
Completedto compare completed and uncompleted sessionsNetworkto see how sessions are distributed across networks
This helps you quickly answer questions like:
- Are users completing the flow?
- Did a recent change cause more users to drop off?
- Which networks are sending the most traffic?
- Are some days busier than others?
The completion rate shown above the logs is based on the same filters.
Filtering logs
By default, the sessions page shows logs for the current month.
You can change the date range using the From and To filters. You can also search by:
MSISDNSession ID
This is useful when a user reports an issue and gives you their phone number, or when you already have a session id from a provider, hook request, or support conversation.
Reading the logs table
Each row in the logs table represents one USSD session.
For each session, USSDK shows:
- Date
- Session ID
- Provider
- Network
- Service code
- MSISDN
- Time spent
- Whether the session was completed
Time spent is calculated from when the session was created to when it was last updated. This gives you a quick idea of how long the user spent in the flow.
The completion indicator shows whether the user reached the end of the session. If a session was not completed, it may mean the user abandoned the flow, entered an invalid response too many times, or the session ended earlier than expected.
Viewing session steps
Click Steps on a session row to view the details of that session.
This opens the step history for the session. The history shows the deployment version that handled the session, then lists each step the user passed through.
For each step, you can see:
- The step id
- The user's input
- How long it took to reach that step
- The hook URL that was called
- The hook status
- The hook response
This is especially useful when debugging hooks. You can see exactly which hook ran, what status it returned, and the data USSDK received from it.
Understanding step actions
Some steps may include actions returned by hooks.
For example:
retrymeans the user was asked to try the same step againbackmeans the user was sent back to the previous screenskipmeans USSDK automatically supplied an input and moved forwardendmeans the hook ended the session
If a hook returns an error status, the step is marked as a hook error. You can use the hook status and response to understand why the session did not proceed as expected.
Deployment version
Each expanded session shows the deployment version that handled it.
This matters because users may have gone through different versions of your application. If you changed the flow and deployed a new version, older session logs still show the version that was active when that user started their session.
When investigating a problem, always check the deployment version before assuming the current editor state is the same flow the user experienced.
Loading more logs
USSDK loads session logs in batches. If there are more logs for the selected filters, use Load more to continue through the history.
When to use session logs
Use session logs when you want to understand what happened after users started using your app.
They work well for:
- Investigating support issues
- Checking completion rates after a deployment
- Understanding where users drop off
- Debugging hook responses
- Verifying which provider, network, or service code was used
- Reviewing the exact path a user took through the app
While the Sim tab helps you test a flow before users reach it, session logs help you understand what happened in real sessions.