Minor releases introduce new features and improvements. Check out what’s new!

Tweakwise App

• Tweakwise App | Fixed a problem in the list view of Tweakwise App > Catalog > Items where the item image would not be consistent in size. Meanwhile we removed the brand column and added a filter on status possibility.
• Tweakwise App | In the Filter Templates module, the min/max depth settings are now always visible for Category facets, regardless of the type (tree/link) which is configured. Also a bug was fixed where disabling the AI Smart Filter percentage usage the context menu wouldn't work. We fixed validation for Bucket Slider/Clickpoints facet type too.
• Tweakwise App | Added the ID of the template to the detail page of Builder templates. The ID was also added to the detail page of Suggestion templates, and was removed from the list overview.
• Tweakwise App | Fixed a small issue where making changes to SQL Replace Derived Attribute configurations could lead to an error.
• Tweakwise App | We have fixed a bug where duplicating tiles in the Builder failed and made the whole template not able to save.
• Tweakwise App | In the renewed Filter Templates module it is now again possible to change the position of a facet via an input field (via context menu). Also the index page (list of templates) now loads faster, as extra data (number of attributes & usage) is fetched after the list is loaded. This fix also prevents incorrect usage data to be displayed.
• Tweakwise App | Removed unnecessary validation message when editing a Suggestion configuration.
• Tweakwise App | A small bugfix was done. The amount of filters and the links would not show properly when there was only one filter template available in your Tweakwise configuration. Meanwhile wreduced the number of requests fired each time a Filter Templates module is opened by moving some logic to the backend.
• Tweakwise App | There were some translations in the App that didn't work properly when it contained a dynamic numeric value. For example "1 times" when it should be "1 time". This issue is now fixed. We renamed the 'Usages'-widget to 'Links' and changed the layout of the modal for a better overview across several modules.
• Tweakwise App | Statistics failed to load in the Builder. Issue caused by some refactoring. It is now fixed.
• Tweakwise App | Fixed an issue where Filter Templates could not be deleted if their associated Category had already been removed.
• Tweakwise App | When setting an attribute as a characteristic, it will show an informational alert explaining the consequences of setting the characteristic. For example the 'Image' characteristic replaces the item image, but the 'Brand' characteristic is just used for the brand component in the Builder and doesn't replace the item brand.
• Tweakwise App | We've simplified the layout of the tiles on the builder and changed the titles for some of the components so that it is clearer what each tile does.

Demoshop

• Demoshop | Fixed a bug where sorting results prevented you from applying a different sorting rule afterwards.
• Demoshop | The AI personalization message was, in case of an error, not showing the right feedback. When a key was not found it looked like an error has occured. This is fixed so the right error is shown again.

Tweakwise JS

• Search & Merchandising JS | According to our documentation, the Category IDs should be configured as a string to prevent any unexpected behavior, but inputting them as numbers also worked, however, apart from one situation when your CID is 0 (zero) and this edge case was fixed.
• Search & Merchandising JS | A specific component (Bucket Slider) was exporting third party styles that polluted the global space, meaning if customers had their own implementation of 'noUI slider', these exposed styles would affect their components as well. This should no longer be happening.
• Search & Merchandising JS | We have added a new configuration option 'filters.hideActiveCategoryFilter' to the Search & Merchandising JS package. It will hide selected category filter from the selected filters overview. Also, when all selected filters are cleared, it will make sure the user is not moved to a parent category, but instead stays in the current one.

Event Tag

• Event Tag | We have covered an edge case where, depending on the implementation of the Event Tag, profileKeys consisting of only numbers could be parsed as a number and therefore fail the request to Analytics API. Profile keys are now always sent as strings through the Event Tag.

We have significantly expanded the capabilities of the Tweakwise Event Tag. While tracking conversions and product-page views is essential, understanding the in-between actions like what users add to their carts or wish lists, provides a much richer picture of customer intent. We have updated the Event Tag to capture a broader range of behavioral signals. Understanding how users interact with your products before they reach the checkout is essential for fine-tuning your ranking algorithms.

This update introduces structured support for Page Impressions, Add-to-Cart, and Add-to-Wishlist events, with built-in automation for many of our standard integrations.

New Event Types

Each of these events provides a specific layer of intent data that helps Tweakwise understand which products are trending and which are effectively converting interest into action.

