Note: Descriptions are shown in the official language in which they were submitted.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
1
Système de traitement de données de connexion à une
plateforme d'un site internet
DOMAINE TECHNIQUE GENERAL
La présente invention concerne le domaine de l'analyse de données
utilisateur pour le e-commerce.
Plus précisément elle concerne un système de traitement de
données de connexion à une plateforme d'un site Internet, le procédé étant
dédié notamment aux traitements statistiques, au forage de données
("datamining" dans la terminologie anglo-saxonne), à la conception d'outils
d'aide à la décision, aux diagnostics, à la prévision ou à l'approximation, à
la conception de simulateurs, de systèmes d'apprentissage automatique ou
d'aide à l'apprentissage et d'une manière générale à la conception de
systèmes d'analyse de situations ou analyse situationnelle.
ETAT DE L'ART
Le développement d'internet a entrainé l'essor du commerce en
ligne, ou e-commerce . De nombreux services allant de la vente de
produits à la mise en relation d'utilisateurs en passant par la banque ou la
presse sont ainsi proposés sur les réseaux.
Le e-commerce a entraîné dans son sillage l'apparition du e-
business , c'est-à-dire tout ce qui peut être mis en oeuvre en amont pour
concrétiser une transaction et par la suite assurer la fidélisation client, en
particulier le marketing électronique.
En effet, bien que la vente en ligne permette théoriquement la
personnalisation à l'extrême de la relation-client, l'anonymat qui règne sur
Internet empêche l'application des règles marketing traditionnelles, qui sont
basées sur le ciblage et la différentiation des clients.
Comprendre l'internaute est donc essentiel. Certains acteurs du e-
commerce proposent ainsi à leurs client de remplir des profils permettant de
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
2
mieux les identifier, ce afin de leur offrir une approche personnalisée,
comme le ferait un vendeur dans un magasin. Cette solution est toutefois
contraignante pour l'internaute, lequel est en outre souvent réticent à
donner des informations personnelles.
Des techniques connues proposent la collecte de données
comportementales de l'internaute, par exemple via le contenu de son
historique, afin de mieux l'identifier et de personnaliser les contenus en
particulier publicitaire qu'il reçoit. Ces techniques n'apportent toutefois
qu'une compréhension partielle de l'internaute, et ne permettent d'en
déduire que peu d'informations.
La présente invention propose un système de traitement de données
de connexion alternatif qui, par une architecture inédite, permet de
déterminer de situations d'utilisateurs connectés à la plateforme d'un site
Internet, puis de les analyser pour obtenir des données et prédire d'autres
situations, sans être dépendant d'un modèle ou d'une structure
d'implémentation physique ou logique.
PRESENTATION DE L'INVENTION
La présente invention propose un système de traitement de données
de connexion à une plateforme d'un site Internet, caractérisé en ce qu'il
comprend :
- au moins deux modules indépendants de traitement de données de
connexion, les modules de traitement étant répartis en moins deux
groupes complémentaires, les modules d'un groupe étant configurés
pour mettre en oeuvre un sous-ensemble des opérations nécessaires
pour l'exécution d'un procédé de traitement des données de
connexion d'un utilisateur via un équipement à ladite plateforme
comprenant l'identification d'une situation de l'utilisateur, les modules
de traitement de chaque groupe recevant des données issues des
modules de traitement d'un autre groupe de sorte à compléter la
totalité du procédé de traitement de données de connexion ;
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
3
- un module répartiteur qui reçoit lesdites données de connexion et les
transmet aux modules de traitement ;
- un module réconciliateur qui collecte les données issues des
modules de traitement et délivre des données traitées de connexion
à ladite plateforme et/ou à l'équipement de l'utilisateur.
Selon d'autres caractéristiques avantageuses et non limitatives de
l'invention :
= les différents modules s'échangent des données sous la forme de flux
XML ;
= les modules de traitement d'un groupe mettent en oeuvre les opérations
en temps réel, et les modules d'un autre groupe mettent en oeuvre les
opérations différées ;
= les modules de traitement d'un groupe sont des modules de pré-
traitement configurés pour identifier les situations d'utilisateurs connectés
à
ladite plateforme, et les modules de traitement d'un autre groupe sont des
modules de post-traitement configurés pour traiter des situations identifiées
d'utilisateurs connectés ;
= le ou les modules de pré-traitement collectent des données issus du ou
des modules de post-traitement de sorte à influer sur l'identification des
situations ;
= les modules de traitement de chaque groupe mettent en oeuvre le
procédé de traitement spécifiquement pour les utilisateurs naviguant sur les
pages du site internet relatives à une ou plusieurs lignes de services
données ;
= les modules de traitement sont connectés à une bibliothèque de
moteurs situationnels exécutables et/ou à une base de données contenant
une ontologie caractéristique dudit site internet.
BREVE DESCRIPTION DES FIGURES
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
4
D'autres caractéristiques et avantages de la présente invention
apparaîtront à la lecture de la description qui va suivre d'un mode de
réalisation préférentiel. Cette description sera donnée en référence aux
dessins annexés dans lesquels :
- la figure 1 est un schéma d'une architecture réseau dans laquelle
s'inscrit l'invention ;
- la figure 2 est un diagramme représentant schématiquement les
étapes du procédé de traitement de données de connexion selon
l'invention ;
- la figure 3 est un schéma d'un mode de réalisation d'un système
de traitement de données de connexion selon l'invention ;
- la figure 4 représente un module de traitement d'un système de
traitement de données de connexion selon l'invention ;
- la figure 5 est un schéma d'un module de traitement immédiat
d'un mode de réalisation d'un système de traitement de données
de connexion selon l'invention ;
- la figure 6 est un schéma d'un module de traitement différé d'un
mode de réalisation d'un système de traitement de données de
connexion selon l'invention.
DESCRIPTION DETAILLEE D'UN MODE DE REALISATION PREFERE
Situations
Contrairement à tous les procédés de traitement connus, le procédé
de traitement de données selon l'invention est basé comme mentionné
précédemment sur l'analyse de situations complètes, et non sur une
simple liste de paramètres.
Dans la suite de la présente description, on décrira plus
particulièrement l'application du procédé au domaine mentionné
précédemment du e-commerce (dans ce cas lesdites données sont des
données de connexion à une plateforme d'un site Internet), mais on
comprendra qu'il peut être transposé au traitement de données utilisateur
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
de façon générale sur un poste de travail. Les données peuvent en effet
être les e-mails de l'utilisateur, ses paramètres système, etc. Le traitement
de données de connexion donne d'excellents résultats en terme
d'identification de situation grâce au volume et à la diversité de telles
5 données.
On entend ici par "situation" d'un utilisateur une information plus ou
moins complexe et plus ou moins floue décrivant les notions d'ordre
psychologique, sociologique de l'utilisateur et sa scène situationnelle
(l'ensemble des situations des autres utilisateurs connectés). Une situation
peut être nommée par un terme porteur de sens pour le e-commerçant,
comme par exemple butineuse de l'après-midi pour désigner des
femmes qui surfent sur internet après déjeuner sans idées préconçues.
L'analyse situationnelle ouvre ainsi de grandes perspectives dans de
nombreux domaines économiques utilisant des outils d'analyse, de
prédiction et de simulation. Des processeurs d'analyse situationnelle (voir
par exemple la demande de brevet français FR2962823) sont capables de
façon autonome de recevoir en entrée un ou plusieurs flux situationnels,
d'en extraire des situations, de distinguer les éléments importants et de leur
appliquer en continu des traitements, de détecter des phénomènes et de
prévoir des évolutions de solutions, notamment par induction.
Les avantages sont multiples : comme on va le voir les systèmes
situationnels ne sont pas contraints par des modèles ou des architectures
d'implémentation, et s'adaptent donc en permanence. Ils sont capable, à
l'instar du cerveau humain, de se concentrer sur l'essentiel en gérant leurs
ressources. Enfin, leurs possibilités apparaissent bien plus universelles que
celles de n'importe quel système expert actuel, cloisonné dans un domaine
particulier.
Le principe du procédé de traitement de données (le traitement étant
réalisé par un serveur comprenant au moins une unité de traitement de
données et des moyens de stockage de données, le serveur étant dans le
cas du traitement de données de connexion à une plateforme d'un site
Internet en connexion réseau avec ladite plateforme) selon l'invention est
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
6
ainsi d'identifier par un premier mécanisme la situation d'un ou plusieurs
utilisateurs, puis de traiter par un deuxième mécanisme les situations
collectés dans une deuxième temps. Les utilisateurs concernés sont dans le
cas du-e-commerce des utilisateurs connectés à ladite plateforme via un
équipement, voire tous les internautes visiteurs si les ressources du serveur
le permettent (voir plus loin).
Ce traitement peut avoir plusieurs destinataires et de nombreuses
finalités, comme il sera également expliqué plus loin.
La figure 1 représente l'architecture réseau dans laquelle l'invention
s'inscrit. Un équipement 3 (on comprendra qu'il peut s'agit de toute sorte
d'équipement informatique sur lequel un utilisateur peut accéder à Internet,
du poste de travail au terminal mobile tel qu'un smartphone ou une tablette
tactile) est connecté à la plateforme 2 d'un site internet via le réseau
internet 4. Le serveur 1 comprenant au moins une unité de traitement de
données et des moyens de stockage de données pour la mise en oeuvre du
procédé est en connexion réseau avec ladite plateforme 2.
Il est important de comprendre que le terme plateforme désigne
un ou plusieurs serveurs interconnectés du site internet sur lequel sont
hébergées la ou les pages de site internet que l'utilisateur est en train de
consulter. Le serveur 1 qui réalise le traitement peut être l'un de ces
serveurs qui composent la plateforme 2. L'équipement utilisateur 3 est dans
tous les connecté directement ou indirectement (via la plateforme 2) à
travers le réseau internet au serveur 1 qui met qui en oeuvre le procédé. Il
est à noter que la connexion entre le serveur de traitement 1 et la
plateforme 2 peut être locale, mais alternativement rien n'interdit qu'elle
repasse par le réseau internet 4.
Premier mécanisme : Identification d'une situation
Comme le montre la figure 2, l'identification de la situation d'un
utilisateur connecté à ladite plateforme se fait parmi une liste de situations
de référence, lesquelles peuvent être soit prédéfinies à partir de
l'observation des comportements des internautes, soit de façon
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
7
particulièrement avantageuse automatiquement générées par un autre
mécanisme qui sera décrit plus loin.
Pour ce faire, le mécanisme d'identification de situation du procédé
selon l'invention utilise des déclencheurs . Les déclencheurs, mieux
connus sous l'appellation anglo-saxonne triggers , sont des modules
logiciels qui sont aptes à s'activer et provoquer un traitement particulier en
fonction d'événements prédéfinis.
Les triggers peuvent être de nombreux types. Dans un premier type,
l'évènement est une action de l'internaute comme un clic de consultation,
un clic de sélection, etc. Dans un second type l'évènement est l'expiration
d'un délai, par exemple après la dernière visite de l'internaute, ou par
rapport à la précédente activation du trigger (dans ce dernier cas il s'active
à une fréquence fixe, par exemple toutes les heures). On comprendra que
de nombreuses autres configurations sont possibles.
A l'activation d'un trigger donné, les moyens de traitement de
données du serveur 1 déclenchent une tentative de détermination de l'état
d'au moins un indice . Les indices sont divers éléments porteurs de
signification pour une situation. Certains indices concernent la scène
situationnelle , c'est-à-dire l'ensemble ou un sous-ensemble des situations
des internautes connectés qui se déroulent concomitamment. Il s'agit par
exemple de l'heure, de la météo, etc. Alternativement, certains indices
concernent la sphère situationnelle , c'est-à-dire la situation
particulière
de l'internaute. Il s'agit alors par exemple de l'âge, le genre, la taille de
l'internaute, sa navigation (rapide, hésitante, etc.) son état (pressé, en
recherche, etc.). Les indices sont donc relatifs à des données personnelles
dudit utilisateur connecté à la plateforme 2 et/ou relatifs à des données
générales. La combinaison de ces deux zones situationnelles offre en
pratique de bons résultats pour la détermination fiable de la situation d'un
utilisateur.
Naturellement, certains indices relatifs à des résultats espérés (par
exemple la conclusion ou non d'une transaction) sont spécialement
impliqués, en particulier en vue de l'analyse des situations.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
8
La ou les unités de traitement du serveur 1 disposent ainsi d'une
collection d'indices observables prédéterminée. Il est à noter qu'observable
ne signifie pas forcément déterminable. Une tentative de détermination de
l'état d'un indice peut ne pas être fructueuse. Par exemple l'âge de
l'internaute n'est pas forcément accessible. L'indice est alors considéré
comme indiscernable . Il n'est toutefois pas exclu qu'une tentative
ultérieure (via le même trigger ou un autre) soit cette fois couronnée de
succès.
Une liste des indices à tenter de déterminer est associée à chaque
trigger. Si ce trigger est activé, ce seront ces indices et seulement ces
indices dont l'état sera observé. A titre d'exemple, un trigger périodique
pourra tenter de déterminer la météo ou le nombre de clics par seconde de
l'utilisateur. Alternativement, un trigger lié au clic sur le bouton envoyer
à la fin d'un formulaire pourra tenter de déterminer l'âge et le genre de
l'utilisateur en fonction du texte saisi.
En fonction des résultats de ladite tentative de détermination de l'état
d'au moins un indice, la ou les unités de traitement génèrent et stockent sur
les moyens de stockage du serveur 1 une signature situationnelle de
l'utilisateur (si une situation situationnelle existe déjà, elle est seulement
mise à jour).
La signature situationnelle d'un utilisateur correspond à l'ensemble
des données relatives aux indices, lesquelles permettent de caractériser la
situation de l'utilisateur.
Avantageusement, une signature situationnelle est en particulier
composée d'une pluralité d'unités d'information chacune étant associée à
un indice (avantageusement on trouve deux parties dans une signature
situationnelle, les unités étant appelées respectivement thresholds si
l'indice associé est relatif à la scène situationnelle, et trackers si
l'indice
associé est relatif à la sphère situationnelle), chaque unité d'information
pouvant prendre au moins trois valeurs dont une première valeur si l'état
déterminé de l'indice associé correspond à un état de référence (valeur
1 ), une deuxième valeur si l'état déterminé de l'indice associé ne
correspond pas à l'état de référence (valeur O ), et une troisième valeur
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
9
(valeur X ) si l'état de l'indice associé n'a pas pu être déterminé (que ce
soit parce qu'aucune tentative de détermination n'a été faite pour l'indice
associé, ou parce que la tentative qui a suivi le déclenchement du trigger
n'a pas réussi). Chaque unité d'information est alors un bit à trois
valeurs.
On comprendra que les notations 0, 1 et X sont purement illustratives
et que l'homme du métier pourra choisir la représentation de données de
son choix. En particulier, on peut envisager utiliser des unités d'information
n'ayant pas un nombre déterminé de valeurs et aptes à stocker par exemple
des nombres, des chaines de caractère, etc. On verra toutefois plus loin
l'intérêt d'avoir des unités d'information à n états. En utilisant la notation
définie précédemment, 1X10 01XX est un exemple de signature
situationnelle à 8 unités d'information.
On note en outre que bien qu'ici on ne distingue pas les cas
aucune détermination tentée / détermination tentée mais
infructueuse (même valeur X ), l'information selon laquelle une
détermination a été tentée peut être alternativement prise en compte. En
effet, bien que l'information que constitue l'état de l'indice n'ait pas pu
être
obtenue, le fait que la tentative ait échoué peut être porteur d'information.
Par exemple cela peut signifier que l'utilisateur a volontairement (voire
involontairement) occulté des pans de son profil et donc qu'il peut être
quelqu'un cherchant à augmenter sa confidentialité internet.
Il est à noter que certains trackers ou thresholds peuvent s'appuyer
sur des intégrateurs de loi de distribution, par exemple de gauss ou de
poisson, afin de leur conférer un caractère rémanent. En d'autres termes,
les intégrateurs prévoient l'état que doit avoir l'indice en fonction des
précédentes observations, ce qui évite à court terme la nécessité de
redéclencher une tentative de détermination lorsque la précédente s'est
faite il y a peu.
La signature situationnelle de l'utilisateur est alors comparée avec
une pluralité de masques . Chaque masque est associé à une situation
de référence, et correspond à un espace de signatures situationnelles. Pour
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
cela, chaque masque est constitué comme une signature d'une pluralité
d'unités d'informations, pouvant prendre les valeurs 0, 1, X, mais aussi une
quatrième valeur (notée A ) si l'unité d'information peut être quelconque.
L'état de certains indices n'est en effet pas caractéristique de certaines
5 situations.
Par exemple 10A0 AAX1 est un masque à 8 unités d'information qui
regroupe les signatures suivantes : 1000 00X1, 1000 01X1, 1000 0XX1,
1000 10X1, 1000 11X1, 1000 1XX1, 1000 X0X1, 1000 X1X1, 1000 XXXI,
1010 00X1, 1010 01X1, 1000 OXX1, 1010 10X1, 1010 11X1, 1010 1XX1,
10 1010 X0X1, 1010 X1X1, 1010 XXXI, 10X0 00X1, 10X0 01X1, 10X0 OXX1,
10X0 10X1, 10X0 11X1, 10X0 1XX1, 10X0 X0X1, 10X0 X1X1, 10X0 XXXI.
La comparaison entre la signature et un masque se fait alors
facilement grâce à des portes logiques (on compare chaque unité du
masque n'ayant pas pour valeur A avec l'unité correspondante sur la
signature grâce à XOR, et on applique AND sur les résultats de ces
comparaisons). Lorsqu'un masque correspond, on identifie la situation dudit
utilisateur connecté à la plateforme 2 comme étant la situation de référence
associée à l'au moins un masque contenant ladite signature situationnelle.
Il est à noter qu'une pluralité de masques est avantageusement
stockée sur les moyens de stockage du serveur 1, et qu'il n'est pas
impossible que certains des masques aient des portées qui se recoupent,
en d'autres termes qu'il n'y ait pas unicité du masque correspondant à une
situation donnée. Pour résoudre cette difficulté, les masques sont
avantageusement testés itérativement selon un roulement : si le test est
positif, la situation de référence associée au masque est retenue, sinon le
masque suivant est testé. Lorsqu'un nouveau trigger est activé, le même
masque de situation est retesté en premier afin de maintenir si possible la
stabilité de la situation actuelle.
A l'issue de cette première phase du procédé, on dispose donc d'une
situation identifiée comme étant la situation de l'utilisateur.
Deuxième mécanisme : Traitement de la situation
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
11
Le deuxième mécanisme du procédé selon l'invention consiste en
une analyse de la situation identifiée de l'utilisateur par des moyens
physiques ou logiques d'analyse situationnelle du serveur 1 de sorte à
obtenir des données traitées, qui vont être porteuses de sens pour
l'utilisateur, un gestionnaire du site internet, etc. Les moyens d'analyse
situationnelle peuvent consister en une application exécutée par les moyens
de traitement de données du serveur 1 (on peut envisager un processeur
multi-coeur dont des coeurs sont dédiés à cette analyse situationnelle, voir
plus loin).
Pour cela, chaque situation de référence est associée à au moins
une stratégie (avantageusement 1 à 3), c'est-à-dire un ensemble
composé d'un ou plusieurs moteurs situationnels (ainsi que les éventuels
paramètres de ces moteurs) et de contenus de messages, c'est-à-dire des
textes, des contenus graphiques (incluant des images, des vidéos, etc.),
des liens URL (Uniform Resource Locator), des éléments de forme (format,
paramètres de police, etc.), et tout autre donnée utile à la personnalisation
d'un message. Par message (également appelé recommandation) on
entend toute forme de communication résultant du traitement des données
de connexion et ayant un effet escompté sur la situation.
Tout à fait classiquement, il peut s'agir de messages de compte-
rendu adressés au gestionnaire du site (sous la forme de mails par
exemple), mais il peut s'agir surtout de messages destinés à l'utilisateur
dont la situation est en cours de traitement. Par exemple, ce peut être un
bandeau qui s'affiche la page internet qu'il consulte, un mail, un SMS, etc.
Le ou les moteurs situationnels sont des éléments logiciels choisis
parmi une bibliothèque de moteurs situationnels. Chaque moteur
situationnel est ainsi apte à mettre en oeuvre un traitement donné sur une
situation d'un utilisateur (le moteur prend en compte des paramètres de
toute la scène et la sphère situationnelles : en effet, si la signature
situationnelle d'un utilisateur est unique, la situation identifiée ne l'est
pas.
La prise en compte des unités d'information, c'est-à-dire des états des
indices observés, permet de personnaliser le traitement) de sorte à obtenir
un ou plusieurs messages ayant un effet escompté sur la situation.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
12
Un premier exemple de moteur peut mettre en oeuvre une
recommandation d'un ou plusieurs produits connexes à ceux visités (on
oriente vers les situations du magasin). Un deuxième exemple de moteur
peut mettre en oeuvre une recommandation de produits achetés par des
internautes dans une situation similaire à la situation identifiée de
l'utilisateur (on est au niveau personnel). Dans un troisième exemple de
moteur, on peut tout simplement recommander des produits à la mode
(détection d'une hausse des ventes significatives, on est au niveau de la
sociologie de groupe).
Il est à noter qu'une même stratégie peut être associée à plusieurs
situations et que chaque stratégie peut relever d'un niveau
d'essentialité , c'est-à-dire un critère de priorité qui peut être important
en cas de forte affluence d'utilisateurs.
Pour au moins une des stratégies associées avec ladite situation
identifiée (on peut les analyser par ordre d'essentialité), les moyens de
traitement du serveur 1 mettent en oeuvre les moteurs situationnels
associés de sorte à obtenir au moins une pile de messages.
Avantageusement, on génère au moins deux piles de messages
(avantageusement trois), chacun étant associée à un niveau de
confidentialité. Par niveau de confidentialité on entend le niveau de
publicité
du message. Par exemple, dans une mise en oeuvre du procédé à deux
niveaux de confidentialité, le niveau 1 correspond à des messages
personnels, alors que le niveau 2 correspond à des messages globaux (par
exemple un bandeau sur le site). Les trois exemples de moteurs décrits
précédemment correspondent à trois niveaux de confidentialités distincts :
le premier présente un niveau de confidentialité faible , puisqu'il est
destiné à tout utilisateur ; Le deuxième présente un niveau de confidentialité
élevé , puisque la recommandation est personnelle, et n'est donc
destinée qu'a l'utilisateur. Le troisième correspond à un niveau de
confidentialité moyen , puisque l'exposition se fait au niveau du groupe.
Les trois recommandations produites par ces trois moteurs se
retrouveraient donc dans trois piles différentes.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
13
Ces piles de messages sont alors dépilées pour exposer les
messages, c'est-à-dire les transmettre à leur destinataire. Plus précisément,
cela consiste à envoyer à destination (selon le cas) de l'équipement 3 dudit
utilisateur et/ou de la plateforme 2 (quand il s'agit d'éléments de pages) un
sous-ensemble des messages de ladite au moins une pile de messages.
Ce peut être fait via une simple politique LIFO (Last In First Out,
Dernier Entré, Premier Sorti ), mais avantageusement une stratégie dite
à jetons est mise en oeuvre. Dans cette stratégie, la page courante
comprend des zones d'exposition aptes à recevoir un message dans un
format donné et présentant des paramètres donnés. Les zones, lorsqu'elles
sont disponibles, émettent un jeton comprenant les différents paramètres de
la zone. Un moteur situationnel reçoit le jeton et constitue sur
commande un ou plusieurs messages en fonction de ces paramètres. Les
messages disposant du jeton sont alors extraits de la pile avant les autres.
L'exposition du ou des messages affecte la situation (par exemple en
provoquant une transaction si elle a eu l'impact escompté sur l'utilisateur),
ce qui a des chances d'activer de nouveaux triggers et d'entraîner le
changement de la situation dans laquelle se trouve l'utilisateur. Le procédé
est ainsi relancé et l'effet des messages sera observé au prochain cycle
d'analyse.
Optimisation des capacités de traitement
L'activité des internautes n'est pas constante au cours de la journée,
et en particulier à des périodes de pics les moyens de traitement de
données du serveur 1 peuvent avoir des difficultés à faire face à l'afflux
d'information (en d'autres termes le volume du flux à traiter).
Avantageusement le système tient compte de ces variabilités du
trafic et régule le procédé. En particulier, le procédé mobilise
avantageusement les ressources nécessaires pour identifier les situations
de tous les utilisateurs connectés (la première partie du procédé est moins
consommatrice de ressources que la seconde), mais n'en analyse qu'une
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
14
partie selon les capacités disponibles, triés en particulier sur le niveau
d'essentialité des stratégies mentionné précédemment.
Pour cela, trois niveaux graduels d'activité sont définis (ici appelés
alphafloor , betafloor et gammafloor ), le fonctionnement passant
dans un mode dégradé (on laisse tomber certaines situations au-delà d'un
seuil) ou différé (des situations jugées intéressantes ne sont pas traités
tout
de suite à cause de l'engorgement, mais le seront plus tard lorsque l'activité
sera plus faible). La précision de l'analyse d'une situation peut également
varier en fonction du niveau d'activité : si les ressources manquent on va à
l'essentiel (mode essentiellement déductif), et sinon on réalise une analyse
précise (mode essentiellement inductif) pour lequel on a plus de réflexe.
Dans le cas d'une semi ou non supervisé (voir plus loin), en cas de
ressources disponibles on favorise l'apprentissage.
Les trois niveaux précédents sont définis en fonction des niveaux
d'activité typiques sur le site en nombre d'actions par seconde.
L'alphafloor correspond à un niveau d'activité élevé . Par exemple
sur un site où l'on observe jusqu'à 1000 connexions simultanée, en
supposant qu'un utilisateur produit un clic (ou tout autre action comme une
saisie) toutes les 10 secondes en moyenne, l'alphafloor est à 100 Hz.
Le betafloor correspond à un niveau d'activité moyen . Par
exemple si sur le même site on observe 100000 connexions par jour et on
constate qu'un internaute reste 1 min 30 secondes en moyenne, le betafloor
est à 10,4 Hz.
Le gammafloor correspond à un niveau d'activité faible . Par
exemple, si on observe sur le site un ratio de 1 à 100 entre le maximum et
le minimum de connexions simultanées sur une journée (soir un minimum
de 10 connexions simultanées à 9 secondes par clic), le gammafloor est à
1,11 Hz.
Dans le cas inverse (plus de capacités de traitement disponibles que
nécessaire), le procédé peut utiliser des Shadows , c'est-à-dire maintenir
des situations rémanentes d'anciens utilisateurs, afin d'augmenter la base
d'apprentissage.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
Modes semi-supervisé et non-supervisé
Le procédé nécessite un ensemble de situations de référence pour
5 fonctionner, mais cet ensemble n'est pas figé et peut évoluer. En
particulier,
les stratégies peuvent comporter des moteurs situationnels configurés pour
que des messages soient émis pour signaler en particulier à destinataire
d'un gestionnaire du site l'émergence d'une nouvelle situation. Le
gestionnaire peut décider d'en faire une nouvelle situation de référence.
10 Dans un mode semi-supervisé, le système suggère au gestionnaire
de nouvelles situations de référence (associées à un masque prédéterminé
par le moteur situationnel), et ce dernier peut valider ou non ces
propositions. Alternativement, dans un mode non-supervisé (tel que celui
représenté par la figure 2), le système est complètement automatique et
15 inclut de lui-même les nouvelles situations de référence.
Il est à noter que l'observe l'apparition de nouvelles situations par
bourgeonnement . En d'autres termes, ce que les moteurs détectent est
l'émergence d'une sous-catégorie d'une situation large (par exemple si une
part non négligeables des signatures situationnelles correspondant à une
situation de référence s'avèrent présenter des états identiques pour des
indices qui étaient classés A , c'est-à-dire non pris en compte dans le
masque). Alternativement, pour une situation de référence donnée, on peut
tenter de sélectionner les situations qui ont débouché sur une transaction,
afin de détecter les messages efficaces.
Processeurs reflexes
Selon un deuxième aspect, l'invention concerne un système 1, en
particulier un serveur 1 comprenant au moins une unité de traitement de
données et des moyens de stockage de données, ladite au moins une unité
de traitement étant configurée pour la mise en oeuvre du procédé selon le
premier aspect lors de la connexion d'un utilisateur à une plateforme 2 d'un
site via un équipement 3.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
16
Comme l'on a expliqué, le plus souvent le procédé est mis en oeuvre
par un serveur du site qui est distinct des serveurs qui composent la
plateforme 2 (c'est-à-dire les serveurs qui hébergent les pages du site et
gèrent le fonctionnement du site), l'équipement 3 de l'utilisateur étant alors
connecté audit serveur pour la mise en oeuvre du procédé via la plateforme
2.
De façon particulièrement préféré, le deuxième aspect de l'invention
concerne un système 1 de traitement de données de connexion à une
plateforme 2 d'un site Internet dont un mode de réalisation particulièrement
préféré est représenté sur la figure 3. Ce système comprend
- au moins deux modules indépendants 21, 22 de traitement de
données de connexion (modules SALI2 dont SALIX et SALIC
sont deux versions), les modules de traitement 21, 22 étant répartis
en moins deux groupes complémentaires, les modules 21, 22 d'un
groupe étant configurés pour mettre en oeuvre un sous-ensemble
des opérations nécessaires pour l'exécution d'un procédé de
traitement des données de connexion d'un utilisateur à ladite
plateforme 2 comprenant l'identification d'une situation de
l'utilisateur, les modules de traitement 21 de chaque groupe recevant
des données issues des modules de traitement 22 d'un autre groupe
de sorte à compléter la totalité du procédé de traitement de données
de connexion ;
- un module répartiteur 10 ( RENZO ) qui reçoit lesdites données de
connexion et les transmet aux modules de traitement 21, 22;
- un module réconciliateur 30 ( RENALDO ) qui collecte les données
issues des modules de traitement 21, 22 et délivre des données
traitées de connexion à ladite plateforme 2.
Ces modules 10, 21, 22, 30 sont appelés des processeurs réflexes, à
cause de leur aptitude à traiter sans a priori les données en entrée.
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
17
Le principe est donc d'avoir deux (voire plus) groupes de n modules
21, 22, les modules 21, 22 d'un groupe effectuant en parallèle la même
tâche, et les tâches de chacun des groupes étant complémentaires pour
réaliser le traitement des données de connexion. Les différents modules 21,
22 peuvent être soit des processeurs physiquement indépendants (et reliés
par un bus), chacun disposant de ses moyens de traitement et de son
espace de stockage, ou alternativement des briques logicielles mises en
oeuvre sur un équipement donné, les modules partageant alors des mêmes
ressources processeur (éventuellement multi-coeur) et un même espace de
stockage. Il est à noter que le système 1 peut être réparti sur plusieurs
serveurs voire être installé en cloud-computing sur des machines virtuelles
Les modules 21, 22 s'échangent avantageusement des données sous la
forme d'un flux dans un langage d'abstraction, par exemple XML
(eXtensible Markup Language), JSON (JavaScript Object Notation), le
protocole SOAP (Simple Object Access Protocol), Silvia ou encore
Mawerick.
En référence à la figure 4 est représenté schématiquement un
module de traitement 21, 22 (indifféremment du groupe) de type SALI2.
Comme l'on voit, il possède avantageusement 7 ports d'entrée/sortie. Il est
en effet souhaitable que les modules 21, 22 soient connectés à une
bibliothèque de moteurs situationnels exécutables et/ou à une base de
données contenant une ontologie caractéristique dudit site internet afin de
pouvoir mettre en oeuvre les étapes de procédé précédemment expliquées.
En particulier :
- Le port OBS (observateur) reçoit les données en provenance de la
plateforme 2 sous forme de flux XML ;
- Le port COL (collecteur) reçoit les données en provenance des
autres modules de traitement 21, 22 SALI2 sous forme de flux XML ;
- Le port ONT (ontologie) reçoit l'ontologie sous forme de fichier XML ;
- Le port LIB (library) contient les bibliothèques de trackers, thresholds
et moteurs situationnels (exécutables) ;
- Le port EDI (éditeur) émet les données de sortie sous forme de flux
XML ;
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
18
- Le port DIF (diffuseur) émet les données à destination des modules
de traitement 21, 22 d'autres groupes sous forme de flux XML ;
- Le port MON (monitoring) émet des statistiques.
La répartition des tâches entre les groupes de modules 21, 22
permet une bien meilleure efficacité de traitement par la spécialisation des
modules 21, 22, et le fait que chaque groupe soit alimenté en données
assure comme on le voit sur la figure 3 un feedback . Les résultats d'une
partie du traitement permettent d'améliorer l'autre partie de traitement.
Plusieurs clés de répartitions possibles entre les groupes de modules de
traitement 21, 22 vont être décrites plus loin. Il est à noter qu'il est
possible
de combiner ces approches : le système 1 peut avoir deux groupes de
modules 21, 22 répartis selon une première loi, les modules 21, 22 d'un
groupe étant eux même répartis en deux sous-groupes selon une deuxième
loi.
Le travail de tri est effectué par le module répartiteur 10. Ce dernier
interprète chaque paquet d'information, et l'adresse aux modules de
traitement 21, 22 adéquats.
Le module réconciliateur 30 reçoit les flux relatifs à des messages à
envoyer en fonction des traitements effectués et s'occupe de la publication
de ces messages. Il recompose un flux global à destination de la plateforme
2 du site et/ou de l'équipement 3 de l'utilisateur.
Selon une première variante, les modules de traitement 21 d'un
groupe sont des modules de pré-traitement configurés pour identifier les
situations d'utilisateurs connectés à ladite plateforme 2, et les modules de
traitement 22 d'un autre groupe sont des modules de post-traitement
configurés pour traiter des situations identifiées d'utilisateurs connectés.
Dans cette configuration particulièrement avantageuse, on a
avantageusement un module de pré-traitement 21, et N modules de post-
traitement 22 (en particulier 4 ou 8, mais on comprendra qu'on n'est pas
limité à ce nombre et que l'on peut en avoir un nombre quelconque), car le
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
19
traitement des situations obtenues et l'envoi de messages et la partie la
plus consommatrice de ressources du procédé.
Le lien de feedback, que l'on voit sur la figure 2, permet que ou les
modules de pré-traitement 21 collectent des données issus du ou des
modules de post-traitement 22 de sorte à influer sur l'identification des
situations. Cela rend possible le mode non-supervisé évoqué
précédemment.
Selon une deuxième variante, les modules de traitement 21 d'un
groupe mettent en oeuvre les opérations en temps réel (les modules de
traitement immédiat ), et les modules 22 d'un autre groupe mettent en
oeuvre les opérations différées (modules de traitement différé ). En
d'autres termes, certains modules 21 exécutent des tâches nécessitant une
action immédiate (par exemple les déclencheurs en lien avec la navigation
des utilisateurs, l'envoi de messages à exposition immédiate), alors que les
autres modules 22 réalisent des tâches dont l'exécution peut être décalée
dans le temps. Les données sont stockées sur les moyens de stockage le
temps de pouvoir être traitées. Cette configuration facilite la rémanence des
informations et la prise en compte du passé, dans la mesure où à tout
instant les modules 21 temps réel reçoivent des données relatives à des
traitements réalisés en différé (qui sont donc le fruit de données de
connexion plus anciennes). La boucle de feedback permet ainsi aux
modules de traitement différé 22 de communiquer aux modules de
traitement immédiat 21 des grilles de traitement via lesquelles le
traitement immédiat est adapté. Cette configuration s'adapte en outre très
bien aux périodes de forte affluence en transférant des données de
traitement immédiat à traitement différé.
Il s'agit du système représenté sur la figure 3 : le SALIX est le
module de traitement différé 22, et les SALIC sont les modules de
traitement immédiat 21. Dans cette configuration particulièrement
avantageuse, on a avantageusement un module de traitement différé 22, et
N modules de traitement immédiat 21 (le traitement immédiat a la priorité, et
est plus consommateur puisque une certaine partie des traitements ne
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
peuvent être faits en différés). Dans une configuration à 4 modules de
traitement immédiat 21, on a alors au total 7 modules 10, 21, 22, 30, un
processeur octo-coeur est donc particulièrement préféré (le huitième coeur
gérant le reste des opérations systèmes).
5 Les
figures 5 et 6 représentent plus en détail respectivement un
module de traitement immédiat 21 de type SALIC et un module de
traitement différé 22 de type SALIX. Sur ces figures on voit les ports OBS,
COLL, EDI et DIF (les ports ONT, LIB et MON sont câblés de façon
similaire entre les deux types de module).
10 Un module
de traitement immédiat 21 SALIC s'occupe d'identifier
toutes les situations des utilisateurs (à réaliser en temps immédiat) via les
vecteurs de consultation, sélection, consommation (qui comprennent les
données observées pour déterminer les états des indices) reçus par le port
observateur.
15 Le port
diffuseur transmet les vecteurs au module de traitement
différé 22 SALIX. Le port collecteur réceptionne les vecteurs d'information
traitée en différé et les grilles en provenance du module de traitement
différé 22 SALIX.
Les trackers (ainsi que les thresholds) génèrent les signatures
20
situationnelles à partir des vecteurs et des grilles. Les moteurs
situationnels
temps réel associés aux stratégies des situations identifiées sont exécutés,
et les messages produits par l'exécution des moteurs envoyés via le port
éditeur.
Un module de traitement différé 22 SALIX s'occupe quant à lui des
traitements qui n'ont pas besoin d'être faits tout de suite. Le port
observateur reçoit exclusivement des données relatives aux services et aux
usagers administrateurs. Le port collecteur réceptionne les vecteurs en
provenance des modules de traitement immédiat 21 SALIC. Des moteurs
situationnels sont mis en oeuvre sous le contrôle d'un timer (minuteur) qui
définit à quel point le traitement est différé.
Ces moteurs produisent les messages différés (messages à
destination des utilisateurs étant envoyés quelques heures suivant sa visite
par exemple sous la forme d'un e-mail promotionnel l'incitant à revenir sur
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
21
le site) et les messages pour les administrateurs du site qui sont émis à
destination des supports adéquats via le port éditeur, ainsi que les grilles
de
traitement qui comme expliqué sont renvoyées (avec certains vecteurs) vers
les modules de traitement immédiat 21 SALIC via le port diffuseur.
Selon une troisième variante, chaque groupe de modules 21, 22
correspond à une ligne de services . Il s'agit d'une unité de base de
classification de produits au sein d'un site internet au sein du système dit
LSO pour Lignes/Services/Options. Une ligne de services regroupe
plusieurs services. Par exemple la catégorie Salon qui va regrouper des
services Tables , Meubles TV , Canapés , etc. dans un catalogue
de meubles est une ligne de services. De même, la catégorie Homme ,
ou Taille XL est une ligne de services d'un catalogue de vêtements. Sur
un site internet tel un site marchand, on note qu'il est possible de présenter
les mêmes produits sous plusieurs modes de classifications, il s'agit alors
de lignes de services différentes. Chaque service présente des options.
Dans l'exemple précédent, un service Pantalons d'une ligne Homme
contiendra une liste d'options qui sont autant de modèles de pantalons.
Chaque option présente un produit avec plusieurs variantes (taille, couleurs,
etc.) ; chaque produit est en effet unique (référence catalogue donné),
contrairement à l'option. Un même produit peut donc être présenté dans
plusieurs contextes LSO. Pour revenir à notre exemple, on peut retrouver le
même pantalon dans le service Pantalons homme de la ligne XL .
On peut ainsi envisager de séparer les modules de traitement 21, 22
par ligne de services, en particulier pour des sites présentant des produits
très divers pour lesquels les situations des utilisateurs vont être très
différentes. Il est à noter qu'il est courant pour des gros sites que
l'utilisateur
soit redirigé vers l'un ou l'autre des serveurs de la plateforme 2 selon la
ligne de services sur laquelle il navigue.
En outre, de façon avantageuse, on combine plusieurs de ces
variantes. En particulier, les modules de traitement immédiat 21 SALIC de
la deuxième variante peuvent être chacun dédié à une ou plusieurs lignes
de services. Dans ce cas, le module répartiteur 10 RENZO repartit le flux
CA 02880418 2015-01-28
WO 2014/020122
PCT/EP2013/066217
22
entrant en le dirigeant vers le module de traitement différé 22 SALIX s'il
s'agit de données d'administration ou vers un module de traitement
immédiat 21 SALIC s'il s'agit de données de navigation d'un utilisateur, en
fonction de la ligne de services dans laquelle il se trouve.
