GRIN - Personalisierungstechniken im WWW - Untersuchung der Anforderungen und Möglichkeiten anhand einer prototypischen Umsetzung

Personalisierungstechniken im WWW - Untersuchung der Anforderungen und Möglichke...

Bitte warten

Bitte installieren Sie den Flash Player, wenn kein E-Book erscheint.

E-Book Cover: Personalisierungstechniken im WWW - Untersuchung der Anforderungen und Möglichkeiten anhand einer prototypischen Umsetzung(Informatik - Theoretische Inf.)

Personalisierungstechniken im WWW - Untersuchung der Anforderungen und Möglichkeiten anhand einer prototypischen Umsetzung

Autor: Stefan Kluge
Fach: Informatik - Theoretische Inf.

Lesen Sie im E-Book

Details

Institution/Hochschule: Hochschule für Technik, Wirtschaft und Kultur Leipzig (FH
Tags: Personalisierungstechniken, Untersuchung, Anforderungen, Möglichkeiten, Umsetzung

Kategorie: Diplomarbeit
Jahr: 2002
Seiten: 132
Note: sehr gut
Sprache: Deutsch
Dateigröße: 799 KB

Archivnummer: V106388
ISBN (E-Book): 978-3-640-04667-6

Anmerkungen :
Co-Autor: Gerald Menzel

Volltext (computergeneriert)

HTWK Leipzig

Diplomarbeit

Personalisierungstechniken im WWW

Untersuchung der Anforderungen und Möglichkeiten

anhand einer prototypischen Umsetzung

Vorgelegt dem Fachbereich Informatik, Mathematik und

Naturwissenschaften von

Kluge, Stefan

Humboldtstraße 4

06766 Wolfen

Matrikelnummer: 21957

Menzel, Gerald

Max-Seyfert-Straße 5

04316 Leipzig-Baalsdorf

Matrikelnummer: 22091

abgegeben am 18. Februar 2002

Erstgutachter: Prof. Dr.-Ing. Gabriele Schade

Zweitgutachter: Prof. Dr.-Ing. habil. Dr. rer. nat Wolfgang S. Wittig

1-2

Inhaltsverzeichnis

Inhaltsverzeichnis 1-2

Einleitung 1-5

Grundlagen und Gegebenheiten 2-8

2.1

Begriff Personalisierung 2-8

2.2

Sicherheitsaspekte und Datenschutz 2-10

2.2.1

Sicherheitsaspekte bei der Personalisierung 2-10

2.2.1.1

Personalisierung mittels unabhängiger Nutzerverwaltung. 2-11

2.2.1.2

Personalisierung durch gemeinsame Nutzerverwaltung 2-12

2.2.2

Datenschutz 2-14

2.2.3

Rechtliche Grundlagen 2-15

2.2.4

Potentielle Gefahren 2-17

2.2.5

Maßnahmen 2-19

2.3

Bekannte Techniken zur Personalisierung 2-21

2.3.1

Expertengestützte Systeme 2-21

2.3.1.1

Uniforme Bewertung 2-21

2.3.1.2

Regelbasierte Personalisierung 2-22

2.3.2

Nutzergestützte Systeme 2-23

2.3.2.1

Einfaches Filtern 2-24

2.3.2.2

Inhaltsbasiertes Filtern 2-24

2.3.2.3

Kollaboratives Filtern (collaborative filtering): 2-25

Konzepte zur Lösung 3-30

3.1

Datengewinnung 3-31

3.1.1

Technischer Ansatz zur kontinuierlichen Nutzerbeobachtung .. 3-33

3.1.2

Beschreibung der Funktionsweise 3-35

3.1.2.1

Identifikation der Session bzw. des Nutzers 3-35

3.1.2.2

Identifikation der angeforderten Seite 3-37

3.1.2.3

Identifikation der Aktionselemente 3-40

3.1.2.4

Identifikation aktiver Textdaten 3-44

3.1.2.5

Identifikation passiver Textdaten 3-47

3.1.2.6

Protokollierung der Seitenanforderung 3-50

3.1.2.7

Modifikation des HTML-Quelltextes 3-52

3.2

Informationsgewinnung 3-54

3.2.1

Informationsgewinnung aus Aktionsdaten 3-54

3.2.1.1

Aktionen 3-54

3.2.1.2

Seitenwechsel 3-56

3.2.1.3

Navigationswege 3-57

3.2.2

Textbasierte Informationen 3-65

3.2.2.1

Verarbeitung von Textdaten 3-66

3.2.2.2

Verarbeitung von textbasierten Informationen 3-77

3.3

Wissensgewinnung 3-81

3.3.1

Wissen über den Nutzer 3-81

3.3.1.1

Erfahrungslevel 3-82

3.3.1.2

Interessengebiete 3-83

1-2

1-3

3.3.2

Wissen über die Anwendung 3-85

3.3.2.1

Nutzungsschwerpunkte (räumlich/zeitlich) 3-86

3.3.2.2

Zielgruppeninformationen 3-88

3.4

Integration 3-89

3.4.1

Metasprache 3-89

3.4.2

API 3-92

3.5

Anwendung 3-94

3.5.1

Personalisierung 3-94

3.5.1.1

Sichtbarkeit 3-94

3.5.1.2

Ranking 3-97

3.5.1.3

Textuelles Ranking 3-99

3.5.1.4

Hotlinks 3-102

3.5.1.5

Prefilling 3-104

3.5.1.6

Individuelle Rechtschreibkontrolle 3-106

3.5.1.7

Inhaltsvorschlag 3-108

3.5.1.8

Zusatzinformationen bei intensiver Nutzung 3-109

3.5.1.9

Auswahl ähnlicher Inhalte mittels kollaborativen Filterns 3-111

3.5.2

Analysen und Statistiken 3-115

Zusammenfassung und Ausblick 4-120

Anhänge 5-121

5.1

Grundbegriffe zur Computerlinguistik 5-121

Abbildungen 5-126

Gleichungen 5-127

Beispiele 5-127

Quellen, Referenzen und Verweise 5-130

1-3

1-4

Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und

ohne fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benutzt

und die den verwendeten Quellen wörtlich oder inhaltlich entnommenen Stellen

als solche kenntlich gemacht habe.

Leipzig, 18.02.2002

Stefan Kluge

Gerald Menzel

1-4

1-5

1. Einleitung

Warum finden bis heute Techniken zur Personalisierung nur in so

geringem Maß Anwendung im WWW? Eine wesentlicher Grund ist die enorm

hohe Technologie- und Kostenhürde, die bisher bei der Realisierung eines

personalisierten Angebotes zu überwinden ist. Daneben bestehen zusätzlich oft

auch große Vorbehalte gegenüber der Personalisierung. Diese beziehen sich

neben dem nur schwer definierbaren wirtschaftlichen Nutzen vor allem auf die

Datenschutzproblematik.

Dennoch ist ein Trend hin zum verstärkten Einsatz von

Personalisierungstechniken erkennbar. Und das nicht nur im WWW. Diesen

wachsenden Bedarf nach entsprechenden Lösungen wird mehr und mehr

nachgekommen. Vor allem Hersteller von Systemen im Bereich Content

Management (CM) und Customer Relation Management (CRM) bieten

mittlerweile immer öfter auch Module mit Personalisierungstechniken. So ist die

große Mehrzahl der derzeit am Markt präsenten Lösungen meist nur als

Bestandteil oder Erweiterung umfangreicher CM- oder CRM-Lösungen

einsetzbar. Der Markt für derartige Systeme ist undurchsichtig und lässt sich

aufgrund der Vielfalt und rasanten technologischen Veränderungen der Systeme

kaum abgrenzen, weshalb an dieser Stelle bewusst keine Aufstellung oder gar

ein Vergleich einzelner verfügbarer Systeme gegeben werden soll.1

Beispiele für personalisierte Angebote im WWW sind inzwischen zahlreich

zu finden. Das Kürzel ,my′ weist vielerorts auf die Möglichkeit der persönlichen

Anpassung des Angebotes hin, so z.B. myYahoo2. Ein besonders oft zitiertes

Beispiel stellt der Online-Buchversand Amazon3 dar, welcher schon sehr früh

1 Dennoch sei auf das Angebot unter www.content-manager.de hingewiesen, welches aktuelle

Informationen und Vergleiche zu Produkten aus den Bereichen CM und CRM bietet.

2 www.yahoo.de

3 www.amazon.com / www.amazon.de

1-5

1-6

auf Personalisierungstechniken gesetzt hat und damit auch sehr erfolgreich war

und ist.

Es fällt auf, dass derzeit hauptsächlich größere eCommerce-Angebote

den Querschnitt der personalisierten Angebote im WWW bilden. Dies ist wohl

vor allem damit zu begründen, dass der Einsatz von Personalisierungstechniken

meist wirtschaftlichen Erwägungen (Stichwort: Kundenbindung) folgt und sich

die Hersteller solcher Systeme ausschließlich auf dieses lukrative zentrale

Marktsegment konzentrieren.

Grenzbereiche finden dagegen bisher kaum Beachtung. Die meisten CM-

Systeme sind mit komplexen Verwaltungsfunktionen, wie z.B. Workflow-

Koordinierung oder Mitarbeiterverwaltung, ausgestattet und daher für kleinere

Anbieter völlig überdimensioniert bzw. nicht finanzierbar. Auch für das andere

Ende des Marktes, z.B. Anbieter mit sehr komplexen Angeboten, kommen die

derzeit verfügbaren Lösungen kaum in Frage, da diese oft nicht flexibel genug

den individuellen Bedürfnissen angepasst werden können.

Es besteht also Bedarf nach Personalisierungslösungen, die unabhängig

von CM-Systemen einsatzfähig sind. Eine solche Lösung müsste leicht und mit

nur geringem Aufwand in bestehende Angebote integrierbar, gleichzeitig aber

auch flexibel anzupassen und einsetzbar sein. Es müssten damit sowohl

komplett dynamische Websites personalisiert werden können als auch

Angebote, die teilweise oder gänzlich aus statischen HTML-Dateien bestehen.

Dem Personalisierungssystem sollte ein offenes und dadurch transparentes

Konzept zugrunde liegen, um Datenschutzbedenken entgegenwirken zu

können.

Im Folgenden werden Ansätze für ein solches innovatives

Personalisierungskonzept vorgestellt. Eine besondere Rolle spielen dabei auch

Methoden der Computerlinguistik.4 Im Gegensatz zu herkömmlichen Systemen

wird ein nicht-integrativer Ansatz, d.h. eine klare Trennung zwischen

4 Einige Grundbegriffe der Computerlinguistik werden im Anhang näher erläutert.

1-6

1-7

Personalisierungssystem und der zu personalisierenden Anwendung, verfolgt.

Diese Arbeit untersucht die Möglichkeiten der Informationsgewinnung und

skizziert Anwendungsfälle für eine Personalisierung auf Basis dieser

Informationen.

1-7

2-8

2. Grundlagen und Gegebenheiten

2.1 Begriff Personalisierung

Vor dem ,Wie′ sollen zu Beginn zunächst die Fragen ,Was ist

Personalisierung?′ und ,Wer braucht sie?′ geklärt werden. Erstere Frage ist nicht

leicht zu beantworten, denn es existieren viele verschiedene Definitionen zum

Begriff ,Personalisierung′ in unterschiedlichen Kontexten.

Bezogen auf das Feld der Informationsverarbeitung könnte eine intuitive

Definition vielleicht folgendermaßen lauten: ,Personalisierung bedeutet die

Anpassung von Inhalten für ein konkretes Subjekt, z.B. durch Hinzufügen von

für dieses Subjekt interessanten und Weglassen von uninteressanten

Informationen.′ Ein solches ,konkretes Subjekt′ könnte als eine reale Person

oder auch als eine Gruppe von Personen verstanden werden.

Tatsächlich existieren aber auch hier teilweise sehr verschiedene

Definitionen. So findet der Begriff Personalisierung u.a. im Bereich eCommerce

Verwendung und meint dort oft nichts anderes als die Möglichkeit, sich als

Kunde mit Name, Adress- und Kontoverbindungsdaten zu registrieren, um diese

bei späteren Bestellungen nicht erneut eingeben zu müssen. Es bedarf also

einer allgemeinen (allumfassenden) Definition des Begriffes Personalisierung für

das Feld der Informationsverarbeitung.

Personalisierung bedeutet eine positive Beeinflussung der Art und Weise,

wie Information für eine konkrete Person zugänglich ist. Dies schließt z.B. auch

die Möglichkeit der Vorauswahl von Informationen ein, abhängig von den

Präferenzen der Person - in Anbetracht der zunehmenden Informationsflut eine

nicht zu unterschätzende Stärke personalisierter Informationssysteme.

Bei der Entwicklung von Informationssystemen wie z.B.

Anwendungsprogrammen, aber auch Angeboten im WWW, wurde bisher meist

2-8

2-9

von einer allgemeinen Zielgruppe ausgegangen, welche, abhängig vom

Charakter des Systems, mehr oder weniger groß ist. Der Gruppe werden

gewisse Eigenschaften zugeschrieben und diese als für jedes Individuum der

Gruppe zutreffend angenommen. Anhand dieses Eigenschaftskataloges findet

die Ausrichtung der Schnittstellen und Inhalte des Systems statt. Die Anpassung

an den Nutzer (die Zielgruppe) ist also statisch, d.h. einmalig, bei der

Entwicklung des Angebotes. Naturgemäß können so jedoch nur elementare und

wenig differenzierte Eigenschaften von Personen berücksichtigt werden. Dies

sind in den meisten Fällen Eigenschaften wie z.B. Alter, Bildungsstand,

Interessengruppe usw.

Im Gegensatz zu diesem klassischen Zielgruppenkonzept, verfolgt die

Personalisierung den Gedanken, jeden einzelnen Nutzer als Individuum zu

behandeln und die Schnittstellen und Inhalte des Informationssystems nach

dessen persönlichen Eigenschaften anzupassen. Natürlich bedeutet dies, dass

das Personalisierungssystem Kenntnis der persönlichen Eigenschaften jedes

Nutzers haben muss. Diese Daten können auf verschiedene Weise gewonnen

werden, vom einfachen Fragebogen bis hin zur automatischen Beobachtung

und Auswertung aller Aktionen der Nutzer des Informationssystems. Letzteres

Verfahren ist nur mit enormem technischem Aufwand realisierbar, birgt aber

großes Potenzial, da sich aus den so gesammelten Daten sehr viele

Informationen zu Eigenschaften der Nutzer gewinnen lassen, was wiederum

sehr komplexe und effiziente Personalisierungstechniken ermöglicht.

Jedoch müssen persönliche Daten als sensibel eingestuft werden.

Begriffe wie ,Nutzerbeobachtung′ oder ,Profilerstellung′ können leicht

missverstanden werden. Dies fügt der technischen Problematik auch noch einen

heiklen rechtlichen Aspekt hinzu und macht die Personalisierung zu einem

kontrovers diskutierten Thema. Das folgende Kapitel setzt sich daher zunächst

näher mit der Datenschutzproblematik auseinander.

2-9

2-10

2.2 Sicherheitsaspekte und Datenschutz

2.2.1 Sicherheitsaspekte bei der Personalisierung

Berichtet man von Techniken zur Ermittlung von Nutzergewohnheiten,

zur Erstellung von Nutzerprofilen oder zur Individualisierung eines Interfaces,

so wird man oft konfrontiert mit Kommentaren wie "Spyware", "Datenspionage"

oder "ich will nicht, dass sich meine Oberfläche verändert". An dieser Stelle

muss man unterscheiden zwischen der Skepsis über die Qualität eines solchen

Systems, die zur vorschnellen Ablehnung führen kann, und über Bedenken

bezüglich Datenschutz und Anonymität.

Gründe für das Misstrauen gegenüber einer Interface-Individualisierung

können verschiedener Natur sein. Viele Nutzer, vor allem im professionellen

Bereich, haben schlechte Erfahrungen mit solchen Techniken gemacht. So sind

einige in Microsoft Windows bzw. in den Microsoft Office Produkten integrierten

Personalisierungstechniken für bestimmte Zielgruppen nicht geeignet oder

sogar produktivitätsmindernd. Als konkretes Beispiel sei an dieser Stelle die

Funktion zum automatischen Verbergen selten genutzter Menüpunkte genannt,

die in modernen Microsoft Office Produkten integriert ist. Während

durchschnittlichen Nutzern durch diese Funktion eine größere Übersichtlichkeit

gegeben wird, fühlen sich zahlreiche fortgeschrittene Anwender durch die

zusätzlich notwendige Erweiterung der jeweils eingeblendeten Menüleiste, um

verborgene Menüpunkte nutzen zu können, behindert. Microsoft hat mit seiner

hohen Marktdurchdringung einen großen Einfluss auf die öffentliche

Meinungsbildung. Daher sind diese für bestimmte Zielgruppen mangelhaften

Konzepte nicht unwesentlich für das Misstrauen dieser Nutzer

mitverantwortlich.

Für viele Kritiker sind Bedenken bezüglich der Datenspionage und des

Anonymitätsverlustes Gründe für eine Zurückhaltung. Diese Bedenken sind

2-10

2-11

natürlich nicht von der Hand zu weisen. Jedoch muss berücksichtigt werden,

dass die Gewährleistung dieser Sicherheit von einem konkreten System abhängt

und nicht zu einer Pauschal-Verurteilung der Personalisierung an sich führen

kann. Nun ist es Nutzern von personalisierten Systemen allerdings in der Regel

nicht möglich, diese auf Einhaltung diverser Sicherheitsanforderungen zu

prüfen. Allerdings ist bereits ein Trend erkennbar, dass sich namhafte Firmen

immer öfter um eine freiwillige Sicherheitskontrolle durch mehr oder weniger

unabhängige Experten, wie dem TÜV für IT-Security, bemühen.

In dieser Arbeit werden modulare Personalisierungssystemkonzepte

favorisiert. Es handelt sich dabei um Konzepte, die eine unkomplizierte

Erweiterung bestehender Systeme um eben diese Personalisierungskomponente

ermöglichen. Sicherheitsaspekte, die für eine konkrete Anwendung dieser

Personalisierung relevant sind, müssen nicht zwangsläufig auch für die

Personalisierung an sich eine Bedeutung haben. Die gewährleistbare Sicherheit

hängt vor allem von der Schnittstelle zwischen dem Personalisierungssystem

und der Anwendung ab. Von den Autoren wird im Folgenden ein mehrstufiges

Sicherheitskonzept vorgestellt.

2.2.1.1 Personalisierung mittels unabhängiger Nutzerverwaltung

Nutzer des Personalisierungssystems werden völlig losgelöst von den

Nutzern der Anwendung betrachtet. Es gibt keinerlei Austausch von

Nutzeridentifikationsnummern oder sonstigen Daten, die eine Verbindung

zwischen Nutzerdaten des Personalisierungssystems und Nutzerdaten der

Anwendung ermöglichen. Damit ist es nicht möglich, Wissen über den Nutzer

innerhalb des Personalisierungssystems, auf eine reale Person zu übertragen,

da eine Verbindung zur realen Person, wenn überhaupt, nur in der Anwendung

existiert. So wäre dies z.B. möglich, wenn in der zu personalisierenden

Anwendung Adressinformationen archiviert würden und eine Abkopplung

zwischen Nutzer im Personalisierungssystem und Nutzer der Anwendung nicht

vorliegen würde.

2-11

2-12

Vorteil dieser Methode ist die völlige Anonymität personalisierter Daten.

Es ist z.B. nicht möglich, Wissen über das Erfahrungslevel eines Nutzers auf

eine reale Person zu übertragen. Da dies aus Marketinggründen auch erwünscht

sein kann, ist es unter Umständen ebenso ein Nachteil. Ein erheblicher Nachteil

kann die mangelhafte Nutzererkennung sein. Das Einloggen ist die einzig

sichere und praktikable Möglichkeit zur Identifikation eines Nutzers, da die

jeweilige Person sich aktiv auf einem beliebigen Rechner mittels Benutzername

und Passwort identifiziert. Für das Personalisierungssystem ist dieses Verfahren

in diesem Fall jedoch nicht von Nutzen, daher muss die Identifikation auf der

Verwendung von Cookies bzw. nicht persistenten Session-IDs basieren. Cookies

sind Dateien, die von einem Server auf dem Client gespeichert werden, wo sie

vom Webbrowser verwaltet werden. Diese Dateien können beispielsweise eine

Nutzeridentifikationsnummer dauerhaft speichern. Da Cookies durch Nutzer

blockierbar sind, kann eine Wiedererkennung von Nutzern nicht garantiert

werden. Nicht persistenten Session-IDs sind, wie der Name schon sagt, nur für

die Dauer eine Session gültig. Eine solche eindeutige ID wird einem Nutzer bei

der ersten Anfrage vergeben und dann bei jeder weiteren Anfrage dieses

Nutzers weitergereicht. Für eine Personalisierung ist dieses Verfahren nur

bedingt geeignet, da wiederkehrende Nutzer nach Beendigung einer Session

nicht wiedererkannt werden können.

Sinnvoll ist die Anwendung der unabhängigen Nutzerverwaltung, wenn

im zu personalisierenden System ohnehin keine Nutzerverwaltung

implementiert ist. Außerdem gibt es Online-Angebote, die die Annahme von

Cookies durch Ihre Anwender voraussetzen. Auch in diesem Fall ist der Einsatz

möglich und voraussichtlich nur geringfügig durch mangelhafte

Nutzererkennung beeinträchtigt.

2.2.1.2 Personalisierung durch gemeinsame Nutzerverwaltung

Websites mit eigener Nutzerverwaltung können diese über die

Schnittstelle zum Personalisierungssystem propagieren. Technisch kann dies

2-12

2-13

vereinfacht als ,,Durchreichen" einer eindeutigen Nutzeridentifikationsnummer

verstanden werden. Vorteilhaft ist in diesem Fall die eindeutige

Nutzererkennung durch Login. Die Möglichkeit, eine Verbindung zwischen

nutzerbezogenen Daten des Personalisierungssystems und denen der

Anwendung zu schaffen, kann aus Marketing-Sicht erhebliche Vorteile bringen.

So können Anwendungsfunktionalitäten implementiert werden, deren

Realisierung mit Hilfe einer Personalisierungsmetasprache nicht möglich wäre.

Als Beispiel sei das Verschicken von personalisierten Newslettern genannt. Als

Nachteil ist der Verlust der Anonymität personalisierter Informationen zu

nennen, wenn Informationen zur realen Person in der Anwendung vorliegen.

Generell soll hier darauf hingewiesen werden, dass Nutzerdaten

bezüglich einer Personalisierung in dem von uns vorgestellten Sinne im

Allgemeinen keine sensiblen persönlichen Informationen sind. Bei einer

Diskussion sollte im Auge behalten werden, dass es sich nicht um Konto-,

Adress- oder sonstige Informationen mit direktem Bezug zur realen Person

handelt. Die Informationen, die auf der Basis des hier vorgestellten

Personalisierungskonzeptes gewonnen werden, sind vielmehr als abstraktes

Wissen, etwa in Form von Navigationsverhaltensregeln bezüglich einer Website,

oder in Form von Interessenschwerpunkten, bezogen auf dynamische

Informations-Cluster, zu verstehen.

Einer Entscheidung für eines der beiden Sicherheitskonzepte sollten

folgende Überlegungen vorausgehen:

I. Anforderungen an die Personalisierung

Wird das Personalisierungssystem vorwiegend zur Analyse des

Kundenverhaltens eingesetzt? Oder kommen aktive Personalisierungsfunktionen

zum Einsatz, die beispielsweise Inhalte und Form der Anwendung beeinflussen?

Dann spricht dieser Fakt für eine Personalisierung durch gemeinsame

Nutzerverwaltung.

2-13

2-14

II. Nutzerverwaltung der Anwendung

Existiert in der zu personalisierenden Anwendung eine Nutzerverwaltung?

Ist dies nicht der Fall, so kommt eine gemeinsame Nutzerverwaltung ohnehin

nicht in Frage.

III. Sicherheitsanforderungen an die Anwendung

Bei der Implementierung einer Personalisierungslösung in Anwendungen

mit strikten Sicherheitsbestimmungen kann es, z.B. auch aus

unternehmenspolitischen Gründen, gefordert werden, die Nutzeridentifikation

nicht an ein externes Modul weiterzugeben. Auch in diesem Fall kann keine

gemeinsame Nutzerverwaltung zum Einsatz kommen.

2.2.2 Datenschutz

Folgende Betrachtungen des Datenschutzes spielen nur dann eine Rolle,

wenn es sich bei den verarbeiteten Daten um personenbezogene Daten

handelt. "Personenbezogene Daten sind Einzelangaben über persönliche oder

sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person

(Betroffener)."5 Abhängig vom Einsatz eines Personalisierungssystems ist eine

Verbindung zwischen verarbeiteten Daten eines Nutzers und der

entsprechenden natürlichen Person nicht immer notwendig. Die Bestimmbarkeit

einer natürlichen Person kann dadurch verhindert werden, dass eine solche

Verbindung gar nicht erst hergestellt wird. So können Daten über das

Navigationsverhalten eines Nutzers verarbeitet werden, ohne dabei Daten über

die natürliche Person, die sich hinter diesem Nutzer verbirgt, festzuhalten. In

einem solchen Fall spielen rechtliche Grundlagen des Datenschutzes keine Rolle.

Da bei einem Personalisierungssystem jedoch eine Verbindung zwischen

verarbeiteten Daten und den jeweiligen natürlichen Personen auch gewünscht

sein kann, sollen gesetzliche Regelungen an dieser Stelle nun genauer

betrachtet werden.

5 § 3 BDSG

2-14

2-15

2.2.3 Rechtliche Grundlagen

Die rechtlichen Grundlagen des Datenschutzes in Deutschland sind im

Bundesdatenschutzgesetz (BDSG)6 festgehalten. Speziell im Internet-Bereich

spielen außerdem das Teledienstegesetz (TDG)7, das

Teledienstedatenschutzgesetz (TDSSG)8 und der Mediendienstestaatsvertrag

(MDStV)9 eine Rolle. Im Rahmen eines Urteils des Bundesverfassungsgerichts

wurde 1983 erstmals der Begriff der Informationellen Selbstbestimmung (ISR)

geprägt, welcher grundlegende Bedeutung für die datenschutzrechtliche

Gesetzgebung hat. Es wird argumentiert, dass ein Bürger in seiner Freiheit

wesentlich gehemmt sein kann, wenn für ihn nicht überschaubar ist, welche

Informationen seiner Umwelt über ihn bekannt sind.

Folgende gesetzliche Vorgaben sollten bei der Konzeption eines

Personalisierungssystems beachtet werden:

Es dürfen nur Daten verarbeitet werden, die für den konkreten Fall

erforderlich sind (Datensparsamkeit). Daten müssen zweckgebunden

gesammelt und vor Zugriffen unberechtigter geschützt werden (Zweckbindung).

Personen haben das Recht zu erfahren, welche personenbezogenen Daten über

Sie gespeichert werden und zu welchem Zweck dies geschieht. Außerdem

können betroffene Personen die Berichtigung, Löschung oder Sperrung der

Daten fordern. Die Datenverarbeitung muss so organisiert werden, dass Sie

nachvollziehbar ist (Transparenz). Dazu gehört auch die Unterrichtung der

betroffenen Personen vor der Erhebung der Daten.

Angaben über die rassische und ethnische Herkunft, politische

Meinungen, religiöse oder philosophische Überzeugungen,

Gewerkschaftszugehörigkeit, Gesundheit oder Sexualleben unterliegen

schärferen Bestimmungen.

6 http://www.datenschutz-berlin.de/recht/de/bdsg/bdsg1.htm (abgerufen am 17. Februar 2002)

7 http://www.bfd.bund.de/information/info5/info5011.htm (abgerufen am 17. Februar 2002)

8 http://www.bfd.bund.de/information/info5/info5012.htm (abgerufen am 17. Februar 2002)

9 http://www.iid.de/iukdg/gesetz/mdstv.html (abgerufen am 17. Februar 2002)

2-15

2-16

Der folgende Ausschnitt der BDSG [§ 46] weist auf einige für die

Organisation der Datenverarbeitung wichtigen Anforderungen hin:

"1. Unbefugten den Zutritt zu Datenverarbeitungsanlagen, mit denen

personenbezogene Daten verarbeitet oder genutzt werden, zu verwehren

(Zutrittskontrolle),

2. zu verhindern, dass Datenverarbeitungssysteme von Unbefugten

genutzt werden können (Zugangskontrolle),

3. zu gewährleisten, dass die zur Benutzung eines

Datenverarbeitungssystems Berechtigten ausschließlich auf die ihrer

Zugriffsberechtigung unterliegenden Daten zugreifen können, und dass

personenbezogene Daten bei der Verarbeitung, Nutzung und nach der

Speicherung nicht unbefugt gelesen, kopiert, verändert oder entfernt werden

können (Zugriffskontrolle),

4. zu gewährleisten, dass personenbezogene Daten bei der

elektronischen Übertragung oder während ihres Transports oder ihrer

Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder

entfernt werden können, und dass überprüft und festgestellt werden kann, an

welche Stellen eine Übermittlung personenbezogener Daten durch

Einrichtungen zur Datenübertragung vorgesehen ist (Weitergabekontrolle),

5. zu gewährleisten, dass nachträglich überprüft und festgestellt werden

kann, ob und von wem personenbezogene Daten in Datenverarbeitungssysteme

eingegeben, verändert oder entfernt worden sind (Eingabekontrolle),

6. zu gewährleisten, dass personenbezogene Daten, die im Auftrag

verarbeitet werden, nur entsprechend den Weisungen des Auftraggebers

verarbeitet werden können (Auftragskontrolle),

7. zu gewährleisten, dass personenbezogene Daten gegen zufällige

Zerstörung oder Verlust geschützt sind (Verfügbarkeitskontrolle),

2-16

2-17

8. zu gewährleisten, dass zu unterschiedlichen Zwecken erhobene Daten

getrennt verarbeitet werden können."

2.2.4 Potentielle Gefahren

Unberechtigter Zugang zu den Daten

Um nur berechtigten Personen den Zugang zu einem personalisierten

System zu ermöglichen, bietet sich ein Passwortschutz an. Abhängig von der

konkreten Implementierung wird dies möglicherweise nicht in der Zuständigkeit

des Personalisierungssystems liegen, sondern bereits von der zu

personalisierenden Anwendung selbst übernommen - zum Beispiel einem

Internet-Portal, welches ein Login vorsieht.

Missbrauch der Daten

Die Verwendung von personenbezogenen Daten für nicht vorgesehene

Zwecke wiederspricht der gesetzmäßigen Zweckbindung. Für ein

Personalisierungssystem bedeutet dies, dass bei der Formulierung des

Verwendungszweckes gegenüber den Benutzern entsprechend sorgfältig

vorgegangen werden muss. Einerseits erfordert die angestrebte und für das

Vertrauen des Nutzers notwendige Transparenz eine deutliche Formulierung

des Verwendungszweckes der Daten. Andererseits machen ökonomische

Gesichtspunkte eine Skalierbarkeit und Flexibilität eines

Personalisierungssystems und der entsprechend verarbeiteten Daten

notwendig. Auch hier gilt es eine Verhältnismäßigkeit zu wahren. Das heißt, vor

allem bei der Verarbeitung sensibler persönlicher Daten den Verwendungszweck

besonders unmissverständlich zu formulieren und ihm strikt zu entsprechen.

Schutz vor Datenmissbrauch heißt weiterhin, Maßnahmen zu ergreifen um

Unberechtigten den Zugang zu diese Daten zu verwehren. Diese Maßnahmen

hängen jedoch stark von der konkreten Anwendung und dem jeweiligen System

2-17

2-18

ab und bedürfen einer individuellen Integration in das entsprechende

Sicherheitskonzept.

Manipulation der Daten

Im Gegensatz zur Manipulation etwa von Kontodaten in einer

Onlinebanking-Anwendung hat die Veränderung der Daten eines

Personalisierungssystems (nur) dessen Fehlfunktion zur Folge. Man muss sich

darüber im Klaren sein, dass die Daten der jeweiligen Anwendung völlig

unabhängig von den Daten des Personalisierungssystems sind. Eine

Manipulation wirkt sich also nicht in der Form aus, dass etwa eine Überweisung

innerhalb einer Onlinebanking-Anwendung ein falsches Konto erreichen würde,

allerdings wären Fehlfunktionen innerhalb des vom Personalisierungssystem

gesteuerten individuellen Nutzer-Interfaces möglich. Wie auch beim Schutz

gegen Missbrauch der Daten muss einer Manipulation bereits bei der

Integration in das gesamte Sicherheitskonzept der Zielanwendung vorgebeugt

werden. Andererseits können auch Anwendungsunabhängige Maßnahmen die

Sicherheit des Personalisierungssystems erhöhen. So zum Beispiel die Bildung

einer Checksumme über gefährdete Daten, welche dann bei der Verwendung

dieser Daten als Dekodierungsschlüssel dient.

Gefahr durch Verknüpfung von Daten

Auch wenn personenbezogene Daten isoliert betrachtet keine

unrechtmäßig erlangten Informationen darstellen, so muss beachtet werden,

dass die Verknüpfung dieser Daten möglicherweise weitergehende

Rückschlüsse zulassen. Ob eine Verknüpfung möglich ist, muss für jedes Datum

anhand der konkreten Anwendung geprüft werden. Auch hier gilt der Grundsatz

der Verhältnismäßigkeit. So ist die Verknüpfung von IP-Adresse und der

entsprechenden natürlichen Person theoretisch zwar möglich, jedoch nur mit

erheblichem Aufwand durchsetzbar. Damit ist die Verarbeitung der IP-Adresse

im Regelfall vertretbar.

2-18

2-19

2.2.5 Maßnahmen

Passwort-Schutz

Passwörter gelten als guter Kompromiss zwischen Sicherheit und

Benutzerfreundlichkeit. Es lässt sich in jedem Fall folgende Empfehlung für

Passwort-Schutzmechanismen aussprechen10:Passwörter sind im System

verschlüsselt abzulegen und gegen unbefugte Zugriffe zu schützen

· wiederholte Falscheingaben sind zu unterbinden, z.B. durch Sperrung

nach dreimaliger Falscheingabe

· Passwörter sollten eine Mindestlänge von 6 Zeichen haben und aus

einem alphanumerischen Zeichenmix bestehen.

· Die Eingabe sollte verdeckt erfolgen, das Anzeigen von Ersatzzeichen

(*) lässt die Erkennung der Passwortlänge für Dritte zu.

· Falscheingaben sollten dem Nutzer sofort mitgeteilt und vom System

protokolliert werden.

· Die Nutzung von Trivialpasswörtern sollte vom System unterbunden

werden.

Bei den Maßnahmen ist jeweils abzuwägen, wie stark die Benutzbarkeit

des Systems darunter leidet und wie groß der organisatorische Aufwand ist. So

ist die Vorgabe einer Mindestlänge von 8 Zeichen zwar der Sicherheit zuträglich,

nicht jedoch der Usability. Ebenso ist es einem Systembetreiber unter

Umständen aus ökonomischen Gesichtspunkten nicht möglich, bei einer

Sperrung eines Nutzer-Profils eine Entsperrung nur nach Kontaktaufnahme mit

der jeweiligen Person vorzunehmen. Der Sicherheitsaufwand sollte vor allem im

Verhältnis zu den verarbeiteten personenbezogenen Daten stehen.

10 siehe auch: http://www.datenschutz-berlin.de/infomat/ratgeber/3ratgeb.htm (abgerufen am

17. Februar 2002)

