diff --git a/docs/personalization/content_import.md b/docs/personalization/content_import.md
new file mode 100644
index 00000000..cc5f65be
--- /dev/null
+++ b/docs/personalization/content_import.md
@@ -0,0 +1,21 @@
+# 9. Content Import
+
+Basic recommendation algorithms are statistics-based and need only the product ID and user ID. This information is provided by the event tracking as described in chapter [4. Event Types](event_types.md).
+There are several use cases where the recommendation engine requires additional information linked to the products.
+The most important cases are:
+
+- Filtering results based on the category the product is located in ([Category Filter](filters.md#category-filter))
+- Filtering results based on price and product availability ([General Filters](filters.md#general-filters))
+- Sub-models based on custom attribute grouping ([Submodels](recommendation_models.md#submodels))
+- An additional export/import interface is designed to provide editor-based models ([6. Recommendation Models](recommendation_models.md))
+
+There are four different ways to import data into the recommendation system:
+
+- **In-Event:** During the event tracking process, where related data is attached to a click event (e.g. categorypath information)
+- **Push interface:** Classic HTTP POST-based import. It is suitable for uploading single content or editor lists
+- **Pull interface:** The recommendation engine loads an exported file from the specified location in the background. It was designed to upload big portions of information, for example a weekly update of the whole product catalog
+- **Trigger logic:** The recommendation engine triggers a transactional full import at the customer's system. Therefore some custom development or a plugin is needed. 
+
+!!! tip
+
+    You can find Specification for Import interfaces in the developer guide under [Content API](https://doc.ezplatform.com/en/master/guide/personalization/content_api.md).
diff --git a/docs/personalization/content_types.md b/docs/personalization/content_types.md
new file mode 100644
index 00000000..66b9045f
--- /dev/null
+++ b/docs/personalization/content_types.md
@@ -0,0 +1,33 @@
+# 5. Content Types
+
+In the **advanced** edition of the recommendation engine it is possible to build different recommendation domains. It can be achieved by splitting all the products into different content types. There are several possible use cases for content types.
+
+- A publisher tracks articles, pictures and videos as three different types.
+- A supermarket splits all the products into food and non-food product groups.
+- An owner of several web shops uses a single account for all of them
+
+The content types concept provides the possibility to make so-called cross domain recommendations (like "Users who watched this film also read this book" or "Users who read this article also liked these photos").
+
+Additionally to the logical separation of the content domains the content types provide another important advantage. They play a role if different types of products are not equally popular but must be recommended equally often. For example, on a publisher's page users watch videos less often than they read articles. If the most popular products are requested without content type splitting, there will be most likely no videos in the result. If articles and videos are split into different content types, it is possible to explicitly request popular videos and/or popular articles.
+
+Below is a comparison for different ways of splitting content in the recommendation engine.
+
+|Use case|content types solution (domain context)|Attribute based sub-models (group context)|Different recommendation engine accounts|
+|---|---|---|---|
+|Cross-group recommendation requests are possible|yes|yes|no|
+|Products must belong to one group|mandatory|optional|mandatory|
+|Products can belong to multiple groups|no|yes|no|
+|Single recommendation request can contain products from different groups|no|yes|no|
+|Product can change the group it belongs to|no|yes|no|
+|Different content types share the scenario and model configuration|yes|yes|no|
+|Required Recommender Edition|single advanced|-|multiple basic|
+
+#### Scenario configuration
+
+If multiple content types are enabled, one must enable this output type for every scenario that should recommend this type.
+
+![Scenario settings](img/scenario_configuration.png)
+
+Every scenario supports a single input type and multiple output types (see [8. Scenarios](scenarios.md)). Every recommendation request delivers only content of one output content type (even if multiple are selected in the interface above). The output type is set during the recommendation request and must be covered by the list of the supported content types in the requested scenario.
+
+You can find more information about fetching recommendations in developer documentation: [Recommendation API](https://doc.ezplatform.com/en/master/guide/personalization/recommendation_api.md)
diff --git a/docs/personalization/dashboard.md b/docs/personalization/dashboard.md
new file mode 100644
index 00000000..4b95b70b
--- /dev/null
+++ b/docs/personalization/dashboard.md
@@ -0,0 +1,77 @@
+# 3. Dashboard
+
+The administration dashboard is the entry point to configure and control the Personalization Solution. It is split into two main sections:
+
+- The top section contains diagrams representing statistical information on how the recommendation engine is used and how successful - depending on the KPIs - recommendations are.
+- The lower section is made up of many configuration tabs. It contains at least the Scenarios and Added revenue information. Depending on the license and registration information there is also a tab for A/B-Testing, Plugin, Content Import and Newsletter settings
+
+## Statistics
+
+![Dashboard statistics](img/dashboard_statistics.png)
+
+The diagram part consists of three main blocks:
+
+- Collected events:
+    The input data (clicks, buy, clickrecommended, ...) which is going into the recommendation engine for the customer website (see [4. Event Types](event_types.md) for more information).
+- Recommendation calls:
+    The number of recommendation calls (total and per scenario)
+- Clicked recommendations, Purchased recommendations and Revenue by recommendations:
+    The effectiveness of recommendations regarding clicked recommendations, revenue through recommendations and absolute number of converted/sold recommendations
+
+The conversion (or click-through) rate is an **indicator of the acceptance** and therefore the **quality of recommendations**. It is calculated as follows: The total number of clicked recommended products divided by the amount of recommendation calls. This statistic only delivers reliable information if the tracking is implemented correctly.
+
+The revenue-through-recommendations is a **monetary value** which was additionally created by recommendations. It is calculated as follows: If a user buys product A and has clicked on it as a recommendation within 30 minutes before we assume it was sold through a recommendation.
+
+Purchased recommendations is the **plain number of sold recommendations** without any revenue/price information.
+
+All statistical information can be downloaded in MS Excel format. The timeframes depend on the selection of the diagram period (day, week, month, 3 months and year) but can also be customized.
+
+## Configuration Settings
+
+### Revenue details
+
+This tab shows you when recommendations were bought and how much time passed between the click on the recommendation and the buying event.
+
+![Dashboard Added Revenue](img/dashboard_added_revenue.png)
+
+### Scenarios
+
+The scenario overview shows all available scenarios. Additional info like a description and the delivered recommendations in the selected timeframes are also presented.
+
+![Dashboard scenarios](img/dashboard_scenarios.png)
+
+Scenarios with green status bars indicate that all models can provide recommendations. Yellow bars indicate that only a part of the configured models can provide recommendations and red ones indicate that no recommendations can be delivered. See [8. Scenarios](scenarios.md).
+
+### Models
+
+This tab allows you to see all available models and configure them, see [6. Recommendation Models](recommendation_models.md) 
+
+![Dashboard models](img/dashboard_models.png)
+
+### Preview
+
+This tab shows you recommendation preview based on a Scenario.
+
+![Dashboard Preview](img/dashboard_preview.png)
+
+### A/B Testing
+
+This tab holds an overview of A/B Tests. Finished, currently running and scheduled tests are listed here.
+
+![Dashboard A/B Tests](img/dashboard_ab_tests.png)
+
+### Plugins
+
+If a plugin was used to register the service, specific settings can be configured under **Plugins**.
+
+![Dashboard Plugins](img/dashboard_plugins.png)
+
+### Import/Export
+
+Item import jobs are used to fetch data from a customer system. Data-mappings and schedule times are defined here.
+
+![Dashboard Item Import](img/dashboard_item_import.png)
+
+### Newsletter
+
+Newsletters are sent out if certain events happen, e.g. a user did not come back for a number of days or the shopping cart was abandoned. Style and conditions are configured in the **Newsletter** tab.
diff --git a/docs/personalization/event_types.md b/docs/personalization/event_types.md
new file mode 100644
index 00000000..65f0e929
--- /dev/null
+++ b/docs/personalization/event_types.md
@@ -0,0 +1,34 @@
+# 4. Event Types
+
+It was already mentioned that the recommendation engine collects events and computes recommendations based on user behavior. The most important events collected by the engine are click and buy events. They are enough for providing basic recommendations. There are some additional events for creating more complex scenarios and providing statistics about acceptance of recommendations, such as conversion rate or revenue. 
+
+![Overview of how events work](img/events_overview.png)
+
+All possible events used in the system are described in the following table.
+
+|Event|Description|
+|---|---|
+|CLICK|It should be sent to the recommendation engine if a user opens any detail page on the website.|
+|BUY|It should be sent if something was bought.|
+|CONSUME|Similar to the BUY event but without a payment. It is designed for publisher websites. This event is sent if an article or a web page is consumed (usually "read" or a "pre-listened" video).|
+|RENDER|It should be sent if a recommendation is shown on the web page. This information is used by filters to suppress repeated recommendations of the same item.|
+|FOLLOW / CLICKRECOMMENDED|If a user clicks on the recommended product the "clickrecommended" (sometimes called FOLLOW) event must be sent. It allows building acceptance statistics and enables A/B testing.|
+|TRANSFER / LOGIN|A special type of event to deal with a user login after the user already surfed on the web page anonymously. It should always sent if the identifier of the user changed. As a result the anonymous history of the user will be transferred from the old identifier to the new one. This workflow is automatically done in the recommender engine.|
+
+#### Additional events for the advanced edition
+
+|Event|Description|
+|---|---|
+|BASKET|It should be sent when the user adds the specified product to the shopping cart. It allows creating recommendations for products the customer is interested in but which they finally did not buy for some reason.|
+|BLACKLIST|Allows a user to suppress this recommendation. If the recommendation engine gets this event, the specified product or article won't be recommended anymore to the specified user. Default duration of suppression is one year.|
+|OWNS|Same as BUY, but without influence on the statistics. It can be used if a user already owns the product, but bought it somewhere else, to avoid recommending it again.|
+|RATE|Additional models can be created for the advanced edition, using this type of events. It allows building recommendations not only for implicit tracking events like "clicked" or "buy", but also for events with explicit value like "rated" or "liked". These events need additional integration into the web page to allow the user to give an appropriate feedback. The event should be triggered as a result of this user feedback.|
+
+All the events require the current user ID and the ID of one or more context items. Some events need additional information. For more sophisticated algorithms and result filtering event types with additional parameters are needed. In the table below is a brief overview of additional parameter information.
+
+|Event|Additional information|
+|---|---|
+|CLICK|Category path of the product a customer clicked on can be attached to the event. It is an alternative way to provide this information for a product without having a catalogue/export. This way is available for both basic and advanced editions. If an export is available to be fed into the recommendation engine, this information is ignored.|
+|BUY|The price that a user paid for the product. This is an important parameter for the statistics and especially for A/B tests. Quantity of the products bought must be sent as well to be used in the revenue statistics.|
+|FOLLOW/CLICKRECOMMENDED|The scenario which provided the recommendations must be sent in this event.|
+|RATE|The rating (for example 1 to 5 stars) can be sent as an additional parameter.|
diff --git a/docs/personalization/filters.md b/docs/personalization/filters.md
new file mode 100644
index 00000000..33e2b9be
--- /dev/null
+++ b/docs/personalization/filters.md
@@ -0,0 +1,114 @@
+# 7. Filters
+
+## Category Filter
+
+For every row in the scenario configuration you can define a category filter. If the filter is activated, only items from the specified category will be recommended. The actual category used to filter on is specified in the parameters of each recommendation request.
+
+There are two ways to specify a category in a recommendation request:
+
+- No context items, but the **category explicitly provided in the request**. This recommendation call is usually placed on the category overview page for getting most popular products of the selected, actual category (in the figure it is called "reference category").
+- **Context items are provided** and categories of all context items are used for the request. This approach is recommended only if it is technically impossible (or too complex) to provide the category information explicitly.
+
+Depending on configuration of the filter, the recommendation engine can take different approaches to finding the actual set of categories the products will be recommended from.
+
+The following example explains the different possibilities in more detail.
+
+Depicted below is the configuration dialog - available in the GUI on the right side of the model configuration tab in a scenario (see [Advanced Model Configuration](recommendation_models.md#advanced-model-configuration)) - and category structure which is basically the site navigation:
+
+![Category path screenshot](img/categorypath_filter.png)
+
+![Category path tree](img/categorypath_tree.png)
+
+The table below lists the possible configurations and categories that recommended items will be fetched from.
+
+In all examples we assume that the category received in the request is **"/Furniture/Desks&Tables/Tables"**.
+
+|category Path Filter configuration|Target categories to fetch recommended products from|
+|---|---|
+|Always recommend products from the whole shop. Do not use category path for filtering.|All categories ("Plants", "Furniture" and below).|
+|Recommend only products from the same category ("also include..." is not checked).|Category "Tables" and all the sub-categories below ("Garden tables" and "Living room tables").|
+|Recommend only products from the same category. "Also include parent category" is set to 1.|Category "Desks/Tables" and below including "Desks", "Tables" and all their sub-categories.|
+|Recommend only products from the same category. "Also include parent category" is set to 2.|Category "Furniture" and below.|
+|Recommend products from the same main category and its subcategories from level 1.|Category "Furniture" and below.|
+|Recommend products from the same main category and its subcategories from level 2.|Category "Desks/Tables" and below.|
+|Recommend products from the same main category and its subcategories from level 3.|Category "Tables" and below.|
+
+It is possible to provide multiple reference categories (both in the request and over the context item or items). In this case the superset of the recommendations will be returned. The results are sorted based of global weight of the recommendations. Depending on the popularity of the categories the more popular category will most probably push the less popular categories out of the results.
+
+If the recommended item is located in more than one category, it will be recommended if at least one category is requested in this recommendation call.
+
+### Multiple Categorypath dimensions for popularity models
+
+The categorypath parameter is very powerful in its usage. The default approach is to represent content in the navigation-based structure of a website which is used by default. If there is a need to represent available items of a website in different dimensions (taxonomies) it is possible to do this out-of-the box simply by enriching the categorypath information of an item, without changing any settings in the recommender engine.
+
+To make it a bit clearer let's take a look at the following example: In the above mentioned shop both furniture and plants are sold and they are structured based on site navigation. Typically customers would look for computer desks and get a list of recommendations of all computer desks in the shop. If desired, the recommendation engine could also use another dimension for filtering recommendations, for example a "brand" dimension. In this case the user would get recommendations for all items from the same "brand".
+
+In case of popularity based recommendations it will be possible to get most popular products based on the main navigate tree (most popular desk) or based on the brand (most popular IKEA item).
+
+Some examples of common representation dimensions of items beyond the site navigation:
+
+|Business|Possible dimensions|
+|---|---|
+|eCommerce|manufacturer (e.g. BOSCH, Renault, ...)</br>season (e.g. winter, spring, ...)</br>price range (e.g lowprice, midprice, highprice, ...)</br>platform (e.g. Mac, Windows, Linux ...)|
+|Book store|genre (e.g. action, science, ...)</br>author (e.g. George R. R. Martin, ...)|
+|Publisher site|global subject (e.g. politics, sports, ...)</br>physical location (e.g. Cologne, Munich, ...)</br>timeframe (time identifier like 2013-07-04)|
+
+You should avoid using category filtering with also-click/also-buy and stereotype models. These models usually contain only similar items. Additional filtering will probably remove the best results from the list of possible recommendations. The only exception to this rule could be copyright or legal issues like removing adult content. For the last use case sub-models and item types often provide better results. See the following chapters for more information:
+
+[5. Content Types](content_types.md)
+
+[Submodels](recommendation_models.md#submodels)
+
+To provide category filtering, the recommendation engine must know the categories the products belongs to. See the following chapters for more information:
+
+[4. Event Types](event_types.md)
+
+[9. Content Import](content_import.md)
+
+## General Filters
+
+For every recommendation scenario a set of filters can be defined. They are applied to all recommendations from every model linked to this scenario. In the edit dialogue of a scenario you can find the user interface to manage filters.
+
+![General filter settings](img/scenario_configuration_full.png)
+
+|Filter|Requirements and restrictions|
+|---|---|
+|Do not recommend items the user has already purchased|The recommendation engine stores the buy (e-commerce) and consume (publisher) events of every user for one year. When this filter is activated, the user won't get these products recommended again.|
+|Max. repeated shows of identical recommendations per session|If this filter is activated, this content/product will be removed from all recommendation lists of the current user session after being recommended n times before.|
+|Do not recommend the item currently viewed|Remove the context items from the recommendation list. Usually it makes sense to activate this filter except in the "Bundle" and "Ultimately bought" recommendation case ([6. Recommendation Models](recommendation_models.md)).|
+
+**Filters which are available only in the advanced solution**
+
+|Filter|Requirements and restrictions|
+|---|---|
+|No top-selling items|Removes products from the recommendation list which are recommended by the top selling model (even if the model itself is not linked to this scenario). It is another way to remove very popular products from the recommendation list if you are not interested in showing them again. It makes no sense to apply this filter to a top selling scenario as it will filter out every recommendation.|
+|Item price should be higher than the specified value|This filter could be used to remove very cheap but popular items from the recommendation list. For example an optometrist wants to show the most popular designer glasses on the home page to avoid displaying insurance subsidized cheap models and glass cleaning cloths. This filter relies on product metadata and uses [prices exported to the recommendation engine](content_import.md).|
+|Item price should be equal or higher than the price of the context product|Like the filter above it compares prices exported to the recommendation engine against the product which is currently shown.|
+|Do not recommend if price is unknown|If a product's price is not available then it will not be recommended.|
+
+**Special and always enabled filters (advanced edition only)**
+
+|Filter|Requirements and restrictions|
+|---|---|
+|Editor blacklisted products.|Advanced edition gets several editor-based models ([6. Recommendation Models](recommendation_models.md)). One of them is an editor blacklist. The products from the blacklist will always be removed from every list of recommendations. You can use this feature to remove some standard products which users will buy in any case without recommendation (bread, butter, milk) or non-existing test products which are only used by a robot to check if the shop software is working properly.|
+|Customer blacklisted products|In addition to the standard set the website can send blacklist events for selected products and users. It can be implemented as e.g. a button "I do not like this product". If a user added a product to their blacklist, it will not be recommended to them anymore.|
+|Product validity interval|Additional product information [can be exported to the recommendation engine](content_import.md). If the product information is available and contains a validity time interval (for example the product is available only until 24 December 2014), it will be used to remove invalid products from the recommendation list.|
+
+## Boost-Filters
+
+In addition to general filters, which remove specified elements from recommendations, the boost filter allows shifting (boosting) selected recommended items to the top positions of the recommendation response. This may happen if a selected attribute of the customer has the same value as the selected attribute of the recommended item. For example, we can show the news from the user's home country with higher priority than the rest.
+
+Assuming every item in the picture below has the attribute "country" and the user has the attribute "country\_of\_origin", the boost filter can be configured in **Filter settings** like this:
+
+![Boost filter settings](img/boost_filters.png)
+
+...which leads to boost recommendations for certain users:
+
+![Boost filter example](img/boost_example.png)
+
+This type of filter needs both item import and user attribute import.
+
+See developer guide for more information on item and user attributes import:
+
+- [Insert XML Content](https://doc.ezplatform.com/en/master/guide/personalization/content_api.md#insert-xml-content)
+- [User API](https://doc.ezplatform.com/en/master/guide/personalization/user_api.md)
diff --git a/docs/personalization/img/attribute_config.png b/docs/personalization/img/attribute_config.png
new file mode 100644
index 00000000..05a5f2b0
Binary files /dev/null and b/docs/personalization/img/attribute_config.png differ
diff --git a/docs/personalization/img/attribute_example.png b/docs/personalization/img/attribute_example.png
new file mode 100644
index 00000000..af881042
Binary files /dev/null and b/docs/personalization/img/attribute_example.png differ
diff --git a/docs/personalization/img/boost_example.png b/docs/personalization/img/boost_example.png
new file mode 100644
index 00000000..631f5e73
Binary files /dev/null and b/docs/personalization/img/boost_example.png differ
diff --git a/docs/personalization/img/boost_filters.png b/docs/personalization/img/boost_filters.png
new file mode 100644
index 00000000..70378fcb
Binary files /dev/null and b/docs/personalization/img/boost_filters.png differ
diff --git a/docs/personalization/img/categorypath_filter.png b/docs/personalization/img/categorypath_filter.png
new file mode 100644
index 00000000..5e0fccd7
Binary files /dev/null and b/docs/personalization/img/categorypath_filter.png differ
diff --git a/docs/personalization/img/categorypath_tree.png b/docs/personalization/img/categorypath_tree.png
new file mode 100644
index 00000000..469e2a9e
Binary files /dev/null and b/docs/personalization/img/categorypath_tree.png differ
diff --git a/docs/personalization/img/dashboard_ab_tests.png b/docs/personalization/img/dashboard_ab_tests.png
new file mode 100644
index 00000000..52aaabf0
Binary files /dev/null and b/docs/personalization/img/dashboard_ab_tests.png differ
diff --git a/docs/personalization/img/dashboard_added_revenue.png b/docs/personalization/img/dashboard_added_revenue.png
new file mode 100644
index 00000000..e88d7f82
Binary files /dev/null and b/docs/personalization/img/dashboard_added_revenue.png differ
diff --git a/docs/personalization/img/dashboard_item_import.png b/docs/personalization/img/dashboard_item_import.png
new file mode 100644
index 00000000..127efa78
Binary files /dev/null and b/docs/personalization/img/dashboard_item_import.png differ
diff --git a/docs/personalization/img/dashboard_models.png b/docs/personalization/img/dashboard_models.png
new file mode 100644
index 00000000..e0e9610f
Binary files /dev/null and b/docs/personalization/img/dashboard_models.png differ
diff --git a/docs/personalization/img/dashboard_plugins.png b/docs/personalization/img/dashboard_plugins.png
new file mode 100644
index 00000000..139fabd2
Binary files /dev/null and b/docs/personalization/img/dashboard_plugins.png differ
diff --git a/docs/personalization/img/dashboard_preview.png b/docs/personalization/img/dashboard_preview.png
new file mode 100644
index 00000000..12557bc9
Binary files /dev/null and b/docs/personalization/img/dashboard_preview.png differ
diff --git a/docs/personalization/img/dashboard_scenarios.png b/docs/personalization/img/dashboard_scenarios.png
new file mode 100644
index 00000000..74bdc86c
Binary files /dev/null and b/docs/personalization/img/dashboard_scenarios.png differ
diff --git a/docs/personalization/img/dashboard_statistics.png b/docs/personalization/img/dashboard_statistics.png
new file mode 100644
index 00000000..4830b73d
Binary files /dev/null and b/docs/personalization/img/dashboard_statistics.png differ
diff --git a/docs/personalization/img/events_overview.png b/docs/personalization/img/events_overview.png
new file mode 100644
index 00000000..d15d7232
Binary files /dev/null and b/docs/personalization/img/events_overview.png differ
diff --git a/docs/personalization/img/model_config_details.png b/docs/personalization/img/model_config_details.png
new file mode 100644
index 00000000..416ece38
Binary files /dev/null and b/docs/personalization/img/model_config_details.png differ
diff --git a/docs/personalization/img/model_config_editor.png b/docs/personalization/img/model_config_editor.png
new file mode 100644
index 00000000..544cb8de
Binary files /dev/null and b/docs/personalization/img/model_config_editor.png differ
diff --git a/docs/personalization/img/model_config_editorial_list.png b/docs/personalization/img/model_config_editorial_list.png
new file mode 100644
index 00000000..b479de8f
Binary files /dev/null and b/docs/personalization/img/model_config_editorial_list.png differ
diff --git a/docs/personalization/img/model_config_in_dashboard.png b/docs/personalization/img/model_config_in_dashboard.png
new file mode 100644
index 00000000..29b68a69
Binary files /dev/null and b/docs/personalization/img/model_config_in_dashboard.png differ
diff --git a/docs/personalization/img/scenario_configuration.png b/docs/personalization/img/scenario_configuration.png
new file mode 100644
index 00000000..dc0cac23
Binary files /dev/null and b/docs/personalization/img/scenario_configuration.png differ
diff --git a/docs/personalization/img/scenario_configuration_full.png b/docs/personalization/img/scenario_configuration_full.png
new file mode 100644
index 00000000..ada1ea29
Binary files /dev/null and b/docs/personalization/img/scenario_configuration_full.png differ
diff --git a/docs/personalization/img/scenario_matrix.png b/docs/personalization/img/scenario_matrix.png
new file mode 100644
index 00000000..1eb76b4b
Binary files /dev/null and b/docs/personalization/img/scenario_matrix.png differ
diff --git a/docs/personalization/img/scenario_preview.png b/docs/personalization/img/scenario_preview.png
new file mode 100644
index 00000000..b7e92a50
Binary files /dev/null and b/docs/personalization/img/scenario_preview.png differ
diff --git a/docs/personalization/img/submodel_config.png b/docs/personalization/img/submodel_config.png
new file mode 100644
index 00000000..76fcec1b
Binary files /dev/null and b/docs/personalization/img/submodel_config.png differ
diff --git a/docs/personalization/img/use_case_detail_page.png b/docs/personalization/img/use_case_detail_page.png
new file mode 100644
index 00000000..37aff8b5
Binary files /dev/null and b/docs/personalization/img/use_case_detail_page.png differ
diff --git a/docs/personalization/img/use_case_landing_page.png b/docs/personalization/img/use_case_landing_page.png
new file mode 100644
index 00000000..b7e46b31
Binary files /dev/null and b/docs/personalization/img/use_case_landing_page.png differ
diff --git a/docs/personalization/img/use_case_shopping_basket.png b/docs/personalization/img/use_case_shopping_basket.png
new file mode 100644
index 00000000..4e7c7c2d
Binary files /dev/null and b/docs/personalization/img/use_case_shopping_basket.png differ
diff --git a/docs/personalization/personalization.md b/docs/personalization/personalization.md
new file mode 100644
index 00000000..08e69146
--- /dev/null
+++ b/docs/personalization/personalization.md
@@ -0,0 +1,7 @@
+# 1. Personalization
+
+!!! note "E-Commerce vs. Publisher Wording"
+
+    This guide's wording is more related to the E-Commerce Personalization Solution but can be used for a thorough understanding of a Publisher Personalization Solution as well.
+
+    Keep in mind that a product or item can be referred to as content and the buy event for non-paid publisher content is replaced by the consume event.
diff --git a/docs/personalization/recommendation_models.md b/docs/personalization/recommendation_models.md
new file mode 100644
index 00000000..e12ea1dd
--- /dev/null
+++ b/docs/personalization/recommendation_models.md
@@ -0,0 +1,151 @@
+# 6. Recommendation Models
+
+Chapter [2. Use Cases](use_cases) describes where recommendations can be used in real-world situations. They are based on algorithms and the calculated result of an algorithm is called a model. The models work in the background and are updated regularly to provide recommendations. There are several types of models available:
+
+### Models available for both basic and advanced edition
+
+#### Popularity
+
+Classic popularity recommendation. The model can be customized using time-dependent weights (recent events are more important) and category based filtering (bestsellers in selected category and/or subcategories).
+
+#### Also clicked/purchased
+
+This type of recommendation is often called "Collaborative Filtering based on user data" and is a proven approach to calculating recommendations. It recommends products which are usually clicked or purchased together. It is very simple to configure, needs no maintenance and it is a very powerful model.
+
+#### Ultimately bought
+
+This model combines click and buy events. In human readable form it could be something like "Users who looked for that kind of product finally bought this". It therefore provides a "matching factor" of searching and buying. This model suggests alternative products which customers bought after they clicked on the selected product. In contrast to the "also-bought" model it recommends products that are related but not purchased together. This model is the best choice to suggest alternative products for their search. For example, a user searches for a book which explains how to cut trees. If they finds a book and on the book page this exact same book is being recommended, it means that several users interested in cutting trees bought this book (and not others), which hints that this book is the very best choice.
+
+#### History based
+
+Pseudo recommendation model to show the user products from his own history. Like "you have just watched" box.
+
+### Additional models are available for advanced editions
+
+#### Frequently bought together / Bundle recommendations
+
+Products that were bought in this combination for at least n times can be treated as bundles and recommended as a "package". Based on the product which is currently shown, this model can recommend other products that fit exactly the one the user is currently looking at. An example could be:
+
+A user wants to buy a smartphone and browses on the detail page of smartphone X. Additionally to the "Also Clicked" recommendations, the Recommender Engine would recommend the bundle *Smartphone X + Smartphone X Cover + Headphones* as they were  bought together in exactly this combination for at least five times.
+
+It is not guaranteed that there's a bundle available for every product. Therefore a rendering logic should display a box of bundle recommendations only if they are available, otherwise the box can be left out. Remember that the currently displayed product is always included in the bundle.
+
+#### Content Based (by attributes)
+
+The content based algorithm calculates the similarity scores among products based on given attributes. This algorithm depends on expert knowledge because you should be able to define the most important attributes of the product catalog. An example could be the price, the producer or the location of a product. In the news domain, this may be the story location the article is talking about, the author or the category. The distinct attributes should be limited in their range (a nominal set) because it does not make sense to build similarities based on attributes that are different for each product (e.g. a timestamp or EAN-Code). There is also a need to assign weights to these attributes since they are used to compute the importance weight of each attribute for the similarity.
+
+#### Content Based (by semantic full text analysis)
+
+This model provides similarities based on free text analysis and indexing. This is a very powerful model publishers can use to get similar articles based on their content without the need of manual maintenance of related articles by e.g. editors. The full text analysis algorithm uses a search engine in the background.
+
+#### Similar Rated
+
+The similar rated algorithm provides recommendations based on user preferences. It predicts similar articles which the user will probably like and that will suit their interests. Recommendations for articles similar to their dislikes are suppressed.
+
+#### Best Rated
+
+The best rated model provides recommendations based on algorithms that include the ranking values and the amount of distinct ratings. It is best suited for landing or category pages.
+
+#### Random
+
+Semi-random products from the most recent ones. It allows injecting new products to the recommendation while the history based models are not yet able to recommend products based on the statistics. It is a really simplified and unsophisticated alternative if no other information is available to calculate and provide recommendations.
+
+This model is not built based on the history footprints but based on the imported product catalog.
+
+#### Editor based
+
+Products that are manually selected by a human. A customer can replace an automatically generated recommendation with a predefined list. It is best suited when the store administrator wants to add special offers or sell stock remains. It could also be called "static recommendations".
+
+#### Blacklist
+
+Products on this list will never be recommended in any scenario. Usually test products or products that are used for system monitoring are placed on this list. Be careful to use this model in any scenario config, it works globally!
+
+## Advanced Model Configuration
+
+Most of the models provide additional configuration parameters for customization. Here is an example:
+
+Open a model configuration in the Dashboard and enter the model configuration of a Collaborative-Filtering model
+
+![Model configuration in the Dashboard](img/model_config_in_dashboard.png)
+
+![Model configuration details](img/model_config_details.png)
+
+or an Editor-Based model
+
+![Model configuration - Editor-Based model](img/model_config_editor.png)
+
+![Model configuration - Editorial list](img/model_config_editorial_list.png)
+
+The parameters supported by the different types of models are described in the table below. Some models support submodels, see chapter [Submodels](#submodels) for more information. Additional differentiation criteria is the supported context. If a model requires context it can only be linked to scenarios that provide the necessary context.
+
+|Model type|Available parameters|Submodel support|Context|
+|---|---|---|---|
+|Popularity|Relevant event history defines the time period for which the statistics must be analyzed. Dependent on the product type it can be between several months and several hours.Fast event aging can be used to weight newer events higher than older events.|yes</br>submodels based on category are enabled by default|not needed|
+|Also clicked/bought / Ultimately bought|Both also clicked and ultimately bought models allow to define the relevant event history.|yes, manual|required (either context items or user data)|
+|Random|This model requires the maximum age for the items that should be recommended by this model.|no|not supported|
+|History based|The type of the history (click-history or buy-history) must be specified|no|required (user data)|
+|Editor based|The list of recommendations must be created manually by the editor.|no|not supported|
+|Blacklist|The list of items that should be excluded from the recommendations must be created manually by the editor.|no|not supported|
+
+Do not confuse event history age with item age. History age is the age of the user's footprint (for example "they clicked on the product A two weeks ago"). Item age is the time over which the item is available in the shop - so to say "how new is the item". The history is filled automatically over event tracking (see [4. Event Types](event_types.md)). The item catalog must be filled separately over an item import.
+
+## Submodels
+
+Statistics-based recommendations often have the disadvantage of providing recommendations limited to the "most"-popular, "most"-suitable to you or "most"-similar products. Often it is needed to extend the set of available recommendations by defining a subset of most-"something" items based on some external criteria. For example:
+
+- most popular products for the predefined age (searching for a toy)
+- also bought products with the same color (for clothes)
+- also bought products with a predefined price (searching for a birthday present)
+
+Submodels provide the possibility to group all the products based on an attribute. Recommendations can then be requested especially for the selected group.
+
+#### Nominal Attributes
+
+If the possible values of some attribute are a limited set of values, we talk about a nominal attribute submodel, for example the number of possible colors. The set of possible values is usually limited and every product has a single color attached to it.
+
+Submodels must be manually configured. Therefore it works only if the number of possible values is relatively small and there is a large group of products for every value. Good examples would be "color" for clothing store, "genre" for a book store or "city district" for a newspaper. Bad examples would be ~~street name~~ (there are too many of them), ~~book author~~ (there are too many of them as well) or EAN-Code (they are unique and therefore hard to group).
+
+Coming back to the color example. We are configuring submodels for a clothing store and want to get recommendations for some color (it can be a predefined color or a color of the context item). Every manufacturer has its own color classification. Similar colors can be grouped together as shown in the picture below:
+
+![Attribute example](img/attribute_example.png)
+
+The configuration is done using the property dialog of the recommendation model.
+
+![Attribute configuration](img/attribute_config.png)
+
+After the submodel is configured and built (happens automatically during the nightly build process) there are several cases for recommendations. Based on the example above the following are possible:
+
+|Attribute example in the recommendation request|Result|
+|---|---|
+|color=lime|Value "lime" is found in the green-ish group (Group 1). There are products in this group. If a model has some of them, they will be recommended.|
+|color=sand|Value "indigo" is found in the blue-ish group. There are no products in the group. Nothing will be recommended by this model. The fallback model (if configured) will be used.|
+|color=white|Value "white" was not found in any of groups. The main model will be used. Items from all submodel groups can appear in the result (as if the submodels were not configured at all.).|
+|no attribute specified|The main (full) model will be used, means the request is handled as if submodels were not configured at all. Products from the whole shop could appear in the recommendation list.|
+
+#### Numeric Attributes
+
+Similar to the nominal submodels, the configuration is about the definition of subgroups. 
+It is done by selecting limits for every group.
+
+![Submodel configuration](img/submodel_config.png)
+
+There are two values used for setting the limits — `from` and `to`.
+
+The logic behind it is as follows:
+
+- The `from` value indicates the beginning of the range of the subgroup and belongs to it.
+- The `to` value indicates only the range end and does not belong to the subgroup.
+- The **only exception** is the last of the defined subgroups.
+In its case, the `to` value indicates the range end and also belongs to it. 
+
+!!! note
+
+    1. Both numeric and nominal attribute can have multiple values. Such a product will be placed in multiple submodel groups.
+    1. Submodel results are not available immediately after the submodel is configured. In contrary to category filters and general filters, submodels must be (re)built during the nightly building process. The results are usually available on the next day.
+    1. It is possible to specify a single or multiple attributes with multiple values for requesting recommendations. In this case the recommendation will be fetched from all the submodels and merged based on the weight (aka relevance). If one of the submodels delivers recommendations with better relevance (which is very often the case) it is possible that the results of other models will be removed from the list.
+
+!!! tip
+
+    Once configured, submodels are enabled for the model globally. All the scenarios which use this model will be aware of it. If it is not intended to activate the recommendation grouping in some cases, do not provide the attribute parameter in the request. The submodel is not used then.
+
+    See [Recommendation API](https://doc.ezplatform.com/en/master/guide/personalization/recommendation_api.md) in the developer documentation for more information.
diff --git a/docs/personalization/scenarios.md b/docs/personalization/scenarios.md
new file mode 100644
index 00000000..e17a6765
--- /dev/null
+++ b/docs/personalization/scenarios.md
@@ -0,0 +1,23 @@
+# 8. Scenarios
+
+A scenario is a configuration for getting recommendations. It consists of:
+
+1. a content type to be returned as recommendation, 
+1. a filter configuration,
+1. a set of models to be used for generating recommendations.
+
+![Scenario configuration](img/scenario_configuration_full.png)
+
+We strongly encourage adding several models to a scenario in order to avoid empty recommendation boxes. In the configuration interface there is a matrix provided for the configuration. You can drag available models from the left side into the scenario matrix on the right side.
+
+![Scenario configuration matrix](img/scenario_matrix.png)
+
+The scenario configuration field has several rows. Models located in the same row will be used in parallel and the result will contain an equally distributed mixture of all used model results (horizontal configuration). Models located on the second and third row will be used only if models from the row above return no or not enough results (vertical configuration).
+
+Following the example in the images, the first recommendations that will be displayed to the user will come from "Also purchased". If there are no or not enough recommendations available, the "Also clicked" model will be requested. If there are still not enough products in the result set, the "Top purchased" products from the Fail-safe row (not visible in the example image) will be added according to the number of requested recommendations. On the right side of the first rows there is a button to configure Category Filter usage in the recommendation request. This is described in detail in [Category Filter](filters.md#category-filter).
+
+In contrast to the model configuration described in the chapter [6. Recommendation Models](recommendation_models.md), the configuration performed in this step is applied only to the selected scenario.
+
+The **Preview** tab can be used to simulate a recommendations request performed by the system. One only needs to add the required parameters and click 'Send' (in the upper right corner).
+
+![Scenario preview](img/scenario_preview.png)
diff --git a/docs/personalization/use_cases.md b/docs/personalization/use_cases.md
new file mode 100644
index 00000000..9844260b
--- /dev/null
+++ b/docs/personalization/use_cases.md
@@ -0,0 +1,29 @@
+# 2. Use Cases
+
+There are many different use cases where recommendations can be used. The most common ones are located in the e-commerce and publishing industries.
+
+## E-commerce
+
+E-commerce recommendations can be very powerful to help customers find what they're looking for. If a user is not sure about what to buy, recommendations can be used to show similar, alternative or complementary products. Some typical use cases are:
+
+- On the landing page the current bestsellers ('Hot Sellers') are shown to every customer.
+- A detail page displays the products that were bought by others ('What other customers bought') or have been frequently bought together (e.g. this TV and a HDMI cable).
+- The shopping cart page shows recommendations ('Related to your shopping cart') matching the products in the cart.
+- On a category page, bestsellers of the current category are shown.
+- Additionally on the landing page and on the detail page a recommendation bar could be placed to show **personalized recommendation** (based on their latest profile information) for the current user.
+
+![Landing page](img/use_case_landing_page.png "Landing page")
+
+![Detail page](img/use_case_detail_page.png "Detail page")
+
+![Shopping basket](img/use_case_shopping_basket.png "Shopping basket")
+
+In the pictures above each recommendation box presents a scenario. Scenarios are configurations that define what kind of recommendations should be delivered. More can be read under [8. Scenarios](scenarios.md)
+
+## Publishing
+
+Recommendation and Personalization in the publishing business provide indirect value by keeping users on the website. Unlike in the e-commerce business, publishers often do not sell content, it is provided for free and cross-financed by advertisement. Increasing the CTR (click-through-rate) and adding value generated by advertisement is one of the drivers in the publishing business. Use cases for placing recommendations are straightforward:
+
+- On the landing page, the most read content is presented.
+- On every category page, the most popular content in the current category is shown.
+- On every content page, the related content is shown.
diff --git a/docs/personalization/user_data_import.md b/docs/personalization/user_data_import.md
new file mode 100644
index 00000000..8ccce55a
--- /dev/null
+++ b/docs/personalization/user_data_import.md
@@ -0,0 +1,15 @@
+# 10. User Data Import
+
+By default the recommendation engine has very little information about the user visiting the website, especially first-time visitors. The only information provided in the event tracking and recommendation request is the customer ID of the website owner and an external user ID (usually an anonymous session ID). This external user ID is again anonymized in the recommendation engine by a hashing algorithm.
+
+Sometimes it is helpful to store additional attributes for every user, for example age or home city. It is possible to retrieve the stored information based on the external user ID, but due to the hashing step mentioned above, it is not possible to get the external user ID within the user's attribute set (unless the external ID is not explicitly stored as an attribute of course).
+
+How user attributes are imported and what they can be used for is described in the [User API](https://doc.ezplatform.com/en/master/guide/personalization/user_api.md).
+
+Usage of the user attribute in the recommendation process is quite straightforward and explained in detail in the [Recommendation API](https://doc.ezplatform.com/en/master/guide/personalization/recommendation_api.md).
+
+!!! tip
+
+    An example of how user attributes can be used in the recommendation engine:[Boost-Filters](filters.md#boost-filters)
+
+    Information on the import format can be found in the developer guide:[User API](https://doc.ezplatform.com/en/master/guide/personalization/user_api.md)
diff --git a/mkdocs.yml b/mkdocs.yml
index b388a069..b9978482 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -18,6 +18,17 @@ nav:
         - 'Multi-file content management': 'site_organization/multi_file_content_management.md'
         - 'Working with Page': 'site_organization/working_with_page.md'
     - 'Searching': 'search.md'
+    - Personalization:
+        - 'Personalization': 'personalization/personalization.md'
+        - 'Use cases': 'personalization/use_cases.md'
+        - 'Dashboard': 'personalization/dashboard.md'
+        - 'Event Types': 'personalization/event_types.md'
+        - 'Content Types': 'personalization/content_types.md'
+        - 'Recommendation models': 'personalization/recommendation_models.md'
+        - 'Filters': 'personalization/filters.md'
+        - 'Scenarios': 'personalization/scenarios.md'
+        - 'Content import': 'personalization/content_import.md'
+        - 'User data import': 'personalization/user_data_import.md'
     - 'FAQ': 'faq.md'
 theme:
   name: null
@@ -58,8 +69,6 @@ extra:
       url: '/projects/userguide'
     - title: 'eZ Platform Developer Documentation'
       url: '/'
-    - title: 'eZ Personalization Documentation'
-      url: '/projects/ezpersonalization'
     - title: 'eZ Commerce'
       url: '/projects/ezcommerce'