USSDK

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:

  • Completed to compare completed and uncompleted sessions
  • Network to 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:

  • MSISDN
  • Session 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:

  • retry means the user was asked to try the same step again
  • back means the user was sent back to the previous screen
  • skip means USSDK automatically supplied an input and moved forward
  • end means 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.

On this page