1. Server Monitor

Server Monitore werden als Server Plug-In realisiert und zeichnen alle serverseitigen Ereignisse auf. Im Unterschied zu normalen Webserver-Logfiles werden die erhobenen Daten in Echtzeit an ein Data Warehouse übertragen und können sofort ausgewertet werden.

Problematisch wird der Einsatz von Server Monitoren jedoch, wenn ein Unternehmen mehrere Webserver parallel betreibt. Um hier ein vollständiges Bild vom Nutzerverhalten zu erhalten, müssen die Daten der verschiedenen Server zusammengefasst werden. Dies kann sehr aufwändig und fehlerbehaftet sein.

2. Network Monitor (Packet Sniffer)

Eine mögliche Lösung wäre der Einsatz eines Network Monitors (Packet Sniffers). Dieser ist zwischen dem Internet und der Serverfarm angesiedelt und protokolliert passiv alle versandten TCP-/IP-Pakete.

Da ein Network Monitor im Gegensatz zum Webserver auf einer niedrigeren Netzwerkschicht kommuniziert, hat er Zugriff auf weitergehende Informationen. Dies sind neben der Bestätigung, dass die vom Webserver versandten Daten den Empfänger erreicht haben, auch Informationen über:

• Client-initiated disconnects (z.B. Stop-Button während einem Download gedrückt)
• Netzwerkprobleme (z.B. Server retransmissions wegen überlasteten Netzwerken)
• Busy signals (z.B. Ignorierte Anfragen wegen einem überlasteten Server)
• Die Zeit, die der Server zum Antworten gebraucht hat

Mit einem Network Monitor können also zusätzliche Informationen über die technischen Rahmenbedingungen (Geschwindigkeit, Qualität und Ausfallsicherheit) gesammelt werden – alles Werte, die für die Qualität eines Internetauftritts von grundlegender Bedeutung sind.

3. Reverse Proxy Monitor

Noch weiter als Packet Sniffing geht ein Reverse Proxy Monitor (RPM), welcher den Kommunikationsstrom zwischen Client und Webserver nicht nur filtert, sondern auch gezielt verändert. Auf diese Weise lassen sich zusätzliche Informationen erheben (z.B. CGI-Parameter oder semantische Schlagworte). Angesiedelt wird ein Reverse Proxy Monitor, wie auch ein Network Monitor, zwischen dem Internet und dem Webserver.

Ein bekannter Anbieter dieser Technik ist die Firma SiteSpect. Ihr RPM ermöglicht neben der Datenerhebung und Analyse auch eine einfache Realisierung von A/B- und multivariaten Tests. Alle Analysen und Contentvariationen werden dabei vom RPM on the fly umgesetzt.  Es sind also keinerlei Änderungen an den Inhalten auf dem Webserver nötig.

Diese Techniken zur Netzwerküberwachung haben einige Vor- und Nachteile.

Von Vorteil ist:

• Andere Verfahren zur Datenerhebung sind überflüssig
• Es können live und zentral so viele Daten gesammelt werden wie mit keiner anderen Methode. Dazu gehören zum Beispiel neben den üblichen Geschäftsdaten auch technische Informationen wie Serverfehler und Auslastungsdaten.
• RPMs ermöglichen es, immer First Party Cookies einzusetzen

Von Nachteil ist allerdings:

• Die Installation eines solchen Systems erfordert einiges Know-how, Konfigurationsarbeit und Zugriff auf das Netzwerk.
• In den Rohdaten können brisante Informationen wie Passwörter, Adressdaten und Kreditkartennummern unverschlüsselt vorhanden sein. Folglich sind einige Anstrengungen erforderlich, um das System auch datenschutzrechtlich sicher zu gestalten.
• Auch ein RPM stößt an seine Grenzen, wenn der Browser Daten aus dem Cache lädt oder massiv Flash eingesetzt wird.
• Ist die Datenerhebung vom Daten ausliefernden Webserver separiert, können anhand der Logfiles die Entscheidungskriterien (z.B. Zielgruppeneigenschaften) die zur Auslieferung eines bestimmten, dynamisch generierten Contents geführt haben, nicht mehr nachvollzogen werden.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Übersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking zu finden.

Grundlage: Die Datenübertragung im WWW

