Aller plus loin avec Algolia : pertinence, personnalisation et recommandations

Une fois Algolia branché sur un site Drupal ou une application Symfony (l'intégration est détaillée dans l'article Algolia avec Drupal ou Symfony), le moteur répond vite et tolère les fautes. Ce n'est qu'un point de départ. Les fonctions qui font la différence sur un catalogue, la personnalisation, le reclassement automatique, les recommandations, reposent toutes sur la même condition : savoir ce que les visiteurs font des résultats. Voici dans quel ordre les mettre en place, et ce que chacune exige réellement.

Régler la pertinence avant tout le reste

Les réglages de base d'un index sont disponibles quelle que soit l'offre. Ce sont eux qu'il faut travailler en premier.

Les attributs recherchables (searchableAttributes) sont ordonnés : un mot trouvé dans le titre pèse plus qu'un mot trouvé dans la description. Listez peu d'attributs, du plus au moins important, et marquez unordered() ceux où la position du mot dans le texte n'a pas de sens.

Le classement métier (customRanking) départage les résultats de pertinence textuelle égale : popularité, ventes récentes, date de publication, note moyenne. Il suppose que ces valeurs soient présentes dans les enregistrements et tenues à jour par l'indexation.

La tolérance aux fautes est active par défaut. On la désactive sur les attributs où elle nuit : références produit, codes, numéros de formation.

