Praktik terbaik

Halaman ini memberikan praktik terbaik untuk membuat pengalaman RCS untuk Bisnis yang efektif dan menarik, yang mencakup implementasi teknis dan desain percakapan.

Panduan teknis

Memeriksa kemampuan perangkat

Sebelum memulai percakapan dengan pengguna, pastikan perangkat pengguna dapat menerima pesan RCS. Untuk mengidentifikasi kemampuan pengguna, kirim pemeriksaan kemampuan, dan sesuaikan interaksi agen Anda. Hanya berinteraksi dengan pengguna dengan cara yang didukung oleh perangkat mereka. Jika perangkat pengguna tidak mendukung RCS, siapkan metode komunikasi pengganti dengan saluran lain, seperti SMS.

Mematuhi ukuran pesan maksimum

Ada batasan ukuran maksimum pesan RCS untuk Bisnis dan file media yang dapat dimuatnya. Lihat Ukuran pesan maksimum untuk mengetahui detailnya.

Mencegah pengiriman pesan duplikat

Untuk menghindari pengiriman pesan duplikat kepada pengguna, sistem Anda harus mengonfirmasi terlebih dahulu bahwa pesan tidak terkirim sebelum mencoba penggantian ke SMS.

Ikuti praktik terbaik ini untuk meningkatkan keandalan sistem Anda dan mencegah pesan duplikat:

• Tetapkan masa aktif kumpulan koneksi agar sesuai dengan waktu aktif (TTL) DNS: Gunakan kumpulan koneksi dan objek klien untuk menggunakan kembali koneksi dan objek klien yang ada. Untuk menghindari penggunaan alamat IP yang tidak berlaku setelah pembaruan DNS, tetapkan waktu maksimum koneksi atau objek tetap berada dalam kumpulan agar sesuai dengan waktu aktif DNS API.
• Jangan menganggap waktu tunggu koneksi berarti kegagalan: Jangan menganggap waktu tunggu koneksi berarti pesan RCS untuk Bisnis tidak terkirim. Pesan mungkin masih diproses di sisi server.
• Verifikasi tanda terima pengiriman: Selalu periksa tanda terima pengiriman sebelum memicu pesan pengganti.
• Cocokkan TTL dengan waktu tunggu koneksi: Jika memungkinkan, tetapkan TTL pesan agar sesuai dengan waktu tunggu koneksi.
• Batalkan pesan sebelum penggantian: Selalu coba batalkan pesan asli sebelum mengirim SMS pengganti. Jika pembatalan gagal, tangani kegagalan tersebut, karena hal ini mungkin menunjukkan bahwa pesan telah dikirim ke pengguna.
• Coba kirim pesan lagi: Jika pesan gagal karena error yang dapat dicoba lagi atau waktu tunggu koneksi, coba lagi operasi pengiriman. Gunakan messageID awal untuk mencegah duplikat, dan terapkan backoff eksponensial untuk memberi jarak pada upaya.

Memeriksa pesan masuk duplikat

Saat Anda memeriksa dan merespons pesan masuk dari pengguna, periksa messageId dan pastikan Anda belum menerima dan merespons pesan tersebut.

Dengan sistem terdistribusi, ada dua cara untuk mengirim pesan:

• Paling banyak sekali: Sistem mengirim pesan sekali, tetapi jika ada error jaringan atau komunikasi di sepanjang proses, pesan mungkin tidak diterima.
• Setidaknya sekali: Sistem mungkin mengirim pesan beberapa kali, tetapi pesan dapat diterima meskipun ada error jaringan atau komunikasi.

Google Cloud Pub/Sub menggunakan sistem setidaknya sekali. Meskipun hal ini dapat menyebabkan pesan masuk duplikat, pesan dapat dengan mudah dihapus duplikasinya dengan melacak string messageId. Jika Anda telah menerima pesan, Anda dapat mengabaikan pesan tambahan yang diterima dengan messageId yang sama.

Menggunakan ID unik untuk semua pesan keluar

