Recherche intelligente sur Typesense : 50 fois plus rapide que WooCommerce intégré

La semaine dernière, le propriétaire d'un magasin de pièces automobiles en ligne m'a écrit. Il a 14 000 positions dans le catalogue, WooCommerce, un hébergement pour trois mille roubles par mois, et une recherche très spécifique. La personne dit : "Le client saisit le numéro de pièce, appuie sur Entrée, attend six secondes, obtient un résultat vide et s'adresse à un concurrent. Je perds de l'argent chaque jour et je ne sais pas quoi faire." J'ai demandé ce qu'il avait déjà essayé. Il s'est avéré que j'avais installé trois plugins de recherche différents, dont un payant 79 $ par an, et aucun d'entre eux n'a vraiment résolu le problème. La recherche était encore lente, elle ne pardonnait pas les fautes de frappe et je ne comprenais pas du tout la morphologie russe. Le mot « roulement » a été trouvé, mais « roulements » n'a plus été trouvé.

Cette histoire ne fait pas exception. J'entends cela presque chaque semaine de la part de différentes personnes, dans différents magasins, mais avec le même problème. Et tu sais ce qui m'étonne le plus ? Ce n’est pas que la recherche intégrée de WordPress soit mauvaise, c’est connu depuis longtemps. Et le fait qu'un grand nombre de propriétaires de magasins ne soupçonnent même pas à quel point la situation est grave et combien d'argent ils en perdent chaque mois. Ils attribuent le faible taux de conversion à la concurrence, à la saisonnalité, à la publicité - à tout autre chose qu'à ce petit champ de recherche dans l'en-tête du site, par lequel passent 30 à 60 % de tous les acheteurs.

Voyons pourquoi cela se produit, ce que vous pouvez faire à ce sujet et pourquoi nous avons fini par créer notre propre module de recherche Typesense directement dans notre plugin COS WP Woo. Je vais vous le dire sans fioriture - avec des chiffres réels, avec le rake sur lequel nous avons marché et avec les résultats que nous avons obtenus dans un magasin de combat avec près de dix-sept mille produits.

Pourquoi la recherche WordPress intégrée est une condamnation à mort pour une boutique en ligne

Pour comprendre l'ampleur du problème, nous devons prendre une seconde pour regarder sous le capot. Lorsqu'un client tape une requête dans la barre de recherche WordPress standard et appuie sur Entrée, ce qui suit se produit : WordPress prend cette requête et génère une requête SQL sur la base de données MySQL. De plus, il le fait de la manière la plus primitive possible - via l'opérateur LIKE avec des pourcentages des deux côtés. Traduit en langage humain, cela ressemble à ceci : "Chère base de données, veuillez parcourir chaque ligne de la table wp_posts et vérifier si le champ post_title ou post_content contient cette séquence de caractères quelque part en lui-même." Pas d'index, pas d'optimisation, rien - juste une recherche complète, ligne par ligne.

Sur un blog contenant cinquante articles, cela fonctionne très bien. Dans un magasin aux mille produits, c’est tolérable. Mais lorsque vous avez dix, quinze, vingt mille positions et que chaque produit a des méta-champs, des attributs, des descriptions, des variations, cela se transforme en désastre. MySQL commence à s'étouffer. La requête, qui doit être exécutée instantanément, prend entre une heure et demie et trois secondes. Et si le serveur est chargé d’autres tâches à ce moment-là, c’est facile en cinq à six secondes.

Mais la lenteur n'est pas si grave. Le vrai problème est que cette recherche est stupide. Il ne comprend pas la morphologie - si un produit s'appelle « Huile moteur synthétique » et que l'acheteur recherche des « huiles moteur », une recherche standard ne le trouvera pas. Parce que « moteur » et « moteur » sont des chaînes différentes pour l'opérateur LIKE. Il ne pardonne pas les fautes de frappe - vous avez tapé « Shell Oil » au lieu de « Shell Oil », et c'est tout, aucun résultat. Il ne sait pas comment être pertinent : si trois cents produits correspondent à une requête, ils sont classés non pas par importance, mais par date de publication. Un câble industriel pour deux cents roubles sera plus cher qu'un générateur pour un million simplement parce qu'il a été ajouté au catalogue plus tard.

J'ai longtemps réfléchi pourquoi WordPress, après vingt ans d'existence, n'a pas acquis une recherche normale. Et je suis arrivé à la conclusion que le problème n'est pas la paresse des développeurs, mais l'architecture. WordPress a été conçu comme un moteur de blog, et la recherche sur un blog est une tâche complètement différente de la recherche dans un catalogue de produits. Pour un blog, recherchez simplement un article à l’aide de mots-clés. Pour un magasin, il faut rechercher un produit par article, par marque, par caractéristique, par synonyme, par partie du nom, en tenant compte des fautes de frappe - et cela en une fraction de seconde, avec aperçu et filtrage instantanés. WordPress n'est tout simplement pas créé pour cela, et aucun plugin qui tente de « terminer » le WP_Query standard ne résoudra fondamentalement ce problème. Vous ne pouvez pas réparer ce qui est brisé par conception.

