Adobe Real-Time CDP implementation and activation

Define what the customer data platform must enable

A customer data programme needs a concrete activation purpose. The first use case might suppress existing customers from an acquisition audience, recognise a service need across channels or identify a group eligible for a specific experience. Emerge starts with that decision and works backwards to the minimum sources, identifiers and attributes required.

Adobe Real-Time CDP brings customer-data capabilities into the Adobe Experience Platform ecosystem. The selected edition, destination support and operational limits are verified during scoping. We do not equate a connected source with a complete customer view or assume that a product described as real time makes every ingestion, audience and destination path instantaneous.

Establish source contracts before ingestion

The source inventory records data owners, entities, identifiers, update frequency and permitted uses. Customer accounts, contacts, devices, orders and service records represent different things. Mapping them into a shared model requires an explicit decision about those relationships, not simply matching fields with similar names.

Each dataset has a purpose and a quality contract. We define required fields, accepted values, timestamps and deletion or correction behaviour. Historical imports and ongoing updates are assessed separately because a one-time clean file does not prove the live source will remain reliable.

Ingestion failures and rejected records are visible to an owner. A partially loaded source can produce a plausible audience while excluding the customers the business most needs to reach. The operational model therefore measures completeness and freshness alongside technical job success.

Design identity with ambiguous cases in mind

Identity resolution should be tested against the organisation’s actual relationships. Shared email addresses, household devices, multiple accounts and changed contact details can create unwanted merges or fragmentation. Emerge defines namespaces, matching intent and the role of each identifier before activating profile-dependent use cases.

Merge behaviour and source precedence are reviewed where applicable. A newer value is not necessarily a more authoritative value, and a merged profile does not automatically inherit every permission associated with its contributing records. We document how conflicts are resolved and how operators investigate an unexpected relationship.

The test pack includes deliberately difficult examples rather than only clean one-to-one customer records. Acceptance requires the team to understand why a profile contains the information it does and how to correct a source issue without destabilising unrelated identities.

Apply governance to the intended use

Data labels, access controls and usage policies are designed around the organisation’s approved purposes. Emerge maps sensitive attributes and consent state to the proposed audience and destination behaviour. A field available for service resolution may be inappropriate for advertising activation.

Sandbox and role design separate implementation work from approved production use. Test data and controlled profiles support configuration review without exposing an unnecessary customer dataset to every contributor. Access is granted to the task and reviewed when project responsibilities change.

Preference changes and deletion requests need an end-to-end operating path. The design identifies the authoritative source, expected propagation and the systems that require confirmation. A profile update inside the platform is not treated as proof that every downstream destination has already applied the same change.

Create audiences that represent a business rule

An audience definition states who qualifies, which source fields it uses, when it is evaluated and why the business needs it. We compare sample qualified and excluded profiles with the business owner. The review catches rules that are syntactically valid but commercially wrong, such as treating an old purchase as current product ownership.

Refresh requirements are chosen for the use case. Some decisions need event-driven responsiveness; others can use a scheduled audience with simpler operating requirements. The delivery design records the expected end-to-end delay and the conditions that can extend it.

We also establish suppression and expiry. A useful audience should not remain active indefinitely after its original purpose ends. Owners need a process for retiring rules, removing unused destinations and reviewing whether the underlying data still supports the intended decision.

Verify destination delivery beyond the export job

A destination mapping specifies the identifiers and attributes allowed to leave the platform. Emerge verifies the receiving system’s requirements, credentials and supported audience operations. Only the fields required for the activation are included.

Acceptance follows controlled profiles from source ingestion through identity, qualification and destination receipt. Tests cover rejected identifiers, stale credentials, consent changes and audience removal where supported. Export completion and downstream usability are separate observations, and the report explains any destination-specific limitations.

The operating handover includes source contracts, identity decisions, audience definitions, destination mappings and reconciliation procedures. Monitoring has named owners for data quality, policy issues and activation failures. The resulting programme expands from proven use cases, with each new source or destination justified by an observable customer or commercial need rather than a goal of collecting everything available.