마케팅 타깃팅 툴 BUDS 제작기, 탄생부터 수출 역군이 되기까지

Jun.11.2024 윤혜상

Data PM

1.BUDS란?

개인화 마케팅을 들어보셨나요? 개인화 마케팅은 고객의 특성과 선호도를 반영하여 맞춤형 메세지와 경험을 제공하는 마케팅 전략입니다. 맞춤형 메세지와 경험을 고객에게 전달하려면 특정 조건을 가진 고객을 타깃팅 할 수 있어야 하는데요, 이 때 활용하는 것이 BUDS입니다.
BUDS는 쿼리 작성 없이 클릭만으로 원하는 고객 집단(이하 세그먼트)을 찾아 저장하고 업무에 활용할 수 있도록 지원합니다.

아래 이미지와 같이 고객을 필터링 할 기준이 될 데이터 항목(대표주소, 최근 1주 주문 카테고리)을 선택하고 값(경기도, 치킨)을 입력하면, 경기도에 살면서 최근 1주일 내에 치킨을 주문한 고객을 찾아 그 수와 분포를 확인하고 업무에 활용할 수 있습니다.
이전에는 이렇게 특정 조건을 가진 고객을 찾고자 할 때 SQL을 작성해야만 했고, 이 부분의 진입장벽이 높았습니다. BUDS는 이것을 효율화 하기위해 개발 되었습니다.

BUDS란 Baemin User Data System의 약자이자, 새싹(bud)의 의미를 가지고 있습니다. 새싹같은 데이터를 잘 가꾸고 키워서 크게 활용하자는 뜻입니다.
BUDS의 기반이 되는 데이터는 CDP(Customer Data Platform)로, 고객을 정의하는 수백 개의 데이터 항목(attribute)을 포함합니다.
최근 BUDS는 우아한형제들의 모회사인 DH그룹 내에서 타깃팅 영역에서의 기술 우위를 인정 받아 글로벌 수출 작업을 진행 중입니다. 곧 전 세계 계열사에서 타깃팅 작업을 할 때 BUDS를 엔진으로 사용하게 됩니다.

2.BUDS는 어떻게 시작되었나요?

마케팅을 효율화 해보자

BUDS를 기획할 당시, 사내에는 너무 많은 마케팅 어드민들(Push 어드민, SMS 어드민, 쿠폰 어드민 등)과 수기로 해야만하는 작업들이 존재했습니다. 어드민들을 통합하거나 수작업을 자동화 하는 것이 꼭 필요했습니다. 그리하여 "마케팅 효율화" 과제가 시작되었습니다.
과제 구체화를 위해 마케터들을 만나 인터뷰를 진행하고, 업무 미팅을 참관하고, 기존 자료들을 공유받아 분석하며 현황 파악을 시작했습니다.
마케팅은 크게 3가지 프로세스로 구분할 수 있었습니다.

  1. 고객 분석 및 타깃팅
  2. 캠페인(Push, SMS, 쿠폰 등) 설정 및 실행
  3. 결과 분석 및 리타깃팅

전체 프로세스를 한 번에 다룰 수는 없기 때문에, 가장 비효율적인 부분부터 접근하기로 합니다.
그렇게 1번 ‘고객 분석 및 타깃팅’ 영역의 효율화로 과제를 구체화했습니다.

타깃팅을 효율화 해보자

타깃팅은 특정 조건을 가진 고객 집단을 찾는 과정입니다. 고객에게 필요한 메세지만 전달해 피로도를 관리하고, 메세지 발송에 드는 비용을 최적화하기 위해 타깃팅을 하고 있습니다.
타깃팅 영역에서 발견한 문제점은 크게 두 가지가 있었습니다.

  • SQL로 고객을 분석하고 타깃을 추출하는 것이 어렵고 오래걸린다.
  • 타깃 추출 후에도 수동으로 파일을 다운로드해 유관 시스템(쿠폰 어드민, Push 어드민 등)에 업로드해서 사용하는 것이 번거롭다.

SQL은 학습하는 데 시간이 오래 소요되어, 마케터들이 마케팅 시나리오에 대한 고민을 하기보다 SQL 공부와 검토에 시간을 많이 할애하고 있었습니다.
동료에게 복잡한 SQL문을 전달받아 수정해 사용하는 경우 발생하는 오류도 많았습니다.
파일을 로컬 PC에 다운로드하고 다른 시스템에 업로드하는 과정에서도 오류가 발생하고 잠재적 보안 이슈가 있었습니다.

그래서 도출한 목표는 다음과 같습니다.

  • SQL을 사용하지 않고도 누구나 쉽고 빠르게 고객을 분석하고 타깃팅 해 업무에 활용할 수 있도록 하는 것

기대효과로는 4시간 이상도 소요되던 SQL 작성 및 검토 과정을 1분 내로 가능하도록 효율화하고, 각종 오류와 보안 이슈를 없애는 것이었습니다.

3.BUDS를 만드는 과정

