FR3071086A1 - Un procede et systeme pour une offre adaptative intelligente dans un reseau d'echange en ligne automatise - Google Patents

Abstract

Un procédé en œuvre par ordinateur comprenant la réception, à partir d'un serveur d'échange de publicités, via un réseau de communication de données, d'un message comprenant une demande d'offre qui inclut des informations sur le site et des informations sur l'utilisateur liées à un encart publicitaire disponible. Pour chaque offre, dans la liste classée générée, une estimation de niveau d'offre de probabilité d'interaction de l'utilisateur avec l'offre est calculée. Pour une combinaison d'offres incluses dans la liste classée, un prix d'offre de niveau publicitaire est calculé, sur la base au moins des estimations de niveau d'offre calculées de probabilité d'interaction de l'utilisateur, des revenus d'interaction de niveau d'offre correspondants et d'un paramètre d'agressivité. Une réponse d'offre inclut une publicité à prix d'offre qui comprend la combinaison des offres et du prix d'offre de niveau publicitaire. Les modèles d'apprentissage automatique pour prédire le comportement des utilisateurs en ligne sont capables de déterminer automatiquement les estimations de probabilité d'interaction de l'utilisateur avec des éléments de contenu en ligne sur la base du comportement agrégé des utilisateurs antérieurs dans des contextes similaires.

Description

UN PROCÉDÉ ET SYSTÈME POUR UNE OFFRE ADAPTATIVE INTELLIGENTE DANS UN RÉSEAU D’ÉCHANGE EN LIGNE AUTOMATISE

DOMAINE DE L’INVENTION [0001] La présente invention concerne des systèmes d’offre automatisés et en particulier un procédé et système intelligents et adaptatifs pour générer un prix d’offre sur la base de prédictions du comportement d’interaction de l’utilisateur et d’un réglage d’agressivité variable. Des modes de réalisation de l’invention emploient des modèles d'apprentissage automatique pour prédire le comportement des utilisateurs en ligne et sont capables de déterminer automatiquement la probabilité de l'interaction de l'utilisateur avec les éléments de contenu en ligne sur la base d’un comportement agrégé d'utilisateurs antérieurs dans des contextes similaires. L’invention peut être appliquée dans des systèmes de publicité en ligne, par exemple pour déterminer un prix d’offre pour le placement d’une publicité à présenter à un utilisateur, par ex. via une page web ou dans une application mobile.

CONTEXTE DE L’INVENTION [0002] La publicité en ligne (par ex., basée sur le web, mobile ou dans l’application) diffère de la publicité dans les médias traditionnels en termes de ciblage personnalisé d’audience. Par exemple, tandis que la publicité multimédia de diffusion, telle que la publicité à la télévision, a pour but d’atteindre une caractéristique démographique cible définie par des caractéristiques larges telles qu’un groupe d’âge, un statut socio-économique et/ou des intérêts généraux, la publicité en ligne a pour but d’atteindre les individus ayant un intérêt particulier pour le produit, le service ou les informations qui sont présentées.

[0003] La technologie de ciblage d’audience hautement personnalisée a conduit au développement de modèles d’affaires qui sont spécifiques à la publicité en ligne. Par exemple, il est à présent commun pour tes sites Web qui fournissent des nouvelles, des informations agrégées et un autre contenu d’intérêt à des utilisateurs en particulier, d’héberger des publicités tierces comme moyen pour générer des revenus. Les annonceurs dont les publicités apparaissent sur ces sites Web peuvent payer l’opérateur sur la base de la vue d’opportunités ou d’impressions (communément mesurées en tant que « coût par mille impressions », c.-à-d. CFM), sur la base du coût par clic (CPC) ou selon une autre mesure de la performance. La sélection actuelle d'une publicité à placer sur une page Web présentée à un utilisateur individuel peut se baser, au moins en partie, sur un processus d’offre où un annonceur qui est disposé à payer un CPM, CPC ou autre mesure de coût plus élevé(e) est plus susceptible d’avoir sa publicité présentée à l’utilisateur.

[0004] Selon un modèle commun, le processus d’offre est facilité par une « plate-forme d’échange de publicités ». Un échange de publicités est une plateforme technologique qui met en œuvre une place de marché numérique permettant aux annonceurs et aux éditeurs de sites Web et autre contenu en ligne d’acheter et de vendre de l’espace publicitaire, souvent via des ventes aux enchères en temps réel. DoubleClick™ (détenue par Google™), AppNexus™, Microsoft™ Ad Exchange™ et OpenX™ sont des plates-formes d'échange de publicités connues.

[0005] Une plate-forme d’échange de publicités maintient un « ensemble » d’encarts publicitaires. Les éditeurs contribuent à leurs impressions de publicité, par exemple des encarts publicitaires intégrées dans des pages Web desservies à des utilisateurs, dans l'ensemble. Les acheteurs peuvent alors faire une offre pour les impressions qu’ils souhaitent acheter. Les décisions de soumission sont souvent prises en temps réel sur la base des informations telles que le comportement antérieur de l’utilisateur auquel une publicité est desservie, l’heure de la journée, le type d’appareil, la position de la publicité, etc. En pratique, ces décisions de soumission doivent elles-mêmes être prises très rapidement, par ex. en quelques dizaines de millisecondes tout au plus, à l’aide des plates-formes technologiques communément connues sous le nom de plates-formes côté demande (DSP). Puisque le coût réel pour l’annonceur existe fors de l’achat d’impressions via un échange de publicités, les performances des technologies et algorithmes déployés dans une DSP pour évaluer la «valeur» potentielle d’un utilisateur afin de prendre une décision d'offre peut avoir un aspect commercial important.

[0006] Dans une configuration typique, chaque demande d'offre reçue à une DSP d’un échange de publicité comprend des informations de niveau publicitaire en rapport avec un encart publicitaire disponible. Les informations de niveau publicitaire peuvent inclure la taille de l’encart (par ex. les dimensions en pixel), l’URL du site Internet, la position de l’encart sur la page Web, une clé d’identification d’encart publicitaire, etc. La demande d’offre peut également inclure des informations de contexte, tels que les informations du navigateur, 1e type dispositif utilisateur, etc. De plus, les informations de niveau utilisateur peuvent être disponibles, telles qu'un identifiant de cookie d’une visite antérieure, l’adresse IP, etc. Une DSP type peut recevoir plusieurs centaines de millions de demandes de ce type par jour. Par conséquent, la DSP doit être capable de traiter des milliers de demandes d’offre par seconde.

[0007] La réponse attendue de la DSP est un prix d’offre, dans une devise supportée par l’échange de publicité, pour chaque encart publicitaire proposé. Si la DSP est trop lente pour répondre, ou si elle propose un prix d’offre bas, elle peut être battue lors deToffre par une DSP concurrente. Elle perdra par conséquent l'opportunité de placer une publicité dans l’encart proposé. D’un autre côté, si la DSP répond rapidement avec un prix d’offre élevé, elle peut gagner l’opportunité de placer le contenu publicitaire sélectionné dans l’encart proposé. Cependant, pour que la DSP fonctionne en général avec succès, le prix d’offre doit être raisonnable, et le contenu publicitaire sélectionné doit être bien ciblé vers l’utilisateur final, afin d’assurer un taux de clics (CTR) suffisamment élevé. Si, par exemple, les offres placées par la DSP sont trop élevées et/ou le contenu publicitaire n’est pas bien ciblé vers les utilisateurs finaux, le revenu total généré par la DSP, donné par la somme du CPC payé par les annonceurs pour toutes les publicités cliquées, sera inférieur au coût de fonctionnement total qui inclut le coût pour l’opérateur de la DSP de toutes les offres réussies.

[0008] II existe par conséquent une exigence technique selon laquelle les procédés employés par la DSP sont à la fois précis et très rapides lors du calcul d’un prix d'offre.

[0009] Une autre complication arrive parce que chaque encart publicitaire peut éventuellement être peuplé par un nombre d’offres distinctes. Typiquement, un encart publicitaire comprend une « bannière », composée d’une région rectangulaire orientée horizontalement ou verticalement (en fonction de l’affichage sur une page web) et des offres distinctes peuvent être agencées selon un agencement de grille dans l’encart. Tandis que les offres peuvent toutes être liées à un intérêt d’utilisateur commun, chacune peut avoir des caractéristiques assez différentes. Par exemple, dans le contexte d’une publicité liée aux voyages, différentes offres dans un inventaire publicitaire peuvent se rapporter à l’hébergement, au dîner, à la location de voiture, aux surclassements de voyage, etc. Le revenu du CPC généré à partir d’un évènement d’interaction d’utilisateur (par ex., clic) peut être différent pour chaque offre dans l’encart publicitaire. Cependant, une DSP est requise pour répondre à une demande d’offre avec un prix d’offre correspondant au niveau de l’encart publicitaire.

[0010] Il est par conséquent souhaitable que les procédés employés par la DSP soient capables de calculer un prix d’offre de niveau publicitaire basé sur les probabilités de niveau d’offre d’interaction d’utilisateur.

[0011 ] Pourtant, un autre problème pour une DSP est que différentes campagnes menées par les acheteurs de publicité peuvent avoir des objectifs différents, et par conséquent des risques et des profils de coût différents. Par exempte, dans une campagne ciblant la croissance sur une part de marché, un annonceur peut être préparé à payer un CPC plus élevé, permettant à la DSP de prendre le risque de faire des offres plus élevées pour un CTR estimé donné.

Inversement, dans une campagne de faible valeur, la DSP peut être contrainte de faire une offre de manière très conservatrice, même si moins de trafic serait alors généré.

[0012] Il est par conséquent souhaitable que les procédés utilisés par la DSP soient configurables dynamiquement pour varier le degré d’« agressivité » lors du calcul du prix d’offre de niveau publicitaire.

[0013] Par conséquent, des modes de réalisation de la présente invention concernent l’adressage des caractéristiques souhaitables susmentionnées, c.-àd. le calcul des probabilités de niveau d’offre d’interaction et les prix d’offre de niveau publicitaire ainsi que la mise en œuvre d’une agressivité variable, tout en respectant également les exigences techniques de vitesse et de précision.

RÉSUMÉ DE L’INVENTION [0014] Dans un aspect, l’invention fournit un procédé mis en œuvre par ordinateur comprenant :

La réception, d’un serveur d’échange publicitaire via un réseau de communication de données, d’un message comprenant une demande d’offre qui inclut des informations sur le site et des informations sur l’utilisateur liées à un encart publicitaire disponible ;

la génération d’une liste d’offres classée, choisies dans une base de données d’offres active, dans laquelle le classement des offres se base au moins en partie sur les informations sur le site et les informations sur l’utilisateur ;

pour chaque offre dans la liste classée, le calcul d’une estimation de niveau d’offre de la probabilité d’interaction de l’utilisateur avec l'offre ;

pour au moins une combinaison d’offres, incluse dans la liste classée, le calcul d’un prix d’offre de niveau publicitaire, dans lequel le prix d’offre de niveau publicitaire se base au moins sur les estimations de niveau d’offre calculées de la probabilité d’interaction de l’utilisateur, les revenus d’interaction de niveau d’offre correspondants, et un paramètre d’agressivité qui contrôle l’agressivité de la tarification des offres ; et la transmission, au serveur d’échange de publicités via le réseau de communication de données, d'un message comprenant une réponse d’offre incluant une publicité à prix d’offre qui comprend la combinaison des offres et du prix d’offre de niveau publicitaire.

