AD0-E605 · Question #22
A financial services customer wishes to suppress people from active credit card campaigns as soon as they submit an application for the associated credit card name. The business's goal is to optimize
The correct answer is C. Application Submit is modeled as an XDM Experience Event class-based schema D. Offer is de-normalized back into the Application Submit schema. C is correct because an application submit is a time-stamped behavioral action - exactly what XDM Experience Events are designed to capture. Streaming these events into Real-Time Customer Profile triggers immediate audience re-evaluation, which is what enables the suppression to
Question
A financial services customer wishes to suppress people from active credit card campaigns as soon as they submit an application for the associated credit card name. The business's goal is to optimize ad spend by suppressing people quickly who convert and use the savings to help funnel more money back into their acquisition strategies. The current data model that IT has provided from their data warehouse looks like the following:
It is assumed that each application submit contains an offer that is always associated to a credit card name. Assuming all applications are streamed into the Real-Time Customer Profile, in which two ways could a developer model the application submit event to ensure the real-time suppression requirement is supported? (Choose two.)
Exhibit
Options
- AApplication Submit is modeled as an XDM Individual Profile class-based schema
- BOffer is modeled as an object within the Application Submit schema
- CApplication Submit is modeled as an XDM Experience Event class-based schema
- DOffer is de-normalized back into the Application Submit schema
How the community answered
(63 responses)- A19% (12)
- B10% (6)
- C71% (45)
Explanation
C is correct because an application submit is a time-stamped behavioral action - exactly what XDM Experience Events are designed to capture. Streaming these events into Real-Time Customer Profile triggers immediate audience re-evaluation, which is what enables the suppression to happen in real time.
D is correct because de-normalizing the offer (and its associated credit card name) directly into the Application Submit event schema means all the data needed to evaluate suppression eligibility is present the moment the event lands - no lookups or joins required, no added latency.
A is wrong because XDM Individual Profile schemas represent who someone is (attributes, preferences), not what they did - using it for a transactional event like an application submit is the wrong class, and it won't fire the time-series trigger needed for real-time suppression.
B is wrong because modeling Offer as a separate object implies a normalized relationship that requires resolution at query time - this introduces latency that violates the real-time suppression requirement; D's de-normalization eliminates that join.
Memory tip: Think "Event = Experience Event, Real-time = De-normalize." If data needs to be acted on instantly, it must already be embedded in the schema - any lookup is a delay. Profile class = who you are; Experience Event = what you just did.
Topics
Community Discussion
No community discussion yet for this question.