Unser Weg mit Sitecore Search

Sitecore Search zielt darauf ab, relevanten und personalisierten Content zur richtigen Zeit für die richtige Zielgruppe bereitzustellen. Es handelt sich um eine vollständig SaaS-basierte Lösung, die die folgenden Komponenten umfasst:

• Customer Engagement Console (CEC) – Ihre zentrale Anlaufstelle für Suchanalysen, Tests, Konfiguration und mehr.
• Such- und Empfehlungsservice – Eine KI-basierte REST-API zur Durchführung von Suchanfragen und Ergebnisausspielung.
• Eventservice – Eine REST-API zur Erfassung von Besucherinteraktionen, die für die Optimierung des Sucherlebnisses entscheidend sind.

Das Engineering-Team hinter Sitecore Discover erhielt die Chance, etwas völlig Neues auf der neuesten Technologie aufzubauen – und seine jahrzehntelange Erfahrung mit E‑Commerce-Suche, Merchandising und Empfehlungen zu nutzen.

Das Ergebnis war Sitecore Search, das eine leistungsstarke Content-Suchmaschine mit E‑Commerce-basierten Konzepten verbindet, um eine branchenweit einzigartige Lösung zu entwickeln. Sie können sich Sitecore Search als „Discover 2.0“ für Content vorstellen.

Sitecore.com ist in erster Linie eine Content-basierte Website, auf der sich Besucher:innen über unsere Angebote informieren und sich letztendlich mit uns in Verbindung setzen. Sitecore Search war daher die ideale Lösung, da es keine B2C‑Commerce-Website benötigt, um personalisierte Ergebnisse zu liefern. Und im Gegensatz zu anderen Content-Suchlösungen passt sich Sitecore Search an die Aktivitäten der Besucher:innen an, um diese personalisierten Ergebnisse und Empfehlungen in Echtzeit bereitzustellen.

Nach der Abstimmung zwischen unserem Anwendungsfall und dem, was Sitecore Search zu bieten hat, machten wir uns daran, das Sucherlebnis auf Sitecore.com zu überarbeiten. Das Projekt begann mit Recherche und Planung, bevor wir uns an die Umsetzung machten. Der stufenweise Ansatz half uns, das Wissen des Teams schrittweise zu erweitern und die Lösung nach und nach zu erlernen.

Konfigurieren des Crawlers

Unsere Reise begann mit der Konfiguration des Sitecore Search Crawlers. Zu den wichtigsten Überlegungen zum Thema Crawling gehören:

• Firewall
  Sitecore.com ist durch eine Web Application/App Firewall (WAF) geschützt, die Bot-Schutzmaßnahmen umfasst. Damit der Crawler auf unsere Website zugreifen konnte, waren einige Anpassungen an der WAF erforderlich.
• Crawlgeschwindigkeit/Last
  Wir haben sorgfältig geprüft, wie schnell der Crawler die Website besucht. Indem wir unsere Testumgebung mit einer sehr hohen Geschwindigkeit crawlen ließen, bekamen wir einen Anhaltspunkt dafür, wie lange ein vollständiger Crawl dauert.
• Crawl-Taktik & Häufigkeit
  Nachdem wir viele Optionen in Erwägung gezogen hatten, haben wir den Crawler so konfiguriert, dass er unsere XML-Sitemaps nachts durchsucht, im Gegensatz zum Crawlen einer API oder einem Push-Ansatz in Echtzeit.
• Mehrsprachigkeit
  Sitecore.com unterstützt acht Sprachen und es war wichtig für uns, dass wir in der Lage sind, die gleiche großartige Sucherfahrung über alle Regionen hinweg zu bieten.
• Multi-Site/Quellen
  Es war wichtig, dass wir nicht nur Sitecore.com indexieren, sondern auch die benachbarten Websites. Zusätzliche Crawling-Quellen wurden für Symposium-, Dokumentations- und Entwicklerseiten eingerichtet.
• Facettieren
  Sitecore Search ist zwar in der Lage, Facetten allein auf der Grundlage der URL-Struktur zu erstellen, aber wir entschieden uns für einen präziseren Ansatz. Wir wollten die Taxonomie dem Crawler zugänglich machen, indem wir sie in Metatags auf jeder Seite der Website einbetteten.

Entwicklungsplanung

Jetzt war es an der Zeit, mit der Planung für die Entwicklung zu beginnen. Sitecore Search hat keine Meinung dazu, wie Sie Dinge gestalten, wie Sie entwickeln oder welche Technologien Sie verwenden. Damit war die Planungsphase ein Kinderspiel.

Wir begannen mit einer Untersuchung der APIs mit Postman, das Beispiele für die Antworten und Datenstrukturen lieferte, mit denen wir arbeiten würden. ReactJS mit Axios wurde als Frontend-Framework ausgewählt, mit dem wir entwickeln wollten. Damit waren die Voraussetzungen für die Definition der Anforderungen und Aufgaben geschaffen.

Es ist Zeit, etwas zu erschaffen!

Unsere Entwicklungsarbeiten wurden im Laufe eines Monats hauptsächlich von unserem Senior Frontend-Entwickler durchgeführt. Um die Konsistenz der Taxonomie auf der gesamten Webseite zu gewährleisten, wurde zusätzliche Zeit für die Erstellung von Wireframes sowie für einige Anpassungen an unseren Meta-Tags aufgewendet. Insgesamt verlief die Erstentwicklung sehr reibungslos und viel einfacher als bei unserer bisherigen Lösung. Die Arbeit mit einer einfachen Auswahl von REST-APIs machte dies möglich.

Die wichtigsten KPIs, die wir im Auge behalten, sind die allgemeinen Klickraten (CTR) und die Suchkonversionen (CVR) für einige unserer wichtigsten Suchbegriffe. Auf Sitecore.com haben wir eine Suchkonversion als alle Formularabschlüsse definiert, denen eine Suche vorausgegangen ist.

Einen Monat nach dem Go-Live sehen wir einige sehr ermutigende Ergebnisse:

Neue Funktionen sind in Arbeit, von denen wir glauben, dass sie für Content-reiche Websites absolut wegweisend sein werden. Auf unserer Roadmap steht ein Empfehlungs-Widget, das wir auf der gesamten Website einbinden wollen. Diese Widgets kennen nicht nur den Kontext der Seite, in die sie eingebettet sind, sondern sie verstehen auch die Vorlieben der Besucher:innen für Content auf der Grundlage des Browserverlaufs. basierend auf der Browser-Historie. Sie können völlig frei eingerichtet und gewartet werden oder mit kontextabhängigen Regeln präzise gesteuert werden.

Die Erstellung von personalisierten Content-Empfehlungen mit einem solchen Maß an Flexibilität ist keine triviale Aufgabe, selbst für sehr erfahrene Entwicklungsteams. Wenn die Empfehlungen jedoch in einer API-gesteuerten SaaS-Lösung bereitgestellt werden, verkürzt sich die Entwicklungszeit drastisch, während sich Content Marketer auf die Produktion von Content und die Abstimmung der Empfehlungen nach ihren Wünschen konzentrieren können.