• Page Impressions: This event should be triggered whenever a product is displayed to a user within a lister page, search result page, recommendation carousels, or guided selling flows. Measures findability and calculates accurate Click-Through Rates (CTR).
• Add-to-carts: Triggered the moment a customer adds an item to their shopping basket. This is the strongest indicator of purchase intent. Directly influences ranking by identifying high-conversion products.
• Add-to-wish lists: Triggered when a user saves a product to their favorites or wish list. FeatureFeaturCaptures long-term interest and helps identify "aspirational" products that may benefit from specific merchandising rules.

📘

Implementation Details

The expanded Event Tag is designed to be lightweight and easy to trigger via your frontend framework or Tag Manager. Each event type follows a consistent structure to ensure clean data processing. You can find the full technical specifications, including the required attributes for each new event type, in our updated tracking guide.

We are excited to announce a significant upgrade to our Suggestions module. While Tweakwise has always excelled at providing product recommendations in the search dropdown, we recognize that your customers are looking for more than just products: they are looking for content. With this update we have expanded the 'Item suggestions' configuration to allow for multiple, dynamic item types. This means you can now seamlessly integrate blogs, pages, and FAQs into your search suggestions, right alongside your products.

Previously, the 'Items' section was mainly reserved for products. We have now mirrored the flexibility of our Suggestions Groups (Categories, Facets, and Search Phrases) within the Item Suggestions section.

• Unlimited item types: You are no longer limited to just products. You can now add an unlimited number of item types, such as blogs, pages, FAQs and even visuals. By categorizing results you provide users with a clearer path to the information or items they need, significantly improving the user experience and Click Through Rates.
• Customizable ordering: You have full control over the display order. Use the drag-and-drop interface in the Tweakwise App to determine exactly where each item type appears in the response.
• Rich Content integration: Provide a more holistic search experience by surfacing relevant blog posts or guides (e.g., "5 tips for a better catch") directly in the search suggestions.

Backwards Compatibility

To support these changes while maintaining stability for existing implementations, we have introduced a new structure to our API response. We understand the importance of continuity. The existing items object in the API response remains intact to ensure your current implementation doesn't break. However, when multiple groups are configured, the API will now provide a distinct breakdown per item_type.

📘

New API Endpoint

For those looking to leverage the full power of this update, a new API-endpoint needs to be implemented. This update is already reflected in both our Standard JS Implementation and the Demoshop.

Minor releases introduce new features and improvements for our Shopware plugin. Check out what’s new!

• SW-Tweakwise 5.3.0 | Product synchronizations via Backend
• SW-Tweakwise 5.2.0 | Rules will now be checked while defining the categories for the feed.
• SW-Tweakwise 5.2.0 | The profileKey will not be stored in the session anymore when visiting the finalize-transaction route. This is done to prevent issues when returning from some payment providers like Buckaroo.
• SW-Tweakwise 4.7.1 | Some small fixes for bugs that prevented backend sync in Shopware 6.5. The Tweakwise tab on the product editing window is now only visible when there is at least one instance enabled for backend sync.
• SW-Tweakwise 4.7.0 | Product synchronizations via Backend
• SW-Tweakwise 4.6.3 | Use the LanguageLocaleCodeProvider to determine the language code for the feed on other places as well.
• SW-Tweakwise 4.6.2 | Use the LanguageLocaleCodeProvider to determine the language code for the feed. This also might fix issues with inherited languages.
• SW-Tweakwise 4.6.2 | A small bugfix was done to to prevent errors in the frontend when showing sibling categories in the category filter without having a path.
• SW-Tweakwise 4.6.1 | Fixed wrong name of finalize-transaction rout.
• SW-Tweakwise 4.6.0 | The profileKey will not be stored in the session anymore when visiting the finalize-transaction route. This is done to prevent issues when returning from some payment providers like Buckaroo.

📘

Reminder

The 4.x version of the plugin is compatible with Shopware v6.5 and v6.6. The 5.x version of the plugin is compatible with Shopware 6.7. Click this link to visit corresponding repository and update on Github.

We have introduced the ability to assign specific languages to specific categories in your Tweakwise Catalog. This allows for more granular control over which languages are indexed per category, significantly improving publish performance for large, multi-language catalogs. When a request is made to the Delivery API without a specific tn_lang, the API now checks the category tree.

Previously, instances were published and available in all languages configured for that instance. This meant that even if a category was only relevant for a specific region (e.g., 'The Netherlands'), it was indexed for all enabled languages (Dutch, English, French, etc.), resulting in unnecessary data processing and longer publish times. With this update you can restrict a category to a specific language. This has two main benefits:

• Performance: Only the relevant language is indexed for Full Text Search (FTS), reducing publish duration.
• Frontend logic: The Delivery API automatically determines the correct default language based on the category, reducing the need for complex frontend logic. Especially for a multilingual Filter Templates setup, the use of tn_lang is not longer required in order to have the right language presented in our Delivery API.

How it works

This feature is currently available for Tweakwise instances with the Languages Management feature enabled. The logic follows a specific hierarchy to determine the default language. We first look at the requested category and its language setting. If a language is assigned, that language is used. If the category has no language configured, we check the parent categories (inheritance) up to the Root. If the Root category has no language restriction, the instance defaults to the standard behavior (publishing in all configured languages).

📘

Utilizing the tn_lang parameter

The tn_lang parameter in the API is still leading. If a valid tn_lang is provided in the request, it will override the category configuration as setup via Tweakwise App. However, the tn_lang parameter should be recognized by Tweakwise and therefore needs to be configured in Languages Management.

Scenarios and logic

To help you understand how the default language is determined for any given request, we have outlined the most common configuration patterns below. The logic follows a strict hierarchy: specific category settings take precedence, followed by parent category settings, and finally the global instance configuration.

1. Root category without restriction: If the Root category is left unset, the root is published in all languages configured for the instance. This maintains backwards compatibility.

2. Root category with restriction: If the Root is set to a specific language (e.g., Dutch), the entire tree inherits this language. If a sub-category (e.g., 'DE Storefront') has a different language set (e.g., German), that sub-category and its children will switch to German.

3. Shared categories: For categories shared between different parent categories, the default language is derived from the path taken to reach the category.

   1. Path A (via Netherlands): Shared category resolves to Dutch.
   2. Path B (via Belgium - FR): Shared category resolves to French.

By scoping languages to specific categories, you can significantly reduce publish times and simplify your frontend logic. We encourage you to test this configuration in a staging environment to experience the performance benefits firsthand.

Minor releases introduce new features and improvements for our Magento plugins. Check out what’s new!

Magento2Tweakwise

• Magento2Tweakwise 8.8.0 | Added support for multi-language filter templates. You can now configure a language per store view, resulting in this parameter being sent to Tweakwise APIs in all requests. This functionality enables the use of multilingual Filter Templates.
• Magento2Tweakwise 8.8.0 | Fixed an issue where item clicks were not being sent and fixed a type mismatch bug where a string was expected but another type was provided. We also fixed an infinite loop in case recommendations returned no items.
• Magento2Tweakwise 8.8.0 | Resolved multiple issues with filter value translations when store views had different spellings for the same value. Filter slugs are now stored per store view and slugs can be regenerated (only if needed) by running bin/magento tweakwise:regenerate:filter-url-slugs.

Magento2TweakwiseHyva

• Magento2TweakwiseHyva 4.4.2 | Fixed an issue where item clicks were not being sent. We also solved an issue where the url of an landingpage was not correct. Added support for diacritics in the in-filter search.

Magento2TweakwiseExport

• Magento2TweakwiseExport 7.8.0 | We added a store filter to the export in process in certain places to increase speed. The actual performance win will vary per customer, although customers with a different set of products for different store views are expected to see the greatest speed gains. Meanwhile we added a hook for category export so customers can insert custom logic.

We are pleased to announce the release of a significant new capability within the Tweakwise Shopware plugin, designed to streamline your content management workflow and ensure real-time accuracy for your shoppers. In SW-Tweakwise 4.7.0 and SW-Tweakwise 5.3.0 we introduce an experimental feature that enables you to manually synchronize a specific product's information directly from the Shopware storefront backend to your Tweakwise Catalog, making use of our Backend API.

This feature is designed to eliminate lag and potential inconsistencies that can occur between scheduled full catalog synchronizations. The functionality is managed via a dedicated setting within the Tweakwise configuration section of your Shopware admin panel. Once enabled, a new action will appear on the product editing screen within the Shopware backend. Clicking this action initiates a process that immediately pushes the latest product data (including name, price, attributes, inventory, etc.) for that specific item to the Tweakwise index.

🚧

Release for 4.7.0 & 5.3.0

This feature is currently labeled as experimental. While fully functional, we are actively seeking feedback on its performance and utility in various Shopware environments. We recommend thorough testing in a staging environment before relying on it for high-volume, critical updates.

📘

Reminder

