This guide covers deploying data streams from a web or mobile SDK connector and mapping Data Lake Objects (DLOs) to Data Model Objects (DMOs) in Data 360. It applies to both connector types and should be completed after the connector schema has been defined.
Deploy Data Streams
Both web and mobile connectors follow the same deployment process.
- Open the App Launcher and select Data Cloud.
- Navigate to the Data Streams tab.
- Select the connector — web or mobile — and click Next.
- Review the list of event definitions from the connector schema. All events should be selected to enable DMO mapping.
[ACTION REQUIRED: Review Note] - NOTE: If new event definitions are added to the schema after the initial deployment, this page must be revisited to select the newly added events before mapping can proceed.
- Select the data space to deploy to. A single data stream can be shared to additional data spaces without duplicating ingestion credits — data is ingested once and shared.
- Confirm the refresh mode is set to Partial. This is the default and must not be changed. Incremental mode overwrites any field values not included in the event and must not be used for web or mobile implementations.
- Optionally, apply Filters to exclude specific events from flowing into the selected data space.
- Click Deploy.
Data Streams Created per Connector Type
The connector schema determines which data streams are deployed. The structure is the same for both web and mobile connectors.
| Connector Type | Profile Events | Behavioral Events |
|---|---|---|
| Web Connector | One data stream per profile event definition | One combined data stream for all engagement event definitions |
| Mobile SDK Connector | One data stream per profile event definition | One combined data stream for all engagement event definitions |
[ACTION REQUIRED: Review Note] - NOTE: The sitemap (web) or event tracking configuration (mobile) should be built and validated in parallel with the schema. Deploying data streams progressively — rather than waiting for a complete schema — enables earlier event validation via Data Explorer.
Map Data Streams to DMOs
After deployment, DLO fields from each data stream are mapped to the appropriate DMO fields in the data space.
Key Mapping Rules
- Schema object to DMO cardinality — All event data objects in a data stream can be mapped to multiple DMOs. All other schema objects must be mapped 1:1 to a DMO. Mapping a non-event schema object to multiple DMOs will cause data to be overwritten.
- Field fan-out — A single DLO field can be mapped to multiple fields on a single DMO.
- Automated mapping — Fields where the
masterLabelexactly matches a DMO field label are mapped automatically. Aligning schema field names with DMO labels reduces the amount of manual mapping required.
Common Field Mappings
The following standard field mappings apply to both web and mobile implementations.
All Event Data DLO Object — Fields present on every event, regardless of type.
| Schema Field | DMO Field |
|---|---|
dateTime |
Created Date |
deviceId |
Individual ID (in identity data streams, deviceId can also be mapped to partyId) |
eventId |
DMO Engagement Object Primary Key |
Engagement DLO Objects — Fields specific to behavioral engagement events.
| Schema Field | DMO Field |
|---|---|
eventType |
Engagement Channel Type |
interactionName |
Engagement Channel Action |
sourceChannel |
Engagement Channel |
personalizationID |
Personalization |
[ACTION REQUIRED: Review Note] - NOTE: Relevant documentation for identity, contact point email, and behavioral data stream mapping should be reviewed for connector-specific field details.
[ACTION REQUIRED: Update Image Here] - Original Context/URL: DLO to DMO attribute mapping canvas showing source DLO on the left and target DMOs on the right
Progressive Mapping Approach
For implementations with many event types, a progressive approach simplifies the mapping process. This method applies to both web and mobile connectors and allows teams to focus on one event type at a time while taking full advantage of automated mapping.
- Split the entire connector schema file into separate files — one per event type.
- Add the first event type schema file to the connector schema configuration.
- Create a new behavioral event data stream, or add the event type to an existing stream.
- Complete all required DMO mapping for that event type.
- Repeat for each remaining event type.
Automated mapping matches schema fields to DMO fields where the masterLabel is an exact match. Structuring field names to match DMO labels from the outset maximises the automation benefit.
Standard vs Custom Interaction Events
This distinction applies specifically to web implementations and affects how behavioral events are mapped to DMOs.
Standard interaction names — Events using names such as View Catalog Object, Purchase, or Add to Cart follow preconfigured transformation logic. The eventType field is derived automatically from the interaction name and cannot be overridden. All events sharing the same eventType are mapped to a single DMO.
Custom interaction names — When a site or app includes multiple object types that users interact with in different ways (e.g., Products and Articles), custom interaction names and event types provide the flexibility to map engagement with each object type to a separate DMO.
Example: View Product events can be mapped to a Product Browse Engagement DMO while Download Article events map to an Article Engagement DMO — rather than routing both through the same catalog event type and DMO.
[ACTION REQUIRED: Update Image Here] - Original Context/URL: Example event translation table for standard interaction names (View Catalog Object, Add to Cart, Purchase)
[ACTION REQUIRED: Update Image Here] - Original Context/URL: Example event translations for custom interaction names showing Data 360 translated events
Validate Events in Data 360
Data Explorer in Data 360 should be used to confirm that events are landing correctly after deployment.
- If events are missing, all mandatory schema fields should be verified as present in the emitted event and field data types should be confirmed to match the schema definition.
- For behavioral event data streams, the
eventTypefield for the specific event type group must be confirmed as mapped to the correct target DMO. - For web: the sitemap and schema should be built in parallel to allow progressive event validation as mapping proceeds.
- For mobile: SDK event emission should be validated against the schema before finalising the data stream deployment.
Best Practices
- Data streams should be deployed as soon as schema objects are defined — progressive deployment enables earlier validation.
- Partial refresh mode must be used for all web and mobile data streams without exception.
- Different
eventTypevalues should be used for engagement with different object types (e.g., Products vs Articles) to preserve mapping flexibility. - For web implementations using standard interaction names, the preconfigured
eventTypederivation should be understood before DMO mapping is planned. masterLabelvalues in the schema should be aligned with DMO field labels to maximise automated mapping and reduce manual effort.