Explanation:
In Salesforce Data Cloud, streaming insights process real-time engagement data like abandoned browse behavior to detect patterns within a defined rolling time window. For hourly triggers to Journey Builder via data actions, the aggregation time window must be set to 1 hour, ensuring insights recompute and evaluate rules every hour. This controls the cadence of data action execution, enabling timely journey entry without relying on ingestion batches or unrelated schedules, thus aligning with the customer's requirement for efficient, event-driven orchestration.

Correct Option:

D. Set the insights aggregation time window to 1 hour:
Streaming insights use a configurable rolling window (minimum 1 minute to 24 hours) to aggregate streaming data like web/mobile events. Setting it to 1 hour causes the insight to refresh hourly, re-evaluating conditions (e.g., abandonment criteria) and triggering associated data actions to Journey Builder if met. This directly governs the trigger frequency, supports real-time behaviors, and integrates seamlessly with Marketing Cloud for automated journeys without custom coding.

Incorrect Options:

A. Set the activation schedule to hourly:
Activations publish segment data to targets like Marketing Cloud at scheduled intervals, but they do not trigger data actions based on streaming insights. Data actions are event-driven via insight rules, not activation schedules, so this would not achieve the required hourly cadence for journey triggers.

B. Configure the data to be ingested in hourly batches:
Ingestion batching applies to bulk data streams, not streaming sources like Web/Mobile SDKs for real-time events. Streaming data is continuous, and batching would delay processing, contradicting the near-real-time needs of abandoned behavior detection and hourly action triggers.

C. Set the journey entry schedule to run every hour:
Journey Builder entry sources (e.g., API events from data actions) are typically event-based, not scheduled. Scheduling the entry would poll for data hourly, adding unnecessary latency and inefficiency compared to insight-driven triggers, and it doesn't leverage Data Cloud's streaming capabilities.

Reference:
Salesforce Help: “Streaming Insights Overview” – Details aggregation windows and data action triggers for real-time orchestration to Journey Builder.

Explanation:
Engagement-based related attributes depend on recent event activity and the correct relationship path between the profile and the engagement object. If related attributes are missing from activation payloads, it typically means either (1) the engagement events fall outside the supported look-back window, or (2) the wrong related attribute path is selected. Reviewing these areas ensures the system can correctly resolve and include the expected event-based attributes in outgoing activations.

Correct Options:

A. The related engagement events occurred within the last 90 days.
Engagement-based related attributes only resolve if the qualifying engagement events fall within the supported activity window, typically 90 days. If the majority of segment members have older events, no values will appear in the payload. Ensuring that interactions are recent enough is essential for the attributes to be included in activations.

C. The correct path is selected for the related attributes.
Related attribute paths define how Data Cloud traverses from the Unified Individual to the engagement events. Selecting the wrong path—such as a mismatched DMO relationship—results in no engagement attributes populating. Verifying the path ensures the system pulls data from the intended engagement object and correctly resolves related attributes.

Incorrect Options:

B. The activations are referencing segments that segment on profile data rather than engagement data.
Segments based on profile data can still activate related engagement attributes. The segmentation criteria do not determine whether related attributes can be included in payloads; the related attributes rely on event availability and correct mapping. Therefore, this is not a cause for missing related attributes.

D. The activated profiles have a Unified Contact Point.
The presence or absence of Unified Contact Points does not affect engagement-based related attributes. Related attributes are derived from engagement events tied to the Unified Individual, not from contact point resolution. This does not help troubleshoot missing engagement attributes.

Reference:
Salesforce Data Cloud — Related Attributes for Activation & Engagement Window Requirements Documentation

Explanation:
The customer wants a deterministic, high-confidence match between CRM Contacts and Marketing Contacts using the shared CRM ID as the common identifier. In Data Cloud, the most accurate and performant way to achieve this is by mapping the shared key to the Party Identification DMO with the same identification name (CRM ID) on both sides, then creating an exact-match rule on that Party Identification attribute. This guarantees a 1:1 match without relying on fuzzy logic like email.

Correct Options:

A. Map the primary key from the two systems to Party Identification, using CRM ID as the identification name for both.
During data stream harmonization, both the CRM Contact stream and the Marketing Contact stream must map their shared CRM ID field to the Party Identification DMO, and both must use the exact same Identification Name value of “CRM ID”. This tells Identity Resolution that records sharing the same CRM ID value (regardless of source) belong to the same person.

D. Create a matching rule based on party identification that matches on CRM ID as the party identification name.
In the Identity Resolution ruleset, add a new matching rule of type Party Identification → Exact Match → Identification Name = “CRM ID”. This rule has the highest precedence and ensures that any record with the same CRM ID value is unified, overriding or complementing other fuzzy rules (e.g., email).

Incorrect Options:

B. Using different identification names (CRM ID vs Marketing ID) would prevent matching, because Party Identification matching requires the same identification name.

C. There is no “Individual ID” attribute for matching; matching is done on normalized attributes (e.g., Name, Email, Phone) or Party Identification. Custom rules on Individual ID are not supported.

Reference:
Salesforce Help: “Use Party Identification for Deterministic Matching” – Recommends mapping shared primary keys to Party Identification with identical Identification Name values.

Explanation:

To calculate customer lifetime value (LTV) with channel-specific revenue breakdowns (website, mobile app, retail), Metrics on Metrics is the ideal solution in Data Cloud. Here’s why:

1. Metrics on Metrics (Correct - D)

What It Does:
Allows layered calculations, where one metric (e.g., total revenue) is broken down into sub-metrics (e.g., revenue by channel).

Example:
Base Metric: Total Revenue (sum of all purchases).
Sub-Metrics:

Website Revenue (filtered by source = website).
Mobile App Revenue (filtered by source = mobile_app).
Retail Revenue (filtered by source = retail_store).

Why It Fits This Use Case:

Enables LTV to be calculated per customer while preserving channel attribution.
Supports dynamic segmentation (e.g., "High-LTV Mobile App Users").

Why Not the Other Options?

A. Nested segments → Useful for hierarchical audiences (e.g., "Premium Customers + Frequent Buyers"), but doesn’t calculate numeric breakdowns.
B. Flow orchestration → Coordinates processes (e.g., triggering campaigns), not metric calculations.
C. Streaming data transformations → Processes real-time data streams, but doesn’t aggregate historical metrics like LTV.

Key Takeaway:

Metrics on Metrics is the only feature that lets you:
1. Calculate LTV (a composite metric).
2. Slice it by channel (sub-metrics).
Critical for multi-touch revenue analysis.

Reference:

Salesforce Help - Metrics on Metrics
Exam Objective: Calculated Insights and Analytics.

Explanation:
Data from the Interaction and Mobile SDKs represents high-volume, real-time behavioral events (e.g., app clicks, page views). Performing aggregations on this data in short, 15-minute windows is a streaming analytics problem. It requires a tool that can process unbounded data streams in near real-time, computing results continuously as new events arrive, rather than on a scheduled batch basis.

Correct Option:

C. Streaming insight:
This is the correct method. Streaming Insights are specifically designed for this use case. They perform continuous, stateful aggregations (like counts, sums, or averages) on streaming data within defined time windows (tumbling, sliding, or hopping windows), making them ideal for real-time analysis of SDK event data.

Incorrect Option:

A. Batch transform:
Batch transforms are designed for processing large volumes of data that have already been ingested into the data lake, typically on a scheduled basis (e.g., hourly, daily). They are not suitable for low-latency, continuous aggregation of real-time event streams.

B. Calculated insight:
Calculated Insights compute metrics from unified profile data in the data model (e.g., total lifetime value). They are refreshed on a schedule and are not intended for real-time aggregation of raw, high-volume event streams from SDKs.

D. Formula fields:
Formula fields are used within data model objects to create a derived value based on other fields on the same record (e.g., concatenating a full name). They are evaluated per record and cannot perform aggregations across a window of multiple events.

Reference:
Salesforce Help - "Streaming Insights in Data Cloud"