Voice-as-UI: Wo wir stehen und was wir wissen

„Längerfristig gedacht sollten sich Webmaster Gedanken machen,
wie sie mit ihrer Website erfolgreich sein können, wenn
der Nutzer nicht mehr am Bildschirm hängt.“

John Mueller im Interview mit onlinemarketing.de

Das sehen wir genauso, daher beschäftigen wir uns seit Mitte 2017 mit dem Thema Voice-as-UI. Wenn der Bildschirm wegfällt, wie ändert sich dann das Nutzerverhalten und wie sollten wir den Zugang zu Informationen und zum „Online-Shopping“ in Zukunft gestalten? Nicht nur aus SEO-Sicht, sondern in erster Linie aus Nutzer-Sicht stellen wir die Frage, wie sich die heutigen Konsumenten mit Google Assistent, Alexa oder Siri beschäftigen und fragen uns, wie wird sich das Verhalten verändern? Wie weit muss man als Webseiten- oder Shop-Betreiber gehen, um den impliziten hohen Erwartungen der Endnutzer gerecht zu werden?

Aus diesem Grund haben wir uns einmal eine Customer-Journey angeschaut, die nicht am Browser startet, sondern im Google Assistent auf dem Smartphone. Im Grunde ist die Kundenreise bei der Nutzung des Google Home oder einer Amazon Alexa vergleichbar.

Der Nutzer startet im Voice- oder Sprachkontext, er fragt „OK Google, frag den Zalando Geschenkefinder nach einem Geschenk für meine Mutter“. Google erkennt, das der Zalando-Skill angefordert wird und aktiviert diesen. Von jetzt an übernimmt der Zalando-Skill die Antworten auf Spracheingaben, fragt ein paar Mal nach und zeigt nach einer quasi Guided-Selling Methode ein Ergebnis im Sinne von einer Produktkachel.

Und jetzt kommt der Moment der Enttäuschung:

Der Nutzer muss das Smartphone in die Hand nehmen und aktiv auf die Kachel klicken, wenn er den Artikel bestellen möchte. Als Resultat landet er dann im Zalando-Shop. Hier geht die Reise jetzt leider nur noch per Touch und Klick weiter – also mit einer physischen Interaktion mit dem Smartphone-Bildschirm. Der Nutzer kann sich weitere Bilder des Produktes anschauen oder dieses per Klick in den Warenkorb legen – alles nichts Neues und aus Nutzersicht so gar nicht cool oder besonders. Denn die eigentlich im Sprachkontext gestartete Customer Journey ist jetzt auf einmal so gar nicht mehr sprachlich. Mit dem Zalando-Shop kann man nicht reden, er nimmt keine Fragen entgegen und kann schon gar nicht auf Spracheingaben reagieren.

Warum eigentlich nicht?

Dieser Frage sind wir nachgegangen, denn eigentlich wollen wir eine „seamless“ Customer Journey. Amazons Alexa macht das schon ganz gut, nur leider ist hier der Schwerpunkt reichlich produktfokussiert. Und das auch noch limitiert auf immer nur ein Produkt in der Erst-Empfehlung. Man kann zwar per Sprache bestellen, ja, das ist toll, nur ist auch bei einer Alexa die visuelle Darstellung recht begrenzt. Also war unsere Überlegung, was müsste eigentlich passieren, wenn wir in einem Sprachkontext die Customer-Journey starten, und dann, aufgrund der Google- oder Amazon-Logik, in einem Webshop landen? Die Antwort liegt auf der Hand – der Shop muss in die Lage versetzt werden, Sprachbefehle anzunehmen, intuitiv zu navigieren und per Sprache zu beraten. Somit haben wir uns an die Arbeit gemacht und verschiedene Möglichkeiten evaluiert. Dabei fiel auf, der der Google Browser „Chrome“ von Haus aus Spracherkennung unterstützt. Das bedeutet, man kann mit überschaubarem Aufwand ein Javascript erstellen, welches Spracheingaben des Nutzers erkennt und durch die nativ verbaute Schnittstelle zu den Google-Diensten diese in Text umwandelt und zurückliefert.

Weg 1 – Nutzung der nativen Spracherkennung als Google Chrome Add-On

