From External Audience Intelligence to Measurable Action An Adobe Architecture Without AJO

The audience has two layers of meaning

The external system determines the original population—for example, customers whose recent behavior suggests a need for proactive service outreach. RTCDP creates the final activation population by applying conditions relevant to execution:

External service-retention membership
AND current business eligibility
AND applicable channel requirements
EXCLUDING recent completions and suppressions

The source remains authoritative for its model. RTCDP remains authoritative for the additional activation criteria. This arrangement preserves the original calculation while allowing Adobe to account for current customer context.

AEP and RTCDP are separated below to show responsibilities. RTCDP uses AEP's underlying platform capabilities; they are not unrelated systems connected through a generic export.

The swimlane separates publication, execution, and measurement

The first lane owns the audience calculation. The integration lane owns publication and operational validation. AEP and RTCDP own identity association and activation criteria. Destinations own their decisions and execution. Feedback ingestion makes the resulting evidence available for CJA.

The steps are operational responsibilities rather than guarantees of immediate processing. Each stage has its own readiness conditions and latency.

Publication begins with a contract

The source should publish enough information to explain what the audience means and when its membership was calculated.

These are proposed contract concepts. Some may travel as payload attributes; others belong in a separate manifest or audit dataset.

Audience metadata and customer membership are different. Knowing that an audience exists does not establish who belongs to it. Likewise, an audience identifier must not be used as a customer identity.

For a repeatable implementation, use the documented audience import workflow rather than treating the segmentMembership field as a general-purpose write interface. Adobe's field-group documentation warns against manually populating that map. Segment Membership Details ↗

Validate a small set of known customers before releasing a large population. A successful API request does not prove that those customers are ready for downstream use. An empty export also deserves a specific rule: it may mean that nobody qualifies, or it may mean that the source failed.

RTCDP prepares a population for each destination

Sending an identical list everywhere is rarely sufficient. Each destination has different identity requirements and execution responsibilities.

Adobe documents outbound connections for Pega ↗, Facebook ↗, and Google Customer Match ↗. The Pega connection supplies profile attributes and audience membership to Customer Decision Hub.

Zeta requires an explicitly configured exchange and campaign process. Its documented SFTP capability ↗ is one possible building block, not proof of a complete native RTCDP integration.

A difference between the source audience count and a destination population is therefore not automatically a defect. It may reflect channel eligibility, missing identifiers, or deliberate exclusions.

Pega owns the decision it is asked to make

A customer's membership in the service-retention audience can become an input to Pega. Pega may select a service review, prioritize another interaction, or determine that no action is appropriate.

The return contract should distinguish decision selection from execution. A decision record explains what Pega chose; an execution record explains what actually happened. A “no action” response is meaningful evidence. Without it, analysts may interpret deliberate suppression as missing data.

If Pega also owns cross-channel treatment priority, the integration must distribute the necessary decision state before other systems act. That is an additional design responsibility; it is not automatically supplied by audience distribution.

Adobe Target adds the website to the execution model

A customer can receive a personalized service message when visiting the website, provided the implementation can resolve the relevant identity and audience context.

Target requires a configured activity and website implementation. Audience activation alone does not create content or prove that a visitor saw it.

Adobe's Target destination supports people audiences from multiple origins, including custom uploads. Personalization timing depends on the audience and implementation; an imported membership does not make the original external model executable at the edge. Adobe Target connection ↗

An experience response is not equivalent to a confirmed display. Instrumentation should collect the appropriate display and interaction evidence. Target reporting in CJA ↗ is documented, but it requires reporting configuration separate from audience activation.

Coordination is the main design challenge without AJO

Pega, Zeta, Target, and advertising campaigns can operate concurrently. The organization therefore needs shared rules for treatment priority, contact limits, recent outcomes, and active service interactions.

A proposed policy might allow website assistance while preventing another outbound message after a service review is completed. The architecture must define where that policy is evaluated and how quickly updated facts become available. RTCDP can supply audience conditions, while execution systems may also require final checks.

There is no automatic global contact lock merely because all destinations receive Adobe audiences.

At every decision point, a “no” or a conflict should lead to exclusion or deferral according to documented priority rules. These are recommended business controls, not preconfigured product behavior.

The feedback loop is where the architecture becomes measurable

Every destination should return the evidence it can provide. Pega and Zeta may return customer-level interactions through configured integrations. Website collection can record Target displays and subsequent behavior. Meta and Google reporting may be aggregated.

Do not manufacture person-level exposure from aggregate advertising totals. CJA supports summary data ↗ for uses such as combining advertising measurements with on-site reporting.

The feedback design should preserve:

• Who was involved, where identity is available.
• Which audience publication initiated the action.
• Which campaign, treatment, or activity was involved.
• Whether an action was selected, executed, suppressed, or failed.
• When the event occurred and when it arrived.
• Which unique identifier supports duplicate detection.
• Which business outcome followed.

Operational and analytical uses should be separated. A completion event may affect future eligibility. Aggregate spend is analytical data. Not every reporting dataset belongs in Profile.

Consider a customer who completes a service review after a Pega interaction. The completion returns to AEP, updates the relevant operational state, and becomes available in CJA. Subsequent audience evaluation excludes that customer from further retention outreach.

The interval between completion and downstream suppression should be measured. The architecture should not promise immediate removal across all destinations.