BUDS는 앞서 소개드린 것처럼 고객을 정의하는 데이터 항목(attribute)을 포함하는 CDP(Customer Data Platform, 고객 데이터 플랫폼)와 BUDS 화면 두 가지를 동시에 구축해야 했습니다.

CDP(Customer Data Platform, 고객 데이터 플랫폼)


기본 컨셉은 마케팅에서 자주 사용하는 데이터(고객의 대표주소, 메세지 수신 동의 여부 등)를 미리 집계해두고 빠르게 꺼내 쓸 수 있도록 하자, 였습니다.
기존에 없던 새로운 시스템을 만드는 것이었기 때문에, 마케터들에게 "이런이런 시스템을 만들건데 어떤 데이터 항목이 있으면 좋을 것 같으세요?" 하고 묻는 방식으로 접근하면, 서로의 이해 수준이 달라 효과적이지 못한 의사소통이 됩니다.
그래서 "이 중에 필요한 데이터가 있겠지" 하는 마음으로 위키, 슬랙 등을 참고한 500개의 데이터 항목 초안을 기획하고 인터뷰를 통해 구체화를 진행했습니다.

이후 각 데이터 항목마다 type(문자형, 숫자형, 날짜형…)과 type 마다 사용할 수 있는 연산자(다음과 같음, 큼, 두 값 사이에 있음…)를 정의하고, 3뎁스(주문>최근1주>주문건수)로 항목들의 taxonomy를 구조화 해 프론트에 연계되도록 했습니다.
데이터 엔지니어와는 Data lake > Data Warehouse > Data Mart로 이어지는 파이프라인을 구축하고, 데이터 항목들을 집계해 저장한 후, ElasticSearch를 통해 BUDS로 데이터를 전송해서, 서버에서 데이터 항목을 조회할 수 있도록 했습니다.

BUDS(Baemin User Data System)

BUDS는 CDP 데이터를 활용해, 클릭 기반으로 특정 조건을 가진 고객을 타깃팅 할 수 있도록 합니다.
고객을 찾을 필터로 사용할 데이터 항목(대표주소)을 선택한 후, 연산자(다음과 같음)와 값(경기도)을 입력하면, 하나의 조건(대표주소=경기도)이 완성됩니다.
이런 조건들을 여러 개 추가 및 조합해서, 그 조건 조합에 해당하는 고객을 찾는 구조입니다.

화면을 기획할 때는 상용 툴인 Braze, Amplitude, Salesforce 등을 벤치마킹 했습니다.
디자이너, 프런트엔드, 백엔드 개발자들과 소통을 원활하게 하기 위한 수준의 피그마 와이어프레임을 그려 작업을 진행했습니다.

CDP와 BUDS의 합체

약 5개월간 효율적인 작업을 위해 2 트랙으로 나누어 개발을 진행했습니다. CDP 개발은 저와 데이터 엔지니어끼리, BUDS 개발은 저와 디자이너, 프런트엔드, 백엔드 개발자끼리 작업하고 마지막 1개월동안 합체 작업을 진행했습니다.
CDP에서 ElasticSearch까지 전송해둔 데이터를 BUDS 화면에 붙이는 작업이었고, 이 단계까지 마무리하며 BUDS MVP(Minimum Viable Product)1을 오픈하게 됩니다.
마케터들은 이제 타깃팅을 할 때, 긴 쿼리를 작성할 필요 없이 클릭 몇 번 만으로 고객을 찾을 수 있게 되었습니다.
예시로, 아래 이미지와 같이 타깃팅을 할 경우 Push 수신에 동의하고 최근에 배민클럽 관련 배너에 관심을 가졌으며 주문도 많이하는 고객을 찾을 수 있습니다.

MVP1 이후

MVP1으로 클릭 기반의 타깃팅이 가능해진 후에는 기능 고도화와 도메인 확장 작업을 진행했습니다.

  • 기능 고도화
    시스템 연동 > 쿼리 세그먼트(아래 설명 예정) > 스케줄링 > 분석 기능

  • 도메인 확장
    배민 > 라이더 > 사장님 > 글로벌수출

4.BUDS를 만들면서 어려웠던 부분

BUDS의 목표는 앞서 말씀드린 것처럼 "SQL 없이도 누구나 쉽고 빠르게 고객을 분석하고 타깃팅 할 수 있는 것" 이었는데요, 오랫동안 SQL 기반으로 일을 해 온 여러 부서들의 모든 요건을 CDP 데이터로만 대응하기는 어려웠습니다.

  • 그래도 쿼리를 써야겠어요, 근데 쿼리로 추출한 고객 리스트를 BUDS에 세그먼트로 저장하고 싶어요.
  • 쿼리로 만든 세그먼트도 시스템연동, 스케줄링 같은 기존 BUDS 기능들을 쓰고 싶어요.
  • 쿼리로 만든 세그먼트랑 BUDS의 일반 세그먼트를 조합해 사용할 수 있었으면 좋겠어요.

