웹사이트 데이터를 분석하려면 먼저 웹사이트 데이터의 출처를 알아야 합니다.
사용자가 인터넷에 액세스하면 서버에 서비스 요청을 보냅니다. 전송된 요청은 서버 로그에 별도의 기록으로 기록됩니다. 이는 가장 원본인 웹사이트 데이터 로그입니다.
먼저 아파치 로그를 살펴보세요
10.1.1.95 - 사용자 [18/Mar/2005:12:21:42 +0800] “GET /stats/awstats.pl?config=user HTTP/1.1″ 200 899 “http://10.1.1.1/pv/” "Mozilla/4.0(호환; MSIE 6.0; Windows NT 5.1; Maxthon)"
위는 Apache의 표준 로그입니다.
이 콘텐츠 줄은 9개 항목으로 구성됩니다. 위의 예에서는 두 항목이 비어 있지만 전체 콘텐츠 줄은 여전히 9개 항목으로 나누어져 있습니다.
· 첫 번째 정보는 원격 호스트의 주소입니다. 즉, 방문자 컴퓨터의 IP입니다. 서버는 이 IP를 기반으로 방문자에게 응답 정보를 보냅니다.
· 두 번째 항목은 비어 있으며 "-" 자리 표시자로 대체됩니다. 실제로 이것은 대부분의 경우에 해당됩니다. 이 위치는 방문자의 로그인 이름뿐만 아니라 방문자의 이메일 주소 또는 기타 고유 식별자인 방문자의 신원을 기록하는 데 사용됩니다. 이 정보는 identd에 의해 반환되거나 브라우저에 의해 직접 반환됩니다. 초기에는 이 위치에 시청자의 이메일 주소가 기록되는 경우가 많았습니다. 하지만 일부 사람들이 이메일 주소를 수집하고 스팸을 보내는 데 사용했기 때문에 오래 가지 못했고, 시중에 나와 있는 거의 모든 브라우저에서는 오래 전에 이 기능을 제거했습니다. 따라서 오늘 현재 로그의 두 번째 항목에서 이메일 주소를 볼 가능성은 거의 없습니다.
· 세 번째 항목도 사용자입니다. 이 위치는 방문자가 인증 시 제공한 이름을 기록하는 데 사용됩니다. 물론 웹사이트의 일부 콘텐츠가 사용자 인증을 요구하는 경우 이 정보는 비어 있지 않습니다. 그러나 로그인 확인이 필요하지 않은 대부분의 웹 사이트의 경우 로그 파일의 대부분 기록에서 이 항목이 여전히 비어 있습니다.
· 로그에 기록되는 네 번째 항목은 요청 시간입니다. 이 메시지는 대괄호로 묶여 있으며 "공통 로그 형식" 또는 "표준 영어 형식"이라고 합니다. 따라서 위 예의 로그 기록은 요청 시간이 2005년 3월 18일 12시 21분 42초임을 나타냅니다. 시간 정보 끝부분의 "+0800"은 서버의 시간대가 UTC보다 8시간 늦다는 것을 나타냅니다. 실제로 국내 서버의 시간은 +8000입니다.
· 로그 기록의 다섯 번째 정보는 아마도 전체 로그 기록에서 가장 유용한 정보일 것입니다. 이는 서버가 어떤 종류의 요청을 받았는지 알려줍니다. 이 정보의 일반적인 형식은 "메소드 리소스 프로토콜"입니다.
위의 예에서 메소드는 GET입니다. 자주 나타날 수 있는 다른 메소드는 POST 및 HEAD입니다. 가능한 법적 방법은 다양하지만, 주요한 세 가지 방법은 다음과 같습니다.
리소스는 브라우저가 서버에 요청하는 문서 또는 URL을 의미합니다. 이 예에서는 브라우저가 "/stats/awstats.pl?config=user"를 요청했습니다.
프로토콜은 일반적으로 HTTP이고 그 뒤에 버전 번호가 옵니다.
· 기록된 여섯 번째 정보는 상태 코드입니다. 요청이 성공했는지 또는 어떤 오류가 발생했는지 알려줍니다. 대부분의 경우 이 값은 200입니다. 이는 서버가 브라우저의 요청에 성공적으로 응답했으며 모든 것이 정상임을 의미합니다. 일반적으로 2로 시작하는 상태 코드는 성공을 의미하고, 3으로 시작하는 상태 코드는 사용자 요청이 다양한 이유로 다른 위치로 리디렉션되었음을 의미하며, 4로 시작하는 상태 코드는 클라이언트 측에 일종의 오류가 있음을 의미합니다. 4로 시작하는 상태 코드는 클라이언트 측에 일종의 오류가 있음을 의미합니다. 5로 시작하는 상태 코드는 서버에 오류가 발생했음을 나타냅니다.
· 로그 레코드의 일곱 번째 항목은 클라이언트로 전송된 총 바이트 수를 나타냅니다. 전송이 중단되었는지 여부(즉, 값이 파일 크기와 동일한지 여부)를 알려줍니다. 로그 기록에 이러한 값을 더하면 서버가 하루, 일주일, 한 달 동안 보낸 데이터의 양을 알 수 있습니다.
· 로그 기록의 여덟 번째 항목에는 고객이 요청했을 때 있었던 디렉터리 또는 URL이 기록됩니다. 이번에는 10.1.1.1의 pv 디렉토리 아래의 홈 페이지인 "http://10.1.1.1/pv/"입니다. 대부분의 경우 홈 페이지는 httpd.conf의 DocumentRoot 지시문 다음에 지정된 유형과 이름의 웹 파일입니다.
· 로그 기록의 9번째 항목은 클라이언트의 세부 정보를 나타냅니다.
위는 Apache 로그 기록에 대한 설명입니다.
그런 다음 IIS 로그로 전환하면 identd에 의해 반환된 로그인 인증이 항상 비어 있고 전송 또는 수신된 쿠키의 내용이 되었으며 규약.
위에서 볼 수 있듯이 우리가 분석한 데이터는 대부분 얻을 수 있지만, 여전히 사용자가 브라우저의 앞으로 및 뒤로 버튼을 클릭하면 클라이언트의 브라우저가 캐시를 먼저 읽고 이를 찾는 데에만 문제가 있습니다. 그렇지 않은 경우 서버에 다시 요청합니다. 따라서 사용자가 뒤로 또는 앞으로 클릭한 후 서버가 페이지를 기억할 수 있는지 여부는 전적으로 페이지 작성 방식과 시스템 상태에 따라 달라집니다.
분석을 위해 원본 로그를 사용할 경우 일부 작은 iram 및 기타 페이지가 별도로 요청되므로 페이지 열기 요청 수가 반드시 1이 아닐 수도 있습니다. 이는 원본 로그의 몇 가지 단점이기도 합니다.
동시에 이러한 기록은 주로 서버 상태 추적 및 서버 보안을 위한 것이며 일부 데이터는 기록되지 않습니다.
· 페이지 간의 관계는 기록되지 않으며, 사용자가 어느 페이지에서 접속했는지 관계가 없습니다.
· 특정 방문과 사용자를 구별하는 것은 불가능하며, 특히 접근이 필요하지 않은 웹사이트의 경우 더욱 그렇습니다.
· 페이지 작업, 특히 클릭 작업은 기록할 수 없습니다.
따라서 일부 웹사이트에서는 일반적으로 JS를 사용하거나 이 정보를 기록하기 위해 1픽셀 이미지를 요청하는 등 자체 기록 방법을 개발했습니다.
이러한 방식으로 방문한 소스 페이지의 리퍼러, 세션 번호, 쿠키 번호, 클릭으로 생성된 데이터를 포함한 여러 정보가 기록됩니다. 그리고 이러한 데이터는 데이터베이스에 직접 기록될 수 있습니다.
이 방법을 사용하면 분석의 난이도가 낮아지고 분석할 수 있는 정보가 늘어나지만, 어느 정도 정확도가 희생됩니다. 득실도 있고 손해도 있다고 할 수 있습니다.
· 첫 번째는 기록 가능한 데이터인데, 서버에 오류가 발생하면 100% 데이터가 손실되는데, 어떻게 데이터를 출력할 수 있나요? 게다가, 데이터를 전송하기 위해서는 js를 시작해야 하기 때문에 어느 정도는 모든 데이터가 손실될 수 있습니다. 일반적으로 서버 상태가 나쁘지 않은 경우에는 98%의 정확도가 허용됩니다.
· 페이지 이동과 프로토콜 간의 관계로 인해 소스 페이지의 데이터가 여전히 손실됩니다. 더 문제는 https 페이지가 암호화된 프로토콜을 사용하여 전송된다는 것입니다. 어떤 방법을 사용하든 http 페이지에서는 해당 정보가 손실됩니다.
· 페이지의 언어, 프로토콜, Ajax, js 등의 영향을 많이 받아 기록의 정확성에 영향을 미칠 수 있습니다.
· 마지막으로 모든 페이지를 코드로 추가해야 합니다. 페이지가 많으면 해당 페이지를 잊어버리면 전체 데이터에 영향을 미치게 됩니다.
· 기기의 IP를 찾을 수 없습니다. 이 시점의 IP와 로그의 IP에는 약간의 차이가 있습니다. 여러 기기가 IP를 공유하는 경우 기록되는 내용은 사용자의 최종 기기에 있는 IP입니다. 인터넷 액세스 경로의 IP입니다.
이상을 종합하면, 웹사이트 분석은 데이터 수집 방식과 웹사이트 자체 프로그래밍 방식의 관계가 상대적으로 복잡하기 때문에 웹사이트 데이터를 분석할 때 어느 순간부터 데이터의 오류나 함정이 발생할 수 있으므로 더욱 주의가 필요합니다. 시간.
기사 출처: Lance's Notebook