• MagentoTweakwise 5.8.2 | Resolved an issue where the incorrect parent category was utilized while navigating a category tree that is three levels deep.
• MagentoTweakwise 5.8.2 | Resolved an issue where the filter parameter remained in the URL after deactivating the filter.
• MagentoTweakwise 5.8.2 | Resolved an issue where in case of the URL pathslug strategy enabled, selecting a filter on a category page would lead to an incorrect URL upon refreshing the page and selecting another filter.
• MagentoTweakwise 5.8.2 | Bugfix implemented to address the duplication of category names in the default Magento renderer.
• MagentoTweakwise 5.8.2 | Implemented query length limitation for search to prevent a 500 error. We also have implemented measures to prevent 500 errors in the search when Tweakwise is inaccessible or down.
• MagentoTweakwise 5.8.2 | Implemented a preventive measure to avoid errors when no attribute values are present for ALP facet requests.
• MagentoTweakwise 5.8.2 | Resolved the issue with Merchandising Builder and pagination not functioning correctly when utilizing the filter form.
• MagentoTweakwiseExport 6.0.1 | Resolved an issue where not all stores were exported when no feed was available and needed to be generated.
• MagentoTweakwiseExport 6.0.1 | Resolved an issue where in case of the URL pathslug strategy enabled, selecting a filter on a category page would lead to an incorrect URL upon refreshing the page and selecting another filter.
• MagentoTweakwiseHyva 2.3.8 | In Hyva themes, featured products where not working on the category page as the products shown were not fetched from Tweakwise. The product slider didn't have code to show featured or new products at all.
• MagentoAttributeLanding 4.1.3 | Updated code comments to prevent an error in the Magento Swagger API.
• MagentoAttributeLanding 4.1.3 | Resolved an issue with ALP URL when utilizing the store code in the URL and having 'allow link in facet search' enabled on an ALP.
• MagentoAttributeLanding 4.1.3 | Resolved an issue with missing ALP resources in the ACL.

Really minor but important for understanding, we have added the Redirects-algorithm on top of the 'Search algorithm' in Tweakwise App > Search > Search algorithms, as every search request always starts with checking on available redirects. We've decided to show it prominently on top, as there was some confusion and misunderstanding on how this settings could affect your search behavior. Redirects is a locked algorithm and therefore can not be switched to another position.

Next to that, we made the overall page of the Search algorithms simpler. We have added buttons to each algorithm linking them to their respective support articles, and we moved the 'Add algorithm' button to below the table to comply with new algorithms being added to the bottom of your funnel too.

Other improvements

• Tweakwise App | In a hypothetical situation where your Tweakwise instance is still being created while accessing Tweakwise App, we now do show a neat error message that the instance is not ready for use yet (instead of throwing an unknown server 500 error).
• Frontend API | There is a field showselectedfirst that was already available in the XML-response of our navigation endpoint, but was missing from the JSON version of that same response. This field can be used as an indicator which determines whether selected filters should be shown on top of a facet.
• Tweakwise App | Tweakwise App now is completely available in German language. You can access Tweakwise in German by using the language switch button by clicking on your avatar in the top right of the screen first.
• Tweakwise App | We've rebranded the Tweakwise Account login pages as we did with the Tweakwise Instance Select screen. We changed the display font throughout the app to have it more in line with our marketing.
• Tweakwise App | We also simplified the Merchandising templates detail and creation page. The labels with rules and templates are now separated and at the bottom of the page instead of showed on top.
• Tweakwise App | We fixed in-app tooltips that were annoyingly disappearing when you hovered on them. Also fixed a bug on redirecting when initializing a new JS Instance from within Tweakwise App.
• Backend API | We've added status to the BackendApi get instance call. If an instance is not yet ready for use, it will have the status New. Other possible states are Active and Inactive.
• Suggestions JS | A bug was fixed in our Suggestions JS solution, where when looking for redirects for a specific search term, the current category was not taken into consideration. This is now fixed.

The Category Match search algorithm is real powerful algorithm that checks whether your entire search query exactly matches the name of a single category. If so, your query will only search through categories and products that are within or directly underneath the current category.

We have now implemented the possibility to exclude categories from the Category Match algorithm's behavior. That is, if there is a match during the category search and the found category is in the exclusion list, then the matching result will be ignored and the search algorithm will continue with the next step.

Example: In case you sell LEGO-products and there is a found Category Match on the category Junior > Cars (based on search term 'cars'). It will then only show products from that specific category, although there might be other cars available in the rest of the assortment as well. These products will not be shown, unless you configure the category Junior> Cars to be excluded from the Category Match algorithm.

Read this support article for a complete understanding of the Category Match algorithm.

Other improvements