Voici le problème : la plupart des "plugins de recherche" WooCommerce font exactement cela : essayer d'améliorer une requête standard. Ils ajoutent une recherche par champs méta, par SKU, et améliorent la pertinence grâce à des JOIN supplémentaires aux tables. Et cela donne un effet - de vingt, peut-être trente pour cent. Mais le problème fondamental demeure : la recherche passe toujours par MySQL, toujours par recherche exhaustive, toujours sans morphologie et sans traitement normal des fautes de frappe. C'est comme essayer de gagner une course de Formule 1 dans un Zhiguli simplement en le peignant en rouge et en y collant un spoiler.

Typesense - quand j'ai vu la différence pour la première fois

Nous ne sommes pas tombés sur Typesense tout de suite. Nous avons d'abord examiné Elasticsearch, une norme de recherche en texte intégral reconnue et utilisée par Amazon, eBay et la moitié des principaux sites de commerce électronique du monde. Techniquement, Elasticsearch est génial. Mais pour une petite et moyenne boutique en ligne, c'est comme acheter un camion-benne minier pour transporter des produits de Pyaterochka. Elasticsearch nécessite au moins deux Go de RAM pour fonctionner. En pratique, pour un travail confortable, vous avez besoin de quatre à huit gigaoctets. Il s'agit d'un serveur séparé ou d'un VPS puissant. Plus la pile Java, plus la configuration complexe, plus le besoin de surveillance et de maintenance. Pour un magasin proposant dix à quinze mille produits, c'est comme tirer des moineaux avec un canon, et le canon coûte également cher à entretenir.

Ensuite, un collègue a recommandé Typesense. Pour être honnête, j'étais sceptique : le projet open source n'est pas aussi connu qu'Elasticsearch ou Algolia. Mais j'ai décidé de l'essayer, et le premier test m'a littéralement bluffé. Nous avons chargé un index de quinze mille produits dans Typesense et la requête de recherche a commencé à s'exécuter en cinq à douze millisecondes. Pas des secondes – des millisecondes. À titre de comparaison, la même demande via une recherche WooCommerce standard sur le même catalogue a pris entre huit cents et mille cinq cents millisecondes. La différence n'est pas de plusieurs fois, mais de dizaines de fois.

Mais la vitesse n’est qu’un côté de la médaille. Typesense prêt à l'emploi peut faire quelque chose que MySQL ne pourra jamais faire : effectuer une recherche en tenant compte des fautes de frappe, ce qu'on appelle la tolérance aux fautes de frappe. L'acheteur tape « Castrol » au lieu de « Castrol » - et trouve toujours les huiles nécessaires. Écrit « huile hydraulique » - Typesense comprend qu'il s'agit d'une faute de frappe et donne les résultats corrects. Pour un magasin en langue russe, cela est d’une importance cruciale, car la disposition du clavier russe et les noms de marques latins sont une source inépuisable de fautes de frappe. Les gens changent de mise en page au mauvais moment, écrivent en translittération, confondent « i » et « th », « e » et « e » - et Typesense traite tout cela correctement.

Séparément, il convient de mentionner la morphologie. Pour la langue anglaise, ce n'est pas si critique - la morphologie y est relativement simple. Mais pour la langue russe, c’est une autre histoire. Dans notre pays, un nom peut avoir douze formes, et un verbe peut en avoir encore plus. "Huile", "huiles", "huile", "huile", "huile", "huiles" - tout cela est le même produit, et le moteur de recherche doit le comprendre. Typesense prend en charge la morphologie russe, et cela ne fonctionne pas parfaitement - il existe des cas extrêmes - mais c'est un ordre de grandeur meilleur que les stupides comparaisons de chaînes dans MySQL.

Typesense consomme également ridiculement peu de ressources par rapport à Elasticsearch. Pour un index de vingt mille produits, un à deux cents mégaoctets de RAM suffisent. Il est écrit en C++, s'exécute comme un seul binaire, ne nécessite pas Java et ne nécessite pas d'infrastructure complexe. Vous pouvez l’installer directement sur le même serveur sur lequel WordPress s’exécute, et il coexistera paisiblement, en consommant un minimum de ressources. Ou utilisez le Typesense Cloud basé sur le cloud - il existe un forfait gratuit pour les petits projets et des forfaits payants assez abordables.

Quand j'ai vu tout cela en action, c'est devenu évident : la recherche intégrée de WordPress doit être entièrement remplacée, et non « améliorée ». Et nous avons commencé à créer une intégration Typesense directement dans notre plugin afin qu'un propriétaire de magasin puisse obtenir une recherche de niveau Algolia, mais sans payer des centaines de dollars de frais mensuels et sans avoir à comprendre comment configurer les moteurs de recherche.

Comment nous l'avons construit - et sur quels types d'erreurs nous avons marché

