علم البيانات - كيف تأتي بيانات موقع الويب؟

إذا كنت تريد تحليل بيانات موقع الويب، فيجب عليك أولاً معرفة من أين تأتي بيانات موقع الويب.

عندما يصل المستخدمون إلى الإنترنت، سيرسلون طلبات الخدمة إلى الخادم. يتم تسجيل الطلب المرسل بواسطة الخادم في سجل الخادم في سجل منفصل. هذا هو سجل بيانات موقع الويب الأكثر أصالة.

انظر أولاً إلى سجل أباتشي

10.1.1.95 - المستخدم [18/مارس/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 هذا.

· العنصر الثاني فارغ، وتم استبداله بالعنصر النائب "-". في الواقع، هذا صحيح في معظم الأوقات. يتم استخدام هذا الموقع لتسجيل هوية الزائر، وهو ليس فقط اسم تسجيل دخول الزائر، ولكن عنوان البريد الإلكتروني للزائر أو أي معرف فريد آخر. يتم إرجاع هذه المعلومات عن طريق المعرف، أو مباشرة عن طريق المتصفح. في الأيام الأولى، غالبًا ما كان هذا الموقع يسجل عنوان البريد الإلكتروني للمشاهد. ومع ذلك، لم يدم الأمر طويلاً لأن بعض الأشخاص استخدموه لجمع عناوين البريد الإلكتروني وإرسال البريد العشوائي، وقد قامت جميع المتصفحات الموجودة في السوق تقريبًا بإزالة هذه الميزة منذ وقت طويل. لذا، اعتبارًا من اليوم، فإن فرص رؤية عنوان بريد إلكتروني في الإدخال الثاني في السجل ضئيلة للغاية.

· العنصر الثالث هو المستخدم أيضًا. يستخدم هذا الموقع لتسجيل الاسم الذي قدمه الزائر عند المصادقة. بالطبع، إذا كان بعض المحتوى الموجود على موقع الويب يتطلب مصادقة المستخدم، فلن تكون هذه المعلومات فارغة. ومع ذلك، بالنسبة لمعظم مواقع الويب التي لا تتطلب التحقق من تسجيل الدخول، سيظل هذا الإدخال فارغًا في معظم السجلات في ملف السجل.

· البند الرابع المسجل في السجل هو وقت الطلب. هذه الرسالة محاطة بين قوسين مربعين وهي مكتوبة بما يسمى "تنسيق السجل العام" أو "تنسيق اللغة الإنجليزية القياسي". ولذلك، يشير سجل السجل في المثال أعلاه إلى أن وقت الطلب كان 18 مارس 2005، الساعة 12:21:42. تشير معلومات "+0800" في نهاية الوقت إلى أن المنطقة الزمنية للخادم متأخرة بمقدار 8 ساعات عن التوقيت العالمي المنسق (UTC). وفي الواقع، فإن وقت الخوادم المحلية هو +8000.

· ربما تكون المعلومة الخامسة في سجل السجل هي المعلومات الأكثر فائدة في سجل السجل بأكمله، فهي تخبرنا بنوع الطلب الذي تلقاه الخادم. التنسيق النموذجي لهذه المعلومات هو "بروتوكول موارد الطريقة".

في المثال أعلاه، الطريقة هي GET والطرق الأخرى التي قد تظهر بشكل متكرر هي POST وHEAD. هناك العديد من الطرق القانونية الممكنة، ولكن هذه هي الطرق الثلاثة الرئيسية.

يشير المورد إلى مستند، أو عنوان URL، يطلبه المتصفح من الخادم. في هذا المثال، طلب المتصفح "/stats/awstats.pl?config=user".

عادةً ما يكون البروتوكول HTTP، متبوعًا برقم الإصدار.

· الجزء السادس من المعلومات المسجلة هو رمز الحالة. يخبرنا ما إذا كان الطلب ناجحًا، أو ما الخطأ الذي تمت مواجهته. في أغلب الأحيان تكون هذه القيمة 200، مما يعني أن الخادم قد استجاب لطلب المتصفح بنجاح وأن كل شيء طبيعي. بشكل عام، رمز الحالة الذي يبدأ بـ 2 يعني النجاح، ورمز الحالة الذي يبدأ بـ 3 يعني أنه تمت إعادة توجيه طلب المستخدم إلى موقع آخر لأسباب مختلفة، ورمز الحالة الذي يبدأ بـ 4 يعني وجود نوع من الخطأ من جانب العميل، و رمز الحالة الذي يبدأ بالرقم 4 يعني وجود نوع من الخطأ من جانب العميل. تشير رموز الحالة التي تبدأ بالرقم 5 إلى أن الخادم واجه خطأ.

· يمثل الإدخال السابع في سجل السجل إجمالي عدد البايتات المرسلة إلى العميل. يخبرنا ما إذا كان النقل قد تمت مقاطعته (أي ما إذا كانت القيمة هي نفس حجم الملف). إن إضافة هذه القيم في سجلات السجل يخبرك بمقدار البيانات التي أرسلها الخادم في يوم أو أسبوع أو شهر.

· يسجل العنصر الثامن في سجل السجل الدليل أو عنوان URL الذي كان العميل يتواجد فيه عند تقديم الطلب. هذه المرة هي "http://10.1.1.1/pv/"، وهي الصفحة الرئيسية ضمن الدليل الكهروضوئي 10.1.1.1. في معظم الحالات، ستكون الصفحة الرئيسية عبارة عن ملف ويب من النوع والاسم المحددين بعد توجيه DocumentRoot في httpd.conf.

· العنصر التاسع في سجل السجل يمثل المعلومات التفصيلية للعميل.

ما ورد أعلاه هو شرح لسجلات سجل أباتشي.

ثم قم بالتبديل إلى سجل IIS، والسجلات متشابهة، باستثناء أن مصادقة تسجيل الدخول التي تم إرجاعها بواسطة identd، لأنها كانت فارغة دائمًا، أصبحت محتوى ملف تعريف الارتباط المرسل أو المستلم، وهناك بعض محتويات الحالة الفرعية الإضافية لـ بروتوكول.

كما ترون مما سبق، يمكن الحصول على معظم البيانات التي قمنا بتحليلها، ولكن لا تزال هناك بعض المشاكل. عندما ينقر المستخدم على زري الأمام والخلف في المتصفح، يقرأ متصفح العميل ذاكرة التخزين المؤقت أولاً، ويجدها فقط. إذا لم يكن الأمر كذلك، فسيتم إعادة طلب الخادم. لذلك، يعتمد ما إذا كان الخادم يمكنه تذكر الصفحة بعد نقر المستخدم للخلف أو للأمام بشكل كامل على طريقة كتابة الصفحة وحالة الجهاز.

عند استخدام السجلات الأصلية للتحليل، سيتم طلب بعض صفحات iframe الصغيرة وصفحات أخرى بشكل منفصل، مما يؤدي إلى عدم بالضرورة أن يكون عدد طلبات فتح الصفحة 1. وهذا أيضًا بعض عيوب السجلات الأصلية.

في الوقت نفسه، هذه السجلات مخصصة بشكل أساسي لتتبع حالة الخادم وأمن الخادم، ولا يتم تسجيل بعض البيانات.

· لا يتم تسجيل العلاقة بين الصفحات، ولا توجد علاقة بين الصفحة التي دخل المستخدم منها.

· من المستحيل تمييز زيارة معينة عن المستخدم، خاصة بالنسبة لمواقع الويب التي لا يشترط إمكانية الوصول إليها.

· لا يمكن تسجيل عمليات الصفحة، وخاصة عمليات النقر.

لذلك طورت بعض مواقع الويب طرق التسجيل الخاصة بها، وعادةً ما تستخدم لغة JS أو طلب صورة ذات بكسل واحد لتسجيل هذه المعلومات.

وبهذه الطريقة، يتم تسجيل عدة أجزاء من المعلومات، بما في ذلك مُحيل الصفحة المصدر التي تمت زيارتها، ورقم الجلسة، ورقم ملف تعريف الارتباط، والبيانات التي تم إنشاؤها بواسطة النقرة. ويمكن تسجيل هذه البيانات مباشرة في قاعدة البيانات.

إن استخدام هذه الطريقة يقلل من صعوبة التحليل ويزيد من المعلومات التي يمكن تحليلها، ولكنه يضحي بدرجة معينة من الدقة. ويمكن القول أن هناك مكاسب وخسائر.

· الأول هو البيانات القابلة للتسجيل، حيث أنها يتم إنشاؤها على العميل، فإذا حدث خطأ في الخادم، سيتم فقدان 100% من البيانات، ولا يستجيب الخادم على الإطلاق، فكيف يمكن إخراج البيانات؟ علاوة على ذلك، نظرًا لأنه يجب تشغيل Js لنقل البيانات، فسيتم فقدان جميع البيانات إلى حد ما. بشكل عام، عندما تكون حالة الخادم ليست سيئة، يكون معدل الدقة مقبولًا بنسبة 98٪.

· ستظل بيانات الصفحة المصدر مفقودة، نظرًا للعلاقة بين قفزات الصفحة والبروتوكولات، سيتم فقدان قدر معين من الصفحة المصدر، والأمر الأكثر إزعاجًا هو أن صفحات https يتم نقلها باستخدام بروتوكول مشفر، بغض النظر عن ذلك بغض النظر عن الطريقة المستخدمة، سيتم فقدانها على صفحة http.

· يتأثر بشكل كبير باللغة وبروتوكول الصفحة، وقد تؤثر المكالمات على الصفحة، مثل Ajax وjs وما إلى ذلك على دقة التسجيل.

· أخيرًا، يجب إضافة جميع الصفحات باستخدام الكود، ولا تقلل من شأن ذلك، إذا كان هناك العديد من الصفحات، فهذه مشكلة حقًا. إذا تم نسيان تلك الصفحة، فسوف يؤثر ذلك على البيانات الإجمالية.

· لا يمكن العثور على عنوان IP الخاص بالجهاز. توجد بعض الاختلافات بين عنوان IP في هذه المرحلة وعنوان IP الموجود في السجل. في بعض الحالات التي تشترك فيها أجهزة متعددة في عنوان IP، فإن ما يتم تسجيله ليس هو عنوان IP الموجود على الجهاز النهائي للمستخدم، بل IP على طريق الوصول إلى الإنترنت.

لتلخيص ما سبق، بالنسبة لتحليل موقع الويب، نظرًا لأن العلاقة بين طريقة الحصول على البيانات وطريقة البرمجة الخاصة بموقع الويب معقدة نسبيًا، يجب أن تكون أكثر حذرًا عند تحليل بيانات موقع الويب، فقد تحدث أي أعطال أو مصائد في البيانات وقت.

مصدر المقال: دفتر لانس