Die Datenübertragung im WWW basiert auf einem Client-Server-Ansatz. Alle vom Besucher initiierten Aktionen werden von seinem Computer (Client) in Anforderungen (Requests) umgewandelt und an einen anderen Computer, z.B. einen Webserver weitergeleitet, der die angeforderten Ressourcen liefert (Response).

HTML-Dokumente werden mittels HTTP (Hypertext Transfer Protocol) an den Client übertragen. Das HTTP ist ein verbindungsloses Protokoll, bei dem die Datenpakete aus Performancegründen einzeln versandt werden. Die Verbindung zwischen Client und Server wird nach jeder Übertragung wieder getrennt, weshalb ein Logfile keinen zusammenhängenden Nutzungsstrom, sondern lediglich eine Auflistung aller bearbeiteten Anfragen zeigt. So resultiert der Aufruf einer einzigen HTML-Seite in der Regel in zahlreichen Logfile-Einträgen, wobei jede eingehende Anfrage (Dokument, Bilder, CSS-Dateien, etc.) in einer neuen Zeile des Logfiles gespeichert wird. Dies hat zur Folge, dass Logfiles immense Ausmaße annehmen können.

Formate und Inhalte von Webserver-Logfiles

Es existieren derzeit etwa 30 standardisierte Logfile-Formate, die mehr oder minder weit verbreitet sind. Die Formate unterscheiden sich in den Angaben, die der Server pro Zeile (Hit) festhält. Felder zu Anfragen, die in einem bestimmten Log-Format festgehalten werden könnten, aber nicht verfügbar sind, werden in den Logfiles mit einem „-“ gekennzeichnet.

Im Allgemeinen werden folgende Werte in den Logfiles festgehalten:

• der Zugriffszeitpunkt
• die angeforderten Inhalte
• der zugreifende Browser
• die Adresse des Clients
• eventuell auftretende Fehler.

In Anlehnung an diese Inhalte haben sich vier Grundformen herausgebildet: Access Log, (Browser) Agent Log, Referrer Log und Error Log. Diese Dateien können je nach Systemkonfiguration getrennt oder in Kombination angelegt werden.

Als Standardformat des Access Log wurde das Common Logfile Format (CLF) entwickelt. Das Combined Logfile-Format (oder auch Extended Common Logfile Format – ECLF) erweitert das CLF um die Inhalte des Agent- und Referrer Log. Die folgende Abbildung zeigt zusätzlich die Unterteilung der Inhalte in Grunddaten über den Besucher und Interaktionsdaten über die ausgelieferten Inhalte.

Eine Zeile aus dem Log des Formats ECLF könnte zum Beispiel so aussehen:

 88.217.105.216 - - [24/Jul/2008:12:31:57  +0200]
 "GET /wp-admin/ HTTP/1.1" 200 50484 "http://www.georg-weidner.de/"
 "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1)  Gecko/2008070208 Firefox/3.0.1"

Die einzelnen Bestandteile (Felder eines Webserver-Logfiles des Formats ECLF) sind:

Eine Analyse der Daten zeigt, dass am 24 Juli 2008 um 12:31 Uhr und 57 Sekunden das Verzeichnis wp-admin von der IP-Adresse 88.217.105.216 aufgerufen wurde. Dabei fanden weder eine Clientidentifizierung noch eine Clientauthentifizierung statt, weshalb die entsprechenden Felder frei geblieben sind (mit einem „-“ gekennzeichnet). Das transferierte Datenvolumen belief sich auf 50.484 Bytes. Am Status-Code 200 ist zu erkennen, dass die Übertragung erfolgreich war.

Im Referrer- und User-Agent-Zusatz ist zudem festgehalten, dass der Aufruf von der Seite http://www.georg-weidner.de aus erfolgte, der Besucher Windows NT 5.1 (Windows XP) nutzt, mit dem Firefox-Browser Version 3.0.1 surft und als bevorzugte Sprache Deutsch (de) angegeben hat.

Statusinformationen

Ein wichtiger Bestandteil, welcher in fast allen Logfile-Formaten vorgesehen ist, ist die Angabe von Statusinformationen. Dem HTTP folgend verwenden Server eine dreistellige Zahl, die angibt wie die Anfrage serverseitig bearbeitet werden konnte. Den so genannten Status Code sendet der Webserver zum anfragenden Browser und schreibt ihn zudem in das Logfile. Es gilt zu beachten, dass die meisten Browser nicht alle in HTTP/1.0 definierten Status Codes unterstützen.

