Shopping engines : finalement, personne n’a cracké le code…

On sentait le vent tourner depuis quelques mois : il y avait belles lurettes que les moteurs de shopping (Kelkoo et consorts) ne faisaient plus de beaux effets d’annonces à propos de technologies révolutionnaires. Finis les communiqués pour clamer qu’on avait plus de produits, plus de revendeurs, plus de catégories, plus de mises à jour, plus de plus… tout le charme du syndrome Bahlsen des belles années.

Depuis quelques temps déjà les quelques innovations étaient centrées sur la technologie de recherche elle-même. Car le nerf de la guerre est bien là pour les shopping engines : référencer un maximum de prix, les associer à un maximum de produits… et surtout faire en sorte qu’on les trouve ! Et c’est bien là que les ennuis commencent. Si la recherche s’articule autour d’un nom de produit, facile : pas besoin d’une base de spécifications ultra-normalisée et tirée au cordeau. Un index assez basique remplit son office. Mais cela ne suffit pas, surtout que Google fait aussi bien avec ses résultats naturels, sans rien demander à personne (ni faire payer d’ailleurs).

Bref, le point n’est pas de fournir un prix, mais bien de proposer d’abord des produits et ensuite des prix pour ces produits. C’est (cétait ?) d’ailleurs le parti de Kelkoo : être un moteur de recherche de produits.

Non, le nerf de la guerre, le nirvana du truc, c’est d’être capable de donner des résultats pertinents avec une requête basée sur un usage ou au moins d’être capable de proposer des options de tri permettant de répondre à cet usage. Le top étant de pouvoir ajouter à cela du contenu utilisateur sur les produits et les revendeurs, quelques fonctions bien senties comme la possibilité de suivre les variations de prix via du RSS sur sa page personalisée Yahoo, MSN ou Google, des listes de shopping intelligentes à base de tags, etc (avec un petit coup d’Ajax pour permettre une personnalisation facile). Mais jusqu’à maintenant, même les plus avancés dans le domaine se cassaient la tête sur la base, le coeur de la machine : comment automatiser au maximum :

  • la normalisation des données revendeurs
  • la mise à jour d’un catalogue produit et des spécifications de chaque produit (un beau casse-tête en soi déjà)
  • le matching de données revendeurs sur cette base de donnée (miam)
  • la création d’un index permettant de répondre au plus grand nombre de requête, aussi larges soient-elles en utilisant les spécifications produits

Et finalement, c’est Google qui annonce la couleur, en 2 étapes :

  • 1 : la normalisation des données revendeurs et produits est un mythe, un but impossible à atteindre (lire cet article de comparisonengines.com). Allez hop, du balai les données normalisées, spécifications, SKUs, et autres joyeusetés.
  • 2 : Google commence à gentiment baisser les bras (une première !) et retire Froogle de sa homepage au profit de son service vidéo, certainement plus prometteur.

Résultat, il va falloir apprendre à trier à la place des moteurs (un comble !) car effectivement, les produits sont là, mais on est plus à la brocante du village que dans les rayons policés d’un grand magasin (faudrait d’ailleurs trouver une solution pour les images car 30 fois la même image, c’est fatigant à la longue ; et puis c’est intéressant de pouvoir comparer les specs du même produit 15 fois de suite 🙂 ).Signes des temps ? Sûrement… les services vidéos sont autrement plus « 2.0 » que les shopping engines, ces gros bouzins pas sexy, compliqués à développer, compliqués à maintenir, compliqués à commercialiser et où avant d’exister, il faut atteindre des volumes d’audience et de clics pharaoniques (d’ailleurs pour le moment, les seuls qui s’en sortent sont bien ceux qui savent revendre un clic plus cher qu’il ne leur a coûté à capter…).

Donc résumons : Google, le roi de l’algo qui tue et de l’indexation, baisse les bras, Microsoft a abandonné depuis longtemps, Ebay, le pape du commerce en ligne, n’a même jamais tenté de se frotter au problème (trop malin) et laisse ces migraines à sa filiale Shopping.com (pour moi certainement les plus avancés sur les techniques de recherches et ce n’est pas parce que je travaille avec eux que je le dis), et Yahoo tente de s’en sortir avec la « techno » Kelkoo en Europe et les neurones maisons aux US (avant de déployer Kelkoo ?).

Cela donne tout de même l’impression de fin de rêve : on invente de nouvelles histoires pour faire oublier les anciennes, de nouveaux termes pointent leur nez (comme le crowdsourcing – une pointe de user content, ça fait mieux 🙂 ), ou bien on essaie d’éviter les grosses machineries en rajeunissant les réus Tupperware à la mode social networking (encore de l’affiliation qui ne dit pas son nom ?).

Dommage, l’utopie binaire de développeur était belle, mais finalement, pour les shopping engines, tout est bien question de volume et de masse critique : de produits, de visites, de clics, de revendeurs… et de mains plus ou moins petites pour faire fonctionner tout cela. Exit l’algo miraculeux qui permet d’automatiser au maximum les traitements de données et de faire traiter humainement ce qui est à la marge en essayant de limiter les coûts au maximum.

Au final, est-ce que le code était crackable ?

Publicités