[0015] Avantageusement, des modes de réalisation de l’invention sont par conséquent capables de calculer la tarification des offres de niveau publicitaire sur la base des informations de niveau d’offre et des estimations de la probabilité d’interaction de l’utilisateur avec des offres individuelles. Des expériences utilisant un mode de réalisation de l’invention ont montré des améliorations significatives du taux de clic (CTR) par rapport aux procédés conventionnels de calcul de la tarification des offres dans les réseaux d’échange de publicités. D’autres augmentations du CTR ont été observées au moment d’augmenter l’agressivité de la tarification des offres via rajustement du facteur d’agressivité.

[0016] Selon des modes de réalisation de l’invention, facteur d’agressivité varie entre deux limites. Une première limite peut être une limite d'offre « conservatrice », alors qu’une seconde limite peut être une limite d’offre « agressive ». La limite d’offre « conservatrice » peut se baser sur une moyenne pondérée d’une probabilité estimée d'interaction de l'utilisateur, alors que la limite d’offre « agressive » peut se baser sur une prévision qu’un utilisateur interagit avec une offre ayant la combinaison la plus élevée de probabilité estimée d’interaction de l’utilisateur et de revenu d’interaction de niveau d’offre. Avec une définition de paramètre appropriée, les limites de paramètre d’agressivité peuvent être des valeurs finies et, dans un mode de réalisation exemplaire, le paramètre d’agressivité varie en continu, par ex. entre zéro (limite « conservatrice ») et un (limite «agressive»).

[0017] Avantageusement, des modes de réalisation de l’invention utilisent un modèle d’apprentissage automatique pour le calcul des estimations de probabilité d’interaction de l’utilisateur avec chaque offre. Le modèle d'apprentissage automatique peut être entraîné sur la base de la mise en correspondance d’événements de placement de contenu agrégés avec des événements d’interaction de l’utilisateur agrégés, et peut être configuré pour une représentation efficace afin de permettre le calcul rapide des estimations de niveau d’offre de probabilité d’interaction de l’utilisateur avec chaque offre, par ex. en moins de quelques dizaines de millisecondes. Dans des modes de réalisation de l’invention, le modèle d’apprentissage automatique est entraîné en ligne, en continu ou périodiquement, et la représentation utilisée pour te calcul des estimations de niveau d’offre de probabilité est mise à jour périodiquement pour s’assurer que les estimations se fondent sur des informations suffisamment actuelles.

[0018] Dans un autre aspect l'invention fournit un appareil informatique qui met en œuvre une plate-forme côté demande, l’appareil informatique comprenant:

un processeur ;

au moins un dispositif de mémoire accessible par le processeur ; et une interface de communication de données associée au processeur de manière opérationnelle, dans lequel le dispositif de mémoire contient un corps d’instructions de programme incluant des instructions qui, lorsqu’elles sont exécutées par le processeur, amènent l’appareil informatique à mettre en œuvre un procédé comprenant les étapes de :

la réception, d’un serveur d’échange de publicités via une interface de communication de données, d'un message comprenant une demande d’offre qui inclut des informations sur 1e site et des informations sur l’utilisateur liées à un encart publicitaire disponible ;

la génération d’une liste d’offres classée, choisies dans une base de données d’offres active, dans laquelle 1e classement des offres se base au moins en partie sur tes informations sur le site et tes informations sur l’utilisateur ;

pour chaque offre dans la liste classée, 1e calcul une estimation de niveau d’offre de probabilité d’interaction de l’utilisateur avec l’offre ;

pour au moins une combinaison d’offres, incluse dans la liste classée, le calcul d’un prix d’offre de niveau publicitaire, dans lequel le prix d’offre de niveau publicitaire se base au moins sur les estimations de niveau d’offre calculées de probabilité d’interaction d l’utilisateur, les revenus d’interaction de niveau d’offre correspondants, et un paramètre d’agressivité qui contrôle l’agressivité de la tarification des offres , et la transmission, au serveur d’échange de publicités via l’interface de communication de données, d’un message comprenant une réponse d’offre incluant une publicité à prix d'offrequi comprend la combinaison des offres et du prix d’offre de niveau publicitaire.

[0019] Le paramètre d’agressivité peut comprendre une valeur numérique continue a, pour laquelle les instructions du programme amènent l’appareil informatique à mettre en œuvre l’étape de calcul du prix d’offre de niveau publicitaire PO sur la base d’une formule :

^p0(“⁾⁼i%ⁱ⁺“}^IIEW’^o,*'^î dans lequel :

ERPO = R=>P

R ~ [Ri, Rz, .... Rn] est un vecteur de revenus d’interaction de niveau d’offre généré à partir de l’interaction de îutilisateur avec chaque offre 0/ (i- 1, 2,.... n) dans la liste des offres classée

P = [Pi, Pz,R»] est un vecteur des estimations calculées de niveau d’offre de probabilité d’interaction de l’utilisateur n est un nombre d’offres à inclure dans l’encart publicitaire disponible, et représente un produit de vecteurs dans 1e sens de l’élément.

[0020] Avantageusement, le paramètre d’agressivité a peut être modifié sur une plage continue, permettant un contrôle substantiellement plus élevé du ortement du système entre des réglages d'agressivité discrets tels qu’utilisés précédemment. La DSP est par conséquent capable de sélectionner le comportement d’offre à l’aide d’un procédé de contrôle d’agressivité doux, plutôt que d’être restreinte à des comportements catégoriques spécifiques.

[0021] Dans des modes de réalisation de l’invention, les revenus d’interaction de niveau d’offres comprennent les valeurs du coût par clic (CPC) convenues entre un opérateur de la plate-forme côté demande et les annonceurs respectifs des offres sélectionnées dans la base de données d'offres active.

[0022] Dans un autre aspect, l’invention fournit un programme informatique comprenant des instructions de code de programme pour exécuter les étapes du procédé conformément au premier aspect, si ledit programme est exécuté sur un ordinateur. Les instructions de code de programme peuvent, par exemple, être stockées sur un support tangible, lisible par machine.

[0023] D’autres aspects, avantages et caractéristiques des modes de réalisation de l’invention seront apparents aux personnes du métier concernées à partir de la description suivante de divers modes de réalisation.

BRÈVE DESCRIPTION DES DESSINS [0024] Des modes de réalisation de l’invention sont à présent décrits en référence aux dessins, dans lesquelles les chiffres de référence similaires se réfèrent aux caractéristiques similaires ; et dans lesquels

La Figure 1 est un diagramme schématique illustrant un système exemplaire en réseau mettant en œuvre l’invention ;

La Figure 2 représente une ligne temporelle de communications entre un dispositif utilisateur, un serveur Web, un serveur d’échange de publicités et une DSP mettant en œuvre l'invention ;

La Figure 3 est un diagramme bloc illustrant de manière schématique un nombre de modules de code comprenant une prédiction d’interaction de l'utilisateur et le moteur d'offre de niveau publicitaire mettant œuvre l'invention ;

La Figure 4 représente un organigramme d’un procédé de mise à jour en ligne d’un modèle d'apprentissage automatique pour la prédiction d’interaction de l’utilisateur en ligne ;

La Figure 5 représente un organigramme d’un procédé d’ingénierie de caractéristiques et d’optimisation d’hyperparamètres de modèle du modèle d’apprentissage automatique ;

La Figure 6 est un diagramme bloc illustrant schématiquement un nombre de composante de code du module d’offre en temps réel représenté à la Figure 3 ;

La Figure 7 est un organigramme d’un procédé d’estimation du CTR attendu à l’aide du modèle d’apprentissage automatique pour la prédiction d’interactions de l’utilisateur en ligne ;

La Figure 8 est un organigramme d’un procédé de génération d’une réponse d’offre, incluant le prix d’offre, selon un mode de réalisation de l’invention ;

La Figure 9 est un organigramme d’un procédé de génération d’une publicité à prix d’offre comprenant une ou plusieurs offres selon un mode de réalisation de l’invention ;

La Figure 10 est un organigramme d’un procédé de fonctionnement d’un module d’offre en temps réel mettant en œuvre l’invention ; et

La Figure 11 montre un tableau illustrant les performances d’un module d’offre en temps réel mettant œuvre l’invention.

DESCRIPTION DES MODES DE RÉALISATION PRÉFÉRÉE [0025] La Figure 1 est un diagramme bloc illustrant un système en réseau 100 exemplaire incluant un serveur de plate-forme côté demande (DSP) 102 qui est configuré pour mettre en œuvre un procédé d’offre de placement de contenu publicitaire, selon un mode de réalisation de l’invention. Le serveur DSP 102 peut comprendre un système informatique ayant une architecture conventionnelle. En particulier, le serveur DSP 102, comme illustré, comprend un processeur 104. Le processeur 104 est associé de façon opérationnelle à un dispositif de mémoire/stockage non volatile 106, par ex. par rintermédiaire d’un ou de plusieurs bus d’adresses/de données 108, comme représenté. Le stockage non volatile 106 peut être un lecteur de disque dur, et/ou peut inclure une mémoire non volatile à semi-conducteurs telle qu’une ROM, une mémoire flash, un disque statique à semi-conducteurs (SSD) ou similaire. Le processeur 104 est également ïnterfacé avec le stockage volatile 110, tel qu’une RAM, qui contient les instructions de programme et les données transitoires liées au fonctionnement du serveur DSP 102.

[0026] Dans une configuration conventionnelle, le dispositif de stockage 106 maintient te programme connu et le contenu des données relatif au fonctionnement normal du serveur DSP 102. Par exemple, 1e dispositif de stockage 106 peut contenir des programmes de système d’exploitation et des données ainsi qu’un autre logiciel d’application exécutable nécessaire pour tes fonctions visées du serveur d’authentification 102. Le dispositif de stockage 106 contient également des instructions de programme qui, lorsqu’elles sont exécutées par te processeur 104, amènent le serveur DSP 102 à effectuer des opérations liées à un mode de réalisation de l’invention, telles que décrites plus en détail ci-après, et en référence aux Figures 2 et 6 -10 en particulier. En fonctionnement, les instructions et tes données conservées sur le dispositif de stockage 106 sont transférées à la mémoire volatile 110 pour exécution sur demande.

[0027] Le processeur 104 est également associé de manière opérationnelle à une interface de communication 112 de manière conventionnelte. L'interface de communication 112 facilite l’accès à un réseau de communication de données étendu, tel qu’internet 116.

[0028] En fonctionnement, le dispositif de stockage 110 contient un corps correspondant 114 d'instructions de programme transféré à partir du dispositif de stockage 106 et configuré pour effectuer te traitement et d’autres opérations mettant en oeuvre tes caractéristiques de la présente invention. Les instructions de programme 114 comprennent une contribution technique spécifique à l'état de la technique conformément à l’invention, comme décrit plus en détail ci-dessous.

[0029] Concernant l’aperçu précédant du serveur DSP 102 et d’autres systèmes et dispositifs de traitement décrits dans la présente spécification, les termes tels que « processeur », « ordinateur », etc., sauf si 1e contexte exige le contraire, doivent être compris comme faisant référence à une gamme de mises en œuvre possibles de dispositifs, d’appareils et de systèmes comprenant une combinaison de matériel et de logiciel. Cela inclut des dispositifs et appareils à processeur unique et à processeurs multiples, notamment les dispositifs portables, tes ordinateurs du bureau et divers types de systèmes de serveurs, notamment tes plates-formes matérielles et logicielles coopérantes qui peuvent être colocalisées ou distribuées. Les processeurs physiques incluent des CPU à usage général, des processeurs de signaux numériques, des unités de traitement graphique (GPU), et/ou d’autres dispositifs matériels appropriés pour une exécution efficace des programmes et des algorithmes requis. Les systèmes informatiques peuvent inclure des architectures informatiques personnelles conventionnelles ou d’autres plates-formes matérielles à usage général. Le logiciel peut inclure un logiciel de système d’exploitation à source ouverte et/ou commercialement disponible en combinaison avec divers programmes de services et d’application. Autrement, des plates-formes informatiques ou de traitement peuvent comprendre des architectures logicielles et/ou matérielles personnalisées. Pour une extensibilité améliorée, tes systèmes de calcul et de traitement peuvent comprendre des plates-formes d’informatique en nuage, permettant aux ressources logicielles physiques d’être allouées dynamiquement en réponse aux demandes de service. Alors que toutes ces variations relèvent de la présente invention, pour faciliter l’explication et la compréhension, tes modes de réalisation exemplaires décrits dans tes présentes se basent sur des platesformes de calcul à processeur unique et à usage général, des plates-formes de systèmes d'exploitation communément disponibles et/ou des produits de consommation largement disponibles, tels que les PC de bureau, les ordinateurs portables, les smartphones, les tablettes, etc.

