Updates: Check the release notes for new features and product updates.

Best practices

When you interact with users through Business messages agents, keep the following best practices in mind.

Don't provide or request sensitive information

Avoiding sensitive content during chats keeps your and your customers' information safe. Sensitive information include, but isn't limited to

  • Credit card numbers
  • Social Security, passport, or other government identification numbers
  • Login credentials, like passwords

Respond to users quickly

Slow or unreasonable response times to user messages create a bad user experience for your customers. Make sure that you design your response infrastructure to consistently provide timely replies to user messages.

Even worse than a slow response is no response at all. Make sure that users always receive responses to their messages, regardless of your message load. For example, if live staff aren't available, send an automated message acknowledging the user, and include an estimate of when the user can expect a full response.

Google measures time to respond (TTR) between messages. If a brand's agent is slow to respond to consumers, Google will remove the brand's messaging buttons.

When automation can't fulfill requests, hand off to humans

Users get frustrated when automation fails to fulfill their requests. To prevent bad user experiences, when automation fails to properly respond or fulfill a request twice in a row, send a message with a live agent request suggestion.

Live agent request suggestions enable agents to programmatically transition conversations to human representatives and empower users to take action, bettering their experiences.

When a user taps a live agent request suggestion, the agent receives a live agent requested event.

Authenticate users with OAuth

To verify users' identities and provide personalized information to them, authenticate users with backend systems through OAuth. Authentication with OAuth gets agents access to user data quickly and prevents users or agents from including sensitive information (such as usernames or passwords) in the conversation. See Authenticate with OAuth.

Measure CSAT within Business Messages

Business Messages measures Customer Satisfaction Scores (CSAT) with surveys directly within messaging experiences. To prevent users from receiving multiple surveys, use Business Messages' survey functionality. Don't implement your own CSAT measurement techniques.

Stay on topic

Don't send messages that are unwanted or irrelevant to the current conversation. For example,

  • Messages about a product or service unrelated to the original request
  • Repeated messages with no user response
  • Excessively long messages or excessive use of emoticons and URLs

Leverage placeId when it's available

For location-based entry points, messages may contain a placeId in the context payload. You can leverage it to provide contextual information that the user may be asking about, like inventory at a particular location. A placeId uniquely identifies a place in the Google Places database and in the Google Maps Platform.

Even if you only launch with location-based entry points, make sure to implement a strategy for situations where a placeId isn't present. Although not common, there are circumstances where a placeId, among other contextual data, isn't passed to your webhook.

Implement retries with exponential backoff

When calling any API, it's possible for a call to fail because of infrastructure issues, service overload, QPS limits, and myriad other errors. To recover from failed API calls gracefully, implement retries with exponential backoff.

Using retries with exponential backoff, your infrastructure automatically

  1. Identifies a failed API call
  2. Sets the initial wait duration and the maximum number of retries
  3. Pauses for the wait duration
  4. Retries the API call

  5. Assesses the API call response:

    • If a success, proceeds with next step in the workflow
    • If a failure, increases the wait duration and returns to step 3
    • If a failure after the maximum number of retries, enters a fail state

Ideal wait durations and the ideal maximum number of retries vary by use case. Determine these numbers based on the latency requirements of your infrastructure and workflows.

Check for duplicate incoming messages

When you check for and respond to incoming messages from users, check the messageId and verify that you haven't already received and responded to the message previously.

With distributed systems, there are two ways of sending messages: at most once, and at least once. With "at most once" systems, the system sends a message once, but if there are network or communication errors along the way, the message may not be received. With "at least once" systems, the system might send a message multiple times, but the message can be received even when there are network or communication errors.

Business Messages uses an "at least once" system. While this can lead to duplicate incoming messages, it's straightforward to de-duplicate messages by tracking messageId strings. If you've already received a message, it's safe to disregard any additional messages you receive with the same messageId.