FS.identify – Identifizieren von Benutzer:innen

Jedes Mal, wenn eine Seite oder ein Bildschirm eines:einer Benutzer:in geladen wird, der:die identifiziert werden kann, benötigst du JavaScript, um die Funktion FS.identify aufzurufen. So kannst du deine eigene anwendungsspezifische ID mit dem:der aktiven Benutzer:in verknüpfen. In diesem Artikel bezeichnen wir dies als UID („Unique User ID“, also eindeutige Benutzer-ID).

FS.identify(uid); // UID ist ein String, der eine eindeutige Kennung für den:die aktuelle:n Benutzer:in enthält.

Fullstory bewahrt die Benutzeridentität mithilfe von Cookies auf, die sich im Laufe der Zeit und zwischen den Geräten ändern können. FS.identify ermöglicht es Fullstory, das aktuelle Cookie mit dem:der Benutzer:in zu verknüpfen, da deine Anwendung eine eindeutige Identifizierung durchführen kann. Wir verwenden den Begriff UID, um auf die ID deiner App für eine:n bestimmte:n Benutzer:in zu verweisen.

Du solltest FS.identify nicht für anonyme oder Gastbenutzer:innen verwenden, da du nicht wirklich weißt, wer sie sind. (Du kannst jedoch mit FS.setUserVars benutzerdefinierte Variablen nicht identifizierten Benutzer:innen zuweisen).

Vorsicht! Du kannst eine Person nicht erneut identifizieren, nachdem du ihr mit FS.identify eine eindeutige ID gegeben hast. Beim Versuch, FS.identify für eine:n bereits identifizierte:n Benutzer:in aufzurufen, wird die Session aufgeteilt und ein:e neue:r, separate:r Benutzer:in erstellt. Wenn du FS.identity nicht auf der Abmeldeseite oder dem Abmeldebildschirm verwendest, kannst du verhindern, dass verschiedene Benutzer:innen, die einen Browser teilen, verwechselt werden.

Die UID ist für Fullstory undurchsichtig. Sie ist aber ein nützliches Suchkriterium.

Eine Session wird nur geteilt, wenn beim Aufruf ein anderer Wert für die UID übergeben wird. Wenn du also FS.identify erneut mit derselben UID, aber mit zusätzlichen FS.setUserVars-Werten aufrufst, wird die Session nicht geteilt.

Bitte beachte, dass das Setzen des UID-Feldes in FS.setUserVars dem Aufruf von FS.identity entspricht. Wenn also die UID an beide Aufrufe nacheinander übergeben wird, führt dies zu einer erneuten Identifizierung und einer Aufteilung der Session.

Best Practices für UIDs

Es gibt einige Best Practices, an die du dich bei der Auswahl von UIDs zur Verwendung mit FS.identify halten solltest.

• Eine UID sollte eine:n Benutzer:in innerhalb deiner Anwendung eindeutig identifizieren, aber der UID-String selbst sollte keine persönlichen Informationen enthalten oder für eine:n bestimmte:n Benutzer:in öffentlich erratbar sein.

• Informationen wie E-Mail-Adressen oder Telefonnummern solltest du generell nicht als UIDs verwenden.

  • Warum sollte ich keine E-Mail-Adresse als UID verwenden? Für Unternehmen, die es Benutzer:innen ermöglichen, E-Mail-Adressen zu ändern und dasselbe Benutzerkonto weiterhin zu verwenden, bedeutet die Verwendung der E-Mail-Adresse als UID, dass bei einer Änderung der E-Mail-Adresse ein:e neue:r Benutzer:in in Fullstory für die neue E-Mail-Adresse erstellt wird. Dies ist möglicherweise kein gewünschtes Verhalten. Wenn dieses Verhalten akzeptabel ist, kannst du die E-Mail-Adresse als UID verwenden. Andernfalls empfehlen wir, für die UID eine eindeutige ID aus deiner Kundendatenbank zu verwenden und stattdessen die E-Mail-Adresse als Benutzervariable bereitzustellen (siehe FS.setUserVars).

