Google utilise-t-il les statistiques comportementales dans le ranking des apps mobiles ?

Mathieu Chartier SEO 0 commentaire

Le 19 novembre 2015, Barry Schwartz du site Search Engine Land a rédigé un long article pour expliquer comment Google peut améliorer le positionnement des applications mobiles en termes de SEO. Il est vrai que les critères de ranking diffèrent entre les pages web classiques et les apps mobiles.

Il a surtout évoqué le critère comportemental et les analyses statistiques des utilisateurs comme un fait potentiellement utilisé par Google pour classer les applications et les liens profonds dans les SERP. Après de nombreux échanges avec d'autres SEO, il a donc réexpliqué sa position à ce sujet le 20 novembre 2015 sur Search Engine Roundtable. En effet, il semblerait à juste titre que Google utilise quelques informations comportementales des usagers pour le ranking, notamment le temps passé et le nombre de clics effectués dans les applications mobiles.

Barry Schwartz n'a pas fondé ses idées sur son intuition, mais sur ses échanges avec Rajan Patel, un statisticien bien placé de l'équipe Quality Search de Google. Ce dernier lui a confirmé que Google utilise un robot pour crawler les applications mobiles, c'est d'ailleurs celui-ci qui est utilisé lorsque nous téléchargeons une app mobile dans l'outil "Explorer comme Google" de la Google Search Console. Cet app crawler permet aussi de mieux évaluer les applications et de détecter les éventuels spams ou techniques de cloaking. Le porte-parole du jour a d'ailleurs indiqué qu'un spam au niveau des titres et descriptions d'applications (récupérées via l'App Indexing notamment) pouvait fortement être sanctionné, Google a donc pensé à tout... :D

Rajan Patel a également indiqué que Google ne pouvait pas utilisé la plupart de ses algorithmes habituels dans les apps mobiles, comme le PageRank par exemple, car le linking ne s'utilise pas dans ce monde à part. De fait, il a précisé que Google utilise des "datas" provenant de l'API App Indexing pour positionner les liens profonds dans les SERP du mieux possible. Si nous faisons le détail des données, cela est donc très vite vu puisque les développeurs peuvent indiquer uniquement un titre et une description (optionnelle), en plus du contenu des pages.

Le "title" et la description (optionnelle) sont récupérés pour chaque lien profond dans l'App Indexing, mais cela ne peut pas suffire pour positionner parfaitement les liens dans les SERP. C'est là que l'idée des "datas" évoquée par Rajan Patel prend tout son sens. En effet, l'usage de l'API App Indexing oblige les développeurs à rajouter le début et la fin des "Actions" (class Java de l'API), de cette façon :

  • AppIndex.AppIndexApi.start(client, viewAction) marque le début des actions en cours.
  • AppIndex.AppIndexApi.end(client, viewAction) marque la fin des actions précédemment réalisées.

Ces deux événements Java permettent donc de récupérer des données statistiques des usagers, comme le taux de clics, la durée des visites, le nombre de pages vues dans l'application... Essentiellement, cela permet de récupérer le temps passé dans l'application, mais nous pouvons imaginer bien d'autres aspects. Personne n'a confirmé cet état de fait, mais le mot "datas" employé par Rajan Patel a peu de chance de se limiter uniquement aux "title" et "description" de l'App Indexing, les statistiques comportementales sont donc fortement envisageables dans la liste des critères de ranking des applications mobiles...

Le contexte sémantique comme critère de ranking des apps mobiles ?

Je me suis souvent demandé si le contexte sémantique des pages d'applications mobiles était pris en compte. En effet, l'App Indexing permettait uniquement de fournir à Google des liens profonds ayant des équivalences avec des pages web existantes à l'origine, donc je pensais que Google pouvait éventuellement utiliser les liaisons sémantiques entre les deux entités pour favoriser le ranking. Maintenant, comme les liens profonds n'ont pas forcément de correspondances, je doute davantage de ce type de signal utilisé par Google, mais une variante existe peut-être...