ÃÛ¶¹ÊÓƵ

Target release notes (prerelease)

This article contains prerelease information for upcoming ÃÛ¶¹ÊÓƵ Target releases, including SDKs, APIs, and JavaScript libraries.

Last Updated: December 11, 2024

NOTE
Release dates, features, and other information are subject to change without notice.
To view information about the current release, see Target Release Notes. The information on these pages might be the same, depending on the timing of releases. The issue numbers in parentheses are for internal ÃÛ¶¹ÊÓƵ use.

Offers Library user interface update (January 9, 2025)

To enhance the user experience for ÃÛ¶¹ÊÓƵ Target users, this release updates the Offers Library user interface. Using the latest ÃÛ¶¹ÊÓƵ Spectrum design system, this update standardizes inconsistent design patterns and introduces new enhancements, including the following:

  • Bulk offer management: Select and delete multiple offers simultaneously.

  • Code Editor upgrades: Refreshed HTML and JSON editors with syntax highlighting and line numbering.

  • Improved offer cards: Enhanced quick information and detail cards for easier information access.

  • Persistent search and filters: Adds session-persistent search and filter options.

Starting January 9, 2025, all Target customers will gain access to the new UI, with the option to switch back to the current version of the UI if needed.

Here’s a short video that highlights the changes in this release:

Offers UI refresh video

ÃÛ¶¹ÊÓƵ Experience Platform Web SDK __view__ scope optimization (October 22, 2024)

Between July 22, 2024 and August 15, 2024, the Target team optimized the __view__ scope, enhancing the accuracy of activity impression, visit, and visitor reporting. This optimization aims to automatically capture reporting data for auto-rendered propositions and should be transparent to most accounts.

All new ÃÛ¶¹ÊÓƵ Experience Platform Web SDK customers will have this optimization enabled. However, customers who migrated from at.js and have not followed the implementation steps below have the optimization disabled. We urge these customers to review their implementations by February 3, 2025. After this date, we will enable the optimization for all customers. Failure to review and adjust implementations by then might impact reports, as mentioned below. Please contact ÃÛ¶¹ÊÓƵ Customer Care if you need to confirm whether your implementation is affected or if you require more time to adjust your implementation.

IMPORTANT
If you cannot complete your implementation review and resolve any issues by February 3, 2025, you can request a one-time, six-month extension. Ensure that your request is submitted by January 31, 2025. ÃÛ¶¹ÊÓƵ will review and decide on your request.

To benefit from this optimization in case of manual proposition rendering, review your Platform Web SDK implementation to ensure that you are sending notifications after manually rendering experiences or when using the applyPropositions method (or the corresponding Launch action as a helper) to render experiences.

The most-common scenarios when experiences are manually rendered include:

  • Using JSON offers
  • Using a custom decision scope in an activity created in the Form-Based Experience Composer
  • Not using renderDecisions: true when fetching an activity created using the Form-Based Experience Composer that uses the global __view__ scope

If notifications are not implemented as documented in Render personalized content in the Data Collection guide, reporting data might be missing in Target and in Analytics for Target reporting (A4T). In certain scenarios, you might notice an incorrect traffic split because the reporting data is not captured. Or, in other scenarios, reporting the same event repeatedly.

Depending on your implementation, check for Analytics and A4T reporting impacts.

The Platform Web SDK supports two implementation types for rendering experiences and personalizations:

  • Single call for personalization and measurement.

    Initially recommended, the single-call approach for the Platform Web SDK is scheduled to be deprecated in favor of the split-call approach. ÃÛ¶¹ÊÓƵ advises all new implementations to use the new split-call approach and recommends that existing customers transition to the split-call method as well.

    If you continue to use the single-call approach, you might notice the following unexpected changes in your Analytics reports:

    • A dip in bounces.
    • A4T and Page View hits not stitched together, making it challenging to perform certain breakdowns and correlations of your A4T reports using Analytics eVars and events.
  • Split calls (also known as top and bottom of page events).

    This implementation type is the new split-call implementation approach recommended by ÃÛ¶¹ÊÓƵ. With this approach, the new optimization does not impact Analytics or A4T reports.

If you have questions, contact ÃÛ¶¹ÊÓƵ Customer Care. (KB-2179)

Additional release notes and version details

Resource
Details
Release notes: ÃÛ¶¹ÊÓƵ Target Platform Experience Web SDK
Details about changes in each version of the Platform Web SDK.
at.js version details
Details about changes in each version of the ÃÛ¶¹ÊÓƵ Target at.js JavaScript library.

Prerelease information section_7B9D4AAFC6A74388B9D7DEF0658D8B63

To receive advance notifications about upcoming product enhancements to Target and other ÃÛ¶¹ÊÓƵ Experience Cloud solutions, sign up for the ÃÛ¶¹ÊÓƵ Priority Product Update:

recommendation-more-help
3d9ad939-5908-4b30-aac1-a4ad253cd654