Today, we have launched the Event Hub Analysis Widget, a diagnostic overview designed to ensure your data foundation is rock-solid. This isn't just a status bar; by providing real-time feedback on your Event Tag health, we enable to debug implementations instantly, ensuring that downstream features like A/B testing and Personalization are fueled by high-quality data.
For too long, the 'success' of a Tweakwise implementation was invisible. If an event (like itemClick or Purchase) was misconfigured, customers only found out weeks later. The new Event Tag analysis provides a transparent overview for your data stream. The global overview can be found on your dashboard, as it gives you an at-a-glance status of your entire setup. Within specific modules, starting with A/B Testing, the widget filters for relevance. It will warn you if the specific events required for that test are not being tracked correctly.
📘
Data latency
While the widget provides 'real-time' feedback, there is a minor processing window for event aggregation. A missing status immediately after a code push, might just need to wait a day of traffic to refresh.
Minor releases introduce new features and improvements. Check out what’s new!
API's
Delivery API | We’ve fixed a small inconsistency where the Delivery API would return XML instead of JSON when no instance with the provided instance key could be found or the request resulted in an error for whatever reason. Now 'format=json' and 'Accept: application/json' are both respected
Tweakwise App
Tweakwise App | Its no longer possible to delete Filter Template attributes that are still used by a Guided Selling. setup. Previously expanded our validations so we check also on attributes which are used in Guided Sellings but are not longer present on referenced Filter Templates.
Tweakwise App | When creating a new filter in the Filter Templates module, the 'hide filter if only one option is available' setting is now set to true by default. No more manual toggling for each attribute!
Tweakwise App | A critical issue in the Builder where component labels were incorrectly displayed was resolved, ensuring that merchandising configurations now properly reflect the intended labels at their designated positions. We also fixed a small bug where the Builder Click Distribution rates would not show on components.
Tweakwise App | We encountered a problem where a Builder Template could not be deleted in case it was used in an archived A/B Test. From now on, if the B/B Test is not active (archived or deleted), you can delete the template even though it is 'in use'. At that moment we will save the template name, remove the link, and delete the template.
Tweakwise App | As we will introduce a new way of Personalization soon, we already renamed the 'Personal Products' component in the Builder (if applicable in your plan) to a 'Just for you' component. The component itself is marked still as 'personal'.
Tweakwise App | We are now making sure suggestion configuration items are ordered properly even if data from the API is returned without these values.
Tweakwise App | The instance select screen after logging in would not scroll anymore.
Plugin Studio
Plugin Studio | While creating a new product tile in Plugin Studio, the initial modal would not close by clicking on the cross-button.
Plugin Studio | Added an option to configure hideActiveCategoryFilter in Starter settings page. When toggled on, the selected category will be hidden from the summary of selected filters.
Plugin Studio | The way text element values can be formatted has been changed. In order to set up precision, decimal separator or rounding the actual type of the attribute supplying a value in the Product Tile Editor needs to be Numeric. Text attributes (even though they have number-like value) would not offer these options anymore. This is to prevent e.g. certain item codes (like "16008.2500") from being automatically treated as numbers.
Tweakwise JS
Tweakwise JS | A secondary language option for internal UI language in both JS Implementation and Plugin Studio for multilingual teams has been added. All JS packages now take a new config value ui: { lang: 'code' } that takes precedence in interface localization.
In alignment with our commitment to the European Accessibility Act (EAA), we have updated our Magento extensions to be compatible with the latest WCAG 2.2 standards. By integrating the accessibility enhancements previously released for Tweakwise JS, Magento users can now provide a keyboard-navigable and screen-reader-friendly experience. This update ensures your storefront remains compliant while delivering an inclusive shopping journey for all users.
Magento2Tweakwise
Magento2Tweakwise 8.9.1 | Fixed a PHP return type mismatch to ensure compatibility with strict typing in newer PHP versions.
Magento2Tweakwise 8.9.1 | Fixed a bug in the purchase event dispatcher to prevent 400 Bad Request errors when sending data to Tweakwise. This ensures conversion data is tracked reliably.
Magento2Tweakwise 8.9.0 | Added native support for high-intent user actions tracking, so Magento is now sending in Page Impressions, Add-to-Cart, and Add-to-Wishlist events to Tweakwise. Important, as understanding the in-between actions like what users add to their carts or wish lists, provides a much richer picture of customer intent.
Magento2Tweakwise 8.9.0 | Improved WCAG compatibility for better compliance.
Magento2Tweakwise 8.9.0 | Fixed an issue where multiple recommendations failed to load and resolved some errors occurring when no recommendations were returned. We fixed a bug where incorrect product data was sent during events.
Magento2TweakwiseHyva
Magento2TweakwiseHyva 4.5.1 | Resolved an issue where multiple item click events were being triggered simultaneously when selecting product attributes like color or size.
Magento2TweakwiseHyva 4.5.0 | Added full support for session_start, add_to_cart, and add_to_wishlist events to align with the latest core module tracking.
Magento2TweakwiseHyva 4.5.0 | Improved WCAG compatibility for better frontend compliance and screen reader support.
❗️
Important note
If you are using the Hyva theme, you must update both the Magento2Tweakwise and Magento2TweakwiseHyva modules to their latest versions.
Minor releases introduce new features and improvements for our Shopware plugin. Check out what’s new! But from this version, Shopware will add the event tags even in listings and search even if your are not (yet) using Tweakwise. So you can already collect data before you use the merchandise and search features. We also added the events add-to-cart and add-to-wishlist on the product detail pages, so those will be tracked as well.
SW-Tweakwise 5.5.1 | Make sure the categories of a product are always synced with backend-sync even when no categories are selected anymore. And in some cases the groupcode whas defined incorrect with variant products, this is now resolved resulting in the right code.
SW-Tweakwise 5.5.0 | If you add a quantity field on a product tile in the Plugin Studio, this field will now be used to determine the quantity that needs to be added to the Shopware cart.
SW-Tweakwise 5.4.2 | Removed argument in service definition.
SW-Tweakwise 5.4.1 | Removed some unused code to make the plugin perform better with large navigation trees.
SW-Tweakwise 5.4.0 | We added the add-to-cart and add-to-wishlist event tags on the product detail page as well. This way we also track these actions on the product detail and not only on the listing pages.
SW-Tweakwise 5.4.0 | Events will now be collected even if you have not enabled the frontend implementation. This will give you the option to collect data before implementing the search and merchandise options.
SW-Tweakwise 5.4.0 | We changed the way the profileKey is defined for the event tag. Now the profileKey is not cached anymore when using full page caching.
SW-Tweakwise 5.4.0 | Only show the Tweakwise tab on the product editing screen in Shopwares storefront admin when the Backend sync is enabled for at least one instance.
SW-Tweakwise 5.4.0 | Added the language parameter in several places to make sure you get the best values for the language of the current domain. Now the languageKey assignment is also updated to handle null case.
SW-Tweakwise 5.4.0 | Refactored the feed generation a bit to get rid of deprecation notices when using grouped products. Also flattened iterable values in CustomFieldValueExtension to make these values are also added to the feed.
SW-Tweakwise 5.4.0 | Added missing argument in services definition preventing messages about too few arguments.
SW-Tweakwise 4.9.0 | Removed some unused code to make the plugin perform better with large navigation trees.
SW-Tweakwise 4.9.0 | If you add a quantity field on a product tile in the Plugin Studio, this field will now be used to determine the quantity that needs to be added to the Shopware cart.
SW-Tweakwise 4.8.0 | We added the add-to-cart and add-to-wishlist event tags on the product detail page as well. This way we also track these actions on the product detail and not only on the listing pages. Events will now be collected even if you have not enabled the frontend implementation. This will give you the option to collect data before implementing the search and merchandise options.
SW-Tweakwise 4.8.0 | Added the language parameter in several places to make sure you get the best values for the language of the current domain.
SW-Tweakwise 4.8.0 | Flattened iterable values in CustomFieldValueExtension to make these values are also added to the feed. And we changed the way the profileKey is defined for the event tag. Now the profileKey is not cached anymore when using full page caching.
📘
Duplicate notes?
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!
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.
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.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_langis 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.
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.
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.
Shared categories: For categories shared between different parent categories, the default language is derived from the path taken to reach the category.
Path A (via Netherlands): Shared category resolves to Dutch.
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.
