Lookup schema audience | Community
Skip to main content
T
TashaCa
Level 1
February 26, 2026
Solved

Lookup schema audience

  • February 26, 2026
  • 1 reply
  • 48 views

Hi,


Can we use lookup attributes in audience criteria?

 I am looking for support around using the Lookup class in Audience criteria. We’re validating our RTCDP modeling approach for campaign eligibility and would appreciate architectural confirmation. We were asked last minute to include divisionNumber in an audience eligibility which is apart of the lookup schema and dataset in dev sandbox.
Current setup:
Profile schema (XDM Individual Profile) identities: accountID, urlAccName
Card Lookup dataset contains divNoLogo (Division Number + Logo)
Division Number = first 3 digits of divNoLogo (fixed length, 3 digits)

  • Card Lookup does not contain accountID
  • Card Lookup was previously profile enabled
  • Requirement: segment based on Division Number

Question:

Given that Card Lookup is not keyed by accountID, is Adobe’s recommended pattern to:
1. Materialize divNoLogo (or derived divisionNumber) onto the Profile store via a profile enabled enrichment dataset keyed by accountID, and segment directly on the Profile attribute, rather than
2. Rely on a schema relationship between Profile.divNoLogo and CardLookup.divNoLogo for audience evaluation?

Additionally:

  • Any concerns with storing divNoLogo as a non identity profile attribute strictly for segmentation purposes?
  • Any architectural risks with using a non person business key as a foreign key (not identity) in Profile?



Our objective is to ensure deterministic segmentation and alignment with Adobe modeling best practices before finalizing production architecture.

Additionally, we also will need to support with using the lookups in AJO.

Best answer by arpan-garg

​@TashaCa  

This situation comes up quite a bit when a lookup dataset suddenly needs to be used in audience eligibility.

From a modeling standpoint, using schema relationship is usually the cleaner and more standard Adobe approach. If divNoLogo exists on the profile and is also the key in the Card Lookup dataset, you can create a relationship from Profile.divNoLogo to CardLookup.divNoLogo and use the lookup attributes during segmentation. The lookup dataset does not need accountID for this to work. Also, having divNoLogo on the profile as a non-identity attribute is perfectly fine. Using business keys (store IDs, region codes, product codes, etc.) as foreign keys on the profile is a very common pattern and doesn’t create any architectural risk.

That said, there is one practical difference between the two approaches that’s important.

If you materialize the divisionNumber directly onto the profile through a profile-enabled enrichment dataset keyed by accountId , segmentation becomes much simpler because the attribute sits directly on the profile. This also means it can be used in streaming segmentation without any dependency on lookup joins. The only downside is that it technically increases the profile size since the value is stored per profile, but in practice the increase is almost invisible.

With the relationship approach, you avoid duplicating the attribute and the data model stays cleaner. However, you should keep in mind that when segmentation relies on lookup joins, the audience evaluation usually happens through batch rather than streaming. So if real-time qualification is required, the materialized attribute tends to be more reliable.

So practically speaking, both approaches work. Relationships keep the model cleaner, while materializing the attribute on the profile makes segmentation and streaming use cases easier. The choice usually depends on whether streaming audience qualification is needed.

Hope this helps.

Arpan

1 reply

arpan-garg
Community Advisor
arpan-gargCommunity AdvisorAccepted solution
Community Advisor
March 8, 2026

​@TashaCa  

This situation comes up quite a bit when a lookup dataset suddenly needs to be used in audience eligibility.

From a modeling standpoint, using schema relationship is usually the cleaner and more standard Adobe approach. If divNoLogo exists on the profile and is also the key in the Card Lookup dataset, you can create a relationship from Profile.divNoLogo to CardLookup.divNoLogo and use the lookup attributes during segmentation. The lookup dataset does not need accountID for this to work. Also, having divNoLogo on the profile as a non-identity attribute is perfectly fine. Using business keys (store IDs, region codes, product codes, etc.) as foreign keys on the profile is a very common pattern and doesn’t create any architectural risk.

That said, there is one practical difference between the two approaches that’s important.

If you materialize the divisionNumber directly onto the profile through a profile-enabled enrichment dataset keyed by accountId , segmentation becomes much simpler because the attribute sits directly on the profile. This also means it can be used in streaming segmentation without any dependency on lookup joins. The only downside is that it technically increases the profile size since the value is stored per profile, but in practice the increase is almost invisible.

With the relationship approach, you avoid duplicating the attribute and the data model stays cleaner. However, you should keep in mind that when segmentation relies on lookup joins, the audience evaluation usually happens through batch rather than streaming. So if real-time qualification is required, the materialized attribute tends to be more reliable.

So practically speaking, both approaches work. Relationships keep the model cleaner, while materializing the attribute on the profile makes segmentation and streaming use cases easier. The choice usually depends on whether streaming audience qualification is needed.

Hope this helps.

Arpan

    T
    TashaCaAuthor
    Level 1
    March 10, 2026

    Thank you ​@arpan-garg . I really appreciate your feedback on this and your detailed response. 

    Terms & ConditionsAccessibility statement

    Loading footer...