왜 필요했나
최근 게시글 평균 조회수가 20에서 40 사이로 오르면서, 정작 이 숫자가 어디서 왔는지를 전혀 알 수 없다는 게 눈에 띄었다. 관리자 통계 페이지(/admin/stats)에는 오늘 방문자·누적 방문자·게시물 평균 조회수·인기 게시물 Top 10까지는 나오지만, 그 방문이 검색에서 왔는지 SNS 공유에서 왔는지 아니면 어느 커뮤니티 링크를 타고 왔는지는 애초에 저장하지 않는다.
현재 블로그에 적용된 View Count 측정 방식은posts/[slug]/page.tsx의 view_count + 1만 원자적으로 증가시킬 뿐이고, site_visits 테이블도 날짜별 방문자 합계 한 줄만 쌓는 구조다. Referer 헤더든 UTM 파라미터든 유입 경로를 짐작할 만한 값은 어디에도 기록되지 않는다. Google Analytics 4나 Vercel Analytics 같은 외부 분석 스크립트도 붙어있지 않았다.
조회수가 왜 늘었는지 알아야 다음 글을 어디에 맞춰 쓸지, 어떤 채널에 더 신경 쓸지 판단할 수 있다고 생각해서, 이번 기회에 유입 경로 추적을 붙이기로 했다.
설계: Vercel Analytics냐 Google Analytics 4냐 자체 구현이냐
후보는 세 가지였다.
하나는 Vercel Analytics다. 이미 Vercel에 배포 중이라 패키지 설치 + 레이아웃에 컴포넌트 하나만 추가하면 끝나는 수준으로 제일 간단하다. 다만 무료 플랜은 리퍼러 상세도가 낮고 데이터 보관 기간도 짧아서, "어디서 왔는지"를 구체적으로 보고 싶은 이번 목적과는 맞지 않았다.
다른 하나는 기존 incrementViewCount를 확장해서 요청의 Referer 헤더를 직접 DB에 저장하는 자체 구현이다. 외부 서비스 의존 없이 지금 있는 관리자 통계 페이지 스타일에 그대로 통합할 수 있다는 장점이 있다. 하지만 Referer 헤더는 브라우저 정책이나 확장 프로그램에 의해 누락되는 경우가 잦아서 데이터가 애초에 불완전할 가능성이 높고, 직접 만들고 유지보수까지 떠안아야 한다는 부담도 있었다.
마지막이 Google Analytics 4다. 추적 스크립트를 붙이는 초기 설정은 앞의 두 방식보다 손이 더 가지만, 무료로 검색·소셜·직접 방문·리퍼러 사이트별 유입 경로를 상세하게 볼 수 있다. 과거 데이터를 소급해서 볼 수는 없고 붙인 시점부터만 쌓인다는 한계는 있지만, 지금 필요한 건 "지금부터라도 정확하게" 보는 쪽이라 이 한계는 감수하기로 했다.
정밀도를 우선해서 Google Analytics 4로 결정했다. 자체 구현은 헤더 누락으로 인한 데이터 손실 리스크가 이번 목적(유입 경로를 최대한 정확히 파악)과 어긋난다고 판단해 제외했고, Vercel Analytics는 무료 플랜의 리퍼러 상세도 부족이 발목을 잡았다.
적용 방향
Next.js App Router 환경이라 @next/third-parties의 GoogleAnalytics 컴포넌트를 쓰는 방식을 선택할 것이다. 왜냐하면 직접 next/script로 gtag.js를 붙이는 것보다 공식 지원 방식이라 관리 포인트가 적다.
Google Analytics 4 측정 ID 발급 전까지는 코드 변경을 미뤄두고, 실제 적용과 그 과정에서 걸린 부분은 다음 개발일지에서 이어서 정리할 예정이다.