• Wir empfehlen, bei UIDs keine Sonderzeichen wie Doppelpunkte einzufügen.

• Außerdem solltest du FS.identify nur aufrufen, nachdem sich ein:e Benutzer:in erfolgreich bei deiner Anwendung authentifiziert hat.

Angenommen, du verwendest Integer als eindeutige Schlüssel für Benutzer:innen in deiner Anwendungsdatenbank. Da diese undurchsichtig und nicht persönlich identifizierbar sind, eignen sie sich als UIDs. Du kannst ein:e Benutzer:in wie folgt identifizieren:

FS.identify('462718483'); // 462718483 erscheint in deiner Anwendungsdatenbank als die ID dieses:dieser Benutzer:in.

Wenn du in deiner Anwendung noch keine solche eindeutige Kennung hast, kannst du sie am besten mithilfe eines HMAC generieren. Durch Erstellen eines HMAC einer ansonsten ungeeigneten UID (z. B. einer E-Mail-Adresse) unter Verwendung eines serverseitigen Geheimnisses wird sie undurchsichtig.

Wenn deine Anwendung beispielsweise E-Mail-Adressen verwendet, um Benutzer:innen zu identifizieren, könntest du einen HMAC auf deinem Server wie folgt generieren (Pseudocode):

email_hmac = HMAC(secret, 'daniel.falko@example.com');

Dieser HMAC-Wert sollte an den Client gesendet werden, sobald sich der:die Benutzer:in erfolgreich authentifiziert hat. Dann könntest du FS.identify in JavaScript so aufrufen:

FS.identify(email_hmac);

Warum sollte ich keine erratbare UID verwenden? Da FS.identify() in erster Linie von beliebigen Personen auf der Website oder App aufgerufen werden kann, indem einfach JavaScript im eigenen Browser ausgeführt wird. Es ist sehr einfach, eine Session so zu fälschen, dass sie aussieht, als wäre sie von einer anderen Person. Die Verwendung einer nicht erratbaren UID macht dies viel schwieriger, da der:die Angreifer:in diese private UID stattdessen kennen müsste, um den:die Benutzer:in imitieren zu können (z. B. so etwas wie „23sdfsdf3f255“ im Gegensatz zu „yourname@fullstory.com“). Ein solcher Angriff würde wiederum die Ergebnisse verfälschen, die du in Fullstory siehst, da es jetzt Sessions geben könnte, die einem:einer bestimmten Benutzer:in zugeordnet sind, die wirklich nicht von ihm:ihr stammen. Wenn die UID erraten werden kann, könnte sie außerdem verwendet werden, um über unsere Server herauszufinden, ob ein:e Benutzer:in ein Konto auf deiner Website oder App hat, wo eine Zustimmung vorliegt.

Angabe des Anzeigenamens und der E-Mail-Adresse

FS.identify akzeptiert auch ein optionales zweites Argument: ein JSON-Objekt, das einfache Schlüssel-/Wert-Paare enthält, die du für den:die aktuelle:n Benutzer:in erfassen möchtest.

FS.identify(uid, userVars); // userVars ist ein JSON-Wörterbuch.

Im Gegensatz zur UID kannst du dich dafür entscheiden, persönlich identifizierbare Benutzerinformationen in die userVars aufzunehmen.

Fullstory hat spezielle Systemfelder für displayName und email.  Du kannst Werte für diese Felder wie folgt angeben:

FS.identify('462718483', {
 displayName: 'Daniel Falko',
 email: 'daniel.falko@example.com'
});

Anzeigenamen und E-Mail-Adressen werden automatisch angezeigt, wenn du das nächste Mal deine Benutzerliste in Fullstory durchsuchst.

