NOTE: This page is not about the Piano User Interest segments in Composer1x. Go to https://docs.piano.io/composer-1x-segments/#userinterest to read about those.
Introduction
User Interests is a Cxense metric used to identify and describe individual interests of a user based on the users browsing behavior. The ‘user’ in this sense is assumed to be an individual, identified either by a browser cookie, or in other ways identified in the system. The 'interests' are computed based on the content of the articles the user is consuming. For each user engagement the weights are modified, hence we aim to dynamically update the user’s interests based on the full browsing history of the user. As a data structure, the User Interests is a weighted tree where each node in the tree represents an interest.
Motivation
Predicting user interests based on user actions is an emerging research field which attracts an increasing amount of attention. Its use cases involve any application that aims to personalize feedback based on the users demands. While similar approaches could also be used more short-term user intents, our purpose is to maintain a slowly evolving record of the long-term user interests of a user based on the users entire browsing history, and associating the user interests with a score defining how important this niche is for the user. The Cxense User Interest aims to condense all browsing history and user interaction for a user, and present this as a user-friendly tree structure of of user interests which is scored by importance based on the entire browsing history and user actions for the user.
Taxonomies
Cxense offers default standard taxonomies for a limited amount of languages. A User Interest Taxonomy is a mapping of a set of keywords, and corresponding node or nodes in an interest tree. If a page browsed by the user contains a given amount of keywords which maps to certain nodes, these nodes in the interest tree are boosted. Custom taxonomies provides an in-depth description of how such taxonomies are developed and uploaded.
Interest Tree
Each user will be associated with an interest tree. For a new user, this tree is empty, i.e. it does not contain any nodes. As mentioned earlier, each time a user visits a page with a user interest keyword, nodes in the interest tree will be boosted. When a node is boosted, all other nodes, excluding the nodes' ancestors, will be down-weighted. This is to ensure that the weights in the tree remains in accordance with the Balance Principle of an Interest tree.
Balance Principle
The weight balancing principle for an Interest tree:
-
If a node has ancestors, the weight of the node equals the sum of the weight if its ancestors.
-
The sum of the top node is 1.0
-
When the weight of a node is increased or decreased, the weight of all other nodes in the tree must be re-computed in order to not violate principle 1.
This is illustrated in the interest tree in Figure 1, where we see the two categories Tech and Lifestyle. Tech expands two sub-categories, Computer and Mobile, whose weights equal the sum of their ancestor node.
If a user with the interest tree described in Figure 1 visits a new page which contains keywords that trigger a match to the node Top/Tech/Mobile, the tree weights will be re-computed, and weight for this node will be boosted, while all other nodes will be down-weighted, as demonstrated in Figure 2.
Similarly, new nodes can be introduced in the interest tree, resulting in all none-related nodes being down-weighted. A none-related node in this case would imply any node which is not an ancestor of the node.
The sum of ancestor/ancestors will always equal the sum of the parent node, and the sum of the Top node is 1. The actual weighting of new nodes, and thereby the down-weighting of existing nodes, may depend on a number of factors, which will be discussed in the section on Weighting below.
Note that there is no explicit mechanism for down-weighting a specific node in the interest tree. However, if a node is not boosted, it will be down-weighted, following the weight balancing scheme presented above. A node will disappear from the interest tree if the weight goes below a given threshold, in which case the weight for this node will be re-distributed to the existing nodes in the interest tree, hence upholding the weight balancing principle.
Dynamic and Periodic Updates
Each user action that implies that a node in the interest tree is boosted will call for a re-weighting of the interest tree. This re-weighting could be done continuously, maintaining an interest tree which dynamically evolves parallel to the browsing actions of the user. Alternatively, we could store all user actions in a batch, and process this batch periodically, thereby updating the user interest tree at fixed intervals.
Given the purpose of an interest tree, namely to monitor long-term user interests, it is not expected that an interest tree changes dramatically based on a limited number of user actions. Hence, carrying out dynamic updates of the user interest tree is not expected to offer significant benefits compared to a periodic updates. Further, as we have concluded that dynamic updates do not offer any convincing benefits for our use-case, we have opted to do periodic updates of the user interest trees. This allows us to use more sophisticated weighting schemes by analyzing each individual user action, and assigning node weights based on the importance of the user action. To exemplify, if a user spends 10 seconds on reading a featured article about a car crash, and another user spends 2 minutes on a page about the new Audi, a human evaluator would likely conclude that based on these two events in isolation, the second user has shown more interest for cars than the first user. Utilizing periodic updates rather a dynamically evolving user interest tree allows us to do such sophisticated analyses of user behavior. These methods will be discussed below.
User Action Weighting
A crude weighting scheme would be to assign a static weight increase to any interest tree node which should be boosted. However, all user actions may not have equal importance when building and modifying an interest tree. In the following, we will describe the metrics which are utilized in our weighting scheme.
Dwell Time
The amount of time spent on a page, the dwell time, suggests how interesting the user found this page. However, since articles have various lengths, we take the average dwell time of the page into account. If the user spends more time than the average user, any interest nodes derived from this page is boosted additionally. Similarly, if a user spends below-average time on an article, the interest nodes which are derived from this page will not be boosted to the same extent.
Node Frequency versus Inverse Document Frequency
As an interest node is boosted based on the presence of a set of keywords, some keywords will occur in a large amount of pages, while others are rarer. We want to reflect that very common keywords do not represent the same importance as keywords which seldom occur. We may see that the keyword "mobile", occurs in a high proportion of page which are using this taxonomy. This suggests that although the user who browses a page where this keywords is triggers may be likely to be interested in mobile devices, it should only be considered a minor cue. Alternatively, the keyword "fly fishing" occurs on a just a tiny proportion of the pages. If this keyword is triggered, its weight is boosted based on the intuition that it is more unlikely that the user randomly read an article about fly fishing that about mobiles.
Page Popularity
Page Popularity is a metric which follows much of the same intuition as described in the previous section. If a user visits a page with a very high number of page views, this suggests that the article has reached a wide audience. Interest nodes that derive from such pages are weighted less than interest nodes from less popular pages under the assumption that pages that reaches a wide audience reach this popularity because they are of general interest, and not because a very large number of people are interested in a particular niche. An example of this may be that the keyword "flight", with the interest node lifestyle/travel, could be triggered on a page on a major plane crash. Since this article has a very high page popularity, the interest node is only boosted marginally.
Aggregated User Interests
Previously we have discussed interest trees associated with an individual. However, for many use-cases we would rather retrieve an aggregated view of a population of users. This is achieved by summing all interest nodes of all users in the population by considering the individual user interest trees as vectors, and using sum all the vectors as a vector addition operation.
Note that an aggregated interest tree based on a population of users will not abide to the weight balancing principle which is upheld for individual user interest trees. As the sum of the Top node for an individual user is 1, the sum of the Top node for a population of size N will equal N. The sum of the ancestors weights of a node will be equal or less than the weight of the ancestor. The reason for this possible discrepancy is that two individual interest trees may have a common node where this node is expanded to a sub-category in only one of the interest trees. This is illustrated in Figure 4, where we see that for the node Top/Tech, the node has two daughters, the sub-categories Computer and Mobile, in the first interest tree, while the node is not expanded in the second tree. When merged, we see that the sum of the Top/Tech/Mobile and Top/Tech/Computer does not equal the sum of Top/Tech (Figure 5).
Conceptually, a discrepancy between the sum of the ancestors and the weight of the parent node could be resolved by injecting a placeholder node which equals the sum of the parent node subtracted by the sum of the ancestor weights, see Figure 6. This would convey the intuition that the node Top/Tech consists of two known sub-categories, Computer and Mobile, while the superfluous weight not belonging to those categories are not defined.
Implementational details
Update intervals
Every 24 hours all events from a user will be combined, and we will create a new user interest tree based on the user interest keywords associated with these events. This daily user interest tree will be merged with the existing user interest profile for the user, provided that such a profile exists.
Daily User Interests influence
When the user interest tree compiled from the events over the last 24 hours is merged with the existing user interest profile, we assign a given influence weight to the daily user interest tree with respect to how much the new user interest tree should influence the existing user interest profile. The formula for the influence for the new user interest profile is given below:
double interestInfluence = Math.max(1.0d / (this.updateCount + 1), 0.07);
Essentially, it means that the second day, the user interest profile for the full day will be merged with the existing user interest profile, and both profiles will be equally important, as both profiles are based on 24 hours. As the user interest profiles is older, the new profile for the latest 24 hour will induce less changes to the existing profile. Minimally, the new 24 hour user profile will be merged with the existing user interest profile where the daily user interest profile will influence the existing profile with 7 %.
Minimum number of events in an interval
We only consider users with at least 5 events in each interval (i.e. within the last 24 hours). For users with less events within the interval, we do not update the existing user interest profile if they already have a user interest tree, nor create a new interest profile.
Inactivity threshold
A user will typically maintain multiple separate user interest trees with various prefixes. Each time the user has reached the minimal number of events in a day (see last section), all user interest trees are re-computed. However, if there are no events that pertain a user interest tree for a specific prefix (say the user has a user interest tree for the prefix xxx, and another for the prefix xyz, and the user only has events for site groups with prefix xxx, not xyz), we will count start counting the number of successive inactive days where a user interest profile is not updated for a given prefix. If there are 25 successive days where only the user interest tree for xxx is updated, and not the tree for xyz, the whole user interest profile for prefix xyz is removed. However, if there are events for prefix xyz, the counter is reset.