Naming conventions for Dialogflow ES intents and contexts

Do you capture user input in your chatbot?

For example, do you ask them to provide their name, or email, or other information?

I have recently started using the following convention in the bots I am building (as well as advising on).

Suppose you have an intent which should get user’s email address. You can, of course, name it “EmailAddress”, but that isn’t very obvious.

“Obvious to whom?”, you might ask.

Where do you use it?

The key, of course, is where you use the intent name. It is not just the intents list view.

One use for the intent name, for example, is in the Dialogflow simulator console. Looking at the intent name, you can tell what intent was just mapped. When you receive user input, you want the intent name to convey that some input was indeed received.

Another use is when you are accessing the agent via Dialogflow’s REST API. In this case, it is even more important to have the intent be as self-descriptive as possible because often you don’t have the additional context that you sometimes get when you are inside the Dialogflow console.

A final use for the intent name is in your training and history tab. Here again, you want the intent name to be as descriptive as possible. Almost certainly, you don’t want a confusing intent name in your training tab.

Suggested intent naming convention

Here is what I suggest. Name your intent based on the action which was completed – that is, what is the conclusion you can make from that intent firing?

If you are collecting the user’s email address, you can conclude that “UserProvidedEmailAddress”. That is how specific the intent name should be.

Update: I have improved this a little bit and removed User (which is redundant) and added a period sign between each word because it is easier to read. For example, UserProvidedEmailAddress becomes provides.email.address

Suggested context naming convention

The next question is – how do we know that the intent is ready to accept an email address?

Usually, we set an output contextContexts are used in Dialogflow ES to manage the state of th... More on the previous intent which was triggered. For an intent which is supposed to collect an email address, we should have already set a context indicating that that’s what we wish to do.

So in the previous intent, set the following as the output context: awaiting_email_address

Or maybe you can use expecting_email_address.

Keeping the context name as short as possible while also keeping it descriptive is also a good idea. Once again, I have improved this to await_email_address

Follow up intent autogenerated context names

One of the big problems I have with using follow up intentsBoth Dialogflow ES and Dialogflow CX have the concept of int... More is the terrible naming convention used for context names. And you cannot change the context names without breaking the hierarchy either.

As a result, merely using follow up intents leads to poor context names which are not easy to read.

Comparisons

Let us compare the follow up intent agent naming conventions to the session-vars agent naming conventions. This will make it very clear how useful these naming conventions can be.

Dialogflow Simulator

In the simulatorYou can use the Simulator in both Dialogflow ES and Dialogfl... More, it is much easier to read the name of the intent which was mapped, as well as understand the state of the bot based on the currently active context.

History

Similarly, if you inspect the Raw Interaction Log inside the simulator, it is much easier to understand what happened with the suggested naming conventions.

Training

We can see the same benefits in the Training feature also

Conversation Analytics

Finally, good naming conventions can be immensely helpful when doing conversation analytics.

For example, this is the output of my History JSON to CSV converter tool (which you can use to measure the accuracy of your Dialogflow bot)for the follow up agent.

And this is the output of the same tool for the session-vars agent.

As you can see, the denser the information, the more useful these naming conventions.

---

Note: This is my old website and is in maintenance mode. I am publishing new articles only on my new website. 

If you are not sure where to start on my new website, I recommend the following article:

Is Dialogflow still relevant in the era of Large Language Models?