The 4.x version of the plugin is compatible with Shopware v6.5 and v6.6. The 5.x version of the plugin is compatible with Shopware 6.7. Click this link to visit corresponding repository and update on Github.

Minor releases introduce new features and improvements. Check out what’s new!

API's

• Backend API | Small bugfix in two Backend API endpoints, which now are only available via authentication.
• Analytics API | We’ve made it possible to supply the instanceKey to the Analytics API via a query parameter instead of via a header. This was done to make it possible to use so called beacon requests. This will allow our Event Tag to track events more reliably in the background. With this change we’ve made using the instance key header obsolete. Using a query parameter is now the preferred way. This has also been reflected in the API specification.

Tweakwise App

• Tweakwise App | We've improved the Derived Attributes Preview and Value distribution tabs. When the values are being calculated, a message is displayed to reflect this. When the calculation is done, values will automatically be displayed. There will also be no longer a timeout error for larger complex attributes.
• Tweakwise App | Fixed a bug where established and manual suggestions would not load in the detail page if the selected category had ID 0 (zero).
• Tweakwise App | We renamed the use of the name Autocomplete to Suggestions throughout Tweakwise App.
• Tweakwise App | When searching for a specific category in Tweakwise App, it now is possible to search on both the ID as Key too in category selectboxes (for example in those in Search Algorithms, Suggestions and Demoshop). Previously only searching by Category Name was possible.
• Tweakwise App | Google Analytics (UA) has stopped working and is replaced by Google Analytics 4 (GA4) for quite some time now. There were however still some instances that had recurring tasks for importing old reports based on UA; now we have set these tasks to inactive as results were no longer beneficial to your Tweakwise setup.
• Tweakwise App | The Tweakwise App's menu now correctly expands on page reload if a visitor is currently in a module within any group.
• Tweakwise App | A small bug was fixed in the new Filter Template module, in which validation on the facet type IsMultipleChoice resulted in an error. We fixed that so that all existing templates from the old module should save correctly again in the new module as well.
• Tweakwise App | You can now quickly update settings for a filter with the context menu (three dots). It supports setting the visibility, the collapsibility and the relevancy percentage for AI Smart Filters. When you select an option, it will be immediately applied for that filter. Also the lister page is extended with two columns: Usage and the amount of facets attached.
• Tweakwise App | We have updated the interlinking of the Attribute Used tab page to navigate to the new Filter Template module if that one is enabled for your instance.
• Tweakwise App | We added a clearer error messaging for failed connections to Google Analytics servers in order to assist with troubleshooting.

Demoshop

• Demoshop | We added an optional login to the Demoshop (same credentials as your Tweakwise account), which enables us to show more relevant data and in the Demoshop (as this information is not present in the Delivery API). First usecase of this is showing the SKU on the product tile and details about running A/B Tests.

Tweakwise JS

• Tweakwise JS | We improved the way personalized requests are sent to the server. Sometimes due to a raise condition the profile key was not part of the request. This should now be fixed. We also added the requestId to the navigation-success event.
• Search & Merchandising JS | We added a new option called selection that allows to pre-select filters for search. This setting was already available for category pages but was missing for search.
• Search & Merchandising JS | Search & Merchandising JS now automatically trigger the Event Tag events where possible: search, page impression, item click, add to cart, add to wishlist. Events not mentioned here (for example the purchase or productView) still need to be implemented manually.
• Search & Merchandising JS | We've fixed a bug where the search term would not update properly in some cases.
• Recommendations JS | We fixed an issue in the recommendations where the carousel would 'jump' while scrolling through the results. This issue should be fixed now.
• Suggestions JS | Recommendations JS | Guided Selling JS | Automatically trigger the Event Tag events where possible: item click, add to cart, add to wishlist. Events not mentioned here need to be implemented manually. The JS does not automatically include the Event Tag on it own. It still needs to be added to the platform manually for this to work.

Plugin Studio

• Plugin Studio | Added a new configuration option to the Plugin Studio's JS Suggestions configuration page to show the number of results for the given search suggestion. This number is shown on the results button, which of course needs to be enabled in order to see the number of results as well.
• Plugin Studio | We have added Event Tag configuration to the Plugin Studio so that you can setup which events should be fired automatically. Currently it is possible to configure whether, and what, events are fired automatically from each JS module (search, page impression, click, add to cart, add to wishlist), essentially changing the package's configuration. Manual implementation of the tag itself is still required.