2-19

2-20

Verschlüsselung

Passwörter und andere sensible Daten müssen angemessen verschlüsselt

werden. Dies gilt auch für die Übertragung dieser Daten. Generell ist es

empfehlenswert, sich dabei an standardisierten Konzepten zu orientieren, zum

Beispiel einer Verschlüsselung gemäß des Advanced Encryption Standard

(AES)11 und einer Übertragung über Secure Socket Layer (SSL)12.

Transparenz

Platform for Privacy Preferences (P3P)13 ist ein Protokoll zur

Beschreibung von Daten-Sammlungs-Praktiken einer Website. Dieses Protokoll

dient sowohl der Information der Nutzer über private Daten, die auf einer

Website über ihn gesammelt werden, als auch der automatischen Verarbeitung

dieser Informationen durch den Webbrowser. Browser, die dies unterstützen,

können einen automatischen Vergleich mit den Sicherheitseinstellungen der

Nutzer vornehmen und den Nutzer ggf. warnen. Microsoft hat diese

Unterstützung im IE 6 integriert. P3P ist als Empfehlung des W3C ein offener

Standard und kann als vertrauensschaffende Maßnahme dem Betreiber einer

Personalisierungstechnik nutzenden Website empfohlen werden. Da das

Personalisierungssystem jedoch unabhängig von persönlichen Nutzerdaten

