Sprawdzone metody

Na tej stronie znajdziesz sprawdzone metody tworzenia skutecznych i angażujących rozwiązań RCS dla firm, obejmujące zarówno implementację techniczną jak i projektowanie rozmów.

Wskazówki techniczne

Sprawdzanie możliwości urządzenia

Zanim rozpoczniesz rozmowę z użytkownikiem, sprawdź, czy jego urządzenie może odbierać wiadomości RCS. Aby określić możliwości użytkownika, wyślij sprawdzenie możliwości, i odpowiednio dostosuj interakcje agenta. Wchodź w interakcje z użytkownikami tylko w sposób obsługiwany przez ich urządzenia. Jeśli urządzenie użytkownika nie obsługuje RCS, skonfiguruj alternatywną metodę komunikacji w innym kanale, np. SMS.

Przestrzeganie maksymalnego rozmiaru wiadomości

Istnieją limity maksymalnego rozmiaru wiadomości RCS dla firm i pliku multimedialnego, który może ona zawierać. Więcej informacji znajdziesz w artykule Maksymalny rozmiar wiadomości.

Zapobieganie wysyłaniu zduplikowanych wiadomości

Aby uniknąć wysyłania zduplikowanych wiadomości do użytkowników, Twój system musi najpierw potwierdzić, że wiadomość nie została dostarczona, zanim spróbuje wysłać ją jako SMS.

Aby zwiększyć niezawodność systemu i zapobiec wysyłaniu zduplikowanych wiadomości, postępuj zgodnie z tymi sprawdzonymi metodami:

• Ustaw czas życia puli połączeń tak, aby odpowiadał czasowi życia DNS (TTL): używaj puli połączeń i obiektów klienta, aby ponownie wykorzystywać istniejące połączenia i obiekty klienta. Aby uniknąć używania nieaktualnych adresów IP po aktualizacjach DNS, ustaw maksymalny czas, przez jaki połączenie lub obiekt pozostaje w puli, tak aby odpowiadał czasowi życia DNS interfejsu API.
• Nie zakładaj, że przekroczenie limitu czasu połączenia oznacza niepowodzenie: nie zakładaj, że przekroczenie limitu czasu połączenia oznacza, że wiadomość RCS dla firm nie została dostarczona. Wiadomość może być nadal przetwarzana po stronie serwera.
• Sprawdzaj potwierdzenia dostarczenia: przed wysłaniem wiadomości alternatywnej zawsze sprawdzaj potwierdzenia dostarczenia.
• Dopasuj TTL do limitu czasu połączenia: jeśli to możliwe, ustaw TTL wiadomości tak, aby odpowiadał limitowi czasu połączenia.
• Cofnij wiadomości przed wysłaniem wiadomości alternatywnej: przed wysłaniem wiadomości alternatywnej w postaci SMS zawsze spróbuj cofnąć oryginalną wiadomość. Jeśli cofnięcie się nie powiedzie, obsłuż ten błąd, ponieważ może to oznaczać, że wiadomość została już dostarczona do użytkownika.
• Ponów wysyłanie wiadomości: jeśli wysłanie wiadomości nie powiedzie się z powodu błędu, który można naprawić, lub przekroczenia limitu czasu połączenia, ponów operację wysyłania. Aby zapobiec duplikatom, użyj początkowego parametru messageID i zastosuj wzrastający czas do ponowienia , aby rozłożyć próby w czasie.

Sprawdzanie, czy nie ma zduplikowanych wiadomości przychodzących

Gdy sprawdzasz wiadomości przychodzące od użytkowników i na nie odpowiadasz, sprawdź parametr messageId i upewnij się, że wiadomość nie została już odebrana i że nie odpowiedziano na nią.

W systemach rozproszonych wiadomości można wysyłać na 2 sposoby:

• Co najwyżej raz: system wysyła wiadomość raz, ale jeśli wystąpią błędy sieciowe lub komunikacyjne, wiadomość może nie zostać odebrana.
• Co najmniej raz: system może wysłać wiadomość kilka razy, ale wiadomość może zostać odebrana nawet wtedy, gdy wystąpią błędy sieciowe lub komunikacyjne.

Google Cloud Pub/Sub używa systemu co najmniej raz. Może to prowadzić do duplikowania wiadomości przychodzących, ale łatwo można je usunąć, śledząc ciągi znaków messageId. Jeśli wiadomość została już odebrana, możesz zignorować wszystkie dodatkowe wiadomości z tym samym parametrem messageId.