L'idée semble simple : on prend les données de WooCommerce, on les charge dans Typesense, on affiche les résultats via un widget AJAX. Dans la pratique, bien sûr, tout s’est avéré plus compliqué. La première question qui s’est posée était de savoir quoi indexer exactement. Le nom du produit est évident. Description également. Et puis les nuances commencent. Le SKU (numéro d'article) est indispensable, car de nombreux acheteurs B2B effectuent une recherche spécifiquement par numéro d'article. Attributs du produit : oui, car une personne peut rechercher « huile 5W-30 » et s'attendre à ce que la recherche trouve des produits avec l'attribut de viscosité 5W-30. Prix : nécessaire au filtrage des facettes afin que vous puissiez filtrer les résultats par fourchette de prix. Les catégories concernent les mêmes facettes. Marque - la même. En stock - parce qu'il n'y a rien de pire que de trouver le produit parfait et de découvrir qu'il est en rupture de stock.

Nous sommes allés encore plus loin et avons ajouté une indexation basée sur le contenu pour les fichiers PDF joints aux produits. Cela semble exotique, mais pour les magasins industriels, où chaque produit est accompagné de documentation technique, de fiches de données de sécurité et de certificats, cela change les règles du jeu. Le responsable des achats peut saisir le numéro GOST ou le nom d'une approbation spécifique, et la recherche trouvera les produits dans la documentation desquels ce GOST est mentionné. Auparavant, cela nécessitait d'ouvrir chaque PDF manuellement.

La tâche suivante est la synchronisation. L’index Typesense doit être à jour. Lorsqu'un gestionnaire ajoute un nouveau produit, modifie le prix, met à jour la description, ces modifications doivent être reflétées dans la recherche. Nous avons implémenté cela via Action Scheduler, un planificateur de tâches WooCommerce intégré. Chaque fois qu'un produit est enregistré, un hook est déclenché qui met en file d'attente la tâche de mise à jour de l'index. SearchIndexerJob reprend cette tâche et met à jour le document correspondant dans Typesense. Cela se produit de manière asynchrone, en arrière-plan - le gestionnaire n'attend pas la mise à jour de l'index, il enregistre simplement le produit et continue.

Honnêtement, c'est avec la synchronisation que nous avons le plus souffert. La première version a mis à jour l'index de manière synchrone, directement dans le hook save_post - et lors de l'importation massive de marchandises depuis 1C, cela a tué le serveur. Imaginez : un paquet de trois cents produits arrive, et pour chacun il y a une requête HTTP vers Typesense. Trois cents requêtes par minute sont toujours tolérables, mais si l'importation se fait par morceaux et qu'il y a quinze mille produits, le serveur commence à s'étouffer. Nous sommes passés à la file d'attente via Action Scheduler - et le problème a disparu. Désormais, lors de l’importation groupée, les tâches de mise à jour de l’index sont mises en file d’attente et traitées par lots, sans charger ni WordPress ni Typesense.

Un autre problème non évident est l'indexation initiale. Lorsqu'un magasin connecte simplement le module de recherche, il doit indexer l'intégralité du catalogue. Pour un magasin proposant mille produits, cela prend une minute ou deux. Pour notre magasin de combat comptant 16 844 produits, l'indexation initiale a pris une vingtaine de minutes. Nous avons optimisé le processus en le divisant en lots de 250 produits, avec des pauses entre les lots pour ne pas surcharger le serveur. Une barre de progression est affichée dans le panneau d'administration - le propriétaire voit combien de pourcentages ont été indexés et peut facilement faire d'autres choses.

Il y avait aussi une histoire avec des encodages. Typesense fonctionne bien avec UTF-8, mais certaines boutiques WordPress proposent des produits avec des caractères délicats - espaces insécables, tirets spéciaux, symboles de marque. Un magasin de pétrole a conservé un « ™ » dans les noms de ses produits, et il a rompu la sérialisation JSON lorsqu'il a été envoyé à Typesense. J'ai dû ajouter une normalisation du texte avant l'indexation - supprimer les caractères de contrôle invisibles, remplacer les guillemets « intelligents » par des guillemets normaux et autres joies de travailler avec des données réelles.

Chapitre séparé - filtrage des facettes. Lorsqu’un client recherche « huile moteur », il obtient, disons, quatre cents résultats. Sans filtrage, cela ne sert à rien - personne ne feuilletera quatre cents cartes. Vous avez besoin de facettes : filtrer par marque (Shell, Castrol, Lukoil), par viscosité (5W-30, 10W-40), par type (synthétique, semi-synthétique), par prix (de 500 à 2000 roubles). Typesense prend en charge le filtrage à facettes de manière native : nous spécifions simplement quels champs sont à facettes et le moteur compte automatiquement le nombre de produits dans chaque catégorie. L'utilisateur voit non seulement une liste de filtres, mais aussi des filtres avec des quantités - « Shell (47) », « Castrol (32) » - et peut rapidement affiner les résultats aux produits souhaités.

Synonymes, curation et analytique - les trois piliers de la recherche intelligente

Il y a trois choses qui séparent une recherche véritablement intelligente d'une recherche simplement rapide. Le premier concerne les synonymes. Chaque niche a son propre jargon, ses propres abréviations, ses propres noms alternatifs. Dans le magasin d'huile, « transmission » = « huile pour engrenages » = « huile pour engrenages » = « huile pour engrenages ». Dans un magasin d'électronique, « mobile » = « smartphone » = « téléphone » = « portable ». Dans un magasin de matériaux de construction, « plaques de plâtre » = « plaques de plâtre » = « plâtre sec ». Si le moteur de recherche ne connaît pas ces synonymes, il perd des clients.