• Tweakwise App | In Search algorithms we fixed the behavior of 'Use Merchandising Template of the matching category' option. If the checkbox is enabled, then the filter template, merchandising rule and merchandising builder configured for this category will be applied to the found category.
• Tweakwise App | In Catalog > Properties (of any kind) there is now a possibility to download an export of all values available for that specific property. It is available under the 'Download' button at the bottom of the detail screen.
• Tweakwise App | Pagination is added to the detail pages of Derived attributes of the type 'replace' as we did experience some performance issues on the override page of a derived attribute if the attribute contains too many overrides. Now opening the page and saving changes is much faster, as is the the transition between pages.
• Tweakwise App | We have introduced a new feature that allows users to download the full error message of a failed job, which can be helpful when dealing with feeds containing many incorrectly configured products and/or categories. The full error message can be downloaded by clicking on the link provided below the truncated error message. Good to note that the same file is re-used on every new run of the same job.
• Frontend API | An optimization for searching with strange words was done under the hood. We encountered some issues with requests timing out because the search query became too complex. Meaning a search term with mix of a lot of normal words consisting of only alphanumeric characters and so called strange words consisting of special characters and/or numeric characters. Execution times were unpredictable and could differ per server. Now searches with a lot of strange words are more predictable and stable in terms of execution time.

We have added new events that are being fired at different points of using the JS Implementation and JS Suggestions. These can be used to hook into for implementing custom functionality and business logic.

JS Implementation

• The twn.product.visible event is fired when a product tile is visible on the screen (technically it goes for the middle pixel on the entire tile, so you must scroll at least 50% for this event to be fired).
• The twn.product.click event is fired when a link is clicked on the product tile (right click or middle click; any anchor tag including the one on the product image).

These events are useful for additional tracking the impressions of for example products fetched from an external source.

Suggestions JS

• twn.request.started - Request to fetch suggestions has started
• twn.request.products.started - Request to fetch product suggestions has started
• twn.request.success - Request to fetch suggestions has succeeded
• twn.request.products.success - Request to fetch product suggestions has succeeded
• twn.request.failed - Request to fetch suggestions has failed
• twn.request.products.failed - Request to fetch product suggestions has failed
• twn.request.completed - Request to fetch suggestion has been completed
• twn.request.products.completed - Request to fetch product suggestions has been completed

Series of events following the lifecycle of requests to fetch the suggestion data.

Read our complete Tweakwise JS documentation for more information on how to implement this.

Redirects can be triggered when a user enters a specific search term on your website. With Tweakwise’s autocomplete feature, your users get suggestions for search phrases while they’re typing. Sometimes there is a suggested search phrase that would result in a redirect. However, previously you would first have to do a navigation search or products request to know if there was a redirect for the chosen search phrase.

With the addition of adding redirects directly in the response for search phrase suggestions, we’ve removed the need for a separate call. This means your users can get redirected immediately instead of having to wait for an extra request, speeding up the user experience.

<!--This is an example of a XML response for a suggestions call-->
<suggestionGroups xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <group>
    <name>Suggestions</name>
    <type>SearchPhrase</type>
    <suggestions>
      <suggestion>
        <match>Apple</match>
        <navigationLink>
          <path><![CDATA[/navigation-search/e4894213?tn_q=Apple]]></path>
          <context>
            <searchterm>Apple</searchterm>
          </context>
        </navigationLink>
        <redirects> <!--The new redirects node-->
          <redirect>
            <url>https://tweakwise.com</url>
          </redirect>
        </redirects>
      </suggestion>
    </suggestions>
  </group>
</suggestionGroups>

// This is an example of a JSON response for a suggestions call
[
    {
        "name": "Suggestions",
        "type": "SearchPhrase",
        "suggestions": [
            {
                "match": "Apple",
                "navigationLink": {
                    "path": "/navigation-search/tweakwise?tn_q=Apple",
                    "context": {
                        "searchterm": "Apple"
                    }
                },
                "redirects": [ // The new redirects object
                    {
                        "url": "https://tweakwise.com"
                    }
                ]
            }
        ]
    }
]

The following endpoints have been affected by the change:

• Suggestions including the grouped variant

Today we have a big update to announce regarding the behavior of the Category tree settings and its interpretation by our Magento plugins. The category view in Magento differs from the way it is presented in Tweakwise Demoshop which we consider to be desired and common behavior. This difference is related to the way how (sub)category levels in fact are shown.

We've added a setting to Magento2Tweakwise plugin in which you can define whether to use the old/existing way of presenting, or whether you want to use the desired way of presenting the category tree. The setting can be found under Stores > Catalog > Tweakwise > Layered Navigation >Category View in your Magento backend and is set to simple by default. This represents the current way of presenting and nothing will change if you do not touch this setting. If the setting is changed to extended, the category view is changed to the same view as the Tweakwise Demoshop.