[0030] En particulier, le terme « unité de traitement » est utilisé dans cette spécification (notamment les revendications) pour faire référence à toute combinaison appropriée de matériel et de logiciel configurés pour réaliser une tâche particulière définie, telle que l’accès et le traitement hors-ligne ou en ligne de données, l’exécution d’étapes d’entraînement d’un modèle d’apprentissage automatique ou l’exécution d’étapes de prédiction d’un modèle d’apprentissage automatique. Une telle unité de traitement peut comprendre un module de codes exécutables s’exécutant en un seul emplacement sur un dispositif de traitement unique, ou peut comprendre des modules de code exécutables coopérants qui s’exécutent dans de multiples emplacements et/ou sur de multiples dispositifs de traitement. Par exemple, dans certains modes de réalisation de l’invention, la classification et le traitement de décision/tarification d’offre peuvent être entièrement réalisés par l’exécution du code sur le serveur DSP 102, alors que dans d’autres modes de réalisation, le traitement correspondant peut être réalisé de manière distribuée sur une pluralité de serveurs DSP.

[0031] Les composants logiciels, par ex. les instructions de programme 114, mettant en œuvre les caractéristiques de l’invention, peuvent être développés à l’aide de tout langage de programmation approprié, environnement de développement ou combinaison de langages et d’environnements de développement, comme cela sera familier aux personnes de métier dans l’ingénierie des logiciels. Par exemple, le logiciel approprié peut être développé à l’aide du langage de programmation C, du langage de programmation Java, du langage de programmation C++, du langage de programmation Go et/ou d’une gamme de langages appropriés pour la mise en œuvre de services de réseau ou basés sur le Web, tels que JavaScript, HTML, PHP, ASP, JSP, Ruby, Python, Péri, etc. Ces exemples ne sont aucunement limitatifs et on remarquera que des langages ou systèmes de développement appropriés peuvent être utilisés, conformément aux exigences du système. Les descriptions, diagrammes bloc, organigrammes, etc., présentés dans la présente spécification sont fournis à titre d’exemple, pour permettre aux personnes de métier dans l'ingénierie logicielle et l’apprentissage automatique de comprendre et d’apprécier les caractéristiques, la nature et l’étendue de l’invention, et de mettre à exécution un ou plusieurs modes de réalisation de l’invention en mettant en œuvre le code logiciel approprié selon cette révélation sans exercer une ingéniosité inventive supplémentaire.

[0032] Revenant à la Figure 1, le système 100 comprend par ailleurs des serveurs DSP supplémentaires, par ex. 118,120 qui, en fonctionnement, rivalisent avec le serveur DSP 102 pour offrir le placement de contenu publicitaire dans des encarts publicitaires en ligne offerts via un serveur d’échange de publicités 122. Le serveur d’échange de publicités 122 met en œuvre une place de marché numérique permettant aux annonceurs et aux éditeurs de sites Web et autre contenu en ligne d’acheter et de vendre de l'espace publicitaire sous la forme d’une vente aux enchères en ligne en temps réel pendant laquelle chaque serveur DSP 102, 118, 120 est un soumissionnaire automatique à grande vitesse Le serveur d’échange de publicités 122 comprend une base de données 124 dans laquelle il conserve les détails des prestataires de contenus en ligne (serveurs Web) et des annonceurs (DSP) dans le but d’exploiter une place de marché publicitaire numérique. Les fonctions des plates-formes d’échange de publicités telles que DoubleClick™ (détenue par Google™), AppNexus™, Microsoft™ Ad Exchange™ et OpenX™ sont bien connues et ne seront par conséquent pas décrites plus en détail dans les présentes, autrement que nécessaire pour illustrer de manière adéquate le fonctionnement des modes de réalisation de l’invention.

[0033] Le système 100 comprend par ailleurs des dispositifs de terminal utilisateur, représentés par exemple par le dispositif de terminal 126. Les dispositifs de terminal 126 peuvent être, par exempte, des PC de bureau ou portables, des smartphones, des tablettes ou d’autres dispositifs informatiques personnels, et chacun comprend un processeur 128 interfacé, par ex. par l’intermédiaire d’un bus d’adresses/de données 130, avec un stockage volatile 132, un stockage non volatile 134 et au moins une interface de communication de données 136. Le processeur 128 est également interface avec une ou plusieurs interfaces d’entrée/sortie (I/O) d’utilisateur 140. Le stockage volatile 132 contient des instructions de programmes et des données transitoires liées au fonctionnement du dispositif de terminal 126.

[0034] Le stockage du dispositif de terminal 132,134 peut contenir un contenu du programme et de données relatif au fonctionnement normal du dispositif 126. Cela peut inclure des programmes et des données de système d’exploitation (par ex. associés à Windows, Android, iOS, MacOS, Linux ou autre système d’exploitation), ainsi qu’un autre logiciel d’application exécutable généralement non lié à la présente invention. Le stockage 132 inclut également des instructions de programme 138 qui, lorsqu’elles sont exécutées par le processeur 128 permettent au dispositif de terminal de fournir à l’utilisateur l’accès à du contenu en ligne. Tandis que de nombreuses applications sont connues pour fournir un tel accès, pour la simplicité de la présente description, il est supposé que les instructions de programme 138 mettent en œuvre un navigateur Web ayant une interface utilisateur graphique (GUI) présentée via l’interface I/O utilisateur 140.

[0035] Par conséquent, si un utilisateur de dispositif de terminal 126 accède à un serveur Web 142, l’affichage 144 d’une page Web correspondante est généré par l’intermédiaire du dispositif Ul 140. L’affichage 144 inclut le contenu du site Web 146 et un ou plusieurs encarts publicitaires, par ex. 148,150. Quand cela est en outre illustré, chaque encart publicitaire 148,150 peut comprendre une pluralité d’« offres » spécifiques pour le compte d'un annonceur. Ces offres sont communément agencées selon un agencement de grille, par ex. tel qu’indiqué par des lignes en pointillé 148a, 148b, 148c, 150a, 150b, 150c en Figure 1. Un nombre d’étapes de communication ont ensuite lieu afin de peupler ces encarts, c.-à-d. pour fournir aux annonceurs en ligne des impressions publicitaires dans l^!affichage de la page Web 144. Ces étapes de communication sont maintenant décrites en référence à la ligne temporelle 200 illustrée à la Figure 2.

[0036] Initialement, le terminal utilisateur 126, par l'intermédiaire de l’application de navigateur Web d’exécution 138 et en réponse à une entrée d’utilisateur, transmet 202 une demande HTTP au serveur Web 142 qui inclut une URL du contenu Web souhaité. Le serveur Web 142 répond en transmettant 204 le contenu, par ex. une page Web au format HTML au dispositif utilisateur 126. Les personnes de métier dans la programmation Web noteront que la population complète et le rendu l’affichage de la page Web 144 peuvent nécessiter de multiples demandes et réponses, et peuvent impliquer d’autres transactions avec le serveur Web 142 et/ou avec d’autres serveurs en ligne, tels que les serveurs de réseau de distribution de contenu (CDN) et autres serveurs Web fournissant du contenu intégré. À des fins de simplicité et pour faciliter l’accent sur les communications mettant en oeuvre des caractéristiques de la présente invention, toutes lesdites. transactions supplémentaires connues sont représentées par une seule communication exemplaire 206 à la Figure 2.

[0037] Afin d’obtenir le contenu publicitaire pour remplir les encarts 148,150, la page Web transmise par le serveur Web 142 au dispositif utilisateur 126 inclut typiquement une référence hypertexte (« href ») invitant le navigateur 138 à récupérer te contenu dans te serveur d’échange de publicités 122 conformément à une interface de programmation d’application (API) définie et fournie par l’opérateur concerné du serveur 122. Par conséquent, le dispositif utilisateur 126 transmet 208 une demande HTTP au serveur d’échange de publicités 122. La demande inclut tes informations sur le site Web et les informations sur l'utilisateur liées à l’utilisateur du dispositif de terminal 126. Les informations sur l’utilisateur disponibles peuvent inclure des informations que 1e serveur Web 142 a collectées et peuvent inclure des informations côté client, telles que l’identité du dispositif et du navigateur et des détails techniques, des informations d’identification et des contenus de cookies de navigateur, et similaires. De nombreux mécanismes en ligne pour la collecte, la conservation et le suivi des informations sur l'utilisateur et sur te dispositif sont bien connus et disponibles pour tes personnes de métier dans la programmation Web et ne seront par conséquent pas décrits plus en détail ici.

[0038] Le serveur d’échange de publicités 122 reçoit la demande, identifie les serveurs DSP 102, 118,120 pertinents dans sa base de données 124 et transmet 210 tes messages de demande d’offre à chaque serveur DSP sélectionné. Un tel message de demande d’offres, incluant tes informations sur site et sur l’utilisateur, est reçu sur le serveur DSP 102 mettant en oeuvré la présente invention, qui exécute un processus 212 conformément à sa programmation spécifique 114 afin de prédire la vraisemblance d’interaction de l’utilisateur avec une publicité sélectionnée incluant une ou plusieurs offres, placées dans un ou plusieurs encarts disponibles 148,150, et d’arriver à une décision d’offre. Au cas où une décision est prise pour faire une offre pour l’impression proposée, et une valeur d’offre est déterminée, le serveur DSP 102 transmet alors 214 l’offre au serveur d’échange de publicités 122.

[0039] Le serveur d’échange de publicités 122 reçoit toutes les offres transmises à partir des serveurs DSP, notamment le serveur 102 et sélectionne une offre gagnante. Il récupère ensuite te contenu publicitaire correspondant à l’offre gagnante à partir de sa base de données 124 et transmet 216 te contenu publicitaire au dispositif utilisateur 126 pour un rendu dans l'encart publicitaire correspondant, par ex. 148 ou 150.

[0040] Il est bien connu que la vitesse de chargement de la page est une caractéristique importante d’un site Web du point de vue de l’utilisateur, et qu’il n’est pas souhaitable que la durée requise de chargement complet d’une page Web soit excessive. Typiquement, il est préférable que le temps de chargement ne dépasse pas quelques secondes, par ex. 3 secondes 218. Il existe, comme décrit ci-dessus, de nombreuses étapes nécessaires pour servir intégralement tout te contenu d’une page web complexe, ce qui peut impliquer des serveurs multiples sur l’Internet global. Il est, par conséquent critique que la durée du processus d’offre facilité par le serveur d’échange de publicités 202 soit strictement limitée. Actuellement, on considère qu’il est souhaitable que le serveur DSP 102 prenne une décision d’offre en quelques dizaines de millisecondes au maximum, par exemple en moins de 30 millisecondes 220. Cette décision doit être prise avec des informations sur l’utilisateur limitées et compte tenu du fait qu’une mauvaise décision peut avoir des conséquences significatives pour l’annonceur. Par exemple, si le serveur DSP détermine faussement que l’utilisateur est une cible souhaitable pour une publicité en particulier (c.-à-d. calcule un « faux positif »), il peut placer une offre gagnante relativement élevée et engager un coût réel avec peu ou pas de potentiel de retour. Inversement, si le serveur DSP détermine faussement que rutilisateur n’est pas une cible souhaitable pour la publicité (c.-à-d. calcule un « faux négatif»), il ne peut placer aucune offre, ou une offre à faible perte et amener f annonceur à manquer une opportunité pour obtenir une impression avec un réel potentiel de retour.