Nous avons rendu la gestion des synonymes aussi simple que possible. Dans le panneau d'administration de WordPress, dans la section de recherche, il y a un onglet « Synonymes ». Vous ajoutez un groupe de synonymes - par exemple, « huile pour engrenages », « transmission », « huile pour engrenages » - et Typesense commence à considérer tous ces termes comme équivalents. L'acheteur saisit l'une des options et reçoit le même ensemble de résultats. La configuration prend cinq minutes et entraîne des dizaines de sessions de recherche enregistrées par jour.

Il existe un autre type de synonymes : unidirectionnel. C'est à ce moment-là que Mobil doit trouver des produits de marque Mobil, mais pas l'inverse. Ou lorsque « liquide de direction assistée » doit trouver « huile de direction assistée », mais que la recherche de « huile de direction assistée » ne doit pas nécessairement inclure tout ce qui est étiqueté « liquide de direction assistée ». De telles subtilités sont particulièrement importantes dans les niches techniques où la terminologie peut être ambiguë.

La deuxième chose importante est la conservation des résultats. Certaines demandes sont stratégiquement importantes pour l’entreprise. Par exemple, vous savez que la requête « huile moteur 5W-30 » vous apporte le plus d’acheteurs de recherche. Et vous voulez que les premiers éléments dans les résultats de recherche ne soient pas n'importe quelle huile 5W-30 aléatoire, mais des articles spécifiques - peut-être avec la marge la plus élevée, peut-être provenant d'une marque partenaire, peut-être ceux qui sont actuellement en vente. La curation vous permet d'enregistrer les positions de produits spécifiques dans les résultats de recherche pour des demandes spécifiques. Vous dites : « Lorsque vous recherchez « huile 5W-30 », affichez toujours Shell Helix Ultra en premier, Castrol Edge en second, et masquez complètement le produit X des résultats de recherche. » Et ça marche.

Je sais que certaines personnes sont offensées par l'idée de peaufiner manuellement les résultats de recherche. On dit que la recherche doit être objective, l'algorithme doit décider. Et en théorie, c'est vrai. Mais dans la pratique, les affaires ne sont pas un exercice académique. Vous avez des produits qui doivent être promus. Il y a des biens qui doivent être vendus. Il existe des obligations de partenariat. Et le merchandising intelligent dans la recherche est un outil aussi légitime que le merchandising dans un magasin physique, où les bonbons sont toujours à la caisse et le lait est toujours dans le coin le plus éloigné.

La troisième fonctionnalité, et peut-être la plus sous-estimée, est l'analyse de recherche. Nous enregistrons chaque requête de recherche : ce qu'ils cherchaient, s'ils ont trouvé quelque chose, s'ils ont cliqué sur un résultat. De ces données se dégage une image qui ne peut être obtenue autrement. Vous voyez qu'au cours du mois dernier, deux cents personnes ont recherché « antigel rouge G12 » et aucune n'a trouvé de résultat - car dans votre catalogue, ce produit est appelé « liquide de refroidissement G12+ rouge ». Ajoutez un synonyme - et deux cents sessions de recherche perdues par mois se transforment en deux cents produits trouvés et ventes potentielles.

Ou un autre exemple. Vous voyez qu'une centaine de personnes par mois recherchent un article spécifique - disons "550046983". Il s'agit d'une référence d'huile Shell que vous n'avez pas dans le catalogue. Mais vous avez un analogue d'un autre fabricant. Sans l’analyse de recherche, vous ne sauriez jamais que ces centaines de personnes viennent, ne trouvent pas le produit et repartent. Et maintenant, vous voyez cette demande dans la partie supérieure "recherches sans résultats" et vous pouvez prendre une décision : soit ajouter ce produit au catalogue, soit créer un synonyme qui redirigera cette demande vers un analogue, ou au moins afficher la bannière "Vous n'avez pas trouvé cet article ? Essayez notre analogue..."

L'analyse de recherche est essentiellement une ligne de communication directe vers les besoins de vos acheteurs. Ils vous disent eux-mêmes ce qu’ils veulent via la barre de recherche. Il ne reste plus qu'à écouter.

Nous affichons les analyses sous une forme pratique : les requêtes les plus fréquentes, les requêtes sans résultats, les requêtes avec un faible CTR (lorsque les gens trouvent des résultats mais ne cliquent pas, ce qui signifie que les résultats ne sont pas pertinents), les tendances par jour et par semaine. Un gérant de magasin peut accéder à la section analytique une fois par semaine, y consacrer quinze minutes et obtenir des informations plus utiles sur la demande que n'importe quelle étude de marché.

Widget de recherche - à quoi il ressemble pour l'acheteur

Tout ce dont j'ai parlé auparavant concerne le backend. Indexation, synonymes, analyses, l'acheteur ne voit rien de tout cela. Il voit une barre de recherche et son expérience détermine s'il achète quelque chose ou s'il part. Par conséquent, nous avons effectué l’interface de recherche avec un soin particulier.

