I85PREP
⌘ K
AEM Sites Business Practitioner Expert study materials
AEM Sites Business Practitioner Expert study resources

Personalization That Never Fires

AEM Sites Business Practitioner Expert · Put your knowledge to work in context.

All case studies

Personalization That Never Fires

A B2B software company configured an AEM Experience Fragment (XF) offer on the homepage using ContextHub. The audience is 'Enterprise visitors' defined by a segment that checks a companySize trait greater than 500. The XF is mapped to the segment in the page's targeting. Analytics shows the Enterprise offer is served to only 0.3% of homepage visits, though the sales team says roughly 25% of traffic is enterprise. The ContextHub store for companySize is populated by a client-side script that calls an external API after page load. The page uses the default targeting engine, and the CDN caches the homepage for 10 minutes. Editors report the offer 'sometimes' appears after a refresh.

1. Diagnose why the Enterprise offer almost never appears, and propose the fix.

Read the worked answer

Several compounding causes, each individually enough to suppress the offer:

  1. Client-side trait timing. ContextHub resolves companySize only after the external API call completes. AEM's targeting evaluates segments at render time. If the trait is not yet in ContextHub when the page is rendered, the visitor falls into the default (non-enterprise) experience. The offer appearing 'after a refresh' is the tell - by then the trait is cached in ContextHub.
  2. CDN caching. With a 10-minute TTL and default targeting, the first-rendered variant can be cached and served to everyone, or the personalized variant is cached for the wrong audience. Caching and personalization conflict unless handled explicitly.
  3. Segment logic. companySize > 500 requires the trait to be a number; if the API returns a string, the comparison silently fails.

Fix:

  • Move the trait resolution server-side (e.g., resolve via a service or pass the value into ContextHub before render) so the segment can be evaluated at first render.
  • Bypass or vary the CDN cache for personalized paths (e.g., disable caching on the homepage or use a cache key that accounts for the resolved segment), or move personalization client-side so the cached shell is neutral and the offer swaps in.
  • Validate the trait type and segment rule with the segment tester.

Judgement: personalization + CDN caching + late client-side data is a classic triple failure. The practitioner must make the trait available before render and make caching aware of personalization.

2. The business wants 'enterprise' visitors to also see a personalized CTA on 200 product pages. What approach should the practitioner recommend to scale this without editing every page?

Read the worked answer

Do not hand-edit 200 pages. Options, ranked:

  1. Shared XF + targeting at the template/container level. Put the personalized CTA in an XF referenced by a component included in the product template (or a common container). Target once on the XF/component; all 200 pages inherit it. Update the template or the shared component, not each page.
  2. Editable template + policy. Add the CTA component to the product template with a policy that allows targeting. New and existing pages using that template pick it up (existing pages may need the component added if not inherited - verify).
  3. MSM/live copy if regions are involved. If product pages are live copies, target on the master and roll out.

Caveats: confirm the 200 pages actually use the same template (if some are legacy static templates, they will not inherit). Also re-check the CDN/caching fix from the first issue applies to product pages too, or the CTA will hit the same suppression. Verify with a sample of pages across templates before declaring done.

Judgement: scale personalization through shared components/templates and inheritance, not per-page edits, and confirm template coverage first.