Używanie unikalnych identyfikatorów wszystkich wiadomości wychodzących

Gdy agent wysyła wiadomość do użytkownika, parametr messageId dołączony do wywołania interfejsu API musi być unikalny dla każdej wiadomości.

Ważne: ponieważ każdy identyfikator wiadomości jest unikalny, nie używaj ponownie identyfikatorów wiadomości w przypadku różnych wiadomości. Jeśli spróbujesz wysłać nową wiadomość z identyfikatorem, który został już użyty, platforma RCS dla firm zwróci błąd 409 ALREADY_EXISTS. Więcej informacji znajdziesz w dokumentacji interfejsu API.

Więcej informacji o odbieraniu wiadomości znajdziesz w artykule Obsługa zdarzeń przychodzących.

Nie używaj nieaktualnych adresów IP

Podczas łączenia się z interfejsem RBM API Twój system musi zawsze używać prawidłowego, aktualnego adresu IP. Różne platformy programistyczne używają domyślnych limitów czasu pamięci podręcznej DNS, które mogą być znacznie dłuższe niż ustawienie TTL DNS Google. Może to spowodować, że Twój system będzie próbował połączyć się z wygasłymi adresami IP, co doprowadzi do przekroczenia limitu czasu. TTL pamięci podręcznej DNS domeny RBM wynosi 300 sekund.

Aby mieć pewność, że logika połączenia uwzględnia nasz 300-sekundowy TTL, wykonaj te czynności.

1. Dopasuj limit czasu puli połączeń do TTL: jeśli używasz puli połączeń lub obiektów klienta, ustaw jej maksymalny czas życia na 300 sekund (lub mniej). Dzięki temu Twój system będzie pobierać nowy adres IP, gdy obiekt zostanie odświeżony.
2. Zadbaj o odświeżanie DNS: upewnij się, że platforma lub biblioteka klienta HTTP jest skonfigurowana tak, aby odświeżać pamięć podręczną DNS co 300 sekund lub rzadziej.
3. Sprawdź bieżący TTL: zalecamy programowe sprawdzanie TTL domeny interfejsu RBM API, aby mieć pewność, że używasz prawidłowej wartości maksymalnej. Musisz sprawdzić domenę odpowiadającą regionowi wdrożenia:

dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort

Implementowanie ponownych prób ze wzrastającym czasem do ponowienia

Podczas wywoływania dowolnego interfejsu API może wystąpić błąd z powodu problemów z infrastrukturą, przeciążenia usługi, limitów QPS i innych błędów. Aby prawidłowo obsługiwać nieudane wywołania interfejsu API, zaimplementuj ponowne próby ze wzrastającym czasem do ponowienia.

Dzięki ponownym próbom ze wzrastającym czasem do ponowienia Twoja infrastruktura automatycznie wykonuje te czynności:

1. Identyfikuje nieudane wywołanie interfejsu API.
2. Ustawia początkowy czas oczekiwania i maksymalną liczbę ponownych prób.
3. Wstrzymuje działanie na czas oczekiwania.
4. Ponawia wywołanie interfejsu API.

5. Ocenia odpowiedź wywołania interfejsu API:

   • Jeśli operacja się powiedzie, przechodzi do następnego kroku w przepływie pracy.
   • Jeśli operacja się nie powiedzie, zwiększa czas oczekiwania i wraca do kroku 3.
   • Jeśli operacja się nie powiedzie po przekroczeniu maksymalnej liczby ponownych prób, przechodzi w stan niepowodzenia.

Idealne czasy oczekiwania i idealna maksymalna liczba ponownych prób różnią się w zależności od przypadku użycia. Określ te liczby na podstawie wymagań dotyczących infrastruktury i opóźnienia przepływu pracy.

Optymalizowanie wydajności interfejsu API za pomocą regionalnych punktów końcowych

Aby zoptymalizować wydajność interfejsu API i zmniejszyć opóźnienie, używaj punktów końcowych znajdujących się najbliżej regionu użytkownika.

Ważne: regionalne punkty końcowe są wymagane w przypadku metody users.batchGet. Gdy używasz metody users.batchGet, upewnij się, że wszystkie numery telefonów w jednym żądaniu należą do tego samego regionu geograficznego. Żądania zawierające numery telefonów z wielu regionów spowodują wyświetlenie błędu 400 Bad Request.

