최근에 퇴사를 하고 개인적인 개발 시간이 늘어나면서, 기존에 만들던 사이드 프로젝트인 북마켓을 추가적으로 개발을 많이 하기 시작했다.
편의성 기능인 / 로 인풋박스 포커스라던지, CMDK를 통한 북마크 검색 기능이라던지, 라즈베리파이로 옮기며 안됐었던 서브도메인 기능이라던지…
그리고 최근에는 이 북마켓 서비스를 한번 홍보를 해봐도 재밌겠다 싶어서 조금의 마케팅 전략을 위해 100 슬롯 제한 기능을 구현을 했다.
100 슬롯이 다 채워지면 다음 슬롯이 열릴 때까지 회원가입이 불가능하고, 서브도메인은 First Come First Served이기 때문에, 회원가입을 유도하는 나름대로의 전략이다.
다만 그 전에 이러한 홍보들을 통해 얼마나 많은 유저들이 들어오고, 얼마나 많은 이벤트들이 발생하는지를 트래킹하기 위해 Analytics 툴을 도입하기로 결심했다.
기존에는 Vercel Analytics를 사용했었지만, Prod 환경은 더이상 Vercel 배포가 아니기 때문에 의미가 없어졌기 때문에 새로운 Analytics 툴을 도입해야했다.
많이들 사용하는 선택지로는 크게 세가지가 있다.
- Google Analytics
- Posthog
- Umami
결론적으로는 Umami를 선택을 했는데, 이 선택을 하게된 배경 설명과, Umami 도입 과정에 대해 이야기 해보려한다.
왜 Umami를 선택했을까?
Google Analytics를 선택하지 않은 이유
이벤트 트래킹을 위해 Analytics 툴을 도입하고자 하면 일반적으로 Google Analytics를 많이들 선택한다.
이유는 엄청나게 많은 자료와, Google이라는 대기업의 지원이라고 볼 수 있다.
하지만 나는 Google Analytics를 선택하지 않았고, 그 이유는 바로 Ad Blocker와 데이터 관리 때문이다.
Google Analytics는 Cookie를 기반으로 동작하는데, 생각보다 많은 사람들이 사용하는 Ad Blocker들을 상대로는 전혀 동작하지 않는다.
만에하나 Ad Blocker를 사용하는 유저가 북마켓에 접속을 한다면, 그 유저의 기록은 남지 않는다는 의미이다.
그리고, Google Analytics에 내가 익숙하지 않아서도 있겠지만, 개인적으로 UI가 정말 불편하다고 느꼈는데, 그 UI를 내 마음대로 변경할 수 없다는 점과, 수집하는 데이터를 내 DB에서 직접 관리할 수 없다는 점이 아쉬웠다.
이러한 이유들로 인해 Google Analytics는 제외를 했다.
Posthog를 선택하지 않은 이유
전부터 Posthog에 대한 극찬을 많이 들어왔어서, 사실 Umami보다 Posthog를 써야겠다는 마음이 처음에는 더 컸었다.
하지만 북마켓은 현재 내 8기가 램의 라즈베리파이에서 실행되고 있다.
근데
Posthog는 기본적으로 16기가 램을 탑재하길 원한다.. 용량도 30기가 이상이 필요하댄다.
Posthog가 이렇게 무거운줄 몰라서 당황했고, Posthog를 사용하되, self-host를 하지 말까 생각도 했지만, 역시나 Google Analytics와 동일한 이유로 수집하는 데이터를 내가 직접 관리할 수 없다는 점이 걸렸다.
그래서 결국 Posthog도 제외가 되었다..
Umami를 선택한 이유
Umami는 일단 가볍다. 정말 가볍고 필요한 기능들만 갖고 있기 때문에 거창한 사양이 필요가 없다.
사실 내 북마켓이 얼마나 사양을 잡아먹는다고 이렇게 성능 걱정을 하나 싶지만, 사이드 프로젝트를 개발하는 사람들은 항상 본인의 서비스가 대박이 날거라고 생각을 하니… ㅋㅋㅋ 만에하나 유저가 몰렸는데, 트래킹 툴이 사양을 다 잡아먹어서 유저 경험이 떨어지고 전환률이 떨어진다고 생각하면 마음이 아프다.
그래서 lightweight한 Umami는 내 마음에 쏙 들었고, self-host하는 과정도 정말 간단했다.
Umami 직접 배포하기
https://github.com/umami-software/umami
Umami의 공식 깃허브 레포를 확인해보면, clone해와서 docker compose를 통해 띄우는 방법, docker hub에 올라간 docker 이미지들 가져와서 띄우는 방법, 이렇게 두가지가 있다.
그중에서 나는 clone 후 docker compose를 사용하는 방법을 선택했다.
이렇게 클론을 하고,
클론해온 디렉토리 안으로 들어와서
호스트 머신의 3000번 포트와 컨테이너의 3000번 포트가 매핑되어있는 기본 설정을 바꿔서, 호스트 머신의 4000번 포트와 매핑을 해주었고,
이렇게 docker compose up을 해주면 끝이다.
그러면 내 라즈베리파이의 4000번 포트에서는 Umami가 실행이 되게 된다.
이제 기본 username(admin)과 password(umami)로 로그인을 하면,
이렇게 트래킹 할 website를 추가해주면 된다.
Website가 추가되고 나면, client에 추가해줄 Tracking code가 제공이 되는데, 이걸 NextJS 기준
<Script
strategy='afterInteractive'
src='https://umami.bmkt.tech/script.js'
data-website-id={process.env.NEXT_PUBLIC_UMAMI_WEBSITE_ID}
/>
이렇게 추가를 해주면 된다.
참고로 나는 외부에서 접근하기 위해 umami.bmkt.tech 에 배포를 하고 설정을 했기 때문에 Tracking code의 src가 umami.bmkt.tech 로 되어있는데, 로컬에서 실행하면 localhost:3000 으로 설정이 되어있을 것이다.
물론 나중에 내가 한 것처럼 도메인 연결을 해줘야지만 정상적인 트래킹이 된다.
로컬에서 정상적으로 띄우고 나면, 이제 이 로컬의 4000번 포트를 외부에 열어줘야하는데, 기존 북마켓에 해준 것처럼 그냥 했다. 당시에는 삽질을 엄청 했지만, 이제는 나름 익숙해져서 바로바로 할 수 있었다.
Cloudflare에 umami.bmkt.tech 의 CNAME 레코드를 추가해줬고,
내 라즈베리파이는 nginx를 사용하고 있기 때문에,
server {
listen 443 ssl http2;
server_name umami.bmkt.tech;
ssl_certificate /etc/letsencrypt/live/bmkt.tech/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/bmkt.tech/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
location / {
proxy_pass http://127.0.0.1:4000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
이렇게 umami.bmkt.tech 로 들어오는 요청은 4000번 포트로 매핑을 시켜주었다.
이게 다 마무리가 되면,
이렇게 umami.bmkt.tech 를 통해 북마켓에서 발생하는 트래픽을 관리하고 볼 수 있게 된다!
이제는 슬롯 기능 마무리와, 홍보만 남았다!
내 라즈베리파이에서 돌아가는거라 서버 비용이 나가지도 않아서, 그냥 부담 없이 홍보를 해봐야겠다~