Saat agen Anda mengirim pesan kepada pengguna, messageId yang Anda sertakan dalam panggilan API harus unik untuk setiap pesan.

Penting: Karena setiap ID pesan bersifat unik, jangan gunakan kembali ID pesan untuk pesan yang berbeda. Platform RCS untuk Bisnis menampilkan error 409 ALREADY_EXISTS jika Anda mencoba mengirim pesan baru dengan ID yang telah digunakan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi referensi API.

Untuk mengetahui informasi selengkapnya tentang cara menerima pesan, lihat Menangani peristiwa masuk.

Jangan menggunakan alamat IP yang tidak berlaku

Sistem Anda harus selalu menggunakan alamat IP yang benar dan terbaru saat terhubung ke RBM API. Berbagai platform pemrograman menggunakan waktu tunggu cache DNS default yang mungkin jauh lebih lama daripada setelan TTL DNS Google, yang dapat menyebabkan sistem Anda mencoba terhubung ke alamat IP yang sudah tidak berlaku, sehingga menyebabkan waktu tunggu. TTL cache DNS domain RBM adalah 300 detik.

Untuk memastikan logika koneksi Anda mematuhi TTL 300 detik kami, ikuti langkah-langkah berikut.

1. Cocokkan waktu tunggu kumpulan koneksi dengan TTL: Jika Anda menggunakan kumpulan koneksi atau objek klien, tetapkan masa aktif maksimumnya ke 300 detik (atau kurang). Hal ini akan memaksa sistem Anda untuk mengambil alamat IP baru saat objek diperbarui.
2. Pastikan pembaruan DNS: Konfirmasi bahwa platform atau library klien HTTP Anda ditetapkan untuk memperbarui cache DNS setiap 300 detik atau kurang.
3. Periksa TTL saat ini: Sebaiknya periksa TTL domain RBM secara terprogram untuk memastikan Anda menggunakan nilai maksimum yang benar. Anda harus memeriksa domain yang sesuai dengan wilayah deployment Anda:

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

Menerapkan percobaan ulang dengan backoff eksponensial

Saat memanggil API apa pun, panggilan dapat gagal karena masalah infrastruktur, kelebihan beban layanan, batas QPS, dan error lainnya. Untuk pulih dengan baik dari panggilan API yang gagal, terapkan percobaan ulang dengan backoff eksponensial.

Dengan menggunakan percobaan ulang dengan backoff eksponensial, infrastruktur Anda akan otomatis melakukan hal berikut:

1. Mengidentifikasi panggilan API yang gagal.
2. Menetapkan durasi tunggu awal dan jumlah maksimum percobaan ulang.
3. Menjeda selama durasi tunggu.
4. Mencoba ulang panggilan API.

5. Menilai respons panggilan API:

   • Jika berhasil, lanjutkan ke langkah berikutnya dalam alur kerja.
   • Jika gagal, tingkatkan durasi tunggu dan kembali ke langkah 3.
   • Jika gagal setelah jumlah maksimum percobaan ulang, masukkan status gagal.

Durasi tunggu yang ideal dan jumlah maksimum percobaan ulang yang ideal bervariasi menurut kasus penggunaan. Tentukan angka ini berdasarkan persyaratan latensi infrastruktur dan alur kerja Anda.

Mengoptimalkan performa API dengan endpoint regional

Untuk mengoptimalkan performa API agar latensinya lebih baik:

• Gunakan endpoint terdekat dengan wilayah pengguna.

  Tabel berikut memberikan rekomendasi tentang endpoint RBM regional mana yang akan digunakan, bergantung pada nomor telepon pengguna.

  Awalan nomor telepon	Endpoint yang direkomendasikan	Wilayah geografis
  +1	us-rcsbusinessmessaging.googleapis.com	Amerika
  +2	europe-rcsbusinessmessaging.googleapis.com	Eropa
  +3	europe-rcsbusinessmessaging.googleapis.com	Eropa
  +4	europe-rcsbusinessmessaging.googleapis.com	Eropa
  +5	us-rcsbusinessmessaging.googleapis.com	Amerika
  +6	asia-rcsbusinessmessaging.googleapis.com	Asia
  +7	europe-rcsbusinessmessaging.googleapis.com	Eropa
  +8	asia-rcsbusinessmessaging.googleapis.com	Asia
  +9	asia-rcsbusinessmessaging.googleapis.com	Asia
  Default	us-rcsbusinessmessaging.googleapis.com	Amerika

