วิทยาศาสตร์ข้อมูล--ข้อมูลเว็บไซต์มาจากไหน?

หากคุณต้องการวิเคราะห์ข้อมูลเว็บไซต์ คุณต้องรู้ก่อนว่าข้อมูลเว็บไซต์มาจากไหน

เมื่อผู้ใช้เข้าถึงอินเทอร์เน็ต พวกเขาจะส่งคำขอบริการไปยังเซิร์ฟเวอร์ คำขอที่ส่งจะถูกบันทึกโดยเซิร์ฟเวอร์ในบันทึกของเซิร์ฟเวอร์ในบันทึกที่แยกต่างหาก นี่คือบันทึกข้อมูลเว็บไซต์ดั้งเดิมที่สุด

ก่อนอื่นให้ดูที่บันทึกของ apache

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 หรือโดยเบราว์เซอร์โดยตรง ในช่วงแรกๆ สถานที่นี้มักจะบันทึกที่อยู่อีเมลของผู้ชมไว้ อย่างไรก็ตาม ใช้งานได้ไม่นานเนื่องจากมีบางคนใช้เพื่อรวบรวมที่อยู่อีเมลและส่งสแปม และเบราว์เซอร์เกือบทั้งหมดในตลาดได้ลบคุณลักษณะนี้ออกไปนานแล้ว ดังนั้น ณ วันนี้ โอกาสที่เราจะเห็นที่อยู่อีเมลในรายการที่สองของบันทึกจึงน้อยมากจนแทบไม่เห็นเลย

· รายการที่สามก็เป็นผู้ใช้เช่นกัน ตำแหน่งนี้ใช้เพื่อบันทึกชื่อที่ผู้เยี่ยมชมให้ไว้เมื่อตรวจสอบสิทธิ์ แน่นอนว่าหากเนื้อหาบางอย่างบนเว็บไซต์ต้องการให้ผู้ใช้ตรวจสอบสิทธิ์ ข้อมูลนี้จะไม่เว้นว่าง อย่างไรก็ตาม สำหรับเว็บไซต์ส่วนใหญ่ที่ไม่ต้องการการยืนยันการเข้าสู่ระบบ รายการนี้จะยังคงว่างเปล่าในบันทึกส่วนใหญ่ในไฟล์บันทึก

· รายการที่สี่ที่บันทึกไว้ในบันทึกคือเวลาของการร้องขอ ข้อความนี้อยู่ในวงเล็บเหลี่ยมและอยู่ในรูปแบบที่เรียกว่า "รูปแบบบันทึกทั่วไป" หรือ "รูปแบบภาษาอังกฤษมาตรฐาน" ดังนั้น บันทึกบันทึกในตัวอย่างข้างต้นบ่งชี้ว่าเวลาของคำขอคือวันที่ 18 มีนาคม 2548 เวลา 12:21:42 น. ข้อมูล "+0800" ที่ส่วนท้ายของเวลาระบุว่าโซนเวลาของเซิร์ฟเวอร์ช้ากว่า UTC 8 ชั่วโมง จริงๆ แล้วเวลาของเซิร์ฟเวอร์ในประเทศคือ +8000

· ข้อมูลส่วนที่ห้าในบันทึกบันทึกอาจเป็นข้อมูลที่มีประโยชน์มากที่สุดในบันทึกบันทึกทั้งหมด ซึ่งบอกเราว่าเซิร์ฟเวอร์ได้รับคำขอประเภทใด รูปแบบทั่วไปของข้อมูลนี้คือ "Method Resource Protocol"

ในตัวอย่างข้างต้น วิธีการคือ GET วิธีการอื่นๆ ที่อาจปรากฏบ่อยครั้งคือ POST และ HEAD มีวิธีทางกฎหมายที่เป็นไปได้หลายวิธี แต่นี่คือสามวิธีหลัก

ทรัพยากรอ้างถึงเอกสารหรือ URL ที่เบราว์เซอร์ร้องขอจากเซิร์ฟเวอร์ ในตัวอย่างนี้ เบราว์เซอร์ร้องขอ "/stats/awstats.pl?config=user"

โดยปกติโปรโตคอลจะเป็น HTTP ตามด้วยหมายเลขเวอร์ชัน

