Scope
You want to have a trending/behavioral widget on all of your frontpages.
Your site is structured by a main "home frontpage" and six different "section frontpages", like "technology", "strategy", "recruitment", "entertainment" and so on…
On each frontpage you want to have the same widget. The only difference should be, that the articles recommended should stick to the section, or all articles for the "home frontpage".
Challenge
-
Is there a way to avoid the setup of seven different widgets and content-configurations?!
-
Is there a way to make a content-configuration dependent on the context of the site it will be presented on?
The general challenge is, if content-configurations support dynamic parameters or in other words, could be made "context aware"?
Cxense Content solution approach
There is an explicit "context" feature available, which could be used to define "conditional" branches within one content-configuration.
Pseudo algorithm:
-
If section is "technology", then recommend only "technology" articles
-
If section is "finance", then recommend only "finance" articles
-
If section is "home", then recommend all articles available
This feature could be seen as a function with a "context" parameter and an logic to process this "context".
In Cxense Content terminology
-
The
/public/widget/datarequest has the option to set a "context" object for following fields:
pageclass, sentiment, recommendingandcategories
All of this fields could exist in the content-profile of a page, as a result of the document parsing process.
Setting this fields and values explicit in a request, could be useful to:
-
Specify pairs of "
context" objects and values, in the case the content-profile doesn’t have this fields-
Override, in the case you need dynamic and explicit control of this fields, independent from the document-parsing and the existing content-profile
-
The /public/widget/data request will typically be used as part of the "insertWidget" script, how to set the "context" through the "insertWidget" will be shown in the example.
-
The "
if/then/else" conditional logic, which will be configured as a "Content setting condition" of type "context
Example how to take explicit control of the "context" object
A typical script to insert a widget into your webpage could look like this:
|
To inject an explicit "context" object, the request needs to be extended:
|
A "conditional" content-configuration, to make the "query" parameter dependent on the "context >> categories >> taxonomy" value.
In our case all articles, which belongs to a section like "technology", can be filtered by the "kw-category" index-field.
This field in the sitesearch index reflects the "categories" field in the content-profile.
Using "comment", "tag" and "itemDefault" are best practices:
-
to have filter options for the Cxense Content reporting (based on the "
tag") and -
Cxense Analytic filters for articles clicked by a recommendation widget (based on the "
itemDefault", a best-practice is available here)
To access "categories" other then "taxonomy" requires an additional "categoryType" parameter in the "condition" statement, like though:
|
All common parameters can be grouped together by the "defaults" block.
|
Testing the configuration
The content-configuration preview option doesn't support the explicit setting of "context" objects other than the "url".
So a test could be done with a minimal HTML page, editing the context manually and reloading the page:
|
Fetching the response of the /public/widget/data request and making it readable with a beautifier like http://jsbeautifier.org/ , should reflect based on the value of the "{ taxonomy :'strategy' }" setting, in the "response" > "items" > "tag" value, like this:
|