2020.12.10_프로젝트의 이해

우리 회사 CTO는 너무 순하다. 그리고 자기 사업때문에 바쁜 탓인지 세세하게 관리하질 않는다. 

그래서, 날 혼내지 않는다. 순해서, 그리고 관심이 없어서(?).

 

내가 혼나야 하는 이유는 2가지이다. 첫 번째, 프로젝트에 대한 이해도가 부족해서이다.

프로젝트는 단순했다. 현재 사용하고 있는 광고플랫폼들의 데이터를 엑셀시트에 자동 기입하는 시스템만 구축하면 된다. 이걸 이해못했냐고? 아니, 완벽히 했다. 마케팅팀 멤버와 일본어로 회의까지 했다. '여기 데이터를 어디어디에 넣어주세요. 이 데이터는 여기에 있구요, 저 데이터는 저기에 있어요'  등등의 이야기를 귀뿐만이 아닌 온몸의 기관을 다 사용하여 완벽히 이해해냈다. (야마키상, 천천히 얘기해줘서 고마웠어요)

내가 부족했던 것은 '프로젝트' 자체에 대한 이해도였다. 무슨 소리냐고? 이 프로젝트를 '왜' 하는지를 이해 못한채, '어떻게'에만 집중했다는 소리이다. 물론, 굳이 '왜'를 이해하지 않고도, 구현해달라는대로 구현해내면 그만인 프로젝트들은 많다. 하지만 우리 회사의 특성을 미루어볼때 '왜'를 이해하는 것은 절대 빠져서는 안되는 단계였다. 회사 규모가 작아 모든 일들이 주먹구구식으로 돌아갔기 때문이다.

결국 저번주 회의에서 문제가 터져나왔다. 광고(배너 등의 크리에이티브 혹은 광고형 기사)의 성과 수치는 각 플랫폼(구글애드, 야후애드 등)에서, 랜딩페이지의 conversion은 별개의 사이트에서 확인을 했으나 그 연결고리가 불명확한 탓이었다. 마케팅팀에서는 그저 플랫폼 단위로 컨버젼 사이트와 연결을 했고, 나는 그렇게 해달라하니 별 생각없이 그렇게 설계를 했었다. 하지만 CTO는 정확히 이 부분을 지적했다(자상하게... ). 위에서 말했듯 연결고리가 빈약하다는 것이었다. 그러곤, '어떻게 연결시킬지 고민해봐' 한마디 던지곤 홀연히 사라지셨다. 그냥 혼내시고 방향을 알려주시지... 혼 대신 막막함이 찾아온 순간이었다.

 

막막한 와중에 한가지 떠오른 생각은 '이 프로젝트는 왜하지'였다. 단순히, 마케팅팀에서 필요하니까 라는 답은 오답이었던것같다. 조금 더, 깊숙히, 근원적인 곳에 가닿아야 했다.

이걸 왜하지? 왜 저기서 저 수치가 필요하고, 여기선 이 수치가 필요한거고, 이 것들은 어떻게 연관이 있는거지?

그러한 고민 끝에 깨달은 점은 이번 프로젝트가 단순히 '데이터 - 스프레드시트 연결'이 아니었다는 점이다. 사실 데이터를 끌고와서 스프레드 시트에 넣는 것은 그다지 어려운 작업이 아니다. 이번 프로젝트는 그보다 좀 더 무거웠다. 각 플랫폼에 있는 성과수치와 랜딩페이지 관리화면에 있는 컨버젼 수치. 이 둘을 긴밀히 연결하는 것. 그 연결고리를 견고히 하는 것. 나에게 주어진 임무는 바로 이것이었다. 

 

그제서야 마케팅팀의 업무를 샅샅이 살펴보기 시작했다. 그 분석의 결과를 아래와 같이 공유한다. 해도..되나? 여튼 한다. 

 

1. 광고 플랫폼 - 구글애드, 야후애드, 도코모 애드네트워크 등

2. 랜딩페이지 관리 - EC Force(일본의 쇼피파이)

3. 플랫폼에 담긴 정보는 아래와 같다. 아래 리스트 된 순으로 큰 개념 -> 작은 개념이며 큰 개념 밑에 작은 개념이 담긴 형태이다.

• 어카운트(운영하고 있는 광고의 광고주, 즉 고객의 정보)
• 캠페인(광고를 담는 큰 틀. 이름에선 별다른 규칙성을 못찾겠다. 리타겟정보가 담긴 캠페인명도 있긴 하지만 규칙적인 패턴도 없고 각 플랫폼마다 중구난방이다)
• 애드그룹(광고를 담는 중간 틀. 데모그래픽 정보가 담긴 애드그룹명도 있기 하지만 역시나 규칙이 없다)
• 광고(광고 혹은 크리에이티브. 배너의 형태다. 야후의 경우는 해당 사이트 플랫폼의 측면에 나타나고, 구글의 경우는 구글애즈가 심어진(?) 각 블로그나 사이트에 나타날 것이다. 도코모 등 다른 플랫폼의 경우 애드네트워크 형식으로 광고배신이 진행되는 것으로 알고 있다)

4. 각 광고 (혹은 크리에이티브)를 클릭시 광고기사(제휴마케팅 기사)로 넘어간다.

