{`

Recent articles

Mastercard Dynamic Yield and Next.js 16 Partial Prerendering: Next.js 16 adds official support for partial prerendering, a web framework concept that allows pages to mix cached and uncached data without affecting site loading times. This article explains how to use this concept with Experience API for improved performance and developer experience.

Meet with us

Our Technical Experience team is here to advise teams on using Mastercard Dynamic Yield better in their existing code base and alongside other digital vendors. If you have a unique setup or a complicated use case for Dynamic Yield, or want to learn more about how you could improve your integration with Dynamic Yield, reach out to your Customer Success Manager or Technical Account Manager to schedule a session with them.

Recent product releases

Email notifications for implementation issues

The Dynamic Yield admin console now has an “Alerts” pane to show potential implementation issues in your site or app.

The Dynamic Yield admin console showing active alerts for Experience API errors, data feed not syncing, and event validation errors.

These alerts can help you be proactive in resolving issues early. In addition to seeing these in the console, you can subscribe to email alerts. Do this today, it only takes a moment to configure. These emails will be sent within 24 hours of when the issue is first detected, and then weekly reminders will be sent (note: product feed alerts are sent daily).

We will add additional alert types over time, and we welcome your feedback on the prioritization of new alert types.

Shopping Muse API: unlocking new possibilities in design and functionality

Shopping Muse, Dynamic Yield’s main Generative AI product, has been around and powering the AI assistant on major e-commerce brands since 2023. After it proved its value and stability in our default recommended experience, we now open access to Shopping Muse as an API.

A screenshot of Shopping Muse in its default configuration.

The Shopping Muse API allows you to build unique branded experiences on both web and mobile that incorporate Shopping Muse’s interactive product recommendations. You can integrate other content into the experience, you can (carefully) modify and enhance the visitor’s query before sending it to the API, and you can display products in native-feeling ways including instant checkout and “view on model” integrations. Additionally, it can be integrated into non-conversational experiences to create contextual and personalized AI-powered recommendations that still allow the visitors to follow up with questions or request visually similar products.

Shopping Muse will receive major upgrades in 2026 to expand its capabilities with other skills and customizability for brand knowledge, catalog expertise, and more. Inquire with your Customer Success Manager or Account Director to learn more or join the early access programs that will be available throughout the year.

Script performance improvements: up to 35% speed up

We are continuously evaluating opportunities to improve the loading times and performance of the Dynamic Yield script. The four categories of script performance that we’re tracking are:

Page load impact: how the script affects other resources’ loading time on the page.
Script loading time: how long it takes for the script to load and start operating.
Campaign execution: what delays the execution of campaigns, specifically those that can’t run immediately when the script loads due to dependencies on additional data.
Rendering: what affects the rendering time and performance of campaigns on the page.

In recent months, we have implemented several changes to improve performance across all categories. We will continue to do so throughout the rest of the year.

Some highlights in this area:

Multiple optimizations to the api_dynamic.js script structure focusing on its size, with backwards-compatible improvements. This file represents most of the site’s campaigns and settings. This directly improves the script loading time and indirectly reduces the page load impact.

New Site Speed Tips in the admin console, including personalized opportunities for reducing the size of the api_dynamic.js script based on campaign usage, and choosing image file formats that are more efficient (we recommend WebP for images).

New internal tools and guidance for analyzing api_dynamic.js that were created for our Customer Success department. Reach out to your Technical Account Manager to have them audit your site’s campaigns and settings and provide specific guidance. This is especially impactful for customers who have 20+ campaigns live on their site.

Updated network and asset loading settings to sequence scripts and resource loading better, allowing campaigns to start executing earlier for certain Dynamic Yield deployments. This included aligning the network settings between our US (adm.dynamicyield.com) and EU (adm.dynamicyield.eu) data centers so now EU-deployed customers receive all the same benefits that the US-deployed customers have had before.

An upcoming change here is loading Dynamic Yield’s auxiliary rendering and data collection script earlier, as shown in the diagram below. For certain customer setups, this gave an improvement of hundreds of milliseconds for the campaign execution and rendering times.

Upcoming: improving the user experience and default behavior of “optimized site loading” campaigns, meant to help with below-the-fold campaigns, to improve the adoption of this optional feature. The option to “optimize site loading” in the admin console has several meanings, and the most powerful of them moves most of the campaign data outside of api_dynamic.js and into an asynchronously loaded asset. We will improve the ease of use of this feature and visibility of its meanings, to ensure all customers who can benefit from it know how to do so. If you want an understanding of your current potential improvements of this feature, and to have it fully enabled for you right now, contact your Technical Account Manager who will audit your site’s campaigns and settings to come up with recommendations, including this.

Fewer cookies managed by Dynamic Yield

One of our big efforts in 2025 was reducing the amount of data stored in the browser in cookies and local storage. Without changing Dynamic Yield’s functionality, we reimplemented some features using server-side user profiles and removed 16 cookies and local storage items.

You can view the current list of cookies, local storage items and session storage items in the Cookies and Local Storage knowledge base article.

We prioritized the project for three reasons:

Adding the data to the server-side user profiles allows us to offer this functionality in non-browser contexts. For example, Experience API campaigns now can use the “Landing URL” targeting condition.
Browsers limit the size of cookies per website, and the fewer cookies are managed by Dynamic Yield, the more potential storage space is available to other vendors.
In most jurisdictions, it is required to list all browser-stored data in the privacy policy or a dedicated policy, in addition to disclosing and seeking user consent for data collection in general. By having fewer of these items, we allow customers to have simpler and less daunting privacy policies. You may wish to review your current policy and remove unnecessary items from it, comparing to the Cookies and Local Storage knowledge base article.

And if we’re discussing cookies, if you’re using the _dyid_server to work around Safari’s ITP or for server-side Experience API usage, you may wish to ensure that your implementation sets the Domain, Path, and Secure attributes correctly. We have recently updated the Server-Side Cookies knowledge base article.

New Mobile SDKs: React Native, Swift, Kotlin

For new customers that are looking to use Dynamic Yield in mobile apps, our mobile SDKs simplify the integration with Experience API in a mobile device environment. They are available for React Native, Swift and Kotlin.

The mobile SDKs provide type safety for API operations, and help in managing user and session identifiers for the mobile app.

Mobile apps that already use the API directly don’t need to switch to the SDK, as it is entirely optional.

Misc. updates to Experience API

Preview of draft campaigns now works for a set of campaigns using a selector group. Experience API has an optional built-in preview mechanism that can be used to test draft campaigns and preview individual variations. To support it in your website, when making Choose API calls, the application must check the page’s URL for any occurrences of the URL query parameter dyApiPreview and collect their values into the selector.preview.ids array in the request payload. Business users will be redirected to the website during their workflow and Dynamic Yield’s console will append unique values this way to URLs.

In the past, the console only supported previewing a single draft campaign at a time. It was possible, manually, to craft a URL that previews multiple drafts, but we saw low usage of this capability due to complexity. Instead, now the console allows a user to choose to preview all campaigns within the same selector group, and the correct URL will be created.

The Get Preview Link modal with the newly available option

As a reminder, you can identify all the campaigns that belong to a selector group using the right-hand side filters in the Campaigns table.

The campaigns list page's filters, including "Filter by Selector Group"

Added the “Landing URL” targeting condition to API campaigns, matching the behavior of the script-based targeting condition. This condition allows campaigns to change their behavior based on the page the user landed on to begin their session, or for traffic acquisition URL parameters (e.g., UTM parameters) which were present on the first page but are not available after site navigation. In Experience App campaigns, this is called “Landing Screen”.

Note that this will use the value of the first URL reported from either Experience API calls or script tracking, if you use both. You will want to report pageviews only from API or only from the script. That means that on pages where the script is implemented, your server shouldn’t report pageviews, and for pages or mobile app screens that don’t have the script, your server or mobile app should make an API call to report the pageview.

The improved search functionality in the API Logs now supports many more request attributes to search by. Using the Experience API Logs explorer, you can validate and diagnose your API usage without creating your own logging system and log explorer. You can now search for requests by user identifier (Dynamic Yield’s DYID or your customer user identifier), the request ID that was returned to your server, the page context, the selector name of the campaigns requested, custom page attributes (usually used for custom targeting), the browser name or device type, the browser’s user agent, and purchase transaction IDs (for purchase events).

Added support for “product performance” (aka “Social Proof”) in API campaigns by introducing the “Product Popularity” targeting conditions and “Product Performance” variable type in variations and templates. These were already available for script-based campaigns. For campaigns running on a product page, determined by the page context, you can now use the number of unique visitors who viewed or purchased to control which experience is shown and the content shown. This is the famous “Hurry up, 8 people purchased this product in the last day!” or “20 people are viewing this product.”.

Updated the communications opt-in/opt-out endpoints used for Reconnect. One of Reconnect’s main requirements is communicating to Dynamic Yield the opt-in status of consumers for each communication channel (email, SMS, push notifications). We introduced new API endpoints, and we recommend existing users to migrate to them over time. Reconnect Opt-In, Reconnect Opt-Out.

`}

Changelog

Post with callout and icon at the top

Welcome to Fallen Madrona