How we made an AEM storefront respond to a customer's lifecycle

For a company building AI for enterprise customer experience, we had a challenge: show a visitor move from browsing to a simulated purchase, then show the storefront respond to that change. The experience needed to come from Adobe's customer profile and decisioning stack. If a button in our demo simply swapped the hero text, we would have proved very little.

We started with a more basic question. What kind of site would make that change visible? We considered adapting an existing non-retail AEM site, but a storefront gave us a natural sequence: browse a product, choose a variant, add it to a bag and complete a purchase. We adapted Adobe's WKND sample code into an AEM storefront with a home page, listing and product pages, a bag, a mock checkout and a confirmation page. Adobe Commerce supplied catalogue data. Checkout recorded a simulated purchase; it did not take payment or create a Commerce order.

Giving the page something real to react to

The first phase had three visitor states: an anonymous guest, an identified prospect who had not bought anything, and a returning customer. We put three places on the page under decision control: the home hero, product suggestions and assistance copy. AEM kept default content for a guest or for a request that returned no offer.

We used Adobe Tags and Web SDK to send page and shopping events through a datastream into Adobe Experience Platform. We created the identity and event model, lifecycle audiences in Real-Time CDP, and an Adobe Target activity for the prospect and returning-customer experiences. Customer Journey Analytics gave us a place to check whether the page, product, cart, help and purchase events arrived. Target selected the content for the three placements.

The demo included a way to select a test identity. It was useful for walking through the scenarios, but selecting an identity could not itself claim that a visitor had become a customer. The purchase event had to reach Adobe; the audience and subsequent Target response had to account for the change.

When the wrong customer appeared

During testing, Target sometimes returned no decision or the wrong experience. We traced the Web SDK request, its identity, the Experience Platform identity graph and the Edge response instead of treating the visible page as sufficient evidence. Several simulated people had been used in the same browser. Their customer IDs had become linked through a shared Experience Cloud ID, so the test identities no longer represented separate people.

We isolated the demo identities and cleared the browser identity state when switching between them. We also turned off legacy ECID migration and third-party cookies in the test property's Web SDK configuration. Adobe's identity graph guidance describes how shared identifiers can merge separate people; the Web SDK settings explain what those cookie options do.

A second problem appeared at checkout. Navigation could begin before the purchase request completed. We changed the Web SDK event delivery for that interaction so the browser could finish sending it as the page unloaded. On a product page, we also found that both page-view and product-view events were requesting the same Target placements, which appended one suggestion twice. We left decision requests with the page view and kept the product view as a measurement event.

The test that settled it

The decisive check used one clean browser identity. The prospect page request returned Target's first-order offers. We completed a simulated purchase, followed the confirmation page and loaded the next page with that same identity. This time the Edge response contained the returning-customer Target experience, and AEM Publish displayed the corresponding hero, suggestions and assistance copy. We could follow the sequence from browser event to identity to audience to delivered offer. The recorded Phase 1 scenarios also covered guest defaults, product and variant interactions, cart and help events, and the purchase transition.

That verified the agreed first-phase behavior in the development environment. Checkout remained a simulated purchase, while audience availability, Target delivery, and analytics processing were separate checkpoints. The external AI decision service was planned for a later phase.

What stayed with us was the acceptance test. A convincing page can still be driven by a demo switch. We trusted the change once the purchase used the same visitor identity and Adobe returned a different offer on the following request.