Adobe Target works in development, but one market sees nothing in production

The same exit-intent experience works in a test environment but fails for one market after promotion. The immediate question is whether Adobe Target sent a proposition and the page failed to render it, or the request never qualified. A recent Experience League discussion describes this market-specific AEP Web SDK scenario.

Compare the two network paths

Capture the Web SDK request and response in a working market and the failing one, using the same consent state and activity eligibility. Adobe's Web SDK debugging guide shows how to inspect personalization decisions. Record datastream ID, environment, property token, page URL and whether a Target proposition appears. If the response has a proposition, the investigation moves to application rendering and event timing. If not, it remains a delivery or eligibility question.

Inspect promoted configuration

Adobe's Target setup for Web SDK requires Target to be enabled in the relevant datastream and the correct property token when properties are used. Compare published Tags build versions and production datastream configuration, not just source code. For an exit-intent experience, verify that the trigger still fires and that the element exists when the decision is applied.

Write a market-specific release check

Use a known eligible profile and a stable test page in each market. Save the request, response and rendered result as three separate artifacts. That evidence lets the Target owner, Tags owner and frontend owner resolve the issue without passing an ambiguous screenshot between teams.

Adovo’s view

“It works in dev” is a statement about one path, not about the release. A market-specific experience needs a market-specific contract across configuration, delivery and rendering. When those three are observable, ownership becomes clear.