Web Log Analysis

실시간 웹사이트분석으로 방문자 성향 200% 이해하기라는 주제의 워크샵을 다녀왔습니다.

그룹 웹마스터들의 정기적인 웹사이트 관련 세미나 였는데 이번이 두번째로 참석한 자리였습니다.

 

주 내용은 기존 웹서버의 Log를 분석하는 방식이 아닌 Packet Sniffing 방식에 대한 소개였습니다.

그럼 Packet Sniffing 방식에 대한 설명에 앞서 웹사이트의 방문자 로그를 분석하는 방식부터 소개하자면, 크게 3가지로 분류 될 수 있습니다.

 

  1. WebServer Logs

  2. Web Page Tags

  3. Packets Sniffing

 

WebServer Logs를 분석하는 방법은 일반적으로 지금까지 대부분의 로그 분석 솔루션이 가져오던 방식이다. 모든 웹서버는 접속된 사용자들의 웹서버에 대한 요청과 답변을 로그로 남겨놓습니다. 이러한 로그는 특정한 규칙에 의해 축적되고 있으며 이를 로그 분석계 서버에서 적절한 데이터로 가공하고 DB에 보관하는 방식입니다.

두번째 방법인 Web Page에 Tag를 삽입하고 해당 Tag에 대한 요청의 실행 결과를 로그로 남겨놓는 방법은 대부분의 ASP방식으로 서비스 되는 로그 분석 프로그램들이 이러한 방법을 사용하고 있는데 단점이라면 서버에 부하를 많이 주는 편이며 필요한 패턴이 비교적 정교하지 못한 편이며 당양하지도 못하다는 단점이 있습니다.

마지막으로 Packet Sniffing 방식은 client의 요청과 웹서버의 답변이 오가는 스위치에서의 패킷을 mirroring or tapping하여 이를 분석계 서버에서 데이터를 가공하여 DB로 축적하는 방식으로서 최근에 나오는 대부분의 로그 분석 솔루션이 이러한 방법을 사용하고 있습니다.

[패킷 스니핑 시스템 구성도]

 

이처럼패킷 스니핑 방식을사용하는 이유로는로그 분석에 비해 하드웨어의 성능 요구가 낮으며패킷이라는 http 프로토콜 상의 통일된 형식인 패킷을 받아 분석하는 관계로플랫폼과는 무관하게 작동할 수 있다는 장점 때문이다. 특히 로그 분석과는 다르게PV의 실시간 분석(모니터링이 더 맞는 표현이 되겠다.)이 가능하며서버의 증설이나 이전, 추가 또는 환경변화에 무관하게 작동해 준다는 점에서 그 점수를 얻었다고 봅니다.

하지만 단점도 있습니다.

일단 https를 타는 페이지의 분석이 불가능하다. 즉SSL을 사용한 페이지의 로그는 분석이 불가능하다는 것이다. 만약 귀사가 은행 사이트라면 패킷 스니핑 방식의 로그 분석 솔루션 도입은 꿈도 꾸지 마시길 바랍니다. 또한 전용 분석계 서버가 별도로 준비되어야 한다. 예를 들어 PV나 UV가 무척 낮아서 분석계 작업의 CPU할당량이나 메모리 사이즈가 크지 않다면 웹서버의 로그 분석 솔루션은 굳이 웹서버와 분리되어 운영할 필요가 없으나 본 방식은 스위치에서 타고다니는 패킷을 잡아오는 관계로 무조건 별도의 장비가 있어야만 한다. 그 밖에도 몇몇 단점은 존재하나 기존 방식에 비해 성능은 일단 후한 점수를 줄 수 있다.

 

하지만 사실 로그 분석 프로그램의 도입으로 원하는 편리함과 놀라운 고객 분석 패턴을 도출하는데에는 부족하다. 많은 웹로그 분석 솔루션 판매사들은 자사의 솔루션을 도입하면 엔지니어가 배제된 채 사이트의 트래픽 분석이 가능하며 컨텐츠를 고객의 선호도에 따라 유기적으로 반영할 수 있다라고 자랑한다.

짧게 말해 관리를 하는 사람이 줄어들고 효과적으로 컨텐츠를 운영할 수 있다고 한다. 또한 고객의 습성과 선호도 파악도 가능하며 앞으로의 의사결정에 필요한 기반 자료를 제공하는 것처럼 들린다.

 

하지만 여기까지는 환상이며 현실은 전혀 그렇지 못하다.

