View a markdown version of this page

RCS 모범 사례 - AWS 최종 사용자 메시징 SMS
대화형 및 대화형 설계제안 전략리치 카드 및 캐러셀 디자인미디어 모범 사례TTL 및 대체 전략모니터링 및 이벤트디바이스 및 클라이언트 렌더링 분산옵트아웃 처리

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

RCS 모범 사례

RCS 리치 메시징을 사용하면 기존 SMS를 넘어 대화형 경험을 만들 수 있습니다. 이 주제에서는 제안 전략, 리치 카드 및 캐러셀 레이아웃, 미디어 최적화, 메시지 만료, 대체 계획 및 모니터링을 포함하여 효과적인 RCS 메시지를 설계하기 위한 지침을 제공합니다.

개별 기능에 대한 자세한 내용은 RCS 제안 구성, , RCS 리치 카드 전송RCS 캐러셀 전송, RCS 메시지 만료 구성, 및 단원메시지당 SMS 또는 MMS 폴백 구성을 참조하십시오RCS 메시지 이벤트.

대화형 및 대화형 설계

RCS 메시지는 제안된 회신, 제안된 작업, 리치 카드 및 캐러셀과 같은 대화형 요소를 지원합니다. 이러한 기능을 효과적으로 사용하려면 각 메시지 교환을 단방향 알림이 아닌 지속적인 대화의 일부로 취급해야 합니다.

컨텍스트 및 옵션으로 열기

명확한 인사말을 포함하고, 사용자가 할 수 있는 일을 설명하고, 다음 단계를 안내하기 위해 제안된 답변을 제공합니다. 이렇게 하면 기대치를 설정하고 마찰을 줄일 수 있습니다.

메시지를 간결하게 유지

문자 메시지당 300자 미만을 목표로 합니다. 복잡한 정보를 여러 메시지로 나누거나 구조화된 콘텐츠에 리치 카드를 사용합니다.

데드 엔드 방지

모든 메시지는 다음 단계로 이어져야 합니다. 후속 제안, 기본 메뉴 옵션 또는 인적 에이전트 경로를 제공합니다.

사용자 직접 주소 지정

두 번째 사람을 사용합니다. "예약이 확인됨"이 아닌 "예약이 확인됨"을 작성합니다.

제안 전략

제안 사항(응답과 작업 모두)은 메시지 아래에 대화형 칩으로 표시됩니다. 입력을 줄이고 참여를 높이며 구조화된 PostbackData 값을 통해 응답을 라우팅할 수 있습니다. 제안 유형의 전체 목록은 섹션을 참조하세요RCS 제안 구성.

간결한 작업 레이블 작성

Text 필드에는 25자 제한이 있습니다. 탭할 때 정확히 어떤 일이 발생하는지 사용자에게 알려주는 작업 지향 언어를 사용합니다.

제안 레이블 예제
Avoid 선호
"옵션 1" “월요일 예약”
"여기를 클릭하세요" “주문 상태 보기”
"추가 정보" "요금 세부 정보 보기"

제안 3~5 옵션

세 가지 제안은 대부분의 상호 작용에 적합합니다. 메시지당 최대 11개의 제안(리치 카드당 4개)을 포함할 수 있지만 한 번에 5개 이상의 옵션이 사용자에게 부담을 주는 경향이 있습니다. 더 많은 선택 항목이 필요한 경우 캐러셀을 사용하거나 흐름을 여러 단계로 분할합니다.

PostbackData의 라우팅

디스플레이 텍스트를 구문 분석하는 대신 PostbackData 백엔드 라우팅 로직에를 사용합니다. 이 접근 방식은 현지화를 지원하고(라우팅을 수정Text하지 않고 사용자가 볼 수 있도록 변경할 수 있음) 애플리케이션에 대한 구조화된 컨텍스트를 제공합니다.

포스트백 값에서 작업, 개체 및 컨텍스트를 인코딩합니다. 예제:

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

일관된 접두사(예: book_, confirm_, cancel_, nav_)를 사용하여 백엔드의 라우팅을 간소화합니다.

중요

오래된 포스트백을 정상적으로 처리합니다. 사용자는 제안을 받은 후 몇 시간을 선택할 수 있습니다. 참조된 엔터티가 여전히 존재하는지 확인하고 작업이 더 이상 유효하지 않은 경우 사용자에게 알립니다.

