Recommendation client¶
The ezrecommentation-client package
adds a personalization solution to Ibexa DXP and communicates with
the server that runs the recommendation engine.
Its job is to track the way visitors use your website and recommends content based on their behavior.
Once you become familiar with this article, for more information about integrating the Personalization service, see Developer guide and Best practices.
Configuration¶
Before you can use the Personalization service, you must configure the client.
Set up Content Type tracking¶
For the recommendations to be calculated, apart from visitor events (CLICK, BUY, etc.), the Recommendation engine must be fed with the list of Content Types that are tracked.
You define Content Types to be tracked in the config/packages/ezplatform.yaml file.
The content is then initially exported by a script.
After this, it is synchronized with the Personalization service every time a change
occurs in the Back Office.
The client's configuration is SiteAccess-aware, and can resemble the following example:
1 2 3 4 5 6 7 8 9 | |
Tip
It is recommended that you provide your host_uri, customer_id and
license_key through environment variables: '%env()%'.
| Parameter | Description |
|---|---|
authentication.customer_id |
Your customer ID. |
authentication.license_key |
Your license key. |
host_uri |
The URI your site's REST API can be accessed from. |
included_content_types |
A list of alphanumerical identifiers of Content Types on which the tracking script is shown. |
random_content_types |
A list of alphanumerical identifiers of Content Types that are returned when the response from the server contains no content. |
Advanced configuration¶
If the Content item's intro, author or image are stored in a different Field,
you can specify its name in the ezplatform.yaml file:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
In case a content owner ID is missing, you can set up the default content author in the default_settings.yaml file:
1 2 3 4 | |
You can edit advanced options for the Recommendation engine using the following settings:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
You can use an alphanumeric content identificator remoteId instead of a numeric id. To enable it, add the following code to the configuration file:
1 2 3 4 5 6 | |
Caution
Changing any of these parameters without a valid reason breaks all calls to the Recommendation engine.
Enable tracking¶
The EzRecommendationClientBundle delivers a Twig extension
which helps integrate the user tracking functionality into your site.
Place the following code snippet in the <head> section of your header template:
1 2 3 | |
How tracking works
For more information about tracking in general, see Tracking API and Tracking with yct.js.
Checking whether the bundle provides REST data¶
You can verify the import controller of the bundle by calling the local API.
Use the Accept header; you may need to add an Authorization header if authentication is required.
To check whether the content endpoint is working as expected, perform the following request:
1 2 3 | |
Additionally, check whether the contenttypes endpoint is working with the following request:
1 2 3 | |
The content endpoint returns one Content item and the contenttypes endpoint returns many.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | |
Exporting content information¶
To get recommendations you must first export the content information to the Recommendation engine.
After you define Content Types to be tracked and recommended,
start the full export.
You do it either with the ibexa:recommendation:run-export command...
1 2 3 4 | |
... or by accessing the http://<yourdomain>/api/ezp/v2/ez_recommendation/ endpoint:
1 | |
The bundle exporter collects all content related to the SiteAccesses of this customerID and stores it in files (1).
After finishing, the systems sends a POST request to the webHook endpoint and informs the Recommendation engine to fetch new content (2).
An internal workflow is then triggered (3) so that the generated files are downloaded (4) and imported in the Recommendation engine's content store (5).
The export process can take several minutes.
Re-exporting modified Content Types
If the Content Types to be recommended change, you must perform a new full export
by running the php bin/console ibexa:recommendation:run-export command again.
Checking export results¶
There are three ways to check whether content was transferred and stored successfully in the Recommendation engine:
REST request to the client's content store¶
To get the content of an imported item you can request the following REST resource:
GET https://admin.yoochoose.net/api/<your_customer_id>/item/<your_content_type_id>/<your_content_id>
This way requires BASIC Auth. BASIC Auth username is the customerID and the password is the license key.
Example response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | |
Recommendation client backend¶
In the Back Office, navigate to Personalization > Import and review a list of historical import operations to see whether a full import was successful.
Subsequent content exports¶
The Recommendation engine is automatically kept in sync with the content in Ibexa DXP.
Every time an editor creates, updates or deletes content in the Back Office (1), a notification is sent to https://admin.yoochoose.net (2). The personalization service also notifies other components of the Recommendation engine (3) and it eventually fetches the affected content (4) and updates it internally (5).
Displaying recommendations¶
Client-based recommendations
Recommendations are fetched and rendered asynchronously in the client, so there is no additional load on the server. Therefore, it is crucial that you check whether the content export was successful, because certain references, for example, deeplinks and image references, are included. If the export fails, the Recommendation engine does not have full content information. As a result, even if the recommendations are displayed, they might miss images, titles or deeplinks.
To display recommendations on your site, you must include the asset in the template using the following code:
1 | |
This file is responsible for sending notifications to the Recommendation API after the user clicks on a tracking element.
To render recommended content, use a dedicated showRecommendationsAction from the RecommendationController.php:
1 2 3 4 5 6 7 8 | |
Tip
To check whether tracking is enabled on the front end, use the ez_recommendation_enabled() Twig function.
You can wrap the call to the RecommendationController with:
1 2 3 4 5 | |
Parameters¶
| Parameter | Type | Description |
|---|---|---|
contextItems |
int | instance of eZ\Publish\API\Repository\Values\Content\Content |
scenario |
string | Scenario used to display recommendations. You can create custom scenarios in the Back Office. |
outputTypeId |
int | Content Type you are expecting in response, for example, 10. |
limit |
int | Number of recommendations to fetch. |
template |
string | Template name. |
attributes |
array | Fields that are required and are requested from the Recommendation engine. These Field names are also used inside Handlebars templates. |
You can also bypass named arguments with standard value passing as arguments.
Custom templates
To use a custom template for displaying recommendations,
ensure that it includes event_tracking.html.twig:
{% include 'EzRecommendationClientBundle::event_tracking.html.twig' %}.
Recommendation responses contain all content data that is requested as attribute in the recommendation call. This response data can be used in templates to render and style recommendations.
For example, the following GET request should deliver the response below if the content Fields were previously exported by the export script.
GET https://reco.yoochoose.net/api/v2/<your_customer_id>/someuser/popular.json?contextitems=71&numrecs=5&categorypath=/&outputtypeid=<your_content_type>&attribute=name,author,uri,image
Example response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 | |
Modifying recommendation data¶
You can retrieve data returned from the recommendation engine and modify it before it is shown to the user.
To modify recommendation data, subscribe to RecommendationResponseEvent.
See Event/Subscriber/RecommendationEventSubscriber.php for example:
1 2 3 4 5 6 | |
The -10 refers to priority, which must be negative so this action is performed before the main subscriber is run.
Image variations¶
Displaying image variations is not readily supported yet.
You can work around this limitation by creating a template (based on recommendations.html.twig).
To access a specific image variation through API, add the image parameter to the request URL with the name of the variation as its value.
For example, to retrieve the rss variation of the image, use:
/api/ezp/v2/ez_recommendation/v1/contenttypes/16?lang=eng-GB&fields=title,description,image,intro,name&page=1&page_size=20&image=rss
Troubleshooting¶
Logging¶
Most operations are logged via the ez_recommendation Monolog channel.
To log everything about Recommendation to dev.recommendation.log, add the following to the ezplatform.yaml:
1 2 3 4 5 6 7 | |
You can replace info with debug to increase verbosity.