Amazon Echo and Google Home: An insider’s perspective

Just a heads up, if you buy something through our links, we may get a small share of the sale. It’s one of the ways we keep the lights on here. Click here for more.

We’re itcher and we’re an entertainment recommendations app helping users find their next favorite movie in less than 50 seconds. When Google launched the Google Assistant, they approached us to work on an action for the Google Assistant on Google Home, meaning they wanted us to be their preset recommender for movies and books. This meant users could simply ask itcher to recommend them a book or movie. We’re a small start-up, so we were thrilled to be selected.

Since voice is bound to model the future of tech and human communications, we couldn’t miss the train. So following the Google Home, itcher also joined as an action with the other major player on the market, the Amazon Echo. In the generation of voice Enabled devices, we’re allowing our users to discover their next favorite title simply by asking itcher for a recommendation on both the Google Assistant on Google Home and – more recently – the Amazon Echo.

In this article, we’ll be looking at how both devices handle user input, along with conversational flow and account linking.

Our voice journey has been a fascinating one, and we would like to share our experience with you so you can get an inside look at how the new devices in the market are operating internally.

We’re going to cover the differences we found working with the Google Assistant and Amazon Alexa, so you can see the experiences we had with each and learn about what’s behind the curtain of the latest developments in Virtual Assistants.

Built-in Ontologies

‘Built-in ontologies’ refer to a set of entities in a specific domain. Both platforms offer semantics support to help classifying user inputs correctly.

• Amazon Alexa: support for all common types itcher needs
  • Book authors,
  • Movie directors,
  • Actors,
  • Book titles,
  • Movie titles.

• Google Assistant (using API.AI): no ontology defined for the above types, only for more generic ones.

Our Different Custom Types

A custom type in this context is the definition of a (complex) entity by means of more basic types. Both platforms offer support to define custom types. We used them in both the action and the skill to automatically classify some common itcher types, such as main categories (books, movies, etc.) and rating values.

• For the English U.K. language on Alexa, we also used them to define surrogates for the Amazon built-in ontologies available for the ‘English U.S.’ language only (actors, authors, book titles etc.).
• API.AI supports the definition of composite custom types, created using other custom types or built-in types (save for the ‘catch-all’ @sys-any built-in type) in the definition.
• Terms used to define a custom type in Alexa are automatically expanded (that is, Alexa natural language processing algorithm tries to identify terms in the user input that would belong to the defined custom type, even if they don’t exactly match one of the terms used in the definition). Automatic expansion is available for API.AI custom types, but can also be turned off to define strict enumerations, if needed.

Conversational Flow

Both platforms support the concept of intent, where user inputs get classified as specific requests to the skill/action, with associated slots/parameters.

• Only the Google Assistant platform offers access to the recognized input in its raw form, as part of the intent. While in the optimal case (user input correctly recognized and slots/parameters filled in as expected) this makes no difference, it is potentially helpful to implement fallback logic on the endpoint processing the intent.
• While Machine Learning (ML) can obviously be influenced on both platforms by carefully defining sample patterns/utterances for the intents, only the Google Assistant platform (via API.AI) offers some tools for tuning the process once the action is live.
• At least for the time being, the Google Assistant platform offers more structured support for complex conversations, thanks to intent priority settings and intent input/output context sets. Specifically, being able to restrict recognition of specific intents to sets of predetermined input contexts makes it easier to use intents to define a state-based conversation. E.g., an intent is defined to ‘request one more recommendation’ when the users says ‘One more’

Account Linking

In order to use itcher on a voice enabled device, users much link the device to their itcher account. Services are equivalent in this respect, as they both support OAuth2 account linking. Users link their own itcher account to the Assistant/Alexa (possibly registering first, if they don’t have one), and from that moment onwards they can enjoy a seamless cross-platform experience, having their ratings and recommendations available across all supported platforms (Android/iOS/web/Assistant/Alexa).The

Future is Voice

In summary, our development experience so far has shown that both platforms are very promising. While Amazon Alexa stood out for its better domain-specific input recognition (although so far only available for English – US skills), the Google Assistant (combined with API.AI) provided a more conversation-oriented platform, which made it easier for us to handle the relatively complex, state-based user flows required for our itcher action.

We always enjoy learning from new platforms. By working with the two front runners in the Virtual Assistant industry, we were given the opportunity to develop our product so it can fit seamlessly into the future.

This post was written by Daniel Rovira. Daniel Rovira is the co-founder of itcher, the free entertainment app that offers personalized movie, book, music and game recommendations. Available on both the App Store and Google Play.

Guest Author