View a markdown version of this page

Praktik terbaik RCS - AWS SMS Pesan Pengguna Akhir
Desain percakapan dan interaktifStrategi saranKartu kaya dan desain korselPraktik terbaik mediaStrategi TTL dan fallbackPemantauan dan acaraVarians rendering perangkat dan klienOpt-out penanganan

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik RCS

Dengan pesan kaya RCS, Anda dapat membuat pengalaman percakapan dan interaktif yang melampaui SMS tradisional. Topik ini memberikan panduan untuk merancang pesan RCS yang efektif, termasuk strategi saran, tata letak kartu kaya dan korsel, optimasi media, kedaluwarsa pesan, perencanaan fallback, dan pemantauan.

Untuk detail tentang fitur individual, lihatMengkonfigurasi saran RCS,Mengirim kartu kaya RCS,Mengirim komidi putar RCS,Mengkonfigurasi kedaluwarsa pesan RCS,Mengkonfigurasi fallback SMS atau MMS per pesan, danAcara pesan RCS.

Desain percakapan dan interaktif

Pesan RCS mendukung elemen interaktif seperti balasan yang disarankan, tindakan yang disarankan, kartu kaya, dan komidi putar. Untuk menggunakan fitur-fitur ini secara efektif, perlakukan setiap pertukaran pesan sebagai bagian dari percakapan yang sedang berlangsung daripada pemberitahuan satu arah.

Buka dengan konteks dan opsi

Sertakan salam yang jelas, nyatakan apa yang dapat dilakukan pengguna, dan berikan balasan yang disarankan untuk memandu langkah selanjutnya. Ini menetapkan harapan dan mengurangi gesekan.

Jaga agar pesan tetap ringkas

Bertujuan untuk kurang dari 300 karakter per pesan teks. Pecah informasi kompleks menjadi beberapa pesan atau gunakan kartu kaya untuk konten terstruktur.

Hindari jalan buntu

Setiap pesan harus mengarah ke langkah berikutnya. Tawarkan saran tindak lanjut, opsi menu utama, atau jalur ke agen manusia.

Alamat pengguna secara langsung

Gunakan orang kedua. Tulis “Janji temu Anda dikonfirmasi” daripada “Janji temu telah dikonfirmasi.”

Strategi saran

Saran (baik balasan maupun tindakan) muncul sebagai chip interaktif di bawah pesan Anda. Mereka mengurangi pengetikan, meningkatkan keterlibatan, dan memungkinkan Anda merutekan respons melalui PostbackData nilai terstruktur. Untuk daftar lengkap jenis saran, lihatMengkonfigurasi saran RCS.

Tulis label tindakan ringkas

TextBidang ini memiliki batas 25 karakter. Gunakan bahasa berorientasi tindakan yang memberi tahu pengguna dengan tepat apa yang terjadi di tap.

Contoh label saran
Hindari Lebih suka
“Opsi 1" “Pesan untuk hari Senin”
“Klik di sini” “Lihat status pesanan”
“Info lebih lanjut” “Lihat detail harga”

Tawarkan 3 hingga 5 opsi

Tiga saran sangat ideal untuk sebagian besar interaksi. Anda dapat menyertakan hingga 11 saran per pesan (4 per kartu kaya), tetapi lebih dari 5 opsi sekaligus cenderung membanjiri pengguna. Jika Anda membutuhkan lebih banyak pilihan, gunakan korsel atau bagi aliran menjadi beberapa langkah.

Rute di PostbackData

Gunakan PostbackData untuk logika perutean backend alih-alih mengurai teks tampilan. Pendekatan ini mendukung pelokalan (Anda dapat mengubah tampilan pengguna Text tanpa memodifikasi perutean Anda) dan menyediakan konteks terstruktur untuk aplikasi Anda.

Encode tindakan, entitas, dan konteks dalam nilai postback. Contoh:

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

Gunakan awalan yang konsisten (sepertibook_,, confirm_cancel_,nav_) untuk menyederhanakan perutean di backend Anda.

penting

