device and method for tracking a user accessing a website

Abstract

Device and Method for Tracking a User Accessing a Website. The invention relates to a method and a system (PT1) for tracking a user (UR1) accessing a website (ST1). The method comprises: receiving, from a client terminal (T1), user data (DT3) representative of the user (UR1) accessing the website via a browser client (12); obtaining, from the user data (DT3), at least one digital fingerprint (FP1) of the user; obtaining behavioral data (DT4) representative of the user's behavior on the website (ST1); and recording user history data (DH1) from the behavioral data (DT4) in association with said at least one digital fingerprint (FP1) to enable tracking of the user's behavior on the website (ST1). Figure for the abstract: Fig. 1.

Description

Title of the invention: Device and method for tracking a user accessing a website technical field

[0001] The invention relates to the field of website tracking and more particularly to tracking the behavior of a user accessing a website, regardless of the resources used by the client to view the website. Technological background

[0002] It is essential for website owners, particularly e-commerce sites, to be able to know which visitors access their site, how they access it, and what they do during their visits. Numerous website tracking tools (also called audience tracking or "web tracking" tools) have been developed in recent years to enable such tracking.

[0003] Website tracking refers to various techniques for tracking internet users as they browse websites. In other words, these techniques aim to follow a customer's progress on a website. A majority of websites thus use audience tools, such as Google Analytics® or Google Adsense®, which allow the aggregation of information about a site's users, including visitors' IP addresses (to determine their geographical location), visitor behavior (to determine the links they click on, the time spent on each page, or the pages that are viewed), or information about visitors (interests, etc.).

[0004] Website tracking can be implemented for various reasons, including statistical, marketing, or commercial purposes. With this tracking information, website owners can monitor their site's performance, analyze customer behavior, understand their interests, and adapt their website content accordingly, particularly advertising content. E-commerce sites use this type of tool to create consumer profiles and encourage conversions leading to sales. By identifying the web pages that perform best, e-commerce businesses can direct visitors to them or apply the same strategy to other pages.

[0005] Website tracking uses various tools but their capabilities are currently limited and do not allow for satisfactory tracking of users, especially when they use means of protection that thwart such tracking.

[0006] Furthermore, current tracking solutions do not comply with certain rules regarding the confidentiality of personal data (such as the general regulations of the data protection, known as "GDPR", in Europe).

[0007] When a website user authenticates themselves (for example, using a customer ID and password), the website owner can easily track the user and monitor their behavior. However, a user may visit a website without authenticating, either because the site does not require authentication or because the user prefers to visit the site anonymously.

[0008] It is common to use hidden tracking tools or trackers on visited websites. For example, the use of cookies (also called "tracking cookies") is commonly employed to track website users. A cookie is a file (usually small) that is stored by a server on a user's device when they visit a website. This file is automatically sent back during subsequent visits to the same website. This file contains identifying information (shopping cart ID, session ID, etc.). Some types of cookies are necessary for functionalities expressly requested by the user, while others generally require the user's consent before visiting the site.

[0009] However, the use of cookies is not always appreciated by users, who sometimes tend to refuse their use. Furthermore, some users use secure web browsers that block cookies to ensure user privacy while browsing. Moreover, the proliferation of devices makes tracking users difficult, since the same user may use different devices (tablet, laptop, smartphone, etc.) to access the same website multiple times.

[0010] The quality of user tracking on a website therefore varies greatly depending on the situation, particularly according to the resources used by a user to access a website or the level of protection afforded to the user during their access. It is therefore currently difficult, if not impossible, to effectively track a user's behavior and interests on a website during one or more visits over time. Summary of the invention

[0011] One of the objects of the present invention is to solve at least one of the problems or deficiencies of the technological background described above.

[0012] In particular, an object of the present invention aims to enable efficient monitoring of a website, regardless of the resources used (browsers, protections, terminal, etc.) by users to access the website.

[0013] In particular, an object of the present invention aims to efficiently track a user when accessing a website.

[0014] To this end, a first aspect of the invention relates to a method for tracking a website, implemented by a tracking system, said method comprising: a) receiving, from a client terminal, user data representative of a user accessing the website via a browser client; b) obtaining, from user data, at least one digital fingerprint of the user; c) obtaining behavioral data representative of user behavior on the website; and d) recording of user history data from behavioral data in association with said at least one digital fingerprint to enable tracking of user behavior on the website.

[0015] The method according to the first aspect of the invention may include other features which may be taken separately or in combination, in particular among the following embodiments.

[0016] According to a particular embodiment, the process comprises: - in response to a request for access from the browsing client to the website, sending an identification module causing the execution of said identification module by the browsing client, in which user data is received from the identification module.

[0017] According to a particular embodiment, the user data comprises at least one of the following: - system data representative of system properties of the client terminal; and - browser data representative of properties of the browsing client.

[0018] According to a particular embodiment, said at least one digital fingerprint comprises at least one of the following: - a first digital fingerprint, called a system fingerprint, generated from system data; and - a second digital fingerprint, called a browser fingerprint, generated from browser data.

[0019] According to a particular embodiment, the method comprises: - generation of profile data by monitoring user behavior on the website, the profile data being representative of a consultation of at least one web page or web object; behavioral data being obtained at least from said profile data.

[0020] According to a particular embodiment, the monitoring includes: - detection that the user accessing the website has viewed a web page, or a web object; - in response to said detection, updating of a counter representing a consultation time, or a number of consultations, of at least one of the following: • said web page or said web object; • at least one piece of information constituting said web page or said web object.

[0021] According to a particular embodiment, the profile data are representative of a consultation of at least one web page, or web object, defined by at least one element of a taxonomy; in which the updated counter is representative of a consultation time, or a number of consultations, of said at least one element of the taxonomy.

[0022] According to a particular embodiment, the behavioral data includes application data and an identifier, associated with at least one application executed by the client terminal,

[0023] application data and identifier being recorded in history data in association with behavioral data and said at least one digital fingerprint.

[0024] According to a particular embodiment, the recording (d) of historical data includes sending, to a customer relationship management platform, behavioral data in association with said at least one digital fingerprint for historization as historical data in a database.

[0025] According to a particular embodiment, steps a) to d) are repeated for each among a plurality of user visits to the website, in which the user's history data is updated from the behavioral data obtained in association with each digital fingerprint corresponding to said user.

[0026] According to a particular embodiment, the process comprises: - collection of form data submitted by the user accessing the website; and - recording of form data in history data in association with said at least one digital fingerprint and behavioral data.

[0027] According to a particular embodiment, the process comprises: - obtaining decoded data by decoding a data-enriched link through which the user accesses the website; - recording of decoded data in history data in association with said at least one digital fingerprint.

[0028] In a particular embodiment, the different stages of the tracking process according to the first aspect of the invention are determined by instructions for computer programs. Consequently, a second aspect of the invention relates to a computer program on an information medium (or recording medium), this program being capable of being implemented in a tracking device or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a tracking process according to the first aspect of the invention.

[0029] Thus, the method of the first aspect of the invention can be implemented by means of a non-volatile memory storing computer program instructions and by means of a processor executing these instructions.

[0030] The computer program according to the second aspect can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0031] A third aspect of the invention relates to an information carrier (or recording medium) readable by a processor or by a computer, and comprising instructions of a computer program according to the second aspect of the invention.

[0032] The information medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a rewritable non-volatile memory or ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk.

[0033] On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be downloaded onto an Internet-type network.

[0034] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0035] A fourth aspect of the invention relates to a tracking device (or monitoring device) configured to implement the tracking method of the first aspect of the invention. For example, the fourth aspect provides a tracking device comprising a memory associated with at least one processor configured to implement the steps of the tracking method according to the first aspect of the invention.