Wir haben also ein Add-On für den Google-Chrome geschrieben, welches dem Nutzer ein Sprachinterface zur Verfügung stellt. Der Plan: besucht jemand jetzt die Webseite per Google Chrome und hat das Plugin installiert, kann er per Sprache weitersurfen. Vorteile für die Shop-Betreiber – sie können ein gebrandetes Plugin publizieren. Doch die Nachteile wurden schnell sichtbar. Im ersten Schritt versuchten wir, über Keyword-Regeln zu erkennen, welchen Sprachbefehl der Nutzer eingegeben hatte. Nach einigen Testrunden wurde schnell klar, dass jeder Nutzer anders in sein Gerät spricht. Eine keywordbasierte Erkennung wurde unglaublich schnell komplex und nicht mehr sinnvoll bearbeitbar. Daher entschieden wir uns, das bereits vorhandene Wissen aus dem Kontext der Chatbots zu nutzen, und Dialogflow als NLP-Engine (natural language processing) anzubinden. Die NLP wurde mit den wesentlichen Intents erstellt und antrainiert. Im Plugin wurde jetzt alles, was von der nativen Google-API von Sprache in Text umgewandelt wurde, an die Dialogflow API gegeben, um den Intent zu ermitteln. Somit mussten wir keine Keyword-Analyse machen, sondern haben die Intent-Erkennung (die im Wesentlichen die Sprachbefehle an den Browser darstellen) an Google ausgelagert. Unser Plugin war damit als BETA „ready to launch“. Am Desktop PC funktionierte alles überwiegend reibungslos, jetzt galt es, den Test am mobilen Endgerät erfolgreich zu absolvieren.

Ausgehend von unserem ersten Use-Case, Nutzer spricht mit seinem Smartphone und dem Google Assistenten, mussten wir jedoch feststellen, dass der mobile Chrome Browser das Installieren von Add-Ons oder Plugins nicht zulässt. Damit ist dieser Weg der Umsetzung quasi nur den Desktop-Nutzern vorbehalten, was zu Teilen sehr spannend ist, uns jedoch nicht wirklich zum Ziel bringt.

Da ein Chrome Plugin überwiegend in Javascript geschrieben wird, lag der Gedanke nahe, das bereits bestehende Konstrukt aus Sprach- und Intenterkennung in Form einer Javascript-Bibliothek direkt in den Quellcode eines Webshops zu implementieren. Damit umgehen wir die Plugin-Problematik des mobilen Chrome, müssen jedoch nicht bei Null beginnen.

Weg 2 – native Spracherkennung und Javascript-Integration

Wir haben also den Code des Plugins genutzt, und daraus das Javascript extrahiert. Dieses kann dann problemlos in den Quellcode einer Webseite oder eines Shops integriert werden und stellt über diesen Weg die Sprach- und Intenterkennung sicher.

Erkenntnis 1: Ohne SSL geht gar nichts. Das hatten wir bei der Plugin-Erstellung vollkommen ignoriert, denn dem Plugin ist es im Grunde egal, ob der User auf einer verschlüsselten Seite unterwegs ist, oder nicht. Dem Javascript und den angeschlossenen Google APIs ist das allerdings nicht egal. Wir haben unsere Bibliothek angepasst und dann in ein Test-Shop-System integriert (welches auch auf einer SSL-verschlüsselten Domain arbeitet) und begannen, es zu testen. Dabei sind wir auf weitere interessante Erkenntnisse und leider auch Hindernisse gestoßen.

Erkenntnis 2: Die Informationsdichte auf aktuellen Shops ist für Voice vollkommen untauglich. Das hat auf der einen Seite technische Hintergründe, auf der anderen nutzerbezogene. Bei einer Aufforderung wie etwa „Was kann das Produkt“ oder „Lies´ mir die Beschreibung vor“ wird der entsprechende Produkt-Text vorgelesen. Das mag sich nett anhören, jedoch hat die Praxisverprobung gezeigt, dass Texte und Beschreibungen, die länger als 3 Sätze sind, einfach nicht mehr wahrgenommen werden und eher nervig sind. Die technischen Hürden in Verbindung mit bestehenden Inhalten sind darin begründet, dass auch der Chrome Browser entweder „reden“ oder „zuhören“ kann. Sprich, wenn man etwas Vorlesen lässt, dann wird das Mikrofon deaktiviert. Das muss nach dem Vorlesen wieder aktiviert werden. Der Nutzer hat jedoch zwischendrin keine Chance, per Sprachbefehl das Vorlesen abzubrechen. Daher müssen vorlesbare Texte für Produktmerkale und Beschreibungen wahrscheinlich zusätzlich geschaffen und bereitgestellt werden. Der Anspruch an diese Art der Inhalte ist hoch, denn fachliche und wichtige Informationen müssen auf die Besonderheiten des akustischen Kanals zugeschnitten sein. Einfach ein Kürzen bestehender Texte wird da eher nicht die Lösung sein.