· ข้อมูลที่หกที่บันทึกไว้คือรหัสสถานะ โดยจะแจ้งให้เราทราบว่าคำขอสำเร็จหรือไม่ หรือพบข้อผิดพลาดอะไร โดยส่วนใหญ่แล้วค่านี้คือ 200 ซึ่งหมายความว่าเซิร์ฟเวอร์ตอบสนองต่อคำขอของเบราว์เซอร์ได้สำเร็จและทุกอย่างเป็นปกติ โดยทั่วไป รหัสสถานะที่ขึ้นต้นด้วย 2 หมายถึงสำเร็จ รหัสสถานะที่ขึ้นต้นด้วย 3 หมายถึงคำขอของผู้ใช้ถูกเปลี่ยนเส้นทางไปยังตำแหน่งอื่นด้วยเหตุผลหลายประการ รหัสสถานะที่ขึ้นต้นด้วย 4 หมายความว่ามีข้อผิดพลาดบางอย่างในฝั่งไคลเอ็นต์ และ รหัสสถานะที่ขึ้นต้นด้วย 4 หมายความว่ามีข้อผิดพลาดบางอย่างในฝั่งไคลเอ็นต์ รหัสสถานะที่ขึ้นต้นด้วย 5 ระบุว่าเซิร์ฟเวอร์พบข้อผิดพลาด

· รายการที่เจ็ดในบันทึกบันทึกแสดงถึงจำนวนไบต์ทั้งหมดที่ส่งไปยังไคลเอนต์ มันบอกเราว่าการถ่ายโอนถูกขัดจังหวะหรือไม่ (เช่น ค่าเท่ากับขนาดของไฟล์หรือไม่) การเพิ่มค่าเหล่านี้ในบันทึกบันทึกจะบอกคุณว่าเซิร์ฟเวอร์ส่งข้อมูลไปเท่าใดในหนึ่งวัน สัปดาห์ หรือเดือน

· รายการที่แปดในบันทึกบันทึกจะบันทึกไดเร็กทอรีหรือ URL ที่ลูกค้าอยู่เมื่อทำการร้องขอ คราวนี้เป็น "http://10.1.1.1/pv/" ซึ่งเป็นหน้าแรกภายใต้ไดเร็กทอรี pv ของ 10.1.1.1 ในกรณีส่วนใหญ่ หน้าแรกจะเป็นไฟล์เว็บประเภทและชื่อที่ระบุหลังคำสั่ง DocumentRoot ใน httpd.conf

· รายการที่เก้าในบันทึกบันทึกแสดงถึงข้อมูลโดยละเอียดของลูกค้า

ข้างต้นเป็นคำอธิบายของบันทึกบันทึก Apache

จากนั้นสลับไปที่บันทึก IIS บันทึกจะคล้ายกัน ยกเว้นว่าการตรวจสอบสิทธิ์การเข้าสู่ระบบที่ส่งคืนโดย identd เนื่องจากว่างเปล่าอยู่เสมอ กลายเป็นเนื้อหาของคุกกี้ที่ส่งหรือรับ และมีเนื้อหาสถานะย่อยเพิ่มเติมบางส่วนของ โปรโตคอล.

ดังที่คุณเห็นจากด้านบน ข้อมูลส่วนใหญ่ที่เราวิเคราะห์สามารถรับได้ แต่ก็ยังมีปัญหาอยู่บ้าง เมื่อผู้ใช้คลิกปุ่มไปข้างหน้าและย้อนกลับบนเบราว์เซอร์ เบราว์เซอร์ของลูกค้าจะอ่านแคชก่อน และจะพบเฉพาะแคชเท่านั้น ในแคช หากไม่เป็นเช่นนั้น จะขอเซิร์ฟเวอร์อีกครั้ง ดังนั้น การที่เซิร์ฟเวอร์สามารถจำเพจได้หลังจากที่ผู้ใช้คลิกย้อนกลับหรือส่งต่อนั้นขึ้นอยู่กับวิธีการเขียนเพจและสถานะของเครื่องทั้งหมด

เมื่อใช้บันทึกดั้งเดิมเพื่อการวิเคราะห์ ระบบจะขอ iframe ขนาดเล็กและหน้าอื่นๆ แยกต่างหาก ส่งผลให้จำนวนคำขอเปิดหน้าไม่จำเป็นต้องเป็น 1 ครั้ง นี่เป็นข้อเสียบางประการของบันทึกดั้งเดิมเช่นกัน

ในเวลาเดียวกัน บันทึกเหล่านี้มีไว้เพื่อการติดตามสถานะเซิร์ฟเวอร์และความปลอดภัยของเซิร์ฟเวอร์เป็นหลัก และข้อมูลบางส่วนจะไม่ได้รับการบันทึก

