How Fitwell uses Chatbase to create a unified customer view across platforms

By Ahmet Taha Sakar

(Ed. Note: Ahmet is a London-based entrepreneur and CTO of Fitwell, an AI wellness start-up that focuses on providing holistic coaching in healthy nutrition and fitness, with more than 1.3 million members globally.)

Fitwell's vision is to become an omnipresent life companion utilizing voice, chat, and graphics interfaces. As part of that vision, we've built a life-coach bot called Hailee that's integrated with four common bot platforms. With Chatbase, we've solved the difficult problem of analyzing and optimizing our bot across all those platforms (the Google Assistant, Amazon Alexa, Facebook Messenger, and Slack) in a unified way.

In this post, I’ll share some insights about our development experience and the effectiveness of taking a “universal id” approach when integrating with the Chatbase API.

Supporting multiple login methods is complicated

To make Hailee’s authentication and user management architecture comply with all four platforms, we had to add support for multiple login methods for a single user. Our entity diagram looks something like this:

Most bot platforms are flexible with respect to how authentication is done. However, our user experience tests confirm that users prefer to use the same platform for both social login and messaging: Hence, Facebook Login for Facebook Messenger, Slack Login for Slack, Google Login for the Google Assistant, and Amazon Login for Amazon Alexa. To support a quick one-click login to Hailee across all four platforms, we had to integrate with each one in a slightly different way. (In contrast, if we were to prompt the user to login using a custom authentication system or social login that differs from the messaging platform in use, many, if not most, users would have to go through the registration and onboarding process.)

Here’s a quick summary of the differences in how we integrate with each platform:

Facebook Messenger

Hailee is attached to our Facebook page, and user messages are relayed to our servers via our Facebook App. The same Facebook App is used within our mobile app for Facebook Login. When a user starts a chat with Hailee, we receive a unique identifier called Facebook Page User Id; however, during mobile-app login, we obtain a unique identifier called Facebook App User Id. These ids don’t match, but fortunately Facebook allows sharing user id between pages and apps as long as they belong to the same business. Thus when a user starts chatting with Hailee, we can check if the user also has a mobile app account.


Slack bots are straightforward to create: You create an app and attach a bot to it. What makes Slack unique is  that team admins decide which bots are added to a team; when a bot is added, it gets immediate access to all team users, and each team and each user has a unique identifier. For Hailee to link a Slack user to a mobile app user, we needed to integrate the Slack login with the Fitwell mobile app. Because the Slack and Fitwell ids now match, Hailee can identify the user.

The Google Assistant

Unlike Facebook Messenger and Slack, which are text-based chat platforms where the user is already in an app or a website, for users of the Google Assistant the experience is voice- or text-controlled with support from the Google Home mobile app. With Hailee, we use Google Login to accomplish a quick one-click login: Once the user is authenticated, Hailee has access to the Google id of the user. This id is also what our mobile app receives with Google Login, so thanks to these matching ids, Hailee can identify the user.

Amazon Alexa

Alexa is also controlled by text or voice and requires Alexa mobile app for authentication. Just like the Google Assistant approach, we can authenticate the user and receive the amazon id using Amazon Login.

The end result looks like this:

Integrating with Chatbase for a unified customer view

Besides keeping track of social login ids, we also assign a universal id to each user. With that done, integrating the Hailee bot with Chatbase was easy.

We found that it’s a best practice to set the “universal id” as the user_id field when calling the Chatbase Generic Message API. This approach makes it possible to analyze a unified user base in the service. For example, the Cohorts report displays user retention by percentage across weekly time periods. If a unique user_id is used for each messaging platform, the cohort numbers may not reflect reality because there is a good chance that some users will connect with the bot from multiple messaging platforms -- and hence Chatbase will treat them as separate users. In contrast, with a universal id approach, reports reflect a unified view user activity levels and churn rates.

Knowing user identity unlocks personalization

One important takeaway from this experience is that knowing user identity has numerous benefits for the user, including the ability to personalize the conversation and get contextual information. The content range of the conversation is exponentially wider than it would be for an anonymous user. As an example:

Keep in mind that these platforms are very new, so APIs and methodologies are still in flux. In the meantime, I hope this post shaves some time from the analysis and design phases of your development process. Best of luck :)

About Chatbase 

Chatbase gives builders of conversational interfaces (or bots) sophisticated tools for creating better, and stickier, consumer experiences than ever before--leading to better conversion rates and retention. Chatbase is a cloud service that easily integrates with any bot platform and type, voice or text, and is free to use.

Among other features, Chatbase uniquely relies on Google’s machine learning capabilities to automate the identification of  bot problems and opportunities that would otherwise take a lot of time, leading to faster optimizations and better bot accuracy.

Chatbase is brought to you by Area 120, an incubator for early-stage products operated by Google.