Le widget de recherche fonctionne comme ceci. L'acheteur commence à saisir du texte - et après le deuxième ou le troisième caractère, une fenêtre déroulante avec les résultats apparaît sous la barre de recherche. Pas seulement des liens texte, mais des fiches produits à part entière : image miniature, nom, prix, disponibilité en stock. L'acheteur voit les résultats avant même de terminer la demande et d'appuyer sur Entrée. C'est ce qu'on appelle la recherche au fur et à mesure de la frappe, et c'est la norme à laquelle les gens se sont habitués grâce à Google, Amazon et d'autres grandes plateformes. Lorsque votre magasin peut le faire également, ce n’est pas seulement une question de commodité, c’est un signal : « Nous sommes un magasin sérieux, tout fonctionne ici comme il se doit. »

Une requête vers Typesense est envoyée à chaque frappe, mais avec un anti-rebond de 200 millisecondes - afin de ne pas bombarder le serveur de requêtes pendant que l'acheteur tape rapidement. La réponse arrive en 5 à 50 millisecondes et les résultats sont mis à jour instantanément. C’est comme si les résultats étaient déjà prêts et n’attendaient que d’être montrés.

Le widget peut être inséré sur n'importe quelle page via un shortcode. Vous pouvez le mettre dans l'en-tête du site au lieu de la recherche WordPress standard - pour ce faire, dans la plupart des thèmes, il vous suffit d'ajouter un shortcode au bloc de widget souhaité. Peut être placé sur une page de résultats de recherche distincte. Peut être utilisé comme élément de page de destination : « Trouvez l'huile dont vous avez besoin en 3 secondes » - et il y a une ligne de recherche qui affiche instantanément les résultats. Cela fonctionne comme un élément de confiance puissant car cela démontre à l’acheteur que le catalogue est vraiment vaste et facile à parcourir.

Lorsqu'un client appuie sur Entrée ou clique sur « Afficher tous les résultats », il sera redirigé vers une page de résultats de recherche. C’est là qu’intervient le filtrage par facettes, dont j’ai parlé plus tôt. Sur la gauche se trouve un panneau de filtres avec les catégories, les marques, la gamme de prix et les attributs. À droite se trouvent les fiches produits avec pagination. Les filtres fonctionnent instantanément - sans recharger la page, via AJAX. J'ai cliqué sur "Shell" - la liste a été mise à jour en une fraction de seconde, affichant uniquement les produits Shell. J'ai supprimé le filtre et toute la liste est revenue. C'est le niveau d'UX auquel les clients sont habitués sur les marketplaces, et qui distingue nettement votre boutique des concurrents, où la recherche renvoie tous les résultats dans une seule feuille interminable sans possibilité de filtrage.

Je vais vous parler séparément de la mise en évidence des correspondances. Lorsqu'un client recherche « Huile hydraulique HLP 46 », les résultats de la recherche mettent en évidence les mots trouvés en gras ou en couleur. L'acheteur voit instantanément pourquoi ce produit particulier est apparu dans les résultats de recherche et peut rapidement évaluer sa pertinence. C'est une petite chose, mais cela améliore considérablement l'expérience et réduit le temps entre la demande et le clic.

Et une autre chose qui est souvent négligée est l'adaptabilité. Le widget de recherche fonctionne correctement sur les appareils mobiles. Et le trafic mobile atteint désormais 60 à 70 % pour la plupart des boutiques en ligne. Sur un téléphone, une fenêtre déroulante avec les résultats occupe toute la largeur de l'écran, les fiches produits s'adaptent à un écran étroit, les filtres de la page de résultats sont réduits en un panneau coulissant. Rien ne se casse, rien ne s'emboîte les uns dans les autres. Cela semble être une exigence évidente, mais vous seriez surpris du nombre de plugins de recherche qui fonctionnent encore mal sur les téléphones mobiles.

16 844 produits - comment ça marche au combat

La théorie c'est bien, mais parlons de l'expérience réelle. Nous avons un magasin de lubrifiants - 16 844 produits, WooCommerce, un thème personnalisé basé sur Porto, et notre plugin COS WP Woo avec un module de recherche sur Typesense. Ce magasin est notre terrain d'entraînement au combat, où nous testons toutes les fonctions sur des données réelles et de vrais clients.

Avant l'introduction de Typesense, la recherche sur cette boutique fonctionnait via le standard WooCommerce avec plusieurs améliorations - recherche par SKU et par attributs via un plugin supplémentaire. Le temps de réponse moyen à une requête de recherche variait de 800 à 2 000 millisecondes, selon la charge du serveur. Sur les appareils mobiles, où chaque seconde compte, la lenteur était désastreuse. Nous n’avons pas du tout collecté d’analyses de requêtes de recherche : il n’existait aucun outil.

