마케팅 푸시 서버 구축기 1탄 -마케팅 푸시 알람의 꽃!! 데이터!!

어느 앱을 만드는 스타트업 이야기이다. 어느날 마케터가 서버 개발자에게 찾아왔다. 그녀는 똘망똘망한 눈을 하며 말했다. "특정 앱버젼을 지닌 한국인에게만 ios,android 기기에게 app push(앱 푸시)를 보내고 싶어요!" 물론 fcm을 사용하고 있었지만 그녀는 그것보다 더욱 세밀한 푸시를 보내고 싶어했다. 그녀의 말을 들은 서버 개발자는 갑자기 어안이 벙벙해졌다. 지금 할일도 많은데.... 하지만 어쩌겠는가? 우리 마케터님이 쓰고 싶다는데!! 만들어줘야지!! 이게 바로 개발자의 사명이자 운명 아닌가?

 

서버 개발자는 빠르게 핵심 요구사항을 적어나갔다.

 

1. 타켓팅

특정 그룹군에게 앱 푸시(app push) 보낼수 있어야만 한다. 예를 들면 이런거다. "1.5.6 버젼인 ios와 android 한국 사용자에게 푸시를 보내줘!"이걸 우리는 타겟팅이라 칭한다. 국가, 사용언어, 버젼, 기종에 따라서 보낼수 있도록 타케팅 기술을 지원해야만 했다. 

 

2. 푸시 view

마케터가 푸시(push)를 세팅할수 있는 view 화면을 제공해야만 한다. 

 

3. 예약기능

특정 시간에 보낼수 있는 예약 기능이 있어야만 한다. 마케팅 푸시는 시간이 중요하다. 언제 보내느냐에 따라 마케팅 성과는 달라진다. 

 

4. 분산처리

그때만 해도 우리앱은 약 40만 유저를 소유하고 있었다. 그러면 적어도 40만 유저에게 동시에 앱 푸시(app push)를 보내도 서버가 다운되서는 안된다. 그리고 서비스가 더 커진다면 더 많은 유저에게도 마케팅 푸시(marketing push)를 보낼수 있어야만 한다.

 

5. 결과 데이터 

마케터가 마케팅 푸시(markeing push) 성과를 측정할수 있는 feedback 데이터를 제공해야만 한다.

 

핵심요구사항을 정리하니 마음이 한결 편안해진다. 역시 정리는 사람의 마음을 편하게 한다. 그리고 하나씩 설계를 하기 시작했다. 

 

1. 타겟팅

저번에도 말한적이 있지만 푸시 알림 시스템(push alarm system)의 꽃은 타겟팅이다. 타겟팅을 얼마나 정교하게 하냐에 따라 난이도가 틀려진다. 

타겟팅을 하기 위해선 무엇이 필요할까?

 

데이터

 

데이터 없는 푸시 타게팅(push targeting)은 있을수 없다. 특정국가에 있는 유저에게 타게팅을 하고 싶다면  

다음과 같은 테이블이 존재해야만 한다. 

 

userID	country
A	South Korea
B	United State

 

우리는 기본적으로 국가, 언어, 앱 버젼, os로 타겟팅하기로 정했기 때문에 다음과 같은 테이블이 필요했다.

 

user_device 

deviceID	userID	country	language	os
device1	A	South Korea	ko-kr	andriod

 

응? 갑자기 deviceID가 등장했다. 왜냐? 우리앱은 다중 device를 지원했기 때문이다. A라는 유저가 안드로이드 폰이랑 아이오에스 폰 두개의 폰을 가지고 있다. 그리고 두 폰(android,ios) 모두에 우리앱이 설치 되어 있다면 하나의 기기에만 푸시를 보내는건 좀 이상하지 않은가?? 물론 하나의 기기에만 보내야 할때도 있다. 그럴때는 최근 많이 사용한 기기에게 보내는게 일반적이기는 하다. 하지만 우리는 다중 디바이스면 다보내자는 원칙이 있었기에 우선 보냈다.

 

이 테이블을 보고 의문점이 있지 않은가?

세계여행을 하는 유저가 있다고 해보자. 그럼 country는 계속 바뀐다. language를 계속 바꾸는 유저가 있다. 이런 경우 country와 language는 어떤 값을 지니고 있어야 하는가?

이건 정하기 나름이다. 최근 사용횟수가 많은 country와 language로 정한다든지 마지막 접속 정보를 기준으로 한다던지 등.. 대개 개발의 편의(?)를 마지막 접속한 country와 language로 설정하는 편이다. (특별한 이유가 없다면)

 

이제 데이터는 준비되었다. 데이터가 준비가 되었다면 푸시 타게팅(push targeting)은 정말 싶다. 우리는 DB의 쿼리를 이용해서 조회해주기만 하면 된다.

 

한국에 살고 있으는 1.5.2 appVersion의 ios에게만 푸시를 보내고 싶다면 다음과 같이 쿼리로 유저를 조회하면 된다.

