personalization
The personalization object configures what personalization decisions (offers or propositions) are requested and how they are handled in the request and response. It is especially valuable in Adobe Target or Adobe Journey Optimizer implementations, as it is the driving force that allows you to customize displayed content per user.
alloy("sendEvent", {
personalization: {
decisionScopes: ["hero-banner"],
surfaces: ["web://example.com"],
schemas: ["https://ns.adobe.com/personalization/dom-action"],
sendDisplayEvent: true,
sendDisplayNotifications: true,
includePendingDisplayNotifications: true,
defaultPersonalizationEnabled: false
},
renderDecisions: true,
xdm: adobeDataLayer.getState(reference)
});
The personalization object contains the following properties:
personalization.decisionScopes
The decisionScopes property is an array of strings that instructs the Web SDK to retrieve and return personalization decisions. Each item in the array identifies a location, context, or logical placement where personalized content is desired.
This property is useful when you want to explicitly fetch personalized content for specific areas or components of a page. It is especially valuable in single-page applications that might require different sets of offers as the user’s navigation or view changes. You can also use this property to optimize performance by only retrieving offers for the UI elements relevant to the user.
personalization: {
decisionScopes: ["hero-banner", "cart-offer"]
}
In Adobe Target, each decision scope maps to an mbox or activity. In Adobe Journey Optimizer, each decision scope maps to decision-based web content placements or campaigns. In Offer Decisioning, decision scopes map to which offers or propositions that the visitor should receive.
defaultPersonalizationEnabled instead of specifying it here in decisionScopes.personalization.surfaces
The surfaces property is an array of surface URI strings that manually define the channel, device, or context for which personalization is requested from. They allow you to distinguish between different digital experiences, such as domains, apps, or device platform within your cross-channel ecosystem. By default, the library infers the default surface from the current page. You can use this property to override the automatically-inferred surface for the current page.
This property is valuable when you want to use cross-channel personalization and must distinguish how personalization works between separate channels. It allows you to create distinct offers for different sites under the same Adobe Experience Platform organization.
personalization: {
surfaces: ["web://example.com", "web://support.example.com/contact"]
}
This property is foundationally used with Adobe Journey Optimizer, as it matches up with surfaces set up in Journey Optimizer campaigns and surface management.
personalization.schemas
The schemas property is an array of schema URI strings that filter the types of personalization content requested from the Edge Network. Setting this property restricts the response that you receive from Adobe to only include offers that match the content type definitions that you specify. If omitted, the library requests offers of all available schemas for the matched scopes or surfaces.
This property helps optimize response size and makes sure that your web site or application only receives offer types that it can handle. It is also helpful when used with single-page applications that renders personalized content in a specific way (such as using only DOM actions or only JSON objects).
personalization: {
schemas: [
"https://ns.adobe.com/personalization/dom-action",
"https://ns.adobe.com/personalization/html-content-item"
]
}
The following schema URIs are supported:
https://ns.adobe.com/personalization/dom-action: Offers that are direct DOM actions, typically generated by the Visual Experience Composer in Adobe Target. They contain instructions to automatically manipulate elements on the page without additional code. It is the standard for auto-rendered web personalization.https://ns.adobe.com/personalization/html-content-item: Offers that contain raw HTML delivered as a string. Your implementation typically inserts this content at the desired location on the page, giving you more control than DOM actions. Commonly used for banners, snippets, or modal content.https://ns.adobe.com/personalization/json-content-item: Offers that are formatted as a JSON object. Most commonly used in API-based implementations or front-ends that expect structured data instead of HTML or DOM changes.https://ns.adobe.com/personalization/redirect-item: Offers that redirect to a different URL. Used to take the user to a new page based on targeting or decisioning logic, such as landing pages or onboarding flows.https://ns.adobe.com/personalization/ruleset-item: Delivers a block of business logic to power a client-side rules engine. Contains a versioned ruleset defining logical conditions and consequences (if/then personalization logic).https://ns.adobe.com/personalization/message/in-app: Offers formatted specifically for Adobe Journey Optimizer in-app messages, typically rendered as modals, banners, pop-ups, or overlays.https://ns.adobe.com/personalization/message/content-card: Offers formatted specifically for Adobe Journey Optimizer content cards, designed for persistent or inbox-style feeds in web or mobile apps.https://ns.adobe.com/personalization/message/native-alert: Offers formatted specifically for Adobe Journey Optimizer native alerts, triggering platform-native notification dialogs.https://ns.adobe.com/personalization/measurement: Used to tracks clicks and interactions on personalized offers. Does not contain content that can be rendered.https://ns.adobe.com/personalization/eventHistoryOperation: Schema for altering a visitor’s event history in local storage. Used internally by SDKs for tracking which experiences that have been delivered or blocked. Does not contain content that can be rendered.https://ns.adobe.com/personalization/default-content-item: Fallback or default content, typically when no personalized offer is eligible. It ensures that non-qualifying users still receive content, keeping the experience consistent.
personalization.sendDisplayEvent
The sendDisplayEvent property is a boolean that determines if a display notification event is automatically sent to the Edge Network immediately after personalized content is rendered on the page. If omitted, its default value is true. Set this variable to false if you do not want to indicate that personalized content was rendered for impression tracking.
The most common use case for setting this variable to false is when you plan to send another command elsewhere in your implementation that flags a display event. Some implementations have both impression and Analytics events; this property gives you full control over which sendEvent commands increment impressions.
personalization: {
sendDisplayEvent: true
}
sendDisplayNotifications instead.personalization.includePendingDisplayNotifications
The includePendingDisplayNotifications property is a boolean that controls if any pending display notifications are bundled into the current sendEvent call. Pending display notifications are impressions for personalized content that have been rendered but not yet reported to the Edge Network as a display event. This property is helpful when using single-page applications, as rendering personalized content and sendEvent calls might be asynchronous to each other.
The default value for this property is false. Set this property to true if you want to batch and flush any pending display notifications so their impressions are accurately recorded. Synchronous implementation, such as traditional websites, typically do not need to set this property.
personalization: {
includePendingDisplayNotifications: true
}
personalization.defaultPersonalizationEnabled
The defaultPersonalizationEnabled property is a boolean that gives you explicit control over how the Web SDK requests the default page-wide personalization scope (__view__) and surface for this sendEvent command. By default, on the first sendEvent command after a page load, the Web SDK requests offers for the default page-wide personalization scope and associated surfaces. Subsequent sendEvent commands do not request default personalization. You can use this property to override that behavior. It is valuable in single-page application implementations where you might want to request default personalization again as the user navigates your site. You can also use this property when you want to only send a display event without duplicating offer retrieval.
personalization: {
defaultPersonalizationEnabled: false
}
This property uses the following logic depending on how it is set:
- Not set: Request default personalization when it has not yet been requested. Default personalization is typically requested on the first
sendEventafter a page load, then not requested again on subsequentsendEventcalls on the same page. Setting this property overrides this behavior. true: Explicitly request the page scope and default surface, even if thissendEventcommand is not the first after a page load. Ideal times to set this property totrueare when you need to force a default personalization request, such as in single-page application scenarios.false: Explicitly suppress the request for the page scope and default surface, even if thissendEventcommand is the first after a page load. Ideal times to set this property tofalseare when you want a givensendEventcommand to not request new offers and instead just send data to Analytics or send a display event.
Personalization components using the Web SDK tag extension
The Web SDK tag extension equivalent of this property is the Personalization section when configuring a ‘Send event’ action.