Beispiele für HTTP Status-Codes:
200 OK – Erfolgreiche Bearbeitung der Anfrage (wie im Beispiel oben)
304 Das Dokument wurde seit dem letzten Abruf nicht modifiziert: Abruf vom Browser-Cache
404 Dokument wurde nicht gefunden
500 Interner Server Error

Die Systematik des Codes leitet sich von der ersten Ziffer her:
1xx Gegenwärtig nicht benutzt, reserviert für zukünftige Erweiterungen des HTTP
2xx Erfolgreiche Bearbeitung der Anfrage
3xx Weitere Aktionen zur Bearbeitung der Anfrage erforderlich
4xx Clientseitiger Error (z.B. Syntaxfehler in der Anfrage)
5xx Serverseitiger Error (z.B. Überlastung des Servers)

Mit Server-Logfiles lassen sich umfangreiche Daten erheben:

• Wer besuchte wann die Webseite
• Woher kommen die Besucher
• Wie navigieren die Besucher durch die Webseite
• Hinweise auf mögliche technische Probleme

Allerdings haben Server-Logfiles einige entscheidende Nachteile:

• Große Probleme bei der Datenspeicherung in Caches
• Zugriff von virtuellen Nutzern wie Spidern und Robots gehen mit in die Logfiles ein
• Der Umfang der Logdateien wächst sehr schnell
• Eine Identifikation wiederkehrender Besucher kann problematisch sein

Eine genauere Erläuterung der Probleme von Webserver-Logfiles und entsprechende Maßnahmen wird im später unter “Datenaufbereitung” näher behandelt.

Von grundlegendem Vorteil jedoch ist, dass Logfiles sowieso vom Server erzeugt werden. Es müssen also keine zusätzlichen Anstrengungen unternommen werden um Daten zu erheben. Weiterhin handelt es sich um eine nicht-reaktive Erhebung von Daten: Der Nutzer erfährt hiervon nichts und hat auch keine Möglichkeit die Logfile-Einträge zu beeinflussen.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Übersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking zu finden.

Der Begriff des Usertracking lässt sich bezogen auf das Internet in drei Schritte unterteilen

• Die Datenerhebung
• Die Datenaufbereitung und -speicherung
• Die Datenanalyse und -verwendung

Bei der Datenerhebung geht es zunächst darum, wie der Webseiten-Besuch eines Besuchers überhaupt registriert wird. Daten die nicht registriert wurden, können später zur Auswertung nicht herangezogen werden. Das Vorgehen muss zudem sorgfältig geplant sein, um qualitativ hochwertige Daten zu erhalten, denn aus einer schlechten Datenqualität lassen sich keine aussagekräftigen Statistiken erstellen.

Die erhobenen Daten müssen zunächst aufbereitet werden. Dazu zählt das Entfernen unwichtiger oder falscher Daten und das Aggregieren zu Standardmetriken. Die daraufhin folgende Speicherung der Daten in einer Datenbank ist keine triviale Angelegenheit und will gut geplant sein, um später alle gewünschten Analysen zu ermöglichen.

Vor der finalen Datenanalyse und -verwendung gibt es wichtige, grundlegende Aspekte zu beachten. Mit der Einbindung weiterer Datenquellen können wertvolle Einblicke in online-offline Zusammenhänge ermöglicht werden. Schließlich ist es mit den Informationen aus dem Usertracking möglich, die Usability der Webseite zu verbessern oder Webseiten zielgruppenspezifisch auszuliefern.

Die Verfahren der Datenerhebung

Zur Erhebung von Daten stehen im Internet eine Vielzahl von Verfahren zur Verfügung. Diese können nach verschiedenen Kriterien wie z.B. technischen Eigenschaften oder der Partizipation des Users am Erhebungsprozess unterschieden werden.

Weit verbreitet ist die Unterscheidung anhand des Bewusstseins des Users über die Aufzeichnung der Daten, zwischen einer reaktiven und nicht-reaktiven Datenerhebung. Während es eine nicht-reaktive Datenerhebung erlaubt, Aspekte des Besucherverhaltens relativ frei von Störeinflüssen zu erheben, ist es dem Besucher bei einer reaktiven Datenerhebung bewusst, dass Daten über ihn erfasst werden. Folglich reagiert er möglicherweise anders.