• Pertimbangkan untuk menempatkan server di dekat endpoint yang dipilih.

  Lihat https://www.google.com/about/datacenters/locations/ untuk mengetahui pusat data Google.

Untuk mengetahui informasi selengkapnya tentang cara mengidentifikasi wilayah agen, lihat dokumentasi Membuat agen.

UI percakapan dan pengalaman pengguna

UI percakapan, bukan UI aplikasi

Agen RCS untuk Bisnis sangat cocok untuk menyediakan tugas yang efisien dan spesifik kepada pengguna dalam antarmuka pengguna percakapan. Agen yang didesain dengan baik akan menjaga interaksi tetap fokus, mudah dipahami, dan terstruktur seperti percakapan alami.

Agen tidak dapat mengandalkan UI visual aplikasi atau halaman web dan tidak boleh mencoba menirunya. Sebagai gantinya, agen harus mengandalkan percakapan yang dibuat dengan cermat yang memenuhi kebutuhan pengguna dengan memandu mereka menggunakan petunjuk verbal, saran, dan penanganan error yang baik.

Agen juga tidak boleh meniru pohon telepon, atau antarmuka yang mengandalkan pengguna untuk merespons dengan angka yang mewakili tindakan tertentu. Pengguna harus dapat berkomunikasi dengan agen secara alami, seperti mereka berkomunikasi dengan orang lain dalam percakapan.

Mulai percakapan

Awal percakapan menetapkan ekspektasi pengguna tentang kemampuan agen. Mulai percakapan dengan baik: tunjukkan kepribadian agen Anda, berikan informasi yang penting bagi pengguna Anda, dan bagikan kemampuan agen Anda. Berikan opsi yang jelas kepada pengguna untuk berinteraksi dengan agen Anda dan melanjutkan percakapan.

• Tunjukkan kepribadian agen Anda: Tetapkan gaya bahasa dengan menyapa pengguna dan memperkenalkan merek Anda. Jika Anda membuat persona untuk agen, seperti asisten virtual atau concierge digital, jelaskan bahwa agen tersebut adalah chatbot, bukan orang sungguhan. Anda dapat menetapkan nama agen agar sesuai dengan persona. Avatar adalah cara yang bagus untuk memperkuat citra Anda. Avatar dapat berupa logo Anda, tetapi karakter kartun grafis juga cocok.

  Catatan: Jangan gunakan foto orang sungguhan untuk mewakili chatbot; hal ini dapat menyesatkan.

• Bagikan kemampuan agen Anda: Pesan sapaan yang baik akan menjelaskan dengan jelas apa yang ditawarkan percakapan. Pesan tersebut menjelaskan kemampuan agen pada tingkat tinggi. Pesan tersebut juga menyertakan balasan dan tindakan yang disarankan untuk memandu pengguna ke jalur tertentu. Gunakan saran ini untuk membantu pengguna menavigasi percakapan dan memahami tugas yang dapat dibantu oleh agen.

Menulis pesan yang jelas dan konsisten

Kirim pesan yang mudah dipahami dan direspons oleh pengguna. Buat teks pesan yang meminta pengguna untuk merespons. Pertahankan gaya, format, dan kecepatan yang konsisten untuk membangun kepercayaan dengan pengguna.

Ingatlah praktik terbaik tambahan berikut saat membuat teks pesan:

• Jangan membuat jalan buntu. Setiap pesan harus mengarah ke langkah berikutnya yang bermakna.

  • Jika perjalanan pengguna memiliki tugas dengan beberapa langkah, gunakan penanda wacana untuk memandu pengguna melalui proses tersebut.

  Misalnya, Sekarang…, Dan…, Oke! Ini dia…

  • Buat pesan yang ringkas karena balasan yang disarankan dan tindakan memiliki maksimum 25 karakter.
  • Jika percakapan mencakup pengalihan, konfirmasi cepat dapat memperlancar transisi.

  Misalnya, "Oke. Pengelola akun Anda akan mengambil alih dari sini."

  Misalnya, "Sempurna! Saya rasa saya tahu apa yang Anda cari." dan berikan link ke situs Anda.

• Konfirmasi pesan pengguna dengan kata atau frasa pengakuan.

  Misalnya, "Pilihan yang bagus!", "Oke", "Baiklah", atau "Oke".

• Sapa pengguna secara langsung dengan menggunakan nama mereka (jika diketahui) atau kata ganti "Anda". Hindari menyebut pengguna sebagai "saya" atau "aku", karena hal ini dapat menimbulkan kebingungan.

• Untuk judul dan label, gunakan huruf kecil, bukan huruf kapital.

  Misalnya, "Laporan akun", bukan "Laporan Akun".

• Gunakan singkatan, yang sesuai bahkan untuk agen dengan gaya bahasa yang serius atau formal.

  Misalnya, "it's" lebih santai daripada "it is".

• Gunakan tanda seru seperlunya.

• Gunakan koma serial, yaitu, "A, B, dan C", bukan "A, B dan C".

• Tulis angka sebagai digit.

  Misalnya, "1, 2, 3", bukan "satu, dua, tiga".

• Saat menggunakan emoji, pastikan gaya bahasa yang santai sesuai dengan kasus penggunaan.

  Misalnya, pengguna yang memesan mobil derek atau mencari hasil tes kesehatan mereka mungkin tidak sedang dalam suasana hati yang baik.

Menjaga urutan pesan

Jika Anda mengirim beberapa pesan secara berurutan, penting bagi pengguna untuk menerima pesan tersebut secara berurutan. Pesan dengan media memerlukan waktu lebih lama untuk diproses daripada pesan teks saja. Untuk memastikan pengguna menerima pesan dalam urutan yang benar, tunggu hingga Anda menerima respons 200 OK untuk pesan sebelum mengirim pesan berikutnya dalam urutan tersebut.

Membuat percakapan yang menarik dengan balasan dan tindakan yang disarankan

Balasan yang disarankan dan tindakan adalah alat yang efektif untuk memandu dan meningkatkan percakapan pengguna. Balasan dan tindakan yang disarankan dapat mengikuti pesan atau kartu multimedia dan menawarkan opsi untuk melanjutkan atau mengubah topik percakapan.

• Balasan yang disarankan: Membantu pengguna merespons agen Anda dengan cepat dengan memberikan opsi yang telah ditentukan. Gunakan balasan yang disarankan jika memungkinkan, terutama saat respons tertentu diharapkan.

  

• Tindakan yang disarankan: Memungkinkan agen Anda berintegrasi dengan fitur perangkat, sehingga menyederhanakan tugas seperti menghubungi dukungan atau menemukan lokasi.

Ikuti pertimbangan utama ini untuk membuat percakapan yang lebih menarik dan efisien:

• Relevansi: Pastikan saran selaras dengan percakapan saat ini.
• Ringkas: Batasi jumlah saran untuk menghindari pengguna merasa kewalahan.
• Kejelasan: Gunakan bahasa yang jelas dan ringkas untuk teks saran.

Catatan: Dalam kartu multimedia, balasan dan tindakan yang disarankan harus terkait langsung dengan konten dalam kartu tersebut.

Membantu pengguna

Agen Anda harus merespons pesan BANTUAN dari pengguna dan mengedukasi mereka tentang kemampuan agen Anda. Daftar balasan yang disarankan yang disesuaikan dengan kemampuan agen Anda dapat mengubah pengalaman pengguna yang buruk menjadi pengalaman yang bermanfaat.

Memastikan logo dan hero image Anda ditampilkan dengan baik

