brunch

You can make anything
by writing

C.S.Lewis

by 비즈스프링 Mar 11. 2022

웹로그분석에서 데이터 엔지니어링까지

인터넷이 대중화 된 이래로 기업홍보, 쇼핑, 컨텐츠, 소셜 네트워크 등 수많은 비즈니스가 인터넷을 이용하여 이루어지고 있습니다. 인터넷 비즈니스 기업 입장에서는 웹사이트 방문자를 늘리고 방문자의 행동을 파악하고 대응하는 것이 결국 수익과 연결 되는데요, 수익을 늘리기 위한 방문자 분석 니즈로 부터 ‘웹분석‘이라는 기술 및 비즈니스가 탄생하게 됩니다.

비즈스프링은 2002년부터 웹분석을 시작으로 하여 현재까지 데이터를 기반으로한 다양한 솔루션과 서비스를 제공하고 있는데요, 20여년간 웹 데이터를 분석하며 얻은 경험으로 웹분석 제품이 어떻게 변화하고 발전하였는지 기술과 그 환경 관점에서 이야기 해 보고자 합니다.

웹분석의 시작 – 웹로그분석

현재의 웹분석 툴들은 매우 다양한 분석 기법으로 풍부한 결과를 만들어 내고 있지만, 초창기의 웹분석은 아주 단순한 통계 밖에는 얻을 수 없었습니다. 그래서 웹분석이라는 용어보다는 웹로그분석이라는 용어를 더 많이 사용했던 듯 합니다.

웹로그분석 시절의 제품에서는 지금 처럼 고급의 통계를 보기 어려웠는데, 이유는 간단합니다.

원천 데이터가 담고있는 정보가 매우 적고, 제한적이었기 때문입니다.

192.168.72.177 – – [22/Dec/2002:23:32:14 -0400] “GET /news/sports.html HTTP/1.1” 200 3500 “http://www.some.com/” “Mozilla/4.0 (compatible; MSIE …)”
192.168.72.177 – – [22/Dec/2002:23:32:14 -0400] “GET /favicon.ico HTTP/1.1” 404 1997 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)…”
192.168.72.177 – – [22/Dec/2002:23:32:15 -0400] “GET /style.css HTTP/1.1” 200 4138 “http://www.yahoo.com/index.html” “Mozilla/5.0 (Windows…”
192.168.72.177 – – [22/Dec/2002:23:32:16 -0400] “GET /js/ads.js HTTP/1.1” 200 10229 “http://www.search.com/index.html” “Mozilla/5.0 (Windows…”
192.168.72.177 – – [22/Dec/2002:23:32:19 -0400] “GET /search.php HTTP/1.1” 400 1997 “-” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; …)”

위의 예는, 일반적으로 많이 사용하는 apache log 형식으로 작성된 로그파일의 일부입니다.

레코드는 한줄에 표현되고 공백문자를 기준으로 순서대로 아래와 같은 의미를 가집니다.

　- 접속자 IP/도메인

　- remote id

　- 사용자 id

　- 접속시간

　- 요청페이지 (method, path, protocol)

