nerdexam
Adobe

AD0-E409 · Question #44

An eCommerce client has Adobe Target correctly installed on their website. They have an auto- created global Target request (mbox) that runs early on in the page load but after the data layer has…

The correct answer is B. Create a second Target request (mbox) called 'product-data' including the product ID when. Option B is correct because Adobe Target best practice for late-loading data is to fire a named (non-global) mbox at the point the data becomes available. A named mbox like product-data is a separate, scoped request that Target treats independently from the global mbox - this…

Implementation and Integration

Question

An eCommerce client has Adobe Target correctly installed on their website. They have an auto- created global Target request (mbox) that runs early on in the page load but after the data layer has initialized. Many of the items in the data layer are applied to the auto-created global Target request (mbox). On product pages, the product ID is loaded into the data layer only after the Page Load DOM event has triggered. The client needs to be able to send the product ID to Adobe Target when it has loaded and receive any experiences the user should see based on that product ID. They do not want duplicate experiences that have already been received by the auto-created global Target request (mbox). According to best practices, what should the client do?

Options

  • ASet up a product feed to ingest the product data each day at midnight.
  • BCreate a second Target request (mbox) called 'product-data' including the product ID when
  • CCreate a second Target global mbox request including the product ID when available.
  • DDelay the auto-created Target global mbox request until after the product ID has loaded into the

How the community answered

(17 responses)
  • A
    6% (1)
  • B
    76% (13)
  • C
    6% (1)
  • D
    12% (2)

Explanation

Option B is correct because Adobe Target best practice for late-loading data is to fire a named (non-global) mbox at the point the data becomes available. A named mbox like product-data is a separate, scoped request that Target treats independently from the global mbox - this means Target will serve product-specific experiences without re-delivering the experiences already provided by the global mbox, satisfying the no-duplicates requirement.

Why the distractors are wrong:

  • A - A product feed is a Recommendations catalog ingestion mechanism (batch, not real-time); it does nothing to deliver personalized experiences during an active page visit.
  • C - A page can only have one global mbox. Creating a second global mbox causes conflicts and is not supported; it would also risk triggering duplicate experiences, the very problem the client wants to avoid.
  • D - Delaying the global mbox until product data loads defeats its purpose: the global mbox fires early to minimize flicker and deliver page-wide experiences quickly. Delaying it degrades performance for every page, not just product pages.

Memory tip: Think of the global mbox as the "front door" (fires once, early, for the whole page) and named mboxes as "room doors" (fire on demand, scoped to a specific location/moment). When you need to send data that arrives late, open a new room door - don't hold the front door open waiting for it.

Topics

#mbox#data layer#page load#implementation

Community Discussion

No community discussion yet for this question.

Full AD0-E409 Practice