Les synonymes traitent le vocabulaire propre à votre domaine : abréviations, termes métier contre termes grand public. Algolia distingue les synonymes réciproques et les synonymes à sens unique (« ordinateur » peut renvoyer « portable » sans que l'inverse soit vrai).

Ces réglages se versionnent. Plutôt que de les modifier à la main dans le tableau de bord, je les applique par script, ce qui permet de recréer un index à l'identique en préproduction :

use Algolia\AlgoliaSearch\Api\SearchClient;

$client = SearchClient::create($_ENV['ALGOLIA_APP_ID'], $_ENV['ALGOLIA_WRITE_KEY']);

$client->setSettings('produits_fr', [
    'searchableAttributes' => ['title', 'brand', 'unordered(description)'],
    'customRanking' => ['desc(sales_30d)', 'desc(rating)'],
    'attributesForFaceting' => ['brand', 'category', 'filterOnly(visibility)'],
    'disableTypoToleranceOnAttributes' => ['sku'],
]);

Les règles (Rules) complètent ce socle : épingler un produit sur une requête, en masquer un autre, afficher une bannière, appliquer un filtre quand la requête contient un mot précis. C'est l'outil du merchandising. Leur nombre dépend de l'offre : la page tarifs d'Algolia indique 10 règles par index sur le plan Grow et 10 000 sur Grow Plus et Elevate. Sur une petite offre, réservez-les aux requêtes qui comptent vraiment.

Mesurer : les événements Insights, prérequis des fonctions avancées

Tant que le moteur ne reçoit aucun retour, il ne sait pas qu'un résultat en cinquième position est celui qu'on clique le plus. Les événements Insights comblent ce manque. Il en existe trois familles : les vues, les clics (sur un résultat, sur une facette) et les conversions (ajout au panier, achat, inscription, téléchargement).

Côté navigateur, InstantSearch.js les envoie presque sans code : l'option insights: true charge la bibliothèque search-insights et émet les événements par défaut des widgets (résultats vus, résultat cliqué, filtre appliqué). Deux notions sont à comprendre :

• le queryID, renvoyé par chaque recherche quand le paramètre clickAnalytics est activé, relie un clic ou une conversion à la recherche qui l'a précédé. D'après la documentation, un événement qui porte un queryID doit arriver dans l'heure qui suit la recherche ;
• le userToken identifie le visiteur. Depuis la version 2 de search-insights, il n'est plus stocké dans un cookie par défaut : un jeton anonyme est généré au chargement de la page, sans persistance.

Ce second point a une conséquence directe sur le RGPD. Tant que vous n'activez pas le cookie, le suivi reste anonyme et limité à la page. Dès qu'un jeton persiste d'une visite à l'autre, ou qu'il est rattaché à un compte client, il s'agit d'un suivi d'utilisateur : dans la plupart des cas, il faut le consentement du visiteur. Algolia le rappelle dans sa documentation et demande de ne jamais mettre de donnée personnelle (e-mail, nom) dans un userToken. Concrètement, le choix du bandeau de consentement pilote la configuration :

const search = instantsearch({
  indexName: 'produits_fr',
  searchClient,
  insights: {
    insightsInitParams: { useCookie: consentementMesure },
  },
});

Les statistiques de base (requêtes fréquentes, requêtes sans résultat) fonctionnent sans ces événements. Le taux de clic, le taux de conversion par requête, et tout ce qui suit dans cet article, en ont besoin.

Query Suggestions et Autocomplete

Query Suggestions génère un index séparé de suggestions à partir des recherches les plus fréquentes des 30 derniers jours sur votre index source. Il est reconstruit automatiquement. Affiché dans un champ Autocomplete, il guide le visiteur vers des requêtes qui renvoient des résultats. Sur un site récent, sans historique, la documentation prévoit deux solutions : importer des statistiques externes, ou générer des suggestions à partir de combinaisons de facettes. La page tarifs indique la fonction sur toutes les offres, y compris gratuite.

Personnaliser les résultats

La personnalisation reclasse les résultats selon les affinités d'un visiteur : un client qui consulte surtout une marque verra cette marque remonter. Algolia construit ces profils à partir des événements, en particulier des clics et conversions sur des facettes.

L'offre se décline aujourd'hui en trois niveaux, d'après la page tarifs : Classic Personalization à partir du plan Grow, Advanced Personalization (profils générés automatiquement) à partir de Grow Plus, et la personnalisation en temps réel sur Elevate. Activer Advanced Personalization désactive Classic.

Les prérequis sont exigeants. Il faut transmettre le même userToken aux requêtes de recherche et aux événements ; la documentation précise que l'authenticatedUserToken n'est pas utilisé par la personnalisation. Il faut donc un jeton stable, et un jeton stable suppose le consentement évoqué plus haut. Sur un site où une large part des visiteurs refuse le suivi, la personnalisation ne concerne que ceux qui l'acceptent : à intégrer dans vos attentes.

Dynamic Re-Ranking : laisser les clics reclasser

Dynamic Re-Ranking apprend des clics et conversions associés à une requête et fait remonter les résultats qui gagnent en popularité. Il ne crée pas de résultats : il réordonne ceux que le moteur a déjà trouvés. Selon la documentation, il faut pour une paire requête-résultat au moins 20 clics ou 2 conversions sur une fenêtre de 30 jours. Autrement dit, il agit surtout sur les requêtes fréquentes ; sur la longue traîne, vos réglages de pertinence restent seuls en jeu. La page tarifs le place sur les offres Grow Plus et Elevate.

Recherche sémantique : NeuralSearch

NeuralSearch ajoute une recherche vectorielle à la recherche par mots-clés, puis fusionne les deux classements. L'intérêt : répondre à une requête formulée avec des mots absents des contenus (« formation pour manager une équipe à distance » sur un catalogue qui parle de « management hybride »). Il ne nécessite pas d'événements, même s'ils aident le moteur à choisir les attributs à vectoriser. D'après la page tarifs, il est réservé à l'offre Elevate. Avant d'y penser, vérifiez que les synonymes et les Query Suggestions ne couvrent pas déjà l'essentiel des requêtes sans résultat.

Recommend : produits similaires, achetés ensemble, tendances

Algolia Recommend fournit des modèles de recommandation, chacun avec son propre seuil de données selon la documentation :

Ces seuils trient les cas d'usage. Un site institutionnel ou un catalogue de formations a rarement le volume de conversions pour « achetés ensemble », mais peut utiliser « Related content » dès le départ pour proposer des publications proches. Un site e-commerce actif peut viser les modèles fondés sur le comportement.

A/B testing : prouver avant de généraliser

L'A/B testing compare la configuration actuelle à une ou plusieurs variantes, sur du trafic réel. On peut tester des paramètres de recherche directement, ou des réglages d'index via des répliques : autre classement métier, autres attributs recherchables, règles, tolérance aux fautes. La mesure repose sur les clics et conversions : sans événements, pas de test exploitable. La fonction est disponible à partir du plan Grow.

Feuille de route : du moteur qui répond au moteur qui vend

L'ordre compte plus que l'étendue. L'étape 4 sans l'étape 2, c'est payer des fonctions qui n'ont rien à apprendre.

Brancher les conversions côté serveur

Certaines conversions ne se voient pas dans le navigateur : un paiement confirmé, une inscription validée par un back-office. On les envoie alors depuis le serveur avec le client Insights de la bibliothèque PHP v4. Sur Drupal Commerce, un abonné à la transition de commande place s'en charge :

use Algolia\AlgoliaSearch\Api\InsightsClient;
use Drupal\state_machine\Event\WorkflowTransitionEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

final class OrderInsightsSubscriber implements EventSubscriberInterface {

  public function __construct(private readonly InsightsClient $insights) {}

  public static function getSubscribedEvents(): array {
    return ['commerce_order.place.post_transition' => 'onPlace'];
  }

  public function onPlace(WorkflowTransitionEvent $event): void {
    /** @var \Drupal\commerce_order\Entity\OrderInterface $order */
    $order = $event->getEntity();
    // Jeton enregistré sur la commande uniquement si le visiteur a consenti.
    $token = $order->getData('algolia_user_token');
    if (!$token) {
      return;
    }
    $ids = [];
    foreach ($order->getItems() as $item) {
      // Doit correspondre au format d'objectID de votre index.
      $ids[] = 'variation-' . $item->getPurchasedEntityId();
    }
    $this->insights->pushEvents(['events' => [[
      'eventType' => 'conversion',
      'eventSubtype' => 'purchase',
      'eventName' => 'Order Completed',
      'index' => 'produits_fr',
      'userToken' => $token,
      'objectIDs' => array_slice($ids, 0, 20),
    ]]]);
  }
}

Le client se déclare comme service avec InsightsClient::create(), qui prend l'identifiant d'application, une clé et la région des données analytiques. Sur Symfony, la logique est la même dans un handler Messenger déclenché par la validation de la commande, ce qui évite de ralentir la réponse au client. Deux vérifications à faire : les objectIDs doivent être exactement ceux de l'index, et un événement de ce type ne rattache pas l'achat à une recherche précise. Pour cela, il faut conserver le queryID de la recherche d'origine avec la ligne de panier, en respectant la fenêtre d'une heure, ce qui est souvent plus simple à faire côté navigateur.

Par où commencer

Sur un site existant, le premier pas est un état des lieux : quelles requêtes échouent, quels réglages sont en place, quels événements remontent, et si le consentement est correctement relié au suivi. C'est un point que l'audit flash peut couvrir. Les réglages de pertinence et le suivi des requêtes sans résultat relèvent ensuite d'un travail régulier, qui trouve sa place dans une TMA Drupal. Pour une application métier, voir la page Symfony.