arbeitet, ist dies nur indirekt ein Aspekt des Datenschutzes. Indirekt deshalb,

weil zu vermuten ist, dass viele Benutzer ein generelles Misstrauen gegenüber

personalisierten Systemen aufbringen werden und gerade deshalb durch

Transparenz Vertrauen aufgebaut werden sollte.

11 http://csrc.nist.gov/encryption/aes/ (abgerufen am 17. Februar 2002)

12 http://www.netscape.com/eng/ssl3/ (abgerufen am 17. Februar 2002)

13 http://www.w3.org/P3P/ (abgerufen am 10. Dezember 2001)

2-20

2-21

2.3 Bekannte Techniken zur Personalisierung

Den Kern eines jeden Personalisierungssystems bilden Methoden und

Verfahren, die auf verschiedenste Art und Weise die Beziehungen zwischen den

Inhalten der Anwendung und deren Nutzern analysieren und beeinflussen - die

eigentlichen Personalisierungstechniken. Es existieren verschiedene Ansätze für

solche Techniken, wobei die Struktur der Inhalte des Angebotes und der

Nutzergruppen bestimmend für die Qualität der erzielten Ergebnisse ist.

Qualitative,

Key

Endorsement

Collaborative

Complex

Products

Quantitative,

Attributes

Rule Based

CASE

Few

Highly

Uniform

Differentiated

Customer Needs,

Product Space

Abbildung 1: Kriterien zur Auswahl von Personalisierungstechniken14

2.3.1 Expertengestützte Systeme

2.3.1.1 Uniforme Bewertung

Bei der Personalisierung mit Hilfe uniformer Bewertungssysteme werden

dem Nutzer Entscheidungshilfen zur Auswahl von Inhalten, z.B. zum Kauf eines

Produktes oder zur Wahrnehmung einer Dienstleistung, geboten. Die

Entscheidungshilfen orientieren sich dabei nicht an den individuellen

Präferenzen des Nutzers, sondern an denen der Allgemeinheit, also aller Nutzer.

Definition: Uniforme Präferenzen liegen vor, wenn ein großer Prozentsatz

der Nutzer identische Merkmale eines Produktes oder einer Dienstleistung

schätzt.

14 Quelle: Hanson 2000

2-21

2-22

Uniforme Bewertungssysteme sind nicht automatisierbar, d.h. die

benötigten Daten werden manuell erhoben. Alle Inhalte müssen durch

Nutzerbefragungen, Expertenanalysen oder ähnliche Verfahren regelmäßig neu

bewertet werden. Das bedeutet auch, dass sich nicht alle Arten von Inhalten für

diese Technik eignen, so z.B. Inhalte mit emotionalen Aspekten.

2.3.1.2 Regelbasierte Personalisierung

Bei der Personalisierung mit Hilfe regelbasierter Systeme werden die

über den Benutzer gesammelte Informationen einem Satz von Regeln

gegenübergestellt und anhand dieser Regeln ausgewertet. Ein solches

Expertensystem ist, wie der Name schon sagt, mit dem Schlussfolgern und

Handeln eines Experten vergleichbar.

Die zugrunde liegenden Regeln sind häufig nach folgendem Muster aufgebaut:

Folgerung(Bedingung1=wahr)(Bedingung2=wahr)...

Damit lassen sich Bedingungen definieren, wie z.B.:

,,Zeigt Nutzer verstärkt Interesse an >Outdoor<, >Camping< und

>Gebirge<, dann zeige Bannerwerbung einschlägiger Reiseveranstalter."

Ein komplexes regelbasiertes Personalisierungssystem besteht aus einer

Wissensbasis mit Fakten (Sachverhalte, dargestellt durch Objekt-Attribut-Wert

Trippel) und Regeln (in if/then-Struktur), einer Inferenzmaschine (enthält den

Schlussfolgerungsmechanismus), einem Wissenserwerbs-Subsystem, einem

Erklärungs-Subsystem und einer Benutzerschnittstelle.

2-22

2-23

Wissensbasis

(Fakten und

Regeln)

Inferenzmaschine

(Schlussfolgerungs-

mechanismus

und Steuerung)

Wissenserwerbs-

Erklärungssubsystem

Benutzerschnittstele

subsystem

Abbildung 2: Aufbau eines komplexen regelbasierten Personalisierungssystems

Voraussetzung für den Betrieb eines regelbasierten Informationssystems

ist ein umfangreiches Inhalts- und Zielgruppen-Know-How seitens des

Betreibers, da dieser für die Aufstellung und Pflege der Regeln zuständig ist.

Der große Vorteil eines solchen Systems ist die hohe Flexibilität der

Personalisierung durch beliebige Verknüpfungsmöglichkeiten von Fakten und

Bedingungen, woraus auch eine gute Überschau- und Steuerbarkeit resultiert.

Diese Vorteile werden allerdings durch einen hohen konzeptionellen

Initialaufwand (z.B. Aufstellung der Regelbasis) und die Notwendigkeit einer

permanenten - meist manuellen - Aktualisierung erkauft.

2.3.2 Nutzergestützte Systeme

Grundlegendes Arbeitsprinzip der meisten nutzergestützten

Personalisierungssysteme (Cognitive- ,Economic- und Social Filtering) ist der

Einsatz mehr oder weniger komplexer Filtertechniken. Neben einfachen Filtern

lassen sich diese Verfahren hauptsächlich in inhaltsbasierte und

bewertungsbasierte Filterverfahren unterteilen. Nutzergestützte

