Content Cards로 소비자에게 주문 업데이트 알리기

주문 관리 시스템(OMS)의 주문 업데이트를 기록하고, 배송 또는 취소 같은 업데이트에 대해 Content Cards를 보내고, 키-값 페어를 사용해 앱에서 오래된 카드를 닫으면 커스텀 Content Card 피드를 최신 주문 상태로 유지할 수 있습니다.

이 예시에 대하여

가상의 의류 및 뷰티 소매업체인 Flash & Thread는 모바일 앱에 가로형 Content Card 피드를 두고, 각 카드에 구매 상태를 보여주고 싶어 합니다. 예를 들어 주문이 picked에서 dispatched(배송됨)로 바뀌거나 cancelled가 되었을 때를 표시하는 식입니다.

이 회사의 주문 관리 시스템은 소비자의 이메일, 주문 번호, 주문 상태, 추적 URL을 저장하며, 이 값이 업데이트되면 Braze를 호출할 수 있습니다. 마케팅팀은 상태별 카드 문구를 원합니다(예: dispatched에는 “주문하신 상품이 배송 중입니다”, picked에는 “주문을 준비하고 있습니다”). 같은 주문의 이전 카드(예: dispatched 카드가 도착한 뒤의 picked 카드)는 닫아서 소비자가 최신 상태만 보도록 합니다.

이 예시에서는 다음 방법을 보여줍니다.

1. 주문 관리 시스템이 pending, held, picked, dispatched, cancelled 같은 상태 변경을 기록할 때 /users/track에 커스텀 이벤트(예: order_update)를 기록합니다.
2. 각 상태마다 별도의 실행 기반 Content Card Campaign(캠페인)을 트리거하고, 이벤트 속성정보로 Liquid 개인화를 적용합니다.
3. 각 카드에 order_number, order_hierarchy 같은 키-값 페어(extras)를 설정합니다.
4. 커스텀 Content Card 피드에서 order_number별로 order_hierarchy가 가장 높은 카드만 유지하고 나머지는 닫습니다.

대시보드 제거 이벤트만으로는 같은 여정에서 온 여러 카드 중 특정 주문의 카드 하나만 대상으로 지정할 수 없을 때 이 방법을 사용하세요.

고려 사항

• Content Cards는 전송 후 최대 30일이 지나면 만료되어 삭제됩니다. 종료 상태(예: 취소됨)의 카드를 피드에서 더 빨리 없애고 싶다면 만료 기간을 더 짧게 설정하세요. Content Card 만들기를 참조하세요.
• 주문 관리 시스템에 이메일만 있는 경우, /users/track에서 보조 식별자인 email로 사용자를 식별하세요. 주문 관리 시스템에 external_id가 있다면 이를 우선 사용하세요. 커스텀 식별자 유형이 필요하다면 사용자 별칭도 사용할 수 있습니다. 이때 alias_name에는 식별자 값을, alias_label에는 유형(예: email)을 설정합니다. 식별자 확인 및 사용자 별칭 객체를 참조하세요.
• 이벤트 트리거 방식을 사용하면 커스텀 이벤트 속성정보를 Liquid 개인화와 이벤트 속성정보 세분화에 활용할 수 있습니다. 단, 속성으로도 따로 기록하지 않는 한 이벤트 속성정보는 프로필에 속성으로 유지되지 않습니다.
• API 트리거 Content Card Campaign을 사용하면 커스텀 이벤트 기록(및 그에 따른 데이터 포인트)을 피할 수 있지만, Campaign마다 별도로 트리거 전송이 필요하고 해당 신호에 대한 이벤트 속성정보 세분화를 사용할 수 없습니다.
• 커스텀 피드는 다음 세션이 시작되거나 requestContentCardsRefresh를 직접 호출하기 전까지는 세션 중간에 새로 고침되지 않습니다. 소비자가 주문 피드를 열거나 당겨서 새로 고칠 때 새로 고침을 호출하세요.
• 완전히 커스텀된 Content Card UI에서는 분석을 직접 기록해야 합니다(노출 횟수, 클릭, 닫기). 기본 피드를 서브클래싱하면 작업량은 줄지만 가로형 캐러셀은 지원되지 않습니다.
• 이 계층 로직은 주문 번호마다 한 번에 하나의 활성 상태만 있다고 가정합니다. 하나의 주문에 여러 상태가 동시에 존재할 수 있다면(예: 창고별 분할 출고), 다른 키(예: 출고 ID)를 추가하고 유지 또는 닫기 규칙에 포함하세요.
• 앱 측 닫기 로직을 적용하려면 새 앱 릴리스가 필요합니다. 프로덕션에 적용하기 전에 개발 워크스페이스에서 테스트하세요.