[0041] Afin d’atteindre une prise de décision de qualité à grande vitesse dans le contexte des services de réservation de voyages, les modes de réalisation de la présente invention peuvent utiliser une approche d’apprentissage automatique. Pour faciliter davantage la compréhension de cette approche, il est maintenant fait à nouveau référence à la Figure 1, dans laquelle 1e système 100 comprend par ailleurs un serveur d’apprentissage automatique (« Serveur ML ») 152, qui est configuré pour traiter des données brutes niées au placement de contenu (c.-à-d. des publicités/offres) avec des interactions d'utilisateurs (c.-à-d. les clics d’utilisateurs sur les publicités/offres), pour générer des ensembles de données d’apprentissage pour un modèle d’apprentissage automatique, et pour entraîner le modèle d’apprentissage automatique pour le déploiement sur le serveur DSP 102. Les étapes de traitement, d’entraînement et de déploiement sont décrites plus en détail ci-dessous, en référence aux Figures 3 et 4 et peuvent être effectuées en continu, périodiquement et/ou à la demande afin de maintenir la devise du modèle d’apprentissage automatique.

[0042] Comme avec te serveur DSP 102, le serveur ML 152 peut comprendre un système informatique ayant d'architecture conventionnelte, par ex. comprenant un processeur 154 qui est associé de manière fonctionnelle a une mémoire/un dispositif de stockage non volatile 156 via un ou plusieurs bus d’adresses/de données 158, comme représenté. Le processeur 154 est également interface avec te stockage volatile 160, tel qu’une qui contient tes instructions de programme et tes données transitoires liées au fonctionnement du serveur ML 152. Classiquement, 1e dispositif de stockage 156 contient des programmes de systèmes d’exploitation et des données, ainsi qu'un autre autre logiciel d’application exécutable pour tes fonctions visées du serveur ML 152 et incluant des instructions de programme qui, lorsqu’elles sont exécutées par le processeur 154, amènent le serveur ML 152 à effectuer tes opérations décrites en détail ci-dessous, en référence aux Figures 3 et 4 en particulier. En fonctionnement, tes instructions et tes données conservées sur te dispositif de stockage 156 sont transférées à la mémoire volatile 150 pour exécution sur demande. De plus, 1e processeur 154 est également associé de manière opérationnelle à une interface de communication 162 de manière conventionnelle, fournissant l’accès à Internet 116.

[0043] En fonctionnement, 1e dispositif de stockage 160 contient un corps correspondant 164 d’instructions de programme transféré à partir du dispositif de stockage 156 et configuré pour exécuter tes étapes de traitement et d’entraînement et de déploiement pour un modèle d’apprentissage automatique. Les instructions de programme 164 comprennent une autre contribution technique spécifique à l’état de la technique conformément à ce mode de réalisation.