리치 카드 및 캐러셀 디자인

리치 카드와 캐러셀은 시각적 형식으로 구조화된 콘텐츠(이미지, 제목, 설명 및 제안)를 제공합니다. 구현 세부 정보는 RCS 리치 카드 전송 및 섹션을 참조하세요RCS 캐러셀 전송.

독립 실행형 리치 카드

  • 디바이스 간에 가장 일관된 렌더링을 위해 VERTICAL 방향을 사용합니다.

  • TALL 미디어 높이를 사용하여 Android와 iOS 모두에서 이미지에 적절한 디스플레이 공간을 제공합니다.

  • 제목과 설명 텍스트를 간결하게 유지합니다. 일부 클라이언트는 세 줄 이상으로 텍스트를 잘라냅니다.

  • 설명 텍스트의 URLs 모든 클라이언트에서 링크로 작동하지 않습니다. 설명에 링크를 임베딩하는 대신 OpenUrl 제안된 작업을 사용합니다.

  • 카드당 하나의 명확한 call-to-action 제안을 포함합니다. 여러 경쟁 작업을 수행하면 변환 속도가 줄어듭니다.

캐러셀

  • 첫 번째 카드 위치에 권장 옵션 또는 가장 관련성이 높은 옵션을 배치합니다. 사용자는 가장 먼저 보이는 카드를 사용합니다.

  • "메뉴로 돌아가기" 또는 "도움말"과 같은 탐색 작업에 외부(메시지 수준) 제안을 사용합니다. 해당 카드와 관련된 작업에 대한 카드 수준 제안을 예약합니다.

  • 캐러셀 카드의 세로 공간이 적기 때문에 독립형 카드보다 카드 콘텐츠를 더 간결하게 유지합니다.

  • 캐러셀 카드 미디어 높이는 SHORT 또는 로 제한됩니다MEDIUM(TALL 캐러셀에서는 지원되지 않음).

  • 모든 카드에서 결합된 미디어가 100MB 미만으로 유지되는지 확인합니다. 업로드하기 전에 이미지를 최적화합니다.

미디어 모범 사례