Tangani postback basi dengan anggun. Pengguna dapat memilih saran beberapa jam setelah menerimanya. Periksa apakah entitas yang direferensikan masih ada dan beri tahu pengguna jika tindakan tersebut tidak lagi valid.

Kartu kaya dan desain korsel

Kartu kaya dan komidi putar menyajikan konten terstruktur (gambar, judul, deskripsi, dan saran) dalam format visual. Untuk detail implementasi, lihat Mengirim kartu kaya RCS danMengirim komidi putar RCS.

Kartu kaya mandiri

  • Gunakan VERTICAL orientasi untuk rendering yang paling konsisten di seluruh perangkat.

  • Gunakan ketinggian TALL media untuk memberi gambar ruang tampilan yang memadai di Android dan iOS.

  • Jaga agar teks judul dan deskripsi tetap ringkas. Beberapa klien memotong teks di luar tiga baris.

  • URL dalam teks deskripsi tidak berfungsi sebagai tautan pada semua klien. Gunakan tindakan yang OpenUrl disarankan alih-alih menyematkan tautan dalam deskripsi.

  • Sertakan satu saran ajakan bertindak yang jelas per kartu. Beberapa tindakan bersaing mengurangi tingkat konversi.

Komidi putar

  • Tempatkan opsi yang direkomendasikan atau paling relevan di posisi kartu pertama. Pengguna paling banyak terlibat dengan kartu pertama yang terlihat.

  • Gunakan saran luar (tingkat pesan) untuk tindakan navigasi seperti “Kembali ke menu” atau “Bantuan.” Cadangan saran tingkat kartu untuk tindakan khusus untuk kartu itu.

  • Jaga konten kartu lebih ringkas daripada kartu mandiri karena kartu carousel memiliki ruang vertikal yang lebih sedikit.

  • Tinggi media kartu korsel terbatas pada SHORT atau MEDIUM (TALLtidak didukung dalam komidi putar).

  • Pastikan media gabungan di semua kartu tetap di bawah 100 MB. Optimalkan gambar sebelum mengunggah.

Praktik terbaik media