[0044] Le système 100 comprend par ailleurs au moins une base de données 166 qui est configurée pour stocker des données historiques brutes liées au placement de contenu (c.-à-d. des publicités/offres) avec tes interactions utilisateur (c.-à-d. tes clics d'utilisateurs sur des publicités/offres). Le volume de telles données peut être très important sur des périodes d’intérêt, comme un mois ou plus. Par exemple, dans un déploiement en direct particulier, il a été trouvé qu’un journal de données pour un seul jour comprend environ 20 millions de lignes (c.-à-d. d’événements de placements et d’interactions) ayant une taille de stockage totale de l’ordre de 10 Gb. Par conséquent, la base de données 166 est de préférence mise en oeuvre à l'aide des technologies qui sont optimisées pour un stockage efficace, la récupération et la mise à jour de volumes de données très importants (parfois dénommé « données massives ») à travers des serveurs de bases de données et des dispositifs de stockage multiples. Tandis qu’un nombre de technologies à source ouverte et commerciales appropriées existe pour la mise en œuvre de la base de données 166, une configuration expérimentale exemplaire a été mise en œuvre à l’aide de la structure Apache Hadoop, avec des données stockées au format Parquet sur HDFS (Hadoop Distributed File System) (système de fichier distribué Hadoop) et à l’aide d’impala pour fournir un moteur d’interrogation de type SQL à grande vitesse. Cette mise en œuvre a été testée et trouvée pour fournir plus qu’une performance adéquate pour un déploiement en ligne pratique.

[0045] La base de données 166 est accessible â la fois au serveur DSP 102 et au serveur ML 152. À la Figure 1, l’accès logique est illustré par les flèches correspondantes. Dans un mode de réalisation pratique, l’accès physique entre la base de données 166 et les serveurs DSP et ML 102,152 peuvent être, via Internet 116 et/ou d’autres communications dédiées, des liens ou des réseaux, tels qu’un réseau d’espace de stockage local (SAN). Le serveur DSP 102 est configuré pour mettre à jour la base de données 166 en temps réel, avec des données brutes liées aux événements de placement et d’interaction. Le serveur ML 152 est configuré pour récupérer les données brutes dans la base de données 166 et pour réaliser les étapes de traitement, d’entraînement et de déploiement, basées sur les données récupérées.

[0046] Revenant à la Figure 2, d’autres opérations liées à la mise à jour de la base de données 166 par le serveur DSP 102 sont illustrées. En particulier, dans le cas où le serveur DSP 102 place une offre réussie, et que le contenu publicitaire correspondant est transmis 216 au dispositif utilisateur 126, le serveur DSP 102 met à jour 222 la base de données 166, en ajoutant des données liées au placement de la publicité (c.-à-d. l’impression de la publicité/de l’offre). Le code associé à la publicité est configuré de telle sorte que, dans le cas où l'utilisateur interagit par la suite avec (c.-à-d. clique sur) la publicité, le serveur DSP 102 reçoit, directement ou indirectement, une notification 224 de cet événement d’interaction. Le serveur DSP 102 met alors à jour 226 la base de données 166 avec les détails de l’évènement d’interaction. De cette manière, la base de données 166 est mise à jour en continu avec des données brutes liées à tous les événements de placement et d’interaction connus du serveur DSP 102.

[0047] La Figure 3 est un diagramme bloc illustrant schématiquement un nombre de modules de code qui comprennent ensemble une prédiction d’interaction de l'utilisateur en ligne et un moteur d’offres en temps réel 300 mettant en œuvre l’invention. La mise en œuvre du moteur d’offre et de prédiction d’interactions de l’utilisateur 300 est distribuée à travers te serveur ML 152 et te serveur DSP 102, comme représenté par les lignes en pointillés à la Figure 3.

Les trois modules de code préparent 1e composant du serveur ML du moteur 300, à savoir un module de mise en correspondance 302, un module d’enrichissement de caractéristiques 304 et un module d’apprentissage automatique 306. Ces trois modules sont tous mis en œuvre dans les instructions de programme 164, qui s’exécute sur le serveur ML 152. La fonctionnalité mise en œuvre dans chacun de ces modules est à présent décrite plus en détail [0048] L’objet du module de mise en correspondance 302 est de faire correspondre des événements de placement (c.-à-d. l’affichage de publicités et d’offres dans tes publicités, dans tes encarts publicitaires 148,150 de l’écran 144 du dispositif utilisateur 126) aux événements de placement ultérieurs (c.-à-d. des exemptes d’un utilisateur cliquant sur une offre dans une publicité placée sur l’écran 144 du dispositif utilisateur 126). La mise en correspondance permet te placement d’événements à étiqueter comme étant « cliqués » ou « non cliques », de sorte qu’ils puissent être utilisés par le module d’apprentissage automatique 306 dans l’entraînement d'un modèle d’apprentissage automatique supervisé pour la prédiction des événements d’interaction d’utilisateur basés sur les données d’événements de placement. De plus, la mise en correspondance permet aux données d’événements de placement d’être combinées aux données d’événements d’interaction correspondantes pour créer un enregistrement pour les publicités clignées contenant toutes les informations disponibles concernant 1e placement et l’interaction.

[0040] La mise en correspondance présente un défi parce qu’il n’existe aucun lien explicite entre un événement de placement (impression de publicité) et une interaction de l’utilisateur ultérieure (clic publicitaire). Comme illustré dans la ligne temporelle 200 de la Figure 2, une interaction de l’utilisateur peut apparaître à tout moment suite au placement, par ex. suite à un retard important. Puisque les nouveaux événements d’interaction et/ou de placement peuvent apparaître à un taux très élevé (par ex. des centaines ou des milliers de fois par seconde) dans un système en direct, les événements d’interaction et de placement correspondants peuvent être largement séparés dans la base de données 166. De plus, le taux d’évènements interaction peut être très bas, par ex. il est généralement rapporté que lé taux de clic (CTR) pour la publicité d’affichage basée sur le Web est de l’ordre de 0,05 %. De plus, il est souhaitable de relier les événements d’interaction et de placement au niveau de l’offre, plutôt que seulement au niveau de la publicité.

[0050] L’approche générale employée pour la mise en correspondance est d’identifier, dans la base de données 166, les événements de placement et les événements d’interaction ultérieure dans une fenêtre temporelle prédéterminée qui a un ensemble de paramètres correspondants sélectionné. La fenêtre temporelle devrait être d’une durée suffisante pour capturer la majorité substantielle de toutes les interactions, et le nombre et le choix des paramètres devraient être suffisants pour assurer une mise en correspondance unique dans une majorité essentielle de cas. La parfaite mise en correspondance peut être difficile à atteindre, parce qu’il est impossible de savoir si ou quand une interaction se produira. Une fenêtre temporelle d’une durée plus longue capturera les interactions qui surviennent après des délais plus longs mais augmentera également le risque de mise en correspondance erronée, si, par exempte, un utilisateur interagit avec une publicité, présentée ultérieurement, et ayant des paramètres similaires. De même, le risque de mise en correspondance erronée peut être réduit en utilisant un ensemble plus grand et sélectionné de paramètres pour distinguer tes publicités présentées, au détriment de la réalisation du processus de mise en correspondance, plus complexe.

[0051] Dans une configuration expérimentale exemplaire, un mode de réalisation de l’invention a été mis en œuvre dans te contexte d’un serveur DSP spécifique au domaine fonctionnant pour le compte d’annonceurs, à l’aide des données d’événements capturées dans un système en direct Une approche heuristique a été prise pour concevoir le module de mise en correspondance, avec un nombre d’expériences conduites pour déterminer une fenêtre temporelle appropriée, et un ensemble de paramètres sélectionné. On a trouvé qu’une fenêtre temporelle de 80 secondes était efficace en combinaison avec la mise en correspondance des paramètres d’événements suivants :

• un identifiant utilisateur unique (subi via un cookie de navigateur) ;

• un identifiant annonceur ;

• un identifiant d'éditeur (c.-à-d. le réseau de distribution/d’échange publicitaire à travers lequel la publicité a été placée) ;

• le format de l’offre cliquée (par ex. la largeur et la hauteur du graphique d’offre, en pixels) ;

• 1e type de produit publicitaire ;

• l’ensemble de produits publicitaires ;

• le segment d'utilisateur (une combinaison d’un segment de produits d’utilisateur, basée sur un produit tel qu’un vol, un hôtel ou un restaurant précédemment vu par ^utilisateur, et un segment temporel d’utilisateur indiquant la durée depuis la dernière activité de l’utilisateur) ;

• l’URLdusite;

• la visibilité de l’encart publicitaire ;

• le dispositif utilisateu r ;

• Une mesure de distance entre une destination (lieu) sur laquelle l’utilisateur cherchait des informations et une destination qui était l’objet de notre spécifique ; et • une clé d’encart publicitaire (un identifiant stable pour la combinaison de l’annonceur, de l’encart publicitaire et de la page).

[0052] Dans la configuration exemplaire, la mise en correspondance est effectuée à l’aide d’une demande SQL Impala pour sélectionner et joindre les tableaux d’enregistrements d’événements de placement et d’interaction sur les valeurs des champs correspondants aux paramètres dont la liste est dressée cidessus. Spécifiquement, les enregistrements de placement sont joints par la gauche à des enregistrements d’interaction, de sorte que le tableau en résultat comprend une rangée pour chaque événement de placement. Chaque rangée comprend un ensemble de valeurs de caractéristiques brutes dérivées des événements mis en correspondance, avec un indicateur pour savoir si un événement d’interaction, c.-à-d. un clic d’offre/de publicité, s’est produit ou non. Le tableau des données mises en correspondance est entré dans 1e module d’enrichissement de caractéristiques 304.

[0053] La fonction du module d’enrichissement de caractéristiques 304 est de dériver, à partir des valeurs des caractéristiques brutes dans le tableau de données mises en correspondance généré par le module de mise en correspondance 302, un ensemble correspondant de vecteurs de caractéristiques enrichis pour une utilisation par le module d’apprentissage automatique 306. Un processus de détermination d’un ensemble approprié de caractéristiques enrichies (c.-à-d. l’ingénierie de caractéristiques) est décrit en détail ci-dessous en référence à la Figure 5. À la Figure 3, tes définitions des caractéristiques enrichies pour une utilisation par le module d’enrichissement de caractéristiques 304 sont indiquées comme étant stockées dans un fichier 310 dans te magasin de données 308, ceci peut cependant être considéré comme une commodité schématique. Dans une configuration pratique, tes définitions de caractéristiques peuvent être stockées de cette manière, peuvent être compilées dans un module de codes et reliées au module d’enrichissement de caractéristiques 304 ou peuvent être codées en dur dans 1e module d’enrichissement de caractéristiques. On remarquera que chacune de ces options de mise en œuvre (et d’autres qui seront apparentes aux personnes de métier) offre éventuellement un compromis différent entre flexibilité, complexité du code et vitesse d’exécution.

[0054] Dans la configuration exemplaire, toutes les caractéristiques enrichies de type catégorique (c.-à-d. qu'elles prennent l’une d’un certain nombre de valeurs discrètes) et sont codées à chaud. Les vecteurs de caractéristiques résultants sont par conséquent en général relativement rares, et comprennent des éléments binaires. De plus, chaque vecteur de caractéristiques correspond à une offre dans une publicité présentée à un utilisateur et est associé à une étiquette binaire indiquant si futilisateur a interagi (c.-à-d. a cliqué sur) avec l’offre ou non. Le tableau de vecteurs de caractéristiques et d’étiquettes résultant est entré dans te module d’apprentissage automatique 306.

[0055] Le module d’apprentissage automatique 306 comprend un code de programme s’exécutant sur 1e serveur ML 152 et configuré dans la configuration expérimentale exemplaire pour mettre en œuvre un modèle linéaire généralisé. Spécifiquement, 1e module d’apprentissage automatique 306 de la configuration exemplaire met en œuvre un algorithme de régression logistique régularisé, avec un apprentissage proximal de « l'amorce régularisée de suivi » (FTRL). Avantageusement, cet algorithme d’apprentissage automatique est connu pour être efficace en cas d’ensembles de données hautement déséquilibrés (notons que seulement environ 0,05 % des échantillons dans le tableau de vecteurs de caractéristique sont étiquetés comme « cliqués »). Vous trouverez de plus amples détails sur l’algorithme et son application à la prédiction de clic dans H. Brendan McMahan et al, « Ad Click Prédiction: a View from the Trenches » (Prédiction de clics publicitaires : une vue provenant des tranchées), KDD’ 13, août 11-14, 2013, Chicago, Illinois, EU. L’algorithme a un nombre d'hyperparamètres qui peuvent être ajustés dans le but d’optimiser sa précision d’apprentissage sur tes données d’apprentissage pour un problème spécifique. Un processus de détermination d’un ensemble de valeur approprié pour tes hyperparamètres est décrit en détail ci-dessous en référence à la Figure 5. À la Figure 3, les valeurs fixes des hyperparamètres pour une utilisation par 1e module d’apprentissage automatique 306 sont représentées comme étant stockées dans un fichier 312 dans le magasin de données 308. On remarquera cependant que des mises en œuvre alternatives sont possibles, telles que le codage dur des paramètres dans 1e module d’apprentissage automatique 306.

[0056] L’exécution du module d’apprentissage automatique 306 dans un ensemble de données particulier résulte de la génération d’un modèle qui peut être exécuté par 1e serveur DSP 102, comme décrit plus en détail ci-dessous en référence à la Figure 7. En particulier, un modèle de régression logistique est entièrement caractérisé par un ensemble de coefficients associés à des éléments du vecteur de caractéristique d’entrée. Dans la configuration exemplaire, une représentation particulièrement efficace du modèle est utilisée, pour permettre au serveur DSP 102 de calculer une prédiction de la probabilité d’une interaction de l’utilisateur très rapidement, c.-à-d. bien dans la fenêtre cible de 30 ms 220 pour générer une décision d’offre. Spécifiquement, les coefficients sont stockés comme un dictionnaire dans lequel chaque entrée est définie par une clé et une valeur. La clé est une représentation hachée d’une concaténation du nom de caractéristique (c.-à-d. une étiquette de colonne dans le tableau de caractéristiques) et une valeur de caractéristique correspondante (c.-à-d. des valeurs catégoriques avant le codage à chaud). La valeur associée dans le dictionnaire est simplement le coefficient modèle correspondant. Ce type de structure de données est connu pour fournir une recherche extrêmement rapide, notamment pour les ensembles de caractéristiques rares. En particulier, en utilisant des valeurs hachées, une limite du nombre de caractéristiques hachés peut être imposée (un schéma parfois dénommé la « lecture spéciale de hachage »). Ce schéma peut être utilisé pour accélérer considérablement la recherche et le calcul, aux frais d'éventuelles collisions dans les valeurs clés du dictionnaire. Avantageusement cependant, l’effet statistique de ces collisions peut être négligé du point de vue des performances globales de l’algorithme [0057] Pour le déploiement sur le serveur DSP 102, la structure de modèle de données est sérialisée dans un format binaire (dans la configuration exemplaire le format Python « pickle » est utilisé), et stockée dans un fichier modèle 314 dans le magasin de données 308.

[0058] Lors de l’utilisation, le serveur ML 152 exécute les modules 302, 304, 306 de façon répétée, par ex. en continu, périodiquement ou sur demande. Ceci est illustré par l’organigramme 400 représenté à la Figure 4. Les données brutes sont récupérées dans la base de données 166 à l’étape 402. Une période prédéterminée de données récentes peut être utilisée. Elle est considérée comme étant représentative du comportement des utilisateurs en ligne actuels du système 100. Par exemple, tes données brutes provenant de la période d’un mois la plus récente peuvent être utilisées. À l’étape 404, le module de mise en correspondance 302 effectue la mise en correspondance des événements de placement et d’interaction, comme décrit En pratique, les étapes de récupération 402 et de mise en correspondance 404 peuvent être combinées en tant que requête unique, par ex. une requête SQM Impala.

[0059] À l’étape 406, 1e serveur ML 152 exécute le module d’enrichissement de caractéristiques qui utilise les définitions de caractéristiques enrichies 310 pour calculer tes vecteurs de caractéristiques enrichies correspondant aux données mises en correspondance. Ceux-ci sont transférés au module d’apprentissage automatique 306 qui entraîne te modèle utilisant les vecteurs de caractéristiques étiquetés et les hyperparamètres prédéterminés définis dans ie fichier de configuration 312. Les coefficients de modèles résultants sont hachés, sérialisés et publiés 410 sur le fichier modèle 314.

[0060] En option, le serveur ML attend alors 412, avant de recommencer le processus à l'étape 402. La sortie de l’état d’attente 412 peut être déclenchée par un nombre d’événements différents. Par exemple, le serveur ML peut être configuré pour faire fonctionner les modules 302, 304, 306 périodiquement, par ex. une fois par jour. D'une autre façon ou en plus, il peut être configuré pour faire fonctionner les modules 302, 304, 306 sur demande, par ex. à réception d’un signal provenant d’un contrôleur (non représenté) dans te système 100. Dans certaines configurations, te serveur ML peut faire fonctionner tes modules 302, 304, 306 en continu, mettant ainsi à Jour le fichier modèle 314 aussi fréquemment que possible sur la base de l’heure requise pour la mise en correspondance des données, l’enrichissement des caractéristiques et l’entraînement du modèle. Dans une configuration expérimentale exemplaire, il a été trouvé que tes mises à jour basées sur des lots de données de 30 minutes fournissaient un compromis approprié entre la qualité de la sortie du module de mise en correspondance 302 (c,-à-d. le besoin de rapprocher tes événements d’interaction et de placement précisément pour un bon ensemble de données d’entraînement), et la réactivité aux changements en temps réel sur 1e réseau d’échange de publicités (par ex. les nouveaux lancements de campagne, rentrée/la sortie de concurrents, des changements dans la demande utilisateur pour certains contenus, etc.).

[0061] En passant à la Figure 5, un organigramme 500 d’un processus d’ingénierie de caractéristiques et d’optimisation d’hyperparamètres de modèle est représenté. En pratique, le processus 500 est partiellement automatisé et exploité sous surveillance humaine. Le développement de caractéristiques appropriées avec une capacité prédictive élevée, et la sélection de gammes appropriées d’hyperparamètres de modèle impliquent une expérience significative, l’évaluation, la créativité et l'ingéniosité, et ne peut pas dans te plupart des cas être entièrement automatisée de manière efficace.

[0062] Le processus 500 requiert un ensemble de données test qui est récupéré à l’étape 502 et qui peut être obtenu de la même manière que celte décrite ci-dessus par rapport à la fonctionnalité du module de mise en correspondance 302. En particulier, les données peuvent être extraites de la base de données 166 pour une période de test sélectionnée à l’aide d’une requête SQL Impala de la même forme que celte utilisée par 1e module de mise en correspondance 302.

[0063] À l’étape 504, un ensemble de caractéristiques enrichies est défini et configuré. Cette étape implique typiquement l’application de l’évaluation, de la créativité et de l’ingéniosité d’un scientifique de données expérimenté. En pratique, un nombre d’expériences a été réalisé, conformément au processus 500 et supporté par une autre analyse de l’ensemble de données test, dans 1e but d’identifier un ensemble de caractéristiques enrichies efficace. À l’étape 506, tes valeurs des caractéristiques enrichies définies sont calculées à partir de l’ensemble de données test brutes.

[0064] À l’étape 508, un ensemble de valeurs d’hyperparamètres est sélectionné et un modèle d’apprentissage automatique est configuré avec tes valeurs sélectionnées. À l’étape 510, le modèle résultant est entraîné à l’aide des données test enrichies. Typiquement, une portion des données test est retenue à l’étape d’entraînement 510, qui est ensuite utilisée dans une étape de validation croisée 512 pour évaluer tes performances du modèle entraîné sur tes données qui n’ont pas été vues pendant l’étape d’entraînement 510.

[0065] Les performances du modèle entraîné sont ensuite évaluées à l’étape de décision 514 pour déterminer si elles sont acceptables ou non, par exemple en atteignant un certain niveau de performance optimal ou suffisant. Le choix des critères pour évaluer tes performances peut être important pour identifier un modèle acceptable. Divers critères connus peuvent être utilisés, tels que la courbe caractéristique de fonctionnement du récepteur (AUROC), la perte de journal ou Gini (qui est lié à l’AUROC). Dans la configuration exemplaire, une combinaison de Gini (qui prend des valeurs entre -1 et 1 et est de préférence aussi élevé que possible) et la perte de journal (qui est de préférence aussi basse que possible) a été utilisée pour évaluer les performances des différents modèles. Cette approche a été utilisée non seulement pour différents paramètres du modèle proximal FTRL sélectionné, mais également pour un nombre de modèles alternatifs, incluant les arbres de décision (forêt aléatoire distribuée, arbres amplifiés par gradient), Bayes naïfs et des réseaux d'apprentissage en profondeur qui ont été ensuite rejetés dans la mesure où il fournissait des performances inférieures sur les ensembles de données analysés.

[0066] Si les performances sont jugées inacceptables ou si un processus d’optimisation est Incomplet, à la décision 514, une autre décision 516 est prise pour savoir s'il faut mettre à jour les hyperparamètres de modèle. La boucle résultant de la configuration des hyperparamètres, de l’entraînement et du test du modèle est typiquement automatisé à l’aide d’un algorithme tel qu’une recherche de grille ou similaire. Le rôle du scientifique qui supervise les données dans ce cas est de déterminer des plages appropriées pour la grille d’hyperparamètres.

[0067] Si aucune autre variation d’hyperparamètres n’est requise, une boucle extérieure, mise en œuvre via la décision 518 permet de tester tes ensembles alternatifs de caractéristiques enrichies. Si les sélections et les valeurs d’algorithme de modèle disponibles, tes hyperparamètres et tes caractéristiques enrichies ont été épuisés sans identifier un modèle acceptable, alors le processus 500 peut être considéré comme ayant échoué et une recônsidération de la stratégie peut être requise. Aux fins de la configuration exemplaire, cependant, 1e processus 500 a conduit à un modèle avec des performances acceptables. À l'étape 520, par conséquent, tes définitions de caractéristiques enrichies identifiées et les hyperparamètres de modèles sont écrits sur tes fichiers de données 310, 312 dans 1e magasin de données 308. Un résumé des caractéristiques enrichies développées via le processus 500 est présenté au Tableau 1, [0068] La Figure 6 est un diagramme bloc 600 illustrant de manière schématique un nombre de composants de code qui comprend le module d’offre en temps réel 316 décrit ci-dessus en référence à la Figure 3. Chacun de ces composants de code qui comprend collectivement une contribution technique à l’état de la technique spécifiquement développé pour le mode de réalisation de l'invention décrit présentement, et mis en œuvre dans les instructions de programme 114 s’exécutant sur le serveur DSP 102. Les détails des algorithmes mis en œuvre par les composants de code illustrés à la Figure 6 sont décrits cidessous en faisant en particulier référence aux organigrammes représentés aux Figures 7 à 10, tandis que les effets techniques avantageux obtenus par un mode de réalisation exemplaire sont illustrés dans le tableau de la Figure 11.

[0069] L’entrée sur le module d’offre en temps réel 316 inclut des demandes d'offres 210 reçues du serveur d'échange de publicités 122. Un composant de sélection et de classement de niveau d’offre 602 utilise des informations sur l'utilisateur provenant d’une base de données d’utilisateurs active 604, offre des informations provenant d’une base de données d’offres active 606 et, en option, le CTR de niveau d’offre estimé, généré par un composant d'estimation de CTR d'apprentissage machine 608, afin de générer un ensemble classé d’offres 610 pour une éventuelle inclusion dans publicité à générer en réponse à une demande d’offre 210. Le fonctionnement du composant de sélection et de classement de niveau d’offre 602 est décrit plus en détail ci-dessous en référence à la Figure 8.

[0070] Les offres classées 610 sont transmises à un composant de calcul de prix d'offre de niveau publicitaire 612 qui utilise le composant d'estimation de CTR d'apprentissage automatique 608 afin de générer une publicité à prix d’offre. Le fonctionnement du composant de calcul de prix d’offre de niveau publicitaire 612 est décrit plus en détail ci-dessous en référence aux Figures 8 et en particulier. La publicité à prix d’offre peut être utilisée pour générer une réponse d’offre 214.

[0071] La Figure 7 est un organigramme 700 d‘un procédé d’estimation du CTR attendu parle composant d’estimation du CTR 608, à l'aide du modèle d'apprentissage automatique pour la prédiction d’interaction de l’utilisateur en ligne décrite ci-dessus en référence aux Figures 3 à 5. À l’étape 702, les informations sur le site, l’offre et l’utilisateur sont reçues, c.-à-d. via la transmission 210 provenant du serveur d’échange de publicités 122 en rapport avec les informations récupérées dans la base de données d’offres active 606 et toute information disponible récupérée dans la base de données d’utilisateurs active 604. Ces informations sont utilisées à l'étape 704 pour calculer un vecteur de caractéristique enrichi correspondant conformément aux définitions 310.

[0072] Λ l’étape 706, le module d’offres en temps réel accède à la représentation de modèle 314 qui, comme cela a été décrit, comprend un ensemble de coefficients stockés dans une structure de dictionnaire hautement efficace pour une recherche rapide de coefficients. Comme décrit ci-dessus, en référence à la Figure 4 en particulier, le modèle peut être mis à jour le cas échéant par le serveur ML 152. La représentation de modèle 314 peut être stockée sur un support de stockage partagé 308, et être lisible de manière asynchrone par le serveur DSP 102. Dans certains modes de réalisation, le serveur DSP peut conserver une copie mise en mémoire cache de la représentation de modèle 314 pour un accès rapide, qui est mise à jour lors de la mise à jour du fichier stocké par le serveur ML 152.

[0073] La sortie du modèle, générée à l’étape 708 est une estimation de la probabilité d’interaction de l'utilisateur avec l’offre, sur la base du vecteur de caractéristique enrichi. Dans le mode de réalisation exemplaire, la sortie est une valeur représentant une probabilité selon laquelle l’utilisateur cliquera sur l’offre. Dans ce mode de réalisation, on remarquera par conséquent que le modèle peut être considéré de manière équivalente comme fournissant un CTR de niveau d'offre estimé, c.-à-d. que pour un large ensemble d’utilisateurs indépendants, identiques auxquels une offre est présentée, le CTR est égal à la probabilité selon laquelle chaque utilisateur individuel cliquera sur l’offre. Dans la discussion suivante, les termes probabilités d’interaction et CTR sont utilisés de manière interchangeable.

[0074] La Figure 8 est un organigramme 800 d'un procédé de génération d’une réponse d’offre, incluant un prix d’offre, par le module d'offre en temps réel 316. En particulier, l’organigramme 800 représente les étapes mises en œuvre par Je composant de sélection et de classement de niveau d’offre 602, et les étapes de haut niveau mises en œuvre par le composant de calcul de prix d’offre de niveau publicitaire 612. Les détails de l’algorithme de calcul de prix d’offre mis en œuvre par le composant de calcul de prix d’offre de niveau publicitaire 612 sont exposés ci-dessous, en référence à la Figure 9.

[0075] À l’étape 802, une demande d’offre 210 est reçue. À l’étape 804, le composant de sélection et de classement de niveau d’offre 602 exécute une ou plusieurs procédures pour sélectionner et classer les offres pour une éventuelle inclusion dans une publicité générée en réponse à la demande d'offre 210. Du point de vue de la présente invention, la signification du composant de sélection et de classement de niveau d’offre 602 est qu’il produit une liste classée d’offres sélectionnées parmi celles disponibles dans la base de données d’offres active 606. Tout procédé approprié pour ce faire peut être utilisé. Néanmoins, pour aider à la compréhension de l’invention, les procédés exemplaires de classement et de sélection de niveau d’offre sont à présent décrits. Comme cela a été noté, le mode de réalisation exemplaire est mis en œuvre dans le contexte de la réservation de voyages et les services liés, cependant les principes décrits peuvent être appliqués à d’autres contextes et sujets.

[0076] Comme les hommes de métier le savent et comme cela a été généralement décrit ci-dessus en référence à la Figure 1, pour chaque encart publicitaire (par ex, 148,150) de taille et d’attributs donnés, une publicité peut être dynamiquement construite par la DSP 102 et peut comprendre jusqu’à n offres différentes. Par exemple, comme représenté à la Figure 1, l’encart publicitaire 148 comprend jusqu’à trois offres, 148a, 148b, 148c, c.-à-d. n = 3. Dans d’autres modes de réalisation cependant, le nombre maximum d’offres qui peuvent être placées peut être supérieur ou inférieur à trois. Dans une autre configuration commune n - 4. Le nombre maximum d’offres peut être supérieur, si plus d’espace est disponible et si de grandes bannières sont fournies sur un site. Un nombre d’offres, jusqu’au maximum n, et les contenus de chaque coffre, sont choisis de préférence afin d’optimiser l’espace acheté sur l’écran 144 et d'augmenter la probabilité selon laquelle l'utilisateur interagit avec (c.-à-d. clique sur) au moins une des offres.

[0077] Par conséquent, à l’étape 804, le module de sélection et de classement de niveau d’offre exemplaire 602 et configuré par une programmation spécifique pour sélectionner et classer, à partir d’offres actives dans la base de données 606, un ensemble d’offres candidates Οι, O2,.... O_n pour remplir l’encart publicitaire disponible dans la demande d’offre 210.

[0078] Cette étape est principalement entraînée par des heuristiques spécifiques au domaine (c.-à-d. dans le domaine du voyage, dans le mode de réalisation exemplaire), conçues sur la base d’une entrée provenant d'experts du domaine. Les heuristiques peuvent inclure la mise en correspondance entre des attributs incluant des caractéristiques dérivés de la demande (par ex. une URL de site Web, une destination de voyage d’utilisateur dérivée des termes de recherche de l'utilisateur, un lieu d’origine de l’utilisateur dérivé d'une adresse IP du dispositif utilisateur 126, etc.) et les caractéristiques d'offre présentes dans la base de données d’offres active 606 (destination de l’offre, prix, type de produit, etc.). En sélectionnant et en classant les offres, d’autres règles commerciales peuvent également être appliquées, tels que les dates de début et de fin d’activité de campagne, le budget restant, etc.

[0079] La mise en correspondance des heuristiques peut être mise en œuvre à l’aide de filtres appropriés. Dans le mode de réalisation exemplaire, un premier ensemble de filtres est appliqué à l’aide de règles commerciales dans 1e but de déterminer un premier ensemble d’offres éligibles. L’objet de ces filtres est d'éliminer 1e matériel de campagne passé et/ou les offres qui peuvent être inactives ou indisponibles pour une autre raison commerciale (par ex. offre expirée ou budget épuisé).

[0080] Un deuxième ensemble de filtres spécifiques au domaine du voyage est ensuite utilisé pour la mise en correspondance géographique entre la destination d’intérêt pour l’utilisateur, et les destinations associées aux offres disponibles. Le filtrage hiérarchique peut être utilisé pour soutenir la mise en correspondance à des degrés plus et/ou moins élevés de spécificité. Par exempte, si les termes de recherche d’un utilisateur indiquent un intérêt à Majorque en tant que destination mais qu’il n’y a aucune offre active spécifique à cette destination, les filtres pour « l’Espagne » peuvent être appliqués, ou même les filtres pour « l’Europe », s’il n’y a aucune offre active spécifique à « l’Espagne ».

[0081] Dans un mode de réalisation, tes offres de mise en correspondance des caractéristiques de la demande sont ensuite sélectionnées parmi le maximum n précisé par le système pour éviter les coûts de surcalcul à la fois dans te CPU et le temps, et ordonnées en diminuant la qualité de la mise en correspondance.

[0082] Dans un mode de réalisation alternatif, un nombre plus élevé m > n d’offres peut être sélectionnée. Dans ce cas, le composant de calcul de prix d’offre de niveau publicitaire 612 peut être requis pour évaluer tous les choix possibles d’offres n parmi m, par ex. selon le procédé décrit ci-dessous en référence à la Figure 9. Ce mode de réalisation a l’avantage d’étendre le domaine de recherche pour optimiser le prix d’offre, permettant ainsi de découvrir d’éventuelles combinaisons d’offres plus efficaces. Une limite cependant est que cette approche augmente le temps de calcul, et est par conséquent importante pour assurer la disponibilité d’une puissance de traitement suffisante, puisque le temps de réponse requis est court.

[0083] Un classement d’offres sélectionnées 610 est par conséquent généré et mis à disposition du composant de calcul de prix d’offre de niveau publicitaire 612 qui, à l’étape 806, calcule un prix d’offre de niveau publicitaire à l'aide des paramètres de facteur d’agressivité 808 pour produire une publicité à prix d’offre 810 pour l'utiliser en générant 812 une réponse d’offre 214.

[0084] La Figure 9 est un organigramme 900 représentant les détails du calcul de prix d’offre de niveau publicitaire 806 à l’aide d’un ou de plusieurs paramètres de facteur d’agressivité 808. Le composant de calcul de prix d’offre de niveau publicitaire 612 combine les attributs liés à l’offre aux informations sur le contexte et sur l’utilisateur de la demande actuelle 210, et exécute le composant d’estimation du CTR 608 pour calculer une probabilité de clic pour chaque offre O, générée par le composant de sélection et de classement de niveau d’offre 602, selon le procédé 900.

[0085] À l’étape 902, une offre classée O; (/ = 1, 2,..., n) est sélectionnée dans la liste générée par le composant de sélection et de classement de niveau d’offre 602. À l’étape 904, les attributs d’offre et d’utilisateur sont récupérés. En particulier, les informations liées à l’utilisateur sont récupérées dans la base de données d’utilisateurs active, sur la base de la mise en correspondance exacte une à une (par ex. à l’aide des cookies de l’utilisateur) ou sur la base de la mise en correspondance d’autres caractéristiques de l’utilisateur lorsque la mise en correspondance une à une est impossible (par ex. parce que l'utilisateur n’a pas été précédemment rencontré). Par ailleurs, les informations liées à l'offre (par ex. la destination de l’offre, le prix, type de produit, etc. sont récupérées dans la base de données d’offres active 606. L’ensemble des caractéristiques résultant, comprenant {caractéristiques d’offre Oi ; caractéristiques d’utilisateur U ; caractéristiques de contexte de navigation C} est passé au composant d’estimation du CTR 608 qui exécute le processus 700 pour calculer la probabilité d’une interaction de l’utilisateur comme Pi = P(clic | (0/ ; U ; Ç}).

[0086] À l’étape de décision 906, une vérification est faite pour déterminer si toutes les offres ont été traitées, c.-à-d. i = n. Sinon, le commande retourne à l’étape 902 et la prochaine offre classée est traitée. Autrement, la commande passe à l’étape 908 dans laquelle le composant de calcul du prix d'offre de niveau publicitaire 612 calcule une quantité de vecteurs ERPO (Expected Revenue Per Offer) (revenu attendu par offre), définie comme :

ERPO = RoP où R = [Ri, Rz,.... Rn] est un vecteur de revenu (c.-à-c. CPC convenu entre l’opérateur DSP et les annonceurs respectifs) généré à partir d’un clic de chaque offre O} (i~ 1,2,.... n), P = [Pi, P2,.... P«1 est un vecteur de probabilités de clic correspondant déterminé comme décrit ci-dessus, et désigne le produit Hadamard (c.-à-d. dans le sens de l’élément) des vecteurs.

[0087] Intuitivement, l’ERPO correspond aux gains moyens attendus par offre pour être représenté dans l’encart publicitaire, pour chaque offre i. Ce vecteur comprend des informations permettant plusieurs choix possibles pour le prix d’offre, par ex. :

• un choix « conservateur » consiste à prendre la moyenne pondérée de probabilité de clic, le poids étant le revenu respectif par offre, qui peut être calculé comme suit - ERP ;

» ;

• un choix « agressif» consiste à prendre le maximum du revenu attendu par offre, c.-à-d. maxlEJWj, en pariant de manière optimiste que l’utilisateur cliquera sur l’offre la plus probable et générant des revenus pour le DSP ; ou • La plage entre ces deux extrêmes peut être utilisée pour mettre en oeuvre des niveaux intermédiaires d'agressivité d’offre.

[0088] Une manière convenable de définir l’intégralité de la plage d’agressivité d’offre peut être dérivée en définissant d’abord la norme p de l’ERPO :

[0089] En particulier, le calcul d’offre agressive ci-dessus peut être exprimé comme suit:

|ERPO|L =hm[ERPO||_p =max|E7?PO,| et, en notant que ERPO_i > 0 V i e: (1...n), le calcul d’offre conservatrice peut être exprimé comme suit :

^«θιι, [0090] Avec une substitution « = 1—J-, une fonction de prix d’offre qui est P continue sur 0 < a < 1 peut être ensuite définie comme suit :

[0091J Dans l’équation ci-dessus, a est un paramètre de facteur d’agressivité 808 pour lequel :

• a = 0 correspond à une offre « conservatrice » ;

• a -1 correspond à une offre « agressive » ; et • 0 < a < 1 fournit une modulation régulière de l’agressivité entre tes deux extrêmes, comme requis.

[0092] Les calculs ci-dessus sont mis en oeuvre en conséquence à l’étape 910 pour générer un prix d’offre de niveau publicitaire unique sur la base des estimations du CTR de niveau d’offre pour tes offres classées sélectionnées par le composant de sélection et de classement de niveau d’offre 602, à l’aide d’un paramètre de facteur d’agressivité correspondant 808 qui a été fixé selon l’annonceur, la campagne et/ou d’autres exigences.

[0093] Dans certains modes de réalisation, un simple multiplicateur de prix d’offre peut être appliqué sur la valeur PO calculée ci-dessus, afin de convertir la valeur en un prix d’offre actuel dans une devise supportée par le serveur d’échange de publicités 122. Par ailleurs, dans certains modes de réalisation, un prix plafond peut également être appliqué pour limiter le prix d’offre actuel en cas de valeurs manifestées de manière évidente de probabilité de clic et/ou de prix d’offre, et d’éviter une dépense DSP excessive sur les offres individuelles.

[0094] Enfin, à l'étape 912, la publicité finale à prix d’offre 810 est produite ; elle peut être utilisée dans la génération 812 d’une réponse d’offre 214.

[0095] La Figure 10 est un organigramme 1000 d’un procédé de fonctionnement général du module d'offre en temps réel 316 mettant en œuvre l’invention, incluant le traitement post-offre pour supporter te fonctionnement en ligne du serveur ML 152. À l’étape 1002, une demande d’offre est reçue, tandis qu’à l’étape 1004 une réponse d'offre est déterminée. Par conséquent, ces deux étapes générales correspondent aux procédés décrits en détail ci-dessus en référence aux Figures 7 à 9.

[0096] À l’étape 1006_t une décision peut être prise quant à transmettre ou non une réponse d’offre pour l’encart publicitaire présenté dans la demande d’offre 210. Par exemple, si le prix d’offre calculé est indûment élevé (par ex. dépasse un prix plafond ou une contrainte de budget disponible) ou bas (par ex. reflète une faible probabilité de succès et/ou de génération de revenu), la décision de ne pas transmettre la réponse d'offre peut être prise. Si une décision est prise pour faire une offre pour l’encart, la commande passe à l’étape 1008 dans laquelle la réponse d’offre est retransmise 214 au serveur d’échange de publicités 122. Au cas où l’offre est réussie, la commande est dirigée 1010 à l’étape 1012 dans laquelle la base de données 166 est mise à jour avec les détails de l'événement de placement.

[0097] Afin d’évaluer les performances du module d’offre en temps réel 316 mettant en œuvre l’invention, un nombre de modules expérimentaux a été exécuté en parallèle à un module mettant en œuvre un algorithme d’offre conventionnel. La Figure 11 représente un tableau 1100 illustrant les performances du module d’offre en temps réel expérimental mettant en œuvre l’invention. Le tableau 1100 représente le taux de clics (CTR) sur l’axe vertical 1102 avec les performances correspondantes de dix modules d'offres représentés sous la forme d’une série de barres. La barre 1104 représente les performances d’un module d’offre conventionnel, tandis que les barres 1106 représentent les performances d’un soumissionnaire expérimental mettant en œuvre une invention, et utilisant une stratégie d’offre « conservatrice » (a = 0). Ces soumissionnaires expérimentaux ont atteint des CTR en moyenne supérieurs à deux fois les performances du soumissionnaire conventionnel 1104 sans estimation du CTR basé sur l'apprentissage automatique. Enfin, la barre 1108 représente les performances du soumissionnaire «agressif» (a = l ) qui a atteint un CTR supérieur à trois fois celui du soumissionnaire conventionnel 1104. Par conséquent, il apparaît que le soumissionnaire agressif 1108 mettant en œuvre l’invention réussit plus à gagner des encarts publicitaires avec une probabilité élevée d’interaction de l’utilisateur comparé aux soumissionnaires conservateurs 1106 et, même plus, au soumissionnaire conventionnel 1104.

[0098] Il faut noter que tandis que des modes de réalisation et des variations de l’invention particuliers ont été décrits dans les présentes, d’autres modifications et alternatives seront apparentes aux hommes de métier. En particulier, les exemples sont proposés par voie d’illustration des principes de l’invention et pour fournir de nombreux procédés spécifiques et arrangements pour mettre ces principes à exécution. En général, les modes de réalisation de l’invention reposent sur la fourniture d’agencements techniques où la prise de décision en temps réel automatisée, liée à l’offre de niveau publicitaire pour des encarts dans un système de publicité en ligne peut être faite sur la base des prédictions des interactions de l’utilisateur de niveau d’offre. Un module d’offres en temps réel mettant en œuvre l’invention est programmé pour effectuer des étapes techniques, en réponse à un message de demande d’offre reçu d’un serveur d’échange de publicités, de réalisation de filtrage spécifique au domaine d’enregistrements de base de données pour sélectionner et classer les offres, et de calcul d'un prix d’offre de niveau publicitaire correspondant sur la base des estimations du CTR de niveau d’offre, des valeurs de revenu associées, et des paramètres de facteur d’agressivité. En particulier, un algorithme est utilisé. Il permet le contrôle continu de l’agressivité d’offre entre les extrêmes d’offre « conservatrice » (basée sur une moyenne pondérée du CTR d’offre estimé) et d’offre « agressive » (basée sur l'attente qu’un utilisateur interagisse avec une offre ayant la combinaison la plus élevée de CTR estimé et de génération de revenu).

[0099] Dans les modes de réalisation exemplaire, les prédictions d’interaction de niveau d’offre sont déterminées à l’aide d’un modèle d’apprentissage automatique entraîné à l’aide des données dérivées d’une base de données d’événements de placement et d’interaction. D’autres étapes techniques mises en œuvre par lesdits modes de réalisation comprennent la mise en correspondance d’événements pour générer des enregistrements combinés de placement/d’interaction qui sont étiquetés pour une utilisation par des algorithmes d’apprentissage supervisés, le calcul de vecteurs de caractéristique enrichis pour l’apprentissage, et l’entraînement d’un modèle d’apprentissage automatique basé sur la mise à jour en continu de données d’événement pour maintenir une représentation de modèle de mise à jour courante et périodique ayant un format efficace utilisable par le module d’offre en temps réel pour prendre des décisions rapides, par ex. en moins de 30 ms.

Tableau 1 : Résumé des caractéristiques enrichies

Nom de la caractéristique	Description de la caractéristique
ts_day_of_week	Le jour de la semaine (dim.-sam.) du placement de l’événement.
ts_hour_of_day	L’heure du jour (00-23) du placement de l’événement.
tsjs_weekend	Si l’événement de placement a eu lieu un week-end.
tsjs_bank_holiday	Si l’événement de placement a eu lieu un jour férié dans le pays à partir duquel l’utilisateur a accédé à un site.
publîsherjd	Identifiant de l’éditeur (par ex. opérateur du serveur d’échange de publicités).
advertîserjd	Identifiant de l’annonceur.
offerjcey	Un identifiant d’offre unique, créé en combinant l’id_de l’annonceur (voir cidessus) et d’autres champs d’annonceurs (type de produit et ensemble de produits)
ad_dst_top199	Une destination associée à une offre. Limitée aux 199 premières destinations qui ont été trouvées dans les expériences d’ingénierie de caractéristiques pour capturer 92 % de tous les clics.
fmt	Format d’une offre (largeur et hauteur d'une image d’offre dans l’encart publicitaire)
nb_offers_per_ad	Nombre d’offres incluses avec l’encart publicitaire.
mq_dst	Proximité/distance de la destination d’intérêt de l’utilisateur et destination associée à une offre. Une valeur catégorique indiquant la proximité de correspondance sur une échelle d’ensemble.
user_pseg	Identifiant d’un segment de produit précédemment vu par l’utilisateur (par ex. vol, hébergement, restaurant).
user_tseg	Identifiant d’un segment de temps d'une activité antérieure de l’utilisateur (par ex. au cours du dernier jour, il y a 24-48 heures,.... il y a 8-30 jours).

Nom de la caractéristique	Description de la caractéristique
domain name top99	Nom de domaine d’un site sur lequel l’encart publicitaire est affiché. Limité aux 99 premiers domaines qui ont été trouvés dans les expériences d’ingénierie de caractéristiques pour capturer 95 % de tous les clics.
slot_visibility	Visibilité de l’encart publicitaire dans la page sur l’écran de l’utilisateur
device	Identifiant du dispositif utilisateur
fmt_device	Une caractéristique d’ingénierie comprenant une combinaison de format d'offre (fmt) et l’identifiant du dispositif utilisateur (dispositif).
ad_slot_key_top499	Un identifiant unique pour la combinaison de l’annonceur, de l'encart publicitaire et de la page. Limité aux 499 premières valeurs qui ont été trouvées dans les expériences d’ingénierie de caractéristiques pour capturer 97 % de tous les clics.
camp_type	Identifiant catégorique de type de compagnie associée à une offre (par ex. texte + image, image, bannière d’affichage avec contenu dynamique, bannière d’affichage statique).
user_country_top3	Le pays à partir duquel l’utilisateur a accédé à un site. Limité aux trois premiers pays qui ont été trouvés dans les expériences d’ingénierie de caractéristiques pour capturer 99 % de tout le trafic. Notons, cependant que le nombre et l’identité des premiers pays est spécifique à un éditeur/échange de publicités qui peut être spécifique à la région et à la langue.
offerjaos	Une valeur catégorique indiquant le placement d'une offre dans un encart publicitaire.
browser	Identifiant du navigateur de l’utilisateur (par ex. Chrome, IE, Safari, etc.).

Claims (17)

1. REVENDICATIONS :

   1. Un appareil informatique (102) qui met en œuvre une plate-forme côté demande, l’appareil informatique comprenant :

   un processeur (104) ;

   au moins un dispositif de mémoire (106, 110) accessible par le processeur ; et une interface de communication de données (112) associée au processeur de manière opérationnelle, dans lequel le dispositif de mémoire contient un corps d’instructions de programme (114) incluant des instructions qui, lorsqu’elles sont exécutées par le processeur, amènent l’appareil informatique à mettre en œuvre un procédé de calcul distribué en temps réel comprenant les étapes de :

   réception (802), à partir d’un serveur d’échange de publicités (122) via l’interface de communication de données, d’un message (210) comprenant une demande d’offre qui inclut des informations sur le site et des informations sur l’utilisateur liées à un encart publicitaire disponible ;

   génération (804) d’une liste d’offres classée (610) choisie à partir d’une base de données d’offres active (606), dans laquelle le classement des offres se base au moins en partie sur les informations sur le site et les informations sur l’utilisateur ;

   pour chaque offre dans la liste classée, le calcul (700) d’une estimation de niveau d’offre de probabilité d’interaction de l’utilisateur avec l’offre ;

   pour au moins une combinaison d’offres, incluse dans la liste classée, le calcul (910) d’un prix d’offre de niveau publicitaire, dans lequel le prix d’offre de niveau publicitaire se base au moins sur les estimations de niveau d’offre calculées de probabilité d’interaction de l’utilisateur, les revenus d’interaction de niveau d’offre correspondants, et un paramètre d’agressivité (808) qui contrôle l’agressivité de la tarification des offres ; et transmission (1008), au serveur d’échange de publicités (122), via l’interface de communication de données, d’un message (214) comprenant une réponse d’offre incluant une publicité à prix d’offre (810) qui comprend la combinaison des offres et du prix d’offre de niveau publicitaire.
2. 2. L’appareil de la revendication 1 selon lequel le paramètre d’agressivité (808) comprend une valeur de limitation « conservatrice », pour laquelle les instructions de programme amènent l’appareil informatique à mettre en œuvre l’étape de calcul (910) du prix d’offre de niveau publicitaire basé sur une moyenne pondérée des estimations calculées de niveau d’offre de probabilité d’interaction de l’utilisateur, selon laquelle les pondérations de la moyenne pondérée comprennent les revenus d’interaction de niveau d’offre correspondants.
3. 3. L’appareil de la revendication 1 ou 2 selon lequel le paramètre d’agressivité (808) comprend une valeur limite « agressive », pour laquelle les instructions de programme amènent l’appareil informatique à mettre en œuvre l’étape de calcul (910) du prix d’offre de niveau publicitaire basé sur la valeur la plus élevée d’un produit d’estimation calculée de niveau d'offre de probabilité d’interaction d’utilisateur et de revenu d’interaction de niveau d’offre correspondant.
4. 4. L’appareil de l’une quelconque des revendications 1 à 3, selon lequel le paramètre d’agressivité (808) comprend une valeur numérique continue a, pour laquelle les instructions du programme amènent l’appareil informatique à mettre en œuvre l’étape de calcul (910) du prix d’offre de niveau publicitaire PO sur la base d’une formule :

   dans lequel :

   ERPO=RoP

   R = [Ri, R2.....R_n] est un vecteur de revenus d’interactions de niveau d’offre généré à partir de l’interaction de l’utilisateur avec chaque offre 0/ (/=1,2, ..., n) dans la liste classée des offres

   P = [Pi, P2, ..., P_n] est un vecteur des estimations calculées de niveau d’offre de probabilité d’interaction de l’utilisateur n est un nombre d’offres à inclure dans l’encart publicitaire disponible, et *°’ représente un produit de vecteurs dans le sens de l’élément.
5. 5. L’appareil de l’une quelconque des revendications 1 à 4 selon lequel les revenus d’interactions de niveau d’offre comprennent les valeurs du coût par clic (CPC) convenues entre un opérateur de la plate-forme côté demande et les annonceurs respectifs des offres sélectionnées dans la base de données d’offres active (606).
6. 6. Un procédé de calcul distribué en temps réel mis en œuvre par ordinateur comprenant :

   la réception (802), d’un serveur d’échange de publicités (122) via un réseau de communication de données (116), d’un message (210) comprenant une demande d’offre qui inclut des informations sur le site et des informations sur l’utilisateur liées à un encart publicitaire disponible ;

   génération (804) d’une liste d’offres classée (610), sélectionnées dans une base de données d’offres active (606), dans laquelle le classement des offres se base au moins en partie sur les informations sur le site et les informations sur l’utilisateur ;

   pour chaque offre dans la liste classée, calcul (700) d’une estimation de niveau d’offre de probabilité d’interaction de l’utilisateur avec l’offre ;

   pour au moins une combinaison d’offres, incluses dans la liste classée, le calcul (910) d’un prix d’offre de niveau publicitaire, dans lequel le prix d’offre de niveau publicitaire se base au moins sur les estimations de niveau d’offre calculées de probabilité d’interaction de l’utilisateur, les revenus d’interaction de niveau d’offre correspondants, et un paramètre d’agressivité (808) qui contrôle l’agressivité de la tarification des offres ; et transmission (1008), au serveur d’échange de publicités (122) via le réseau de communication de données (116), d’un message (214) comprenant une réponse d’offre incluant une publicité à prix d’offre (810) qui comprend la combinaison des offres et du prix d’offre de niveau publicitaire.
7. 7. Le procédé de la revendication 6 selon lequel le paramètre d’agressivité (808) varie entre deux limites.
8. 8. Le procédé de la revendication 7, selon lequel une première des deux limites est une limite d’offre « conservatrice » basée sur une moyenne pondérée des estimations de niveau d’offre calculées de probabilité d’interaction de l’utilisateur.
9. 9. Le procédé de la revendication 8 selon lequel les pondérations de la moyenne pondérée comprennent les revenus d’interaction de niveau d’offre correspondants.
10. 10. Le procédé de l’une quelconque des revendications 7 à 9 selon lequel une deuxième des deux limites est une limite d’offre « agressive » basée sur la valeur la plus élevée d’une combinaison d’estimation de niveau d’offre calculée de probabilité d’interaction de l’utilisateur et du revenu d’interaction de niveau d’offre correspondant.
11. 11. Le procédé de la revendication 10 selon lequel la combinaison comprend un produit.
12. 12. Le procédé de l’une quelconque des revendications 7 à 11, selon lequel chacune des deux limites est finie.
13. 13. Le procédé selon l’une quelconque des revendications 7 à 12 selon laquelle le paramètre d’agressivité (808) varie en continu entre ces deux limites.
14. 14. Le procédé de l’une quelconque des revendications 6 à 13, selon lequel le calcul (700) de chaque estimation de niveau d’offre de probabilité d’interaction de l’utilisateur avec l’offre comprend l’exécution d’un modèle d’apprentissage automatique entraîné (314).
15. 15. Le procédé de la revendication 14, selon lequel le modèle d’apprentissage automatique (314) est entraîné à l’aide d’un ensemble de données comprenant des événements de placement de contenu agrégé mis en correspondance avec des éléments d’interaction d’utilisateur agrégés.
16. 16. Le procédé de la revendication 15, selon lequel le modèle d’apprentissage automatique est entraîné en continu ou périodiquement en ligne.
17. 17. Un programme d’ordinateur comprenant des instructions de code de programme pour exécuter les étapes du procédé selon les revendications 6 à 15 lorsque ledit programme est exécuté sur un ordinateur.