이런 추가 요건들이 계속 생겨난 데 더해, 회사 보안 정책의 강화로 마케터들이 쿼리 결과를 파일로 다운로드해 활용하는 것이 불가능해지면서, 쿼리를 이용한 타깃팅도 BUDS를 통해야 하는 상황이 굳혀졌습니다.

뭐가 어려운 점이냐면

쿼리를 실행해 나온 결과를 세그먼트로 저장하고, 그 세그먼트(이하 쿼리 세그먼트)가 BUDS의 기능들을 사용할 수 있게 하려면, 기존에 BUDS에서 CDP 데이터를 조합해 만든 세그먼트(이하 일반 세그먼트)와 저장 구조가 같아야 하는데, 그럴 수 없는 문제가 있었습니다. 그래서 솔루션을 찾기 위해 개발자들과 많은 논의를 거쳐야 했습니다.
두 세그먼트 종류의 차이점은 아래와 같습니다.

  • 일반 세그먼트 : BUDS에서 CDP 데이터 항목을 이용해 조건을 생성하고 만든 세그먼트. 세그먼트 정보로 고객id 리스트가 아닌 조건(최근 1주 주문 카테고리 = 치킨)을 저장한다. 하루에 한 번 CDP 데이터가 업데이트 되면 저장한 조건을 만족하는 새로운 고객id 리스트를 조회 및 추출한다. 그래서 어제와 오늘 같은 일반 세그먼트에 속한 고객id 리스트는 다를 수 있다.
  • 쿼리 세그먼트 : BUDS는 사용자가 사내 쿼리 실행 시스템(제플린 노트북)에 미리 작성해둔 쿼리문을 불러와 실행하고, 결과로 나온 고객id 리스트를 저장한다. 고정적 정보를 저장하기 때문에 시간이 흘러도 쿼리 세그먼트에 속한 고객id 리스트는 변하지 않는다.

이 둘의 저장 구조를 통일하는 것이 규모가 큰 작업이고, 통일할 경우에도 세그먼트 조회 때마다 리소스가 많이 소요되며 성능도 좋지 않는 문제가 있어서, 세그먼트 종류를 둘로 나누어 관리하기로 결정합니다.

어떻게 해결했냐면

둘의 저장 구조를 통일하지 않고 나누어 관리하기 위해서 아래와 같은 결정을 했습니다.

  • 일반 세그먼트와 쿼리 세그먼트를 각각 다른 테이블에 분리해 저장하고, 시스템연동과 같은 연계 기능도 따로 관리하기로 했습니다.
  • 두 종류 세그먼트의 생성 방식, 조회 방식이 완전히 다르기 때문에, 사용자가 혼란스럽지 않도록 화면도 분리 개발해 제공하기로 했습니다.

모두 분리해 관리하지만, 특정 캠페인의 타깃이 된 고객을 찾아 리타깃팅 하거나, 세그먼트 간 비교를 하거나, 이미 타깃이 됐던 고객을 다음 캠페인에서 제외하는 등의 요건을 반영하기 위해서는, 두 종류의 세그먼트를 같이 활용할 수 있는 방법을 동시에 마련해야 했습니다.

  • 두 종류의 세그먼트가 각각 저장하는 정보가 다르기 때문에 바로 같이 연산(join) 할 수는 없어서, 쿼리 세그먼트를 일반 세그먼트로 변환할 수 있는 방법을 고안했습니다. 특정 쿼리 세그먼트에 속한 고객id 리스트를 조회하고, CDP 데이터 항목(attribute)으로 다시 제공하는 방법을 채택했습니다.
    마케터들은 아래 이미지와 같이 특정 쿼리세그먼트 번호에 속했던 고객을 찾는 조건을 추가해 일반세그먼트를 생성 할 수 있게 되었습니다.

처음부터 이 기능까지 고려하고 설계했다면 더 좋은 구조로의 개발이 가능했을텐데 하는 아쉬움이 있지만, 프로덕트 컨셉(SQL없이 가능하게 하는)에 정반대되는 요건을 나중에 급하게 품은 것 치고 솔루션을 잘 찾았다고 생각합니다.

5. 다양한 방향으로 계속해서 발전하는 BUDS

BUDS는 그동안 많은 성과를 내왔습니다. 2022년에 올해의 프로젝트로 선정되었는가 하면, 2023년에는 모회사인 DH 그룹에서 기술 우위를 인정받아 글로벌 수출이 확정되었습니다.
가장 뿌듯한 순간은 동료 마케터들에게 "만들어줘서 고맙다"는 말을 전달 받을 때입니다. 현재 BUDS는 매 주 150여 명의 마케터들이 2천여 건의 유의미한 트래픽을 일으키는 전사 공통 타깃팅 툴로 자리 잡았습니다.

BUDS는 다양한 과제들을 앞두고 있습니다. 배치 데이터의 실시간화, 글로벌 수출 과제와 더불어 AI 기술의 접목도 계획 중입니다. 현재의 클릭 기반 소통 방식에서 프롬프트를 이용한 대화형 방식으로의 변경을 염두에 두고 Text-To-SQL 연구를 함께 진행 중입니다.