[0036] Thus, according to a particular example, the fourth aspect of the invention relates to a website tracking device, comprising: - a receiving module configured to receive, from a client terminal, user data representative of a user accessing the website via a browser client; - a first acquisition module configured to obtain, from user data, at least one digital fingerprint of the user; - a second retrieval module configured to obtain behavioral data representative of user behavior on the website; and - a history module configured to update user history data from the behavioral data in association with said at least one digital fingerprint to enable tracking of user behavior on the website.

[0037] It should be noted that the various embodiments defined above (as well as those described below) in relation to the method of monitoring the first aspect of the invention and the associated advantages apply in a similar way to the device for monitoring the fourth aspect of the invention.

[0038] For each step of the tracking process, the tracking device of the invention may include a corresponding module (or unit) configured to carry out said step.

[0039] According to one embodiment, the invention is implemented by means of software and / or hardware components. In this context, the term "module" (or unit) in this document may refer to a software component, a hardware component, or a set of hardware and software components. For example, the modules defined in this document correspond to software components.

[0040] A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or set of functions, as described in this document for the module concerned. Such a software component can be executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of that physical entity (memory, storage media, communication buses, electronic input / output cards, user interfaces, etc.).

[0041] Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions, as described in this document for the module concerned. It may be a programmable hardware component or one with an integrated processor for software execution, for example, an integrated circuit, a smart card, a memory card, an electronic card for executing firmware, etc.

[0042] The present invention advantageously allows for targeted (or personalized) and effective tracking over time of a user's behavior on a website web tracking is available regardless of the resources (client terminal, browser, etc.) used by the user to access the website. Such tracking is made possible, in particular, by linking user behavior data to browsing history data. Associating behavior data with a digital fingerprint ensures that the user is reliably identified, if necessary, on each visit to the website, even if the user employs methods to anonymize their website access (for example, a browser without cookies) or uses different client terminals during multiple visits.

[0043] The present invention makes it possible, in particular, to offer a CRM (Customer Relationship Management) type system that recognizes (or qualifies) website visitors by using their digital fingerprints as identifiers, including unknown visitors who are not identified to the site (by login / password, or by cookie, for example) and who may use anti-tracking protections or different devices during their visits to the site. The same user can thus be recognized on each visit to a website without the user's identity being known (no obligation to collect personal data (name, date of birth, etc.) or cookies).

[0044] If a user using two different terminals to access the same website authenticates with both terminals (for example by means of forms), it is then possible to associate in the history data this user with the two digital fingerprints generated for the two terminals.

[0045] This allows us to track the evolution of user behavior data over time and deduce relevant information about that user's behavior on the site, such as the number of site visits, the user's path on each site visit, the user's interests, their consumption habits, etc. The invention makes it possible to centralize a set of relevant user information, in particular the aforementioned behavioral information.

[0046] By ensuring targeted and reliable user tracking over time, the website owner can better understand the user's profile (needs, interests, etc.) and thus adapt the website content accordingly, for example, by creating or adapting content based on the user's profile (creating offers or advertising content tailored to the user's interests, etc.). This allows for the optimization of a website's performance, regardless of the domain or objective. The system of the invention, for example, makes it possible to optimize sales for an e-commerce site or to optimize advertising revenue for any website.

[0047] In an e-learning system, for example, the system of The invention allows for better tracking of user behavior and therefore a better understanding of learners' interests. In a multimedia content sharing platform, the invention allows for the adaptation of multimedia content offered to the same user over time, based on their preferences. Brief description of the drawings

[0048] Other features and advantages of the present invention will become apparent from the description of the particular and non-limiting embodiments of the present invention below, with reference to the attached Figures 1 to 5, in which:

[0049] [Fig-1] Fig. 1 schematically represents an environment comprising an client terminal and a tracking device, according to at least one embodiment of the invention (client-side configuration);

[0050] [Fig.2] Fig.2 schematically represents the tracking device of Fig.1, according to at least one embodiment of the invention;

[0051] [Fig.3] The [Fig.3] represents, in the form of a diagram, the steps of a monitoring process according to at least one embodiment of the invention;

[0052] [Fig.4] Figure 4 represents, in diagram form, the steps of a monitoring process according to at least one embodiment of the invention; and

[0053] [Fig.5] Fig.5 schematically represents an environment comprising a client terminal and a tracking device, according to at least one embodiment of the invention (server-side configuration). Description of the implementation methods

[0054] Examples of implementation of the invention will now be described in the following with joint reference to Figures 1-5. Unless otherwise indicated, common or similar elements in several figures bear the same reference symbols and have identical or similar characteristics, so that these common elements are generally not described again for the sake of simplicity.

[0055] The terms "first(s)" (or first(s)), "second(s)", etc.) are used in this document by arbitrary convention to allow identification and distinction of different elements (such as operations, devices, etc.) implemented in the embodiments described below.

[0056] As already stated, the present invention relates in particular to devices and methods for monitoring a website. The present invention applies to any website (or site), such as an Internet site, for example, or a site implemented on a network other than the Internet (Intranet site, etc.). The invention relates in particular, but not exclusively, to monitoring a merchant site (or e-commerce site).

[0057] As is known, a website (for example, an internet site) comprises at least one web page accessible via a web address (for example, a URL address for Uniform Resource Locator (URL). Each web page can have variable content accessible to a user via a suitable web browser. In particular, a web page can contain one or more web objects, such as images, text, files (e.g., PDFs), emails, etc. A website can comprise multiple web pages linked together by hyperlinks within the site. Viewing a website or a web page is called a visit (or viewing). A website is hosted by at least one web server, commonly called a content management system (or CMS), which is accessible via a suitable communication network, such as the Internet, a local intranet, or any other network such as the Tor® network.

[0058] A client-server protocol, for example HTTP (Hyper Text Transfer Protocol), is generally used to manage communication between a web server and a client. To access a website, the client uses a web browser, namely software that allows users to view and display websites or web pages. The present invention applies to various types of web browsers, for example, a web browser, an application (for example, an Android® or iOS® application), or an email client (for example, Outlook® or Thunderbird®) that can be connected to a network or the web. An email client, for example, allows users to view emails, which are web objects, when that email client is connected to a network or the web.

[0059] The invention relates in particular to a tracking method, implemented by a tracking device, for tracking a website or, more precisely, for tracking a user's behavior on a website. This method relies in particular on obtaining at least one representative digital fingerprint of a user accessing the website and on updating (or recording) historical data including user behavior data in association with the digital fingerprint. This digital fingerprint makes it possible to identify and track a user's behavior during one or more separate visits to the website, regardless of the resources used by the user to access the website.

[0060] According to different embodiments, the monitoring process comprises: a) receiving, from a client terminal, user data representative of a user accessing the website via a browser client; b) obtaining, from user data, at least one digital fingerprint of the user; c) obtaining behavioral data representative of user behavior on the website; and d) updating user history data from com data behavior in association with said at least one digital fingerprint to enable tracking of user behavior on the website.

[0061] Other aspects and advantages of the present invention will become apparent from the embodiments described below with reference to the drawings mentioned above.

[0062] Fig. 1 schematically represents an environment comprising a PT1 tracking device capable of cooperating with a user's URL client terminal Tl. The PT1 device and the client terminal Tl together form a system denoted S Y1 (client-side configuration).

[0063] More specifically, the PT1 tracking device is a platform, system, or computer system (including, for example, a server) configured to manage a website designated STI. This platform (software and / or hardware) constitutes, in this example, a content management system (CMS) for the STI website. The PT1 platform is hereafter referred to as the "system" or "CMS system" for illustrative purposes only.

[0064] The PT1 system manages user (or client) access, including that of user UR1, to the STI website. As already mentioned, the content and nature of this STI website may vary. The STI website comprises at least one web page 32, which itself contains content, namely at least one web object 34. The STI website may thus comprise a plurality of web pages 32 linked together by hyperlinks. Each web page 32 may include various types of web objects, such as images, text, emails, files, data layers, etc. A web page 32 or a web object may, for example, correspond to a product or article presented by the owner of the STI website.