Personalisierungssysteme lassen sich oft auch sehr gut mit regelbasierten

Systemen kombinieren.

2-23

2-24

2.3.2.1 Einfaches Filtern

Wie der Name vermuten lässt, handelt es sich hierbei um ein sehr

simples Verfahren. Jeder Nutzer wird dabei einer manuell definierten Gruppe

zugeordnet und die Eigenschaften dieser Gruppe als für ihn zutreffend

angenommen. Beispiel:

,,Kunden, die der Gruppe >Premium-Kunden< zugeordnet sind, werden

bestimmte Rabatte angeboten."

Dieses Verfahren erfordert weder einen hohen Initial-, noch eine hohen

Aktualisierungsaufwand. Allerdings lassen sich damit auch nur einfachste

Personalisierungstechniken realisieren.

2.3.2.2 Inhaltsbasiertes Filtern

Inhaltsbasierte Filtertechniken (auch Cognitive/Content Based Filtering

genannt) stellen bereits fortgeschrittenere Methoden zur Personalisierung dar

und produzieren gegenüber dem einfachen Filtern schon wesentlich komplexere

Ergebnisse.

Grundlegendes Prinzip ist eine Klassifizierung aller Inhalte (z.B. Produkte)

des Informationssystems. Dies geschieht, indem jedem Inhalt eine Menge von

zutreffenden Attributen zugeordnet wird. Durch Vergleich dieser Attribute

lassen sich dann wiederum ähnliche Inhalte einander zuordnen. Die Ermittlung

der Präferenzen des Nutzers geschieht durch Beobachtung seiner Auswahl von

Inhalten. So können ihm z.B. passende (ähnliche) Inhalte vorgeschlagen

werden.

Voraussetzung dafür ist allerdings eine ausreichend gute Klassifizierung

der Inhalte. Als Vorteil zeigt sich hier, dass sich diese Klassifizierung in der

Regel natürlich ergibt. Leider lassen sich aber eben nicht alle Arten von Inhalten

gut klassifizieren. Schwierigkeiten treten z.B. bei Bildern oder Düften auf, da

sich solchen Inhalten nur schwer Attribute zuordnen lassen. In jedem Fall ist für

die Klassifizierung der Inhalte ein hoher Initialaufwand notwendig.

2-24

2-25

2.3.2.3 Kollaboratives Filtern (collaborative filtering):

Die Anfänge dieser Technik liegen in den neunziger Jahren. Forschungen

an der Universität von Minnesota verfolgten damals das Ziel, die großen

Mengen von Beiträgen in Newsgroups zu filtern, um dem Nutzer zu

ermöglichen, leichter die für ihn interessanten Beiträge zu finden. Das daraus

entstandene Filtersystem war in der Lage, den Nutzerbestand automatisch in

passende Gruppen zu gliedern - die ,,Group Lens"15

Das so genannte kollaborative Filtern stellt eine der fortgeschrittensten

Filtertechniken dar. Grundlage ist hier nicht eine Klassifizierung der Inhalte,

sondern die Beziehung von Nutzern zu Inhalten. Diese Beziehung entsteht,

indem Nutzer die Inhalte bewerten. Das kann zum einen aktiv (manuell)

geschehen, z.B. durch die Vergabe von Bewertungspunkten durch den Nutzer,

oder auch passiv (automatisch). In letzterem Fall muss der Nutzer nicht direkt

in Anspruch genommen werden. Vielmehr vergibt er die Bewertungen

unbewusst, d.h. schon die bloße Auswahl von Inhalten durch den Nutzer kann

als Bewertung interpretiert werden.

Anhand ähnlicher Bewertungsmuster können alle Nutzer dynamisch

gebildeten Gruppen (sog. Peer-Gruppen) zugeordnet werden. Jede dieser

Gruppen erhält gewisse Eigenschaften, gebildet aus der Summe der

Eigenschaften aller der jeweiligen Gruppe zugehörigen Nutzer. Jede der so

gewonnenen Eigenschaften einer Gruppe wird nun auch als für jedes Mitglied

der Gruppe zutreffend angenommen.

15 siehe auch: http://www.cs.umn.edu/Research/GroupLens/index.html (abgerufen am 7.

Januar 2002)

2-25

2-26

Ein bekanntes Beispiel stellt hier der Online-Buchhandel amazon.de16

dar. Dieser nutzt die Technik des kollaborativen Filterns z.B. für die Empfehlung

von Buchtiteln.

Abbildung 3: Produktempfehlung bei amazon.de (Screenshot)

Die für den Einsatz des kollaborativen Filterns notwendigen Daten

können mit Hilfe verschiedenster Techniken gewonnen werden. Zu nennen sei

hier vor allem die Technik der Nutzerbeobachtung (Usertracking), auf die später

noch näher eingegangen wird.

Da das kollaborative Filtern die zurzeit wohl fortgeschrittenste Technik

darstellt, soll hier auf verschiedene bekannte Algorithmen näher eingegangen

werden:

Speicherbasiert (Memory-Based)

Bei dieser Technik werden immer alle zugrunde liegenden Daten für die

Generierung von Empfehlungen genutzt. Der gesamte Bestand an

Bewertungsdaten wird nach Nutzern mit ähnlichem Bewertungsmuster

durchsucht. Als Maß für die Ähnlichkeit könnte dabei z.B. der

Korrelationskoeffizient nach Pearson dienen.

16 http://www.amazon.de (abgerufen am 20. Januar 2002)

2-26

2-27

Dieser ist wie folgt definiert:

(

x x y y

)(

- )

(

x x

) ×(

- )

Gleichung 1: Korrelationskoeffizient nach Pearson

Die Kovarianz zweier Nutzer wird durch deren Standardabweichung

dividiert. Der Definitionsbereich ist auf Werte zwischen -1 und +1 beschränkt,

wobei Paare mit hohem positivem Korrelationskoeffizienten als zueinander

ähnlich gewertet werden.

Nutzer1 Nutzer2 Nutzer3 Nutzer4 Nutzer5

Inhalt1

Inhalt2

Inhalt3

Inhalt4

Inhalt5

Inhalt6

Nutzer2 Nutzer3 Nutzer4 Nutzer5

Nutzer1

0.00

0.97

0.77

Nutzer2

0.85

-0.52

0.00

Nutzer3

-0.65

-0.37

Nutzer4

0.85

Beispiel 1: Neighbourhood-Methode - Bestand der Bewertungsdaten (Schulnoten) der Nutzer und berechnete

Korrelationskoeffizienten (gerundet)

In diesem Beispiel wurden Nutzer1 und Nutzer4 als zueinander sehr

ähnlich identifiziert (Korrelationskoeffizient = 0.97). Hier erscheint eine

Empfehlung von Inhalt4 an Nutzer1 sinnvoll. Dagegen haben z.B. Nutzer3 und

Nutzer4 so gut wie keine Gemeinsamkeiten (Korrelationskoeffizient = -0.65).

Modellbasiert (Model-based)

Im Gegensatz zum speicherbasierten Verfahren, wird bei modellbasierten

Techniken nicht ständig auf den gesamten Datenbestand zurückgegriffen.

2-27

2-28

Stattdessen wird aus den Nutzerdaten ein Modell generiert (geschätzt, gelernt),

wofür eine Reihe verschiedener Verfahren (Cluster Model, Gibbs Sampling,

Clustered Pearson Algorithm, Bayesian Model, Bayesian Mixed Effects Model)

Anwendung finden.

Ob speicher- oder modellbasiert - für den Einsatz kollaborativer

Filtertechniken müssen zwei wichtige Vorraussetzungen erfüllt sein: Zum einen

bedarf es einer umfangreichen Menge möglichst vielfältiger Inhalte. Zum

anderen ist eine große bis sehr große Nutzerzahl zwingend erforderlich, um

gute Ergebnisse zu erhalten.

Sind diese Vorraussetzungen erfüllt, stellt die Technik des kollaborativen

Filterns ein sehr leistungsfähiges Verfahren dar und bringt eine Reihe von

wesentlichen Vorteilen gegenüber den vorher genannten Verfahren:

· Die Kenntnis der Identität des Nutzers ist nicht erforderlich, da nur

aus seinem Verhalten Schlüsse gezogen werden - aus

datenschutzrechtlicher Sicht ein entscheidender Vorteil.

· Jeder Nutzer kann individuell betrachtet werden.

· Durch Auswertung der Gruppenpräferenzen können dem Nutzer auch

neue (ihm unbekannte) Inhalte vorgeschlagen werden.

· Es fällt kein hoher Initialaufwand an, da die zu personalisierenden

Inhalte nicht klassifiziert werden müssen.

· Das System muss kaum manuell gepflegt werden, da es aus den

Nutzerdaten ständig hinzulernt und so die zugrunde liegenden Daten

immer aktuell sind.

· Das System ist sehr flexibel einsetzbar.

2-28

2-29

Allerdings ist auch der Einsatz dieser Technik mit einer Reihe von

Problemen verbunden:

· Nicht die Inhalte der Empfehlungen, sondern nur die Empfehlung

selbst wird betrachtet, d.h. es werden keine inhaltlichen Beziehungen

berücksichtigt.

· Die Nichtberücksichtigung der Inhalte der Bewertungen birgt das

Risiko irrelevanter Vorschläge durch zufällige Zusammenhänge.

· Nur mindestens einmal bewertete Inhalte werden durch das System

berücksichtigt, was eine Sonderbehandlung neuer Inhalte erforderlich

macht (First-Rater-Problematik).

· Das System kann erst mit Erreichen einer bestimmten Anzahl von

Bewertungen zuverlässig arbeiten und gute Vorschläge liefern

(kritische Masse). Hierfür ist in der Regel ein längerer Zeitraum

erforderlich.

· Für exotische Nutzerprofile werden schlechtere Empfehlungen

generiert, da diese keiner ausreichend großen Gruppe bzw. keiner

Gruppe ausreichend gut zugeordnet werden können.

2-29

3-30

3. Konzepte zur Lösung

Das Konzept für eine Personalisierungslösung, das in dieser Arbeit

vorgestellt werden soll, verfolgt einen nicht-integrativen und modularen Ansatz.

Dies bedeutet nicht nur eine strikte Trennung von Personalisierungssystem und

Anwendung. Auch das Personalisierungssystem selbst ist modular aufgebaut

und gliedert sich in folgende Bestandteile:

· Datengewinnung

· Informationsgewinnung

· Wissensgewinnung

· Personalisierungstechniken

· Auswertung

Zentraler Bestandteil ist dabei die Datenbank, in der sämtliche Ein- und

Ausgabedaten der einzelnen Verarbeitungsschritte abgelegt und verwaltet

werden.

Request

CM / CGI /

Informations-

Wissens-

HTML

gewinnung

Client

Daten-

Browser

gewinnung

nanf

Personali-

sierung

Datenbank

Response

Auswertung

Analysen

Statistiken

Abbildung 4: Modulare Struktur des Personalisierungssystems

3-30

3-31

3.1 Datengewinnung

Verallgemeinert kann das Wort ,,Individualisierung" als Anpassung einer

Sache an ein Subjekt hinsichtlich seiner individuellen Merkmale verstanden

werden. Naturgemäß erfordert dies die Kenntnis der individuellen Merkmale des

Subjekts.

Bezogen auf die Anpassung der Schnittstelle eines Informationssystems

für einen konkreten Nutzer bedeutet dies die Notwendigkeit der Kenntnis aller

relevanten Daten zu den Eigenschaften dieses Nutzers, wie z.B. Interessen,

Gewohnheiten, Vorlieben, Fähigkeiten, Lebensumständen usw. Die Komplexität

und Treffsicherheit der Techniken zur Anpassung hängt dabei in hohem Maße

von der Qualität der aus diesen Daten gewonnenen Informationen ab. Für die

Qualität einer Information sind hierbei u.a. Kriterien wie Aktualität,

Wahrheitsgehalt und Komplexität maßgeblich.

All diese Anforderungen an die Qualität der Informationen machen die

Datengewinnung zu einem wesentlichen Bestandteil eines

Personalisierungssystems.

Herkömmliche Techniken / Fragebogen

Die einfachste und deshalb wohl verbreitetste Methode zur Gewinnung

von Daten zu Merkmalen des Nutzers ist der klassische Fragebogen. Dem

Nutzer wird hierbei (meist einmalig, bei Erstnutzung des Informationssystems)

ein Katalog aus Fragen präsentiert. Das Spektrum dieser Fragen reicht dabei

von den einfachen persönlichen Daten, wie Name und Alter, über eigene

Interessen bzw. Vorlieben, bis hin zur charakterlichen Selbsteinschätzung.

Hierbei muss die Sicherung der Qualität der Information allein dem

Nutzer überlassen werden, was nicht unproblematisch ist. Menschen neigen

dazu, Fragen zur eigenen Person nicht immer objektiv zu beantworten, was

ihnen meist nicht einmal bewusst ist. Der Wahrheitsgehalt der so gewonnenen

Informationen kann also nicht immer als gesichert angesehen werden.

3-31

3-32

Hinzu kommt, dass die Akzeptanz

seitens der Nutzer gegenüber Fragebögen

nur gering ist und mit steigender Anzahl

der Fragen weiter abnimmt. Der Konflikt

zwischen dem Wunsch, möglichst viele

Daten über den Nutzer zu erfragen auf der

einen Seite und der mangelnden Akzeptanz

der Nutzer auf der anderen Seite, kann nur

durch einen Kompromiss überwunden

werden: Wenige einfache Fragen, bei

deren Beantwortung der Nutzer nicht den

Eindruck gewinnt, allzu viel über sich

preisgeben zu müssen. Diese Technik

ermöglicht also nur ein geringes

Komplexitätsmaß der gewonnenen

Information.

Ein weiterer wichtiger Aspekt ist die

Aktualität der erfragten Daten. Nur zum

Zeitpunkt der Beantwortung der Fragen

können die Daten als wirklich aktuell

angesehen werden. So können sich z.B. die

Abbildung 5: Typischer Fragebogen17

Interessengebiete eines Nutzers mit der

Zeit ändern. Je mehr Zeit seit der Beantwortung vergangen ist, desto geringer

ist das Aktualitätsmaß der Daten. Somit nimmt auch die Qualität der aus diesen

