Google Analytics에서 clicks, visits, unique visits, unique visitors 등등의 차이

http://www.google.com/support/analytics/bin/answer.py?answer=47390&topic=7261 의 글을 봐서는 잘 눈에 들어오질 않네요. (아마 모든 용어를 한글로 바꾸어서 그런 듯)
일부를 나름 다시 정리하였습니다.
영단어가 그냥 섞여 있어서 내용이 더 눈에 안 들어올지도…

Clicks vs. Visits

  • Clicks: how many times your advertisements were clicked by visitors
  • Visits: the number of unique sessions initiated by your visitors

이 숫자는 일치하지 않는 경우가 많은데 그 이유는 다음과 같다.

  • 이용자가 여러번 click할 경우, 같은 session 에서는 1회 visit로 취급한다. (Multiple clicks, one visit)
  • 이용자가 1회 click한 다음, 나중에 다른 session 에서 북마크를 이용하여 해당 사이트로 직접 가는 경우. ‘referral information from the original visit’가 남아있기 때문에 ‘multiple visits’로 기록된다. (One click, multiple visits)
  • 이용자가 click을 했지만, 해당 페이지가 전부 로딩되기 전에 다른 페이지로 가버리거나 ‘stop’ 버튼을 누른 경우 트래킹 데이터는 서버로 전송되지 못한다. 그러나, AdWords는 click 수를 기록한다.

Visits vs. Unique Visits (방문수 vs. 고유방문수)

Visits는 개별 session 수를, Unique Visits는 어떤 주어진 기간 동안 이용자의 초기(initial) session을 나타낸다.

보통 해당 사이트에서 30분 동안 활동이 없으면 그 이후의 활동은 새로운 session으로 간주되며, 반면 사이트를 떠나 30분 이내에 돌아오는 이용자는 원래 session에 머무르는 것으로 간주한다.

또한 선택된 기간 동안 추가로 발생하는 방문은 모두 visit로 count 하지만, unique visit에서는 무시된다.

Visitors vs. Unique Visitors (방문자 수 vs. 고유 방문자 수)

일단 Visitor(방문자)란… 실제 사이트를 방문한 사람의 수를 최대한 정확히 표시하기 위해 만들어진 개념이다. 보통 cookie를 이용하여 판단한다.

“Daily Visitors” 레포트는 일일 단위로 unique visitors를 보여준다. 만약 이용자가 1주일 동안 하루에 한 번 씩 사이트를 방문한다면 “Daily Visitors” 레포트에 일자별로 1회씩 저장된다. 만약 이용자가 하루에 2회씩 방문한다고해도 “Daily Visitors” 레포트에는 해당 일에 1개의 unique visit로 취급한다.

반면 “Absolute Unique Visitor” 레포트는 선택된 기간 내 모든 visits를 묶어서 하나의 absolute unique visitor로 취급한다. (얼마나 여러 날에 걸쳐 방문을 했는가, 상이한 session 하에서 얼마나 자주 방문했는가 등등… 에 상관없이 무조건 하나)

“Absolute Unique Visitor” 레포트에서,

  • First Time Absolute Unique Visitors: 주어진 기간 내 사이트를 처음으로 방문하는 absolute unique visitor의 수
  • Prior Absolute Unique Visitors: 주어진 기간 ‘이전’에 사이트를 처음 방문했고 주어진 기간 내에 한 번 또는 그 이상 방문한 unique visitor의 수

Pageviews vs. Unique Views

Visit는 session을 의미한다는 것을 다시 한 번 염두에 두고…

이용자가 한 페이지에 도착한 다음 reload를 하면 추가 pageview로 간주한다. 또한 다른 페이지를 갔다가 다시 원래 페이지로 돌아와도 추가 pageview로 간주한다.

반면 “Top Content” 레포트에 나오는 Unique View는 같은 session 동안 같은 이용자에 의해 생성된 pageview를 모두 합친다. 즉 unique view는 페이지를 한 번 이상 조회한 session의 수를 나타낸다.

application 운영방향에 대하여

salesforce.com 관련 자료를 읽던 중 “No Software”라는 admonition의 부연설명에 아래와 같은 내용이 있더군요.

IT 가 할 수 있어야 하는 것

  • Customize apps
  • Build new apps
  • Integrate seamlessly
  • Respond quickly to change

IT 가 하지 말았어야 하는 것

  • Manage hardware infrastructure
  • Upgrade or patch software
  • Tune databases
  • Worry about backups or disaster recovery

물론 salesforce.com이란 CRM Tool 입장에서 언급한 내용이고 매사 무 자르듯이 이 일은 hosting part, 저 일은 application part 하는 식으로 접근할 수는 없지만, 기본 방향만은 확실히 마음에 새겨두는 것이 좋을 것 같습니다.

우선순위를 정할 때 도움이 많이 되거든요.

요구사항에 따른 서비스 분류

Site Renewal에 대한 ‘유사’ RFP 작성 중 문득 중요한 원칙 하나가 여태껏 주먹구구식으로 처리되었었다는 생각이 들었습니다.

대형 Web Site를 위한 기간 시스템은 안정성, 보안 등 그 목적에 맞게 구성되어 있지만, 급변하는 Web 요구사항에 flexible하게 대응하는데에는 한계가 있습니다. 다양한 open source solution을 이용하여 요구사항을 처리하는 것도 방법이지만 보안이라든가 기술지원에 있어 제약사항이 있구요.

전체적인 그림을 다시 확인하고, 해당 기능들을 classification 해야겠어요. 즉,

  • Class 1: 반드시 현 기간 시스템 내에서 처리되어야 할 서비스
  • Class 2: 현 시스템에서도 처리 가능하지만, 기간 infra가 아닌 별도의 flexible한 zone을 마련하여 기간 시스템과 ‘느슨한’ 연결을 하는 서비스
  • Class 3: 기간 infra로 처리하기 힘들거나 처리할 성격이 아니라고 판단, 외부에서 처리될 서비스

시스템 및 서비스의 면면들을 충분히 check 한 후에야 정확한 작업이 가능하겠지만 꼭 필요할 것 같습니다.