[0065] The STI website is for example a merchant site (of the e-commerce type) although the invention applies more generally to any website containing one or more web objects that can be consulted by a UR1 client using a navigation client.

[0066] As described later in specific examples, identifiers denoted respectively ID1 and ID2 can be assigned to web pages 32 and web objects 34 ([Fig. 1]). Furthermore, web pages 32 and / or web objects 34 can be defined according to at least one taxonomy 36 (for example, a taxonomy of pages and / or a taxonomy of objects). In particular, each web page 32 and web object 34 can be defined by (or correspond to) at least one element of a taxonomy 36. An element of the taxonomy 36 can be qualified, for example, by a category or label. For illustrative purposes only, a web page 32 can belong to (or be defined by) at least two taxonomy elements 36 (or any one of these two elements), namely a category element (e.g., category "shirt", "T-shirt", etc.) and a tag element (e.g., "short sleeve", "long sleeve", "new season", "last season", etc.).The structure of taxonomy 36 can be adapted on a case-by-case basis.

[0067] User UR1 uses a web browser 12 implemented in a client terminal Tl to access (or visit) the STI website. With this web browser 12, the user can view a web page 32 or a web object 34 of the STI website. As already mentioned, the type and configuration of the web browser 12 may vary depending on the case, particularly the configuration of the client terminal Tl (operating system, settings, etc.). The web browser 12 allows cooperation with the PT1 system in a client-server manner to access the STI website. For this purpose, the web browser 12 can be, for example, a web browser, an application, or an email client.

[0068] The client terminal Tl used by the UR1 client may vary depending on the case. It may be, for example, a PC, a laptop, a tablet, a smartphone or any other computer equipment allowing access to the STI website made available by the PT1 CMS system.

[0069] In the example considered, the terminal Tl and the system PT1 communicate with each other through a communication network denoted NT1, this network being for example the Internet, an intranet network or any other network allowing communication between a client terminal and a server.

[0070] For example, the UR1 client can access the STI website by activating (or clicking on) a web link configured to direct the client to that website. Alternatively, the UR1 client may visit another ST2 website, referred to as an intermediary or transitory site (for example, a social networking site or other), which includes a link that the UR1 user can activate to be redirected to the STI website.

[0071] As illustrated in [Fig. 1], the PT1 system may include a processor 20 and a PG3 control module (also called a control unit, control agent, or tracking module / unit / agent). As already indicated, the PG3 control module may be a software and / or hardware component.

[0072] In a particular example, the PG3 module is a computer program executed by the processor 20. For this purpose, the PT1 system may include non-volatile memory (not shown) in which the PG3 control module is stored. The non-volatile memory in which the PG3 control module is stored then constitutes a storage medium (or information medium) according to a particular embodiment of the invention, this medium being readable by the PT1 system (and more specifically by the processor 20). This PG3 computer program may thus include instructions for executing the steps of a monitoring method of the invention as described below in particular embodiments.

[0073] According to a particular example, the processor 20 is therefore configured to execute the instructions of the computer program PG3 in order to carry out steps in the tracking process. For this purpose, the processor 20 can use volatile RAM-type memory. (not shown) of the PT1 system, for example, memory integrated into the processor and / or memory external to the processor, to perform the various operations and functions necessary for the operation of the PT1 system, including to execute the PG3 computer program during the implementation of the tracking method of the invention.

[0074] As described in more detail below, the PT1 system can process and store data in at least one non-volatile memory location (not shown) of the PT1 system, in particular DT4 data and at least one FP1 digital fingerprint. According to one particular example, the PT1 system can also process and store FMI form data submitted by the user UR1 during a visit to the STI website. The nature and use of this various data are described later in specific embodiment examples.

[0075] As illustrated in [Fig. 1], the client terminal T1 may include a processor 10, an analysis module PG1, and a control module (also called a control unit or tracking module / unit) PG2. Like PG3, the PG1 and PG2 modules may be software and / or hardware components. It should be noted that embodiments are possible in which the analysis module PG1 is not implemented by the terminal T1.

[0076] According to a particular example, the PG2 module, and optionally the PG1 module, are computer programs executed by the processor 10 within the navigation client 12. In other words, the PG2 and possibly PG1 modules are part of (or are implemented by) the navigation client 12 and are executed by it. To this end, the client terminal T1 may include non-volatile memory (not shown) in which the PG1 and PG2 modules are stored. The rewritable volatile memory in which the PG2 control module (and possibly also PG1) is stored then constitutes a storage medium (or information medium) according to a particular embodiment of the invention, this medium being readable by the client terminal T1 (and more specifically by the processor 10).The computer program PG2, and possibly PG1, may thus include instructions for executing the steps of a control method of the invention as described below in particular embodiments. To this end, the processor 10 may use volatile RAM-type memory (not shown) of the terminal Tl, for example, memory integrated into the processor and / or memory external to the processor, to perform the various operations and functions necessary for the operation of the terminal Tl, including executing the computer programs PG1 and PG2 during the implementation of the control method of the invention.

[0077] According to specific examples, the PT1 system is capable of cooperating with a PT4 platform (or device). This PT4 platform is configured to store DH1 historical data determined from DT4 data, transmitted by the PT1 system, as described in more detail later.

[0078] According to specific examples, the environment may further include at least one of the PT2 and PT3 platforms (or devices, or systems) described below. The PT2 platform is a performance analysis platform (for example, of the Google Analytics® or Matomo®, Piano Analytics® type) implemented by at least one server, this platform (software and / or hardware) being configured to track or analyze the performance of a website, namely the STI website in the examples considered. To do this, the PT2 platform cooperates with the client terminal T1, via the NT1 network in this example, to track the performance of the STI website when the user UR1 accesses the STI website via their web browser 12. However, embodiments of the invention without the PT2 platform are possible.

[0079] In a specific example, the PT3 platform is a platform (software and / or hardware) configured for processing form data, such as FMI data, which may be submitted by the user UR1 during a visit to the STI website via the browser client 12. The PT3 platform can be implemented by at least one server. This PT3 platform constitutes, for example, a customer relationship management (CRM) system. This type of system allows for the management of relationships with contacts, for example, users of the STI website in this example. This PT3 platform is, for example, capable of storing, processing, and / or exchanging contact data relating to users of the STI website, this contact data being determined, in particular, from form data collected via one or more forms implemented on the STI website.However, examples of implementing the invention without the PT3 platform are possible.

[0080] As shown in [Fig.2] according to a particular embodiment, the processor 20 controlled by the computer program PG3 here implements a number of modules, namely: a receiving module MD2, a first obtaining module MD4, a second obtaining module MD6 and a history (or history management) module MD8.

[0081] More specifically, the MD2 receiving module is configured to receive, from the client terminal Tl, DT3 user data representative of the user UR1 accessing the STI website via the navigation client 12.

[0082] The first MD4 acquisition module is configured to obtain, from the DT3 user data, at least one FP1 digital fingerprint of the user URL

[0083] The second MD6 acquisition module configured to obtain DT4 behavioral data representative of user UR1 behavior on the STI website.

[0084] The MD8 history module is configured to update (or record) DH1 history data of user UR1 from DT4 behavior data in association with said at least one FP1 fingerprint to enable tracking of user UR1 behavior on the STI website.

[0085] The configuration and operation of the MD2-MD8 modules implemented by the PT1 CMS system will be shown more precisely in the embodiments described below with reference to Figures 3 and 4. The MD2-MD8 modules as shown in [Fig. 2] represent only one non-limiting implementation of the invention. As described later in alternative embodiments, the MD2-MD8 modules can be implemented in whole or in part by a platform (or system) other than the PT1 system, such as, for example, in the PT4 system or in the navigation client 12 of the TL terminal.