Daten gewonnenen Information stetig ab. Um eine ausreichende Aktualität der

Daten gewährleisten zu können, müsste die Nutzerbefragung also regelmäßig

wiederholt werden, was wiederum auf starke Akzeptanzprobleme stoßen würde.

Das also nur als gering einzuschätzende Qualitätsmaß der mit Hilfe eines

Fragebogens gewonnenen Informationen lässt diese Methode nur für einfachste

17 Anmeldung GMX, http://www.gmx.de (abgerufen am 24 Januar 2002)

3-32

3-33

Personalisierungstechniken als geeignet erscheinen, z.B. für den Themenfilter

eines Nachrichtenportals.

Kontinuierliche Nutzerbeobachtung

Die im vorangegangenen Abschnitt gezeigten Probleme im

Zusammenhang mit der Datensammlung per Fragebogen gründen sich auf die

direkte Inanspruchnahme des Nutzers, die mangelhafte Aktualität und die

unzureichende Komplexität der mit diesem Verfahren gesammelten Daten und

den daraus gewonnenen Informationen.

Eine Technik, die durch kontinuierliches Beobachten des Verhaltens des

Nutzers Daten sammelt, könnte hier, zumindest teilweise, Abhilfe schaffen. Die

so gesammelten Daten wären ständig ausreichend aktuell - und das, ohne den

Nutzer direkt in Anspruch nehmen zu müssen. So entfiele also auch das

Problem undifferenzierter bzw. unrichtiger Angaben des Nutzers.

Im Folgenden soll nun untersucht werden, inwieweit und unter welchen

technischen Vorraussetzungen die Datengewinnung durch eine kontinuierliche

Nutzerbeobachtung realisierbar ist.

3.1.1 Technischer Ansatz zur kontinuierlichen

Nutzerbeobachtung

Beobachtet werden soll das Verhalten des Nutzers, d.h. alle seine

Aktionen, wie Navigation, Eingaben (z.B. Suchanfragen) usw. Die Grundlage

solcher Aktionen ist in der Regel die Anforderung einer Inhaltsseite beim

Webserver. Entscheidet sich der Nutzer beispielsweise durch Klick auf einen

Link für einen bestimmten Beitrag im Angebot eines Nachrichtenportals, so löst

dies eine Seitenanforderung beim Server aus.

3-33

3-34

Browser

Web-

Seite

Seitenanforderung

server

Abbildung 6: Client-Server-Kommunikation - Anforderung einer Inhaltsseite

Da Seitenanforderungen aus technischen Gründen die einzige Möglichkeit

zum Austausch von Informationen zwischen Client und Server sind, muss es

auch genügen, diesen Vorgang zu beobachten, um alle relevanten Daten zu

erhalten. Bei einem seitenbasierten Informationssystem, wobei jede klassische

Website als ein solches System angesehen werden kann, bedeutet

"Nutzerbeobachtung,, also allein die Analyse des Musters der durch den Nutzer

ausgelösten Anforderungen von einzelnen Inhaltsseiten und den dabei

übermittelten Daten.

Das Datensammler-Modul ist als automatisch arbeitendes System zu

verstehen, welches die im Webserver eingehenden Seitenanforderungen

registriert und auswertet. Dazu gehört die Analyse der angeforderten URL (mit

Parametern), sowie die Untersuchung des Inhaltes der angeforderten Seite. Alle

gewonnenen relevanten Daten müssen anschließend in einer für eine spätere

Auswertung geeigneten Form abgespeichert werden.

Im Rahmen dieser Diplomarbeit wurde der Prototyp eines solchen

Datensammler-Moduls als Apache18-Modul unter Verwendung der

Servererweiterung ModPerl19 realisiert.

18 siehe auch http://www.apache.org/

19 siehe auch http://perl.apache.org/

3-34

3-35

3.1.2 Beschreibung der Funktionsweise

Da die Auswertung der Seitenanforderungen aus Performancegründen

nicht in Echtzeit, also unmittelbar zum Zeitpunkt der Anforderung, erfolgen

kann, müssen zunächst alle relevanten Daten dieser Anforderungen (z.B. URL,

URL-Parameter, Post/Put-Daten) protokolliert und damit dauerhaft erfasst

werden. Dazu sind eine Reihe von Schritten notwendig.

3.1.2.1 Identifikation der Session bzw. des Nutzers

Den ersten Schritt stellt die Identifikation der Session bzw. des Nutzers

dar. Um aus gesammelten Daten Informationen über einen Nutzer zu

gewinnen, müssen diese Daten dem Nutzer natürlich auch eindeutig zugeordnet

werden können. Für die technische Realisierung sind im Wesentlichen zwei

Methoden denk- und realisierbar:

Automatische Variante

Für den Fall, dass das zu personalisierende System über keine eigene

Nutzerverwaltung verfügt, muss die Aufgabe der Nutzeridentifikation ebenfalls

durch das Datensammler-Modul übernommen werden. Hierzu wird zu Beginn

jeder Session automatisch eine eindeutige SessionID erzeugt und per Cookie

clientseitig hinterlegt. So können durch Auslesen des Cookies auch spätere

Sessions dem Nutzer eindeutig zugeordnet werden. Dieses Verfahren bringt

aber zwei wichtige Probleme mit sich:

Mit der Cookie-Methode wird tatsächlich nur der Client-Computer

identifiziert - nicht der Nutzer selbst. Benutzen nun mehrere Personen

denselben Computer (ohne spezielle Nutzerprofile), so können diese nicht

unterschieden werden, was eine Verfälschung der gewonnenen Informationen

bedeuten würde. Jedoch sind mittlerweile Betriebssysteme mit integrierter

Nutzerprofilverwaltung zum Standard geworden, was den Stellenwert dieser

Problematik mindert.

3-35

3-36

Das zweite, noch wichtigere, Problem dieser Methode stellt die mögliche

Deaktivierung der Cookie-Funktion des Browsers durch den Nutzer dar. In

einem solchen Fall könnten keine Informationen clientseitig gespeichert

werden, was eine automatische Nutzeridentifikation unmöglich machen würde.

Allerdings setzen heutzutage vielen Websites die Nutzbarkeit der Cookie-

Funktion voraus, was somit zumindest in diesen Fällen auch den Einsatz der

automatischen Nutzeridentifikation ermöglicht. Es hat also durchaus Sinn, diese

Methode der Nutzeridentifikation zu implementieren.

Nutzung der systemeigenen Nutzeridentifikation

Verfügt das zu personalisierende System bereits über eine eigene

Nutzerverwaltung, so liegt es natürlich nahe, diese auch für das Datensammler-

Modul nutzbar zu machen. Im einfachsten Fall wird der Nutzeridentifikator

bereits durch das Informationssystem bei jeder Seitenanforderung mitgeführt

und steht somit auch dem Datensammler-Modul jederzeit zur Verfügung. Der

Betreiber muss dazu den Parameter spezifizieren, welcher den Nutzer

identifiziert.

Oft wird jedoch aus Sicherheitsgründen nicht der Nutzeridentifikator

selbst mitgeführt, sondern nur ein Sessionidentifikator, welcher meist zu Beginn

jeder Session als Zufallszahl neu erzeugt und in einer gesonderten

Datenbanktabelle dem eigentlichen Nutzeridentifikator zugeordnet wird. Da das

Datensammler-Modul mit dem Sessionidentifikator allein den Nutzer nicht

identifizieren kann, müssen in diesem Fall durch den Betreiber geeignete

Maßnahmen getroffen werden. Beispielsweise wäre es möglich, zusätzlich zum

Sessionidentifikator auch den Nutzeridentifikator als URL-Parameter

mitzuführen. Die Sicherheit bliebe dabei gewährleistet, da das

Informationssystem nicht den zusätzlich mitgeführten Nutzeridentifikator,

sondern allein den Sessionidentifikator zur Erkennung des Nutzers verwendet.

Alternativ dazu kann vom Betreiber der Identifikator bereits im Quelltext

integriert werden, der vom Personalisierungssystem ausgewertet wird.

3-36

3-37

Für beide Methoden müssen natürlich auch die üblichen

Sicherheitsmaßnahmen zum Schutz vor Manipulationen implementiert werden.

So darf es z.B. Nutzern nicht möglich sein, durch Veränderung der

nutzeridentifizierenden URL-Parameter Schaden anzurichten.

3.1.2.2 Identifikation der angeforderten Seite

Der nächste Schritt ist die Identifikation der angeforderten Inhaltsseite.

Nur durch eine eindeutige Identifikation ist es möglich, Aktionen des Nutzers

Inhaltsseiten zuzuordnen. Jede Inhaltsseite muss also durch einen ihr

zugeordneten Bezeichner repräsentiert werden. Hierfür sind im Wesentlichen

zwei verschiedene Ansätze denkbar - zum einen eine automatische und zum

anderen eine explizite Benennung der Inhaltsseiten, wobei letztere durch den

Betreiber vorgenommen werden müsste.

Automatische Variante

Um eine Inhaltsseite sicher automatisch zu benennen, müssen Techniken

gefunden werden, die unter Einbeziehung gewisser Merkmale der Seite einen

Bezeichner generieren, welcher eindeutig und reproduzierbar ist. Jede

Inhaltsseite muss also ihrem Bezeichner zugeordnet werden können und

umgekehrt.

Bei rein HTML-basierten Websites ist dies meist trivial. Hierbei wird jede

Inhaltsseite durch eine HTML-Datei repräsentiert. Als Seitenidentifikator kann

also der Name dieser HTML-Datei dienen.

3-37

3-38

URL:

/support/faq.html

Bezeichner:

/support/faq.html

Beispiel 2: Einer statischen HTML-Datei kann ihre URL als Bezeichner zugeordnet werden

Anders bei skriptbasierten Websites. Hier werden die eigentlichen

Inhaltsseiten dynamisch mit Hilfe von Skripten (z.B. Perl, PHP, ColdFusion usw.)

erzeugt, wobei keine direkte eindeutige Zuordnung von erzeugter Inhaltsseite

zur zuständigen Skript-Datei möglich ist. So kann ein Skript durchaus für die

Generierung von mehreren verschiedenen Inhaltsseiten verantwortlich sein -

abhängig z.B. von übermittelten Parametern (URL-/Submit-Parameter). Selbst

ein Portal mit mehreren hundert einzelnen Inhaltsseiten wird oft nur mit einigen

wenigen Skripten realisiert. Erst die Kombination des Skript-Dateinamens mit

der zugehörigen Menge von Parametern ergibt eine Einheit, die als

Seitenidentifikator genutzt werden kann.

Zunächst müssen also sämtliche übertragenen Parameter in Erfahrung

gebracht werden. Es existieren zwei etablierte Methoden der

Parameterübermittlung. Die gängigste dabei ist das direkte Anhängen der

Parameter an die URL, abgesondert durch ein Fragezeichen. Die Parameter

selbst sind in der Form Bezeichner=Wert notiert und durch das Zeichen &

voneinander getrennt. Die zweite wichtige Methode ist die Übermittlung von

Daten unter Verwendung von Formularen. Hierbei werden die Daten nicht als

URL-Anhang übertragen, sondern in einem gesonderten Puffer, der vom Server

ausgelesen werden kann. Beide Methoden in Kombination sind die Basis der

Datenübertragungen per HTTP-Protokoll auf denen heutige Websites aufbauen.

Aus dem URL-Pfad und den verfügbaren Parametern lässt sich nun eine

Zeichenkette generieren. Jeder so erzeugte Bezeichner kann einer Inhaltsseite

zugeordnet werden und umgekehrt.

3-38

3-39

URL+Parameter:

/cgi-bin/forum.pl?fid=2&uid=76&pid=339

Bezeichner:

/cgi-bin/forum.pl?fid=2&uid=76&pid=339

Beispiel 3: Einer skript-generierten Seite kann eine aus der URL und den übermittelten Parametern (URL-/Post-

Parameter) gebildete Zeichenkette als Bezeichner zugeordnet werden

Einschränkend muss ergänzt werden, dass eine Eindeutigkeit nicht

garantiert werden kann, da skriptbasierte Systeme auch an innere Zustände

gebunden sein können. Im Falle der Änderung eines solchen inneren Zustandes

können auch bei völlig identischen URLs durchaus unterschiedliche Ausgaben

erzeugt werden. Dies kann z.B. durch die Einbeziehung von Daten verursacht

werden, die im Dateisystem oder einer Datenbank abgelegt wurden. Als Beispiel

sei auf eine Gültigkeitsprüfung verwiesen, die nur dann zu einer Erfolgsseite

verzweigt, wenn eine Kombination von Name und Passwort als gültig

identifiziert wurde. Da die für die Prüfung verwendeten Daten aus einer

Datenbank ausgelesen wurden, kann anhand der URL kein eindeutiger

Seitenidentifikator bestimmt werden.

In diesen Fällen kann vom Betreiber der Website mit Hilfe der vom

Personalisierungssystem zur Verfügung gestellten Metasprache explizit ein

eindeutiger Seitenidentifikator in den HTML-Quelltext der Seite integriert

werden.

Explizite Variante

Wie im vorherigen Abschnitt gezeigt, ist eine explizite Benennung von

Inhaltsseiten durch den Betreiber immer dann sinnvoll, wenn eine automatische

Benennung keinen eindeutigen Bezeichner generieren kann (z.B. wegen innerer

Zustandswechsel).

3-39

3-40

Dem Betreiber muss also die Möglichkeit gegeben werden, explizit eine

Benennung der entsprechenden Inhaltsseiten vorzunehmen. Dies könnte z.B.

durch Verwendung der Metasprache realisiert werden.

<html>

<head>

...

<title>Login: Passwort bzw. Nutzername falsch!</title>

...

</head>

<body>

...

</body>

</html>

Beispiel 4: Explizite Vergabe eines Seitenbezeichners mit Hilfe von Quelltextparametern

3.1.2.3 Identifikation der Aktionselemente

Analog zur Identifikation der Session/des Nutzers und der angeforderten

Seite muss nun auch noch jedes Aktionselement der Seite identifiziert werden.

Als Aktionselemente zu verstehen sind hier Links (<a...>...</a>) sowie

Formulare (<form...>...</form>). Auch hier ist wieder sowohl eine