11 réflexions sur “Shopping engines : finalement, personne n’a cracké le code…

  1. Excellent raisonnement. Google n’a pas cracké le code il vient en effet de baisser les bras, le tout est de raconter ça avec une belle histoire pour positiver. Pour les autres ca fait belle lurette qu’une partie de l’index et du catalogue et construit à la main en Inde ou ailleurs. pas de quoi pavoiser quand on communique sur la toute puissance de la technologie …
    Pour moi Shopping.com est aussi médiocre (désolé) que les autres mais bénéficie de la prime du nouvel entrant avec un index encore à peu pres propre… Kelkoo n’a jamais brillé par la pertinence mais délivre du volume c’est ca son secret.
    Votre billet acheve de me convaincre qu’il faut traiter le sujet avant qu’il sombre dans l’oubli. j’ai bien noté l’annonce de Google mais la torpeur de l’été l’a emporté 🙂

  2. Merci Emmanuel (c’est jpp 🙂 ). Marrant (enfin presque) de voir le virage à 180° pris sur les chapeaux de roues en espérant qu’on entendra pas trop les crissements de pneus. En revanche, lorsque l’on voit la tête des résultats de recherche que cela donne, je me demande comment on va encore pouvoir discuter des pouillèmes de taux de transformation (et j’ose même pas imaginer l’histoire avec du CPA… beaux échanges en perspective !)

    Mais qd même, même si les offres de prix et les catalogues sont discutables, de tout ce que j’ai vu, je trouve tout de même que le module de recherche de Shopping.com est un des plus performants actuellement… à quel prix, ça c’est une autre histoire

  3. Pourquoi Shopping.com ?

    Personnellement, j’aime beaucoup MonsieurPrix.com qui est assez complet, plutôt rapide et où l’on peut facilement s’y retrouver (toujours est-il que c’est mon cas).

  4. Monsieurprix.com (propriété de Kelkoo, donc de Yahoo! d’ailleurs… lire http://www.journaldunet.com/0309/030916kelkoo.shtml) offre un catalogue et une couverture de revendeurs sur le domaine hich-tech très bonnes, tant sur la profondeur que la largeur. Mais là ou je pense que les gens de Shopping.com sont plus avancés (opinion toute personnelle, bien sûr) c’est sur l’utilisation des spécifications produits pour faciliter les recherches, les sélections et les choix de produits.

    Pour éléments de comparaison sur un même produit et une même requête :
    – Mprix : http://www.monsieurprix.com/search/quicksearch.html?motcle=nikon&type=
    – Shopping.com : http://fr.shopping.com/xFS?KW=nikon&FN=&FD=0

    Les possibilités de tris sont bien plus avancées et « user centrics » sur Shopping.com : à partir de la requête, l’utilisateur peut affiner sa recherche au fur et à mesure via des tris centrés sur des usages et ces possibilités de tris sont toujours contextualisées selon les choix antérieurs. Il y a bien sûr des propositions plus ou moins pertinentes, mais on peut constater que la base de données utilisent des logiques pour optimiser les résultats le plus pertinemment possible.

    Mais le vrai point est de savoir sur quel point les moteurs de shopping veulent concentrer leur efforts. Dans le cas de ces 2 là, il semble que les stratégies soient totalement oppposées. Le premier privilégie la masse de produit et de prix, le second la navigation et la recherche de produit (même si de gros efforts sont faits pour développer les catalogues produits et marchands).

    Maintenant si l’en raisonne en terme de rendement dégressif, est-ce que les ressources mobilisées pour améliorer l’expérience utilisateur paie plus en termes de volumes et de taux de transformation que la première option ? C’est là qu’intervient l’art de savoir capter des volumes d’audience importants pour leur faire générer des clics, qualifiés ou non…

  5. Très bonne analyse de ce métier.

    A quand un moteur de shopping entièrement automatique ? Avec un crawler (et non des flux donnés par les marchands) et une gestion des data sans intervention humaine. Dans ce cadre c’est le moteur qui « normaliserait » les « données produits ».
    Ce n’est pas simple mais pas impossible 😉

  6. Merci Franck. Et effectivement, nous regardons tous le même Graal dans ce domaine je pense, surtout que les technos deviennent matures. Dommage que les base de données ne le soient pas autant.

    Nous avions nous-mêmes travaillé sur ce type de solution. En gros l’idée était
    – 1 : passer tous les flux récupérés dans un parseur pour les normaliser et les rendre consistants (XML based). Cela nécessitait tout de même un set up énorme, surtout que la plupart des flux étaient loin d’être correctement structurés et encore moins correctement maintenus (ah, la joie de la DTD changée après le setup…)
    – 2 : matcher ces flux normalisés sur une base produits « propre » qui permette ensuite d’utiliser les specs produits pour créer des filtres par usage et donner la possibilité aux utilisateurs de ne plus avoir à trier pas specifications de produits mais bien par usage. Certaines solutions de mapping par logiques sémantiques commencent à voir le jour, mais elles nécessitent encore beaucoup de traitements à postériori (principalement du contrôle).

    Effectivement, les crawlers sont une pistes, mais malheureusement, je n’en ai vu l’efficacité que sur des flux de données intègres. nous avions une techno via les US il y a qq années de ce type, héritée du rachat de mySimon.com à l’époque. Elle était effectivement très flexible à la limite près que si le site changeait sa structure, il fallait réécrire les logiques… Je crois qu’elle est toujours utilisée mais détournée de son utilisation première, comme base pour récupérer et normaliser les données, afin d’intégrer des flux « secure » dans les systèmes d’information.

    En tous cas, les petits malins qui feront sauter ce verrou auront de l’or dans les mains, car cela ouvrirait des perspectives intéressantes, et pas que dans le périmètre du e-commerce 🙂

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s