If you are familiar with the Watson Assistant Plus plan, then you have likely come across the same question as others: How do I determine what constitutes a “unique” user?
The Watson Assistant Plus plan comes with several super cool features, including disambiguation, intent recommendations, and user-based pricing. You can read more from the official announcement: https://www.ibm.com/blogs/watson/2018/12/introducing-watson-assistant-plus-pricing-plan-and-new-powerful-features/
The Plus (and Premium) plan bases its pricing on MAUs (Monthly Active Users). Consider this scenario: You are the owner of a floral shop specializing in yellow roses (my favorite). You would likely create a chatbot to answer common customer inquiries. These may include: what are your store hours, what types of flowers do you sell, and it can look up a customer’s order information. For previous Watson Assistant pricing plans, you were charged per Message API call. If a customer asks, “What type of flowers do you specialize in?” and the bot responds with “We specialize in all types of yellow roses.” then that is 1 Message API call. Each subsequent utterance is another Message API call.
With the Plus plan, you are charged a base rate for “x” number of users (tiered, starting at 10,000 users). So each user could talk to the bot 100 times per week if they wanted, but they are still only considered to be one user. Now to the original point, how do I tell Watson, who is a unique user? In your API calls, there is a parameter called `user_id` which you use to send Watson Assistant the ID for your user. (https://cloud.ibm.com/apidocs/assistant-v2#send-user-input-to-assistant)
You should give each of your users a unique identifier (in the form of a string) as their user ID. Many companies already implement some sort of authentication for their customers, so you may choose to use their existing e-mail address or user ID from your website as their user ID. So if I log in to my floral website with the e-mail address email@example.com, then when I chat with the chatbot while logged in, my chatbot orchestration layer could grab my e-mail address, add it to the payload as the “user_id” then send my message to Watson Assistant. Here’s a snippet to demonstrate:
There is a problem here, however. What if you have a public-facing chatbot? My bot is on the homepage of my floral website. I want any user whether they are currently logged in or not to be able to converse with my chatbot. After all, how else will they know that I specialize in yellow roses? However, if they aren’t logged in, how can I assign a unique “user_id” to them? If I don’t, each API call is considered a unique user. (Update: This applies to v1. v2 uses sessions instead of API calls. So in v2, each session/conversation would be considered a unique user.) The answer: cookies 🍪! When the user visits your website, a cookie is saved on their computer. Then, your website recognizes this cookie on each subsequent visit. You can determine a unique ID for each user to save in the cookie then retrieve that and pass it to Watson Assistant as the “user_id” parameter. Here’s a simple example:
If you are uninterested in using an authentication layer or cookies, you may try using a user’s IP address. There are a few problems with this approach (dynamic IP addresses and VPNs come to mind), but it may work as a rudimentary option.
Note: These code snippets are examples ONLY and are not intended to be implemented in a production environment.