This article answers frequently asked questions about migrating from Classic Personalization to Advanced Personalization, including migration behaviour, configuration options, user profiles, event processing and search ranking.
Can I configure Advanced Personalization before migrating from Classic Personalization?
No. The migration from Classic to Advanced Personalization must be completed through the Algolia Dashboard.
This process triggers internal migration steps that deactivate Classic Personalization and enable Advanced Personalization for your application.
The Advanced Personalization Configuration API (PUT /2/config) cannot be used until the migration has been completed and Classic Personalization is inactive. This prevents conflicting configurations between the two versions.
There are several important considerations when migrating:
- Your existing events and data are preserved during migration.
- Your Classic Personalization configuration, including its strategy, facets and Personalization impact, can no longer be updated.
- Classic user profiles stop personalising search results until Advanced Personalization has been configured.
You can review the Advanced Personalization Configuration API documentation before migrating to familiarise yourself with the available parameters.
Migrating from Classic to Advanced Personalization is not currently self-reversible while the feature is in beta. Contact Algolia Support if you need assistance rolling back.
Can Classic Personalization and Advanced Personalization be used on different indices within the same application?
No. Classic Personalization and Advanced Personalization cannot operate simultaneously within the same Algolia application.
Migrating to Advanced Personalization deactivates Classic Personalization at the application level, including for indices that aren't included in your Advanced Personalization configuration.
However, Advanced Personalization supports configuring multiple indices independently within the same application.
This means you can configure Advanced Personalization for different indices, but you cannot have Classic Personalization operating on one index and Advanced Personalization on another within the same application.
Does the personalizationImpact query parameter still work with Advanced Personalization?
Yes. Advanced Personalization introduces the personalizationReRanking configuration parameter, which provides an abstraction of the existing personalizationImpact parameter.
The available settings correspond to the following values:
personalizationReRanking |
personalizationImpact |
|---|---|
none |
0 |
low |
25 |
medium |
50 |
high |
75 |
maximum |
100 |
If personalizationImpact is explicitly passed as a query parameter in a search request, it overrides the personalizationReRanking value configured in Advanced Personalization.
For example, if your Advanced Personalization configuration uses personalizationReRanking: medium, but a search request includes personalizationImpact: 100, the search request uses the impact value of 100.
This means existing implementations that explicitly pass personalizationImpact will continue to apply those values after migration.
Does Advanced Personalization change the ranking information returned in search responses?
No. The way user profiles influence search results remains the same between Classic Personalization and Advanced Personalization.
The ranking information returned in search responses also remains unchanged, including the existing _rankingInfo.personalization.filtersScore field.
The main differences between Classic and Advanced Personalization are how user profiles are generated and the additional capabilities available in Advanced Personalization, such as real-time personalization and user profiles.
As a result, existing implementations that inspect Personalization ranking information can continue to use the same response fields after migration.
How does Advanced Personalization use events to build user profiles?
Advanced Personalization uses user interaction events, such as clicks, views and conversions, to identify user preferences and generate personalised search experiences.
These events are analysed alongside your indexed data to identify patterns and generate user affinities, which represent a user's interests and preferences.
The following event requirements and time windows apply:
- Historical event window: Advanced Personalization uses events from the previous 90 days by default when building user profiles, consistent with Classic Personalization.
- Returning-user requirement: To generate user profiles, your events must include at least one returning user, defined as a user with more than one session within the last 30 days.
-
User tokens: Events must contain valid
userTokenvalues that match those used in search requests, allowing Algolia to associate user interactions with the correct profiles. - Profile updates: User profiles are updated as new events are processed, allowing affinities to reflect changes in user behaviour over time.
The 30-day returning-user requirement does not replace the 90-day historical event window. They serve different purposes: the former is a prerequisite for generating user profiles, while the latter determines how far back historical events can be considered.
For more information, see the Advanced Personalization requirements and limits and How Advanced Personalization works.
Can user affinities learned from one index influence search results on another index?
Yes. Advanced Personalization supports affinities that can be associated with multiple indices.
However, for an affinity generated from events on one index to influence searches on another index, the affinity name must match exactly across both indices.
For example, if two indices contain records with a shared attribute and matching affinity names, events associated with that affinity can contribute to Personalization across both indices.
You can verify which indices are associated with a particular affinity by inspecting the user's profile through the Algolia Dashboard or User Profiles API.
Each affinity includes an indices property listing the indices associated with that preference.
When an affinity applies across multiple indices, the indices property should reference those indices.
For more information, see the Advanced Personalization user profiles documentation.
Which events contribute to the different collections in Advanced Personalization?
Advanced Personalization groups events into collections based on the type of user interaction they represent.
These collections represent different levels of user engagement and can be configured using the relevant event mappings.
Examples include:
| Event type | Typical collection |
|---|---|
| Click events | Viewing record details |
Conversion events with addToCart subtype |
Showing interest in a record |
Conversion events with purchase subtype |
Achieving a goal with a record |
Do conversion events require an eventSubtype?
No. Conversion events without an eventSubtype can still contribute to Advanced Personalization when mapped to the appropriate collection.
However, including the relevant subtype helps distinguish between different conversion actions, such as adding a product to a cart and completing a purchase.
Are filter-based events supported?
Yes. Filter-based events are also supported by Advanced Personalization and can be used as Personalization signals.
Do click events automatically contribute to add-to-cart and purchase collections?
Click events typically represent a different level of engagement from add-to-cart or purchase events. Their contribution depends on how events are mapped to the appropriate Advanced Personalization collections.
For further details, see:
- Configure user events
- How important is it to include event subtypes in my events for Advanced Personalization?
What happens if one index has an error during Advanced Personalization configuration?
Advanced Personalization distinguishes between errors and warnings during configuration.
Errors must be resolved before proceeding with the affected configuration, whereas warnings do not necessarily prevent Personalization from being configured.
Examples of error codes include:
no_eventslow_unique_user_tokensmismatched_object_ids
Some errors affecting a single index can prevent the overall configuration from being saved.
For example, if one index has a no_events error, you may need to remove that index from the configuration or supply the necessary events before saving again.
You should review and resolve any reported errors before completing your Advanced Personalization configuration.
For more information, refer to the Advanced Personalization error-code documentation.