Häufige Suchprobleme
Fast jede Suchbeschwerde kommt in einer von drei Formen an: es wird nicht gefunden, das falsche steht zuerst oder es ist langsam. Das hier ist die Diagnosereihenfolge für jede davon. Die meisten Ursachen sind Produktdaten, und jede Produktdaten-Prüfung unten läuft auf Feldern, die heute auf Ihrem Tenant existieren. Wo eine Abhilfe einen Bildschirm der Such-App braucht, sagt die Seite das.
Das Produkt existiert, wird aber nicht gefunden
Arbeiten Sie die Liste von oben ab. Halten Sie beim ersten „Nein“ an; das ist Ihre Ursache.
| Prüfung | Wo | Wenn nein |
|---|---|---|
| Ist das Produkt aktiviert? | PIM › Produkte, Filter Status (enabled) | Aktivieren |
| Ist es dem Kanal des Käufers zugeordnet? | Configuration › Kanäle: die Einstellung für nicht zugeordnete Produkte, dann die Zuordnung des Produkts | Warum ein Produkt nicht angezeigt wird |
| Ist der Käufer auf dem Kanal, den Sie meinen? | Ein Punchout-Käufer durchsucht den Punchout-Kanal, nicht den Webshop | Die Prüfungen für diesen Kanal wiederholen |
| Steht das gesuchte Wort in einem indexierten Feld? | sku, name, description, manufacturer, ean, Kategoriecodes und -bezeichnungen | In name oder description aufnehmen |
| Steht der Wert nur in einem technischen Attribut? | Attributwerte reisen mit dem Produkt, werden aber heute nicht als Text indexiert | Gleiche Abhilfe; durchsuchbare Attribute sind geplant |
| Ist der lokalisierte Name gefüllt? | Der name des Produkts in der Locale des Käufers | Übersetzungslücke |
| Hat der Index nachgezogen? | Minuten nach einer Massenänderung | Unten |
Die zwei, die Leute am häufigsten erwischen, sind der Kanal und die Locale. Ein Käufer in einem geschlossenen Punchout-Kanal und ein Käufer auf der englischen Storefront durchsuchen je eine andere Scheibe des Index als die, auf die Sie gerade schauen, denn der Index ist je Kanal und Locale geschnitten.
Die Products-App definiert diesen Index. Sie liest sku, name,
description, manufacturer, ean sowie die Kategoriecodes und
-bezeichnungen als durchsuchbaren Text und trägt kind, enabled,
manufacturer und categories als Facetten. Andere Attributwerte werden mit
dem Produkt für Anzeige und Filter gespeichert, aber nicht als Text
durchsucht — thread_size = M8 wird durch die Eingabe M8 also nicht
gefunden, außer M8 steht auch im Namen oder in der Beschreibung. Die
geplante Indexkonfiguration der Such-App ist der Ort, an dem Attribute
durchsuchbar und gewichtet werden;
Den Index konfigurieren
beschreibt, wie das funktionieren soll. Die Katalogseite desselben Problems
ist Produkt nicht durchsuchbar.
Index-Verzögerung nach einem Import
Der Index leitet sich aus dem Katalog ab und wird nach Änderungen aktualisiert; er wird nicht live gelesen. Im Normalbetrieb sind das Sekunden, und niemand merkt es. Nach einem Massenimport ist es anders: Zehntausende Produktänderungen landen auf einmal und werden der Reihe nach angewandt.
| Beobachtung | Bedeutung |
|---|---|
| Neue Produkte erscheinen über mehrere Minuten | Normal. Der Rückstau läuft ab. |
| Manche erscheinen, manche nicht, eine Stunde später | Nicht normal. Diese Zeilen wurden entweder nicht importiert oder haben den Index nicht erreicht. |
| Gar nichts hat sich geändert | Der Import hat nicht geschrieben, oder er schrieb in einen anderen Kanal oder eine andere Locale als die, die Sie durchsuchen |
| Zähler in der Suche niedriger als im Cockpit | Erwartbar, solange der Rückstau abläuft; danach falsch |
Fehlen nach einer Stunde noch Zeilen, lesen Sie zuerst das Importergebnis, unter Integration Studio › Data Exchange › Import & Export. Zeilen, die der Import abgelehnt hat, erreichen den Index nie, und ein einziger fehlerhafter Wert in einer Zeile ist die übliche ganze Erklärung für „der Import hat nicht funktioniert“. Zeigt der Import die Zeilen als geschrieben und die Suche findet sie trotzdem nicht, eröffnen Sie einen Support-Fall mit drei Beispiel-SKUs. Die für die Such-App geplanten Ansichten für Indexstatus und fehlgeschlagene Updates sollen das ohne einen solchen Fall sichtbar machen.
Das falsche Produkt steht zuerst
| Symptom | Übliche Ursache | Abhilfe |
|---|---|---|
| Eine exakte Artikelnummer liefert zuerst etwas anderes | Ein Boost oder Pin überholt die Identität, oder description überwiegt sku | Boost entfernen; die Identitätsregel in Merchandising |
| Eine Beinahe-Artikelnummer trifft | Tippfehlertoleranz auf Identifikationsfeldern | Geplant: für sku und ean in der Indexkonfiguration abschalten |
| Ein Long-Tail-Artikel schlägt den offensichtlichen | description zu hoch gewichtet | Geplant: senken. Heute: die unterscheidenden Wörter in den name |
| Fünfzig Längen derselben Schraube füllen Seite eins | Nichts gruppiert die Familie, keine Standardvariante geboostet | Geplant: nach Familie gruppieren, die Standardgröße boosten |
| Ein abgekündigter Artikel rankt zuerst | Sein Name trifft am besten, und er ist noch aktiviert | Deaktivieren. Das funktioniert heute |
| Ergebnisse stimmen auf Deutsch, nicht auf Englisch | Englischer name und description sind leer oder tragen noch den deutschen Text | Übersetzungsqualität |
Facettenzähler, die nicht aufgehen
Die Facetten des Produktindex sind heute kind, enabled, manufacturer
und categories; Attributfacetten kommen mit den
filterbaren Attributen. Drei Verhalten
sehen wie Fehler aus und sind keine:
- Das Cockpit sagt 412 Produkte, die Facette sagt 380. Die Facette zählt, was der Käufer sehen darf: die Scheibe seines Kanals, deaktivierte Produkte herausgefiltert.
- Eine Option zu wählen senkt die Zähler in derselben Facette nicht. In einem Standard-Facettenpanel verbinden sich Optionen innerhalb einer Facette mit ODER, die übrigen Optionen bleiben also zählbar. Die Zähler der anderen Facetten sinken sehr wohl.
- Eine Facette zeigt eine Option mit Zähler null. Das Attribut hat eine
Option (
attribute_options), die kein Produkt dieser Treffermenge trägt. Entweder ist die Option ungenutzt und sollte weg, oder die Facette erscheint in einer Kategorie, in die sie nicht gehört; siehe Facetten und Filter.
Eines ist ein Fehler: Zähler, die sich zwischen zwei identischen Anfragen ändern. Das zeigt auf einen Index mitten im Neuaufbau oder auf Knoten mit verschiedenen Daten. Notieren Sie die beiden Anfragen und die Uhrzeit, und melden Sie es. Tunen Sie nichts, bis es erklärt ist.
Die Suche ist langsam
Die Maschine antwortet deutlich unter 100 Millisekunden; dafür ist sie gebaut. Wenn eine Ergebnisseite das nicht tut:
| Ursache | Anzeichen | Was tun |
|---|---|---|
| Die Storefront löst Preise oder Bestand je Ergebniszeile auf | Langsame Ergebnisseite, schnelle Autovervollständigung | Die Storefront reparieren. Mit Abstand die häufigste Ursache |
| Die Seite fragt jede Facette an | Nur Listenseiten sind langsam | Nur die Facetten anfragen, die die Seite rendert |
| Breite Anfragen liefern die ganze Treffermenge | Langsam bei schraube, schnell bei 4711-A | Paginieren |
| Die Autovervollständigung fragt jedes Feld | Nur das Dropdown ist langsam | Nur Identifikatoren und name; siehe Autovervollständigung |
| Der Index wird gerade neu gebaut | Langsam für eine begrenzte Zeit nach einer großen Änderung | Warten; große Importe außerhalb der Geschäftszeiten planen |
Feldgewichtung und die Zahl durchsuchbarer Felder wirken ebenfalls auf die Geschwindigkeit, und beides gehört zur geplanten Indexkonfiguration. Bis sie ausgeliefert ist, liegt die Feldliste bei der Products-App fest — handeln können Sie also bei den Storefront-Ursachen oben.
Weiter
- Suchanalyse
- Warum ein Produkt nicht angezeigt wird: die Katalogseite von „es wird nicht gefunden“.