select user_id,device_id
from user_device 
where country = "South korea" and 
    os = "ios" and 
    appVersion = 1.5.2

 

물론 정말 많은 데이터이기 때문에 limit문을 통해 분산을 해줘야만 한다. 그에 대해서는 '4.분산처리'에서  자세히 설명하겠다.

 

실행 다이어그램을 그려보자면 다음과 같다.

 

 

0. push view에서 마케터가 타겟팅 푸시(targeting push)를 설정 예약 한다.

1. push view는 해당 시간이 되면 푸시 서버(push server)에게 푸시(push)를 보낼것을 요청한다. => requestPush(title,content,targetInfo)

2. targetInfo정보를 이용하면 DB의 select문을 만들어 만들어 DB(deviceInfo)에 쿼리한다.

(물론 분산처리를 해줘야만 한다. 분산처리에 대한 내용은 추후 설명 예정이다.)

3. DB에서 조회한 device들에게 마케터가 작성한 푸시를 payload로 만들어 전송한다.

 

아주 간단한 마테팅 푸시 서버(marketing push server) 가 설계되었다. 

그럼 타겟팅은 끝난걸까? 아니다. 이건 정말 1차원적인 타겟팅일 뿐이다. 좀더 진화된 타겟팅이 필요하다. 이를테면 다음과 같다. '일주일내에 가입한 사용자중에 우리앱에 3번이상 들어온 사람'에게 특정 푸시 알람(push alarm)를 보내고 싶다면 어떻게 할까?  자 이제 슬슬 머리가 아파져 올것이다. 단순히 위에 있는 table 만으로 앱 푸시(app push)를 보낼수 없게 된것이다. 새로운 table이 필요하다. 

 

user_property

userID	가입후 몇번이나 접속했는가?	가입한 날짜
A	10	2022.01.14

 

훌륭하다. 가입한 날짜는 대개 user_property table에 저장되기 때문에 이미 저장되어 있는 데이터 일것이다. 문제는 가입후 몇번 접속했는가? 데이터를 어떻게 얻는가가 중료하다. 유저가 들어올때마다 increase해서 넣으면 된다고? 그리 쉽게 접근할 문제가 아니다.  만약에 '최근 일주일내에 20번 이상 접속한 사용자' 들에게 푸시 알람(push alaram)을 보낸다고 해보자. 단지 increase하는 방식은 확장성이 떨어진다. 그럼 어떻게 하면 될까? 답은 로그데이터에서 끌고 들어와야 한다.

 

우리는 이를 위해서 다음과 같은 로그데이터를 쌓아야만 한다.

 

date	event_name	timestamp	userID
2021-01-14	session_start	10192948139	A

 

그럼 우리는 이 로그 데이터를 이용해서 하루마다 한번씩 배치를 돌려 user_property table에 업데이트 해주면 된다.

 

 

1. jenkins의 cronjob으로 특정시간에 dataflow를 빌드 및 실행시킨다. 

2. dataflow에서 bigquery 로그 데이터를 쿼리해서 session_start 로그 데이터를 가지고 온다. 

3. 가지고 온 session_start data를 transfer 과정을 거쳐 "가입후 몇번이나 접속했는가?" 데이터를 추출한 후 user_property DB에 insert 한다.

 

jenkins를 사용한 이유는 dataflow를 구동시키기 위해선 매 시작마다 빌드 작업이 필요했다. 그리고 jenkins에는 cron_job 기능이 있기 때문에, 배치를 돌리기 적절했다.

 

dataflow는 datapipeline 프레임워크중 하나다. 데이터 추출 변환 적재 과정을 할수 있다. 참고로 필자는 서버 개발자이다. 대개 데이터 엔지니어들이 이런일을 하는데 서비스를 만들다 보니 실제 데이터 파이프라인 설계 구축 코딩까지 하게 되었다.... 불쌍한... 

 

하여튼 이렇게 우리는 다음과 같은 table을 보유하게 되었고, 마켓팅 푸시 타겟팅(marketing push targeting)을 정교하게 할수 있게 되었다.

 

user_property

userID	가입후 몇번이나 접속했는가?	가입한 날짜
A	10	2022.01.14

 

user_device

deviceID	userID	country	language	os
device1	A	South Korea	ko-kr	andriod

 

만약 다른 푸시 알람(push alaram)를 보내고 싶다면 해당되는 칼럼을 추가로 만들어 데이터를 쌓으면 된다. 실제 운영되는 비지니스의 경우 더 많은 데이터가 사용된다. 데이터가 많이질수록 table은 늘어날거고, data pipeline도 많아진다. 하나만 명심하자! 앱 푸시 타겟팅(app push)은 데이터 싸움이다.

 

휴~~ 이제 쉬어갈 시간이다. 큰산을 하나 넘었기 때문이다. 많은 이들이 해당글을 통해서 인사이트를 얻었으면 한다. 이제 다음시간에는 작은산이 '2. push view'와 '3. 예약 기능'을 어떻게 설계했는지에 대해서 썰을 풀어보겠다!!