2021.11 ~ 현재까지, 정말 숨가쁘게 달려왔던 것 같다.
데이터 분석가이기 이전에 다양한 경험을 해보고싶다! 실무를 모르는 데이터 분석가이고 싶지 않다! 라는 고민 끝에 결정한 나의 행동이, 결론적으로 옳았다는 생각이 들었다.
성장하고자 하면 성장하는구나. 그러다보면 이 모든 상황에 감사하게 된다.
회사에서는 기존 paid 캠페인의 경우 GA에서 제공하는 기여모델을 사용하여 first click, last click에 따른 매출 기여도를 측정하고 있었는데, 페북 중심이었던 기존 마케팅 활동에서 네이버, 카카오 DA + 푸시 위주로 진행하고자 하는 방향성을 가지고 있었다. UTM도 워낙 꼼꼼하게 관리하고 있어서 GA 위주의 마케팅 전략을 펼치고 있다.
이 상황에서 광고 비용과 그에 따른 매출을 엮어 CPA 및 ROAS를 분석하고 싶었던 게 현재 기업의 니즈였는데, 먼저 주요 매출 수단이던 페북 데이터를 끌어와 ROAS 분석을 진행하고 Tableau로 대시보드화했다.
피드백 : 기여모델을 넘어서 전체 퍼널 형태로 보고싶다는 니즈 ( 유입 -> 클릭 -> 장바구니 -> 구매 -> 재구매)
위 피드백에 따른 내 생각 : 회사에 개발자도 없고 엔지니어도 없기에 데이터 파이프라인이 없어서, 단계별로 데이터 수집을 진행해봐야겠다!(ㅠㅠ)
신규 paid 캠페인(차이, 페이코) 으로 데려오는 고객이 진짜 신규 고객인가? 를 판별하는 데이터 분석도 진행했다. 각 매체에서 주장하는 '신규고객'과, 우리가 보고 있는 '신규고객'의 편차가 어느정도로 큰지, 이 고객들에 따라 실제 비용은 어느정도로 책정되어야 하는지 등을 배웠다. 이 분석에서 배울게 많았는데, (1) 우리가 원하는 타겟을 정말 데려오고 있는지 (2) 분석을 요청한 팀의 ROAS 상승 기준 또한 알아야 한다 는 점이었다.
결론적으로 위 캠페인은 CAC에 집중을 하게 됐다. 고객 한명당 얼마를 붓고있는지, 그 고객이 가진 퀄리티가 어느정도 되는지 객단가로 본다.
데이터를 보는 기준은 항상 다 다르다. ROAS 250% 이상이 누군가에게는 좋은 성과일 수도, 그저 그럴수도 있다. 좋은 성과인지, 나쁜 성과인지 판별할 수 있는 기준은, 이전 캠페인 진행 여부와 타 캠페인에서 오는 인사이트라고 느꼈다. 대조군은 중요하다!
(지극히 지극히 간단한 코드)
(1) 자사몰 내 데이터를 매일마다 특정 시간에 받아와서 특정 로컬 경로에 저장 (매우 쉬움)
: python selenium > import os
but 특정 요일마다 이슈가 있을때 python 상에서 try와 except 적용
(2) 특정 데이터를 지속적으로 google spreadsheet에 업데이트
: selenium + pandas + gspread + 스케줄러의 합작이었다
등이 있겠다.
사실 단순한 작업들을 자동화 시키는건 매우 재밌는 일이었다. 실무에 곧바로 적용되어 누군가의 도움이 되고 있기 때문이다. 다만, 두 가지 이슈가 있었다.
(1) 크롤링의 한계 -> 특정 구간에서 페이지 태그가 변경된 사항이 있거나, 에러가 있으면 이상한 데이터를 가져온다
(2) 스케줄러의 한계 -> 너무 많은 스케줄러를 돌리다 보니... 몇몇개는 이상하게 안돌아갈 때가 있다. 또, 스케줄러끼리 스케줄이 겹쳐 혼란스러운 때도 있었다.
이런 점을 극복하기 위해서 했던 짓 중 하나는..
(1) API를 도입했다.
광고 데이터의 경우 실시간으로 업데이트 되어야 하는 니즈가 있었지만, 크롤링으로 하게 되면 데이터 정합성이 늘 좋지 않았고 로봇탐지가 발생한다. 그 가운데에서 생각한 것이 REST API를 통한 취득 방식이었다.
API의 경우 광고(paid ad)쪽은 권한 이슈가 굉장히 크게 작용한다. 카카오의 경우 공식 대행사 측에만 열어주는 이슈도 있다. expired 되지 않기 위해 토큰을 바꿔주어야 하는 이슈 또한 존재하기에, 플랫폼 별 access token과 refresh token, 그 이전의 인가 관계를 잘 알아둬야 한다.
한계점도 있겠으나 크롤링보단 훨씬 정확한 방식으로 데이터를 취득할 수 있었다. 또한 데이터를 정제하기에도 정말 편했다. (일단 JSON 다루는 법이 많이 늘었다!)
일단은 네이버 / 카카오 / 구글 쪽을 API로 활용한 상태.
(2) airflow를 도입하려고 한다 (진행중)
스케줄러가 제대로 동작하지 않을 때가 많아서, (1) 필요할 때 retry 하고 error report를 보낼 수 있고 (2) 에러가 기록되고 (3) task 순서를 관리해 줄 수 있는 걸 찾고있었는데, 그게 airflow를 알게 된 이유였다.
airflow ui를 첨 봤을때 진짜 너무 기뻤다.... (이세상 모든 아카이브 매체와 작성자들에게 감사드린다.)
airflow는 나에게 너무 신세계였다. DB,웹서버,DAG,TASK... 다양한 용어가 난무하는 데다가, 어떤 환경이 베스트인지 잘 감이 안왔었다. 진짜 리눅스 환경이 낫나 싶어서 우분투 깔고 리눅스 해봤다가 에러의 늪에서 헤어나오질 못했다. 심지어 세팅되어있는 환경들에 대한 이해도도 약해서 도대체 뭐가 뭔지??? 음?? 매번 이런 상태.
결국 docker에 의존해서 기존에 누군가가 세팅해 놓은 레포를 토대로 localhost를 활용해서 진행하는 것으로 결정했다.
다만, dag 작성 시 정작 필요한 모듈들을 불러오지 못해서 막혀있는 상황. 이 상황은 꼭 해답을 찾아보고 싶다...
(사이즈 어떻게 줄이지.. select 케틀벨 from 헬스장)