If you are working with Dialogflow, you have probably heard of Chatbase.
When it was first introduced, people were thinking "Oh wow! It is like Google Analytics for chatbot conversations". Now it is starting to look like the Zune.
Now, the title is clearly a little click-baity. But please read the article completely because there are a few points you must consider if you are a Dialogflow programmer trying to build out solutions for your end user, whether that is a client, or your place of employment.
Turns out, in its current avatar, Chatbase has a lot of issues.
You need to spend significant resources on the integration
The current Chatbase integration is complex, and there is absolutely nothing "push-button" about it. Expect to spend a good few weeks if you want to integrate Chatbase with your Dialogflow bot.
No built-in Dialogflow (API.AI) integration
The Chatbase site says that it is "Coming soon".
So if you are building a Dialogflow based bot, should you simply wait for the automatic integration to become available? Or should you instead spend weeks trying to build it out to specification only to see that they release the built-in integration the day after you complete your own integration?
You need to understand the concept of 'Not-Handled', which isn't the same as Fallback
While the Fallback intent concept itself can be quite tricky, Chatbase also asks you to add additional tagging for the various intents using the concept of not-handled.
Now this is understandable, as you can get pretty visualizations such as these.
The red frowning emoji is the 'not-handled' scenario, which isn't the same as a fallback.
However, this means you need to wrap your brain around another concept and also you need to figure out which of your intents to classify as not handled.
A better option
My suggestion is to avoid Chatbase, especially in its current avatar.
Instead, you should build out a middleman app. What is a middleman app, you ask? It is basically like a "Proxy service" which
a) receives the message user sends to your agent
b) logs this request message
b) sends the request to Dialogflow
c) gets the response back from Dialogflow
d) logs this response message in your database (or if there is an error, logs the error)
e) sends the response back to the user
You might be thinking: isn't that the same thing that Chatbase is asking us to do?
While the approach might be the same, you get a ton of benefits with this approach.
1 You can get conversation history easily
This is something many folks have requested, and as of date it isn't easy to do this in Dialogflow - you can't just click on a button and get all conversations as say a JSON file.
2 Easier to manipulate the data
As you can imagine, if you log all the data in the simplest format that is most appropriate to your chatbot, you can use the data as you wish. If you send it to a service like Chatbase, you will actually get it back only in a specific format (assuming they make that feature available) and it is entirely possible you might have lost some specific information that is important for you
3 Custom analytics
If you want to perform some specific, custom analytics which make sense only in your particular context you don't have to rely on Chatbase providing that feature someday (say, some kind of integration with your eCommerce store)
4 Cleaning the input
You can correct typos in your proxy service. This will often improve your intent mapping accuracy significantly.
5 Correcting common entity detection issues
Dialogflow seems to have some difficulties extracting entities with periods in them. Once you see this pattern, you can pre-empt it by modifying the request before sending it to Dialogflow and help increase the chances that the correct entity is mapped.
6 Simulate conversation delays
Sometimes, people ask for a way to simulate a delay in the chatbot response, to make it feel more natural. While I don't actually know if adding a delay makes it more natural, it is much easier to implement this feature into your proxy service
7 Get around the 5 second webhook time limit
An interesting use of the proxy service is to get around the onerous 5 second time limit imposed by the Dialogflow webhook. You can do this by doing all the stuff you would have done in your webhook, except now it will be in your proxy service layer.
When you do this, in a practical sense, you are merely moving the webhook processing a couple of steps down the line, but without the ticking 5 second clock, you can first focus on working code, and then worry about optimizing it.
8 Output concatenation
If you have some unusual requirement where you would like to concatenate the output from multiple tabs of your Dialogflow agent (for e.g combine the Default Response and the Facebook Messenger Response), the proxy service is a good place to do this.
9 Transform your output into a specific format
You can also transform the output coming from the Dialogflow response - for e.g. if you have the response written in a format like Markdown, your proxy service can turn it into the appropriate HTML and send it back to the browser. (Of course, you can also do this on the front end - but maybe you don't want to expose all the JSON coming back in the response)
10 Hide your Client Access Token
You can instead create a mapping between an externally visible Guid and the Client Access Token inside your proxy service, and call the proxy using the external Guid as the key.
11 Batch up multiple, short user messages to create a full message
One of my clients once made an interesting request.
"Is it possible for the user to send 2 or more short text messages to the chatbot at once and have it be interpreted as one turn?"
At that time, I told her it wasn't possible (which is true with the 1-click integrations). However, the proxy service allows you to get around this issue, although you do need to know when to stop receiving messages from the user so you can batch them up, which seems like an interesting thing to investigate all by itself.
You might be wondering:
Chatbase could improve very soon
Chatbase could provide specific functionality I can never build
Chatbase is much more scalable
All these are very fair points. But you can always replay your conversations based on the data collected by this proxy service (using the timestamp field) and send it over to Chatbase if you wish. You get the best of both worlds in that case, but more importantly when you have your own data store of request-response messages, it lets you do the kind of slicing/dicing of data that you can never get if you relied solely on Chatbase.