Après avoir lancé le module de recherche sur Typesense, nous avons réalisé une indexation complète du catalogue. Plus de seize mille produits - l'indexation prenait une vingtaine de minutes en arrière-plan, via Action Scheduler. La taille de l'index dans Typesense est d'environ cent cinquante mégaoctets. La consommation de RAM par Typesense lui-même est d'environ deux cents mégaoctets. Pour un serveur doté de huit Go de RAM, cela est imperceptible.

Le temps de réponse moyen aux requêtes de recherche après le passage à Typesense est de 8 à 15 millisecondes. Cela prend en compte la latence du réseau entre WordPress et Typesense, qui se trouvent sur le même serveur. Pour le consommateur, cela ressemble à une réponse instantanée : il commence à taper et les résultats apparaissent avant même qu'il puisse lever le doigt de la touche.

Nous avons commencé à collecter des analyses de recherche dès le premier jour, et cela a rapidement montré des choses intéressantes. Il s'est avéré qu'une partie importante des acheteurs recherchent des produits par numéro d'article - non pas par nom, mais par code alphanumérique. C'est typique du segment B2B : le responsable des achats dispose d'un cahier des charges avec des articles et les saisit simplement un par un. Dans un tel scénario, la recherche instantanée avec saisie semi-automatique représente un énorme gain de temps. Au lieu d'attendre trois à cinq secondes à chaque fois pour le chargement de la page de résultats, le responsable reçoit une réponse instantanément et peut traiter la commande plusieurs fois plus rapidement.

Une autre découverte issue de l'analyse est le nombre de requêtes sans résultat. Au cours de la première semaine, il y en avait environ 15 pour cent du total. Autrement dit, un acheteur sur six ou sept n'a pas trouvé ce qu'il cherchait. Nous avons analysé ces requêtes et découvert plusieurs modèles. Certaines des demandes concernaient des fautes de frappe et des orthographes alternatives, qui ont été résolues en créant des synonymes. Certaines d’entre elles concernaient des produits qui ne figuraient pas vraiment dans le catalogue, mais qu’il était logique d’ajouter. Certaines sont des demandes de produits qui figuraient dans le catalogue, mais sous un nom différent. Après un mois de travail avec des analyses et des synonymes, nous avons réduit la part des demandes sans résultat à 4 à 5 %. Cela signifie qu'environ dix pour cent des acheteurs qui repartaient les mains vides trouvent désormais ce qu'ils cherchent.

Voici un exemple précis. Les acheteurs recherchaient souvent « VMGZ » - il s'agit d'une marque d'huile hydraulique bien connue dans l'industrie. Mais dans le catalogue, le produit s'appelait «Huile hydraulique VMGZ-45», et une recherche standard ne l'a trouvé que par occurrence complète. Si l'acheteur tapait simplement « VMGZ » sans « -45 », il y avait un résultat, mais s'il tapait « huile VMGZ », la recherche était déjà perdue car les mots étaient dans un ordre différent. Après le passage à Typesense, ce problème a disparu : Typesense recherche dans tous les champs, prend en compte l'ordre des mots et trouve des correspondances partielles. De plus, nous avons ajouté des synonymes : « VMGZ » = « Huile hydraulique VMGZ » = « Huile VMGZ-45 » - et désormais chacune de ces requêtes mène aux produits corrects.

Si nous parlons de l'impact sur les indicateurs commerciaux - et ici, nous devons être honnêtes, nous n'avons pas effectué un pur test A/B, je ne peux donc pas dire avec une précision scientifique que la conversion a augmenté de X pour cent précisément à cause de la recherche. Mais nous constatons une corrélation : après l'introduction de la nouvelle recherche, le pourcentage de sessions de recherche se terminant par l'ajout d'un article au panier a augmenté. Les acheteurs ont commencé à utiliser la recherche plus souvent au lieu de naviguer dans le catalogue - ce qui est logique, car la recherche est désormais plus rapide et plus fiable que la recherche par catégories. Et le nombre de demandes d'assistance avec la mention « Je ne trouve pas le produit » a pratiquement disparu.

Je ne donnerai pas de chiffres précis sur la croissance des conversions, car je pense que c'est malhonnête : trop de facteurs influencent la conversion, et il est impossible d'isoler la contribution de l'un d'entre eux sans une expérience contrôlée. Mais je peux le dire en toute confiance : une recherche rapide et intelligente supprime l'un des obstacles les plus ennuyeux entre un acheteur et un achat. Et supprimer les obstacles est l’essence même de l’optimisation des conversions.

Il existe un autre aspect rarement abordé : la charge du serveur. Une recherche WooCommerce standard est une requête SQL lourde qui charge la base de données MySQL. Chaque requête de recherche est une JOIN de plusieurs tables, une analyse de table complète, une consommation d'E/S CPU et disque. Lorsque dix personnes effectuent des recherches sur le site en même temps, il y a dix requêtes lourdes en même temps. Sur un hébergement aux ressources limitées, cela peut ralentir non seulement la recherche, mais aussi l'ensemble du site – pages catalogue, panier, paiement. Avec Typesense, la charge de recherche est complètement supprimée de MySQL. La base de données fait ce qu'elle doit faire : traiter les commandes, mettre à jour les soldes, travailler avec le panier. Et la recherche est traitée par un moteur distinct optimisé à cet effet. Ceci est particulièrement critique pendant les périodes de pointe – soldes, promotions, lorsque le trafic augmente de manière significative.

