브레이즈
Team MAXONOMY ・ 2026.10.08
팀맥소노미
YOUR DIGITAL MARKETING HERO
관련 글 보기
일반 코드의 한계를 넘어 개인화된 고유 코드로 브랜드 신뢰를 쌓는 법
스팸 발송자로 오인받게 만드는 '구독 폭발' 방지법부터 reCAPTCHA 활용까지, 이메일 도달률 향상 9가지 팁
지오펜싱부터 서드파티 데이터 연동까지, Braze로 구현하는 위치 기반 마케팅의 모든 것
AI 예측 모델로 고객의 다음 행동을 파악하고, 정교한 타겟팅 기반의 즉각적인 마케팅 액션을 실행하는 방법
Canvas를 운영하다 보면 타겟에 포함된 사용자에게 메시지가 발송되지 않거나, Canvas 진입 수와 실제 발송 수가 달라 당황스러운 경우가 있습니다.
“타겟 조건을 충족한 것 같은데 왜 메시지가 발송되지 않았을까?”
“Canvas에는 진입했는데 Message Step의 발송 수가 더 적은 이유가 뭐지?”
“현재 사용자 프로필은 정상인데, 당시에는 왜 제외된 걸까?”
이런 차이는 오류가 아니라 Canvas가 여러 시점에 서로 다른 조건을 평가하는 과정에서 발생할 수 있습니다. Braze Canvas에서는 사용자가 Canvas에 진입할 때, 각 경로로 분기될 때, Message Step에 도달할 때, 메시지를 실제로 발송할 때 각각 필요한 조건을 확인합니다.
따라서 미발송 원인을 찾을 때는 현재 프로필만 보기보다, 사용자가 어느 단계까지 이동했고 각 평가 시점에 어떤 상태였는지를 순서대로 살펴볼 필요가 있습니다. 이번 포스팅에서는 Canvas 미발송 상황을 네 가지로 나누고, 원인을 빠르게 좁혀갈 수 있는 점검 순서에 대해서 알아보겠습니다.
‘메시지 미발송’이라는 결과는 하나이지만 실제 원인은 크게 네 가지로 나뉩니다.
먼저 Canvas 자체에 진입하지 못한 경우인지, 아니면 Canvas에는 진입했지만 메시지만 발송되지 않은 경우인지를 구분할 필요가 있습니다.
개별 사용자의 Messaging History에 해당 Canvas나 Message Step 기록이 없다면, 메시지 설정을 보기 전에 Canvas 진입 조건부터 확인하면 원인을 더 빠르게 좁힐 수 있습니다.
Canvas의 기본 구조는 진입 시점에만 조건을 확인하고 끝나지 않습니다. Canvas는 사용자를 한 번만 평가하지 않고 사용자가 이동하는 단계마다 필요한 조건을 다시 평가합니다.
전체 흐름은 다음과 같습니다.
여기서 각 단계는 서로 다른 시점에 실행될 수 있습니다. 예를 들어 사용자가 회원가입을 완료하면서 다음 데이터가 거의 동시에 Braze에 전달됐다고 가정해보겠습니다.
회원가입 이벤트가 먼저 처리되어 Canvas 진입 또는 Message Step 평가가 시작됐다면, 해당 시점에는 이메일 주소나 수신 동의 정보가 아직 사용자 프로필에 반영되지 않았을 수 있습니다. 이후 사용자 프로필을 확인하면 이메일과 수신 동의가 모두 정상으로 보일 수 있습니다. 하지만 실제 발송 가능 여부를 평가한 순간에는 필요한 정보가 아직 반영되지 않아 메시지가 발송되지 않았을 수 있습니다.
이벤트와 사용자 Attribute를 거의 동시에 전송하더라도 처리 순서가 항상 동일하게 보장되는 것은 아닙니다. 이벤트 직후의 값을 타겟 조건으로 사용해야 한다면, 필요한 정보를 이벤트 프로퍼티나 Canvas Context Property에 함께 담는 방식도 고려해보세요.
기본적인 항목이지만 실제 문제 해결 과정에서 자주 놓치는 부분입니다. 아래 내용을 먼저 점검해보세요.
Canvas가 중지되면 예정된 메시지는 발송되지 않습니다. 다시 활성화하더라도 이미 예정 시간이 지난 메시지는 발송되지 않으므로, 문제 발생 시점의 Canvas 상태를 Changelog와 함께 확인하는 것이 좋습니다.
Action-Based Canvas에서는 사용자가 트리거 이벤트를 발생시켰더라도, 해당 시점에 타겟 오디언스 조건을 충족하지 않으면 Canvas에 진입하지 않습니다. 일반적으로 다음과 같은 과정을 거칩니다.
트리거 이벤트 발생 → 해당 시점의 타겟 오디언스 및 기타 Entry Eligibility 조건 평가 → Canvas 진입
따라서 트리거 이벤트가 정상적으로 수집되었다고 해서 Canvas 진입이 완료된 것으로 바로 판단할 수는 없습니다. 트리거 발생 시점에 타겟 오디언스, Re-eligibility, Entry Window 등 Canvas 진입 조건을 함께 충족해야 실제 진입이 가능합니다. 특히 아래와 같이 설정한 상태라면 데이터 처리 순서에 따라 Race Condition이 발생할 수 있습니다.
같은 이벤트를 진입 트리거와 타겟 오디언스 조건에 동시에 사용하면, 사용자 프로필의 이벤트 이력이 반영되기 전에 진입 적격 여부가 평가될 수 있습니다. 가능하면 진입 이벤트 자체를 타겟 오디언스에서 다시 확인하기보다 다음과 같이 역할을 분리하는 것을 권장드립니다.
타겟 오디언스와 트리거가 모두 정상이어도 Re-entry나 진입 제한 설정 때문에 사용자가 Canvas에 들어가지 못할 수 있습니다. 다음 항목을 차례대로 확인해보세요.
Canvas의 재진입 가능 여부는 메시지 수신 여부가 아니라 Canvas 진입 이력을 기준으로 관리됩니다. 따라서 사용자가 이전 Canvas에서 메시지를 한 건도 받지 못했더라도, Re-entry가 허용되지 않았다면 다음 트리거 발생 시 다시 진입하지 못할 수 있습니다.
또한 Canvas Control Group에 배정된 사용자는 Canvas에 진입한 것으로 집계될 수 있지만 실제 Variant의 메시지는 받지 않습니다. Entered 수는 있는데 Sent 수가 적다면 Control Group 비율도 함께 확인해야 합니다.
Canvas에 진입한 사용자 모두가 동일한 Message Step에 도달하는 것은 아닙니다. Message Step 진입 수가 0이거나 예상보다 적다면 바로 앞의 Step부터 확인해보세요.
Delay Step
After 1 day는 사용자가 Delay Step에 들어온 시점부터 24시간을 기다립니다. 반면 1 calendar day at 09:00은 다음 달력 날짜의 지정 시간으로 이동합니다. 두 설정은 결과가 달라질 수 있습니다.
Audience Path
Action Path
Decision Split
Canvas를 운영 중에 수정하더라도 이미 특정 Step을 지나갔거나 Message Step 발송 대기열에 들어간 사용자는 변경사항을 적용받지 않을 수 있습니다. 특히 Delay 설정을 수정해도 이미 해당 Delay에 들어온 사용자는 기존에 부여받은 시간 기준을 따릅니다.
따라서 조건을 변경한 후에는 수정 시점 이후 새롭게 해당 Step에 진입한 사용자를 기준으로 결과를 확인하는 것이 좋습니다.
Canvas 미발송 원인을 확인할 때 특히 헷갈리기 쉬운 세 가지 설정입니다. 각 설정은 평가 목적과 시점이 다르므로 구분해서 이해해두면 좋습니다.
예를 들어 다음과 같은 장바구니 이탈 Canvas를 생각해보겠습니다.
타겟 오디언스에 “구매하지 않은 사용자” 조건을 넣는 것만으로는 충분하지 않을 수 있습니다. 해당 조건은 Canvas 진입 시점에 평가되므로, 사용자가 진입 후 Delay 중 구매해도 이미 Canvas 안에 남아 있을 수 있기 때문입니다.
발송 직전 구매 여부를 다시 확인하려면 Message Step의 Delivery Validation에 ‘최근 1일 이내 구매하지 않은 사용자’와 같은 조건을 추가할 수 있습니다. Delivery Validation은 타겟 오디언스나 앞선 Audience Path의 조건을 자동으로 다시 사용하지 않고 Message Step에 직접 추가한 Segment와 Filter만 평가합니다. 조건을 충족하지 않은 사용자를 Canvas에서 Exit시킬지, 다음 Step으로 계속 이동시킬지도 별도로 설정할 수 있습니다.
쉽게 정리하면 Target Audience는 ‘Canvas에 들어올 수 있는지’, Audience Path는 ‘어느 경로로 이동할지’, Delivery Validation은 ‘발송 직전에도 조건을 충족하는지’를 확인하는 설정입니다. 단, Canvas 내 인앱 메시지의 Delivery Validation은 실제 화면 노출 시점이 아니라 사용자가 Message Step에 진입할 때 평가됩니다.
Frequency Capping은 일정 기간 동안 한 사용자에게 발송할 수 있는 메시지 수를 제한하는 기능입니다. Frequency Capping은 특정 Canvas만 따로 계산하는 기능이 아닙니다. Workspace에 설정된 규칙에 따라 여러 Campaign과 Canvas의 발송 이력이 함께 반영될 수 있습니다.
따라서 문제 발생 시점에 다른 Campaign이 발송되지 않았더라도, 사용자가 앞서 받은 메시지로 이미 한도에 도달했다면 메시지가 제한될 수 있습니다. 예를 들어 다음과 같은 규칙이 있다고 가정해보겠습니다.
사용자가 이미 그날 푸시를 2건 받았다면 세 번째 푸시는 발송되지 않습니다. 태그 기반 규칙을 함께 사용한다면 전체 채널 규칙은 통과했더라도 태그 규칙으로 인해 발송이 제한될 수 있습니다. 여러 Frequency Capping 규칙이 동시에 적용될 때는 충족해야 하는 규칙이 함께 평가되므로, 가장 제한적인 조건이 실질적인 발송 한도가 될 수 있습니다. 다음 항목을 확인하여 Frequency Capping을 점검해보세요.
Frequency Capping은 사용자 Local Time Zone의 달력 날짜를 기준으로 계산됩니다. 따라서 “하루 1회”는 반드시 최근 24시간을 의미하지 않습니다. 사용자가 현지 시간으로 오후 11시에 한 건을 받고 날짜가 바뀐 뒤 오전 0시에 다시 한 건을 받을 수도 있습니다.
또한 Frequency Capping으로 메시지가 발송되지 않아도 사용자는 일반적으로 Canvas의 다음 Step으로 계속 이동합니다.
Quiet Hours는 사용자의 Local Time Zone을 기준으로 특정 시간대의 메시지 발송을 제한합니다.
설정에 따라 Quiet Hours에 도달한 메시지는 다음 두 가지 방식으로 처리될 수 있습니다.
예를 들어 Quiet Hours가 오후 9시부터 다음 날 오전 8시까지이고, 사용자가 오후 10시에 Message Step에 도달했다고 가정해보겠습니다. Send at next available time으로 설정했다면 메시지는 다음 날 오전 8시 이후 발송될 수 있습니다. 반면 Abort message로 설정했다면 해당 메시지는 발송되지 않습니다. Quiet Hours를 확인할 때는 다음 사항을 함께 살펴보세요.
Quiet Hours, Frequency Capping, Rate Limiting은 서로 독립적으로 적용됩니다. Frequency Capping을 통과한 메시지도 Quiet Hours에 의해 보류되거나 중단될 수 있고, Quiet Hours가 종료된 메시지는 다시 Rate Limit의 영향을 받을 수 있습니다.
개인화 메시지에서는 필요한 데이터가 없을 때 잘못된 메시지를 보내지 않도록 Liquid의 abort_message()를 사용하는 경우가 많습니다. 예를 들면 다음과 같습니다.
{% if recommendations == blank %}
{% abort_message('recommendations_missing') %}
{% endif %}
이런 경우 다음과 같은 상황에서 메시지가 취소될 수 있습니다.
Liquid는 사용자가 Canvas에 처음 진입했을 때가 아니라 Message Step에서 메시지를 렌더링하는 시점에 평가됩니다. 따라서 Canvas 진입 당시 데이터가 존재했더라도 발송 시점에 값이 삭제됐거나 변경됐다면 Abort될 수 있습니다. 반대로 진입 시점에는 값이 없었지만 발송 전에 정상적으로 업데이트됐다면 발송될 수 있습니다.
abort_message()를 사용할 때는 반드시 사유를 함께 남기는 것을 권장드립니다.
Abort 사유를 구체적으로 작성하면 Message Activity Log에서 원인을 더 빠르게 구분할 수 있습니다. 사유를 작성하지 않으면 {% abort_message %} called와 같이 표시되어 어떤 조건에서 중단됐는지 파악하기 어려울 수 있습니다.
Liquid로 Abort된 메시지는 발송 및 Delivery에 포함되지 않으며 Frequency Capping 횟수에도 포함되지 않습니다. 사용자는 해당 메시지를 받지 않지만 Canvas의 다음 Step으로는 계속 이동합니다.
Canvas 인앱 메시지는 푸시나 이메일처럼 Message Step에 도달하는 즉시 사용자 기기로 발송되는 구조와 다릅니다. 일반적으로 사용자가 다음 조건을 충족해야 인앱 메시지가 노출됩니다.
Action-Based Canvas에 사용자가 현재 Session 도중 진입했다면, 해당 Session에서는 인앱 메시지가 활성화되지 않고 다음 Session부터 노출 가능해질 수 있습니다. 또한 Canvas 내 인앱 메시지에는 다음 기능이 적용되지 않습니다.
따라서 인앱 메시지 미노출을 Frequency Capping이나 Quiet Hours 문제로 판단하기보다 다음 항목을 먼저 확인하는 것이 좋습니다.
인앱 메시지는 일반 채널의 Sent보다 실제 노출을 의미하는 Impression을 중심으로 확인해야 합니다.
도구마다 확인할 수 있는 정보와 보관 기간이 다릅니다. 먼저 조사 목적을 정한 뒤 알맞은 도구를 선택하면 원인을 더 빠르게 찾을 수 있습니다.
(Audience > Search Users > 사용자 프로필 > Messaging History)
Messaging History에서는 최근 30일 동안 해당 사용자의 메시지 발송·수신·반응 이력을 확인할 수 있습니다. 최근 메시지 관련 이벤트 약 40개가 표시되므로, 정확한 발생 시간을 기준으로 조사하는 것이 좋습니다. 다음 항목을 확인해보세요.
Messaging History에 예상 시점의 기록이 전혀 없다면 메시지 전송 오류보다 먼저 Canvas 진입, Path 분기, Delay를 확인해야 합니다.
Messaging Diagnostics는 Canvas와 Campaign의 발송 결과를 원인별로 나누어 확인할 수 있는 대시보드입니다.
예를 들어 Message Step에 10만 명이 들어왔지만 실제 발송이 7만 명이라면, 나머지 3만 명이 어떤 사유로 제외됐는지 집계 수준에서 빠르게 확인할 수 있습니다.
(Settings > Setup and Testing > Message Activity Log)
다음과 같은 기술적 오류를 확인할 때 유용합니다.
Liquid Abort가 발생했다면 Message 컬럼에 설정한 Abort 사유가 표시됩니다. 다만 Message Activity Log는 최근 60시간의 오류만 확인할 수 있으며, 같은 Campaign이나 Canvas Step에서 동일한 오류가 대량 발생하면 일부 샘플만 저장될 수 있습니다. 또한 모든 미발송 원인이 Message Activity Log에 나타나는 것은 아닙니다.
따라서 문제가 발생했다면 가능한 한 빠르게 로그를 확인하고, 필요한 경우 화면을 캡쳐해두는 것이 좋습니다.
사용자 프로필의 현재 상태만으로 당시의 결과를 설명할 수 없다면 Changelog를 확인해야 합니다. 다음과 같은 변경사항이 있었는지 살펴보세요.
운영 중인 Canvas를 수정하면 이미 특정 Step을 통과했거나 발송 대기열에 들어간 사용자에게 변경사항이 동일하게 적용되지 않을 수 있습니다. 따라서 변경 전후의 사용자를 한꺼번에 비교하기보다 Canvas Version과 Changelog를 기준으로 사용자 평가 시점을 나누어 확인하는 것이 좋습니다.
일부 유저가 메시지를 수신하지 못했습니다. 이들은 현재 프로필 기준으로는 Segment에 포함되어있지만, Canvas 진입 또는 발송 당시의 Attribute는 다른 값이며, 운영 중 Segment 조건도 한 차례 수정된 이력이 있습니다.
Canvas는 과거 시점의 조건을 현재 프로필로 다시 계산하지 않습니다. 사용자 평가 당시 조건을 충족하지 않았거나, 이미 분기를 통과한 뒤 설정이 변경됐을 수 있습니다.
다수 사용자가 Frequency Capped로 제외됐습니다. 하지만 해당 시간대에는 다른 메시지를 발송하지 않았습니다.
Frequency Capping은 같은 시간대의 메시지만 비교하지 않습니다. 사용자의 과거 수신 이력을 누적하여 계산하므로, 해당 사용자가 앞서 받은 Campaign과 Canvas 메시지 때문에 제한에 도달했을 수 있습니다.
Action-Based Canvas에 정상 진입했고, Message Step 진입 수도 정상이지만 일부 사용자에게 메시지가 발송되지 않았습니다.
사용자의 Local Time Zone 기준으로 Quiet Hours에 해당했고, Fallback이 Abort message로 설정됐을 수 있습니다.
Message Step 진입자는 많지만 실제 발송자는 이보다 훨씬 적습니다. 개인화 콘텐츠에 Catalog 또는 외부 API 사용하였습니다.
일부 사용자에게 필요한 상품·쿠폰·추천 데이터가 없는 경우, Liquid 조건에서 데이터가 없는 사용자를 abort_message()로 중단했을 수 있습니다.
Canvas에서 메시지가 발송되지 않았더라도 시스템 오류라고 단정할 필요는 없습니다. 사용자가 Canvas에 진입하지 못했거나 다른 경로로 이동했을 수 있고, 발송 시점에 채널 수신이 불가능했을 수도 있습니다. 또는 Frequency Capping, Quiet Hours, Delivery Validation, Liquid처럼 의도한 발송 제어 조건이 정상적으로 적용된 결과일 수도 있습니다.
다소 복잡해 보이지만 아래 세 가지 기준으로 점검하면 원인을 한층 쉽게 좁힐 수 있습니다.
가장 중요한 점은 현재 사용자 프로필만으로 과거의 발송 결과를 판단하지 않는 것입니다. Canvas 진입, Path 분기, Message Step 도달, 실제 발송 시점의 조건을 각각 나누어 확인해보세요. 사용자의 이동 경로와 당시 상태를 시간순으로 맞춰보면 복잡한 미발송 문제도 훨씬 명확하게 이해할 수 있습니다.
아닙니다. Canvas에 진입한 후에도 사용자는 여러 Path와 Delay를 거칠 수 있으며, Message Step에 도달한 뒤에도 채널 수신 가능 여부, Subscription Settings, Delivery Validation, Frequency Capping, Quiet Hours, Liquid 조건 등에 따라 발송되지 않을 수 있습니다.
일반적으로는 멈추지 않습니다.Frequency Capping, 채널 수신 불가, Liquid Abort 등으로 메시지가 발송되지 않더라도 사용자는 다음 Step으로 계속 이동합니다.Delivery Validation 미충족 사용자는 설정에 따라 Canvas에서 Exit시키거나 다음 Step으로 이동시킬 수 있습니다. 따라서 다음 Step 진입자를 “이전 메시지를 실제로 받은 사용자”로 간주해서는 안 됩니다. 반드시 메시지 수신 여부가 중요하다면 별도의 Audience Path나 메시지 수신 이력 조건을 추가하는 것이 좋습니다.
Canvas는 현재 사용자 프로필을 기준으로 과거의 진입·분기·발송 결과를 다시 계산하지 않습니다.
당시에는 다음 중 하나였을 수 있습니다.
사용자 Messaging History, Attribute 업데이트 시간, Canvas Changelog를 함께 확인해야 합니다.
특정 사례를 조사하려면 최소한 다음 정보를 준비하는 것이 좋습니다.
시간은 [2026-08-31T09:30:00+09:00]과 같이 Time Zone을 포함한 ISO 8601 형식으로 정리하면 혼선을 줄일 수 있습니다.
Canvas 관련 진단 정보는 최근 30일 범위 내에서 확인 가능한 경우가 많으므로, 문제가 발생하면 가능한 한 빠르게 조사하고 문의하는 것이 좋습니다.
브레이즈, 자동화, 메시징, SMS, API, 이메일, 인앱/인웹 메시지, 푸시알림