[0086] In a particular example, the MD2 receiving module is executed by the PG3 control module, while the MD4, MD6, and MD8 modules are executed by a different (external) system from PT1 (for example, by another platform or another server, such as PT4). In this case, PG2 and / or PG3 are configured to collect all the data necessary for the processing performed by the MD4, MD6, and MD8 modules.

[0087] Generally, for each step of the monitoring process implemented by the PT1 system, the PT1 system may include a corresponding module configured to carry out said step.

[0088] The method of monitoring the invention, implemented by the PT1 system (and more particularly by the PG3 control module) illustrated in figures 1-2, is now described below in particular embodiments together with figures 3-4.

[0089] Figure 3 schematically represents steps performed by the PT1 system, and more specifically by the PG3 control module, during a tracking process according to a particular embodiment. For this purpose, the processor 20 implements, for example, the PG3 control module.

[0090] In this example, it is assumed that user UR1 uses their client terminal Tl to access the STI website managed by the CMS PT1 system. User UR1 accesses the STI website via the navigation client 12. The navigation client 12 manages the interactions between user UR1 and the STI website. For example, it allows one or more web pages 32 of the STI website to be displayed on a display screen (not shown) of the client terminal TL.

[0091] Access to the STI website can be achieved in various ways. For example, user UR1 can enter a URL (or domain name) of the STI website into their web browser. As an example, user UR1 activates a hyperlink (or web link) pointing to the STI website (for example, by clicking on this link). This The hyperlink defines a web address (e.g., URL) of the STI website. Thus, the web browser 12 uses the address defined by the hyperlink to request access to the STI website from the PT1 system.

[0092] According to one example, user UR1 accesses the STI website via an intermediary site ST2 (for example, a social network or other), different from STI, on which a hyperlink is provided, for example, a data-rich link. By activating this hyperlink, the user is redirected via their browser client 12 to the STI website.

[0093] During a reception step S2 ([Fig. 3]), the PT1 system receives, from the client terminal T1, DT3 user data representative of the user UR1 accessing the STI website via their browser client 12. The DT3 user data allows the PT1 system to recognize (or identify) the user URL. As described below, this recognition does not require obtaining personal data (name, surname, date of birth, etc.) from the user. For this purpose, it is assumed in this example that the control module PG2 has previously collected the DT3 user data within the browser client 12, and this data is then transmitted to the PT1 system.

[0094] As already mentioned, one problem lies in the fact that it can be difficult to recognize or identify the user UR1, particularly if they are using an unknown or unusual client terminal Tl, or if their browser implements a security mechanism (e.g., an ad blocker, a web browser that limits third-party cookies, etc.) that restricts access to user information. Collecting and subsequently processing user data DT3 makes it possible to accurately identify the user UR1, regardless of the resources they use to access the STI website.

[0095] In the examples considered, it is the PG2 control module, executed by or loaded in the navigation client 12, which collects and sends the DT3 user data to the PT1 system via the NTL network. This PG2 control module is provided by the PT1 system or by the PG3 module, for example on detection of an access request from the navigation client 12 to the STI website.

[0096] According to a particular example, prior to the S2 reception step, the PT1 system receives an access request from the navigation client 12 to access the STI website. In response to this access request, the PT1 system or the PG3 control module triggers the sending of the PG2 control module (or data enabling the installation of the PG2 control module) to the client terminal Tl, thereby causing the navigation client 12 to execute this PG2 module. The client terminal Tl thus receives the PG2 control module and then executes it within the navigation client 12, this PG2 control module then being responsible for sending the user data. DT3 (and where applicable ID3) to the PT1 system to enable recognition (or identification) of user UR1.

[0097] The DT3 user data received (S2) by the PT1 system may be or include any data to which the browsing client 12 grants access. This DT3 user data may include, for example, a cookie ID3 identifier (e.g., a cookie from Google Analytics®) as illustrated in [Fig. 1] and / or layer data (or “data layers”) implemented by other applications (such as PG1).

[0098] DT3 user data includes, for example, DT3a system data, or DT3b browser data, or both ([Fig. 1]). For illustrative purposes in what follows, DT3 user data is assumed to include DT3a system data and DT3b browser data, although variations are possible.

[0099] The DT3a system data are representative of system properties (or technical characteristics) of the client terminal TL. This DT3a system data characterizes, for example, the client terminal Tl, in particular software and / or hardware resources implemented in the terminal TL. The DT3a system data characterizes, for example, at least one of the following: the client terminal Tl (for example, the terminal type, the terminal version, the brand, the terminal extensions, its storage type, etc.), the terminal processor 10 (the processor type and / or version, for example), the operating system implemented by the processor 10 (for example, the operating system type and / or version), the display screen of the terminal Tl (resolution and / or screen size, for example), its IP address, or even its MAC address, etc.

[0100] According to a particular example, the navigation client 12 is configured to collect DT3a system data from the terminal Tl, for example during an installation phase of the navigation client 12 in the terminal TL

[0101] DT3b browser data represents properties (or technical characteristics) of the browser client 12. This DT3b data characterizes, for example, a browser client type 12, a browser client version 12 (e.g., type / version of a web browser), and / or at least one browser client extension (or plugin). For illustrative purposes only, the web browser type might be "Win32" and its version (buildID) "20181001000000". The number and type of DT3b browser data may vary from case to case.

[0102] According to a particular example, the navigation client 12 is configured to obtain DT3b browser data. To do this, the navigation client 12 can request such DT3b browser data from the terminal Tl (the terminal Tl system can be configured to provide or not provide the requested DT3b data).

[0103] Using both DT3a system data and DT3b browser data enhances the PT1 system's ability to uniquely recognize user UR1 accessing the STI website. Combining this data allows for reliable recognition of user UR1 even if, for example, they change their browser client or if the operating system of terminal Tl is updated between visits to the STI website.

[0104] According to a particular example, DT3 user data includes at least one ID3 identifier (also called an application identifier) ​​of an application or service run by the browser client 12 (for example, a cookie identifier from the Google Analytics® application) ([Fig. 1]).

[0105] Such an ID3 identifier may include, for example, cookie data, i.e. data contained in cookies stored in the client terminal TL. This cookie data may be collected by the browsing client 12 and included in the DT3 user data transmitted to the PT1 system.

[0106] According to a particular example, DT3 user data includes DT4b application data, resulting from the execution of at least one application in the client terminal Tl, possibly in association with DT3a and / or DT3b, or even ID3.

[0107] According to a particular example, during the reception step S2, the PT1 system receives from the client terminal T1, in addition to user data DT3, application data DT4b. This application data D4b includes information characterizing (or defining) interactions of the user UR1 with the STI website, for example the selection of a web page 32 or a web object 34. By way of example, the application data DT4b may include layer data (called "data layer") which is included in the STI website and allows the detection of user interactions (or events), such as scrolling a web page, clicking on a page or a web object, etc.

[0108] The use of DT4b application data makes it advantageous to perform precise tracking, and therefore to better understand a visitor's journey on the STI website and their areas of interest, such as web pages and web objects viewed. This DT4b application data can, for example, make it possible to determine how the user UR1 accesses the STI website (for example via a UTM tag for "Urchin Tracking Module", i.e., a URL enriched with data).

[0109] According to a particular example, the PG1 analysis module generates DTI identification data (including, for example, an application identifier ID3 as already described) and / or DT2 performance data within the navigation client 12 while the user UR1 accesses the STI website. This data is then the result of the execution of the PG1 module. The PG1 module can, for example, generate data a cookie containing an ID3 identifier resulting from the execution of PG1. Alternatively, the analytics module (Tags Management, e.g., Google Tag Management) PG1 can contain such data within the PT1 system code. The PG1 analytics module can be configured to transmit DTI and / or DT2 data (possibly with ID3) to the PT2 system.