Erkenntnis 3: Am PC hat sich eine Art „hybrider Arbeitsmodus“ als wirklich spaßbringend und sinnvoll herausgestellt. Wir haben in verschiedenen Fällen also Sprache und Maus-Interaktion kombiniert genutzt. Zum Beispiel können wir im ersten Schritt des Checkouts sagen „Mein Name ist Alexander Käppler, ich wohne in…“ oder „Meine Telefonnummer ist die…“. Diese Informationen wurden von der NLP-Engine im Hintergrund erkannt und in die Felder des Shops eingetragen. Gleichzeitig konnten wir aber mit der Maus scrollen, die AGB checken oder ein Passwort vergeben. Das Nutzererlebnis war erstaunlich gut, weil wir zum Beispiel nicht unsere kompletten Adress- und Namensdaten eintippen mussten. Vergleichsweise gute Erfahrungen haben wir auf Produktdetailseiten gemacht, wenn der Content bereits optimiert war. „Was sind die Besonderheiten von dem Produkt“ liest die Besonderheiten vor, während wir gleichzeitig mit der Maus scrollen konnten oder uns weitere Bilder angeschaut haben.

Doch der Spaßfaktor konnte nicht über die Hindernisse hinwegtäuschen, die sich leider bei der mobilen Nutzung als gravierend herausstellten.

Hindernis 1: Der Browser auf dem mobilen Endgerät ist wesentlich sensibler mit der Erfassung der Sprache. In den PC konnten wir ganze Sätze problemlos einsprechen – das Smartphone hat das Mikrofon quasi nach dem ersten Wort wieder geschlossen. Eine Anpassung des Javascripts hat diese Hürde zwar aus dem Weg geräumt, jedoch blieb eine Nutzung auf Grund der doch sehr sensiblen Mikrofone in etwas geräuschintensiven Umgebungen schwierig. Nicht, weil das Gerät zu viel erkannt hat, sondern weil die Hintergrundgeräusche dazu führten, dass nicht zuverlässig erkannt wurde, wann der User aufhörte zu sprechen. Das Gerät hörte einfach weiter zu, erkannte zwar keine weiteren Eingaben, dennoch bewirkte die Geräuschkulisse, dass die Spracherkennung nicht abgeschlossen wurde.

Hindernis 2: Eigentlich wollen wir ja nicht so ein kleines Mini-Bild eines Produktes auf dem, Smartphone-Screen sehen (responsiv optimiert hin oder her). Besser wäre aus unserer Sicht, wenn wir im Prinzip dem Browser den Befehl geben könnten „Zeig mir das doch mal auf meinem Fernseher“. Folglich haben wir versucht, den Chrome Browser per Chromecast auf einen Bildschirm zu projizieren. Das klappt leider nicht wie bei Youtube, wo man einfach auf den Button klickt, und schon erscheint das Streaming im Chromcast-angeschlossenen TV. Nur über einige Umwege (was mit Sicherheit nicht nutzerfreundlich ist) gelang es, den kompletten Smartphone Screen, und damit den Webshop, auf den TV zu streamen. Gut, wir waren einen Schritt weiter. Kleine Randbemerkung an dieser Stelle: Die Landscape-Ansicht eignet sich um einiges besser zur Darstellung auf großen 16:9 Bildschirmen als die Portrait-Ansicht.

Weg 3 – zahlreiche Workarounds, jedoch noch kein zufriedenstellendes Ergebnis