The correct way of interpreting the category tree settings, is by showing multiple levels of categories always. This tree structure can be directly visible (recommended) or being collapsible depending on your front-end implementation. This differs from the link structure, where only the relevant category will be shown including the single parent category it belongs to.

Other improvements

• Magento2Tweakwise v5.7.5 | Resolved a security vulnerability linked to product sorting.
• Magento2Tweakwise v5.7.5 | Fixed an issue causing JavaScript errors with the Hyva theme and Ajax navigation.
• Magento2Tweakwise v5.7.5 | Enhanced SEO by removing 'p1' from URLs; this issue specifically affected the query parameter strategy for URLs.
• Magento2Tweakwise v5.7.5 | Rectified a bug causing an undefined index in active filters while using the ALP module.
• Magento2Tweakwise v5.7.5 | Addressed a problem where 404 errors were logged in Magento when a product, no longer available in Tweakwise (e.g., out of stock), still had recommendations called. This change prevents such 404 errors from being logged.
• Magento2Tweakwise v5.7.5 | Fixed an issue causing double filter values in URLs. This occurred when activating a filter while Merchandising Builder was active, resulting in incorrect filter URLs with doubled values.
• Magento2Tweakwise v5.7.5 | Improved handling of double values in URL filters. Now, only consecutive double values, such as '/tables/tables/shape/oval', are removed.
• Magento2Tweakwise v5.7.5 | Removed redundant double slashes in category URLs.
• Magento2Tweakwise v5.7.5 | Prevented category ID from being added to the URL during certain category searches, ensuring URL consistency.
• Magento2Tweakwise v5.7.5 | Cleaned up unused imports.
• Magento2TweakwiseExport v6.0.0 (breaking change) | Modified the response returned when accessing the feed via URL to prevent header already sent errors with some external modules. This change might affect any customer-added code executed after reading the feed, though it's unlikely that any customers have such code.
• Magento2TweakwiseExport v6.0.0 (breaking change) | Fixed a bug where a disabled stock source was still exported to Tweakwise in the product's stock count. Now, disabled stock locations won't export stock to Tweakwise, and products with no enabled stock locations won't be exported.
• Magento Tweakwise Hyva v2.3.7 | Fixed a bug where, with Merchandising Builder enabled, refreshing a page with a page number in the URL (?p=2) reverted to the first page. The fix ensures the URL stays on the same page.
• Magento Tweakwise Hyva v2.3.7 | Added styling support for the ALP overview page within the Hyva theme. Related user story 166879

The builder and pinning have an effect on the way products get sorted. It's already possible to view how the builder and pinning influenced the sorting in the demoshop. However, we also wanted to make this information publicly available as part of the frontend API.

For that reason we've added new information to all products, in both the JSON and XML response, we call origin. The origin field gets added whenever the builder or pinning was responsible for the position of that product in the sorting.

<!--This is an example of a XML response for a product-->
<item>
  <itemno>10001-101</itemno>
  <title>Tweakwise Hoodie Blue</title>
  <price>24.95</price>
  <brand>Tweakwise</brand>
  <url>https://sttwdocseuwe.blob.core.windows.net/shop/products/hoodie-blauw.jpg</url>
  <origin> <!--The new origin node-->
    <type>visual-merchandising</type>
    <name>Pinned</name>
  </origin>
</item>

// This is an example of a JSON response for a product
{
    "itemno": "10001-101",
    "title": "Tweakwise Hoodie Blue",
    "price": 24.95,
    "brand": "Tweakwise",
    "url": "https://sttwdocseuwe.blob.core.windows.net/shop/products/hoodie-blauw.jpg",
    "origin": { // The new origin object
        "type": "visual-merchandising",
        "name": "Pinned"
    }
}

Read more 👉

