Adovo

Adobe Experience Cloud

Adobe Target Recommendations is a content system, not only a product carousel

Articles, videos, services and offers can all become Target recommendation entities. Success depends on a governed catalog, meaningful behaviour, eligibility controls and an experiment that measures more than clicks.

July 30, 2026

Teams often reach Adobe Target Recommendations through an ecommerce tutorial. The implementation talks about products, SKUs, inventory and purchases. A publisher, bank or B2B site then asks whether an article, video, service or research report must be forced into a commerce schema to become recommendable.

It does not.

In Target, the item being recommended is an entity. Adobe explicitly describes entities as products or content and gives examples ranging from movies to articles. The deeper design problem is not whether an article can pretend to be a product. It is how to create a trustworthy catalog and behaviour model for whatever the organisation wants to recommend.

Define the recommendation job first

“Show related content” is not a sufficient objective.

Choose the customer and business job:

  • help a reader continue learning about a topic;
  • help a customer discover the next relevant service;
  • reduce time to find support content;
  • cross-sell complementary products;
  • re-engage a known visitor with unfinished content; or
  • move a prospect from educational material to a qualified action.

The job determines the entity model, behaviour signals, placement, success metric and exclusions. A banking recommendation should not optimise only for clicks if it promotes products a customer cannot use. A publisher should not maximise recirculation by repeatedly showing nearly identical articles.

Build a catalog that can be governed

Every recommendable item needs a stable entity ID. Do not use a title or mutable URL as the identifier if either can change.

A useful content entity can include:

  • stable ID;
  • title and canonical URL;
  • content type and topic;
  • audience or market eligibility;
  • language and region;
  • publication and expiry dates;
  • image or presentation metadata;
  • sensitivity, legal or age restrictions;
  • author, product family or business priority; and
  • current availability status.

The catalog is an interface between the content or product system and Target. Give each field an owner and update rule. If an item becomes unpublished, expired or unavailable, Target needs that state quickly enough to prevent an inappropriate recommendation.

Use the right update path for the right attribute

Adobe supports several ways to maintain a Recommendations catalog.

Feeds are suited to bulk catalog loads and attributes that change on a daily or scheduled basis. They create a stable baseline from a product-information system, CMS or other authoritative source.

Entities API updates are suited to individual items or attributes that change more frequently, such as stock or price.

On-page or Delivery API updates can provide timely item context, but Adobe warns against allowing public delivery calls to create or change unverified clickable catalog content. Uncontrolled page data can pollute the catalog.

A common pattern is a governed feed for the full entity and a constrained real-time update for selected volatile fields.

Keep unavailable items when history matters, but exclude them from delivery

Deleting an out-of-stock product or expired article immediately can remove useful behavioural history and destabilise algorithms. Continuing to recommend it creates a customer failure.

Separate catalog presence from recommendation eligibility. Retain the entity when history is useful, update its availability state and use exclusions or collections so it cannot be delivered while unavailable.

Define re-entry rules. A product returning to stock may become eligible immediately; an expired regulatory article may require review and republication rather than a status flip.

Capture behaviour that means something in the domain

Product view and purchase are useful retail signals. Other domains need their own semantics.

For content, useful signals might include:

  • article viewed beyond a minimum engagement threshold;
  • video completed;
  • guide downloaded;
  • topic followed;
  • item liked or saved;
  • form started or completed; and
  • recommendation shown, clicked and consumed.

Do not treat every page load as equal evidence of interest. A mistaken click with a two-second dwell should not carry the same meaning as completing a technical guide.

The event contract needs a stable entity ID matching the catalog. If the behaviour event uses a URL while the feed uses a CMS ID, the recommendation system cannot reliably learn the relationship.

Real-time reaction and algorithm learning are different

A visitor liking three products may expect the next recommendation to change immediately. That requirement contains two possible mechanisms.

The first is real-time context: pass the liked IDs, category or profile preference into the next decision and use rules or filtering to narrow the result.

The second is algorithm learning: allow aggregate behaviour to influence a recommendation model over its processing cycle.

Do not promise instant model retraining when the business really needs immediate rule-based response. Combine a stable criterion with current context when same-session responsiveness matters.

Identity controls continuity

Anonymous and authenticated behaviour can produce different recommendation histories. Decide whether continuity is device-level, account-level or both.

When bringing attributes from CRM, AEP, BigQuery or another source, validate:

  • the alias or namespace used for matching;
  • update cadence and conflict handling;
  • whether multiple sources can update the same attribute;
  • consent and data-usage restrictions;
  • availability at decision time; and
  • separation between sites, markets and business units.

One IMS organisation does not require every site to use the same audience source, but shared identity and naming require governance to prevent accidental crossover.

Recommendations need merchandising and safety controls

Algorithms optimise within the world the organisation gives them. Add constraints for:

  • unavailable or expired entities;
  • market and language;
  • legal and suitability restrictions;
  • frequency and repetition;
  • already consumed or purchased items;
  • diversity across topic, brand or category;
  • editorial priorities; and
  • minimum catalog quality.

These controls are not interference with personalisation. They define what a responsible recommendation is.

Test the recommendation strategy, not only the widget

A click-through rate can rise because the module is more visually aggressive while the customer journey gets worse.

Choose a primary outcome aligned with the job: qualified content consumption, next-step completion, revenue per visit, reduced search exits or support deflection. Add guardrails for page performance, bounce, repeated content, unsuitable recommendations and long-term conversion.

Compare:

  • no recommendation versus recommendation;
  • different criteria or entity features;
  • personalised versus contextual rules;
  • placement and design; and
  • short-term engagement versus downstream value.

Record exposure correctly. A recommendation returned by the API but never rendered should not enter the experiment denominator as a visible treatment.

What to measure

  • catalog completeness and rejected entity updates;
  • unavailable or expired items delivered;
  • event-to-entity match rate;
  • recommendation render and exposure rate;
  • diversity and repetition;
  • qualified engagement after a recommendation click;
  • primary business outcome and guardrails;
  • anonymous-to-authenticated continuity; and
  • time from source-system change to recommendation eligibility.

Adovo’s view

Recommendations is not an ecommerce feature that other industries can borrow by renaming articles as products. It is a decision system operating on entities, behaviour and constraints.

Start with the customer job. Build a catalog whose fields and lifecycle can be trusted. Capture behaviour that means something, distinguish instant context from model learning and test downstream value rather than clicks alone.

The carousel is the visible part. The quality of the recommendation is decided much earlier, in the entity and event contracts behind it.

Primary documentation and further reading

Continue exploring

Adobe Experience Cloud

Adobe Web SDKConsent management

A production-ready Adobe Web SDK needs more than a successful network call

Adobe Web SDK reliability depends on consent timing, identity state, event contracts, personalisation rendering and performance. Testing those concerns separately leaves production gaps between them.

Read more

Adobe Experience Cloud

Adobe AnalyticsAdobe Target

Why Adobe Analytics, Target and CJA numbers do not match

Adobe Analytics, A4T, Target and CJA can all be correct while reporting different numbers. Reconciliation starts with population, unit, identity, time and processing—not with forcing dashboards to agree.

Read more

Adobe Experience Cloud

AEMAdobe TargetAdobe Analytics

ContentSync: Interactive Content Inside AEM

What changedThe product let marketers create, publish and measure interactive content inside AEM.

Read more
Explore Adobe services →