Scope
You want to have a trending/behavioral widget on all of your front pages.
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 recommended articles 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 whether content configurations support dynamic parameters, or in other words, could be made "context aware"?
Piano 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 logic to process this "context".
In Piano Content terminology
-
The
/public/widget/datarequest has the option to set a "context" object for the following fields:
pageclass, sentiment, recommendingandcategories
All of these fields could exist in the content-profile of a page, as a result of the document parsing process.
Setting these fields and values explicitly in a request can be useful to:
-
Specify pairs of "
context" objects and values when the content-profile lacks these fields-
Override when you need dynamic, explicit control of these fields independent of document parsing and the existing content-profile
-
The /public/widget/data request is typically used by the "insertWidget" script. An example below shows how to set the "context" via "insertWidget".
-
The "
if/then/else" conditional logic is configured as a "Content setting condition" of type "context"
Example of 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 that belong 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 Piano Content reporting (based on the "
tag") and -
Piano Content Analytic filters for articles clicked by a recommendation widget (based on the "
itemDefault"; a best practice is available here)
To access "categories" other than "taxonomy" requires an additional "categoryType" parameter in the "condition" statement, like this:
|
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:
|