Du musst nicht wie im obigen Beispiel sowohl den Anzeigenamen als auch die E-Mail-Adresse angeben; eine Option ist ausreichend. Wenn du jedoch eine email-Variable, aber keine displayName-Variable übergibst, zeigen wir die E-Mail-Adresse als Anzeigenamen der Benutzerkarte des:der Kund:in an.

userVars kann andere Felder als displayName und email angeben. Tatsächlich kannst du beliebige benutzerdefinierte Felder erfassen, solange du die Benennungsregeln befolgst.Weitere Informationen zu benutzerdefinierten Feldern findest du unter FS.setUserVars.

Das Argument userVars für FS.identify hat das gleiche Format, das von FS.setUserVars erwartet wird. Es ist bequemer, FS.identify(uid, userVars) anstelle von FS.identify(uid) direkt gefolgt von FS.setUserVars(userVars)zu schreiben. Die beiden Formulierungen sind jedoch gleichwertig.

Spezifische Hinweise

Wir haben festgestellt, dass es eine Handvoll UIDs gibt, die leicht missbraucht werden können. Normalerweise versucht dabei eine Person, eine UID anzuwenden, obwohl diese Person nicht wirklich weiß, wer ein:e bestimmte:r Benutzer:in ist.  Infolgedessen ignoriert Fullstory einige spezielle Werte als ungültig, einschließlich: 0, 1, -1, „nan“, „n/a“, „undefined“, „null“ und „nil“, zusammen mit allen UIDs, die mit einem doppelten Unterstrich beginnen („__“). Du solltest diese Werte nicht als UIDs für bestimmte Benutzer:innen verwenden, da wir sie automatisch ignorieren. Versuche stattdessen, ein anderes Schema zu finden, oder verhindere, dass diese Kennungen angewendet werden.

Sobald ein:e Benutzer:in mit einer UID identifiziert wurde, kannst du diese Zuordnung nicht mehr ändern. Beispielsweise darf Benutzer:in 5673 nicht auch Benutzer:in 9816 sein. Es ist völlig in Ordnung, dass der:die Benutzer:in mit UID 5673 email: 'bob@bobsworld.org' als Teil der userVars hat, weil es sich um die E-Mail-Adresse handelt, nicht um die eindeutige UID.

Anonymisieren von Benutzer:innen

Wenn du eine:n zuvor identifizierte:n Benutzer:in anonymisieren möchtest (z. B. beim Abmelden), kannst du FS.anonymize() aufrufen. Dadurch wird die Session automatisch geteilt und die neue Session einem:einer neuen anonymen Benutzer:in zugeordnet.

Es ist wichtig zu beachten: 

Ab April 2020 wurde dieser API-Aufruf als Ersatz für FS.identify(false) erstellt. Wenn du eine ältere Version deines Datenerfassungs-Snippets verwendest, musst du es aktualisieren, um FS.anonymize() zu verwenden. Die neueste Version deines Datenerfassungs-Snippets findest du unter „Einstellungen“ > „Fullstory-Konfiguration“.

Wenn du in der Vergangenheit FS.identify(false) verwendet hast, funktioniert es weiterhin.

Benutzer:in imitieren

Wenn du dich als Benutzer:in ausgibst (z. B. wenn das Verwaltungssystem deiner App die Anmeldung eines Support-Mitglieds als Benutzer:in zulässt), empfehlen wir dir, die an FS.identify() übergebenen eindeutigen IDs zu differenzieren, um imitierte Benutzer:innen von „echten“ Benutzer:innen zu unterscheiden. 

Wenn du normalerweise einen serverseitigen HMAC wie folgt generierst:

email_hmac = HMAC(secret, 'name@customer.com');

würdest du ihn stattdessen so generieren:

email_hmac = HMAC(secret, 'support@app.com::name@customer.com');

Du kannst auch die displayName-Variable differenzieren, um sie klarer wiederzugeben. Wir verwenden Folgendes, um dies in der Benutzeroberfläche schöner aussehen zu lassen:

{displayName:'someone@fullstory.com as name@customer.com'}