　- 응답 상태코드 (200 – 페이지 응답, 302 – redirect(페이지 이동), 404 – 페이지 찾을수 없음 등 …

　- 전송데이터 크기 (byte)

　- referrer (유입 경로 = 이전 페이지)

　- user-agent 헤더값 (브라우저 정보, 브라우저 정보에는 OS와 관련된 정보도 포함)

Webalizer 는 웹분석 초기에 사용되던 툴인데, 위와 같은 형식의 로그파일을 원천데이터로 이용하여 여러 주제의 통계를 구할 수 있었습니다. (여담이지만, 국내에 Webalizer를 한글화 및 국내 검색엔진등 환경에서 분석되게끔 국내 현지화에 큰 기여한 1인이 비즈스프링에서 근무 중이랍니다.)

웹분석 방식의 발전 – 스크립트 임베딩 (스크립트 태깅)

로그파일을 이용하여 분석하는 방식은 여러가지 큰 단점이 있었습니다. 그 중 하나로, 원인과 결과가 되는 데이터가 여러 레코드로 분리된 경우 결합이 어렵다는 것입니다. 쉬운 예로, 캠페인 집행의 성과를 구하고자 할 때 – 유입 페이지뷰 레코드에는 캠페인 추적값이 있지만 전환값이 없고, 주문 페이지뷰 레코드에는 반대로 전환값은 있으나 캠페인 추적값이 없게 됩니다. 두 레코드를 인과 관계로 결합 하기가 어렵고, 한다고 하더라도 너무 많은 자원이 필요하게 됩니다.

스크립트 임베딩 방식은 자바스크립트를 이용하여 (웹)브라우저에서 실행되는 코드를 작성하고, 이 코드가 데이터를 수집하여 분석서버로 전송하는 구조로 되어 있습니다. 자바스크립트는 대부분의 웹브라우저가 지원하고 있고, 웹브라우저 내 DOM등 객체에 접근하거나, 쿠키의 발행, 읽기가 가능하므로 수집할 수 있는 데이터가 더욱 풍부해 지게 되었습니다.

자바스크립트로 인해 쿠키를 사용하게 되면서 광고매체, 키워드, 유입사이트, 캠페인 등 다양한 주제에 대한 원인 값을 유지한 채 데이터를 수집할 수 있게 됩니다. 주문 페이지뷰 레코드에 전환값과 캠페인등 쿠키 값을 동시에 저장할 수 있게 되면서 성과 측정(컨버전 트래킹)이 쉬워지게 됩니다.

스크립트 임베딩 방식에서 쿠키 사용 외 또 다른 장점은 자바스크립트를 이용하여 다양한 데이터를 매핑하거나 전송 할 수 있다는 것입니다. ‘장바구니에 넣은 상품명’ 이라던가, ‘메뉴명 – 카테고리’ 처럼 웹사이트의 특성에 따른 데이터를 저장하기가 용이합니다. 또한, 버튼 클릭이나 DOM 로딩 과 같이 이벤트 레벨의 데이터도 수집이 가능해 지기 때문에 페이지뷰 기반의 기존 방식보다는 다양한 방문자 행동 데이터를 획득할 수 있습니다.

LOGGER 데이터 구조를 예로 기존의 로그파일 방식에 비해 어떤점이 달라졌는지 살펴 보겠습니다.

유입경로와 추적용 태그 값을 추적하는 것이 가능해지면서

광고, 캠페인, 이벤트 등 다양한 차원에서 주문, 매출, 회원가입, 골(goal) 등 다양한 전환 성과값을 구할수 있게 되었습니다. 또한 인과 관계에 따른 시나리오 – 시계열 funnel 분석도 가능해 졌습니다.

빅데이터 시대 – 데이터 전송을 위한 인터페이스 요구

LOGGER에서 제공하는 리포트 이름만 찾아봐도 종류가 매우 많은 것을 알 수 있습니다.

이렇게 다양한 리포트가 제공 되지만,

웹분석 툴 사용에 익숙해지고 눈이 높아진 사용자들의 요구는 계속 늘어갑니다.

실무자들은 현업 보고서에 사용하기에 좋은 형식, owned 데이터와 결합, 재활용 가능한 형식의 데이터를 요구하기 시작 했습니다. 기술 발전에 의해 빅데이터를 운용하기 위한 비용이 줄어들자, 많은 기업들은 사내에 DW(data warehouse), DL(data lake)를 갖추기 시작했고, 보유한 데이터에 웹분석 데이터를 통합하기 시작 합니다.

위의 스크린샷에서 볼 수 있듯이 LOGGER™, Conversion™(Conversion Tracking System) 에서는 리포트 데이터를 API로 가져갈 수 있도록 제공하고 있는데요, 고객사에서는 이런 인터페이스를 통해 웹분석 데이터를 획득하여 DW에 통합하고 활용하는 것이 가능 해 졌습니다.

써드파티(3rd party) 데이터의 활용 – 광고 성과

앞에서 쿠키와 관련한 주제로 성과 측정에 대해 말씀 드렸는데요,
네이버, 카카오, 구글과 같은 광고 제공자(Ad provider)들도 웹분석과 유사하거나 웹분석을 포함하는 광고성과 보고서를 제공 합니다.

웹분석 데이터에 비해 광고키워드나 소재에 따른 노출 회수나 비용 데이터까지 제공하여 주므로, 성과 위주의 웹분석 보다 풍부한 지표들을 보여줄 수 있죠. 그럼에도 불구하고, 마케터/광고주 입장에서 볼 때 불만인 부분이 생깁니다. 비용대비 성과가 부풀려지는 경우가 있는데, 각 광고 제공자마다 자신의 성과를 따로 보고하기 때문에 다수의 광고 매체를 교차한 방문자의 성과가 뻥튀기 되는 것이죠.

예를 들면, 카카오의 키워드 광고를 이용하여 사이트에 한번 들렀다가, 이후에 다시 네이버의 키워드 광고로 방문 후, 1000원짜리 물건을 구매한 경우를 가정해 봅니다. 실제로 발생한 매출액은 1000원이지만, 두 광고 매체에서는 각각 자신의 광고성과로 1000원씩을 보고하여 총 2000원이 성과로 집계가 됩니다. 광고주 입장에서는 실제 매출을 기준으로 기여한 광고 매체나 키워드를 알고 싶은데 허수가 발생하는 것이죠.

이런 상황에서 매체 데이터의 비용과 웹분석의 성과를 결합하는 아이디어가 나왔습니다.
비용은 매체, 키워드 별로 발생한 것이므로 허수가 없고, 전환값은 기여 모델을 이용하여 최종 또는 최초 매체에 전부 할당하거나 각 매체에 균등 분할하여 매길 수 있습니다.

위 스크린샷은 광고제공자들이 제공하는 매체 데이터와 웹분석툴로 부터 획득한 성과 데이터가 결합된 매체 통합 솔루션을 캡쳐 한 것입니다. 웹사이트에 도달하기 전 – 광고 노출수, 비용 데이터와 웹사이트 도달 이후 – 유입, 구매 데이터를 결합하여 활용하고 있습니다. 이와 같이 자신만의 고유한 원천 데이터만 이용하던 기존 제품에서 다양한 데이터 소스를 사용하는 제품으로, 원천 데이터 경계가 허물어지기 시작하였습니다.

데이터 엔지니어링

이제는 웹분석을 위해 활용할 수 있는 소스 데이터가 더 풍부해 졌습니다.

앞에서 설명한 웹분석 데이터나 광고성과 데이터 뿐만 아니라, 키워드 순위 데이터, 라이브 상품/경쟁 업체상품을 모니터링하기 위한 크롤러 데이터 등 소스들이 다양화 되고 있습니다. 심지어 경쟁사 웹분석 제품의 데이터를 API를 이용하여 가져오는 것도 가능합니다. 예를 들면, GA360(Google Analytics 360)의 원천/리포트 데이터를 API로 가져와서 필요한 통계 데이터를 비즈스프링의 처리 방식으로 구하는 것이 가능합니다.

위의 도식은 고객인 모 쇼핑몰사에서 비즈스프링의 데이터 엔지니어링을 이용한 사례를 간단히 그린 것입니다.

고객사의 내부 시스템에서 사용할 데이터를 생성하기 위해 GA와 비즈스프링의 웹분석 시스템을 이용하여 원천 데이터를 획득하고, 비즈스프링에서 가공 한 후, 가공 완료된 데이터를 가져가는 구성입니다.

고객사 자사의 데이터레이크에 양쪽(GA, 비즈스프링)의 원천데이터를 가져가서 직접 가공하는 것도 가능했지만, 가공과정을 거쳐 완성된 데이터를 받을 경우 데이터레이크 구축에 들어가는 자원/비용을 크게 감소시킬 수 있었습니다.

데이터 엔지니어링을 이용하면 통계 이상의 데이터를 만드는 것도 가능합니다.

이전까지의 웹분석이 주로 특정 주제 – 차원을 기준으로 그룹을 만들고, cardinality, sum, count 같은 통계 방법을 이용하여 집계하는 것이었다고 한다면, 이제는 방문자를 분류하고 대상을 추출하기 위해 머신러닝(ML)을 이용 하거나, 광고 성과를 보는 것에 더 나아가 광고 매체, 키워드/소재 별 성과를 예측하는 인공지능(AI)을 붙이는 것이 가능해 졌습니다.

아래 스크린샷 처럼 웹분석 데이터를 활용하여 협업필터링을 통한 컨텐츠 추천을 하거나,

크롤링 데이터 속성을 이용한 유사 컨텐츠 추천에 데이터 엔지니어링을 이용 할 수 있습니다.

마치며

여기까지, 초기 웹로그분석 부터 현재 비즈스프링의 웹분석까지 변화를 간략히 살펴 보았습니다.

기회가 되면 좀 더 자세한 예와 재미있는 뒷 이야기를 풀어보고 싶네요.

다수의 기업들에서 빅데이터 플랫폼을 내재화 하고, 수많은 종류의 데이터를 활용하고 있습니다.

이에 발 맞추어 저희 비즈스프링도 웹분석 데이터, 기업이 소유한 데이터, 공개된 데이터, 써드파티 데이터까지 데이터 소스/커넥터의 다양화를 통한 빅데이터 플랫폼을 구축하고 있습니다. 요구에 따른 데이터를 설계, 가공/생산 하는 능력도 갖추고 있구요, 잘 만들어진 데이터를 활용할 수 있는 다양한 인터페이스까지 준비하고 있습니다.

많은 기대 바랍니다.

감사합니다.

02-6919-5516 / ad@bizspring.co.kr

▼ https://bizspring.co.kr/company/newsletter.php