· ไม่มีการบันทึกความสัมพันธ์ระหว่างเพจ และไม่มีความสัมพันธ์ระหว่างเพจที่ผู้ใช้เข้าถึง

· เป็นไปไม่ได้ที่จะแยกแยะการเข้าชมบางอย่างจากผู้ใช้ โดยเฉพาะเว็บไซต์ที่ไม่จำเป็นต้องเข้าถึงได้

· ไม่สามารถบันทึกการทำงานของเพจได้ โดยเฉพาะการดำเนินการคลิก

ดังนั้นบางเว็บไซต์จึงได้พัฒนาวิธีการบันทึกของตนเอง โดยปกติจะใช้ JS หรือการร้องขอภาพขนาดหนึ่งพิกเซลเพื่อบันทึกข้อมูลนี้

ด้วยวิธีนี้ ข้อมูลหลายส่วนจะถูกบันทึก รวมถึงผู้อ้างอิงของหน้าแหล่งที่มาที่เข้าชม หมายเลขเซสชัน หมายเลขคุกกี้ และข้อมูลที่สร้างขึ้นโดยการคลิก และข้อมูลเหล่านี้สามารถบันทึกลงในฐานข้อมูลได้โดยตรง

การใช้วิธีนี้จะช่วยลดความยากในการวิเคราะห์และเพิ่มข้อมูลที่สามารถวิเคราะห์ได้ แต่จะสูญเสียความแม่นยำในระดับหนึ่ง อาจกล่าวได้ว่ามีกำไรและขาดทุน

· อย่างแรกคือข้อมูลที่บันทึกได้ เนื่องจากมันถูกสร้างขึ้นบนไคลเอนต์ หากเกิดข้อผิดพลาดของเซิร์ฟเวอร์ ข้อมูลจะหายไป 100% เซิร์ฟเวอร์จะไม่ตอบสนองเลย ดังนั้นข้อมูลจะถูกส่งออกได้อย่างไร นอกจากนี้ เนื่องจากจำเป็นต้องเริ่มต้น js เพื่อส่งข้อมูล ข้อมูลทั้งหมดจะสูญหายไปในระดับหนึ่ง โดยทั่วไป เมื่อสถานะเซิร์ฟเวอร์ไม่แย่ อัตราความแม่นยำ 98% ก็เป็นที่ยอมรับได้

· ข้อมูลของหน้าต้นฉบับจะยังคงสูญหาย เนื่องจากความสัมพันธ์ระหว่างการข้ามหน้าและโปรโตคอล ทำให้หน้าต้นฉบับจำนวนหนึ่งสูญหายไป สิ่งที่เป็นปัญหากว่านั้นคือหน้า https ถูกส่งโดยใช้โปรโตคอลที่เข้ารหัส ไม่ว่าจะใช้วิธีไหนก็จะหายไปที่หน้า http

· ได้รับผลกระทบอย่างมากจากภาษาและโปรโตคอลของเพจ การโทรบนเพจ Ajax, js ฯลฯ อาจส่งผลต่อความถูกต้องของบันทึก

· สุดท้ายนี้ต้องเพิ่มโค้ดทุกหน้า อย่าประมาท หากมีหลายหน้า นี่ถือเป็นปัญหาจริงๆ หากลืมหน้านั้น จะส่งผลต่อข้อมูลโดยรวม

· ไม่พบ IP ของเครื่อง ณ จุดนี้และ IP ในบันทึก ในบางกรณีที่เครื่องหลายเครื่องใช้ IP ร่วมกัน สิ่งที่บันทึกไว้จะไม่ใช่ IP บนเครื่องสุดท้ายของผู้ใช้ IP บนเส้นทางการเข้าถึงอินเทอร์เน็ต

เพื่อสรุปผลข้างต้น สำหรับการวิเคราะห์เว็บไซต์ เนื่องจากความสัมพันธ์ระหว่างวิธีการรับข้อมูลและวิธีการเขียนโปรแกรมของเว็บไซต์นั้นค่อนข้างซับซ้อน คุณจึงต้องระมัดระวังมากขึ้นเมื่อวิเคราะห์ข้อมูลเว็บไซต์ ความล้มเหลวและกับดักในข้อมูลอาจเกิดขึ้นได้ เวลา.

ที่มาบทความ : สมุดบันทึกของแลนซ์