W tabeli poniżej znajdziesz zalecenia dotyczące regionalnych punktów końcowych RCS dla firm, których należy używać w zależności od numeru telefonu użytkownika.

Prefiks numeru telefonu	Zalecany punkt końcowy	Region geograficzny
+1	us-rcsbusinessmessaging.googleapis.com	Ameryka Północna i Południowa
+2	europe-rcsbusinessmessaging.googleapis.com	Europa
+3	europe-rcsbusinessmessaging.googleapis.com	Europa
+4	europe-rcsbusinessmessaging.googleapis.com	Europa
+5	us-rcsbusinessmessaging.googleapis.com	Ameryka Północna i Południowa
+6	asia-rcsbusinessmessaging.googleapis.com	Azja
+7	europe-rcsbusinessmessaging.googleapis.com	Europa
+8	asia-rcsbusinessmessaging.googleapis.com	Azja
+9	asia-rcsbusinessmessaging.googleapis.com	Azja
Domyślny	us-rcsbusinessmessaging.googleapis.com	Ameryka Północna i Południowa

Po zidentyfikowaniu docelowego punktu końcowego spróbuj umieścić serwery jak najbliżej niego. Listę dostępnych lokalizacji znajdziesz na stronie https://www.google.com/about/datacenters/locations/.

Więcej informacji o identyfikowaniu regionu agenta znajdziesz w dokumentacji Tworzenie agenta.

Interfejs rozmowy i wrażenia użytkownika

Interfejs rozmowy, a nie interfejs aplikacji

Agenci RCS dla firm doskonale nadają się do wykonywania wydajnych i konkretnych zadań dla użytkowników w interfejsie rozmowy. Najlepiej zaprojektowani agenci utrzymują interakcje w skupieniu, są łatwi do zrozumienia i mają strukturę naturalnej rozmowy.

Agenci nie mogą polegać na wizualnym interfejsie aplikacji ani strony internetowej i nie powinni próbować go naśladować. Zamiast tego muszą polegać na starannie opracowanych rozmowach, które zaspokajają potrzeby użytkowników, prowadząc ich za pomocą wskazówek głosowych, sugestii i dobrej obsługi błędów.

Agenci nie powinni też naśladować drzew telefonicznych ani interfejsów, które wymagają od użytkowników odpowiedzi w postaci liczby reprezentującej daną czynność. Użytkownicy powinni móc komunikować się z agentami w sposób naturalny, tak jak w rozmowie z inną osobą.

Rozpoczynanie rozmowy

Początek rozmowy określa oczekiwania użytkownika co do możliwości agenta. Rozpocznij rozmowę w mocny sposób: pokaż osobowość agenta, umieść na początku informacje, które interesują użytkowników, i powiedz, co potrafi Twój agent. Daj użytkownikom jasne opcje interakcji z agentem i kontynuowania rozmowy.

• Pokaż osobowość agenta: ustaw ton, witając użytkownika i przedstawiając swoją markę. Jeśli tworzysz personę agenta, np. wirtualnego asystenta lub cyfrowego konsjerża, wyraźnie zaznacz, że jest to chatbot, a nie prawdziwa osoba. Możesz ustawić nazwę agenta tak, aby pasowała do persony. Awatar to świetny sposób na wzmocnienie wizerunku. Może to być Twoje logo, ale dobrze sprawdzi się też graficzna postać w stylu kreskówki.

  Uwaga: nie używaj zdjęć prawdziwych osób do reprezentowania czatbotów, ponieważ może to wprowadzać w błąd.

• Powiedz, co potrafi Twój agent: dobry komunikat powitalny jasno określa, co oferuje rozmowa. Wyjaśnia możliwości agenta na wysokim poziomie. Zawiera też sugerowane odpowiedzi i działania które prowadzą użytkowników określonymi ścieżkami. Użyj tych sugestii, aby pomóc użytkownikom w poruszaniu się po rozmowie i zrozumieniu zadań, w których agent może pomóc.

Pisanie jasnych i spójnych wiadomości

Wysyłaj wiadomości, które są łatwe do zrozumienia i na które użytkownicy mogą łatwo odpowiedzieć. Twórz tekst wiadomości, który zachęca użytkowników do odpowiedzi. Aby budować zaufanie użytkowników, zachowuj spójny styl, format i tempo.

Podczas tworzenia tekstu wiadomości pamiętaj o tych dodatkowych sprawdzonych metodach:

• Nie twórz ślepych zaułków. Każda wiadomość powinna prowadzić do znaczącego następnego kroku.

  • Jeśli ścieżka użytkownika obejmuje zadanie z wieloma krokami, użyj znaczników dyskursu, aby poprowadzić użytkownika przez ten proces.

  Na przykład: Teraz…, A…, Rozumiem! Proszę…

  • Pisz zwięźle, ponieważ sugerowane odpowiedzi i działania mogą mieć maksymalnie 25 znaków.
  • Jeśli rozmowa obejmuje przekazanie, szybkie potwierdzenie może ułatwić przejście.

  Na przykład: „Dobrze. Od tego momentu zajmie się tym Twój menedżer konta”.

  Na przykład: „Świetnie! Chyba wiem, czego szukasz” i podaj link do swojej witryny.

• Potwierdź wiadomość użytkownika słowem lub frazą.

  Na przykład: „Świetny wybór!”, „OK”, „Dobrze” lub „Rozumiem”.

• Zwracaj się do użytkownika bezpośrednio, używając jego imienia i nazwiska (jeśli je znasz) lub zaimka „Ty”. Unikaj odwoływania się do użytkownika jako „ja” lub „mnie”, ponieważ może to powodować zamieszanie.

• W przypadku tytułów i etykiet używaj wielkości liter jak w zdaniu, a nie jak w tytule.

  Na przykład: „Wyciąg z konta”, a nie „Wyciąg z konta”.

• Używaj skrótów, co jest odpowiednie nawet w przypadku agentów o poważnym lub podniosłym tonie.

  Na przykład „jest” jest bardziej konwersacyjne niż „jest”.

• Oszczędnie używaj wykrzykników.

• Używaj przecinka seryjnego, czyli „A, B i C”, a nie „A, B i C”.

• Zapisuj liczby cyframi.

  Na przykład: „1, 2, 3”, a nie „jeden, dwa, trzy”.

• Gdy używasz emoji, upewnij się, że żartobliwy ton pasuje do przypadku użycia.

  Na przykład użytkownicy, którzy rezerwują lawetę lub sprawdzają wyniki badań, mogą nie być w nastroju.

Zachowywanie kolejności wiadomości

Jeśli wysyłasz kilka wiadomości w sekwencji, ważne jest, aby użytkownicy otrzymywali je w odpowiedniej kolejności. Przetwarzanie wiadomości z multimediami trwa dłużej niż wiadomości zawierających tylko tekst. Aby mieć pewność, że użytkownicy otrzymują wiadomości w odpowiedniej kolejności, poczekaj, aż otrzymasz odpowiedź 200 OK na wiadomość, zanim wyślesz następną w sekwencji.

Tworzenie angażujących rozmów za pomocą sugerowanych odpowiedzi i działań

Sugerowane odpowiedzi i działania to skuteczne narzędzia, które pomagają prowadzić rozmowy z użytkownikami i je ulepszać. Mogą one pojawiać się po wiadomości lub karcie rozszerzonej i oferować opcje kontynuowania lub zmiany tematu rozmowy.

• Sugerowane odpowiedzi: pomagają użytkownikom szybko odpowiadać agentowi, udostępniając predefiniowane opcje. Jeśli to możliwe, używaj sugerowanych odpowiedzi, zwłaszcza gdy oczekiwane są konkretne odpowiedzi.

  

• Sugerowane działania: umożliwiają agentowi integrację z funkcjami urządzenia, co usprawnia zadania takie jak dzwonienie do pomocy czy wyszukiwanie lokalizacji.

Aby tworzyć bardziej angażujące i wydajne rozmowy, pamiętaj o tych najważniejszych kwestiach:

• Trafność: upewnij się, że sugestie są zgodne z bieżącą rozmową.
• Zwięzłość: ogranicz liczbę sugestii, aby nie przytłoczyć użytkowników.
• Jasność: używaj jasnego i zwięzłego języka w tekście sugestii.

Uwaga: w karcie rozszerzonej sugerowane odpowiedzi i działania powinny być bezpośrednio powiązane z treścią tej karty.

Pomaganie użytkownikowi

Twój agent powinien odpowiadać na wiadomości HELP od użytkowników i informować ich o swoich możliwościach. Lista sugerowanych odpowiedzi dostosowanych do możliwości agenta może zmienić słabe wrażenia użytkownika w przydatne.

Upewnij się, że logo i baner powitalny wyświetlają się prawidłowo