미디어 파일(이미지, 비디오, PDFs 메시지 참여를 개선하지만 페이로드 크기와 렌더링 변동성을 추가합니다. 파일 형식 및 크기 요구 사항은 섹션을 참조하세요리치 RCS 메시지 전송.

  • 업로드하기 전에 이미지를 압축합니다. 사진에는 JPEG를 사용하고 투명 그래픽에는 PNG를 사용합니다.

  • 통신 사업자와 디바이스 간에 안정적으로 전송할 수 있도록 비디오 파일을 5MB 미만으로 유지합니다.

  • 비디오 및 대용량 파일 메시지ThumbnailUrl에를 제공합니다. 전체 미디어가 로드되는 동안 썸네일이 표시되며 느린 연결에서 사용자 경험을 개선합니다.

  • GIF 애니메이션은 Android에서 재생되지만 iOS에서는 정적 첫 번째 프레임으로 표시됩니다. GIF 애니메이션을 사용하여 중요한 정보를 전달하지 마세요.

  • HTTPS URLs 또는 Amazon S3(s3://URIs. 모든 미디어 URLs 패턴과 일치해야 합니다^(https://|s3://).+$.

TTL 및 대체 전략

TTL(Time To Live) 및 폴백 구성이 함께 작동하여 RCS 전송이 실패하더라도 메시지가 사용자에게 도달하도록 합니다. 구현 세부 정보는 RCS 메시지 만료 구성 및 섹션을 참조하세요메시지당 SMS 또는 MMS 폴백 구성.

TTL 값 설정

항상 시간에 민감한 콘텐츠의 TimeToLive 값을 설정합니다. TTL을 콘텐츠 관련성 기간과 일치시킵니다.

콘텐츠 유형별 권장 TTL 값
콘텐츠 유형 권장 TTL
일회용 암호(OTP) 또는 확인 코드 30~120초
플래시 판매 알림 판매 종료까지의 기간
예약 알림 약속까지의 시간
전송 업데이트 1~4시간
참고

API 최소값은 1초이지만 충분한 전송 시간을 허용하려면 최소 10초의 TTL을 사용하는 것이 좋습니다. 최대값은 172,800초(48시간)입니다.

SMS 또는 MMS 대체

RCS 전송이 실패하거나 만료되는 경우 콘텐츠가 사용자에게 도달하도록 중요 메시지(OTPs, 주문 확인, 보안 알림)에 FallbackConfiguration 대해를 구성합니다.

  • 대체에 미디어가 필요한지 여부에 MMS 따라 Channel 필드를 SMS 또는 로 설정합니다.

  • 를 1,600자 MessageBody 이내로 유지합니다(폴백 제한은 3,072자 RCS 텍스트 제한보다 짧음).

  • RCS를 지원하지 않는 전화번호로 전송하고 SMS 또는 MMS 메시지가 도착했는지 확인하여 폴백 전송end-to-end적으로 테스트합니다.

모니터링 및 이벤트

이벤트 대상 및 전송 이벤트를 사용하여 메시지 성능을 모니터링하고 메시징 전략을 최적화합니다. 이벤트 유형 및 구성에 대한 자세한 내용은 섹션을 참조하세요RCS 메시지 이벤트.

  • 프로덕션 전송을 시작하기 전에 이벤트 대상을 구성합니다. 이렇게 하면 처음부터 전송, 읽기 및 만료 이벤트를 캡처할 수 있습니다.

  • 메시지 만료율을 모니터링하여 TTL 값이 적절한지 확인합니다. 만료율이 높으면 TTL이 너무 짧거나 많은 수신자가 RCS 지원 디바이스를 가지고 있지 않음을 나타냅니다.

  • 절대 지표가 아닌 상대 비교(A/B 테스트)를 위해 읽기 수신을 추적합니다. 모든 클라이언트가 읽기 상태를 보고하는 것은 아닙니다.

  • 폴백을 외부에서 관리하는 경우 전송 확인 이벤트를 사용하여 애플리케이션 로직에서 중복 폴백 타이머를 취소합니다.

디바이스 및 클라이언트 렌더링 분산

RCS 메시지는 Android 및 iOS 클라이언트 간에 다르게 렌더링됩니다. 캠페인을 시작하기 전에 가장 낮은 공통 분모를 설계하고 두 플랫폼에서 테스트합니다.

Android와 iOS의 렌더링 차이
기능 Android iOS
GIF 이미지 애니메이션 정적(첫 번째 프레임만 해당)
텍스트로 미리 보기 연결 메시지의 모든 위치 URL URL은 마지막 요소여야 합니다. 추가 텍스트 뒤에 오는 URL은 클릭할 수 없습니다.
카드 미디어 높이 SHORT, MEDIUM 및 TALL을 준수합니다. 모든 수직 높이를 동일하게 렌더링합니다. 높이 속성을 무시할 수 있습니다.
제안 칩 순서 전송된 상태로 보존됨 칩을 재정렬할 수 있음
제안된 작업 지속성 카드 외부 작업은 탭하면 사라집니다. 카드 버튼은 유지됩니다. 모든 버튼(카드 및 비카드)은 탭 후에도 유지됩니다.
경로 문자가 포함된 표시 이름(/, \, :) 등록된 것으로 렌더링됨 iOS 렌더링 계층에서 캐릭터를 제거할 수 있습니다.
에이전트 배너 이미지 에이전트 프로필에 표시 표시되지 않음
개인 정보 보호 정책 링크 에이전트 프로필에 표시 표시되지 않음
유형당 여러 연락처 모든 연락처 항목이 표시됨 유형당 첫 번째 연락처만 표시됨(목록 순서 기준)
접근성 텍스트 크기가 큰 미디어 안정적인 렌더링 큰 텍스트 크기가 활성화된 경우 이미지를 잘라낼 수 있습니다.
통신 사업자 확인 배지 "[캐리어]에서 확인" 또는 "Google에서 확인" 동일한 배지 값입니다. Apple에서 제어하는 렌더링입니다.

이러한 차이점을 기반으로 권장 사항을 설계합니다.

  • 일관된 레이아웃을 위해 VERTICAL 카드 방향을 사용합니다.

  • 링크 미리 보기가 iOS에서 렌더링되도록 텍스트 메시지 끝에 URLs을 배치합니다.

  • 필수 정보를 전달하기 위해 GIF 애니메이션에 의존하지 마세요.

  • 시퀀스가 사용자 흐름에 의미 있는 경우 두 플랫폼 모두에서 제안 순서를 테스트합니다.

iOS에서 이름 렌더링 표시

Apple의 iOS Messages 앱은 표시된 에이전트 이름에서 운영 체제 경로 구분자(/, \, :) 또는 URL 이스케이프 시퀀스와 유사한 문자를 제거할 수 있습니다. 이 동작은 OS 수준에서 제어되며 AWS, Google, 통신 사업자 또는 메시징 파트너가 재정의할 수 없습니다.

표시 이름 불일치를 방지하려면:

  • 표시 이름에는 영숫자, 공백, 하이픈, 마침표 및 표준 구두점(예: &, ', !)만 사용합니다.

  • 브랜드 이름의 일부로 슬래시, 백슬래시 또는 콜론을 사용하지 마세요.

  • 브랜드 이름에 이러한 문자가 포함된 경우 대체 표현을 고려하세요(예: 슬래시 대신 하이픈 또는 공백 사용).

  • 통신사 시작을 요청하기 전에 테스트 단계에서 항상 iOS 테스트 디바이스에서 에이전트의 모습을 확인합니다. 이는 에이전트 테스트의 주요 목적 중 하나입니다.

영향을 받는 표시 이름으로 에이전트를 이미 시작했으며 변경해야 하는 경우 AWS Support에 문의하십시오. 시작된 에이전트의 표시 이름 변경은 통신 사업자의 재승인이 필요합니다.

iOS의 에이전트 프로필 가시성

Android에 표시되는 일부 에이전트 프로필 요소는 iOS에 표시되지 않습니다.

  • 배너 이미지: iOS에는 표시되지 않습니다. 배너를 사용하여 중요한 브랜드 정보를 전달하지 마세요.

  • 개인 정보 보호 정책 링크: iOS 에이전트 프로필 보기에 표시되지 않습니다. 다른 방법(예: 웹 사이트 또는 환영 메시지의 제안된 작업)을 통해 개인 정보 보호 정책에 액세스할 수 있는지 확인합니다.

  • 여러 연락처: 여러 전화번호, 이메일 또는 웹 사이트를 구성하는 경우 iOS는 연락처 유형당 첫 번째 항목만 표시합니다. 에이전트를 구성할 때 목록에 기본 연락처를 먼저 배치합니다.

플랫폼 간 테스트

RCS 렌더링은 수신자의 운영 체제 버전, 디바이스 모델 및 통신 사업자 구성에 따라 달라집니다. 통신 사업자 시작을 요청하기 전에:

  • Android 및 iOS 디바이스 모두에 테스트 메시지를 전송합니다.

  • 두 플랫폼 모두에서 표시 이름, 로고, 배너, 설명, 제안된 작업, 리치 카드 및 미디어를 확인합니다.

  • iOS에서 다양한 텍스트 크기 및 접근성 설정으로 테스트합니다.

  • 두 플랫폼에서 링크 미리 보기가 올바르게 렌더링되는지 확인합니다.

Apple의 RCS 구현은 여전히 진화하고 있습니다. iOS 업데이트에 따라 동작이 변경될 수 있습니다. iOS 릴리스 후 메시징 환경을 모니터링하고 그에 따라 콘텐츠를 조정합니다.

옵트아웃 처리

모든 메시징 채널에서 사용자 옵트아웃 기본 설정을 즉시 일관되게 준수합니다.

  • 옵트아웃 요청 직후 필수가 아닌 모든 메시지를 중단하여 STOP 및 UNSUBSCRIBE 키워드를 준수합니다.

  • 사용자가 구독을 취소한 발신자를 알 수 있도록 브랜드 이름이 포함된 간단한 옵트아웃 확인을 보냅니다.

  • 사용자가 다른 옵트아웃한 후 한 채널에서 전송되지 않도록 자체 옵트아웃 데이터베이스를 유지하고 채널(RCS, SMS, MMS) 간에 동기화합니다.

  • 옵트아웃 후에도 여전히 전송할 수 있는 메시지 유형(예: OTPs 또는 사기 알림)에 대해서는 법률 팀에 문의하세요.

참고

AWS End User Messaging은 SMS 및 MMS에 대한 옵트아웃 목록 관리를 제공합니다. RCS의 경우 AWS End User Messaging 옵트아웃 목록과 자체 애플리케이션 수준 레코드를 모두 사용하여 옵트아웃 처리를 조정합니다.