In this section, you will learn how to use the Jovo User class to persist user specific data and create contextual experiences for your voice apps.
- Introduction to the User Class
- Database Integrations
- Meta Data
- Session Data
- User ID
User object offers helpful features to build contextual, user specific experiences into your voice applications.
You can access the user object like this:
There are certain configurations that can be changed when dealing with the user object. The following are part of the Jovo default configuration and can be changed in the
Also, by default the framework will write to the database with every user interaction (request & response). To enable data caching, i.e. only write to the database if the state of it has changed between the request and the response, you have to add the following to your configuration file:
Below, learn more about operations you can do for user-specific data:
This will save data with your user's
userID as a mainKey, and a
key and a
value specified by you.
After you saved data, you can use a
key to retrieve a
value from the database.
This will delete your whole user's data (the
mainKey) from the database.
The user object meta data is the first step towards building more contextual experiences with the Jovo Framework. If the feature is enabled, the following data is automatically stored inside your database:
||Timestamp: When the user first used your app|
||Timestamp: The last time your user interacted with your app|
||Timestamp: How often your user engaged with your app|
You can enable meta data like this:
You can also overwrite any other of the default configurations:
The user context is used to automatically store data from past interaction pairs (request and response) inside an array. To be able to use this feature, a database integration is required (data is stored in the FilePersistence
db.json by default, but for e.g. AWS Lambda it is important to set up DynamoDB).
User context can be enabled like this:
This works like pagination. The most recent request and response pair is stored at
Right now, the following data can be accessed (with index
||String: Intent name|
||String: State name|
||String: Session Id|
||String: Timestamp of request|
||Object: Contains all the slots (filled & unfilled). Example: You got a slot called
||String: Primary speech element|
||String: Reprompt element|
||String: State name|
The default configuration looks like this:
You can freely adjust how many of these request-response pairs should be saved by changing the array
size in your app's config to an Integer equal to or bigger than 0.
You can also decide what you want to save and what not. Simply change the value of the unwanted data to
Some platforms do not provide the ability to persist data throughout a session. In that case, you can save the data in the database. Other platforms, e.g. Twilio Autopilot, need to save the session ID in the database for the
NEW_SESSION built-in intent to work.
You can enable both in your project's configuration:
If the feature is enabled, the database entry will have the following structure:
It is also possible to provide
dataKey which changes the key under which the data gets saved:
This is helpful, because some database-integrations like MongoDB do not allow special characters like
$as field names.
This will cause the database-entry to have the following structure:
updatedAt column allows you to store the last time the database entry was updated at (String ISO 8601 format).
The option is disabled by default, but you can enable it inside your config file the following way:
Returns user ID on the particular platform, either Alexa Skill User ID or Google Actions User ID:
This is going to return an ID that looks like this:
Note: Google Action user IDs are generated by Jovo and stored in the Google Action user storage. Learn more about the process here.
Returns the platform's locale: