마케팅 Life Time Value (LTV) 예측 프로젝트: Stage 1

진행 기간: 2021.01 ~ 2022.02

프로젝트 소개

효율적인 마케팅 예산 집행을 위해 캠페인 별 평생 가치(LTV)를 예측하는 프로젝트. 자세한 문제 상황은 LTV 전체 설명 문서에 적혀 있습니다.

Stage 1 목적

Stage 1에서의 주요 목적은 기존 코드 및 대시보드의 유지보수입니다.

LTV 예측 프로젝트는 제가 입사한 2021년 이전부터 오랫동안 연구가 이어진 오래된 프로젝트로, 이미 LTV 예측값을 통해 마케터가 캠페인의 성과를 판단하는 프로세스가 어느 정도 정립된 상황이었습니다. 그렇기 때문에 주 목표는 예측 모델이 잘 작동할 수 있도록 데이터 파이프라인 및 모델 코드를 관리하는 것이었습니다.

서비스 형태

마케터는 두 가지 방식으로 LTV 예측값을 제공받았는데, 하나는 대시보드, 하나는 jupyter notebook 형태의 코드였습니다.

1. 대시보드

국가 단위의 큰 코호트 별 LTV를 주기적으로 확인하는 용도.

• 캠페인 집행 전 국가 별, 매체 별 LTV 트렌드를 모니터링 합니다.
• 이를 기반으로 캠페인 집행 시 국가, 매체 별로 예산 배분을 결정합니다.
• mode analytics 라는 BI (Business Intelligence) 도구를 활용해 대시보드를 제작, 관리, 조회할 수 있습니다.

2. jupyter notebook 코드

캠페인 집행을 지속할지 판단하기 위한 용도.

• 주어진 예산 하에서 캠페인을 지속할지 여부를 판단하기 위해, 캠페인 별 LTV 예측값과 마케팅 비용을 비교해서 예측 ROAS (Return On Ad Spend)를 계산합니다.
• 예측 ROAS가 일정 기준 이하인 캠페인을 중단함으로써, 효율적인 예산 집행이 가능해집니다.

배포 방식

1. 데이터 인프라 설명

• airflow 기반 데이터 파이프라인: LTV DW에 데이터 적재 배치 잡
• AWS S3, Glue: LTV를 비롯한 DW (Data Warehouse) 데이터 저장 및 관리
• jupyterhub: 마케터 및 데이터 과학자가 jupyter notebook을 실행시킬 파이썬 환경

데이터 파이프라인은 데이터 엔지니어 팀에서 관리하는 airflow 인스턴스에서 배치 잡 형태로 주기적으로 실행됩니다. 배치 잡은 AWS S3와 Glue에 저장된 DW 데이터를 읽어와 LTV 예측에 필요한 형태로 가공한 뒤, 다시 S3/Glue에 적재합니다.

2. 코드 배포

• airflow: LTV 배치 잡을 정의하는 코드를 직접 수정했고, prod 환경 배포는 데이터 엔지니어 팀이 담당했습니다.
• jupyter notebook: jupyterhub 내에 노트북 파일을 직접 업로드하거나, google drive 등을 통해 공유했습니다.

운영 및 유지보수 업무

• airflow 배치 잡 장애 대응
• 대시보드 시각화 개선 (SQL, 대시보드 디자인)
• jupyter notebook 코드 유지보수
• 마케터 대상 jupyter notebook 활용법 가이드 및 트러블슈팅 지원
• LTV 관련 ad-hoc 분석/시각화

모델링 (BTYD 모델 + MCMC 시뮬레이션)

• 문제 설정: 한 코호트의 7일 간 평균 데이터를 바탕으로, 365일 간의 평균 LTV 예측
• 모델링: BTYD (Buy Till You Die) 확률 모델 기반으로 MCMC 시뮬레이션 수행
• 입력 데이터: 코호트 별 7일 간 유입 유저 수, 매출, 이탈 유저 수
• 출력: 코호트 내 유저들의 365일 평균 LTV 예측값

자세한 모델링 설명은 LTV MCMC 모델 설명 문서에 작성했습니다.

회고

이 시기 동안 모델링 자체는 개선한 부분이 없었지만, 아직 python 및 소프트웨어 엔지니어링에 대해 배워나가는 시기였기 때문에 핸즈온으로 여러 작업들을 하면서 새로 배운 것들이 많았습니다.