File media (gambar, video, PDF) meningkatkan keterlibatan pesan tetapi menambahkan ukuran payload dan variabilitas rendering. Untuk persyaratan format dan ukuran file, lihatMengirim pesan RCS yang kaya.

  • Kompres gambar sebelum mengunggah. Gunakan JPEG untuk foto dan PNG untuk grafik dengan transparansi.

  • Simpan file video di bawah 5 MB untuk pengiriman yang andal di seluruh operator dan perangkat.

  • Berikan pesan ThumbnailUrl untuk video dan file besar. Thumbnail ditampilkan saat media penuh dimuat dan meningkatkan pengalaman pengguna pada koneksi yang lambat.

  • Animasi GIF diputar di Android tetapi ditampilkan sebagai bingkai pertama statis di iOS. Jangan mengandalkan animasi GIF untuk menyampaikan informasi penting.

  • Host media di URL HTTPS atau di Amazon S3 (s3://menggunakan URI). Semua URL media harus sesuai dengan ^(https://|s3://).+$ polanya.

Strategi TTL dan fallback

Time to live (TTL) dan konfigurasi fallback bekerja sama untuk memastikan pesan Anda mencapai pengguna bahkan ketika pengiriman RCS gagal. Untuk detail implementasi, lihat Mengkonfigurasi kedaluwarsa pesan RCS danMengkonfigurasi fallback SMS atau MMS per pesan.

Mengatur nilai TTL

Selalu tetapkan TimeToLive nilai untuk konten yang sensitif terhadap waktu. Cocokkan TTL dengan jendela relevansi konten.

Nilai TTL yang direkomendasikan berdasarkan jenis konten
Jenis konten TTL yang direkomendasikan
One-time kata sandi (OTP) atau kode verifikasi 30 hingga 120 detik
Pemberitahuan penjualan flash Durasi hingga penjualan berakhir
Pengingat janji Waktu sampai janji
Pembaruan pengiriman 1 hingga 4 jam
catatan

API minimum adalah 1 detik, tetapi TTL minimal 10 detik disarankan untuk memungkinkan waktu pengiriman yang cukup. Maksimum adalah 172.800 detik (48 jam).

Fallback SMS atau MMS

Konfigurasikan FallbackConfiguration untuk pesan penting (OTP, konfirmasi pesanan, peringatan keamanan) sehingga konten mencapai pengguna jika pengiriman RCS gagal atau kedaluwarsa.

  • Atur Channel bidang ke SMS atau MMS tergantung pada apakah Anda memerlukan media di fallback.

  • Pertahankan MessageBody dalam 1.600 karakter (batas fallback, yang lebih pendek dari batas teks RCS 3.072 karakter).

  • Uji pengiriman fallback end-to-end dengan mengirim ke nomor telepon yang tidak mendukung RCS dan memverifikasi bahwa pesan SMS atau MMS tiba.

Pemantauan dan acara

Gunakan tujuan acara dan acara pengiriman untuk memantau kinerja pesan dan mengoptimalkan strategi pesan Anda. Untuk detail tentang jenis dan konfigurasi acara, lihatAcara pesan RCS.

  • Konfigurasikan tujuan acara sebelum Anda memulai pengiriman produksi. Ini memastikan Anda menangkap acara pengiriman, pembacaan, dan kedaluwarsa sejak awal.

  • Pantau tingkat kedaluwarsa pesan untuk menentukan apakah nilai TTL Anda sesuai. Tingkat kedaluwarsa yang tinggi menunjukkan TTL terlalu pendek atau banyak penerima tidak memiliki perangkat. RCS-capable

  • Lacak tanda terima baca untuk perbandingan relatif (A/B pengujian) daripada sebagai metrik absolut. Tidak semua klien melaporkan status baca.

  • Gunakan peristiwa konfirmasi pengiriman untuk membatalkan penghitung waktu fallback yang berlebihan dalam logika aplikasi Anda jika Anda mengelola fallback secara eksternal.

Varians rendering perangkat dan klien

Pesan RCS ditampilkan secara berbeda di seluruh klien Android dan iOS. Rancang untuk penyebut umum terendah dan uji pada kedua platform sebelum meluncurkan kampanye.

Perbedaan rendering antara Android dan iOS
Fitur Android iOS
Gambar GIF Animasi Statis (hanya bingkai pertama)
Tautkan pratinjau dalam teks URL di mana saja dalam pesan URL harus menjadi elemen terakhir. URL yang diikuti oleh teks tambahan mungkin tidak dapat diklik.
Ketinggian media kartu Hormati PENDEK, SEDANG, dan TINGGI Membuat semua ketinggian vertikal identik. Mungkin mengabaikan properti ketinggian.
Saran pesanan chip Diawetkan seperti yang dikirim Mungkin menyusun ulang chip
Kegigihan tindakan yang disarankan Tindakan di luar kartu menghilang setelah ketukan. Tombol kartu tetap ada. Semua tombol (kartu dan non-kartu) tetap ada setelah ketukan.
Nama tampilan dengan karakter jalur (/,\,:) Diberikan sebagai terdaftar Karakter dapat dilucuti oleh lapisan rendering iOS
Gambar spanduk agen Terlihat di profil agen Tidak ditampilkan
Tautan kebijakan privasi Terlihat di profil agen Tidak ditampilkan
Beberapa kontak per jenis Semua entri kontak terlihat Hanya kontak pertama per jenis yang terlihat (berdasarkan urutan daftar)
Media dengan ukuran teks aksesibilitas besar Rendering stabil Dapat memotong gambar saat ukuran teks besar diaktifkan
Lencana verifikasi operator “Diverifikasi oleh [Operator]” atau “Diverifikasi oleh Google” Nilai lencana yang sama. Rendering dikendalikan oleh Apple.

Rekomendasi desain berdasarkan perbedaan ini:

  • Gunakan orientasi VERTICAL kartu untuk tata letak yang konsisten.

  • Tempatkan URL di akhir pesan teks untuk memastikan pratinjau tautan ditampilkan di iOS.

  • Jangan bergantung pada animasi GIF untuk mengkomunikasikan informasi penting.

  • Pengurutan saran uji pada kedua platform jika urutannya bermakna bagi alur pengguna.

Tampilan rendering nama di iOS

Aplikasi Pesan iOS Apple dapat menghapus karakter yang menyerupai pemisah jalur sistem operasi (/,\,:) atau urutan pelarian URL dari nama agen yang ditampilkan. Perilaku ini dikendalikan pada tingkat OS dan tidak dapat diganti oleh AWS, Google, operator, atau mitra perpesanan.

Untuk menghindari ketidakcocokan nama tampilan:

  • Gunakan hanya karakter alfanumerik, spasi, tanda hubung, titik, dan tanda baca standar (seperti,&,') dalam nama tampilan Anda. !

  • Jangan gunakan garis miring maju, garis miring terbalik, atau titik dua sebagai bagian dari nama merek Anda.

  • Jika nama merek Anda menyertakan karakter-karakter ini, pertimbangkan representasi alternatif (misalnya, gunakan tanda hubung atau spasi alih-alih garis miring).

  • Selalu verifikasi penampilan agen Anda di perangkat uji iOS selama fase pengujian sebelum meminta peluncuran operator. Ini adalah salah satu tujuan utama agen pengujian.

Jika Anda telah meluncurkan agen dengan nama tampilan yang terpengaruh dan perlu mengubahnya, hubungi AWS Support. Perubahan nama tampilan pada agen yang diluncurkan memerlukan persetujuan ulang operator.

Visibilitas profil agen di iOS

Beberapa elemen profil agen yang terlihat di Android tidak ditampilkan di iOS:

  • Gambar spanduk: Tidak ditampilkan di iOS. Jangan mengandalkan spanduk untuk mengkomunikasikan informasi merek penting.

  • Tautan kebijakan privasi: Tidak terlihat di tampilan profil agen iOS. Pastikan kebijakan privasi Anda dapat diakses melalui cara lain (seperti situs web Anda atau tindakan yang disarankan dalam pesan selamat datang Anda).

  • Beberapa kontak: Jika Anda mengonfigurasi beberapa nomor telepon, email, atau situs web, iOS hanya menampilkan entri pertama per jenis kontak. Tempatkan kontak utama Anda terlebih dahulu dalam daftar saat mengonfigurasi agen Anda.

Pengujian lintas platform

Render RCS tergantung pada versi sistem operasi penerima, model perangkat, dan konfigurasi operator. Sebelum meminta peluncuran operator:

  • Kirim pesan uji ke perangkat Android dan iOS.

  • Verifikasi nama tampilan, logo, spanduk, deskripsi, tindakan yang disarankan, kartu kaya, dan media di kedua platform.

  • Uji dengan berbagai ukuran teks dan pengaturan aksesibilitas di iOS.

  • Konfirmasikan pratinjau tautan ditampilkan dengan benar di kedua platform.

Implementasi RCS Apple masih berkembang. Perilaku dapat berubah dengan pembaruan iOS. Pantau pengalaman perpesanan Anda setelah rilis iOS dan sesuaikan konten Anda.

Opt-out penanganan

Hormati preferensi opt-out pengguna dengan segera dan konsisten di semua saluran pesan.

  • Honor STOP dan UNSUBSCRIBE kata kunci dengan menghentikan semua pesan yang tidak penting segera setelah permintaan opt-out.

  • Kirim konfirmasi opt-out singkat yang menyertakan nama merek Anda sehingga pengguna tahu pengirim mana mereka berhenti berlangganan.

  • Pertahankan database opt-out Anda sendiri dan sinkronkan di seluruh saluran (RCS, SMS, MMS) untuk mencegah pengiriman pada satu saluran setelah pengguna memilih keluar pada saluran lain.

  • Konsultasikan dengan tim hukum Anda mengenai jenis pesan (seperti OTP atau peringatan penipuan) yang mungkin masih dikirim setelah opt-out.

catatan

AWS End User Messaging menyediakan manajemen daftar opt-out untuk SMS dan MMS. Untuk RCS, koordinasikan penanganan opt-out Anda dengan daftar opt-out Pesan Pengguna AWS Akhir dan catatan tingkat aplikasi Anda sendiri.