Allerdings gilt zu beachten, dass diese Einteilung nicht ganz problemfrei ist. So sind die Verfahren nicht gänzlich voneinander zu trennen, da es stark auf das spezielle Wissen und die Erwartungen des Besuchers ankommt. Womöglich hat er einen kritischen Beitrag gelesen und erwartet nun sogar, dass viel mehr Daten erhoben werden als dies der Fall ist.

Grundlegend gilt zu beachten, dass zur Analyse aller Besucher einer Webseite eine Methode zum Erheben der Daten oft nicht ausreicht. Zum Beispiel führen die meisten Robots keinen JavaScript-Code aus, weshalb sie mit auf JavaScript basierenden Techniken nicht registriert werden können. Sollen sie erfasst werden, muss unter Umständen auf eine zusätzliche Methode zur Datenerhebung zurückgegriffen werden.

Dieser Artikel entstammt meiner Diplomarbeit zum Thema “Usertracking”. Ich habe lange überlegt wie und in welcher Form ich die Arbeit veröffentlichen könnte und bin zum Schluss gekommen, dass meine Erkenntnisse daraus, über diesen Blog veröffentlicht, dem größten Publikum dienen können.

Eine Übersicht über weitere Artikel und ein Quellenverzeichnis sind unter
http://www.georg-weidner.de/usertracking/ zu finden.

Das nächste Kapitel behandelt die Datenerhebung mittels Webserver-Logfiles

Entwickelt wurde das System von der Firma WSP. Jedes Fahrzeug führt einen GPS-Sensor mit sich, welcher die aktuellen Positionsdaten per W-Lan an einen WSP-Server sendet. Dieser visualisiert die Positionen auf einer Google Map – sekündlich aktualisiert.

Und auch wenn das Angebot für normale Kunden vielleicht noch ein bisschen technischer Overkill ist, für die Flottenplanung und Entstörung ist die Technik sicherlich sehr hilfreich… mal davon abgesehen, dass sie einfach nur genial ist!

Live anschauen? => hier *klick*.

Hinweis: Klick auch mal auf ein Fahrzeug!

Web-Bugs sind 1×1 Pixel kleine, transparente Bilder welche z.B. in E-Mails oder auf Webseiten eingebaut werden. Öffnet ein User die E-Mail oder besucht er eine Webseite, wird das Web-Bug wie ein normales Bild geladen – bleibt für den Menschen aber unsichtbar.

Das tolle für den Marketer ist, dass er das Web-Bug von einem beliebigen Server einbinden kann – und immer wenn ein E-Mailprogramm oder ein Browser, etc. etwas von einem Server laden (hier das Web-Bug), darf der Server auf seine Cookies zugreifen (oder neue setzen). Auch erscheint der Aufruf natürlich in den Log-Files des Servers.

Auf die vielen Möglichkeiten die sich mit Cookies bieten möchte ich hier jetzt nicht weiter eingehen, denn auch sehr tolle Dinge kann man machen, wenn das Web-Bug auf dem Server gar kein echtes Bild ist, sondern z.B. ein php-Script.

Zur Veranschaulichung wollen wir uns jetzt ein Web-Bug bauen:

Voraussetzung für dieses sehr einfach Beispiel ist lediglich etwas Webspace mit installiertem mod_rewrite.

Erstellen wir also eine php-Datei mit folgendem Inhalt – das wird unser Web-Bug:

header("Content-Type: image/gif");
 
$width = 1;
$height = 1;
 
$id = ImageCreate($width,$height);
$black = ImageColorAllocate($id, 0, 0, 0);
$white = ImageColorAllocate($id, 255, 255, 255);
$trans = ImageColorTransparent($id, $white);
 
imagefill($id, 0,0, $white);
 
if (function_exists("imagegif"))
{
	Header("Content-type: image/gif");
	ImageGif($id);
}
else
	die("Keine Grafik-Unterstützung vorhanden");
 
ImageDestroy($id);

Das php-Script macht nun nichts anderes, als ein transparentes gif-Bild zu rendern und zurück zu geben.

Standardinformationen über den User lassen sich nun ganz einfach tracken, indem wir Abfragen wie folgende in das php-Script einbauen und die Informationen in unserer Datenbank speichern:

$time = time();
$ip = $_SERVER[REMOTE_ADDR];
$host = gethostbyaddr($ip);

Das wirklich interessante aber ist die Möglichkeit, dem Web-Bug weitere Informationen in Form von angehängten Parametern zu übergeben.
Der Aufruf sähe dann z.B. so aus: http://www.georg-weidner.de/webbug.php?userid=1234
Und ist in der php-Datei auslesbar mit:

$userid = $_REQUEST["userid"];

Baut man in jeder versendeten E-Mail ein Webbug mit einer eindeutigen ID ein, ist somit ganz einfach nachvollziehbar, wer die E-Mail geöffnet hat.

Jetzt fehlt nurnoch, dass wir unserem Server sagen er soll aus der php-Endung unserer Datei gif machen (damit es auch wie ein Bild aussieht).
Das geht ganz einfach mit z.B. mod_rewrite in der .htaccess-Datei:

<IfModule mod_rewrite.c> 
RewriteEngine on
RewriteRule webbug.gif$ webbug.php [PT]
</IfModule>

Nun können wir unser Web-Bug in E-Mails oder auf Webseiten einbauen:

<img src="http://www.georg-weidner.de/webbug.gif?userid=1234" border="0" width="1" height="1" />

Genutzt wird dieses Verfahren z.B. von der Informationsgemeinschaft zur Feststellung der Verbreitung von Werbeträgern (http://www.ivw.de), auf deren Seiten die aktuellen Klickzahlen der teilnehmenden Internet-Portale (eigentlich alle relevanten) abgefragt werden können.

Nun erklärt sich auch, warum z.B. Outlook nicht mehr automatisch alle Bilder lädt, die in E-Mails eingebaut sind, oder?

Bei Fragen oder weiteren Anmerkungen nur keine Scheu!

Anmerkung: Dieses Verfahren ist für professionelle Anbieter natürlich viel zu unperformant und soll auch nur das grundsätzliche Vorgehen veranschaulichen.

Da es leider (noch?) keine Möglichkeit gibt dies einzustellen hier eine kurzfristige Lösung für alle, die als Admin in ihrem Blog nicht mehr von Woopra getrackt werden wollen:

In der Plugin-Datei woopra.php folgenden Teil suchen (um Zeile 50 herum):

echo "<script type="\&quot;text/javascript\&quot;"><!--mce:0--></script>\r\n";
 
$websiteid = get_option('woopra_website_id');
echo "<script src="\" type="\&quot;text/javascript\&quot;"><!--mce:1--></script>";

Davor wird folgende Abfrage eingefügt:

if ( !current_user_can('edit_plugins') )
{

und danach noch die schließende Klammer:

}

Prinzip: Da es keine Wordpress-Funktion à la isAdmin() gibt überprüfen wir, ob der User die Rechte hat Plugins zu editieren – und die hat für gewöhnlich nur ein Admin.

(Getestet in Wordpress 2.5.1)

Update (10.10.2008): Seit den aktuellen Versionen des Woopra-Plugins, kann man dies nun auch ganz einfach über die Einstellungen abschalten! Macht euch also keine unnötigen Mühen!

Wie beim Testfazit schon erwähnt ist es problematisch auf AJAX-lastigen Seiten die Besucherstörme zu beobachten, da nur sich ändernde Inhalte und nicht mehr ganze Seiten neu geladen werden. Der Trackingcode lädt nur einmal – der Besucher wird nur einmal getrackt und bleibt von da an unsichtbar.

Doch dies soll sich mit dem Event Tracking von Google nun ändern. Google hat dazu seinen Analytics-Code aktualisiert und bereits für Beta-Tester freigegeben.

Das Vorgehen soll dabei ganz einfach sein: Das zu beobachtende Objekt (z.B. ein Video) in Google Analytics eintragen und die zu trackenden Aktionen (Video abspielen, Pause, Stop, etc.) festlegen. Man kann wohl sogar den prozentual abgespielten Videoanteil festhalten. Die Auswertung übernimmt dann wieder Google Analytics.

Leider bin ich kein Beta-Tester und muss somit auch voller Spannung abwarten.

Die zugehörige Infoseite von Google findet sich unter code.google.com.

Das Problem, dass Suchmaschinen (und einige Web-User) kein JavaScript und somit auch kein AJAX interpretieren, konnte relativ leicht umgangen werden indem die Webseite dann einfach auf dem üblichen Weg geladen wurde. D.h. anstatt nur Bereich zu aktualisieren lädt einfach die gesamte Seite neu.

Da die AJAX-Funktionalität im verwendeten Style schon vorhergesehen ist, hatte ich nicht sooo viel Arbeit das Blog umzustellen. Leider gibt es aber sehr kreative Fehler, wenn man Plugins benutzt die von den AJAX-Avancen des zugrundeliegenden Systems nichts wissen (wollen).

Ganz bitter ist, dass Usertracking mit aktiviertem AJAX quasi nicht mehr möglich ist. Es werden ja nurnoch die Seiteninhalte neu geladen, in denen sich etwas ändert – der Rest bleibt bestehen. D.h. auch der Trackingcode wird nur einmal beim Seitenaufruf geladen, alle weiteren Aktionen der Besucher werden nicht registriert. Dies könnte man natürlich umgehen indem man bei jedem AJAX-Request (also jedem Klick eines Users) dem Trackingsystem mitteilt was der User macht, der Aufwand dafür steht allerdings in keinerlei Verhältnis zum Nutzen.

Mittlerweile habe ich AJAX wieder deaktiviert. Schade ist’s schon, da die Technik doch sehr flott und sonst auch zuverlässig ist. Wenn der Aufwand in einem angemessenen Rahmen bleiben soll, lohnt sich AJAX wohl noch nicht für Seiten die für Suchmaschinen optimiert werden sollen. Für Anwendungen wie z.B. eine ToDo-Liste (ein anderes Projekt…) ist es aber eine wirklich tolle Sache!

Ganz verzichten wollte ich dann aber doch nicht und so habe ich schnell die Suchfunktion in AJAX realisiert. Einfach ein paar Buchstaben eintippen und kurz warten (der Server ist leider ein bisschen laaangsaam ). Die Suchergebnisse werden direkt unter der Blogüberschrift ausgegeben.

Welche Erfahrungen habt ihr schon mit AJAX gemacht?

In einer Übersicht werden zum Beispiel alle (aktuellen) Besucher, ihre Herkunft und ihre Navigationspfade veranschaulicht. Wer sich über die Option “Leave a message” auf dem Bild wundert: Ja, man kann auch einen Chat mit dem Webseitenbesucher öffnen.

Natürlich gibt es viele Data-Mining- und Analyse-Optionen. Ich konnte noch gar nicht alle ausprobieren – werde ich aber im Zuge der Recherchen für meine Diplomarbeit noch nachholen und gegebenenfalls weiter berichten.

Zur Auswertung von Analysefunktionen erhält man übersichtlich zusammengestellte Graphen.

Für den Betatest kann sich jeder anmelden – allerdings dauert das Freischalten leider einige Zeit (bei mir knapp zwei Wochen). Das tolle Design liegt übrigens daran, dass Woopra ein Programm zur Installation auf dem lokalen Computer anbietet, welches sich dann mit dem Server verbindet.

Woopra: Für Statistikfreaks ein must-have!

Worum geht es also?

Ganz kurz erklärt: Unter AJAX versteht man den gemeinsamen Einsatz von HTML, JavaScript, XML und meist PHP-Code zur Webseitenentwicklung. Doch warum nun so ein Wirrwar, wenn doch HTML/PHP alleine bisher meist auch ausgereicht haben?

Das tolle an AJAX ist, dass man mit dieser Technik einzelne Anfragen an den Server schicken kann, ohne die ganze Webseite neu laden zu müssen. Denn bisher wird mit jedem Klick auf einem Link die komplette Webseite neu geladen. Das kann natürlich manchmal ein bisschen dauern, bis alle Daten durch die Leitung gesickert sind. Mit AJAX werden nurnoch die Teile der Webseite neu geladen, bei deren Inhalt sich wirklich etwas geändert hat, bzw. ändern soll – der Rest bleibt bestehen.

Kling toll? Ist es auch – wenn es funktioniert zumindest. Und darum nun dieser Test um Erfahrungen zu sammeln wo es hakt und was Suchmaschinen wie Google & Co. dazu sagen.

Wenn also etwas passiert was du so nicht erwartet hast, lass es mich bitte wissen.

Dann schauen wir mal, wie es so funktioniert – ich werde wieder berichten…