설정

1단계: 주문 관리 시스템에서 주문 업데이트 기록하기

주문 관리 시스템이 상태 변경을 기록하면 /users/track에 커스텀 이벤트를 보냅니다. Content Card에서 개인화에 사용하고 앱이 extras에서 읽어오는 이벤트 속성정보를 포함하세요.

다음 표는 속성정보 예시입니다.

이메일로 사용자를 식별하는 요청 예시는 다음과 같습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

POST https://rest.iad-01.braze.com/users/track
Content-Type: application/json
Authorization: Bearer {YOUR_REST_API_KEY}

{
  "events": [
    {
      "email": "[email protected]",
      "name": "order_update",
      "time": "2026-09-28T16:02:05Z",
      "properties": {
        "order_number": "12345",
        "order_status": "picked",
        "tracking_url": "https://www.flashandthread.example/track/12345"
      }
    }
  ]
}

워크스페이스의 REST 엔드포인트와 users.track 권한이 있는 API 키를 사용하세요. 샘플 이메일과 주문 값은 주문 관리 시스템의 페이로드로 바꾸세요.

2단계: 주문 상태별로 Content Card Campaign 만들기

보내는 상태마다(예: pending, held, picked, dispatched, cancelled) 실행 기반 Content Card Campaign을 하나씩 만듭니다.

1. 메시징 > 캠페인으로 이동하여 캠페인 만들기를 선택한 다음 콘텐츠 카드를 선택합니다.
2. order_update 커스텀 이벤트에 실행 기반 전달을 설정합니다. 해당 상태만 이 Campaign에 진입하도록 일치하는 order_status 이벤트 속성정보로 필터링합니다.
3. Liquid 이벤트 속성정보를 사용해 카드 제목이나 본문을 개인화합니다.

1

Order {{event_properties.${order_number}}} is {{event_properties.${order_status}}}.

4. 설정 탭에서 새 페어 추가를 선택하고 앱에서 사용하는 키-값 페어를 추가합니다.

다음 표는 계층 예시입니다. 앱은 주문별로 값이 가장 높은 카드를 유지합니다.

5. 카드 만료 기간을 설정합니다(최대 30일). 종료 상태에는 더 짧은 기간을 권장합니다.

대시보드 제거 이벤트는 Campaign 수준에서 적용되므로, 같은 Campaign의 다른 카드는 남겨둔 채 특정 주문의 카드 하나만 제거할 수는 없습니다. 그래서 앱에서 extras를 사용해 오래된 카드를 닫는 것입니다.

3단계: 커스텀 피드에서 주문별 최신 카드 유지하기

커스텀 피드에서 Content Card 업데이트를 구독하고 extras를 읽은 뒤, order_number마다 order_hierarchy가 가장 높은 카드를 유지합니다. 나머지 카드는 플랫폼의 닫기 API로 닫아 분석 데이터가 정확하게 유지되도록 하세요.

피드의 각 카드에 대해 다음을 수행합니다.

1. extras에서 order_number와 order_hierarchy를 읽습니다.
2. 같은 order_number를 가진 카드 중 가장 높은 order_hierarchy를 찾습니다.
3. 카드의 계층 값이 가장 높은 값과 일치하면 카드를 표시합니다(카드 필드를 커스텀 UI 객체에 매핑).
4. 그렇지 않으면 카드를 닫습니다.

플랫폼의 최신 SDK로 구독 및 닫기 호출을 구현하세요. 다음 문서부터 시작하면 됩니다.

• 카드 만들기
• 피드 커스텀하기
• 분석 기록하기

소비자가 이미 앱을 사용 중이라면 requestContentCardsRefresh를 호출하여 다음 세션을 기다리지 않고도 새 주문 카드가 나타나게 하세요.

4단계: 전체 여정을 처음부터 끝까지 테스트하기

1. 같은 주문에 대해 order_status 값이 순서대로 올라가는 order_update 이벤트를 연속으로 보냅니다.
2. 각 상태별 Campaign이 예상한 카드를 보내고 Liquid가 올바르게 처리되는지 확인합니다.
3. 피드에 주문당 카드가 하나만 표시되고 계층 값이 낮은 카드는 닫히는지 확인합니다.
4. 커스텀 UI의 노출 횟수, 클릭, 닫기가 Campaign 분석에 나타나는지 확인합니다.

관련 문서

• Content Card 만들기
• Content Card 키-값 페어 및 동작
• 커스텀 Content Cards 만들기
• Content Card 피드 커스텀하기
• Content Card 분석 기록하기
• POST: 사용자 생성 및 업데이트