Nous avons remarqué dans notre magasin qu'après avoir déplacé la recherche vers Typesense, la charge moyenne de MySQL a diminué de quinze à vingt pour cent. Cela ne semble pas beaucoup, mais en pratique, c'est la différence entre « le site est stable » et « le site ralentit périodiquement pendant les heures de pointe ». Et pour un magasin qui reçoit des commandes valant des dizaines et des centaines de milliers de roubles, chaque seconde de retard à la caisse est une commande potentiellement perdue.

Et on ne peut s’empêcher de mentionner la recherche de documents. C’est une fonctionnalité que peu de gens mettent en œuvre, mais qui s’avère inestimable pour les magasins industriels et B2B. Notre module peut indexer le contenu des fichiers PDF attachés aux produits. Fiches techniques, certificats de conformité, fiches de données de sécurité, mode d'emploi, tout cela est du texte, et tout cela devient disponible grâce à une recherche. L'ingénieur saisit le numéro TU ou GOST et la recherche trouve les produits dans la documentation technique desquels cette norme est mentionnée. Pour une entreprise qui achète des lubrifiants industriels et où le choix de l'huile n'est pas déterminé par le prix, mais par le respect d'une norme spécifique, cela change fondamentalement l'expérience de travail avec le catalogue. Ils n'appellent plus le responsable et lui demandent « de trouver une huile conforme à GOST 17479.4-87 » - ils la trouvent eux-mêmes, en trois secondes, grâce à une recherche.

Une fierté particulière est la rapidité de réindexation. Lorsque nous avons connecté la synchronisation avec 1C via notre propre module d'intégration et que chaque nuit le magasin reçoit des mises à jour des prix et des soldes pour les seize mille produits, il était important pour nous que l'index de recherche soit mis à jour tout aussi rapidement. Typesense gère la mise à jour d'un seul document en 1 à 2 millisecondes. Seize mille mises à jour représentent environ trente secondes au total. En comparaison, la réindexation d'Elasticsearch pour ce volume prendrait quelques minutes, voire plusieurs dizaines de minutes, selon la configuration.

Je vais vous parler d'une autre situation qui illustre bien la différence entre « la recherche fonctionne » et « la recherche fonctionne correctement ». Dans notre catalogue, nous avons des huiles de différents emballages - la même huile peut être vendue en bidon de 1 litre, 4 litres, 20 litres et en fût de 208 litres. Ce sont quatre produits différents avec des prix différents, des articles différents, mais essentiellement le même produit. Lorsqu’un acheteur recherche « Shell Helix HX8 5W-30 », il s’attend à voir tous les emballages côte à côte afin de pouvoir choisir celui dont il a besoin. Une recherche WordPress standard les a renvoyés mélangés à d’autres huiles Shell, car la pertinence était déterminée par l’ordre des mots dans le titre et la date de publication. Typesense se classe par degré de correspondance - une correspondance de nom exacte est toujours supérieure à une correspondance partielle, et les quatre packages sont en première position, regroupés de manière naturelle. L'acheteur voit immédiatement toutes les options et peut choisir sans parcourir trois pages de résultats.

Un autre point que je considère comme fondamental est la sécurité et l'isolement des données. Typesense indexe uniquement les données que vous choisissez explicitement d'indexer. Il n'a pas accès à la base de données WordPress, ne connaît pas les mots de passe des utilisateurs, ne voit pas les commandes et ne stocke pas les données personnelles des clients. L'index contient uniquement des informations sur le produit : nom, description, prix, attributs, images. Pour les magasins qui travaillent avec des entreprises clientes et doivent se conformer aux exigences en matière de traitement des données personnelles, c'est un plus non négligeable. Le moteur de recherche ne peut physiquement pas « divulguer » autre chose que les informations du catalogue public, car il ne contient rien d’autre.

Et je veux aussi parler du coût de possession, car c'est la question qui revient le plus souvent. Algolia, le concurrent le plus connu de Typesense dans le monde de la recherche cloud, commence à 1 $ pour mille recherches. Cela semble bon marché jusqu'à ce que vous fassiez le calcul. Si vous avez un millier de visiteurs par jour et que chacun effectue en moyenne trois requêtes de recherche (une requête de base et deux requêtes de qualification avec saisie semi-automatique), cela représente 90 000 transactions par mois. Plus l'indexation - chaque mise à jour du produit est également considérée comme une opération. Pour un magasin proposant seize mille produits et un commerce actif, la facture d'Algolia peut facilement s'élever à 50-100 dollars par mois. Et malgré le fait qu’Algolia soit un excellent service, je n’en dirai rien de négatif.