• Frontend API | The tn_q parameter is now limited to the same 100 characters on every occasion. This parameter is used in Navigation Search, Facets, Products, Autocomplete and Suggestions endpoints.
• Tweakwise App | When trying to delete a featured product recommendation that is being used in a builder, it now will show the specific builders name upon preventing the deletion.
• Tweakwise App | In Merchandising > Templates and Merchandising > Builder, the connected tab will show full clickable pathnames to make it easier for finding (and browsing) corresponding categories and landing pages. The links will lead to the Catalog > Categories page, the selected item will be shown there and the category tree will also be opened to the corresponding path.
• Tweakwise App | The previously released improvements to other 'connected to' tabs are also now available in Catalogue > Products > Connected Categories and in in Filtering > Filtertemplates > Detailpage > Connected. It shows the full path and is clickable.
• Analytics API | We’ve added the API reference for the Analytics API to our documentation website, just like we have for the Backend and Frontend API. This should make it easier to do a server-side implementation of the Analytics API and track page views, purchases and searches that way. Feel free to take a look around: https://docs.tweakwise.com/reference/analytics-api-introduction
• Analytics API | The Analytics API contained a bug where it would return a 500 Internal Server error when a request with an empty request body was made. We now return a 400 Bad Request with a clear error message, as expected.
• Tweakwise App | You can now open Tweakwise Demoshop by quick accessing it from the category module in Tweakwise App > Catalog > Categories.
• Backend API | The /product call now includes optional search and paging parameters. This also significantly enhances request performance, even if the optional parameters are not used.
• Tweakwise App | The filtertemplates detail pages in Tweakwise App have now paging & search functionality in order to make this module way faster than before. Some side effects are in place since: The quick filterbuttons on the right will no longer save on click, but only after clicking the button which saves the whole form. A few notes:
  • If you add filters to a template, it will always be added at last position(s). This mean in case of paging that after adding a new filter, you will automatically go to the last page where the newly added filter is. Paging is currently set at 50 items per page.
  • If you change pages or search, it will not save the previous 'state'. So if you want to make changes in the filters and then search or use pagination, you have to save before doing that otherwise the changes will be lost.
  • If you make any change and then accidentally (or on purpose) click away from the page - you will be warned of unsaved changes and asked to save before leaving.
• Tweakwise App | We’ve made a minor tweak to the category selector in the app. Basically, it now prioritizes categories which start with the entered search term. This should make it easier to find the categories you are looking for compared to before, when the categories were sorted only alphabetically. There was also a small bug that made is impossible to scroll through all the results. That’s now also fixed.
• Tweakwise App | In the filter statistics module it is possible to filter the results by usage in a specific category. If the ID of the category being filtered on was very large, then the results on the page would be as if no category filter got applied. This was confusing and has now been fixed.
• Tweakwise App | We have added direct links to entities on the property usage page. All property pages (feed, external, derived) now have clickable links on their ‘used’ tab. We also have added internal clickable linking to products and properties from multiple places in the app on occasions where this was still missing.

JavaScript

• Suggestions JS | We have added an identifying data-property to each suggestion group so that customers can target each if they wish. The values are SearchPhrase, Category, FacetFilter and Product and these are under the property data-suggestion-type. These data-properties can be used for styling customizations for example, as you now can target each property by itself.
• Suggestions JS | Suggestions JS now also listens to customer provided event listeners, and that is in two instances: when the suggestion container opens and when it closes. More information can be found here: https://docs.tweakwise.com/docs/js-suggestions-js-api-reference#on
• JS Implementation | We've expanded the JS Implementation's settings in the App with tn_parameters_except options. You can now configure these hidden exclusion filters for the search and lister page results.
• JS Implementation | Fixed a bug where filters using the slider-settings could not be updated if the minimum value was 0.
• Recommendations JS | From now on some JS events will be fired with requests to our servers within the Javascript Recommendations plugin. In this way it is possible to hook into the plugin's life-cycle and, for example, inject more information to the product tiles. The following events will be fired: twn.request.started, twn.request.success (with data payload), twn.request.failed, twn.request.completed.
• JS Implementation | We implemented a maximum number of showed categories in a category tree (facet tree; number already customizable in app), and after reaching this threshold (i.e. "Number of values"), showing a "Show more/less" button (as is the case with most other filters).
• JS Implementation | We fixed a small bug when overriding translations.
• Suggestions JS | In this release we've fixed a bug in the Suggestions JS where incidentally nothing was shown for a search term even though our API did return some results.

The possibilities regarding pagination in our Javascript implementation are expanded with two new options. Apart from paginating via page-numbers, which remains our default behavior, we have introduced infinite scroll and a load more button.

If a customer lands on a paginated link (for example via a bookmark), we show a ‘load previous products’ on top in order to be able to paginate back. Both new ways are available for all existing and new implementations and can be triggered via a local Javascript configuration or in Tweakwise App.

See more: https://docs.tweakwise.com/reference/js-js-implementation-local-configuration#paginationtype

With Universal Analytics (UA) being phased out last year (2023, July 1st) we implemented a Google Analytics 4 (GA4) module as its successor in Tweakwise App. As all of are customers are migrated in the meantime, we encountered some behavior we did not expect.

Apparently, as GA4 is way more flexible in configuration than UA, customer reports can be set-up with some dimensions you can use to group and filter your data. We updated our module so we are completely compatible with these configuration.

So, if you have configured your GA4 property and dimension reports based on for example hostname or language, we can split your reports in Tweakwise App too. This means that there is no longer a requirement to have a one on one relation between storeview and Google-property. You can use one property for multiple storeviews and purposes.

Google Analytics 4 is a paid feature and is accessible under Tweakwise App > Connectivity > Google Analytics 4