Nachdem wir festgestellt hatten, dass der Screen-Lock des Smartphones den Bildschirm und damit auch das Mikrofon abschaltet, begann die Suche nach einer Lösung für das Problem. Wir haben uns verschiedene bereits vorhandene Lösungen und Workarounds angeschaut, die einen Screen-Lock verhindern. Es gibt da Entwicklungen wie NoSleep.js oder auch den react-wakelock, nur dummerweise ist eine Kerneigenschaft dieser Workarounds, dass sie jegliche HTTP-Requests abbrechen oder verhindern. Damit wäre gerade unsere Intent- und Spracherkennung per Google API nicht mehr möglich. Der Workaround „verhindere Screen-Lock“ fällt damit leider erst einmal aus. Ja, sicherlich wäre es möglich, das Smartphone so zu konfigurieren, dass der Screen immer aktiv bleibt (damit dann auch das Mikrofon), nur kann man das keinem User vorher einfach und sinnvoll klarmachen, warum das jetzt notwendig sei. Wer bitteschön re-konfiguriert denn sein Telefon, nur um eine bestimmte Webseite zu besuchen? Keiner.

Ein anderer Lichtblick scheint die Ankündigung von Wake-Lock als HTML5-API zu sein. Derzeit wird dieser Wake-Lock jedoch nicht wirklich von den mobil genutzten Browsern unterstützt, denn diese Integration muss wieder als Chrome App, also als Plugin, erfolgen – und wir haben ja schon gelernt, dass wir auf dem mobilen Chrome keine Plugins installieren können. Also erscheint auch das zum aktuellen Zeitpunkt als Sackgasse.

Weg 4 – native App oder Google Home

Um unserem Ziel, einer nahtlosen Voice-Customer-Journey, näher zu kommen, wird wohl kein Weg an einer App vorbeiführen. Diese App kann sich auf diverse Weise verhalten. Entweder, kein Screen-Lock oder wenn doch, dann eben keine Mikrofonsperre. Darüber hinaus könnte die App die Daten aus dem Shop nutzen, um Bilder und sonstige Inhalt bis hin zum Checkout-Prozess abbilden zu können. Alternativ sehen wir die Möglichkeit, rein eine Applikations-Logik zu erschaffen, welche von anderen Unternehmen und Softwareschmieden als SDK genutzt werden kann, um auf die Sprachsteuerung zugreifen zu können. Dummerweise würde eine Lösung im Sinne einer App wieder voraussetzen, dass der Besucher diese App bereits installiert hat. Und wenn man sich einmal anschaut, was dann am Ende des Tages in so einer App passieren würde, dann kann man sich auch gleich fragen, warum man nicht den kompletten Shopping-Prozess über eine bereits vorhandene Assistenten-Lösung wie Google Assistent oder Alexa in Form eines Skills realisiert.

Aktuell ist es zwar noch nicht möglich, den Bildschirm des Google-Assistenten auf einen Bildschirm zu streamen – aber wer weiß, womöglich kommt das schneller, als wir glauben. Und dann ist es in der Tat der späteste Zeitpunkt, seine Produktdaten und Inhalte so bereitzustellen, dass auch Nutzer ohne Bildschirm in der Lage sein müssen, im Unternehmens-Skill anstelle im Webshop zu navigieren, zu stöbern und zu shoppen.

Ob es dann noch einen Voice-gesteuerten mobilen Shop braucht? Wahrscheinlich nicht, denn das Surfen und letzten Endes auch Einkaufen wird per Sprache im Assistenten-Skill realisiert. Die Aufgabe wird daher in Zukunft sein, die Emotionen des Produktes durch die Sprache und geeignete weitere Medien zu transportieren – damit ein Sale auch ohne Screen möglich wird.

Unser Whitepaper zum Thema Voice-as-UI

Whitepaper "Voice-as-UI" anfordern


Vielen Dank für Ihr Interesse an unserem Whitepaper. Damit wir Ihnen das Dokument zusenden können, geben Sie bitte Ihren Namen und Ihre E-Mail-Adresse an.

Ihr Name

Ihre E-Mail-Adresse (Pflichtfeld)

Sie möchten mehr über Voice-as-UI erfahren? Kontaktieren Sie uns!

Alexander Käppler

senior digital consultant
+49 711 2992-0