automatische als auch eine explizite Variante denkbar und sinnvoll.

Automatische Variante

Zur eindeutigen Benennung eines Links kann aus dem URL-Verweis

sowie der durch das öffnende und schließende Link-Tag begrenzten

Zeichenkette (u.U. auch HTML-Quelltext), ein Bezeichner gebildet werden.

Link-Tag:

<a name="link1" href="http://www.blickreich.de">QWERTY</a>

Bezeichner:

http://www.blickreich.de_QWERTY

Beispiel 5: Bildung des Bezeichners eines Aktionselementes (Link) aus der Ziel-URL und dem Link-Text

3-40

3-41

Auf ähnliche Weise ist dies auch für Formulare möglich. Der Bezeichner

kann hier aus dem Attributbereich des Form-Tags und den Namen der

einzelnen Formularfelder gebildet werden.

Formular:

</form>

Bezeichner:

/cgi-bin/dynamic.pl_KommentarKundennummerPasswortAbsenden

Beispiel 6: Für ein Formular kann der Bezeichner aus dem Attributbereich und den Namen der Fomularfelder

gebildet werden.

Um Mehrdeutigkeiten mit sonst identischen Aktionselementen auf

anderen Inhaltsseiten auszuschließen, muss auch der Seitenidentifikator bzw.

die PageID in den Bezeichner für Aktionselemente integriert werden. Für den

(sehr unwahrscheinlichen) Fall, dass nach dieser Vorschrift für zwei

Aktionselemente auf derselben Seite ein identischer Bezeichner gebildet wird,

genügt es, an vergebene Bezeichner eine fortlaufende Nummerierung

anzufügen.

Eindeutiger Bezeichner: http://www.blickreich.de_QWERTY_114_1

Beispiel 7: Anhängen des Seitenindentifikators und einer fortlaufenden Nummerierung ermöglicht eindeutige

Vergabe von Aktionselement-Bezeichnern

Der so generierte Bezeichner erlaubt die eindeutige Identifikation jedes

Aktionselementes jeder einzelnen Inhaltsseite und somit die Zuordnung jeder

Aktion eines Nutzers zu einem Aktionselement und der zugehörigen

Inhaltsseite.

3-41

3-42

Explizite Variante

Bei Einsatz des automatische Verfahrens zur Benennung von

Aktionselementen wird jedes Aktionselement aller Inhaltsseiten als einmalig

identifiziert. Dies ist aber nicht immer sinnvoll. Beispielsweise hat es Sinn, die

einzelnen Punkte eines Seiten-Menüs, welches auf mehreren Inhaltsseiten

identisch erscheint, auch seitenübergreifend zu identifizieren. Es soll also nicht

für jeden Menüpunkt auf jeder Inhaltsseite ein neuer eindeutiger Bezeichner

gebildet werden. Vielmehr ist jeder Menüpunkt, der auf mehreren Inhaltsseiten

erscheint, als funktionale Einheit zu sehen. Solche funktionalen Einheiten

müssen durch den Betreiber explizit definiert und somit benannt werden

können.

Ähnlich wie für die explizite Benennung von Inhaltsseiten kann auch hier

vorgegangen werden. Dem Betreiber müssten hierzu mit Hilfe von Elementen

der Metasprache geeignete Verfahren zur Verfügung gestellt werden.

Es bedarf also der Möglichkeit einer sinnvollen Kombination von

automatischer und expliziter Benennung von Aktionselementen. Sinnvoll könnte

hier z.B. bedeuten, einer expliziten Benennung eines Aktionselementes stets

Vorrang zu gegeben, sodass die automatische Benennung nur bei Nicht-

vorhandensein einer expliziten Benennung zum Einsatz gebracht wird. Die

explizite Benennung eines Aktionselementes könnte z.B. wie folgt geschehen:

Link-Tag:

<a name="link1" href="http://www.blickreich.de">QWERTY</a>

Beispiel 8: Explizite Vergabe eines Bezeichners für ein Aktionselement durch den Betreiber

Der Wert des Name-Attributs ("link1") stellt dabei den explizit

vergebenen Bezeichner dar. Hierbei muss es natürlich dem Betreiber überlassen

werden, auf Konsistenz und Eindeutigkeit der Bezeichner zu achten.

Auch die weiter oben angesprochenen funktionalen Einheiten ließen sich

so durch eine Mehrfachvergabe desselben Bezeichners definieren. Stünde der

3-42

3-43

Link aus obigem Beispiel in dieser Form in mehreren verschiedenen

Inhaltsseiten, so würde er dank seiner expliziten Benennung immer als ein und

dasselbe Aktionselement identifiziert. Gleiches gilt natürlich auch für Formulare.

Eine weitergehende Möglichkeit zur Benennung von Aktionselementen ist

die Bildung von funktionalen Einheiten, bestehend aus verschiedenen

Aktionselementen einer Inhaltsseite. Eine solche Gruppierung ist immer dann

sinnvoll, wenn mehrere Aktionselemente logisch einer Funktionsgruppe

zuzuordnen sind. Beispielsweise stellt eine ,,Weiter/Zurück"-Navigation einen

solchen Fall dar (siehe Beispiel 9: Definition einer funktionalen Einheit,

bestehend aus mehreren Aktionselementen). Für eine Personalisierung hat hier

nur die gemeinsame Betrachtung der Schaltflächen ,,Zurück" und ,,Weiter" Sinn,

d.h. beide Links müssen als

ein

Aktionselement identifiziert und benannt

werden. Dies könnte z.B. durch Implementierung geeigneter metasprachlicher

Konstrukte realisiert werden:

< Zurück | Weiter >

<a href="/cgi-bin/pages.pl?page=3">Zurück</a>

<a href="/cgi-bin/pages.pl?page=5">Weiter</a>

Beispiel 9: Definition einer funktionalen Einheit, bestehend aus mehreren Aktionselementen

Das Kommentar-Tag ,,qwertyBlock" übernimmt hier die Definition der

funktionalen Einheit. Alle in diesem Block eingeschlossenen Links bzw.

Formulare werden nicht länger einzeln benannt, sondern erhalten als Ganzes

den Bezeichner ,,PageFlicker". Das Beispiel zeigt auch, dass es nun möglich

ist, nicht nur Links in eine solche Gruppe einzuschließen, sondern auch anderen