참고로 이 광고기사는 기사라고 부르긴 하지만 싱글페이지 블로그의 느낌이다. 실제 구매가 가능한 landing page로 넘어가기 전, 제품의 효능을 설명하는 또 하나의 브릿지 역할을 한다고 보면 된다. (대체 왜 이런 단계를 거치는지 모르겠지만..) 

5. EC Force를 통해 관리하는 랜딩페이지는 여러개다. 사실 랜딩페이지라 부르기엔 (이것 역시) 조금 모호하고, 싱글 광고 페이지 정도로 생각하자. 현재까지 약 80여개의 랜딩페이지를 관리중이다(더럽게 많다..). 다행히도, 물론 거지같지만, url명에 규칙이 있어서 플랫폼 단위로 묶을 수 있을것같다. 

6. 각 플랫폼과 EC Force에서 필요한 정보를 톺아보자. 

  - 플랫폼

• Impression(노출건수. 야후를 예로 들자면 측면의 배너공간에 얼마나 노출이 되었느냐이다)
• Click(클릭건수. 그 배너를 얼마나 클릭하였느냐이다)
• Net(비용, 즉 사용금액이다. 아마 우리회사는 cpc, 클릭당비용을 사용하는듯하다)

  - EC Force

• 랜딩페이지 별 MCV와 CV

7. 플랫폼과 랜딩페이지는 참 더럽게 연결되어있다. 내가 본 연결 중에 제일 더럽다. 여튼 어떻게 연결되어있냐면,

플랫폼 측				제휴마케팅 측	랜딩페이지 측
어카운트	캠페인	애드그룹	광고(배너 등) 클릭	광고형기사 클릭	랜딩페이지

8. 여기서 문제가 드러난다. 마케팅 팀에선 각 광고와 그 광고를 클릭시 연결되는 광고형 기사를 정리해놓지 않는다. 어떤 규칙이 있는 것도 아니다. 이렇게 되면, 애드그룹에서, 혹은 캠페인 단위에서 어떠한 기사들을 관리하고 있는지 한 눈에 보기가 어렵다. 이는 즉, 어떤 랜딩페이지로 연결되고 있는지 한 눈에 보기 어렵다는 말이고, 다시 말하자면 어떤 캠페인, 애드그룹에서 어떤 성과가 나왔는지 확인하기 어렵다는 것이다. 그렇기에 그저 플랫폼 - 랜딩페이지 이라는 제일 큰 단위에서의 관리만 하고 있었던 것 같다. 

정말 다행인건 관리를 안하고 있을 뿐이지 해당 광고에 링크된 페이지 정보를 얻는 건 가능했다. 플랫폼의 imp등의 정보가 나온 테이블에도 떡하니 있었고, api로도 무리없이 받아올 수 있었다. 

 

9. 다행인 점이 하나 더 있다. 광고형기사와 랜딩페이지 url은 엑셀로 관리하고 있었다는 것이다. 물론 더럽게. 사실 제대로 관리를 하고 있는지도 모르겠다. 시간이 없어서 일일이 url들을 살펴보진 않았다만, 뭐 관리한다고 하니 믿어야지.. 어찌됐든 연결고리는 찾은 셈이다. 

 

10. 결론 : 마케팅팀은 현재 플랫폼 - 랜딩페이지 레벨에서의 관리만 가능하다. 하지만 원한다면 좀 더 세세한 관리도 충분히 가능하다. url관리만 제대로 해준다면..

 

여기까지가 내가 분석한 마케팅 업무의 실체이다. 여기까지 정리해 놓으니 앞이 조금 밝아진 느낌이다. 가장 먼저 해야할 일은, 그렇다면 플랫폼 - 랜딩페이지 레벨에서의 관리로도 충분한건지, 아니면 좀 더 세세한 관리를 원하는지를 파악하는 것일테다.

 

# 2020.12.13 수정

 

라고 생각했지만 역시나 만만치 않다. 혹시나해서 직접 일일이 데이터 비교 작업을 해봤는데, 세세한 단위로 관리하는게 애초에 불가능했던 이유가 있었다. 플랫폼 기준으로 생각했을때는 광고 하나당 랜딩페이지로 연결이 되고 있어서 적어도 캠페인 단위에서라도 특정한 랜딩페이지로 연결시키는 어떤 규칙이 있을거라 생각했는데 그게 아니었다. 여러 캠페인이 하나의 랜딩페이지로 연결되는 경우도 있었던 것이다. 

A캠페인의 imp, click, net 데이터를 랜딩페이지1의 CV, MCV와 연결할 수 없는 이유다. B캠페인도 랜딩페이지 1로 연결 가능하기 때문이다.

애초에 플랫폼 단위가 아니면 불가능한 연결이었다. 심지어 각 크리에이티브도 이 캠페인, 저 캠페인에서 사용되고 있었으니 말이다. 

 

다시 생각해봐야했다. 세세한 연결은 불가능하다. 내가 가능한 연결은 플랫폼 : 랜딩페이지 뿐이고 코드를 통해 이를 자동화한다면 엑셀시트로 확인 가능한 데이터는 해당 날짜의 플랫폼 전체의 데이터, 그리고 그 플랫폼에서 연결되고 있는 랜딩페이지 전체의 데이터 뿐이다. 이걸로 충분한가. 플랫폼의 성과 확인으로도 충분한 것인가. 만약 아니라면? 여기서부터 다시 출발해야한다. 머릿속이 더 복잡해진 느낌이다.