หน้านี้มีแนวทางปฏิบัติแนะนำสำหรับการสร้างประสบการณ์การใช้งาน RCS สำหรับธุรกิจที่มีประสิทธิภาพและน่าสนใจ ซึ่งครอบคลุมทั้ง การติดตั้งใช้งานทางเทคนิค และ การออกแบบการสนทนา
หลักเกณฑ์ทางเทคนิค
ตรวจสอบความสามารถของอุปกรณ์
ก่อนเริ่มการสนทนากับผู้ใช้ ให้ตรวจสอบว่าอุปกรณ์ของผู้ใช้รับข้อความ RCS ได้ ส่งการตรวจสอบความสามารถเพื่อระบุความสามารถของผู้ใช้ การตรวจสอบความสามารถ, และปรับการโต้ตอบของตัวแทนให้เหมาะสม โต้ตอบกับผู้ใช้ในรูปแบบที่อุปกรณ์ของผู้ใช้รองรับเท่านั้น หากอุปกรณ์ของผู้ใช้ไม่ได้เปิดใช้ RCS ให้ตั้งค่าวิธีการสื่อสารสำรองด้วยช่องทางอื่น เช่น SMS
ปฏิบัติตามขนาดข้อความสูงสุด
ข้อความ RCS สำหรับธุรกิจและไฟล์สื่อที่ข้อความดังกล่าวมีได้จะมีขนาดสูงสุดจำกัด ดูรายละเอียดได้ที่ ขนาดข้อความสูงสุด
ป้องกันการส่งข้อความที่ซ้ำ
ระบบต้องยืนยันก่อนว่าข้อความไม่ได้ส่งถึงผู้ใช้ก่อนที่จะลองส่งข้อความ SMS สำรอง เพื่อหลีกเลี่ยงการส่งข้อความที่ซ้ำไปยังผู้ใช้
ทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อปรับปรุงความน่าเชื่อถือของระบบและป้องกันข้อความที่ซ้ำ
- ตั้งค่าอายุการใช้งานของ Connection Pool ให้ตรงกับ TTL (Time to Live) ของ DNS: ใช้ Connection Pool และ Client Object Pool เพื่อนำการเชื่อมต่อและออบเจ็กต์ไคลเอ็นต์ที่มีอยู่กลับมาใช้ซ้ำ ตั้งค่าเวลาสูงสุดที่การเชื่อมต่อหรือออบเจ็กต์จะอยู่ใน Pool ให้ตรงกับ Time to Live (TTL) ของ DNS ของ API เพื่อหลีกเลี่ยงการใช้ที่อยู่ IP ที่ล้าสมัยหลังจากอัปเดต DNS
- อย่าคิดว่าการหมดเวลาการเชื่อมต่อหมายถึงการส่งไม่สำเร็จ: อย่าคิดว่าการหมดเวลาการเชื่อมต่อหมายความว่าระบบไม่ได้ส่งข้อความ RCS สำหรับธุรกิจ เนื่องจากข้อความอาจยังคงอยู่ระหว่างการประมวลผลในฝั่งเซิร์ฟเวอร์
- ยืนยันใบตอบรับการส่ง: ตรวจสอบใบตอบรับการส่งทุกครั้งก่อนที่จะทริกเกอร์ข้อความสำรอง
- ตั้งค่า TTL ให้ตรงกับการหมดเวลาการเชื่อมต่อ: ตั้งค่า TTL ของข้อความให้ตรงกับการหมดเวลาการเชื่อมต่อทุกครั้งที่ทำได้
- เพิกถอนข้อความก่อนส่งข้อความสำรอง: พยายามเพิกถอนข้อความเดิมก่อนส่งข้อความ SMS สำรองเสมอ หากเพิกถอนไม่สำเร็จ ให้จัดการกับความล้มเหลว เนื่องจากอาจบ่งบอกว่าระบบได้ส่งข้อความถึงผู้ใช้แล้ว
- ลองส่งข้อความอีกครั้ง: หากข้อความส่งไม่สำเร็จเนื่องจากข้อผิดพลาดที่ลองใหม่ได้หรือ
การหมดเวลาการเชื่อมต่อ ให้ลองดำเนินการส่งอีกครั้ง ใช้
messageIDเริ่มต้นเพื่อ ป้องกันข้อความที่ซ้ำ และ ใช้ Exponential Backoff เพื่อเว้นระยะการลองใหม่
ตรวจสอบข้อความขาเข้าที่ซ้ำ
เมื่อตรวจสอบและตอบกลับข้อความขาเข้าจากผู้ใช้ ให้ตรวจสอบ messageId และยืนยันว่าคุณยังไม่ได้รับและตอบกลับข้อความดังกล่าว
ระบบแบบกระจายมีวิธีส่งข้อความ 2 วิธี ดังนี้
- อย่างมาก 1 ครั้ง: ระบบจะส่งข้อความ 1 ครั้ง แต่หากมีข้อผิดพลาดเกี่ยวกับเครือข่าย หรือการสื่อสารระหว่างทาง ผู้รับอาจไม่ได้รับข้อความ
- อย่างน้อย 1 ครั้ง: ระบบอาจส่งข้อความหลายครั้ง แต่ ผู้รับจะได้รับข้อความแม้ว่าจะมีข้อผิดพลาดเกี่ยวกับเครือข่ายหรือการสื่อสาร
Google Cloud Pub/Sub ใช้ระบบอย่างน้อย 1 ครั้ง แม้ว่าระบบนี้อาจทำให้เกิดข้อความขาเข้าที่ซ้ำ แต่การนำข้อความที่ซ้ำออกก็ทำได้ง่ายๆ โดยการติดตามสตริง messageId หากได้รับข้อความแล้ว คุณสามารถละเว้นข้อความเพิ่มเติมที่ได้รับซึ่งมี messageId เดียวกันได้
ใช้รหัสที่ไม่ซ้ำกันสำหรับข้อความขาออกทั้งหมด
เมื่อตัวแทนส่งข้อความถึงผู้ใช้ messageId ที่คุณใส่ในการเรียก API ต้องไม่ซ้ำกันสำหรับทุกข้อความ
ดูข้อมูลเพิ่มเติมเกี่ยวกับการรับข้อความได้ที่ หัวข้อจัดการเหตุการณ์ขาเข้า
อย่าใช้ที่อยู่ IP ที่ล้าสมัย
ระบบต้องใช้ที่อยู่ IP ที่ถูกต้องและเป็นปัจจุบันเสมอเมื่อเชื่อมต่อกับ RBM API แพลตฟอร์มการเขียนโปรแกรมต่างๆ ใช้การหมดเวลาแคช DNS เริ่มต้นซึ่งอาจนานกว่าการตั้งค่า TTL ของ DNS ของ Google อย่างมาก ซึ่งอาจทำให้ระบบพยายามเชื่อมต่อกับที่อยู่ IP ที่หมดอายุแล้วและทำให้เกิดการหมดเวลา TTL ของแคช DNS ของโดเมน RBM คือ 300 วินาที
ทำตามขั้นตอนต่อไปนี้เพื่อให้ตรรกะการเชื่อมต่อเป็นไปตาม TTL 300 วินาที
- ตั้งค่าการหมดเวลาของ Connection Pool ให้ตรงกับ TTL: หากคุณใช้ Connection Pool หรือ Client Object Pool ให้ตั้งค่าอายุการใช้งานสูงสุดเป็น 300 วินาที (หรือน้อยกว่า) ซึ่งจะบังคับให้ระบบดึงที่อยู่ IP ใหม่เมื่อรีเฟรชออบเจ็กต์
- ตรวจสอบการรีเฟรช DNS: ตรวจสอบว่าแพลตฟอร์มหรือไลบรารีของไคลเอ็นต์ HTTP ของคุณตั้งค่าให้รีเฟรชแคช DNS ทุกๆ 300 วินาทีหรือน้อยกว่า
- ตรวจสอบ TTL ปัจจุบัน: เราขอแนะนำให้ตรวจสอบ TTL ของโดเมน RBM API แบบเป็นโปรแกรมเพื่อให้แน่ใจว่าคุณใช้ค่าสูงสุดที่ถูกต้อง คุณต้องตรวจสอบโดเมนที่สอดคล้องกับภูมิภาคการติดตั้งใช้งาน
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
ใช้การลองใหม่ด้วย Exponential Backoff
เมื่อเรียก API ใดก็ตาม การเรียกอาจล้มเหลวเนื่องจากปัญหาเกี่ยวกับโครงสร้างพื้นฐาน บริการทำงานหนักเกินไป ขีดจำกัด QPS และข้อผิดพลาดอื่นๆ ใช้การลองใหม่ด้วย Exponential Backoff เพื่อกู้คืนจากการเรียก API ที่ล้มเหลวอย่างราบรื่น
เมื่อใช้การลองใหม่ด้วย Exponential Backoff โครงสร้างพื้นฐานจะดำเนินการต่อไปนี้โดยอัตโนมัติ
- ระบุการเรียก API ที่ล้มเหลว
- ตั้งค่าระยะเวลารอเริ่มต้นและจำนวนการลองใหม่สูงสุด
- หยุดชั่วคราวตามระยะเวลารอ
- ลองเรียก API อีกครั้ง
ประเมินการตอบกลับของการเรียก API
- หากสำเร็จ ให้ดำเนินการตามขั้นตอนถัดไปในเวิร์กโฟลว์
- หากไม่สำเร็จ ให้เพิ่มระยะเวลารอและกลับไปที่ขั้นตอนที่ 3
- หากไม่สำเร็จหลังจากลองใหม่ครบจำนวนครั้งสูงสุด ให้เข้าสู่สถานะล้มเหลว
ระยะเวลารอที่เหมาะสมและจำนวนการลองใหม่สูงสุดที่เหมาะสมจะแตกต่างกันไปตามกรณีการใช้งาน กำหนดตัวเลขเหล่านี้ตามข้อกำหนดด้านเวลาในการตอบสนองของโครงสร้างพื้นฐานและเวิร์กโฟลว์
เพิ่มประสิทธิภาพ API ด้วยปลายทางระดับภูมิภาค
วิธีเพิ่มประสิทธิภาพ API เพื่อลดเวลาในการตอบสนอง
ใช้ปลายทางที่อยู่ใกล้กับภูมิภาคของผู้ใช้มากที่สุด
ตารางต่อไปนี้แสดงคำแนะนำเกี่ยวกับปลายทาง RBM ระดับภูมิภาคที่ควรใช้ตามหมายเลขโทรศัพท์ของผู้ใช้
คำนำหน้าหมายเลขโทรศัพท์ ปลายทางที่แนะนำ ภูมิภาคทางภูมิศาสตร์ +1 us-rcsbusinessmessaging.googleapis.com อเมริกา +2 europe-rcsbusinessmessaging.googleapis.com ยุโรป +3 europe-rcsbusinessmessaging.googleapis.com ยุโรป +4 europe-rcsbusinessmessaging.googleapis.com ยุโรป +5 us-rcsbusinessmessaging.googleapis.com อเมริกา +6 asia-rcsbusinessmessaging.googleapis.com เอเชีย +7 europe-rcsbusinessmessaging.googleapis.com ยุโรป +8 asia-rcsbusinessmessaging.googleapis.com เอเชีย +9 asia-rcsbusinessmessaging.googleapis.com เอเชีย ค่าเริ่มต้น us-rcsbusinessmessaging.googleapis.com อเมริกา พิจารณาตั้งเซิร์ฟเวอร์ไว้ใกล้กับปลายทางที่เลือก
ดูศูนย์ข้อมูลของ Google ได้ที่ https://www.google.com/about/datacenters/locations/
ดูข้อมูลเพิ่มเติมเกี่ยวกับการระบุภูมิภาคของตัวแทนได้ในเอกสารประกอบเรื่อง สร้างตัวแทน
UI การสนทนาและประสบการณ์ของผู้ใช้
UI การสนทนา ไม่ใช่ UI ของแอป
ตัวแทน RCS สำหรับธุรกิจเหมาะอย่างยิ่งสำหรับการมอบหมายงานที่มีประสิทธิภาพและเฉพาะเจาะจงให้กับผู้ใช้ในอินเทอร์เฟซผู้ใช้แบบสนทนา ตัวแทนที่ออกแบบมาอย่างดีจะทำให้การโต้ตอบมีความชัดเจน เข้าใจง่าย และมีโครงสร้างเหมือนการสนทนาตามธรรมชาติ
ตัวแทนไม่สามารถอาศัย UI แบบภาพของแอปหรือหน้าเว็บ และไม่ควรพยายามเลียนแบบ UI ดังกล่าว แต่ตัวแทนต้องอาศัยการสนทนาที่สร้างขึ้นอย่างรอบคอบซึ่งตอบสนองความต้องการของผู้ใช้ด้วยการแนะนำผ่านคำพูด คำแนะนำ และการจัดการข้อผิดพลาดที่ดี
นอกจากนี้ ตัวแทนไม่ควรเลียนแบบระบบโทรศัพท์อัตโนมัติหรืออินเทอร์เฟซที่ต้องให้ผู้ใช้ตอบกลับด้วยตัวเลขที่แสดงถึงการดำเนินการที่กำหนด ผู้ใช้ควรสื่อสารกับตัวแทนได้อย่างเป็นธรรมชาติ เหมือนกับการสื่อสารกับบุคคลอื่นในการสนทนา
เริ่มการสนทนา
การเริ่มต้นการสนทนาจะกำหนดความคาดหวังของผู้ใช้เกี่ยวกับสิ่งที่ตัวแทนทำได้ เริ่มการสนทนาด้วยข้อความที่น่าสนใจ แสดงบุคลิกของตัวแทน ใส่ข้อมูลที่ผู้ใช้สนใจไว้ด้านหน้า และแชร์ความสามารถของตัวแทน ให้ตัวเลือกที่ชัดเจนแก่ผู้ใช้ในการโต้ตอบกับตัวแทนและสนทนาต่อ
แสดงบุคลิกของตัวแทน: กำหนดน้ำเสียงด้วยการทักทายผู้ใช้และ แนะนำแบรนด์ หากสร้างบุคลิกสมมติให้ตัวแทน เช่น ผู้ช่วยเสมือนหรือเจ้าหน้าที่อำนวยความสะดวกดิจิทัล ให้ระบุอย่างชัดเจนว่าเป็นแชทบ็อต ไม่ใช่บุคคลจริง คุณสามารถตั้งชื่อตัวแทนให้ตรงกับบุคลิกสมมติได้ อวาตาร์เป็นวิธีที่ยอดเยี่ยมในการเสริมสร้างภาพลักษณ์ โดยอาจเป็นโลโก้ของคุณ แต่ตัวการ์ตูนกราฟิกก็ใช้ได้เช่นกัน
แชร์ความสามารถของตัวแทน: ข้อความทักทายที่ดีจะระบุอย่างชัดเจนว่าการสนทนาจะนำเสนออะไร อธิบายความสามารถของตัวแทนในภาพรวม นอกจากนี้ ยังรวมถึง คำตอบ และการดำเนินการ ที่แนะนำเพื่อนำผู้ใช้ไปตามเส้นทางที่เฉพาะเจาะจง ใช้คำแนะนำเหล่านี้เพื่อช่วยให้ผู้ใช้ไปยังส่วนต่างๆ ของการสนทนาและเข้าใจงานที่ตัวแทนช่วยเหลือได้
เขียนข้อความที่ชัดเจนและสอดคล้องกัน
ส่งข้อความที่ผู้ใช้เข้าใจและตอบกลับได้ง่าย สร้างข้อความที่กระตุ้นให้ผู้ใช้ตอบกลับ รักษาสไตล์ รูปแบบ และจังหวะที่สอดคล้องกันเพื่อสร้างความไว้วางใจกับผู้ใช้
โปรดคำนึงถึงแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้เมื่อสร้างข้อความ
อย่าสร้างทางตัน ข้อความแต่ละข้อความควรนำไปสู่ขั้นตอนถัดไปที่มีความหมาย
- หากเส้นทางของผู้ใช้มีงานที่มีหลายขั้นตอน ให้ใช้เครื่องหมายวาทกรรมเพื่อแนะนำผู้ใช้ตลอดกระบวนการ
เช่น ตอนนี้… และ… เข้าใจแล้ว! นี่ครับ/ค่ะ…
- เขียนข้อความให้กระชับ เนื่องจาก คำตอบที่แนะนำ และ การดำเนินการ มีความยาวสูงสุด 25 ตัวอักษร
- หากการสนทนามีการส่งต่อ การรับทราบอย่างรวดเร็วจะช่วยให้การเปลี่ยนผ่านราบรื่นขึ้น
เช่น "ได้เลย ผู้จัดการบัญชีของคุณจะดูแลต่อจากนี้"
เช่น "เยี่ยมเลย! ผม/คิดว่าผม/ทราบแล้วว่าคุณกำลังมองหาอะไร" แล้ว ใส่ลิงก์ไปยังเว็บไซต์
รับทราบข้อความของผู้ใช้ด้วยคำหรือวลีที่แสดงการรับรู้
เช่น "เลือกได้ดีเลย!", "ตกลง", "ได้เลย" หรือ "เข้าใจแล้ว"
พูดกับผู้ใช้โดยตรงโดยใช้ชื่อของผู้ใช้ (หากทราบ) หรือคำสรรพนาม "คุณ" หลีกเลี่ยงการอ้างถึงผู้ใช้ด้วยคำว่า "ฉัน" หรือ "ผม" เนื่องจากอาจทำให้เกิดความสับสนได้
ใช้ตัวพิมพ์ใหญ่เฉพาะอักษรตัวแรกของคำในชื่อและป้ายกำกับ ไม่ใช่ตัวพิมพ์ใหญ่เฉพาะอักษรตัวแรกของคำสำคัญ
เช่น "รายการเคลื่อนไหวของบัญชี" ไม่ใช่ "รายการเคลื่อนไหวของบัญชี"
ใช้คำย่อ ซึ่งเหมาะสมแม้แต่กับตัวแทนที่มีน้ำเสียงจริงจังหรือเป็นทางการ
เช่น "it's" เป็นกันเองมากกว่า "it is"
ใช้เครื่องหมายอัศเจรีย์เท่าที่จำเป็น
ใช้คอมมาอนุกรม เช่น "A, B และ C" ไม่ใช่ "A, B และ C"
เขียนตัวเลขเป็นตัวเลข
เช่น "1, 2, 3" ไม่ใช่ "หนึ่ง สอง สาม"
เมื่อใช้อิโมจิ ให้ตรวจสอบว่าน้ำเสียงขี้เล่นเหมาะกับกรณีการใช้งาน
เช่น ผู้ใช้ที่จองรถลากหรือดูผลการตรวจสุขภาพอาจไม่มีอารมณ์ร่วม
จัดลำดับข้อความ
หากคุณส่งข้อความหลายข้อความตามลำดับ ผู้ใช้ต้องได้รับข้อความเหล่านั้นตามลำดับ ข้อความที่มีสื่อจะใช้เวลาประมวลผลนานกว่าข้อความที่เป็นข้อความอย่างเดียว รอจนกว่าจะได้รับการตอบกลับ 200 OK สำหรับข้อความก่อนหน้าก่อนที่จะส่งข้อความถัดไปในลำดับ เพื่อให้แน่ใจว่าผู้ใช้ได้รับข้อความตามลำดับที่ถูกต้อง
สร้างการสนทนาที่น่าสนใจด้วยคำตอบและการดำเนินการที่แนะนำ
คำตอบที่แนะนำ และ การดำเนินการ เป็นเครื่องมือที่มีประสิทธิภาพในการแนะนำและปรับปรุงการสนทนาของผู้ใช้ โดยอาจปรากฏหลังข้อความหรือริชการ์ด และมีตัวเลือกให้สนทนาต่อหรือเปลี่ยนหัวข้อการสนทนา
คำตอบที่แนะนำ: ช่วยให้ผู้ใช้ตอบกลับตัวแทนได้อย่างรวดเร็วโดยมี ตัวเลือกที่กำหนดไว้ล่วงหน้า ใช้คำตอบที่แนะนำทุกครั้งที่ทำได้ โดยเฉพาะอย่างยิ่งเมื่อคาดหวังการตอบกลับที่เฉพาะเจาะจง
การดำเนินการที่แนะนำ: อนุญาตให้ตัวแทนผสานรวมกับฟีเจอร์ของอุปกรณ์ ซึ่งจะช่วยให้งานต่างๆ เช่น การโทรหาทีมสนับสนุนหรือการค้นหาสถานที่คล่องตัวขึ้น
คำนึงถึงประเด็นสำคัญต่อไปนี้เพื่อสร้างการสนทนาที่มีประสิทธิภาพและน่าสนใจยิ่งขึ้น
- ความเกี่ยวข้อง: ตรวจสอบว่าคำแนะนำสอดคล้องกับการสนทนาปัจจุบัน
- ความกระชับ: จำกัดจำนวนคำแนะนำเพื่อไม่ให้ผู้ใช้รู้สึกว่ามีตัวเลือกมากเกินไป
- ความชัดเจน: ใช้ภาษาที่ชัดเจนและกระชับสำหรับข้อความคำแนะนำ
ช่วยเหลือผู้ใช้
ตัวแทนควรตอบกลับข้อความ HELP จากผู้ใช้และให้ข้อมูลเกี่ยวกับความสามารถของตัวแทน รายการคำตอบที่แนะนำซึ่งปรับให้เหมาะกับความสามารถของตัวแทนสามารถเปลี่ยนประสบการณ์ของผู้ใช้ที่ไม่ดีให้กลายเป็นประสบการณ์ที่เป็นประโยชน์ได้
ตรวจสอบว่าโลโก้และรูปภาพหลักแสดงผลได้ดี
- เว้นพื้นที่รอบๆ โลโก้ให้เพียงพอเพื่อรองรับการครอบตัดและรักษาความสมบูรณ์ของภาพ
- หลีกเลี่ยงการยืดหรือบิดเบือนโลโก้หรือรูปภาพหลัก เนื่องจากอาจส่งผลเสียต่อการรับรู้แบรนด์
- ทดสอบโลโก้ และรูปภาพหลักในทั้งโหมดสว่างและโหมดมืดเพื่อให้มองเห็นได้ชัดเจนและ สวยงามที่สุด
ดูแหล่งข้อมูลเพิ่มเติมที่จะช่วยคุณออกแบบโลโก้หรือแก้ปัญหาได้ที่ หลักเกณฑ์การออกแบบโลโก้
โลโก้
- ออกแบบโดยคำนึงถึงการแสดงผลเป็นสี่เหลี่ยมจัตุรัสที่มีมุมโค้งมน โลโก้ RCS สำหรับธุรกิจจะแสดงเป็น "สี่เหลี่ยมจัตุรัสที่มีมุมโค้งมน" ในรายการการสนทนา หน้าจอการสนทนา และรายละเอียดการสนทนาเพื่อให้สอดคล้องกับมาตรฐานของ Google และอุตสาหกรรม
- วางโลโก้ไว้ตรงกลางรูปภาพเพื่อให้องค์ประกอบของแบรนด์ยังคงชัดเจนหลังการครอบตัด
- ตัวแทนที่ได้รับการยืนยันจะมีเครื่องหมายถูกสำหรับการยืนยันปรากฏอยู่ข้างชื่อตัวแทนโดยอัตโนมัติ เครื่องหมายนี้ได้รับการปกป้องจากการแอบอ้างเป็นผู้อื่นและเพิ่มด้วยตนเองไม่ได้
- สำหรับโลโก้ที่มีพื้นหลังโปร่งใส ให้ตรวจสอบว่ามีคอนทราสต์เพียงพอกับทั้งพื้นหลังสีอ่อนและสีเข้มเพื่อรองรับโหมดมืด หากไม่แน่ใจ ให้ใช้พื้นหลังสีขาว
รูปภาพหลัก
- ใช้สัดส่วนภาพ 45:14 เพื่อป้องกันการครอบตัดที่ไม่ต้องการ
พิจารณาการซ้อนทับของโลโก้เมื่อออกแบบรูปภาพหลัก เพื่อไม่ให้องค์ประกอบสำคัญถูกบดบัง
เคารพความต้องการของผู้ใช้ที่ไม่ต้องการรับข้อความ
การรักษาความไว้วางใจของผู้ใช้หมายถึงการเคารพค่ากำหนดการสื่อสารของผู้ใช้ เมื่อผู้ใช้ระบุว่าต้องการหยุดรับข้อความ ตัวแทนต้องปฏิบัติตามตัวเลือกของผู้ใช้ ซึ่งรวมถึงการทำความเข้าใจและตอบสนองต่อการแสดงเจตจำนงในการเลือกไม่รับต่างๆ อย่างเหมาะสม เช่น "STOP" ในทุกภาษาที่เกี่ยวข้อง
โปรดศึกษากฎหมายและแนวทางปฏิบัติแนะนำสำหรับประเทศที่คุณดำเนินการเกี่ยวกับวิธีการตอบกลับข้อความ "STOP" และคำสั่งอื่นๆ ที่ต้องปฏิบัติตาม
เช่น โปรดดูแนวทางปฏิบัติแนะนำของ CTIA
จัดการเหตุการณ์ยกเลิกการสมัครรับข้อมูลและสมัครรับข้อมูล
Google Messages มีฟีเจอร์ยกเลิกการสมัครรับข้อมูล และสมัครรับข้อมูล ในตัว ซึ่งช่วยให้ผู้ใช้ควบคุมการสนทนาได้ เมื่อผู้ใช้เลือกยกเลิกการสมัครรับข้อมูล ตัวแทนจะได้รับเหตุการณ์ Webhook UNSUBSCRIBE เหตุการณ์ SUBSCRIBE แสดงถึงความตั้งใจของผู้ใช้ที่จะกลับมามีส่วนร่วมกับตัวแทน
ดูข้อมูลโดยละเอียดเกี่ยวกับการจัดการ เหตุการณ์ยกเลิกการสมัครรับข้อมูล และ สมัครรับข้อมูลอีกครั้ง รวมถึงรายละเอียดเพย์โหลด กฎธุรกิจ และตัวอย่างได้ใน เอกสารประกอบเกี่ยวกับ เหตุการณ์ที่ผู้ใช้สร้างขึ้น
จัดการการเลือกไม่รับ
แพลตฟอร์ม RCS สำหรับธุรกิจไม่มีวิธีจัดการรายการผู้ใช้ที่เลือกไม่รับโดยตรง คุณมีหน้าที่รับผิดชอบในการดูแลฐานข้อมูลของผู้ใช้ที่เลือกหยุดรับข้อความผ่านการยกเลิกการสมัครรับข้อมูลหรือการเลือกไม่รับรูปแบบอื่นๆ
สนทนาต่อ
หากผู้ใช้ลบการสนทนากับตัวแทน ผู้ใช้จะต้องเริ่มการติดต่ออีกครั้งผ่านช่องทางอื่น เช่น การเลือกรับในเว็บไซต์ รหัสสั้น SMS หรือกลไกการขอความยินยอมอื่นๆ การโต้ตอบใหม่นี้แสดงถึงความสนใจที่เพิ่มขึ้นในการรับข้อความ