[0110] The DTI identification data may include, for example, data characterizing the navigation client 12, geolocation data of the client terminal Tl, the IP address of the client terminal Tl, etc. The DT2 performance data characterizes interactions of the user UR1 via the navigation client 12 with web pages 32 and / or web objects 34 of the STI website, for example the time spent on a web page 32, the number of times a web page 32 is viewed, the web objects 34 that the user UR1 clicked on or viewed, the path of the pointer (mouse) on a web page 32 displayed by the client terminal Tl (mouse tracking function), and more generally all information enabling analysis of the performance of the STI website.

[0111] As shown below in a specific example, the ID3 identifier can, in particular, allow a link to be established between the PT2 and PT4 systems so as to enrich the data of PT4 with the data of PT2. However, embodiments not implementing the DTI and DT2 data are possible.

[0112] During an acquisition step S4 ([Fig.3]), the PT1 system obtains or determines at least one FP1 digital fingerprint of the user from the DT3 user data. This or these FP1 digital fingerprints (also called "fingerprints" or "prints") constitute one or more identifiers of the user UR1, preferably unique identifiers.

[0113] According to one example, the PT1 system generates the FP1 digital fingerprint(s) in S4 from the DT3 user data. The larger the amount of DT3 user data used, the more reliable the FP1 digital fingerprints are, thus enabling the identification of the user UR1 with a high level of accuracy. In particular, taking into account DT3a system data and D3b browser data (and possibly also the ID3 identifier) ​​to generate the FP1 fingerprints improves the level of identification reliability.

[0114] According to one variant, the DT3 user data provided by the PG2 control module includes the FPL digital fingerprint(s). The PG3 control module then retrieves the FP1 digital fingerprint(s) from the received DT3 user data (S4). In this case, the PG2 control module, for example, generates the FP1 digital fingerprint(s) from all or part of the DT3 user data. The FP1 fingerprint(s) are then transmitted along with the DT3 user data (and possibly also DT4b and / or ID3) to the PT1 system.

[0115] Each FP1 digital fingerprint can be generated by executing a suitable hash function taking user data DT3 as input. The hash function used can vary depending on the use case. A hash function is typically a function that, for a large (theoretically infinite) and diverse set of input, returns output in a specific format, namely a predefined format to be processed as described below. An FP1 digital fingerprint, for example, takes the form of a unique string of characters identifying the user UR1 (for example, the hash function "md5").

[0116] As an example, it is assumed that the PT1 system obtains or generates (S4) two digital fingerprints, namely: a first digital fingerprint FPla (or first sub-fingerprint), called the system fingerprint, generated from the system data DT3a; and a second digital fingerprint FPlb (or second sub-fingerprint), called the browser fingerprint, generated from the browser data DT3b ([Fig. 1]). The system fingerprint FPla thus identifies the user UR1 from the system properties of the client terminal TL. The browser fingerprint FPlb thus identifies the user UR1 from the properties of the browser client 12.The combined use of the FPla system fingerprint and the FPlb browser fingerprint allows for more reliable and robust user identification. In particular, it is possible to identify the user UR1 even if the client terminal system Tl and / or the browser client have undergone changes over time (updates, configuration changes, software and / or hardware modifications, etc.). For example, if the browser client 12 is updated between two visits to the STI website, it is still possible to identify the user UR1 from the FPla system fingerprint or by combining the FPla and FPlb fingerprints.

[0117] By way of illustration only, an MD5 hash function can be applied to each DT3a system data point (FPla = md5(DT3a)) and to each DT3b browser data point (FPlb = md5(DT3b)), thus producing two sub-fingerprints FPla and FPlb. A digital fingerprint FP1 is then generated from FPla and FPlb, for example by hashing FPla and FPlb (FP1 = md5(FPla FPlb)).

[0118] It should be noted, however, that variants are possible in which the PT1 system obtains in S4 ([Fig.3]) only one of these digital fingerprints, i.e., either the system fingerprint FPla or the browser fingerprint FPlb. According to one example, at least one FP1 digital fingerprint is obtained or generated from the aforementioned DT4b application data.

[0119] According to a particular example, the PT1 system obtains or generates (S4), from the user data DT3, a global digital fingerprint FP1 combining the system fingerprint FPla and the browser fingerprint FPlb as previously described. To do this, the PT1 system obtains or generates, for example, the fingerprint The FPla system and the FPlb browser fingerprint are derived from the DT3 user data (as previously described), and then the global digital fingerprint FP1 is determined by concatenating the FPla and FPlb fingerprints. Using a single global digital fingerprint combining FPla and FPlb advantageously limits the complexity of fingerprint processing and, in particular, facilitates the subsequent S8 history-keeping step.

[0120] It is assumed hereafter, by way of example, that the PT1 system generates in S4 a global digital fingerprint FP1 from a system fingerprint FPla and a browser fingerprint FPlb as previously described.

[0121] During a retrieval step S6 ([Fig. 3]), the PT1 system obtains or determines behavioral data DT4 representative of the behavior (or interactions) of the user UR1 on the STI website. In other words, the behavioral data DT4 defines how the user UR1 interacts with the web pages 32 and / or web objects 34 during the visit to the STI website. The behavioral data DT4 may define, in particular, at least one web page 32 and / or at least one web object 34 accessed by the user UR1 on the STI website, or information determined from the web pages 32 and / or web objects 34 accessed.

[0122] According to a specific example, when user UR1 accesses the STI website, the PG3 control module generates DT4a profile data in S6 ([Fig. 1]) by monitoring the behavior (or interactions) of user UR1 on the STI website. In other words, upon detection of user UR1 accessing the STI website, the PG3 module monitors the behavior (or interactions) of user UR1 with respect to the content of the STI website. The DT4a profile data thus generated is representative of a consultation of at least one web page 32 or web object 34 according to at least one element of the taxonomy 36. The DT4 behavior data generated in S6 ([Fig. 3]) is then obtained at least from (or includes) this profile data.

[0123] As already described, the aforementioned taxonomy element 36 defines, for example, a category and / or a label (tag or characteristic) according to which the web pages 32 and / or web objects 34 of the STI site are organized. Each web page 32 and / or web object 34 of the STI site can thus be associated with a taxonomy element as defined by taxonomy 36.

[0124] According to a particular example, during the aforementioned monitoring (S6), the PG3 control module detects that the user UR1 (or their browser client 12) has, during their visit to the STI website, accessed a web page 32 and / or a web object 34 that conforms to an element of the taxonomy 36 (for example, a category and / or a label). According to the taxonomy 36, each taxonomy element is associated with an identifier, i.e., a pair (taxonomy identifier, value). Thus, in response to this detection, the PG3 control module retrieves (or determines) the identifier of The taxonomy element 36 corresponds to the web page 32 and / or a web object 34 that was accessed, and updates (or records) a CTI counter representing the time spent accessing, or the number of times accessed, the accessed taxonomy element ([Fig. 1]), that is, the taxonomy element corresponding to the retrieved taxonomy ID. Thus, in one example, the updated CTI counter represents (or defines) a cumulative time during which user UR1 accessed content (web page(s) 32 and / or web object(s) 34) on the STI website that conforms to the taxonomy element corresponding to the retrieved ID. According to one example, the updated CTI counter represents (or defines) a cumulative number of consultations by user UR1 on the STI website of content (web page(s) 32 and / or web object(s) 34) conforming to the taxonomy element corresponding to the retrieved identifier.As an example, two counters such as those mentioned above are updated to track, respectively, the consultation time and the number of consultations of a taxonomy element. The DT4a profile data generated (S6) by the PG3 control module can then include the updated CTI counter.