Typesense Cloud est nettement moins cher, à partir de 29,99 $ par mois pour une instance dédiée qui gère un nombre illimité de requêtes. Pas de frais de transaction, pas de factures, pas de surprises à la fin du mois. Et si vous êtes prêt à installer Typesense sur votre serveur, c'est totalement gratuit, car Typesense est entièrement open source. Pour notre boutique de combat, nous avons choisi l'option auto-hébergée - Typesense fonctionne sur le même serveur que WordPress, consomme deux cents mégaoctets de mémoire et ne coûte pas un centime. Le seul « coût » est le temps d’installation initial, qui prend environ trente à quarante minutes pour une personne familiarisée avec Linux, ou quelques clics si vous utilisez Docker.

Lorsque je compare le coût de Typesense à ce qu'un magasin perd en raison d'une mauvaise recherche, la différence est si évidente que la question elle-même semble rhétorique. Une commande perdue par jour – disons que la facture moyenne est de trois mille roubles – cela représente quatre-vingt-dix mille roubles par mois. Un. Et combien de commandes sont perdues lorsque 15 % des requêtes de recherche n’aboutissent à aucun résultat ? Quand la recherche ne comprend-elle pas les fautes de frappe ? Lorsqu'un client attend trois secondes et s'adresse à un concurrent qui obtient des résultats instantanés ? Je ne veux pas spéculer sur des chiffres précis, mais l’ampleur des pertes dépasse clairement le coût de la solution, et ce, de plusieurs ordres de grandeur.

Voici ce que j'ai réalisé en travaillant avec la recherche : une recherche appropriée n'est pas une fonctionnalité, c'est une infrastructure. Il s’agit du même élément essentiel d’une boutique en ligne que le panier ou la caisse. Vous pouvez avoir le catalogue parfait, un beau design, une livraison rapide - mais si l'acheteur ne trouve pas le produit dont il a besoin, rien d'autre n'a d'importance. Et pourtant, la recherche est l’une des parties les plus sous-investies de la plupart des magasins WooCommerce. Les gens dépensent des milliers de dollars en publicité, attirent du trafic, puis perdent des clients à cause de la chose la plus simple : « Je n'ai pas trouvé ce que je cherchais ».

Et si on regardait les choses de l'autre côté ? Chaque rouble investi dans l'amélioration de la recherche ne sert pas à attirer du nouveau trafic, mais à convertir le trafic existant. Vous ne payez pas par clic, ni par impression : vous arrêtez simplement de perdre ceux qui sont déjà arrivés. Et en ce sens, le retour sur investissement d’une bonne recherche peut être nettement supérieur au retour sur investissement d’une autre campagne publicitaire.

J'ai beaucoup réfléchi à la raison pour laquelle la communauté WordPress a toléré si longtemps une mauvaise recherche. Et je pense que le fait est que la plupart des propriétaires de magasins ne savent tout simplement pas en quoi cela pourrait être différent. Ils sont habitués au fait que la recherche est une tâche lente et qu’ils ne trouvent pas toujours ce dont ils ont besoin. Ils ne voyaient pas comment fonctionne la recherche sur Amazon ou Ozon, et ne pensaient pas que la même technologie était disponible pour une boutique WooCommerce. Et lorsque vous leur montrez la différence - vous ouvrez littéralement deux fenêtres de navigateur, l'une avec la recherche standard, l'autre avec Typesense, et saisissez la même requête - les mâchoires des gens tombent littéralement. "Est-ce que c'était possible de faire ça?" - la réaction la plus courante.

Oui, c'est possible. Et c'est nécessaire. Et nous l'avons rendu aussi accessible que possible : nous l'avons intégré directement au plugin, avec une configuration étape par étape, un panneau d'administration facile à comprendre et une synchronisation automatique. Pas de danse avec un tambourin, pas de programmation, pas de serveurs séparés - bien que cette option soit également disponible pour ceux qui ont besoin d'évolutivité. Connectez Typesense Cloud ou installez-le sur votre serveur, spécifiez la clé API dans les paramètres, cliquez sur « Index » - et en vingt minutes vous avez une recherche qui fonctionne cinquante fois plus vite, comprend les fautes de frappe, la morphologie russe et les articles. Ce n’est pas une exagération marketing, c’est littéralement ce qui se passe.

Et la dernière chose que je veux dire. Nous ne nous sommes pas arrêtés à ce que nous avons aujourd'hui. La recherche est un système vivant qui doit évoluer avec le magasin et les attentes des clients. Nos projets immédiats incluent la personnalisation des résultats de recherche en fonction de l'historique des achats et de la navigation, l'intégration avec un moteur de recommandation et la recherche vocale pour les appareils mobiles. Le monde du commerce électronique évolue vers une expérience client de plus en plus intelligente, et la recherche est à l'avant-garde de ce mouvement.

En attendant, si vous avez une boutique WooCommerce avec plus d'un millier de produits et une recherche WordPress standard, essayez de taper une requête avec une faute de frappe et regardez le résultat. Si le résultat vous dérange, il est temps de changer quelque chose. Et je sais par où commencer.

Essayez COS WP Woo - 14 jours gratuits.Installez le plugin, connectez le module de recherche intelligente à Typesense et voyez comment l'expérience de vos clients va changer. Aucune restriction de fonctionnalité, aucune liaison de carte. Une recherche rapide et intelligente qui trouve ce que recherchent vos clients, en millisecondes et non en quelques secondes.