Uncategorized

Google Assistant Action Development – Best Practices for Developers

Actions on Google is a developer platform that lets you create software to extend the functionality of the Google Assistant, Google’s virtual personal assistant, across more than 1 billion devices, including smart speakers, phones, cars, TVs, headphones, and more.

Users engage Google Assistant in conversation to get things done, like buying groceries or booking a ride. As a developer, you can use Actions on Google to easily create and manage delightful and effective conversational experiences between users and your own 3rd-party fulfillment service.

We have collated some Google Action development best practices for developers. This content is majorly taken from documentation for Google developers.

Content Best Practices for Google Action Development

  • Utterances Format:
    • Keep your utterances clear and short. Don’t force the user to hold a lot of words in their heads.
    • Keep the responses even shorter. One or two-word responses work best.
    • Make sure your utterances are actually asking the user a question.
      • Try to start with words such as who, what, or when. Guide users to the kind of responses they should give.
    • Since users can’t interrupt a question, it’s helpful to introduce a list of options, such as “Which of these options…” Users might try to answer a question before they hear them all, so let them know that more are coming.
      • Include ordinal responses like first one, 3rd, and second option, with your code, that will be understood by the Assistant as valid responses to multiple-choice questions, so your users can respond however feels the most natural to them.
  • Synonyms: If you think there are multiple correct ways to respond to a question, you can set multiple synonyms, within the entities. For example, if a question’s answer is set to United States, USA, US, a user could say any of these synonyms to correctly answer the question.
  • Engagement: To vary the questions and keep things moving, try to mix in different types of questions, using the random function.
  • Cultural Reach: To engage the maximum number of users, try to offer questions that many people can relate to, regardless of their ethnic or class background. Remember that not everyone has been exposed to the same classical and cultural references.
  • Understandability: Answers work best when they require three or fewer words. If the user has to give a lengthy response, the voice-detection error gap widens.
  • Efficiency: It’s best to use contractions wherever possible (“I’m” instead of “I am“) to speed up TTS (Text To Speech) playback.
  • Age Appropriateness: Determine your target audience before you create your questions and answers. We recommend targeting your content for age appropriateness.
  • Gender Diversity: For maximum user engagement, remember that you’re targeting diverse genders. Try to use pronouns, examples, and subject matter that a maximum number of users can relate to.

 

Push Notifications Title

  • Don’t use question marks or exclamation marks in your title.
  • Don’t use the word daily in the title of a daily update.
  • Don’t use the same title for different updates.
  • Don’t use the exact name of the Action.

 

Updatable intents

  • Enable updates or notifications in the Actions on Google console only for the intents that are triggered by updates and notifications. Don’t enable updates or notifications for intents that you are using during the configuration.

 

Limits

The following limits apply to sending push notifications:

  • Up to 10 notifications per user per day.
  • Up to 1 notifications per user per minute.

 

Design tips

Review the following tips to implement good conversation design practices into your Action.
 

Expect variations

Handle this in the “User says” input in Dialogflow. Also, use more than one intent (if required) that can map to the same action, where each intent can be triggered with different sets of “User says” phrases.
 

Provide helpful reprompts and fail gracefully

To do this, initialize a fallbackCount variable in your conv.data object, and it set to 0. Prepare an array of 3 fallback prompts (escalating in clarity), and a final fallback prompt that ends the conversation.

Then, create a fallback intent (ideally one for each actionable intent in the agent). In the intent handler, pull the fallback count from the conv.data object, increment it, and if it is less than 3, pull the prompt from the array of 3. If the count is greater than 4, close the conversation using the final prompt. In all intents that are not fallbacks, reset the fallback count to 0. Ideally, templatize the fallbacks for specific intents to be specific to those.
 

Be prepared to help at any time

Create an intent that listens for help phrases like “what can I do?”, “what can you tell me”, or “help”. In this intent, offer some (rotating/ randomized) response that offers an overview of what the agent can do and directs users to a possible action. Ideally, also use follow-up help intents in Dialogflow to create different help scenarios for different actionable intents.
 

Let users replay information

Wrap all your output methods with a proxy function that adds the output to conv.data.lastPrompt. Create a repeat intent that listens for prompts to repeat from the user like “what?”, “say that again”, or “can you repeat that?”. Create an array of repeat prefixes that can be used to acknowledge that the user asked for something to be repeated. In the repeat intent handler, call ask() with a concatenated string of the repeat prefix and the value of conv.data.lastPrompt. Keep in mind that you’ll have to shift any ssml opening tags if used in the last prompt.
 

Personalize the conversation with user preferences

Your Action can ask users for their preferences and remember them for later use, letting you personalize future conversations with that user.

For example, an Action gives users a weather report for a zip code. The coding should be done in such a way that it asks the user whether they’d like the Action to remember their zip code for later conversations.

After asking the user which zip code they’re in during their first dialog, you can skip that prompt during their next invocation and use the same zip code. You should still provide an escape route (e.g. a suggestion chip allowing them to pick a different zip code) but by reducing a turn of conversation in the common case, you create a much more seamless experience.
 

Customize for returning users

Maintaining some state between conversations ensures a far more natural experience for return users. The first step in crafting this experience is to greet return users differently. For instance, you can taper the greeting or surface useful information based on past conversations. To do this, use the incoming AppRequest. UserlastSeen property to determine whether the user has interacted with your Action before. If the lastSeenproperty is included in the request payload, you can use a different greeting than normal.

You can further enhance the greeting by tailoring the response to the actual value of lastSeen. For instance, users whose last interaction occurred many months before the current interaction might receive a different greeting than those who used the Action the day before.

At Pragmatic Voice, our Google Assistant developers ensure that we use all or most of the above mentioned best practices while developing Google Actions. In case you want to get your Google Action developed in compliance with the industry’s best standards, you can get in touch with us at +1 713 701 5957 or drop in an email at sales@pragmatic-voice.com

Leave a Reply

Your email address will not be published. Required fields are marked *