Adaptive Personalization Manual / Version 2107
Table Of ContentsScoring is a simple means to abstract an individual user's behavior on a website. In general, the idea is to assign scores to certain observable events and to combine these scores with the user's current scores whenever the events are observed.
Note
Please note that profiling user behavior as well as taking automated decisions based on this profiling may be restricted by applicable privacy law and may require specific user consent to be obtained and may depend on how you implement the Adaptive Personalization module for your project.
Example
Assume the pages on a website are tagged with keywords and you want to keep track of how often the user visits pages tagged with a specific keyword. In this scenario, a visit on a page is an observable event, and the scores are the counters associated with each keyword. Whenever the user visits a page, the scores of all associated keywords are incremented by 1.
CoreMedia Adaptive Personalization supports scoring via the
ScoringContext
. It manages a set of scores and uses a ScoringStrategy
to update scores
if events are observed.
CoreMedia Adaptive Personalization comes with a set of predefined scoring strategies:
CountScoring
This strategy simply counts the occurrence of events. That is, for each supplied event, the corresponding score is incremented. This strategy can be used to implement the keyword scenario described above.PercentageFromMaxScoring
This strategy weights each score by its percentage of the maximum score value. For each event, a score of the corresponding key is maintained and incremented by 1 whenever the event is observed.PercentageFromTotalScoring
This strategy weights each score by its percentage of the sum of all scores. For each event, a score of the corresponding key is maintained and incremented by 1 whenever the event is observed.
Going back to the keyword example, assume that page A is tagged with keywords 'foo' and 'bar', and page B is tagged with 'bar'. Further, assume that a new user visits page A once and page B twice. Here is the table of scores that result from applying the different strategies:
Strategy | foo | bar |
---|---|---|
CountScoring | 1 | 3 |
PercentageFromMaxScoring | 1/3 | 3/3 |
PercentageFromTotalScoring | 1/4 | 3/4 |
Table 4.5. Example results
In addition to the application specific scores, two general scores are maintained by all three strategies:
__max__ contains the maximum score of all scores maintained by the context
__total__ contains the current total of all scores maintained by the context
The scoring strategies are interchangeable, that is, if you start with one you can reconfigure your system later to use a different one without loosing any data.
Configuring a ContextSource to use the ScoringContext
ScoringContext
provides its own ContextCoDec
implementation in the static inner class
ScoringContext$CoDec
. The codec can be used in any source that accepts a ContextCoDec
or
a ContextFactory
. Because the ScoringContext
requires a ScoringStrategy
,
you must inject the strategy you want to use for all decoded and created contexts into the codec.
Here is an example of how to configure a CookieSource
to use a ScoringContext
with the
PercentageFromTotalScoring
strategy:
<bean id="scoringCookie" class="com.coremedia.personalization.context.collector.CookieSource" type="singleton"> <property name="contextCoDec"> <bean class="com.coremedia.personalization.scoring. ScoringContext$CoDec"> <property name="strategy"> <bean class="com.coremedia.personalization.scoring. PercentageFromTotalScoring"/> </property> </bean> </property> <property name="contextName" value="scoringContext"/> </bean>
Writing your own ScoringStrategy
Writing your own scoring strategy is as simple as implementing the ScoringStrategy
interface. Keep in
mind that your implementation must be thread-safe because it is typically shared by several
ScoringContext
instances. Ideally, you simply do not use any modifiable state that is shared among
threads.
In typical scenarios, processing events is far more frequent than reading scores. Thus, it's sensible to perform
costly updates lazily only when scores are requested. To this end, your strategy may implement the
ScoreValueTransformer
interface. If a strategy implements this interface, the
ScoreValueTransformer#transform
method is called by the ScoreContext#getScore
method and
its result returned as the score. The supplied strategies PercentageFromMaxScoring
and
PercentageFromTotalScoring
use this to perform the normalization of values only at the time of
access.
The third interface that is relevant to scoring is MergeStrategy
: A ScoringStrategy
that
allows merging of two sets of scores should implement this interface. Merging of scores is useful if you want to
combine data from different context. A typical scenario is as follows: A user logs into your site and his scoring
context is persisted in a database. Later, the user returns to the site and browses without logging in, thus new
scores are collected. Then, with the user logging in, the formerly persisted data becomes available and can now be
merged with the scores collected while the user was anonymous.
If your ScoringStrategy
implements the MergeStrategy
interface, a
ScoringContext
using your strategy will be able to perform the mergeWith
operation.
Using a ScoringContext to track Keyword Clicks
CoreMedia Adaptive Personalization provides the KeywordInterceptor
for the common use case in which you want to count the keywords associated with the pages a user clicks on. The
KeywordInterceptor
intercepts a CAE request after the controller
but before the view is rendered and attempts to extract keywords from the 'self' bean in the model that is to be
supplied to the view dispatcher. These keywords are sent as events to the configured ScoringContext
.
See the respective Javadoc for details.