동적 콘텐츠를 효율적으로 활용하는 방법: 수정 작업을 줄이는 개인화 캠페인 설계하기
개인화 캠페인을 운영하다 보면 피할 수 없는 수정 요청, 어떻게 더 효율적으로 작업할 수 있을까요? 실무에서 자주 언급되는 사례들을 살펴보며 같은 요청이 캠페인 구조에 따라 어떻게 다르게 처리되는지 비교하고 Liquid, 카탈로그와 같은 동적 콘텐츠를 상황에 맞게 활용하는 방법을 정리했습니다.
CRM 마케팅에서 개인화 캠페인을 설계할 때, 우리는 고객별 특성에 맞춘 메시지를 전달하기 위해 동적 콘텐츠를 자주 활용하곤 합니다.
하지만 짧게는 몇 주, 길게는 몇 개월씩 진행되는 캠페인들은 집행 중에도 여러 크고 작은 수정 요청을 받는 경우가 많습니다. “혜택 메시지 기간이 연장되었어요", "이 고객에게만 안내해 주세요", "이 카테고리만 잠깐 멈춰 주세요"와 같은 요청들은 사소해 보이지만 정교하게 세팅된 캠페인일수록 고칠 곳과 확인할 곳이 함께 늘어나죠.
수정할 부분이 늘어나는 이유는 메시지가 함께 사용하는 정보가 곳곳에 흩어져 있기 때문입니다. 여러 메시지가 동일한 내용을 포함하고 있다면 그 내용이 바뀌었을 때 모든 메시지를 수정해야 하거든요.
이렇게 반복되는 수정 작업을 조금 더 효율적으로 운영하는 방법은 무엇일까요?
이번 글에서는 가상의 패션 커머스 A사의 사례를 통해 동일한 수정 요청이 캠페인 설계 방식에 따라 얼마나 다르게 처리되는지 비교하며 Liquid, 카탈로그와 같은 동적 콘텐츠를 효율적으로 활용하는 방법을 정리했습니다.
수신자(유저)의 속성, 회원 등급, 행동 이벤트 등에 따라 메시지 내용이 자동으로 바뀌어 출력되는 콘텐츠를 말합니다. 노티플라이에서는 Liquid 조건문이나 Connected Content, 카탈로그 기능을 활용해 동일한 메시지 템플릿 안에서도 개인화된 메시지를 보낼 수 있습니다.
1. 수정 작업에서 발생하는 캠페인 운영 비용
패션 커머스 A사는 11월 신발/가방 카테고리 프로모션 기간 동안 구매 전환을 높이기 위해 구매 단계별로 두 개의 앱 푸시 알림 리마인드 유저 여정을 운영하고 있습니다.
상품 조회 리마인드는 상품을 조회하고 1시간 안에 장바구니에 담지 않은 고객에게 관심 상품을 다시 안내하고, 장바구니 리마인드는 24시간 안에 장바구니 상품을 구매하지 않은 고객에게 구매를 유도합니다.
카테고리별로 제공되는 구매 혜택이 다르기 때문에 각 유저 여정의 메시지에 진입 이벤트의 상품 카테고리에 따라 Liquid 조건문으로 혜택 문구를 구분하고 프로모션 종료일을 써 두었습니다.
Liquid 템플릿 기반 메시지 개인화 기본 문법에 대한 자세한 내용은 노티플라이 메시지 개인화 가이드에서 확인하실 수 있습니다.
각 유저 여정에 메시지 노드가 하나씩 있고, 각 메시지 안에 신발과 가방 혜택 안내 메시지가 있으므로 카테고리별 혜택 안내는 총 네 곳에 작성되어 있는 셈입니다. 이 구조로 캠페인을 집행하던 중 기획팀으로부터 다음과 같은 수정 요청을 받게 되었습니다.
"신발 무료배송 혜택을 일주일 연장해 주세요."
이는 단순한 혜택 종료일 수정요청 처럼 들리지만, 실제로 이 내용을 반영하기 위해선 각각의 메시지가 공유하는 내용을 모두 찾아 수정해야 했습니다.
각 유저 여정의 메시지 노드를 열어 신발 혜택 안내에 적힌 종료일 문구를 바꿔야 하며, 종료일에 따라 발송을 멈추는 조건이 있다면 날짜 조건까지 함께 수정해야 하죠.
카테고리별 혜택 내용과 이를 고르는 규칙이 메시지 안에 함께 묶여 있고 같은 혜택이 두 여정에 중복으로 적혀 있다는 점이 A사의 CRM 캠페인 관리를 어렵게 만들고 있었습니다. 수정 요청이 들어올 때마다 작은 변경 사항 하나에도 여러 곳을 확인해야 했어요.
이처럼 처음 세팅할 때는 잘 작동되던 구조라도 운영 과정에서는 번거로움이 발생할 수 있습니다. 그렇다면 반복되는 수정 요청에도 빠르게 대응할 수 있는 캠페인 구조는 과연 어떤 모습이어야 할까요?
2. 운영 효율을 높이는 개인화 메시지 설계하기
2-1. 여러 메시지가 함께 사용하는 정보를 구분합니다
변화에 유연하게 대응할 수 있는 캠페인 구조를 만들기 위해 중요한 것은 공통되는 데이터와 개인화 조건, 발송 조건의 역할을 구분하는 것입니다.
| 구분 | 정의 | A사 예시 |
|---|---|---|
| 공통 데이터 | 여러 메시지가 똑같이 써야 하는 내용 | 카테고리별 혜택 문구, 종료일 |
| 개인화 조건 | 이 고객에게 무엇을 보여줄지, 메시지를 보낼지 판단하는 기준 (Liquid) |
진입 이벤트의 카테고리에 맞는 혜택 선택 |
| 발송 조건 | 누구에게 언제 메시지를 보낼지 판단하는 기준 |
진입 조건, 대기 시간, 이탈 조건 |
메시지가 고객에게 발송되기까지 설정되는 요소들을 나눠서 정리해보면 수정 요청에 따라 함께 관리할 것과 따로 관리할 것을 구분하기 쉬워집니다.
- 함께 관리할 것 [ 공통 데이터 ]
여러 메시지가 함께 사용해야 하는 정보는 한곳에 모아 둡니다. 이렇게 정보를 한곳에 정리해 두면 변경 사항이 생겼을 때 한 번에 반영할 수 있어, 메시지나 여정마다 안내 내용이 달라지는 실수를 줄일 수 있습니다.
- 따로 관리할 것 [ 개인화 조건과 발송 조건 ]
무엇을 보여줄지, 누구에게 언제 보낼지와 같은 조건은 메시지와 여정마다 다를 수 있으므로 구분하여 관리합니다.
이렇게 함께 관리할 내용을 분리해 두면 요청 사항에 따라 수정해야 할 부분이 추려지기 때문에 수정 요청의 성격에 따라 변경할 위치를 빠르게 좁힐 수 있습니다.
2-2. 카탈로그로 공통 데이터를 한 곳에 모아 관리합니다
관리할 요소들을 구분했다면 이제 함께 관리할 공통 데이터를 어디에, 어떻게 모아 두어야 할지 알아보겠습니다. 여러 Liquid문 안에 혜택 문구를 직접 써 두는 방법 대신 혜택 정보를 별도의 표로 빼 두고 메시지가 그 값을 읽어올 수 있도록 정리하는 것입니다. 이때 활용할 수 있는 기능이 카탈로그입니다.
카탈로그는 상품, 매장, 콘텐츠처럼 여러 메시지에서 반복해서 사용하는 참조 데이터를 프로젝트에 저장하는 기능입니다. 유저 속성에 같은 정보를 복제하지 않고, 메시지에서 아이템 ID로 필요한 값을 조회할 수 있습니다.
A사의 경우 카테고리를 ID로 하는 혜택 카탈로그(benefits)를 만들 수 있습니다.
| id | name | benefit_ |
valid_ |
reminder_ |
|---|---|---|---|---|
| shoes | 신발 | 무료배송 | 2026-11-30 | yes |
| bag | 가방 | 적립금 2배 | 2026-11-30 | yes |
카탈로그를 동기화한 후에는 메시지에서 아래와 같이 진입 이벤트의 카테고리 값을 ID로 넣어 카탈로그 데이터를 조회하고, 조회된 값을 문구에 불러옵니다.
{% catalog_items benefits {{ entry_event["category"] }} %}
{% if items.size == 0 or items[0].reminder_enabled != "yes" %}
{% abort_message() %}
{% endif %}
{{ items[0].valid_until }}까지, {{ items[0].name }} 카테고리
{{ items[0].benefit_text }} 혜택이 적용돼요.카탈로그 생성 및 활용에 대한 자세한 내용은 노티플라이 카탈로그 가이드에서 확인하실 수 있습니다.
category 값과 id가 같은 행을 찾고, 맞는 행이 없거나 리마인드 메시지 활성화(reminder_enabled) 값이 “yes”가 아니면 메시지를 보내지 않는 조건을 설정합니다. 조건을 충족한 경우 메시지 노드에 작성된 내용에 따라 종료일, 카테고리명, 혜택 내용이 포함된 메시지가 발송됩니다.
이 방법을 활용하면 카탈로그에 입력된 내용이 두 유저 여정의 메시지에 자동으로 반영되기 때문에 공통 데이터를 한 번에 관리할 수 있습니다. 카탈로그를 수정하면 여러 메시지에 변경된 내용이 동시에 반영되는 것이죠.
3. 카탈로그를 활용하면 수정 작업이 어떻게 달라질까요?
그렇다면 기존 A사의 유저 여정 세팅처럼 혜택 값을 메시지에 직접 작성한 구조와 카탈로그 데이터를 활용한 구조는 실제 수정 업무에서 어떤 차이를 보일까요?
두 구조는 똑같은 메시지를 만들어 내지만, 수정 작업이 필요한 경우 고쳐야 할 범위가 달라집니다. 실무에서 자주 언급되는 수정 요청 사항들을 통해 혜택 값을 메시지에 직접 작성한 구조와 카탈로그에서 불러오는 구조의 차이를 비교해보겠습니다.
3-1. 혜택 내용이나 기간이 바뀌는 경우
"신발 무료배송을 일주일 연장해 주세요" 와 같이 메시지에서 공통으로 활용되는 데이터의 내용이 변경되는 경우 카탈로그 기능을 활용하는 것이 좋습니다.
혜택 값을 메시지에 직접 작성한 구조라면 각 유저 여정의 메시지 노드를 열어 신발 혜택 메시지의 종료일 문구를 수정해야 하며, 종료일에 따른 발송 중단 조건을 미리 설정하지 않았다면 가방 프로모션 종료 시 해당 혜택 안내를 중단하는 작업도 필요합니다.
카탈로그를 참조하는 구조라면 유저 여정을 수정할 필요 없이 카탈로그에서 shoes 행의 종료일(valid_until) 데이터만 수정하면 각 유저 여정의 메시지에 변경된 내용이 반영됩니다. 가방 카테고리 프로모션 역시 종료일에 맞춰 카탈로그의 메시지 발송 활성화(reminder_enabled) 값을 “no”로 수정하면 발송이 중단됩니다.
3-2. 유저 여정 내 특정 카테고리만 발송을 중단하는 경우
"신제품 런칭 기간 동안 가방 리마인드를 잠깐 멈춰 주세요" 처럼 특정 메시지의 발송 여부를 결정하는 경우 카탈로그를 활용하는 것을 권장합니다.
혜택 값을 메시지에 직접 작성한 구조에서 가방 분기의 문구만 삭제하면 빈 문구나 기본 문구로 푸시 알림이 발송될 수 있습니다. 그렇다고 여정 전체를 일시중지하면 신발 리마인드까지 함께 중단되죠. 특정 카테고리만 제외하려는 요청이라면 여정 전체를 멈추는 대신 해당 카테고리의 발송 여부를 제어하는 방식을 활용합니다.
각 유저 여정 메시지의 맨 위에 아래와 같이 발송 중단 조건(abort_message)을 추가합니다. 조건에 해당하면 abort_message()가 해당 메시지의 발송을 중단하는 구조입니다.
{% if entry_event["category"] == "bag" %}
{% abort_message() %}
{% endif %}카탈로그를 참조하는 구조라면 카탈로그의 bag 행에서 리마인드 활성화(reminder_enabled) 값을 “no”로 변경합니다. 메시지에 이미 해당 값을 확인하는 조건이 들어 있기 때문에 카탈로그가 동기화 된 후, 가방 카테고리의 메시지 발송이 자동으로 중단됩니다.
런칭 기간이 끝나면 abort_message() 조건문을 삭제하거나 reminder_enabled 값을 다시 "yes"로 변경해 이후의 메시지 발송을 허용할 수 있습니다.
활성화된 유저 여정 내 메시지를 직접 수정하려면 해당 여정 전체를 잠시 일시중지해야 합니다. 이 과정에서 중단할 필요가 없는 다른 카테고리(예: 정상 작동 중이어야 하는 신발 리마인드)가 영향을 받을 경우를 사전에 방지하기 위함입니다.
카탈로그를 참조하는 구조는 유저 여정을 일시중지하지 않고도 카탈로그의 데이터 값만 수정하면 변경된 내용이 반영되기 때문에 특정 카테고리의 조건만 변경해야 하는 경우 카탈로그 참조 방식을 권장합니다.
4. 혜택 정보를 메시지에 직접 작성할지, 카탈로그로 관리할지 어떻게 판단할까요?
메시지 내용과 연결해 둔 공통 데이터의 값 변경은 유저 여정 수정 없이 카탈로그에서 처리할 수 있습니다. 반면 기존 메시지가 참조하지 않던 필드를 새로 출력하거나, 새로운 개인화 조건과 발송 조건을 추가하려면 메시지 노드의 Liquid문 또는 유저 여정 설정을 수정해야 합니다.
따라서 캠페인을 세팅하는 단계에서 같은 혜택을 여러 곳에서 쓰는지, 운영 중에 혜택이 바뀔 수 있는지를 고려하여 적절한 구조를 선택하는 것이 좋습니다.
활용되는 데이터의 내용이 변경될 일이 거의 없다면 Liquid 조건문만으로도 충분히 개인화된 메시지를 발송할 수 있습니다. 반면 A사처럼 같은 데이터를 여러 메시지에서 사용하고, 프로모션 일정이나 제공되는 혜택이 달라질 수 있다면 카탈로그를 함께 활용하는 것이 좋습니다.
하지만 카탈로그 데이터를 사용한다고 모든 수정이 간단해지는 것은 아닙니다. 카탈로그는 여러 메시지가 함께 참조하는 데이터를 모아둔 곳이기 때문에 해당 값을 어떻게 보여줄지, 어떤 값을 활용할지는 메시지 내용 작성 단계에서 정해두어야 합니다.
위 사례에서 카탈로그의 reminder_enabled 값 하나로 가방 발송을 멈출 수 있었던 것도 메시지 안에 그 값을 읽고 발송을 중단하는 Liquid 조건을 미리 넣어 두었기 때문입니다.
즉, 카탈로그를 활용할 때는 단순히 데이터만 옮겨 두기보다 캠페인 운영 중에 바뀔 가능성이 있는 데이터를 메시지가 미리 읽도록 연결해 두는 것이 좋습니다. 종료일이 연장될 수 있다면 종료일을, 카테고리별로 발송을 멈출 일이 생길 수 있다면 발송 on/off 값을 메시지에 미리 작성해 두는 것처럼요.
① 카탈로그의 값 하나를 바꾸면 그 값을 읽는 모든 메시지가 함께 바뀌기 때문에 카탈로그를 수정하기 전에는 어떤 메시지가 이 데이터를 사용하고 있는지 먼저 확인해야 합니다. 카탈로그를 비활성화할 때도 마찬가지로 연결된 메시지가 더 이상 값을 불러오지 못하게 되니, 참조 중인 메시지가 남아 있지 않은지 확인해주세요.
② 데이터를 수정한 후에는 변경된 값을 참조하는 메시지에서 의도한 내용이 표시되는지, 다른 카테고리의 메시지에는 영향이 없는지 함께 확인해주세요.
마무리
한 메시지에서만 쓰거나 운영 중 바뀔 일이 거의 없는 데이터라면 메시지에 해당 내용을 Liquid문으로 직접 작성하는 것이 더 빠르고 간단할 수 있습니다. 반면 여러 메시지가 함께 사용하고 변경될 수 있는 데이터라면 카탈로그로 모아 관리하는 편이 더 효율적이죠.
지금 우리가 운영 중인 캠페인에 어떤 구조가 맞을지 판단하기 어렵다면, 최근에 진행한 수정 작업 하나를 되짚어 보는 것부터 시작해 보세요. 수정 요청을 처리한 과정을 따라가 보면 같은 정보가 어디에 흩어져 있고 어떤 작업이 반복되는지 확인할 수 있습니다. 특히 같은 내용을 여러 유저 여정이나 캠페인 메시지에서 반복해서 고치고 있었다면 카탈로그를 활용해 데이터를 한 곳에서 관리할 수 있도록 만들어 보세요.
공통으로 활용되는 데이터를 구분하고 수정 가능성을 고려하여 캠페인을 설계해두면 운영 중 반복되는 수정 작업을 줄이고 효율적으로 동적 콘텐츠를 활용할 수 있습니다.