[0125] Thanks to this counting (or “scoring”) function, DT4 behavioral data (including DT4a profile data and therefore the CTI counter) can be advantageously used to precisely track the evolution of user UR1's behavior over time with respect to a type of web page or web object. For example, one can track over time the level of interest that user UR1 has in a particular type of product or item (for example, the “shoe” or “shirt” category), and thus collect relevant information about the user's profile, interests, consumption habits, etc.

[0126] According to a particular example, the CTI counter update includes an operation of accumulating such a CTI counter representing the time spent by the user UR1 consulting a taxonomy type (i.e., a taxonomy element) as defined by taxonomy 36. In other words, the CTI counter accumulates the time spent by the user UR1 consulting a given taxonomy type, or content conforming to said taxonomy type.

[0127] According to a particular example, the CTI counter update includes an operation of incrementing such a CTI counter representing the number of visits (or consultations) by the user UR1 of a taxonomy type as defined by taxonomy 36. In other words, the PG3 control module can increment the CTI counter at each access of the same taxonomy type (i.e., at each access of content on the STI website conforming to said taxonomy type) over time.

[0128] According to a particular example, web pages 32 and / or web objects 34 are associated with identifiers denoted respectively ID1 and ID2. During monitoring carried out in S6 ([Fig.3]), the PG3 control module can determine the ID1 identifiers of the The PG3 control module can integrate into the DT4a profile data at least one page ID1 and / or at least one object ID2, thus determined during monitoring. These ID1 and ID2 identifiers can correspond, for example, to page numbers, product references, product characteristics, etc.

[0129] During a recording (or updating, or logging) step S8 ([Fig. 3]), the PG3 control module updates (or logs) DH1 history data of user UR1 from the DT4 behavior data in association with said at least one FP1 fingerprint obtained in S4, namely in this example a global FP1 fingerprint combining the FPla and FPlb fingerprints. In other words, the PT4 behavior data is logged in association with the FP1 fingerprint as DHL history data

[0130] The S8 update (or recording) of the DH1 history data can be implemented in various ways depending on the use case. This S8 update can generally consist of recording the DT4 behavior data in association with the user's URL FP1 fingerprint

[0131] The updated DH1 history data can be stored in any non-volatile memory accessible by the PT1 system. For example, it is subsequently assumed that the PG3 control module triggers (S8) the recording, as DH1 history data, of the DT4 behavior data associated with the FP1 fingerprint in the PT4 platform. This PT4 platform may include, for example, a database (not shown) configured to store the DH1 history data updated by the PG3 control module. The PT4 platform is, for example, a CRM (customer relationship management) system configured to store and manage the DT4 behavior data of the user URL.

[0132] According to a particular example, during the S8 update, the PG3 control module triggers the sending, to the PT4 CRM platform, of PT4 behavior data in association with the FP1 digital fingerprint for historization (recording) as DH1 history data, for example in a database of the PT4 platform.

[0133] Note that the S8 update of the DH1 history is also possible without using a CRM tool such as the PT4 platform. However, combining the PT1 CMS system with the PT4 CRM platform allows for particularly effective targeted tracking of a URL user.

[0134] According to a particular example, during the S8 update ([Fig.3]), old historical data denoted DH0 ([Fig.1]) is already stored in the PT4 platform in association with the FP1 digital fingerprint of user UR1 – or another FPO digital fingerprint of user UR1 (for example, a fingerprint similar to FP1) – for example, following one or more previous visits by user UR1 to the STI site. In this case, the S8 update amounts to recording the DT4 behavioral data obtained in S4 as DH1 history data in addition to the existing DHO history data (for example, by adding, replacing, etc.), in association with the FP1 digital fingerprint in the PT4 platform.

[0135] According to a particular example, at the time of the S8 update ([Fig.3]), no previous DHO history data is already stored in the PT4 platform in association with a UR1 user fingerprint. In this case, the S8 update is equivalent to recording the DT4 behavior data as DH1 history data in association with the FP1 fingerprint in the PT4 platform.

[0136] The recording or updating of S8 history (also called history recording) advantageously allows for targeted (or personalized) and effective monitoring over time of the behavior of the user UR1 on the STI website, regardless of the resources (client terminal, browser client, etc.) used by the user UR1 to access the STI website.

[0137] Such tracking is made possible in particular by linking DT4 behavioral data to user UR1 in the DHL history data. The association of DT4 behavioral data with the FP1 digital fingerprint ensures that user UR1 is reliably recognized, where appropriate, on each visit of this user to the STI website, even if this user uses means of protection to anonymize their access to the STI website (for example a browser without cookies) or uses different client terminals during several visits to the STI website.

[0138] The present invention makes it possible, in particular, to offer a CRM (Customer Relationship Management) type system that recognizes (or qualifies) website visitors by using their digital fingerprints as identifiers, including unknown visitors who are not identified to the site (by login / password, or by cookie, for example) and who may use anti-tracking protections or different devices during their visits to the site. The same user can thus be recognized on each visit to a website without the user's identity being known (no obligation to collect personal data (name, date of birth, etc.) or cookies).

[0139] If a user using two different terminals to access the same STI website authenticates with both terminals (for example, using forms), it is then possible to associate this user with the DH1 history data. two digital fingerprints generated for the two terminals.

[0140] This allows us to track the evolution of the DT4 behavioral data of user UR1 over time and deduce relevant information about the behavior of this user UR1 on the STI website, such as the number of site visits, the user UR1's path on each site visit, the user's interests, their consumption habits, etc. The invention makes it possible to centralize a set of relevant information about a user, in particular the aforementioned DT4 behavioral information.

