Sitemap and Data Ingestion

Event Type Requirements

Marketing Cloud Personalization sitemaps use the action field as a descriptive label (for example, View Product, Add to Cart, and so on) to help identify what happens on a page. The Data 360 Web SDK uses interaction.name for this purpose, and also requires an eventType field to determine how the event maps to the website connector event schema.

When using standard interaction name constants (for example, ViewCatalogObject, AddToCart, or Purchase), the SDK automatically derives the correct event type.

However, custom actions (for example, Read Article or Shared Article) ingest correctly only when they match a valid event type in the web event schema and follow the required naming conventions. For this reason, we recommend providing an explicit interaction.eventType that matches the event schema object. Alternatively, you can use an interaction.name value that’s also a valid eventType token, and ensure that it matches the schema object.

• Begin with a letter
• Contain only alphanumeric characters and underscores (no spaces)
• Not end with or have consecutive underscores
• Contain a maximum of 80 characters
• Match an object defined in your Data 360 website connector event schema

Example: Incorrect Custom Event Coding
// Event without eventType doesn’t ingest properly
SalesforceInteractions.sendEvent({
  interaction: {
    name: 'Read Article'  // Invalid eventType token naming convention (contains a space)
  }
});

Example: Correct Custom Event Coding
// Event containing explicit eventType
SalesforceInteractions.sendEvent({
  interaction: {
    name: 'Read Article',
    eventType: 'contentEngagement'  // Must match Data 360 schema object
  }
});

Site Maps and Custom Attributes

Using custom attributes in the Data 360 Web SDK requires nesting them in an attributes object.

In the Marketing Cloud Personalization Web SDK, you can place custom catalog item custom attributes at the top level of an object. In the Data 360 Web SDK, you can keep any standard fields, like type and id, at the catalogObject top level. However, any custom attributes at the top level of catalogObject are dropped during transformation to the Data 360 payload.

Example: Marketing Cloud Custom Attribute Coding
// Marketing Cloud Personalization SDK pattern (loses custom attributes in Data 360 Web SDK)
catalog: {
  Product: {
    _id: 'SKU123',
    color: 'red',   // Top-level custom attribute
    size: 'L',      // Top-level custom attribute
    brand: 'Acme'   // Top-level custom attribute
  }
}

Example: Correct Custom Attribute Coding
// Data 360 SDK pattern (required attributes wrapper for custom fields)
interaction: {
  name: SalesforceInteractions.CatalogObjectInteractionName.ViewCatalogObject,
  catalogObject: {
    type: 'Product',
    id: 'SKU123',
    attributes: {   // <-- wrapper for custom fields
      color: 'red',
      size: 'L',
      brand: 'Acme'

Changes for Campaign Responses

The Marketing Cloud Personalization Web SDK provided specific methods to programmatically access server-side campaign decisions. In the Data 360 Web SDK, these methods don’t exist. Instead, we recommend using the Web Personalization Manager and sitemap transformers to render personalization responses.

The Web Personalization Manager (WPM) is a visual tool for managing personalized content on non-Salesforce websites. You can use this tool to create and refresh personalized experiences that appear when and where you want them, using customer interaction data from the web SDK. Sitemap transformers provide the ability to render personalized responses (for example, a carousel of product recommendations or a custom hero banner) using handlebars-based templates defined in your sitemap.

The WPM and sitemap transformer approach is preferred because it automatically:

• Renders content, injecting HTML/CSS using sitemap transformers following the Shadow document object model (DOM) encapsulation standard.
• Tracks impressions and clicks by attaching “stat” tracking monitors to rendered content.
• Hides page elements while decisions load, defending against page flicker.

For situations where manual retrieval of personalization decisions is required, the Data 360 Web SDK provides SalesforceInteractions.Personalization.fetch() as a programmatic API.

When choosing manual retrieval using the fetch approach, you are responsible for:

• Rendering personalized content yourself
• Manually tracking any view or click engagement events for fetched decisions
• Implementing any flicker defense (if needed)

This table calls out the general differences between the getCampaignResponses and the Personalization.fetch methods.

Sitemap Content Zone Requirements

Content zones are predefined areas of your website that can receive personalized content. For Salesforce Personalization to function properly, content zones must have both a name and selector value defined.

// Example: Defined content zones in sitemap for personalization
{
  name: 'Product Detail Page',
  isMatch: () => /\/product\//.test(window.location.pathname),
  contentZones: [
    { name: 'hero_banner', selector: 'div#hero' },
    { name: 'recommendations', selector: 'div#recs-container' }
  ]
}