• Sisakan ruang yang cukup di sekitar logo untuk mengakomodasi pemangkasan dan mempertahankan integritas visual.
• Hindari meregangkan atau mendistorsi logo atau hero image, karena hal ini dapat berdampak negatif pada persepsi merek.
• Uji logo dan hero image dalam mode terang dan gelap untuk visibilitas dan estetika yang optimal.

Untuk mengetahui resource lainnya yang dapat membantu Anda mendesain logo atau memecahkan masalah, lihat Pedoman desain logo.

Logo

• Desain dengan mempertimbangkan rendering persegi panjang yang dibulatkan. Logo RCS untuk Bisnis ditampilkan sebagai "persegi panjang yang dibulatkan" dalam daftar percakapan, layar percakapan, dan detail percakapan agar selaras dengan standar Google dan industri.
• Pusatkan logo dalam gambar untuk memastikan elemen merek tetap jelas setelah pemangkasan.
• Agen yang telah diverifikasi akan otomatis menampilkan tanda centang verifikasi di samping nama agen. Tanda ini dilindungi dari peniruan identitas dan tidak dapat ditambahkan secara manual.
• Untuk logo dengan latar belakang transparan, pastikan ada kontras yang cukup dengan latar belakang terang dan gelap untuk mengakomodasi mode gelap. Jika tidak yakin, gunakan latar belakang putih solid.

Hero image

• Gunakan rasio aspek 45:14 untuk mencegah pemangkasan yang tidak diinginkan.

Pertimbangkan tumpang tindih logo saat mendesain hero image, sehingga elemen utama tidak terhalang.

Mematuhi keinginan pengguna yang tidak ingin menerima pesan

Mempertahankan kepercayaan pengguna berarti menghormati preferensi komunikasi mereka. Saat pengguna menunjukkan bahwa mereka ingin berhenti menerima pesan, agen Anda harus menghormati pilihan mereka. Hal ini mencakup pemahaman dan respons yang tepat terhadap berbagai ekspresi penyisihan, seperti "STOP", dalam semua bahasa yang relevan.

Pelajari undang-undang dan praktik terbaik di negara tempat Anda beroperasi terkait cara merespons perintah "STOP" dan perintah wajib lainnya.

Misalnya, lihat CTIA CTIA.

Menangani peristiwa Berhenti Berlangganan dan Berlangganan

Penting: Meskipun antarmuka pengguna untuk berhenti berlangganan/berlangganan diluncurkan dalam Google Message Beta Terbuka, peristiwa webhook untuk UNSUBSCRIBE dan SUBSCRIBE belum tersedia. Kami membagikan dokumentasi ini sekarang agar partner dapat memahami cara kerja fitur ini dan bersiap untuk rilis lengkapnya dalam update mendatang.

Google Message menyediakan fitur Berhenti Berlangganan dan Berlangganan bawaan, yang memungkinkan pengguna mengontrol percakapan mereka. Saat pengguna memilih untuk berhenti berlangganan, agen Anda akan menerima peristiwa webhook UNSUBSCRIBE. Peristiwa SUBSCRIBE menandakan niat pengguna untuk berinteraksi kembali dengan agen Anda.

Untuk mengetahui informasi mendetail tentang cara menangani Berhenti Berlangganan dan Berlangganan Kembali peristiwa, termasuk detail payload, aturan bisnis, dan contoh, lihat dokumentasi tentang Peristiwa yang dibuat pengguna.

Menangani penyisihan

Platform RCS untuk Bisnis tidak menyediakan cara langsung untuk mengelola daftar penyisihan pengguna. Anda bertanggung jawab untuk mengelola database pengguna Anda sendiri yang telah memilih untuk berhenti menerima pesan melalui pembatalan langganan atau bentuk penyisihan lainnya.

Melanjutkan percakapan

Jika pengguna menghapus percakapan mereka dengan agen Anda, mereka harus memulai kembali kontak melalui saluran lain, seperti ikut serta di situs, kode singkat SMS, atau mekanisme izin lainnya. Interaksi baru ini menandakan minat mereka yang diperbarui untuk menerima pesan.