• Pozostaw odpowiednio dużo miejsca wokół logo, aby umożliwić przycięcie i zachować spójność wizualną.
• Unikaj rozciągania lub zniekształcania logo lub banera powitalnego, ponieważ może to negatywnie wpłynąć na postrzeganie marki.
• Aby uzyskać optymalną widoczność i estetykę, przetestuj logo i baner powitalny w trybie jasnym i ciemnym.

Więcej informacji, które pomogą Ci zaprojektować logo lub rozwiązać problemy, znajdziesz w wytycznych dotyczących projektowania logo.

Logo

• Projektuj z myślą o renderowaniu w postaci zaokrąglonego kwadratu. Aby zachować zgodność ze standardami Google i branżowymi, logo RCS dla firm są wyświetlane jako „zaokrąglone kwadraty” na liście rozmów, ekranie rozmowy i w szczegółach rozmowy.
• Wyśrodkuj logo w obrębie obrazu, aby elementy marki pozostały wyraźne po przycięciu.
• Obok nazwy zweryfikowanych agentów automatycznie pojawi się ikona potwierdzenia. Ten znak jest chroniony przed podszywaniem się i nie można go dodać ręcznie.
• W przypadku logo z przezroczystym tłem upewnij się, że kontrast jest wystarczający zarówno na jasnym, jak i ciemnym tle, aby uwzględnić tryb ciemny. Jeśli nie masz pewności, użyj jednolitego białego tła.

Baner powitalny

• Aby zapobiec niechcianemu przycinaniu, użyj proporcji 45:14.

Podczas projektowania banera powitalnego weź pod uwagę nakładanie się logo, aby kluczowe elementy nie były zasłonięte.

Respektowanie decyzji użytkowników, którzy nie chcą otrzymywać wiadomości

Utrzymanie zaufania użytkowników oznacza respektowanie ich preferencji dotyczących komunikacji. Gdy użytkownik poinformuje, że nie chce już otrzymywać wiadomości, Twój agent musi uszanować jego wybór. Obejmuje to zrozumienie i odpowiednie reagowanie na różne formy rezygnacji, np. „STOP”, we wszystkich odpowiednich językach.

Zapoznaj się z obowiązującymi w Twoim kraju przepisami i sprawdzonymi metodami dotyczącymi odpowiadania na wiadomości „STOP” i inne wymagane polecenia.

Na przykład zapoznaj się ze CTIA CTIA.

Obsługa zdarzeń Unsubscribe i Subscribe

Ważne: interfejs użytkownika do rezygnacji z subskrypcji i subskrypcji jest wdrażany w otwartej wersji beta Wiadomości Google, ale zdarzenia webhooka UNSUBSCRIBE i SUBSCRIBE nie są jeszcze dostępne. Udostępniamy teraz dokumentację, aby partnerzy mogli zrozumieć, jak będzie działać ta funkcja, i przygotować się na jej pełne udostępnienie w przyszłej aktualizacji.

Wiadomości Google mają wbudowane funkcje Rezygnacja z subskrypcji i Subskrybuj , które umożliwiają użytkownikom kontrolowanie rozmów. Gdy użytkownik zrezygnuje z subskrypcji, Twój agent otrzyma zdarzenie webhooka UNSUBSCRIBE. Zdarzenie SUBSCRIBE oznacza, że użytkownik chce ponownie nawiązać kontakt z Twoim agentem.

Szczegółowe informacje o obsłudze rezygnacji z subskrypcji i ponownej subskrypcji zdarzeń, w tym szczegóły ładunku, reguły biznesowe i przykłady, znajdziesz w dokumentacji dotyczącej zdarzeń generowanych przez użytkowników.

Obsługa rezygnacji

Platforma RCS dla firm nie udostępnia bezpośredniego sposobu zarządzania listami rezygnacji użytkowników. Odpowiadasz za prowadzenie własnej bazy danych użytkowników, którzy zrezygnowali z otrzymywania wiadomości przez rezygnację z subskrypcji lub inne formy rezygnacji.

Wznawianie rozmów

Jeśli użytkownik usunie rozmowę z Twoim agentem, musi ponownie nawiązać kontakt w innym kanale, np. przez akceptację w witrynie, krótki kod SMS lub inny mechanizm udzielania zgody na wykorzystanie danych. Ta nowa interakcja sygnalizuje jego ponowne zainteresowanie otrzymywaniem wiadomości.