Every visitor on a platform leaves behind substantial data like search queries, views, clicks, and purchases. Tweakwise helps by connecting these separate data points, revealing patterns, and guiding users toward better choices through comprehensive Insights reports. These reports already allow you to discover what is truly happening on your platform and how visitors search, filter, and convert. We are excited to announce two major expansions: the Conversion Report has been updated with session-differentiation, and we're introducing Data Exports.

Measuring the true impact of search

The Conversion Report has been upgraded to provide a sharper view of how onsite search contributes to your platform’s performance. The biggest addition is the ability to now clearly distinguish between conversions with and without the use of search. This separation provides immediate insight, allowing you to see at a glance how substantial the impact of search is on your total conversion. It gives clear insight into how visitors behave differently when they interact with your search engine compared to browse-only visitors.

📘

Event Tag

Implementing the Tweakwise Event Tag is essential to analyze the performance of your configuration, power our insights reports and support personalization. To support this, Tweakwise needs key e-commerce events on your platform. These are events such as product views, item clicks, add-to-carts, and purchases.

Export Data from Insights Module

To further enhance data usability and support external analysis, we are introducing Export Data functionality across the Insights Module. From now on, it is possible to export the underlying data from any chart within the Insights module. This function is available for all reports, including the E-commerce Report, Conversion Report, Task Statistics Report, Search Word Analysis Report, Usage Report, and Filtering Usage Report.

Accessing this data is simple: navigate to any report in the Insights Module, hover over the chart you wish to export, click on the three dots that appear, and select Export Data. You have the flexibility to choose between .xlsx (Excel) and .csv formats for your exported data.

We are happy to announce our renewed Filter Templates module in the Tweakwise App, redesigned to make managing your product filters faster, easier, and completely intuitive. As an e-commerce manager or digital marketeer, you need to manage your filters quickly, clearly, and without friction. Dealing with filters hidden in code, inconsistent translations, too many clicks, or constantly waiting for a developer costs time and flexibility. This updated module solves those issues by offering a fresh, intuitive interface with a multilingualism setup as a key benefit.

The redesign ensures that you manage your filters completely independently, without relying on developers. It has been revamped from the ground up to give you more control with fewer clicks and greater clarity. Everything now feels faster, clearer, and more logical. With the new interface, you manage filters faster and easier. You define the structure, sequence, types, and even translations yourself, all within one intuitive interface.

• Faster configuration: The redesigned interface means fewer clicks, more efficiency and clarity. You can configure filters in seconds.
• Full Filter control: You gain full filter control, managing filter structure, order, and languages without relying on developers.
• Flexible setup: You can effortlessly add new filter options and adjust their order. Filters can be reordered simply by dragging and dropping them into the position that best fits your category pages.
• Integrated Language Management: The new language management is fully integrated, allowing you to easily manage translations directly within the module. This keeps all filter labels consistent and centralized across every language and region. And don't be bothered to do all your translations yourself; with the help of AI translating was never be that simple.

This renewed Filter Template module gives you more control and boosts your speed. You can keep tweaking until your filtering perfectly matches what your visitors need. The result is a smoother experience, higher relevance, and stronger conversion, all without hassle. And even better, it works smoothly with our A/B Testing module too. Not sure whether your changes are right? Test them first in a make decisions based on clear, factual data instead of assumptions.

Languages management

To ensure you can fully utilize multilingual capabilities of the renewed Filter Templates module, it is essential that your instance recognizes languages as such. Language Management is a new, central feature within Tweakwise App designed to manage your languages. It allows you to easily define which languages are active, set a default language, and ensure your entire platform remains consistent across all languages and regions.

This new structure is what enables the fully integrated translation workflow now visible in the Filter Templates module. By managing languages from one place, it allows you to translate directly where you work: editing texts instantly within the filter configuration screen. This interaction ensures that all your filter labels are kept consistent and centralized, avoiding duplicate entries and mistakes. Tweakwise is continuing to integrate this structure into other modules like categories and products, ensuring you maintain clean oversight and control over multilingual content throughout the entire app.

📘

Utilizing the tn_lang parameter

To ensure filter templates appear in the correct language, the tn_lang parameter should be present in Frontend API requests. The code provided must be configured within the language settings in Tweakwise App. This configured language is mapped to a Full Text Language, which is crucial to apply complex linguistic processing to search terms, including plurals, verb conjugations, and splits. Utilizing the tn_lang parameter guarantees the correct display of filter translations and enhances search relevance and accuracy.