zugehörigen HTML-Quelltext (hier z.B. ,,<","|",">").

3-43

3-44

Nun lassen sich durch Mehrfachvergabe von Gruppenbezeichnern sogar

seitenübergreifende funktionale Einheiten bilden. Die explizite Vergabe von

Bezeichnern ermöglicht auch, bewusst bestimmte Aktionselemente bzw.

Funktionseinheiten von der Identifikation und somit von der Personalisierung

auszuschließen. Z.B. könnte dies für Sprungmarken innerhalb einer Inhaltsseite

sinnvoll sein.

<a name="top">

...

...

Beispiel 10: Ausschluss eines Links durch Definition eines unbenannten Blocks

Die Kennzeichnung, dass dieser Sprungmarken-Link ignoriert werden

soll, erfolgt hier durch den Einschluss des Links in einen ,,qwertyBlock", der

keinen expliziten Bezeichner besitzt.

3.1.2.4 Identifikation aktiver Textdaten

Ein Personalisierungssystem sollte es erlauben, textuelle Eingaben in das

Profil eines Nutzers einfließen zu lassen.

Beispiel 11: Formulareingaben eines Nutzers - aktive Textdaten

3-44

3-45

Um dies zu realisieren, muss zunächst erkannt werden, ob es sich bei

den jeweiligen übermittelten Eingabeparametern um vom Nutzer eingegebene

Einträge handelt oder nicht. Es muss dabei beachtet werden, dass das

Personalisierungssystem nur eine URL-Anforderung erhält, in der die

entsprechenden Nutzereingaben als Parameter oder im HTTP-Request enthalten

sind. Eine einfache Unterscheidung, ob es sich um textuelle oder numerische

Einträge handelt, reicht natürlich nicht aus. Anhand einiger Beispiele soll im

Folgenden auf die Probleme bei der Erkennung von Nutzereinträgen

hingewiesen werden.

</form>

Beispiel 12: HTML-Formular mit Nutzereingabe

Es handelt sich hierbei um ein gewöhnliches HTML-Formular. Nach einem

Klick auf den Absenden-Button wird vom Client, auf dem dieses HTML-Formular

dargestellt wurde, ein HTTP-Request-Objekt erzeugt, in welchem auch die

Eingabeelemente des Formulars enthalten sind:

WarenkorbID = "347hifu472"

Extra = "Oliven, Speck"

Kommentar = [Eingabe des Nutzers]

Kundennummer = [Eingabe des Nutzers]

Passwort = [Eingabe des Nutzers]

Beispiel 13: Parameterübermittlung durch CGI-Datenübertragung

Das Personalisierungssystem hat an dieser Stelle keine Möglichkeit mehr

zu erkennen, dass es sich bei WarenkorbID und Extra nicht um aktive

Nutzereingaben handelt, im Gegensatz zu Kommentar, Kundennummer und

Passwort. Des Weiteren kann man feststellen, dass in bestimmten

Eingabefeldern zwar aktive Texteingaben erfolgen, aber möglicherweise keine

3-45

3-46

sinnvollen Daten in Bezug auf ein Nutzerprofil zu erwarten sind. So hat es

beispielsweise keinen Sinn, die Kundennummer in eine Personalisierung des

Nutzerwortschatzes mit einzubeziehen. Ein weiterer Punkt wird am

beschriebenen Fall deutlich. Einige Felder sollten aus Sicherheitsgründen nicht

ausgewertet werden. Dies betrifft hier das Passwort-Feld.

Anhand der Aufzählungen lässt sich erkennen, dass es notwendig ist,

auszuwertende Eingabefelder explizit zu bestimmen. Der Betreiber muss die

Möglichkeit erhalten, die Eingabefelder zu spezifizieren, auf die er

Personalisierungstechniken anwenden möchte. Dies kann mit Hilfe der

Metasprache erreicht werden, z.B. durch Verwendung eines Attributs, welches

dem entsprechenden HTML-Input-Tag hinzugefügt wird:

Alternativ ist dies auch durch einen umschließenden Kommentarblock

realisierbar, da nicht alle visuellen HTML-Editoren das Einfügen beliebiger

Attribute erlauben:

Wie wir feststellen konnten, erhält das Personalisierungssystem die

Formulardaten über das HTTP-Protokoll in Form eines Requests. Um nun

herauszufinden, welche übermittelten Argumente auszuwerten sind, müsste die

Ausgangsseite erneut geladen und der Quelltext nach den oben beschriebenen

Metasprachelementen durchsucht werden. Dies stellt keine sonderlich

ökonomische Variante dar. Deshalb wird bereits beim Schritt zuvor, nämlich bei

der Anforderung der Seite, die das Formular enthält, diese Analyse

vorgenommen. Da jede Seite ohnehin einmal geparst werden muss, stellt es

keine Zusatzlast mehr dar. Dem Formular wird nun in diesem Schritt bereits ein

weiteres ,,hidden"-Feld hinzugefügt, welches Informationen über die

auszuwertenden Formular-Felder enthält. Mit Hilfe dieses ,,hidden"-Felds

können schließlich vom Personalisierungssystem die entsprechenden

Eingabefelder als aktive textuelle Daten behandelt und zur

3-46

3-47

Informationsverarbeitung an das zuständige Linguistik-Modul weitergereicht

werden. Dies geschieht über die Schnittstelle zwischen Datengewinnungs- und

Informationsgewinnungsschicht.

Eine genaue technische Betrachtung zeigt, dass es nicht notwendig ist,

die kompletten textuellen Daten abzulegen. Da die Textdaten bereits bei der

Protokollierung der Nutzeraktionen und der dabei gespeicherten Parameter-

Werte-Paare in der Datenbank aufgenommen werden, ist es ausreichend, nur

die Parameter-Bezeichner in einer separaten Tabelle für die Protokollierung der

Textdaten abzulegen. Es wäre prinzipiell auch denkbar, diese Parameter-

Bezeichner direkt in die Tabelle, welche für die Protokollierung der

Nutzeraktionen zuständig ist, zu speichern. Jedoch muss man bedenken, dass

es sich bei dem überwiegenden Teil von Nutzeraktionen um Navigationen

handelt, nicht um textuelle Eingaben. Eine seperate Speicherung ist demzufolge

wesentlich ökonomischer.

Folgendes Beispiel zeigt die Verwendung des Attributes ,,qwertyUse" zur

expliziten Kennzeichnung der zu verarbeitenden Formularfelder durch den

Betreiber. Es wurde ein zusätzliches verstecktes Feld eingefügt, welches die

Bezeichner aller mit ,,qwertyUse" gekennzeichneten Formularfelder enthält:

<input type=text name="Kommentar"

qwertyUse

<input type=hidden name="qwertyUserText" value="Kommentar">

</form>

Beispiel 14: Spezifikation zu verarbeitender Eingabefelder

3.1.2.5 Identifikation passiver Textdaten

Im letzten Abschnitt wurde diskutiert, wie aktive Eingaben der Nutzer

erkannt und als Daten für die Informationsgewinnung bereitgestellt werden

können. Aktive Eingaben des Nutzers haben einen direkten Bezug zu dessen

3-47

3-48

persönlichem Profil. Deshalb sind diese Daten besonders interessant für eine

Personalisierung.

Beispiel 15: Durch die Anwendung bereitgestellte Texte - passive Textdaten

Abhängig von der konkreten Anwendung sind Eingaben jedoch im

Verhältnis zu anderen Aktionen der Nutzer, etwa der Navigation, relativ selten.

Wesentlich häufiger ist der Nutzer passiv, indem er z.B. Seiteninhalte liest. Auch

dies sagt etwas über die Eigenschaften des Nutzers aus, z.B. über thematische

Interessen bezüglich des gelesenen Textes.

Im Zusammenhang mit der Navigation ist es daher sinnvoll, auch diese

passiven Textdaten zu betrachten. Bei passiven Textdaten handelt es sich

demnach um Texte, welche nicht vom Nutzer, sondern von der Anwendung

bereitgestellt werden. Natürlichsprachliche Inhalte einer Seite, die vom Nutzer

gelesen wurde, gehören dazu - idealerweise nur wirklich relevante Inhalte.

3-48

3-49

Damit haben wir jedoch zugleich weitere Fragen aufgeworfen. Was sind

relevante Inhalte und welche Seiten wurden vom Nutzer tatsächlich gelesen?

Dies sind Probleme, welche auf der Ebene der Datengewinnung keine

Betrachtung finden können. Dazu müssen zunächst Navigationsdaten und

Textdaten analysiert werden, was jedoch erst auf der Informations-Ebene

geschieht. Aufgabe des Datengewinnungsmodules ist es lediglich, die Daten

möglichst verlustfrei bereitzustellen, die bei der Informationsverarbeitung

genutzt werden können.

Im Fall der passiven Textdaten bedeutet eine verlustfreie Bereitstellung,

dass der gesamte Quelltext einer Seite gespeichert werden muss, bis er auf

Informationsebene verarbeitet wurde. Genauer betrachtet entspricht dies der

Speicherung der aktuellen Seite eines jeden aktiven Nutzers, welche bei einem

erneuten Seitenaufruf überschrieben werden kann, da dann die

Informationsverarbeitung bereits stattgefunden hat.

3-49

3-50

3.1.2.6 Protokollierung der Seitenanforderung

Um eine spätere Auswertung zu ermöglichen, müssen nun alle

relevanten Daten der Anforderung in geeigneter Form abgelegt werden, wofür

nur eine leistungsfähige Datenbank in Frage kommen dürfte. Diese Datenbank

enthält dann im Wesentlichen zwei Arten von Daten: Daten zu referenzierten

Objekten (Seiten, Links) sowie dem Protokoll, welches die Seitenanforderungen

in chronologischer Ordnung enthält.

User

Protocol

Inputs

UserID

EventID

InputID

SessionID

UserID

ProtocolID

PageCache

TimeStamp

FormName

SourcePageID

FieldName

Pages

PageID

FieldValue

PageID

SourceLinkID

PageIdent

PageURL

Links

PageParams

LinkID

LinkIdent

LinkAttr

PageID

Abbildung 7: Strukturschema der Datenbank

Tabelle Pages

Die Einträge in dieser Tabelle repräsentieren die eindeutig identifizierten

Seiten, auf die in mindestens einer protokollierten Seitenanforderung Bezug

genommen wurde. Bei jeder Seitenanforderung muss also zunächst geprüft

werden, ob bereits eine Seite mit diesem Bezeichner in Pages existiert. Ist dies

der Fall, so wurde diese Seite zu einem früheren Zeitpunkt schon einmal

angefordert, d.h. es kann auf den bestehenden Eintrag referenziert werden.

Enthält Pages noch keinen Eintrag für diesen Bezeichner, so stellt dies eine

erstmalige Anforderung dieser Seite dar, d.h. es muss ein neuer Eintrag in

Pages erzeugt und dann auf diesen referenziert werden. Mit Hilfe dieser

Methode lassen sich später Aktionen eines oder mehrerer Nutzer in direkten

Bezug zu einer Seite stellen.

3-50

3-51

Tabelle Links

Analog zur Tabelle Seiten repräsentieren die Einträge der Tabelle

Links sämtliche eindeutig identifizierten Links, die in allen angeforderten

Seiten enthalten waren. Auch hier muss der Bezeichner jedes identifizierten

Links zunächst auf Existenz in Links geprüft, ggf. eingetragen und dann

referenziert werden.

Tabelle Protocol

Alle Einträge in diese Tabelle repräsentieren Seitenanforderungen. Zu

jeder Anforderung werden die ID der Ursprungsseite, die ID des verwendeten

Links, die ID der angeforderten Seite, die Session- bzw. Nutzer-ID sowie Datum

und Uhrzeit gespeichert.

Tabelle User

Die Tabelle User erfüllt mehrere Aufgaben. Primär ist sie für die

Sessionverwaltung, also für die Zuordnung von SessionIDs und NutzerIDs

verantwortlich. Das Feld PageCache nimmt bei jeder neuen Seitenanforderung

den Quelltext dieser Seite auf. Dies ist für die Auswertung des Seiteninhaltes

wichtig, der erst mit der nächsten Seitenanforderung vorgenommen werden

kann. Zusätzlich macht das Caching der angeforderten Seiten auch das

Echtzeit-Monitoring der Nutzeraktionen möglich.

Tabelle Inputs

In dieser Tabelle werden alle textuellen Eingaben der Nutzer abgelegt.

Dabei werden der Name des Formulars sowie der Feldname und Feldwert des

jeweiligen Eingabefeldes referenziert. Gemeinsam mit dem Eintrag

ProtocolID wird somit eine eindeutige Referenz zu der Datenquelle

gespeichert.

3-51

3-52

3.1.2.7 Modifikation des HTML-Quelltextes

Um eine spätere genaue Rekonstruktion der Navigationswege zu

ermöglichen, ist es notwendig, dass durch das Datensammler-Modul gewisse

Informationen im Quelltext der angeforderten Seite hinterlegt werden, die es

ermöglichen, diese Seite mit der nächsten durch den Nutzer angeforderten

Seite in Beziehung zu setzen. Das heißt nichts anderes, als dass jeder

Seitenanforderung die Ursprungsseite, also die Seite, die den zur Anforderung

verwendeten Link enthält, zugeordnet werden kann. Mit jeder

Seitenanforderung, müssen also die PageID der Ursprungsseite und die LinkID

des verwendeten Links bzw. Formulars mit übermittelt werden.

Bei normalen Links ist dies durch Anhängen der IDs als Parameter an die

URL des href-Attributes realisierbar:

<a href="/support.pl?xyz=10&srcpageid=46&

srclinkid=114&sessionid=18377563">...</a>

Beispiel 16: Übermittlung von Ursprungsseiten-, Link- und Session-Indentifikator als URL-Parameter

Anders bei Formularen. Da hier ein Anhängen der Parameter an die

action-URL nicht möglich ist, muss für jeden Parameter ein verstecktes

Formularfeld in das Formular eingefügt werden, was in der Regel keine

Probleme verursachen sollte, da solche Formularfelder keinerlei Einfluss auf

Layout und Funktion der Inhaltsseite haben.

</form>

Beispiel 17: Übermittlung von Ursprungsseiten-, Link- und Session-Indentifikator als versteckte Formularfelder

Wie in obigem Beispiel zu sehen, kann neben den IDs für Ursprungsseite

und verwendeten Link auf gleichem Weg auch die ID der Session übermittelt

3-52

3-53

werden. Insgesamt werden also mit jeder Seitenanforderung drei Parameter an

das Datensammler-Modul übermittelt.

3-53

3-54

3.2 Informationsgewinnung

Wie der Name bereits sagt, hat das Datensammler-Modul allein die

Aufgabe, alle nur möglichen relevanten Daten zu Seitenanforderungen zu

sammeln und zu protokollieren. Diese Daten allein ermöglichen allerdings noch

nicht den Einsatz von Personalisierungstechniken. Der gesammelte

Datenbestand besteht nur aus einem chronologisch geordneten Protokoll aller

Seitenanforderungen und der durch dessen Einträge referenzierten Objekte

(Seiten, Aktionselemente, Sessions/Nutzer).

Diese große Menge von Daten muss also zunächst weiterverarbeitet

werden, um aus ihr so viel Information wie möglich zu gewinnen. Wie wir

später sehen werden, handelt es sich dabei nicht nur um Informationen zu den

Nutzern und deren Verhalten. Vielmehr erlauben die gewonnenen

Informationen zusätzlich auch Rückschlüsse zu Eigenschaften des

Informationssystems selbst.

Die durch das Datensammler-Modul bereitgestellten Daten lassen sich im

Wesentlichen in zwei Arten gliedern: Navigationsdaten und Inhaltsdaten. Unter

Navigationsdaten sind hier die Daten aller durch Nutzer verursachten

Seitenanforderungen zu verstehen. Inhaltsdaten hingegen stellen die durch die

Analyse der Seiteninhalte und der bei den Seitenanforderungen übermittelten

Parameter gewonnenen Daten dar.

3.2.1 Informationsgewinnung aus Aktionsdaten

Der Hauptanteil der durch das Datensammler-Modul bereitgestellten

Daten bezieht sich direkt auf die Aktionen des Nutzers.

3.2.1.1 Aktionen

Wie oben erwähnt repräsentiert der Bestand der gesammelten Daten im

Wesentlichen die Aktionen des Nutzers, z.B. Klicks auf Links oder das Absenden

3-54

3-55

von Formularen. Aus diesen Daten lassen sich vielerlei Informationen über das

Verhalten des Nutzers gewinnen. Die aus diesen Daten direkt gewonnenen

Informationen bilden dabei die unterste Komplexitätsstufe.

Browser

Seite

Web-

Link

Seitenanforderung

server

klick

Abbildung 8: Schema Nutzeraktion - Klick

Häufigkeit und Intensität der Nutzung

Eine grundlegende Information, die sich aus Aktionsdaten gewinnen

lässt, ist die Häufigkeit der Nutzung eines Aktionselementes durch den Nutzer.

Dieser Wert liegt zwischen Null und einer beliebig großen Zahl. Er erlaubt

indirekt die Beurteilung der Relevanz dieses Aktionselementes für den Nutzer.

Für eine direkte Beurteilung kann die Nutzungshäufigkeit eines

Aktionselementes nur ins Verhältnis zur durchschnittlichen Nutzungshäufigkeit

aller anderen Aktionselemente bzw. der Häufigkeit des meistgenutzten

Aktionselementes gesetzt werden. Der so gewonnene Wert - die

Nutzungsintensität - steht für den Grad des Umfanges der Nutzung des

Aktionselementes durch den Nutzer.

Häufigkeit

Intensität

Häufigkeiti

Gleichung 2: Nutzungsintensität

3-55

3-56

Für folgendes Beispiel wurde anhand der Nutzungshäufigkeit von zehn

Aktionselementen deren Nutzungsintensität bestimmt.

Element

Häufigkeit

Intensität 1,11 2,15 0,07 1,6 1,32 0,42

0,14 3,13 0,07

Beispiel 18: Nutzungshäufigkeit und -intensität von zehn Aktionselementen

Eine Nutzungsintensität von 1 bezeichnet eine durchschnittliche

Nutzungshäufigkeit. Werte größer bzw. kleiner als 1 bezeichnen eine über- bzw.

unterdurchschnittliche Nutzungshäufigkeit.

3.2.1.2 Seitenwechsel

Die im vorherigen Abschnitt besprochenen Aktionsdaten lassen sich im

Regelfall auch als Seitenanforderungen interpretieren, da die meisten der

Nutzeraktionen nichts anderes als Klicks auf Links oder auch das Absenden von

Formularen darstellen.

Jede neue durch eine Nutzeraktion ausgelöste Seitenanforderung kann

bildlich als Ortswechsel dieses Nutzers angesehen werden - vorrausgesetzt, es

wurde wirklich eine neue Seite angefordert und nicht die aktuelle Seite ein

zweites Mal angefordert.

3-56

3-57

Browser

Seite 1

Seite 2

Ortswechsel

klick

Seitenanforderung

Web-

server

Abbildung 9: Klick und Standortwechsel

Häufigkeit und Intensität

Analog zur Häufigkeit und Intensität der Nutzung von Aktionselementen

lassen sich diese Werte auch für Seitenanforderungen berechnen. Die

Häufigkeit stellt hier die Anzahl der Aufrufe einer bestimmten Inhaltsseite (die

Zielseite des Seitenwechsels) dar. Auch die Aufrufintensität lässt sich analog zur

Nutzungsintensität von Aktionselementen bestimmen.

3.2.1.3 Navigationswege

Nicht jeder Link und die damit verbundene Seitenanforderung führt den

Nutzer zu den gewünschten Inhalten. Oft bedarf es der Nutzung einer Reihe

von Links, die ihn durch die verschiedenen Hierarchieebenen des

Informationssystems führen, bis er schließlich zur gewünschten Inhaltsseite

gelangt. Die auf diesem Weg aufgerufenen Seiten interessieren den Nutzer

dabei oft nur insofern, als dass sie den Link zur nächsten Seite des

Navigationsweges enthalten. Die Analyse dieser Navigationswege erlaubt

3-57

3-58

Rückschlüsse auf eine Vielzahl von Eigenschaften des Nutzers sowie des

Informationssystems selbst.

Der erfasste Datenbestand erlaubt die Rekonstruktion des Weges, auf

dem sich ein Nutzer durch die Seitentopologie des Informationssystems bewegt

hat, d.h. wann und in welcher Reihenfolge er, mit Hilfe welcher Links, von einer

Seite aus eine andere aufgerufen hat. Eine Nutzungssession besteht in der

Regel aus mehreren solcher Standortwechsel.

Ein Navigationsweg sei also definiert als eine zusammenhängende Kette

von Standortwechseln, beginnend mit einer Startseite und endend mit einer

Zielseite. Um einen Navigationsweg zu identifizieren, muss nun zunächst geklärt

werden, was unter einer Start- bzw. Zielseite zu verstehen ist, d.h. was diese

von anderen Seiten unterscheidet.

Die Startseite bildet den Ausgangspunkt eines Navigationsweges. Diese

kann entweder die erste innerhalb der Session angeforderte Inhaltsseite des

Informationssystems oder die ,,ehemalige" Zielseite des zuvor zurückgelegten

Navigationsweges sein. Die Behandlung des ersten Falles ist trivial, da sich der

erste Seitenaufruf innerhalb einer Session direkt aus dem Datenbestand

ermittelt lässt. Für die Behandlung des zweiten Falles genügt die Definition des

Begriffes ,,Zielseite".

Die Zielseite eines Navigationsweges bildet den Endpunkt der Kette von

Seitenanforderungen, die der Nutzer auf dem Weg zu den von ihm

gewünschten Inhalten ausgelöst hat, d.h. die Zielseite enthält diese

gewünschten Inhalte. Natürlich lässt sich nicht direkt ermitteln, um welche

Inhalte es sich dabei handelte. Allerdings kann die Verweildauer eines Nutzers

auf einer Seite ermittelt werden, indem die Differenz der Zeitpunkte des

Aufrufes dieser und des der nächsten Inhaltsseite berechnet wird.

Nimmt man nun an, dass der Nutzer auf Seiten, mit für ihn interessanten

Inhalten, länger verweilt, als auf Seiten, für deren Inhalte er sich weniger

interessiert, so ließe sich der Begriff ,,Zielseite" und damit der Navigationsweg

3-58

3-59

auch wie folgt definieren: Ein Navigationsweg bildet sich aus einer Anfangsseite

mit langer Verweildauer, gefolgt von einer oder mehreren Seitenanforderungen

in kurzen Abständen und abgeschlossen durch die Zielseite mit wiederum einer

langen Verweildauer, wobei diese Zielseite auch die Anfangsseite eines

nachfolgenden Navigationsweges darstellen kann.

"Seite 1"

"Seite n"

Start-

"Seite 2"

"Seite 3"

"Seite n-1"

Zielseite

seite

lange Verweildauer

kurze Verweildauer

lange Verweildauer

Abbildung 10: Navigationsweg als Kette von Seitenanforderungen

Die Bestimmung eines Navigationsweges gründet sich also neben den

gesammelten Daten der Seitenanforderungen allein auf die berechnete

Verweildauer der einzelnen Wegseiten. Dies bringt leider eine Reihe von

Problemen mit sich:

Nicht aus jedem längeren Aufenthalt eines Nutzers auf einer Inhaltsseite

kann sicher geschlossen werden, dass es sich dabei wirklich um die Seite mit

den gewünschten Inhalten - also die Zielseite - handelt. Ebenso ist es möglich,

dass der Nutzer auch nur für eine Weile abgelenkt ist (z.B. Telefonanruf) und

seinen Navigationsweg später fortsetzen wird. Denkbar ist auch der Fall, dass

der gewünschte Inhalt nur einen kurzen Aufenthalt auf dieser Seite erfordert

(z.B. für einen Download), was die Erkennung des Zielpunktes eines

Navigationsweges ebenfalls unsicher macht. Hier müssen also Maßnahmen

getroffen werden, die helfen, derartige Situationen zu erkennen und eine

Fehlinterpretation zu verhindern, z.B. unter Einbeziehung statistischer

Verfahren.

Zu ermittelten Navigationswegen lassen sich - wie auch bei Aktionen und

Seitenwechseln - gewisse Informationen ableiten. Neben der Häufigkeit und

3-59

3-60

Intensität der Nutzung ist hier auch die Geschwindigkeit der Navigation von

Interesse.

Sonderfall: Wiederholtes Anfordern einer Seite

Browser bieten in der Regel eine "Aktualisieren"-Funktion. Diese dient

dazu, die aktuelle Seite erneut zu laden, d.h. sie beim Server wiederholt

anzufordern. Dabei wird diese Seitenanforderung zunächst wie jede andere

Anforderung behandelt und ein neuer Protokolleintrag erzeugt.

Die Möglichkeit solcher doppelter Einträge muss deshalb bei der

Wegerkennung Berücksichtigung finden. Dies stellt allerdings kein großes

Problem dar, da hierzu einfach aufeinanderfolgende Seitenaufrufe eines Nutzers

verglichen und ggf. ignoriert werden müssen.

Sonderfall: "Vor"- bzw. "Zurück"′-Navigation / Browser-Cache

Wesentlicher Bestandteil der Browserfunktionalität stellt die Navigation

mit Hilfe der "Vor"- und "Zurück"-Schaltflächen dar. Ist eine angeforderte Seite

vollständig geladen, so wird sie in der Regel vom Browser in einen dafür

vorgesehenen Cache-Speicher abgelegt, um sie bei einem erneuten Aufruf

schneller verfügbar machen zu können. Die Seite wird dann nicht neu vom

Webserver angefordert, sondern direkt aus dem Browser-Cache geladen.

3-60

3-61

Cache

Browser

Zurück

Vor

Zurück

Vor

Zurück

Vor

Zurück

Vor

Seite 1

Seite 2

Seite 1

Seite 3

klick

Seite 2

Seite 3

klick

W ebserver

Abbildung 11: Anforderung einer Seite, Ablage im Cache und erneuter Aufruf. Der zweite Aufruf von Seite 1

geschieht ohne erneute Seitenanforderung

Der Vorteil eines schnelleren Seitenaufbaus für den Nutzer ist hier

gleichzeitig ein Nachteil für das Personalisierungssystem, da es diesen Vorgang

nicht direkt beobachten kann.

Seite 1

Seite 2

Seite 3

Abbildung 12: Verfälschte Navigationsdaten - Nutzer befindet sich scheinbar gleichzeitig auf Seite 2 und Seite 3

3-61

3-62

Jedoch erlaubt der verfälschte Datenbestand eine nachträgliche

Rekonstruktion einer solchen Nutzernavigation, z.B. durch Einfügen zusätzlicher

Seitenwechsel:

Seite 1

Seite 2

Seite 3

Abbildung 13: Rekonstruierter Weg nach Einfügen eines zusätzlichen Seitenwechsels

Sonderfall: Mehrere Browserfenster

Im Normalfall wird bei Betätigung eines Links die neue Seite in dem

selben Browserfenster aufgebaut und ersetzt somit die aktuelle Seite. Allerdings

kann der Nutzer den Browser auch veranlassen, die gewünschte Seite in einem

gesonderten Browserfenster zu öffnen, wobei die aktuelle Seite im alten

Browserfenster erhalten bliebe. Die Möglichkeit einer theoretisch beliebigen

Anzahl von Browserfenstern eines Nutzers stellt ein schwieriges aber auch

lösbares Problem für die Wegeerkennung dar.

3-62

3-63

Browser A

Browser B

Seite 1

Seite 2

klick

Seitenanforderung

Web-

server

Abbildung 14: Durch Klick auf Link ,,Seite 2" wird ein neues Browserfenster geöffnet

Dieser Vorgang erscheint für das Personalisierungssystem zunächst als

normaler Seitenwechsel. Dass ,,Seite 2" in einem neuen Browserfenster

angefordert wurde, kann es nicht feststellen. Navigiert der Nutzer nun

abwechselnd in beiden Fenstern, so könnte sich beispielsweise folgendes Bild

ergeben:

Browser B

Seite 2

Seite 4

Seite 5

Browser A

Seite 1

Seite 3

Seite 6

0:00

0:25

0:35

0:40

0:55

1:15

Abbildung 15: Wechselseitige Navigation mit zwei Browserfenstern

Da der erfasste Datenbestand zu Seitenanforderungen die Bezeichner

sowohl der angeforderten Seiten und des verwendeten Links als auch der

3-63

3-64

Ursprungsseite umfasst, ist eine Behandlung solcher Situationen sehr gut

möglich. Hierfür ist eine Reihe verschiedener Vorgehensweisen denkbar:

Eine Variante stellt - ähnlich wie beim "Zurück"-Button-Problem - das

Einfügen zusätzlicher imaginärer Seitenwechsel in den Datenbestand dar:

Browser B

Seite 2

Seite 4

Seite 5

Browser A

Seite 1

Seite 3

Seite 6

0:00

0:25

0:35

0:40

0:55

1:15

Seite 1

Seite 2

Seite 4

Seite 5

Seite 1

Seite 3

Seite 6

0:00

0:25

0:30

0:45

0:45+X

0:55+X

1:15+X

Abbildung 16: Bereinigung des Datenbestandes durch Einfügen eines imaginären Seitenwechsels und

Korrektur des zeitlichen Verlaufes (X steht für die unbekannte Aufenthaltdauer auf Seite 5)

Beide Wegstränge werden zu einem Navigationsweg vereint, indem der

abgeschlossene Seitenstrang in den Hauptstrang eingefügt wird. Der zeitliche

Verlauf muss dabei korrigiert werden, um eine spätere Ermittlung der

Aufenthaltsdauer des Nutzers auf den einzelnen Seiten zu ermöglichen.

3-64

3-65

Als alternative Vorgehensweise ist eine unabhängige Betrachtung und

Auswertung der beiden Wegstränge möglich. Für das obige Beispiel würde dies

folgendes bedeuten:

Seite 1

Seite 3

Seite 6

0:00

0:10

0:30

Seite 1

Seite 2

Seite 4

Seite 5

0:00

0:25

0:30

0:45

Abbildung 17: Bereinigung des Datenbestandes durch unabhängige Betrachtung der Wegstränge und

Korrektur des zeitlichen Verlaufs

Der durch Öffnen des zweiten Browserfensters neu entstandene

Wegstrang wird als eigenständig interpretiert. Der Haupt-Wegstrang bleibt

dabei erhalten. Der zeitliche Verlauf der einzelnen Seitenanforderungen beider

Stränge muss auch hier korrigiert werden.

3.2.2 Textbasierte Informationen

Wie wir bereits feststellten, können Nutzer durch das Anklicken eines

aktiven Elementes einer Website interagieren. Ein solches Element kann z.B. ein

Link sein. Handelt es sich um einen Formularbutton, so werden in der Regel

auch Formulartexte übertragen, die vom Nutzer auf dieser Seite eingegeben

wurden.

3-65

3-66

Aktive textbasierte Informationen

Neben Navigationsinformationen lassen sich deshalb auch textbasierte

Informationen mit dem Nutzer in Zusammenhang bringen. Im oben genannten

Fall liegen aktive, textbasierte Informationen vor, da diese aktiv vom Nutzer

eingegeben wurden.

Nutzereingabe Herkunftsformular

,,Wüste, Australien"

Bild-Suchfunktion

,,Deutschland"

Ländereingabe beim Upload eines

Bildes

,,Suche einen Reisepartner für eine

Forum-Eintrag

Transsahara-Tour Anfang Dez 2002"

Beispiel 19: Beispiele für Nutzereingaben in einem Reiseportal

Passive textbasierte Informationen

Wir sprechen von passiven textbasierten Informationen, wenn Texte

betrachtet werden, welche zwar nicht vom Nutzer eingegeben wurden, aber

dennoch mit dem Nutzer in Zusammenhang gebracht werden können. Dies ist

bei dynamischen Seiteninhalten der Fall. Nutzer treffen eine Aussage über die

Qualität einer Seite, gemessen an ihrem aktuellen Interesse, indem sie kürzer

oder länger auf dieser Seite verweilen. Um diese Aussage in ein Nutzerprofil

einfließen zu lassen, bietet es sich an, die textuellen Informationen dieser Seite

so zu verarbeiten, dass sie möglichst einfach abzuspeichern und zu

interpretieren sind.

3.2.2.1 Verarbeitung von Textdaten

Bei der Datengewinnung wurden textuelle Eingaben des Nutzers sowie

von der Anwendung bereitgestellte Texte, also beliebige textuelle Seiteninhalte,

protokolliert. Auf der Datenebene handelt es sich hierbei zunächst nur um

Zeichenketten. Erst wenn diese Terme in Relation zu bereits existierenden

Informationen über die natürliche Sprache oder zu existierenden Informationen

3-66

3-67

über bisherige Nutzereingaben gebracht werden können, ist es möglich, daraus

Informationen zu gewinnen und mit diesen das persönliche Profil des Nutzers

zu beeinflussen. Dazu wollen wir an einem Beispiel betrachten, welche

Informationen in Textdaten enthalten sein können und wie wir diese für unsere

Personalisierungstechniken verwenden können.

Nehmen wir einen beliebigen natürlichsprachlichen Term her:

"New Orleans in der Nacht".

Es könnte sich bei dieser Phrase um eine Suchanfrage in einem

Reiseportal handeln. Völlig unabhängig von der Suchfunktion würde es nun

sinnvoll erscheinen, wenn ein Personalisierungssystem anhand dieses

Suchausdrucks feststellen könnte, dass der Nutzer Interesse an Inhalten zum

Thema "New Orleans" in Zusammenhang mit "Nacht" hat.

Dabei sind wir soeben die ersten Schritte bereits gegangen. Zunächst

haben wir intuitiv den Term in Wörter unterteilt, d.h. segmentiert. In diesem

Fall ist das nicht schwierig, die Teilung wird anhand der Leerzeichen

vorgenommen. Leerzeichen sind jedoch nicht der einzige Trenn-Operator. Auch

Kommata, Satzzeichen und andere Sonderzeichen sind zu bedenken. Bei

einigen Sonderzeichen muss wiederum beachtet werden, dass diese zwar Satz-

und damit auch Wortgrenzen kennzeichnen, allerdings auch innerhalb eines

Wortes als Bestandteil von Eigennamen auftreten: "amazon.com", "Yahoo!".

Des Weiteren haben wir bereits intuitiv den Suchausdruck auf

Kollokationen (siehe ,,Grundbegriffe zur Computerlinguistik", Seite 5-121)

untersucht und "New" sowie "Orleans" als zusammengehörige Wörter erkannt.

Auch dies fiel uns nicht sonderlich schwer; etwas komplexer wird dieser

Vorgang, wenn Kollokationen über den gesamten Term verstreut sind. Gerade

Verbalphrasen treten oftmals nicht in direkter Nachbarschaft auf, so dass

zwischen zusammengehörigen Wörtern durchaus andere Wörter stehen

können. An dieser Stelle muss man sich jedoch fragen, in welchem Verhältnis

der zu betreibende Aufwand zum erwarteten Erfolg steht. Noch mussten wir

uns nicht festlegen, ob die Techniken der Computerlinguistik in Echtzeit

3-67

3-68

ausgeführt werden sollen oder nicht. Aber selbst wenn dies nicht der Fall ist, so

können durchaus enorme Mengen an Textdaten zu verarbeiten sein. Ein hoher

Rechenaufwand muss ausreichend gerechtfertigt sein.

Schließlich wurden Wörter entfernt, die vermeintlich keine Bedeutung

haben. Die Wörter "in" und "der" sind typische Funktionswörter (siehe Kapitel

,,Grundbegriffe zur Computerlinguistik" Seite 5-121) mit sehr geringer

Eigenbedeutung. So wurden schließlich aus dem Term "New Orleans in der

Nacht" die so genannten bedeutungstragenden Einheiten "New Orleans" und

"Nacht".

Fassen wir die bereits erfolgten Analysen noch einmal zusammen:

(Originaltext)

New Orleans in der Nacht

Segmentieren

New | Or