Asset performance tracking in Analytics Cloud has been expanded to include interactions within Page Fragments. Previously, only assets displayed via Native Widgets (Portlets) were instrumented for performance metrics.
Release Notes
Release Flag (opt-in)
We will introduce a deprecation badge within the Segments Editor in DXP. This badge will be visible whenever users attempt to create a new segment or edit an existing one. In addition to the badge, a UI alert will inform users that Segments in DXP are planned to be deprecated and that Analytics Cloud (AC) will become the single source of truth for segmentation. This change is intended to proactively set expectations and guide users toward creating and managing segments in Analytics Cloud moving forward. Starting in 2026.Q1 version, the Segments module in DXP will transition to a read-only experience by default. Users will only be able to view the list of segments created in Analytics Cloud within DXP. Segment creation and editing capabilities in DXP will no longer be available unless the Segments deprecation feature flag is explicitly enabled. The long-term direction is for Analytics Cloud to fully own segment creation and management, ensuring a single, centralized segmentation workflow. |
The previous OIDC authentication flow identified users based on their email address, which could led to mismatches if users changed their email or if different identity providers shared the same address. To ensure reliable user identification, the system now matches users using the OIDC sub (subject) claim, which is a permanent and unique identifier for each user.
Key Benefits:
Improved identity reliability: Using the OIDC sub claim ensures each user is consistently and uniquely identified, even if their email address changes over time.
Reduced authentication conflicts: Eliminates mismatches caused by shared or reused email addresses across different identity providers, improving security and user experience.
Generally Available (aka OOTB)
This mechanism is server-to-server, making it more reliable than front-channel methods that depend on the user's browser. The IdP will directly notify each RP (Relying Party aka Service Provider) that a user's session has ended by sending a signed logout_token. The RP must validate this token and terminate the corresponding local session.
Key Benefits:
Higher reliability and security: Server-to-server logout does not rely on the user’s browser, reducing failures caused by network issues, blocked scripts, or closed sessions.
Consistent session termination: Signed
logout_tokennotifications ensure each RP can securely validate and promptly terminate the correct local user session.
Generally Available (aka OOTB)