[0141] By ensuring targeted and reliable monitoring of user UR1 over time, the owner of the STI website can better understand user UR1's profile (needs, interests, etc.) and thus adapt the content of the STI website accordingly, for example, by creating or adapting content based on user UR1's profile (creating offers or advertising content tailored to the user's interests, etc.). This allows for the optimization of a website's performance, regardless of the domain or objective. The system of the invention, for example, makes it possible to optimize sales for an e-commerce site or to optimize advertising revenue for any website.

[0142] In an e-learning system, for example, the system of the invention makes it possible to better track user behavior and thus better understand learners' interests. In a multimedia content sharing platform, the invention makes it possible to adapt the multimedia content offered to the same user over time according to their preferences.

[0143] According to a particular example, the method further includes a step of checking the STI website (after the S8 registration step) during which the PT1 system adapts the STI website (for example, its content) according to the DH1 history data recorded in S8 for the user URL. To do this, when the user UR1 consults the STI website, the UR1 system can retrieve (or consult) the DH1 history data associated with the user UR1 and adapt the content of the STI website according to the DH1 history data thus retrieved. This allows for the advantageous personalization of certain elements of the STI website according to the profile or interests of the user UR1 and thus improves the user experience (adaptation of the web objects presented, adaptation of advertising content, etc.).

[0144] As described below in various examples, it is also possible to enrich the DH1 historical data of user UR1 in order to further improve its tracking over time.

[0145] Thus, as already indicated in a particular example, the PG1 analysis module of the client terminal Tl can generate DTI identification data and / or DT2 performance data within the navigation client 12 while the user UR1 accesses the STI website. As illustrated in [Fig. 1], the PG1 analysis module can then transmit the DTI and / or DT2 data to the PT2 performance analysis platform (e.g., Google Analytics® or Matomo®). Using the DTI and / or DT2 data, the PT2 platform monitors or analyzes the performance of the STI website.

[0146] According to one example, in response to user UR1 accessing the STI website, the PG1 module generates a cookie containing an application identifier ID3 as already described. The PG1 module transmits the DTI identification data (including the ID3 identifier) ​​and DT2 performance data to the PT2 system. The PT2 system then records the DTI and DT2 data in association with ID3. In parallel, the PT1 system also records (or causes the recording) during the S8 update (figs 1-3) this application identifier ID3 in association with the FP1 fingerprint of the user UR1 as DHL history data. The recording of the ID3 identifier in the DH1 history data advantageously makes it possible to establish a link (or join) between the DH1 history data stored in the PT4 system on the one hand and the DTI and DT2 data stored in the PT2 system on the other hand.Thanks to this link, it is possible to enrich the DH1 history data with data from other applications. This further improves the tracking of the UR1 user by enriching their DH1 history data with performance analysis data that characterizes the UR1 user's interactions (time spent on each web page, pointer path, etc.) with the STI website.

[0147] Furthermore, as already indicated, the DT3 user data obtained in S2 (Figures 1-3) may include DT4b application data (e.g., layer data). According to a particular example, this DT4b application data may then be included in the DT4 behavior data that is recorded (S8; [Fig. 3]) in the DH1 history data in association with the FPL fingerprint

[0148] Furthermore, as already mentioned, FMI form data can be submitted by the user UR1 during their access to the STI website. As is well known, a form comprises a set of one or more fields intended to receive (or contain) data entered by a user. Typically, a user can enter data into such a field and then validate the entry by means of an appropriate command. Such FMI form data can be retrieved and processed by the PT1 system ([Fig. 1]). This FMI form data can, for example, include at least one of the following pieces of information: form name, user name, user email, etc. According to a particular example, the PT1 system collects the FMI form data submitted by the user and saves (S8; [Fig. 3]) this FMI form data in the DH1 historical data in association with said at least one FP1 digital fingerprint and DT4 behavioral data.

[0149] Adding FMI form data to the DH1 history data in association with the FP1 fingerprint advantageously creates a link (or join) between, on the one hand, the DH1 history data of user UR1 and, on the other hand, the UR1 user data contained in the PT3 system. This further improves the monitoring of user UR1 by enriching their DH1 history data with form data. Thus, when a user UR1 fills out a form, the collected form data can be associated with pre-existing DH1 history data that was previously recorded (S8, [Fig. 4]) as described above. Advantageously, it is not necessary to wait for a user to register using a form to begin monitoring and analyzing their behavior.In this way, we can significantly improve the tracking of a customer's journey, including when they initially access the STI website anonymously.

[0150] Furthermore, as already mentioned, user UR1 can access the STI website in various ways, for example via a data-enriched link that they activate from an intermediate site ST2 ([Fig. 1]). In a particular example, system PT1 obtains decoded DT4b application data by decoding a data-enriched link through which user UR1 accesses the STI website. In other words, system PT1 decodes this enriched link activated by user UR1 to access the STI website, this decoding producing decoded data. This decoded data may, for example, include UTM data.During the S8 update step (Figures 1-3), the PT1 system then records this decoded data in the DH1 history data in association with the DT4 behavioral data and the FPL fingerprint. This function further improves the tracking of user UR1 by enriching their DH1 history data with data decoded from a rich link used by user UR1 to access the STI website. This advantageously allows for determining the origin and context of user UR1's arrival on the STI website.

[0151] Furthermore, steps S2-S8 of the tracking process can be repeated a plurality of times over time, for example at each of a plurality of visits to the STI website by the user URL

[0152] Thus, according to a particular example, steps S2 to S8 ([Fig. 3]) are repeated for each of a plurality of visits by user UR1 to the STI website. The DH1 history data of user UR1 is then updated (S8) from the DT4 behavioral data obtained in association with each FP1 digital fingerprint corresponding to said user URL. As already indicated, a follow-up Reliable and personalized user UR1 can thus be created over time, particularly during multiple visits to the STI website. Digital fingerprints are used to recognize the same UR1 user across multiple visits to the STI website over time and to link the DT4 behavioral data obtained on each visit to that same UR1 user.

[0153] Figure 4 schematically represents steps performed by the PT1 system, and more specifically by the PG3 control module, during several successive iterations (or cycles) of the tracking process according to a particular embodiment. For this purpose, the processor 20 implements, for example, the PG3 control module. The various embodiments of steps S2-S8 of the tracking process described above with reference to Figures 1-3 apply analogously to the embodiments described below with reference to Figure 4.

[0154] In this example, it is assumed that user UR1 makes two successive visits to the STI website, for example, on two different days (or two different dates). User UR1 may use, for example, their browser client 12 implemented by the same client terminal T1, which may have undergone hardware and / or software modifications between the two visits. The PT1 system executes ([Fig. 4]) an iteration (or cycle) of the tracking process described above for each visit (or consultation) of the STI website, namely a first iteration IT1 of steps S2-S8 during the first visit and a second iteration IT2 of steps S2-S8 during the second visit (subsequent to the first visit).

[0155] It is assumed by way of example that before the first visit (iteration IT1) of the STI website, the user UR1 had never visited this website, although variants are possible where the user UR1 had already visited the website.

[0156] Thus, in response to the first visit by user UR1 to the STI website, the PT1 system performs the first iteration IT1 ([Fig. 4]) of steps S2 to S8 as previously described with reference to Figures 1-3. During the acquisition step S4, the digital fingerprint of user UR1 obtained (or generated) by the PT1 system is denoted FP0 (Figures 1 and 4). During the acquisition step S6, the behavioral data of user UR1 obtained by the PT1 system is denoted DT0 (Figures 1 and 4). During the update step S8, the PT1 system thus updates (or saves) the history data—denoted DH0—from the behavioral data DT0 in association with the digital fingerprint FP0 of user UR1 (Figures 1 and 4).

[0157] This is at this stage the first visit of user UR1, so no history data was previously stored as history data in association with user URL. Also, during the S8 update of the first iteration IT1, the PT1 system records, as history data DH0 (figures 1 and 4), the DTO behavioral data in association with the FPO digital fingerprint. To do this, the PT1 system sends, for example, the DTO behavioral data and the FPO digital fingerprint to the PT4 CRM system for recording as DHO history data.

[0158] Subsequently, in response to the second visit by user UR1 to the STI website, the PT1 system performs the second iteration IT2 ([Fig. 4]) of steps S2 to S8 as previously described with reference to Figures 1-3. During the acquisition step S4, the digital fingerprint of user UR1 obtained (or generated) by the PT1 system is denoted FP1 (Figures 1 and 4). During the acquisition step S6, the behavioral data of user UR1 obtained by the PT1 system is denoted DTI (Figures 1 and 4). During the update step S8, the PT1 system thus updates the history data—denoted DH1—from the behavioral data DTI in association with the FP1 digital fingerprint of user UR1 (Figures 1 and 4).

[0159] According to a particular example, the PT1 system can cause the recording (S8, figures 3-4), in the DH1 history data of the user UR1, of a plurality of digital fingerprints FP1 in association with the same application identifier ID3. These FP1 fingerprints are obtained (S4) according to the method of the invention in response to a plurality of accesses by the user UR1 to the STI website.

[0160] According to a particular example, the PT1 system can cause the recording (S8, Figures 3-4), in the DH1 history data of user UR1, of a plurality of FP1 digital fingerprints in association with the same form data identifier. This form data identifier can be any identifier contained in FMI form data submitted by user UR1 during multiple form submissions to the STI website. This identifier can, for example, be or include an email address of user UR1.

[0161] Thanks to the ID3 identifier and / or the form data identifier (email address), it is advantageous to identify all the FP1 fingerprints generated over time for the same user UR1, for one or more terminals Tl.

[0162] According to a particular example, during the S8 update step of the second IT2 iteration, the PT1 system compares the FP1 digital fingerprint generated in S4 (IT2 iteration) with the FPO digital fingerprint—referred to as the reference digital fingerprint—previously recorded (S8, IT1 iteration) in the DHO history data—referred to as the reference history data—of a reference user ([Fig. 1]). If the FP1 digital fingerprint coincides (or matches) with at least one of said reference digital fingerprints, the PT1 system detects that the user UR1 accessing the STI website during the second IT2 iteration is the user of The reference is the one for which the DTO behavior data was previously recorded in the DHO history data. In this case, the DH1 history data updated in S8 (iteration IT2) is then the DHO reference history data associated with the FPO reference fingerprint. In other words, the PT1 system updates the DHO history data from the DTI behavior data associated with the FP1 fingerprint. The PT1 system supplements the DHO history data, for example, by incorporating (or adding) the DTI behavior data.

[0163] Thus, upon detection of a new visit to the STI website, the PT1 system obtains a new FP1 fingerprint, checks if this new FP1 fingerprint corresponds to an already historical FPO reference fingerprint and, if so, associates the user UR1 making the new visit with the DHO history data of the FPO reference fingerprint, which allows personalized tracking over time of the behavior of the user UR1 on the STI website.

[0164] According to one example, the FPO and FP1 digital fingerprints, obtained respectively during the S4 acquisition steps of iterations IT1 and IT2, are identical. In this case, the PT1 system detects that the user accessing the STI website during the two visits considered is the same, namely UR1 in this example. The PT1 system can then update (S8) the DHO history data as previously described.

[0165] According to one example, the FPO and FP1 fingerprints, obtained respectively during the S4 acquisition steps of iterations IT1 and IT2, are different. In this case, during the S8 update step of the second iteration IT2 ([Fig. 4]), the PT1 system evaluates a degree of similarity between the FPO and FP1 fingerprints to determine if they correspond to the same user URL. This evaluation may include a comparison of the different characters in the string of the two fingerprints FPO and FPL. If the two fingerprints FPO and FP1 are sufficiently close, i.e., if the degree of similarity thus obtained is at least equal to a threshold value, then these fingerprints are treated as coinciding with each other (in other words, as corresponding to the same user UR1). The PT1 system can then update (S8) the DHO history data as previously described.

[0166] If, on the other hand, the two fingerprints FPO and FP1 are not sufficiently similar, they are treated as corresponding to two different users (in other words, user UR1 is different from the reference user). In this case, the DT4 behavioral data of user UR1 is recorded (S8) as DH1 history data in association with the FP1 digital fingerprint, independently of the DHO history data of the reference user.

[0167] In the above embodiment examples, the process of the invention is implemented by the PT1 system cooperating in particular with the client terminal T1 and the PT4 system. As already mentioned, however, variations are possible in which the process is carried out by another device or system. Some such variations are described below for illustrative purposes only.

[0168] Figure 5 (server configuration) represents a variant embodiment of the environment of Figure 1. The environment of Figure 5 differs primarily from that of Figure 1 in that modules PG1 and PG2 are not executed by the client terminal T1 but remotely by a PTO system (or server, or platform). In this case, the navigation client 12 of terminal T1 receives, and executes, a PGO control module from the PT1 system. This PGO module collects all the data gathered by PG1 and PG2 in the embodiments previously described with reference to Figure 1. The PGO module distributes this data to the PTO system, which in turn distributes the data to modules PG1 and PG2. Modules PG1 and PG2 also perform the same functions as those previously described with reference to Figure 1.In other words, in this particular example, it is also the PT1 system that implements steps S2-S8 of the process of the invention as previously described.

[0169] As those skilled in the art will understand, all the embodiments and variations described above, some of which have been intentionally simplified for ease of explanation, are merely non-limiting examples of implementation of this disclosure. In particular, those skilled in the art may consider any adaptation or combination of the embodiments and variations described above to meet a specific need.

[0170] The present invention is therefore not limited to the embodiments described above but extends in particular to a tracking method that would include secondary steps without departing from the scope of the present invention. The same would apply to a tracking device (or system) for implementing such a method.

Claims

Demands

1. A method for tracking a website, implemented by a tracking system (PT1), said method comprising: a) receiving (S2), from a client terminal, user data (DT3) representative of a user (UR1) accessing the website via a browser client (12); b) obtaining (S4), from the user data (DT3), at least one digital fingerprint (FP1) of the user, said at least one digital fingerprint being generated by applying at least one hash function taking said user data as input; c) obtaining (S6) behavioral data (DT4) representative of user behavior on the website; and d) recording (S8) history data (DH1) of the user from the behavioral data (DT4) in association with said at least one digital fingerprint (FP1) to enable tracking of user behavior on the website.

