플러그인을 사용하였는데, 구글이 GA를 gtag로 통합하여 지원하면서 gatsby-plugin-google-gtag 플러그인 또한 새로 나왔다. 이미 공식문서에서 gtag를 권장하고 있기 때문에 gtag를 사용할 생각은 이미 굳혔지만 두 플러그인의 실제 사용량이 궁금해졌다.
NPM trends 사이트를 통해 확인해보니 두 플러그인의 추세 변화를 확연히 알 수 있다. GA의 사용량이 꾸준한 하락 추세에 있으며 최근에는 gtag에 역전당했다. 구글이며 gatsby며 gtag를 권장하고 있으니 굳이 GA를 사용할 필요는 없을 것 같다.
공식문서의 안내를 보면, 프로덕션 모드에서만 해당 플러그인이 실행되기 때문에, 개발 단계에서의 트래킹을 제외해주기 위한 처리를 별도로 할 필요가 없었다. 예전에는 개발용 GA, 라이브용 GA 두 개를 나눠서 실행 환경에 따라 GA의 id값을 다르게 해주는 방식으로 데이터를 구분했던 것 같은데 편해진 것 같다.
로컬에서 gatsby 프로젝트를 프로덕션 모드로 띄우기 위해서는 위의 코드로 실행하면 된다.
gatsby config 설정
gatsby.config.ts
에 추가만 해주면 되어서 너무 간편하다. 그런데 내가 느끼기에는 공식문서가 조금 불친절하게 느껴졌다. 특히 예를 들면 trackingIds 에서
GA-TRACKING_ID
라고 되어 있는 부분인데 여러 연동을 지원해주는 만큼 앞에
GA-
가 무조건 붙어야 하는 것인지, 다 지우고
G-XXXXYYYYZZ
의 GA 아이디를 넣으면 되는 것인지 너무 헷갈렸다.
여러 설정 옵션들도 지원해주고 있는데, 이에 대해 짧은 주석 한 줄만 적어둔 건 좋지만 공식문서에서 조금 더 상세한 설명을 해주었으면 좋겠는데, 몇몇 옵션들을 제외하고는 설명이 없었다. 그래서 기본 설정 외에는 최대한 제외하였으며,
delayOnRouteUpdate
만 1000ms 로 수정했다. 사용자가 페이지에 진입했을 때 페이지뷰 이벤트 발생을 얼마나 지연시키느냐 인데, 0ms면 사이트에 들어왔다가 바로 나간 사용자도 페이지뷰로 찍히기 때문에 이를 방지하기 위해 1초 정도로 수정했다.
또 삽질한 내용을 하나 더 적어보자면…
origin
파라미터였다. 내가 호스팅한 사이트의 주소를 입력하라는 건가 ? 라는 생각이 문득 들어서 입력해봤더니 gtag 경로를 찾지 못해 404에러가 났다. 설치하려는 사이트의 주소가 아니라 연결할 gtm에 대한 경로였던 것이다. 그래서 다시 롤백했다.
공식 문서 config 설정 예시
Debug
정상적으로 설치가 되었고 이벤트가 잘 수집되는 지 확인해보자.
Chrome Plugin 설치
구글 크롬에는 GA의 디버깅을 지원해주는 플러그인이 있다. 설치 한 후 해당 플러그인 아이콘을 클릭하여 활성화 시키면 개발자 도구의 콘솔 창에 GA 이벤트에 대한 로그가 찍히는 걸 볼 수 있다. Debug Mode가 On 된 상태에서 발생하는 이벤트에 대해 GA DebugView에서 따로 확인할 수 있다.