Enable Personalization¶
The Personalization service is based on a client-server architecture. To enable it, you must set up authentication parameters that you receive from Ibexa.
Get authentication parameters¶
First, either you or another Ibexa user responsible for managing the Ibexa DXP instance must request access to the service.
Set up customer credentials¶
When you receive the credentials, add them to your configuration.
In the root folder of your project, edit the .env.local file by adding the following lines with your customer ID and license key:
1 2 3 | |
Configuring user credentials for multisite setup and different personalization customers
If your installation hosts multiple sites with different customer IDs, for example, to provide separate recommendations for different language versions of the store, you can store all credentials in the same file:
1 2 3 4 5 6 7 8 9 10 11 | |
Configure Personalization¶
The Personalization package adds a personalization solution to Ibexa DXP and communicates with the Personalization server.
Its job is to track the way visitors use the website and recommend content based on their behavior.
For more information about integrating the Personalization service, see Developer guide and Best practices.
Set up item type tracking¶
For the recommendations to be calculated, apart from visitor events (for example, CLICK or BUY), the Personalization server must receive a list of item types that are tracked.
You define item types to be tracked in configuration files. The content is then initially exported by a script. After this, it's synchronized with the Personalization service every time a change occurs (using any method that triggers the event).
The Personalization configuration is SiteAccess-aware. If your installation hosts multiple sites with different customer IDs, for example, to provide separate recommendations for different language versions of the site, provide the credentials that correspond to each of the sites.
The configuration can resemble the following example:
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 | |
Authentication
For data exchange purposes, basic authentication is enabled by default. To change this, contact support@ibexa.co. For security reasons, store the authentication credentials in the ENV file, and don't commit them to the Version Control System. Then, use environment variables to pull them into the YAML file.
| Parameter | Description |
|---|---|
host_uri |
A location where the site's REST API can be accessed. This is where the Personalization server imports items from. |
authentication.customer_id |
A customer ID related to the supported SiteAccess. |
authentication.license_key |
The Personalization service's license key. |
included_item_types |
A list of alphanumerical identifiers of item types on which the tracking script is shown. |
random_item_types |
A list of alphanumerical identifiers of item types that are returned when the response from the server contains no content. |
You can use an alphanumeric content identifier remoteId instead of a numeric id.
To enable it, add the following configuration:
Support for alphanumeric content identifier
Contact support@ibexa.co with your organization's requirements to have the alphanumeric content identifier enabled.
Enable tracking¶
The Personalization client bundle 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 ibexa-tracker.js.
Check whether the bundle provides REST data¶
You can verify the import controller of the bundle by calling the local API. As the API uses token based authorization you first need a valid bearer token.
When you publish a content item a bearer token is created and saved to the ibexa_token db table.
Additionally a POST request is send to the Personalization Engine, containing the token and the Rest URL where the Personalization Engine can fetch the changed Content.
The BEARER_TOKEN is the newest one in ibexa_token table having type=1 and identifier=update. The token has a default lifetime of one day.
You can use this token to check what is provided to the Personalization Engine:
1 2 3 | |
Additionally, check whether the contentlist endpoint is working with the following request:
1 2 3 | |
The content endpoint returns one item and the contentlist 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 | |
Export item information¶
To get recommendations you must first export the item information to the Personalization server.
After you define item types to be tracked and recommended, start the full export.
You need to run the `ibexa:personalization:run-export command per SiteAccesses that you want to use together with Personalization. You need different customer IDs for different SiteAccesses.
1 2 3 4 5 6 | |
The bundle exporter collects all content related to the <site_access_name>/<customer_id> pair and stores it in files to the folder public/var/export/yyyy/mm/dd/hh/mm of your project.
After finishing, the system sends a POST request to the endpoint and informs the Personalization server to fetch new content.
An internal workflow is then triggered, so that the generated files are downloaded and imported in the Personalization server's content store.
The export process can take several minutes.
Re-exporting modified item types
If the item types to be recommended change, you must perform a new full export by running the php bin/console ibexa:personalization:run-export command again.
Check export results¶
There are three ways to check whether content was transferred and stored successfully in the Personalization server:
REST request to client's content store¶
To get the data of an imported item you can request the following REST resource:
GET https://admin.perso.ibexa.co/api/<your_customer_id>/item/<your_item_type_id>/<your_item_id>
This way uses basic authentication. The username is the customer ID 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 | |
Personalization backend¶
In the back office, go to Personalization > Import and review the list of historical import operations to see whether a full import was successful.
Subsequent content exports¶
The Personalization server is automatically kept in sync with the content in Ibexa DXP.
Every time an editor creates, updates or deletes content in the back office, a notification is sent to https://admin.perso.ibexa.co/. The personalization service also notifies other components of the Personalization server and it eventually fetches the affected content and updates it internally.
Display recommendations¶
Client-based recommendations
Recommendations are fetched and rendered asynchronously, so there is no additional load on the server. Therefore, it's 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 Personalization server doesn't 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. To do it, use the following code:
1 | |
This file is responsible for sending notifications to the Recommendation API after the user clicks 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 ibexa_recommendation_enabled() Twig function.
You can wrap the call to the RecommendationController with:
1 2 3 4 5 | |
Parameters¶
| Parameter | Type | Description |
|---|---|---|
contextItems |
int | ID of the content you want to get recommendations for. |
scenario |
string | Scenario used to display recommendations. You can create custom scenarios in the back office. |
outputTypeId |
string | Item type that you expect in response, for example, blog_post. |
crossContentType |
bool | If set to true, returns recommendations for all content types specified in the scenario. |
limit |
int | Number of recommendations to fetch. |
template |
string | Template name. |
attributes |
array | Fields that are required and are requested from the Personalization server. 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 '@IbexaPersonalization/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.perso.ibexa.co/api/v2/<your_customer_id>/someuser/popular.json?contextitems=71&numrecs=5&categorypath=/&outputtypeid=<your_item_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 | |
Modify recommendation data¶
You can retrieve data returned from the Personalization server and modify it before it's shown to the user.
To modify recommendation data, subscribe to RecommendationResponseEvent.
See Event/Subscriber/RecommendationEventSubscriber.php for an 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 isn't supported out of the box.
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/ibexa_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 by using the ibexa-personalization Monolog channel.
To log everything about Personalization to dev.recommendation.log, add the following configuration:
1 2 3 4 5 6 7 | |
You can replace info with debug to increase verbosity.
Set up user roles and permissions¶
Depending on your requirements, you may need to set up edit and view permissions to grant users access to recommendation settings that relate to different SiteAccesses and results that come from these websites.
Configure recommendation logic¶
When you enable the Personalization, you can go back to the back office, refresh the Personalization dashboard and proceed with configuring the logic used to calculate the recommendation results.