데이터를 수집하는 원리는 간단하다. 웹이라면 사용하는 툴에서 제공하는 수집용 자바스크립트를 사이트의 공통 영역에 삽입하면 된다. 앱도 마찬가지다. 사용하는 툴에서 제공하는 데이터 수집용 SDK를 추가하고 환경 설정을 하면 끝이다.
이 수집 스크립트만 추가하면 기본적인 사용자 행동 데이터는 대부분 수집할 수 있다. 어떤 페이지를 조회했는지, 해당 페이지에 얼마나 머물렀는지, 사용자 환경이 어떠한지 등이 포함된다.
앱도 마찬가지다. 어떤 스크린을 조회했는지, 해당 스크린에 얼마나 머물렀는지, 사용자 환경은 어떠한지 확인할 수 있다.
그럼, 수집된 데이터는 어떤 형태로 전달되며 어디로 저장될까?
구글 애널리틱스를 기준으로 보면, 사용자가 특정 행동을 할 때마다 데이터를 보내는 엔드포인트(수집 서버 주소: https://analytics.google.com/g/collect)와 함께 파라미터 형태로 데이터를 전송한다. 파라미터는 키와 값의 쌍으로 구성되며, 키값은 고정되어 있다. 예를 들어 dl은 방문한 페이지의 URL 정보를 의미한다. en 같은 파라미터를 통해 전송된 이벤트 정보도 알 수 있다. (en=page_view, view_item, purchase...) 또한 ul=en-us(사용자 언어 설정), uap=macOS(사용자 브라우저) 등을 확인할 수 있다.즉, 어떤 방식으로 데이터를 수집하든, 동일한 엔드포인트로 일정한 규칙에 따라 데이터를 보내는 구조다.
어도비 애널리틱스도 마찬가지다. 데이터는 파라미터 형식의 데이터 페이로드 형태로 지정된 데이터 수집 URL로 전송한다.
즉, 수집 방식도 다르지 않다.
과거에는 서버 로그 기반으로 데이터를 수집했다. 서버에서 로그 파일명, 데이터 생성 주기, 저장 위치 등을 지정하면 요청이 발생할 때마다 로그가 자동으로 기록됐다. 아파치나 Nginx 같은 웹 서버별로 로그 설정 방식이 달라 다양한 포맷과 가이드가 필요했다. 이런 방식은 오랫동안 널리 사용되었다.
패킷 로그 방식도 있었다. 서버가 많은 대규모 환경에서는 L4 스위치 같은 네트워크 장비를 통해 패킷을 모니터링하며 데이터를 수집했다. 하지만 이 방식은 서버 관리가 어려웠던 탓인지 점차 대체되었다. 또한, 한때 해당 방식을 선호하던 곳들도 결국 스크립트 형식으로 데이터를 수집하기 시작했다.
지금 금융권에서도 스크립트를 활용한 로그 데이터 수집 방식을 사용하고 있다. 하지만 민감한 정보가 많기 때문에 구글과 같은 외부 시스템으로 데이터를 전송하지 않고, 자체 서버에 저장하는 방식을 유지하고 있다.
결국, 지금은 가장 편리한 방식인 스크립트 기반 데이터 수집이 업계 표준으로 자리 잡았다. 과거에는 서버 로그, 패킷 로그 등 다양한 방식이 존재했지만, 현재는 웹과 앱 환경에서 스크립트와 SDK를 활용한 방식이 가장 효율적이라는 데 이견이 없다.
앞으로 새로운 플랫폼이 등장하고, 그에 따른 새로운 데이터 수집 방식도 나올 것이다. 그러나 기본 토대는 변하지 않는다고 본다. 어쨌든 어떤 데이터를 수집할 것인지 결정해야 하고, 그 데이터는 어떠한 형태로든 남아야 하며, 또한 수집한 데이터를 어딘가에 저장해야 한다.
이 기본만 알고 있다면, 새로운 플랫폼이나 툴이 등장해도 두려울 것이 없을 것이고, 금방 적응할 수 있을 것이며, 그 데이터를 활용해 의미 있는 분석을 도출할 수 있을 것이다.