Wenn Sie Website-Daten analysieren möchten, müssen Sie zunächst wissen, woher die Website-Daten stammen.
Wenn Benutzer auf das Internet zugreifen, senden sie Dienstanfragen an den Server. Die gesendete Anfrage wird vom Server in einem separaten Datensatz im Serverprotokoll aufgezeichnet. Dies ist das ursprünglichste Website-Datenprotokoll.
Schauen Sie sich zunächst das Apache-Protokoll an
10.1.1.95 – Benutzer [18.03.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 (kompatibel; MSIE 6.0; Windows NT 5.1; Maxthon)“
Das Obige ist ein Standardprotokoll von Apache.
Diese Inhaltszeile besteht aus 9 Elementen. Im obigen Beispiel sind zwei Elemente leer, die gesamte Inhaltszeile ist jedoch weiterhin in 9 Elemente unterteilt.
· Die erste Information ist die Adresse des Remote-Hosts. Das heißt, die IP des Computers des Besuchers. Basierend auf dieser IP sendet der Server Antwortinformationen an den Besucher.
· Das zweite Element ist leer und wird durch einen „-“-Platzhalter ersetzt. Tatsächlich ist dies meistens der Fall. Dieser Ort wird verwendet, um die Identifikation des Besuchers aufzuzeichnen. Dabei handelt es sich nicht nur um den Anmeldenamen des Besuchers, sondern auch um seine E-Mail-Adresse oder eine andere eindeutige Kennung. Diese Informationen werden von identd oder direkt vom Browser zurückgegeben. In der Anfangszeit wurde an diesem Ort häufig die E-Mail-Adresse des Betrachters erfasst. Allerdings hielt es nicht lange an, da einige Leute es zum Sammeln von E-Mail-Adressen und zum Versenden von Spam nutzten und fast alle Browser auf dem Markt diese Funktion vor langer Zeit entfernt haben. Daher ist die Wahrscheinlichkeit, dass wir im zweiten Eintrag im Protokoll eine E-Mail-Adresse sehen, derzeit gering bis gleich Null.
· Das dritte Element ist ebenfalls Benutzer. Dieser Ort wird verwendet, um den Namen aufzuzeichnen, den der Besucher bei der Authentifizierung angegeben hat. Wenn für einige Inhalte auf der Website eine Authentifizierung des Benutzers erforderlich ist, sind diese Informationen natürlich nicht leer. Bei den meisten Websites, die keine Anmeldebestätigung erfordern, ist dieser Eintrag jedoch in den meisten Datensätzen der Protokolldatei immer noch leer.
· Das vierte im Protokoll aufgezeichnete Element ist der Zeitpunkt der Anfrage. Diese Nachricht steht in eckigen Klammern und liegt im sogenannten „Common Log Format“ oder „Standard English Format“ vor. Daher gibt der Protokolldatensatz im obigen Beispiel an, dass die Anforderungszeit der 18. März 2005, 12:21:42 Uhr war. Das „+0800“ am Ende der Zeitangabe zeigt an, dass die Zeitzone des Servers 8 Stunden hinter UTC liegt. Tatsächlich beträgt die Zeit auf inländischen Servern +8000.
· Die fünfte Information im Protokolldatensatz ist möglicherweise die nützlichste Information im gesamten Protokolldatensatz. Sie sagt uns, welche Art von Anfrage der Server erhalten hat. Das typische Format dieser Informationen ist „Method Resource Protocol“.
Im obigen Beispiel ist die Methode GET. Andere Methoden, die häufig vorkommen, sind POST und HEAD. Es gibt viele mögliche rechtliche Methoden, aber dies sind die drei wichtigsten.
Eine Ressource bezieht sich auf ein Dokument oder eine URL, die ein Browser vom Server anfordert. In diesem Beispiel hat der Browser „/stats/awstats.pl?config=user“ angefordert.
Das Protokoll ist normalerweise HTTP, gefolgt von einer Versionsnummer.
· Die sechste protokollierte Information ist der Statuscode. Es sagt uns, ob die Anfrage erfolgreich war oder welcher Fehler aufgetreten ist. Meistens liegt dieser Wert bei 200, was bedeutet, dass der Server erfolgreich auf die Anfrage des Browsers geantwortet hat und alles normal ist. Im Allgemeinen bedeutet ein Statuscode, der mit 2 beginnt, Erfolg, ein Statuscode, der mit 3 beginnt, bedeutet, dass die Benutzeranfrage aus verschiedenen Gründen an einen anderen Ort umgeleitet wurde, ein Statuscode, der mit 4 beginnt, bedeutet, dass auf der Clientseite ein Fehler vorliegt, und Ein Statuscode, der mit 4 beginnt, bedeutet, dass auf der Clientseite ein Fehler vorliegt. Statuscodes, die mit 5 beginnen, weisen darauf hin, dass auf dem Server ein Fehler aufgetreten ist.
· Der siebte Eintrag im Protokolldatensatz stellt die Gesamtzahl der an den Client gesendeten Bytes dar. Es verrät uns, ob die Übertragung unterbrochen wurde (d. h. ob der Wert mit der Größe der Datei übereinstimmt). Durch Addition dieser Werte in den Protokolldatensätzen erfahren Sie, wie viele Daten der Server an einem Tag, einer Woche oder einem Monat gesendet hat.
· Das achte Element im Protokolldatensatz zeichnet das Verzeichnis oder die URL auf, in der sich der Kunde befand, als er die Anfrage stellte. Diesmal ist es „http://10.1.1.1/pv/“, die Homepage im pv-Verzeichnis von 10.1.1.1. In den meisten Fällen handelt es sich bei der Homepage um eine Webdatei des Typs und Namens, der nach der DocumentRoot-Direktive in httpd.conf angegeben ist.
· Das neunte Element im Protokolldatensatz stellt die detaillierten Informationen des Kunden dar.
Das Obige ist eine Erklärung der Apache-Protokolldatensätze.
Wechseln Sie dann zum IIS-Protokoll. Die Datensätze sind ähnlich, mit der Ausnahme, dass die von identd zurückgegebene Anmeldeauthentifizierung, da sie immer leer war, zum Inhalt des gesendeten oder empfangenen Cookies geworden ist und es einige zusätzliche Unterzustandsinhalte gibt Protokoll.
Wie Sie oben sehen können, können die meisten der von uns analysierten Daten abgerufen werden, es gibt jedoch immer noch einige Probleme. Wenn der Benutzer auf die Vorwärts- und Zurück-Schaltflächen im Browser klickt, liest der Browser des Clients zuerst den Cache und findet ihn nur Wenn nicht, wird der Server erneut angefragt, ob er sich die Seite merken kann, nachdem der Benutzer auf „Zurück“ oder „Vorwärts“ geklickt hat.
Wenn Originalprotokolle für die Analyse verwendet werden, werden einige kleine IFRAMS und andere Seiten separat angefordert, was dazu führt, dass die Anzahl der Anfragen zum Öffnen einer Seite nicht unbedingt 1 beträgt. Dies ist auch einer der Nachteile der Originalprotokolle.
Gleichzeitig dienen diese Aufzeichnungen hauptsächlich der Verfolgung des Serverstatus und der Serversicherheit, und einige Daten werden nicht aufgezeichnet.
· Die Beziehung zwischen Seiten wird nicht aufgezeichnet und es besteht keine Beziehung zwischen der Seite, von der aus der Benutzer zugegriffen hat.
· Es ist unmöglich, einen bestimmten Besuch von einem Benutzer zu unterscheiden, insbesondere bei Websites, die nicht barrierefrei sein müssen.
· Seitenvorgänge, insbesondere Klickvorgänge, können nicht aufgezeichnet werden.
Daher haben einige Websites ihre eigenen Aufzeichnungsmethoden entwickelt, die normalerweise JS verwenden oder ein Ein-Pixel-Bild anfordern, um diese Informationen aufzuzeichnen.
Auf diese Weise werden mehrere Informationen erfasst, darunter der Referrer der besuchten Quellseite, die Sitzungsnummer, die Cookie-Nummer und die durch den Klick generierten Daten. Und diese Daten können direkt in der Datenbank erfasst werden.
Die Verwendung dieser Methode verringert zwar die Schwierigkeit der Analyse und erhöht die Menge der analysierbaren Informationen, geht jedoch zu Lasten eines gewissen Grades an Genauigkeit. Man kann sagen, dass es Gewinne und Verluste gibt.
· Das erste sind aufzeichnbare Daten. Da sie auf dem Client generiert werden, gehen 100 % der Daten verloren. Der Server antwortet überhaupt nicht. Wie können die Daten also ausgegeben werden? Da zum Übertragen von Daten außerdem js gestartet werden muss, gehen alle Daten bis zu einem gewissen Grad verloren. Wenn der Serverstatus nicht schlecht ist, ist im Allgemeinen eine Genauigkeitsrate von 98 % akzeptabel.
· Die Daten der Quellseite gehen trotzdem verloren. Aufgrund der Beziehung zwischen Seitensprüngen und Protokollen geht ein gewisser Teil der Quellseite verloren. Was noch problematischer ist, ist, dass https-Seiten unabhängig davon über ein verschlüsseltes Protokoll übertragen werden Egal welche Methode verwendet wird, sie geht auf der http-Seite verloren.
· Es wird stark von der Sprache und dem Protokoll der Seite beeinflusst. Aufrufe auf der Seite, Ajax, js usw. können die Genauigkeit der Aufzeichnung beeinträchtigen.
· Schließlich müssen alle Seiten mit Code hinzugefügt werden. Wenn es viele Seiten gibt, wird dies tatsächlich ein Problem sein.
· Die IP der Maschine kann nicht gefunden werden. Es gibt einige Unterschiede zwischen der IP an dieser Stelle und der IP im Protokoll. In einigen Fällen, in denen mehrere Maschinen eine IP teilen, wird nicht die IP auf der endgültigen Maschine des Benutzers aufgezeichnet die IP auf der Internet-Zugangsroute.
Zusammenfassend lässt sich sagen, dass bei der Website-Analyse die Beziehung zwischen der Datenerfassungsmethode und der Website-eigenen Programmiermethode relativ kompliziert ist und Sie bei der Analyse von Website-Daten vorsichtiger sein müssen Zeit.
Quelle des Artikels: Lances Notizbuch