먼저로그를 분석하고 활용하기 위해선 CMS와 함께 도입되어야 한다. 컨텐츠를 생성하고 출판하며 배포하는 일렬의 과정이 방문자 로그 분석 시스템과 연동이 되어야 일단 관리의 효율이 살아난다. 수백 수천 페이지 분량의 웹사이트를 분석하는데 있어서 각각의 채널별로 컨텐츠를 담당하는 사람이 존재할 것이며 이들 컨텐츠 담당자들이 어떤 컨텐츠를 신규로 등록하고 어떤 컨텐츠를 프론트에서 제외되는지 로그 분석 담당자가 일일이 어떻게 추적한단 말인가.

그런 이유로 컨텐츠 관리 시스템은 필연적으로 로그 분석계와 함께 존재해야 하며 이들 시스템과의 연계는 필수라 할 수 있다.

 

고객의 패턴을 알기 위해선 또한각각의 시스템이 DW에의 통합이 필요하다. 단순히 로그를 분석한다고만 될까? 결론적으로 따져서 고객이 우리 웹사이트를 자주 방문케 하고 충성도를 높였다고 치자 그래서 무었을 우리는 원하는 걸까? 그것은 "구매"라는 고객의 행동이다. 아니면 반대로 "구매"라는 행동을 이미 하고 있는 고객이 있다면 그런 고객을 어떻게 하면 우리 회사 웹사이트의 서비스나 컨텐츠를 이용해 더 높은 액션율을 유도하는게 목적이다. 그렇다면 궁극적으로는 매출 DB와 고객 DB 그리고 사이트의 트래픽 DB가 함께 뭉쳐질 필요가 있으며 그래야 제대로 된 고객 분석이 된다는 것이다.Site Analysis와 CRM은 그렇게 통합될 필요가 있음을 인지해야만 할 것이다.

 

다음은 사람이 문제다. 자 시스템은 구비되었다. 이러한 시스템을 운영하는 마케터는 데이터를 OLAP과 같은 툴을 이용하여 데이터를 추출했다고 치자. 과연 그걸로 어떻게 결과를 돌출해야 하는 가가 문제이다. 물론 데이터 마이닝 툴이 이러한 문제를 해결해 주는 것처럼 또한번의 솔루션 판매자들은 현혹시킬 것이다. 하지만 실질적으로 이부분은 아직까지는 사람이 다루어야 할 영역이다. 왜냐하면 아직까지 어떠한 마이닝 시스템도 현업의 특성까지 파악된 결과를 마이닝해주지는 못하기 때문이다. 단지 아주 극히 일반적 현상에 대한 추론만이 가능할 뿐이다.

이에마케터는 현업의 특성을 이해하고 경험이 바탕이 되어 추론을 위한 데이터의 정제를 직접해주어야 한다는 것이다. 예를들어 온라인 프로모션을 실시하고 그 결과의 효율성을 레포팅하기 위해선 어떤 데이터가 추출되어야 하고 어떤 비교를 통해 어떻게 결론내려야 하는 가 하는 문제를 접했다고 치자. 이미 고객들은 구매를 하고 있었으며 그들의 거의 대부분은 멤버쉽 카드를 활용하여 구매를 진행한다고 한다는 전제도 깔려 있다. 그렇다면 마케터는 해당 프로모션에 참여한 고객들이 멤버쉽 고객인지 여부를 먼저 파악해야 한다. 그리고 그들이 해당 프로모션을 실시한 기간 중 매출과 평소의 매출을 비교해야 할 것이다. 단 외부 변수를 최대로 줄이기 위해 현재의 상황(프로모션을 실시하는 중)과 가장 유사한 기상적, 요일적 등등의 상황이 대변되는 표본 기간을 찾아내는 과정이 과연 마이닝 툴로 가능할까? 결국 이건 마케터의 경험과 업의 이해에서 나올 수 있다는 얘기이다.

 

즉 Site Analysis는 매우 중요한 도구이긴 하지만 이를 도입하는 배경에는 분명한 필요 요인이 존재해야 한다. 과연 사이트의 트래픽 요소를 어떻게 활용할지 이를 위해 얻을 수 있는 이익이 비용에 대한 합당한 수준인지 여부가 우선되어야 하며, 두번째로는 하나의 시스템의 도입으로 모두가 끝나지 않음을 인지하고 필요한 시스템을 함께 구현해야 한다는 것이다. 마지막으로 시스템은 존재하지만 이들 시스템을 운영할 적절한 전문인력이 필요할 것이다.