월요일 아침에 들려온 룸메의 갑작스런 이직 소식. 홋카이도로 간단다. 1월부터 근무라하니 나도 당장 대책을 세워야만 했다. 이사를 하든, 새로운 룸메를 구하든. 여튼 그러다보니 이번주는 너무 정신이 없었다. 대책세우랴, 이런 저런 걱정하랴. 일이 손에 잡히질 않았다.
뒤죽박죽이 되어버린 일상탓에 일도 얼렁뚱땅 해버렸다. 조금 더 고민해보고 마케팅 팀과 회의해가며 방향을 잡아보려 했으나 회의는 커녕 채팅조차 하지 못했다.
간신히 대책을 마련해두고 정신차리니 벌써 금요일이다. 양심에 찔려 야근신청을 했다. 일단 저번주 정리해둔 각 플랫폼과 성과측정 사이트의 관계를 토대로 내린 내 나름의 결론은,
플랫폼 -> ec force의 구조가 아닌
ec force -> 플랫폼의 구조로 개편해야 한다는 것이었다.
플랫폼을 기준으로 ec force 각각의 랜딩페이지 mcv와 cv을 엮으려니 마땅한 인사이트가 안보였다. 구조를 ec force기준으로 바꿔보니 그럴듯한 표가 만들어진다. 아래와 같다.
platform | landing page | mcv | conversion | campaign | net | imp | click |
pf11 TOTAL | 33333 | 33333 | ¥33333 | 33333 | 33333 | ||
pf11 | pf11_landing 1 | 11111 | 11111 | pf11_cam 1 | ¥11111 | 11111 | 11111 |
pf11 | pf11_landing 2 | 11111 | 11111 | pf11_cam 1 | ¥11111 | 11111 | 11111 |
pf11 | pf11_landing 3 | 11111 | 11111 | pf11_cam 2 | ¥11111 | 11111 | 11111 |
pf22 TOTAL | 22222 | 22222 | ¥3333 | 33333 | 33333 | ||
pf22 | pf22_landing 1 | 11111 | 11111 | pf22_cam 1 | ¥11111 | 11111 | 11111 |
pf22 | pf22_landing 2 | 11111 | 11111 | TOTAL | ¥2222 | 22222 | 22222 |
pf22_cam 2 | ¥11111 | 11111 | 11111 | ||||
pf22_cam 3 | ¥11111 | 11111 | 11111 | ||||
TOTAL | 55555 | 55555 | ¥66666 | 66666 | 66666 |
조금 복잡해 보일 수 있지만, 나한텐 이게 최선이다. 더 간단한 형태로 바꾸는 건 마케팅팀 쪽에서 제안할 일이니 잠시 제쳐두자.
구조를 설명해보자면(전에 말했지만 다행히 플랫폼 별로 랜딩페이지를 나누는건 가능했다),
(# 각 플랫폼 토탈부분은 아래로 내릴 예정이다)
* pf11
1. pf11에서 연결되는 랜딩페이지 url은 총 3개이다. 각각의 랜딩페이지url별로 cv, mcv성과를 나눌 수 있다.
2. 마케팅팀에서 정리해 둔 article url - 랜딩페이지 url 매칭표를 사용해 랜딩페이지별 플랫폼의 캠페인을 엮을 수 있다. 즉, 캠페인 별 net, impression, click데이터를 각 랜딩페이지의 성과로 엮을 수 있다는 것이다.
3. pf11 에선 랜딩페이지 1과 2에 캠페인 1 하나가 엮여있다. 이경우에도 문제없이 캠페인 수치를 각각의 랜딩페이지로 나눠서 엮을 수 있다.
4. pf11 TOTAL에서 pf11 플랫폼의 토탈 값을 확인할 수 있다. 마케팅 팀에서 현재 관리하고 있는 숫자이다. 이 표를 통해 현재 관리하고 있는 숫자 뿐 아니라 각 랜딩페이지별 플랫폼 켐페인 데이터와 엮인 수치 확인도 가능하게 되었다.
*pf22
1. pf22에서 연결되는 랜딩페이지 url은 총 2개이다. 각각의 랜딩페이지url별로 cv, mcv성과를 나눌 수 있다.
2. pf22에선 랜딩페이지 2에 두개의 캠페인이 엮여있다. 이 경우에는 캠페인 별 성과를 측정할 수 없다. 캠페인 하나 당 하나의 랜딩페이지로 연결되게끔 하는게 베스트다. 마케팅팀에서 관리해줘야 할 일이지만, 아마 불가능할 듯 하다. 그럴 생각도 의지도 없어보이기 때문이다.
3. pf22에서도 랜딩페이지 1, 2 각각의 성과도, 토탈 성과도 확인할 수 있다.
마지막으로, 맨 아래의 TOTAL은 그 날의 성과이다. 모든 랜딩페이지와 플랫폼의 데이터를 엮어 그 날의 성과를 확인할 수 있다.
일단 저 새로운 표를 통해 확인 가능한 성과는
기존의 플랫폼별 토탈 성과 + 랜딩페이지별 성과 + 그 날의 성과
이렇게 확장되었다. 마케팅팀에서도 좀 더 다양한 인사이트를 얻을 수 있지 않을까. 일단 다음주에 회의를 통해 확인을 받아봐야 할 것 같다.
각각의 플랫폼 데이터, ec force에서의 랜딩페이지별 데이터를 수집하기 위한 코드는 이미 다 짜놨다. 몇 개는 api를 통해, api가 없는 곳은 일단 크롤링을 통해 수집했다.
또한 google-drive-ruby gem을 통해 위의 표 역시 자동으로 입력 가능하게끔 코드를 짜고 있다. 토탈 부분만 수정하면 코드는 완성이다.
다음 글은 각 페이지별 데이터 수집 코드와 google-drive-ruby gem에 대해 쓸 예정이다.
'개발일지 > 광고데이터 연결 PJT - 차콜진센' 카테고리의 다른 글
20201228_메인스크립트 - 데이터 수집 및 저장 (0) | 2021.01.12 |
---|---|
20201228_시스템 구조 - 메인스크립트 구조 및 환경설정 (0) | 2021.01.09 |
20201219_시스템 구조 - 데이터베이스 (0) | 2020.12.22 |
2020.12.10_프로젝트의 이해 (0) | 2020.12.12 |