• 코드 버전 관리를 잘해야 코드의 의도를 파악하기 쉽다:
  • jupyter notebook 형태의 코드는 google drive 에 저장되어 있어 버전 관리가 어려웠습니다.
  • 또한 airflow 배치 잡을 위한 코드는 데이터 엔지니어들이 관리하는 별도의 레포에서 관리되어 이원화되는 문제가 있었습니다.
  • 기존의 코드에서 복잡한 비즈니스 로직이 추가/변경되면서 코멘트를 계속 추가하는 방식으로 작성되어 있었는데, 이를 git 같은 도구로 관리했으면 훨씬 추적이 쉬웠을 것 같습니다.
• 모델 운영 및 유지보수의 중요성:
  • 모델을 개발하는 것도 중요하지만, 결국 이 모델이 꾸준히 활용되고 가치를 만들기 위해서는 잘 돋보이지 않는 운영과 유지보수가 필요하다는 것을 꺠달았습니다.
  • 또한 구체적으로 어떤 운영, 유지보수 작업이 필요한지 배운 시기였습니다.
• 개발 환경 세팅은 개발 속도에 큰 영향을 끼친다:
  • MCMC 모델을 구성하기 위해 pymc3 라는 라이브러리를 사용했는데, numpy, pandas, theano 등 여러 라이브러리와의 디펜던시가 엮여있어 환경이 조금 달라질 때마다 어려움을 겪었습니다.
  • 게다가 개발 환경과 서빙 환경이 크게 다르다는 문제도 있었습니다. 데이터 과학자가 개발하기 위한 클러스터, airflow 배치 잡이 실행되는 환경, 마케터가 사용하는 클러스터, 이 셋 모두 각각의 권한과 python 환경이 달라 문제가 생겼습니다.
  • 지금이라면 Docker 컨테이너 등을 통해 최대한 환경을 비슷하게 맞추려는 노력을 하거나, 최소한 python 환경이라도 고정시키기 위한 시도를 했을 것 같습니다.
• 코드를 목적성에 맞게 잘 분리해야 이해가 쉬워지고, 변경도 쉬워진다:
  • jupyter notebook 으로 제공하던 코드는 복잡한 비즈니스 로직이 많이 포함돼 있어, 시뮬레이션을 실행하는 함수 하나가 지나치게 길어져 가독성이 떨어졌습니다.
  • 이 때문에 문제가 생겼을 때 디버깅하기도 어려웠고, 새로운 기능을 추가하는 것도 제한적이었습니다.
  • 또한 가독성으로 인해 코드 자체를 이해하기 어려워지는 것도 코드 개선 작업에 부담을 주는 큰 요인 중 하나였습니다.
  • 이 때의 경험을 통해, 이후의 프로젝트에서는 각 역할에 따라서 코드를 구조화하고 그에 따라 함수를 쪼개거나 모듈화하면서 작업하게 되었습니다.
  • 또한, 비즈니스 로직은 반드시 타 모듈에 존재하는 함수나 클래스를 호출하는 형태로 만들어, 비즈니스 로직 자체를 최대한 분리하는 방향으로 코드를 작성하는 게 좋은 패턴이라는 것을 이해하게 되었습니다.
• 유저의 편의를 고려한 서빙 역시 중요하다:
  • python 자체에 익숙하지 않은 마케터에게 jupyter notebook 형태의 코드를 제공하는 것은 최선의 방법은 아니었던 것 같습니다. 최대한 개발 공수가 적은 방향으로 서빙하려다 보니 어쩔 수 없는 부분이었던 것 같습니다.
  • 특히 많은 데이터를 대상으로 시뮬레이션할 경우 시간이 오래 걸리기 때문에, 노트북을 실행하는 동안 웹브라우저 사용이 불편해지는 문제가 제일 컸습니다.
  • 이를 해결하기 위해 이후 프로젝트에서 웹서비스의 형태로 개발하는 시도도 해봤으나, 프로토타입 수준 이상의 서비스를 개발하기에는 한계점을 느낄 수 있었습니다.
    • 참고: LTV Stage 3
• 결과 재현성은 더 발전된 모델링을 위해 필수적이다:
  • MCMC의 특성 상 랜덤성을 제어하지 않으면 매번 실행할 때마다 결과가 달라집니다.
  • 이 때문에 문제가 생겼을 때 디버깅 과정에서 맞게 나온 결과인지 확인하려면 많은 노력이 필요했습니다.
  • 이전의 결과와 비교하고 싶을 때도 제한적이었습니다.
  • 모델링의 결과를 과학적으로 분석하고 평가하기 위해서 결과를 다시 재현할 수 있는 것이 중요하다는 것을 깨달았습니다.