2. A method according to claim 1, wherein the method comprises: - in response to a request for access from the browsing client to the website, sending an identification module (PG2) causing the execution of said identification module by the browsing client, in which the user data (DT3) are received from the identification module.

3. A method according to claim 1 or 2, wherein the user data (DT3) comprises at least one of: - system data (DT3a) representing system properties of the client terminal (Tl); and - browser data (DT3b) representing properties of the browser client (NW1).

4. Method according to claim 3, wherein said at least one digital fingerprint comprises at least one of: - a first digital fingerprint (FPla), referred to as system fingerprint, generated by applying a first hash function from system data; and - a second digital fingerprint (FPlb), referred to as browser fingerprint, generated by applying a second hash function from browser data.

5. A method according to any one of the preceding claims, in which process includes: - generation of profile data (DT4a) by monitoring user behavior on the website, the profile data being representative of a consultation of at least one web page or web object, the behavior data being obtained at least from said profile data.

6. A method according to claim 5, wherein the monitoring comprises: - detecting that the user accessing the website has viewed a web page, or a web object; - in response to said detection, updating a counter representing a viewing time, or a number of viewings, of at least one of: • said web page or said web object; • at least one piece of information constituting said web page or said web object.

7. A method according to claim 6, wherein the profile data are representative of a consultation of at least one web page, or web object, defined by at least one element of a taxonomy; wherein the updated counter is representative of a consultation time, or number of consultations, of said at least one element of the taxonomy.

8. A method according to any one of the preceding claims, wherein the behavioral data (DT4) comprises application data (DT4b) and an identifier (ID3), associated with at least one application executed by the client terminal, the application data and the identifier being recorded in the history data (DH1) in association with the behavioral data (DT4) and said at least one digital fingerprint (FP1).

9. A method according to any one of the preceding claims, wherein the recording (d) of the history data comprises sending, to a customer relationship management platform (PT4), the behavioral data (DT4) in association with said at least one digital fingerprint for historization as history data in a database.

10. A method according to any one of the preceding claims, wherein steps a) to d) are repeated for each of a plurality of user visits to the website, wherein the data User history is updated from behavioral data (DT4) obtained in association with each digital fingerprint corresponding to said user.

11. A method according to any one of the preceding claims, wherein the method comprises: - collecting form data submitted by the user accessing the website; and - recording the form data in the history data (DH1) in association with said at least one digital fingerprint (FP1) and behavioral data (DT4).

12. A method according to any one of the preceding claims, wherein the method comprises: - obtaining decoded data (DT4b) by decoding a data-enriched link through which the user accesses the website; - recording the decoded data in the history data (DH1) in association with said at least one digital fingerprint (FP1).

13. Computer program (PG3) comprising instructions for carrying out the method according to any one of the preceding claims, when such instructions are executed by a processor.

14. Website tracking device (PT1), comprising: - a receiving module (MD2) configured to receive, from a client terminal, user data (DT3) representative of a user (UR1) accessing the website via a browser client; - a first retrieval module configured to obtain, from the user data (DT3), at least one digital fingerprint (FP1) of the user, said at least one digital fingerprint being generated by applying at least one hash function taking said user data as input; - a second retrieval module configured to obtain behavioral data (DT4) representative of user behavior on the website;and - a history module configured to update user history data (DH1) from behavioral data (DT4) in association with said at least one digital fingerprint (FP1) to enable tracking of user behavior on the website.

Images