Data comes in through source connectors, the Web/Mobile SDK and the streaming API. It is shaped by XDM schemas and stored as datasets in the data lake. Identity Service links identities, and Real-Time Customer Profile merges Profile-enabled data into one view per person. Audiences are built on that profile and activated to destinations or used by apps such as Journey Optimizer, Target and Customer Journey Analytics. Data governance, consent and sandboxes apply across all of it.

AEP is the underlying platform: schemas, datasets, identity, profile, Query Service and APIs. Real-Time CDP is an application built on AEP for building audiences on the unified profile and activating them to destinations. It comes in editions (B2C, B2B, B2P) and tiers, and those decide which features and destinations are licensed.

Every ingested dataset lands in the data lake. That's where Query Service, CJA and data science read from, and it keeps full history. Only datasets enabled for Profile are also loaded into the Profile store, which is optimised for real-time lookups, segmentation and activation. That's why you enable for Profile only the data that audiences and personalisation actually need.

Typical ones are the size of a profile fragment, the number of ExperienceEvents kept per profile, the number of identities in one graph, the number of Profile-enabled datasets and the number of audiences. In practice you keep Profile schemas lean, set ExperienceEvent expiry (TTL) so old behaviour ages out, avoid sending low-value events to Profile, and check the current limits in Adobe's guardrail documentation before sizing a solution.

Experience Data Model is Adobe's standard, extensible schema framework, built on JSON Schema. Every dataset conforms to an XDM schema, so data from web, CRM, call centre and offline sources shares one vocabulary. That's what lets Profile, segmentation, AJO and CJA all use the same data without custom mapping each time.

Individual Profile holds record data: attributes describing who a person is and their current state, such as name, email, loyalty tier or consent. ExperienceEvent holds time-series data: every record has a timestamp and an _id and describes something that happened, such as a page view, purchase or call. A schema is built on exactly one class.

A field group (formerly a mixin) is a reusable set of fields you add to a schema, such as Personal Contact Details or Commerce Details, and it's tied to a compatible class. A data type is a reusable object structure, such as an address or a phone number, that you can use inside field groups or schemas. Custom fields go under your tenant namespace (the _tenantId object) so they never clash with Adobe's standard fields.

Start from the use cases and the audiences they need, not from the source tables. Usually that means one Profile schema for customer attributes (CRM ID, contact details, loyalty, consent) and a few ExperienceEvent schemas, for example web/app interactions, orders and store transactions. Reuse standard field groups, add custom fields only where needed, decide identities and the primary identity up front, and enable for Profile only what activation will use.

A union schema is the merged view, generated by the system, of every Profile-enabled schema that shares a class. Real-Time Customer Profile and the audience builder work against the union, which is why a field added to any Profile-enabled schema of that class becomes available for segmentation.

Only additive, non-breaking changes. You can add new fields, but you can't delete fields, rename them or change their data types, because data already ingested depends on them. Plan field names and types carefully before enabling, and prototype in a development sandbox first.

When one entity references another, such as events referencing a product SKU or, in B2B, a person belonging to an account. A relationship lets you link the reference field to another schema's identity, so attributes such as product category or account industry become usable in segmentation without copying them onto every event.

Model each order as one ExperienceEvent and keep its line items as an array of objects inside that event (for example productListItems with SKU, quantity and price). Don't create one event per item unless the business needs item-level events. Product details that change independently, such as category or brand, go in a separate lookup schema keyed by SKU rather than being copied onto every order.

_id must uniquely identify each event, because Profile treats repeated _id values as the same event. Use the source's transaction ID, or combine it with the event type or date when one order can produce several rows, for example a purchase and a later cancellation. The timestamp should be when the event actually happened, not when it was loaded.

Profile isn't relational, so denormalise. Fold one-to-one and one-to-few data such as addresses and loyalty membership into the Profile schema. Turn time-stamped rows such as sales into ExperienceEvents. Keep only shared reference data that changes on its own, such as products or stores, as lookup schemas linked by relationships. Over-normalising makes segmentation harder and slower.

Define the loyalty object once as a custom data type. Data types aren't tied to a class, so you can use the same structure inside a Profile field group and an ExperienceEvent field group, which keeps paths and definitions consistent.

A namespace gives context to an identity value: the same string means different things as an Email, Phone, ECID or CRM ID. Whenever two or more identities appear in the same record, for example an ECID and a CRM ID sent on login, Identity Service links them. The links build one identity graph per person, which Profile uses to stitch fragments together.

Every Profile and event record needs a primary identity. You can mark schema fields as identities and set one as primary, which suits CRM and batch data with a clear key. identityMap is a flexible field that can carry several identities, one flagged as primary, and is the usual pattern for Web SDK data where an anonymous ECID becomes known on login.

The Experience Cloud ID: a device and browser identifier set through a first-party cookie by the Web SDK (or the Mobile SDK on apps). It identifies anonymous visitors, and it's the identity that later links to a known ID such as a CRM ID or hashed email when the user authenticates.

Each device has its own ECID. When the customer logs in, the authenticated events carry both that device's ECID and the CRM ID in identityMap, so Identity Service links ECID-1 to CRM ID and ECID-2 to CRM ID. Both ECIDs now sit in the same graph, and the merge policy stitches pre-login behaviour from both devices into one profile.

Identity Service is deterministic: it only links identities that actually appear together in a record. It does not guess links from signals such as IP address or device fingerprint. If a business needs probabilistic matching, that has to come from a separate identity partner, and the result is ingested as data.

That's graph collapse. A non-unique value was sent as an identity, for example a shared placeholder email, a shared device or a test login, so it linked unrelated people. Find the over-linked identity in the identity graph viewer, stop sending placeholder or shared values as identities at source, and use identity graph linking rules where available (unique namespaces, namespace priority) so one person can't link to multiple CRM IDs. Then clean or re-ingest the affected data.

Use identityMap, or mark both fields as identities, so each record carries whichever identities it actually has, with one flagged as primary per record. When a row arrives with both, Identity Service links them, so later rows with only one of them still reach the same person.

Check uniqueness before marking anything as an identity. If an email or phone can belong to several people, or the CRM record ID isn't one-per-person, using them as identities will merge different customers. Use a stable person-level ID as the identity and keep shared values as plain attributes, or use identity graph linking rules where available.

A namespace's identity type can't be changed after creation. Create a new custom namespace with the correct type, update the schema identity fields or identityMap mappings to use it, and stop sending data with the old one.

No. Identity Service builds the graph at ingestion from identities that appear together in records. The merge policy only decides, at profile assembly, whether that graph is used to stitch fragments (private graph or none) and which attribute values win.

Batch loads files or connector data on a schedule. It suits CRM extracts, offline sales and historical backfills. Streaming sends records through the HTTP API or the Web/Mobile SDK and reaches Profile within seconds, so it suits behavioural signals that should drive real-time audiences and journeys. Both land in XDM datasets.

Common ones are cloud storage (Amazon S3, Azure Blob, SFTP), CRMs such as Salesforce and Microsoft Dynamics, databases and data warehouses, and the HTTP API. You authenticate the account, pick the source data, map it to a target XDM schema and dataset, and set a schedule. Dataflow monitoring then shows each run's records and errors.

Data Prep is the mapping layer between source fields and XDM. Besides one-to-one mappings, you can use calculated fields: string, date, maths and conditional functions to format phone numbers, concatenate names, hash emails, convert date formats or derive values before data is written.

Read the error diagnostics in dataflow and dataset monitoring. The usual causes are data that doesn't match the schema (wrong types, bad date formats), missing required fields, or a missing primary identity on a Profile-enabled dataset. With partial ingestion enabled, valid rows load up to an error threshold and the failed rows are reported, so fix the mapping or the source data and re-ingest those rows.

Backfill through batch, in chunks, with correct event timestamps. Decide first whether all of that history needs to be in Profile or only in the data lake: older events may only matter for CJA or Query Service. Set ExperienceEvent expiry if the history shouldn't stay in Profile indefinitely, and validate a small sample in a development sandbox before running the full load.

You create an HTTP API streaming connection, which gives you an inlet endpoint, and post XDM-formatted JSON that references the target schema and dataset. Records are validated (synchronous validation is available for testing), and Profile-enabled data becomes available for streaming audiences in near real time.

By default a new record from the same dataset replaces the fragment, so either send the full record every time or enable upserts. For partial updates, enable the Profile dataset for upsert (isUpsert) and send changes through a streaming connection with Data Prep, which updates only the fields you send.

Re-enable the dataflow so future runs continue, then load the missed files, for example with a one-time dataflow for those files or a dataflow with backfill. Confirm the gap is filled by checking dataset batches and the audience counts that depend on that data.

Use encrypted data ingestion for a batch cloud-storage source: create an encryption key pair through the API, give the public key to the team producing the files, and enable encryption on the dataflow so AEP decrypts the files during ingestion.

Subscribe to alert rules such as source flow run failure or ingestion failure, in the Alerts UI (email and in-app) or through Adobe I/O Events for a webhook or monitoring tool. Then use the dataflow monitoring and error diagnostics to find the cause.

The failed rows don't satisfy the target schema, for example a required field is null, the primary identity is missing, or a data type doesn't match. Check the batch errors, fix the query output or relax the schema, and re-run.

The Web SDK (alloy.js) is one library that sends one request to the Adobe Edge Network. From there a datastream routes the data to AEP, Adobe Analytics, Target and other services. That means fewer calls and libraries, one consistent ECID, and data that's already in XDM for AEP.

The server-side configuration on the Edge Network that decides where data from the Web/Mobile SDK goes: which AEP sandbox and dataset, which Analytics report suite, whether Target or Offer Decisioning is on, and any data mapping. You normally keep separate datastreams for development, staging and production.

Tags (formerly Launch) is the tag manager used to deploy the Web SDK. You build data elements that read values from the page or data layer, build the XDM object, and use rules to send events (sendEvent) on page load, clicks or custom triggers, then publish through dev, stage and prod environments.

Event forwarding sends data that has already reached the Edge Network on to third-party endpoints, such as an ad platform's conversion API or a data warehouse, from Adobe's servers instead of the browser. It cuts page weight and client-side tags and gives you more control over what's shared.

Set the SDK's default consent (for example pending or out until the user chooses), then call setConsent with the user's choice from the consent banner, using the Adobe standard or IAB TCF format. The SDK holds or drops data accordingly, and consent is also stored on the profile so downstream activation can respect it.

The Web SDK sends one request with XDM data to the Edge Network. The datastream routes it, and the Edge Network enriches it with the ECID, consent and edge profile data before passing it to Target. Target's decision comes back in the same response, and the SDK renders it on the page.

The hub profile is the full Real-Time Customer Profile in the AEP region. The edge profile is a lightweight copy near the visitor, used for same-page and next-page personalisation. Events received at the edge update the edge profile and flow into the hub. The hub projects only what's needed back to the edge, such as audience memberships and mapped attributes, through edge destinations.

Profile-enabled datasets send records into the Profile store as fragments. Fragments are linked through the identity graph, and a merge policy decides how they combine into the merged profile that segmentation and activation use.

A merge policy defines attribute precedence and identity stitching. Precedence is either timestamp-ordered (the most recently updated value wins) or dataset precedence (a ranked list of datasets decides who wins). Stitching is either the private identity graph or none. Each class has a default merge policy, and audiences reference one.

With stitching set to none, fragments that are only connected through the identity graph aren't combined, so a person's web events and CRM attributes may count as different profiles. Different precedence rules can also change which attribute value wins, and therefore who meets an attribute condition.

Attributes the system calculates on the profile from event data, such as total spend in the last 30 days, last product viewed or the count of purchases. They're kept up to date automatically and can be used in audiences and personalisation, so you don't have to pre-calculate them upstream or write heavy event rules.

Look the profile up by identity in the Profiles UI, or call the Profile entities API, to see its attributes, events, audience memberships and linked identities. Use the identity graph viewer to see which identities are linked and from which datasets.

Batch evaluation runs on a schedule (typically daily) across all profiles and supports the full rule set. Streaming evaluation updates membership as data arrives, but only for supported rule patterns. Edge evaluation runs on the Edge Network for same-page or next-page personalisation, with a narrower set of patterns. The choice is latency versus rule complexity.

Profile attributes, ExperienceEvents with counts and time constraints, existing audiences, and external audiences. Rules combine with AND/OR, include/exclude and sequential event logic. Under the hood an audience is stored as a Profile Query Language (PQL) expression.

The rule uses a pattern streaming doesn't support, for example a long look-back window combined with multiple events, or a reference to a batch audience. Check the evaluation method shown in the builder, simplify or split the logic (for example a computed attribute plus a simple event rule), and confirm the data itself is arriving by streaming.

Audience composition (in Audience Portal) lets you combine existing audiences visually. You can merge or exclude audiences, split them by attribute or percentage, rank them, and enrich them with attributes before sending them to a destination. It's useful for test/control splits and for preparing activation lists without rebuilding rules.

Compare the estimate with a sample of qualified profiles, open several in the profile viewer to confirm they really meet the rule, and cross-check counts with Query Service against the source datasets. Test in a development sandbox and check that consent and governance conditions are part of the definition.

3,000 profiles qualify for both. OR counts each person once, so 5,000 + 10,000 − 3,000 overlap = 12,000. It's a simple check, but it shows you understand that audiences are sets of people, not counts of events.

Most web visitors are anonymous, so they only have an ECID and none of the CRM attributes. Only visitors who logged in, and so were stitched to a CRM ID, can meet the attribute condition. The fix is better authentication and identity stitching, not loosening the rule.

Realized: the profile newly qualified in this evaluation. Existing: it was already in the audience and still qualifies. Exited: it was in the audience and no longer qualifies. Tracking realized and exited shows how an audience is moving.

Don't wait for the daily scheduled run: trigger an on-demand evaluation, through flexible audience evaluation in the UI or a segment job via the API, and check the counts. Then activate it, making sure the destination schedule fits the launch.

Create a relationship from the event's SKU field to a product lookup schema and use multi-entity segmentation, so rules can use product attributes without re-ingesting events. Multi-entity audiences are evaluated in batch, so set expectations on latency.

Streaming destinations (ad and social platforms, personalisation tools), batch file-based destinations (Amazon S3, SFTP, Azure and email marketing platforms that take files), edge personalisation destinations for same-page use, and Adobe applications. Each defines which identities it accepts and how often it receives data.

Connect the destination account, select the audiences, map the identities the platform matches on (often hashed email or phone, with hashing done by AEP or upstream), add any attributes the destination supports, and set the schedule. Monitor the dataflow for activated and failed identities.

A data governance policy forbids the marketing action configured on that destination for data carrying certain labels, for example sending sensitive (S) or contract-restricted (C) fields to a third party. Remove the restricted fields from the mapping or audience, or review the labels and policy with the data owner. Don't just switch the policy off.

Marketing actions declare what the data will be used for, such as email targeting or third-party export. Governance policies are enforced against them, so without the right marketing actions AEP can't stop restricted data reaching that destination.

Create separate activation flows (dataflows) to the same destination connection, one per requirement, each with its own audiences, mapped attributes, file naming and schedule.

Labels classify datasets and fields: C (contract), I (identity), S (sensitive) and custom labels. Marketing actions describe what you want to do with data, such as exporting to a third party or onsite personalisation. Policies connect the two by stating which labels can't be used for which actions, and AEP enforces them at activation and in AJO.

Usually with the Adobe standard Consents and Preferences field group on the Profile schema: collect, share, personalise and marketing preferences per channel. Values arrive from the Web SDK (setConsent) or batch from a consent management platform. Audiences, destinations and AJO then check those fields, and consent policies can enforce them automatically.

Through Privacy Service. You submit access or delete jobs by identity, through the UI or API, and they're processed across AEP datasets, Profile and the other Experience Cloud apps you include. Keep your identity design clean so every system receiving the request can match the customer.

Use attribute-based access control: create roles, label the sensitive schema fields and audiences, and write policies that grant the agency's role access only to resources with permitted labels. Combine this with sandbox-level access, so the agency only sees the sandboxes it works in.

Querying data-lake datasets with PostgreSQL-compatible SQL. Common uses are validating ingestion, investigating data issues, building derived datasets with CREATE TABLE AS SELECT (which can be Profile-enabled), and connecting BI tools such as Power BI or Tableau.

Sandboxes are isolated partitions of one AEP instance, typically development and production, each with its own schemas, datasets, audiences and journeys. Configuration is promoted with sandbox tooling: export objects into a package and import it into the target sandbox, then reconnect sources and destinations there.

Create a project in Adobe Developer Console with OAuth server-to-server credentials and the AEP API added, then request an access token. Each call sends Authorization: Bearer <token>, x-api-key, x-gw-ims-org-id and x-sandbox-name headers. Roles and permissions on the product profile decide what the integration can access.

Look the profile up by identity namespace and value, either in the Profiles UI (Browse) or with the Real-Time Customer Profile API (entities endpoint). Check its attributes, linked identities and audience memberships against the source data.

A bank has web traffic identified only by ECID and a CRM extract keyed by customer ID. Marketing wants pre-login browsing to count toward a customer's profile.

Model a Profile schema for CRM data with CRM ID as the primary identity, and an ExperienceEvent schema for web data collected through the Web SDK. On login, send the CRM ID alongside the ECID in identityMap so Identity Service links them. Enable both datasets for Profile and use a merge policy with identity stitching on. Browsing from before login then appears on the known profile.

Whether you know that the linking happens when both identities appear in the same event, and that the merge policy has to allow stitching.

Retail wants to reach people who viewed a product category in the last 24 hours but didn't buy, within minutes rather than the next day.

Stream product-view and purchase events through the Web SDK into a Profile-enabled event dataset. Build the audience with a rule that streaming evaluation supports: viewed category X in the last 24 hours and no purchase event in the same window. Check that the evaluation method shows as streaming, then use it in an AJO journey through Audience Qualification or activate it to a destination.

Knowing which rule patterns stream and which fall back to batch, and designing around that limit.

After go-live, one profile suddenly has thousands of emails and orders. Call-centre agents had been entering a shared placeholder email for customers who didn't give one.

Inspect the identity graph viewer to find the over-linked identity. Stop sending non-unique values as identities: filter placeholders at source and only mark genuinely unique fields as identities. Use identity graph linking rules and namespace priority where available, then clean or re-ingest the affected data.

Root-cause thinking about identity design rather than just deleting the profile.

Marketing wants to send a high-lifetime-value audience to a paid-social destination, but some customers haven't consented to ad targeting.

Add a consent condition to the audience, or rely on the destination's consent enforcement. Label sensitive fields and set up a governance policy that blocks third-party export of restricted data. Map only hashed email or phone, as the destination requires, and schedule the export.

Treating consent and governance as part of the design, not an afterthought.

AJO is an application built natively on AEP. It uses Real-Time Customer Profile, AEP audiences, streaming events and data governance directly, without exporting data. On top of that it adds journey orchestration, campaigns, content authoring, decisioning and delivery across email, SMS, push, in-app, web and code-based channels.

Journeys are multi-step, individual orchestrations: each person enters on an event or audience and moves through waits, conditions and actions at their own pace. Campaigns deliver one piece of content to an audience in one go, either scheduled or API-triggered. Use journeys for lifecycle flows such as onboarding or cart recovery, and campaigns for newsletters, announcements and one-off sends.

Delegate a subdomain to Adobe (full delegation or CNAME), set up IP pools, and create an email channel configuration with sender name, from and reply-to addresses and headers. Set up permissions and test profiles, and make sure profiles have email addresses and consent. For a new sending domain, plan IP warming so volume ramps up gradually.

Give each brand its own delegated subdomain, and ideally its own IP pool, with matching channel configurations. Reputation then builds and can be damaged per brand, so one brand's poor list hygiene doesn't affect the others.

Subdomain delegation, PTR records and IP pools are set up at organisation level and shared across sandboxes. Channel configurations and the suppression and allow lists are managed per sandbox, so each sandbox needs its own configurations.

Export them as a CSV and bulk-upload them to the AJO suppression list, using the upload option in the suppression list UI or the suppression API, so those addresses are excluded from day one.

A unitary event is tied to one person through an identity, for example 'this customer abandoned a cart', and enters that person into the journey. A business event isn't tied to a profile, for example 'product back in stock' or 'flight delayed', and triggers the journey for an audience that's read at that moment.

Create an ExperienceEvent schema that includes the Orchestration eventID field group, and a Profile-enabled dataset. In AJO, define the event with that schema, choose the fields the journey will use, and pick the namespace and identity used to look up the profile. The event ID is system-generated, or you can use rule-based events that match on a condition on the payload.

Read Audience is batch-style: everyone in the audience when the journey runs enters it, once or on a recurring schedule. Audience Qualification listens in real time for people entering or exiting a streaming audience and enters each one as it happens. Choose based on whether the use case needs immediacy.

Turn off re-entrance in the journey properties, or allow it only after a re-entrance wait period that covers the duplicate window. Also fix the duplicate at source if you can, and for transactional flows add a condition that checks whether the action has already happened.

Usually one of these: the event's identity namespace doesn't match the journey's, or the profile doesn't exist with that identity; the payload doesn't match the event definition or rule; the journey isn't live or is in test mode, which only accepts test profiles; re-entrance blocked it; or a business rule or capping stopped it. Check the journey's step events and the profile in the viewer.

Use a business event that carries the tower ID, then read an audience of customers linked to that tower and send the message. The outage isn't about one person, so a unitary event doesn't fit.

It's an ExperienceEvent schema with the Orchestration eventID field group and a primary identity that isn't person-based (for example a product or tower ID). When defining the event in AJO, select the _id, eventID and timestamp fields.

Start with a unitary check-in event. Add a condition on loyalty membership and tier, and personalise with the guest's first name from the profile and the hotel location from the event's contextual data.

Use a Read Audience journey on a daily recurring schedule against the opted-in audience, so each run picks up everyone who qualifies at that moment, with re-entrance configured for recurring sends.

Make it a rule-based event with a condition on the product array, so only qualifying purchases trigger it, then add a condition activity that checks membership of the loyal-customer audience.

Wait (a duration or until a date), conditions (data source, time, percentage split or date), channel actions, reactions (opened, clicked) with a timeout, Jump to another journey, Update profile, and End. Custom actions call external systems.

Add a reaction event on the first email (opened) with a timeout, for example 2 days. People who open go down the reaction path. People who don't open hit the timeout path, where you send the follow-up or try another channel.

Exit criteria (in journey properties) remove people from a journey when a condition becomes true, for example a purchase event or leaving an audience. They stop you nudging someone to buy something they've already bought, and they keep journeys short and relevant.

Editing a live journey creates a new version. People already inside it continue in the version they entered, and new entrants go into the new version. That's why big structural changes need planning, and why you sometimes close the old version to new entrances while it drains.

When a decision needs data that isn't in Profile and must be current, such as loyalty points from a loyalty API or live inventory. You configure the data source and field groups in AJO, call it in conditions or personalisation, and apply capping rules so the external system isn't overloaded.

Paths are evaluated top to bottom and the first match wins. Put the most specific or most important path, such as VIP customers, at the top.

Give the event a timeout so the profile moves to a fallback path after a set time. Without one, it waits until the journey's global timeout and then leaves the journey.

Use a Wait activity with a custom formula, or a fixed date and time, that resolves to the next 9:00 AM, and take the profile's time zone into account if recipients span regions.

Formerly called a channel surface, it's a reusable preset with the channel's technical settings. For email that means subdomain, IP pool, sender name and address, reply-to and header settings. For push, the app configuration. For SMS, the provider and sender number. Messages pick a configuration, so marketers don't change deliverability settings each time.

With full delegation, Adobe hosts the DNS for the subdomain and manages records such as SPF, DKIM, DMARC and tracking. That's the recommended and quicker option. With CNAME, the client keeps DNS control and adds the records Adobe provides. It suits strict IT policies, but setup and changes take longer.

Mailbox providers trust new IPs and domains slowly. Sending full volume from day one risks throttling or the spam folder. A warm-up plan starts with small volumes to your most engaged recipients and increases over weeks while you watch bounces, complaints and inbox placement.

SMS uses a supported provider integration (such as Sinch, Twilio or Infobip) configured in AJO with credentials and sender numbers, plus keyword handling for opt-in and opt-out. Push needs the Adobe Experience Platform Mobile SDK in the app, push credentials (APNs and FCM) in an app configuration, and push tokens collected on the profile.

A channel that delivers a JSON or HTML payload to a placement in your own web page, app, kiosk or any client that calls AJO through the Edge Network. Developers render it. Use it when the experience isn't a standard email, SMS, push or in-app message, for example a personalised banner in a native app screen.

SMS URL shortening needs an SMS subdomain delegated and selected in the SMS channel configuration. Without it, the shortening helper can't generate links.

The tracking parameters are static. Set URL tracking in the channel configuration with dynamic values, such as journey, campaign or message name, so each send gets its own parameters automatically.

In the expression editor, using Handlebars-style syntax for profile attributes such as {{profile.person.name.firstName}}, contextual attributes from the triggering event (cart items, order ID), audience membership, and helper functions for formatting dates, numbers and strings.

Wrap personalised fields in conditions, for example {%#if profile.person.name.firstName%}Hi {{profile.person.name.firstName}}{%else%}Hi there{%/if%}, or use default values. Then preview with test profiles that have missing fields, so no one gets a blank or broken greeting.

Use the event's contextual attributes. In the expression editor, loop over the product array from the triggering event (an each helper) to render name, image, price and URL for each item, and preview with a sample event payload.

Fragments are reusable content blocks, such as a header, footer or legal disclaimer, that you author once and reference in many messages. Templates are reusable starting layouts. Both keep branding consistent, and updating a fragment updates every message that uses it.

Set up a content experiment on the message: create treatments (different subject lines or body content), choose the success metric (opens, clicks or a conversion) and the traffic split. Monitor the experiment report and roll out the winning treatment.

The dataset or schema isn't enabled for Profile, so the fields aren't in the union schema that AJO personalisation reads. Enable it and re-ingest, or check that the field is in a Profile-enabled schema of the same class.

Personalised offers carry content, eligibility rules, priority and constraints (dates, caps). A fallback offer is shown when nothing qualifies. Placements define where and in what format an offer appears, and collections group offers. A decision combines placements, an evaluation criterion and a ranking method to choose the best offer for each person.

By static priority, by a ranking formula (for example priority multiplied by a propensity score from the profile), or by an AI ranking model that learns from conversions. Eligibility rules always run first, so ranking only applies to offers the person qualifies for.

If a person doesn't qualify for any personalised offer, the placement would otherwise be empty or broken. The fallback guarantees something sensible always renders, such as a generic brand message.

Use capping on the offer: a limit on total impressions or acceptances, or a per-profile frequency limit over a period. Feed impression and acceptance events back into the platform so capping and AI ranking use real interaction data.

The dataset's schema needs the Experience Event – Proposition Interactions field group to record offer impressions and clicks. Add it, collect interaction data, and the dataset becomes selectable for the AI model.

An audience, a decision (offer activity) and an output dataset. The batch job writes each profile's chosen offers to the output dataset, which you then export to the delivery vendor.

A placement, a collection of personalised offers and a fallback offer. Eligibility rules and ranking are optional refinements.

A configured call from a journey to a third-party API, for example to create a CRM task, send through an external messaging provider or notify a loyalty system. You define the endpoint, method, authentication, headers and payload once, and marketers drop it into journeys and map journey or profile data into the payload.

Define the response payload in the custom action configuration. The response fields then become available in later conditions and personalisation. Also add the error and timeout path, so the journey handles an API that fails or responds slowly.

Use capping or throttling settings on the custom action endpoint to limit calls per second, agree the rate limits with the API owner, and test with realistic volumes. Batch-style entries such as Read Audience can create very large spikes.

Capping limits calls per period and rejects calls above the limit, which go down the error path. Throttling, set with the throttling API at organisation level for an endpoint, queues calls above the limit, for up to 6 hours, and processes them in order. Use throttling when no call can be lost.

Field names in the custom action payload can't contain a dot. Rename it, for example to addressStreet, or nest it as an object.

Use test mode with test profiles: trigger events, watch each profile's path through conditions and waits (you can shorten wait times in test mode), and check that messages arrive. For content, preview with test profiles and send proofs. Simulate edge cases before going live.

The journey's live report (recent activity) and global report (performance over time) show entries, exits, errors and message performance per node. Message reports show sends, deliveries, bounces, opens and clicks. For deeper analysis, step events and message feedback datasets are available in AEP and CJA.

Check the delivery and bounce reports, then the suppression list (earlier hard bounces or complaints), the sending domain's authentication (SPF, DKIM, DMARC), spam folder placement and IP reputation, and whether a business rule or consent condition excluded those profiles. Pick a few affected profiles and trace them through the step events.

The profile must be flagged as a test profile, the journey must use the matching namespace, and events must be fired from the test mode interface, not from an external API call. Remember the cap on test profiles per session, and that conditions take the top branch in test mode.

Query the journey step events dataset with Query Service, filtering on the journey version ID, the profile ID and the start node. Each entry is a separate row, so the count includes re-entries.

A list AJO maintains of addresses it must not email: hard bounces, soft bounces that keep failing after retries and spam complaints are added automatically, and you can add addresses manually. It protects sender reputation. In non-production sandboxes an allowlist can restrict sends to approved test addresses.

Through consent fields on the profile (for example email marketing consent) that are checked at send time for marketing messages, consent policies that enforce them automatically, and the unsubscribe links and headers included in marketing emails. Transactional messages are configured separately so they still reach customers.

Business rules limit how many messages a person receives from a channel or message category over a period, across all journeys and campaigns, for example no more than 3 marketing emails a week. Assign rule sets to messages so promotional sends are capped and transactional ones aren't.

Object-level access control now restricts the journey to roles that have that label. An administrator needs to add the label to your role, or remove it from the journey.

Action campaigns that are scheduled to an audience, such as a newsletter or announcement, and API-triggered campaigns that an external system starts by calling the API with a profile and contextual data. API-triggered campaigns can be marketing or transactional, such as an order confirmation or password reset.

When an external system already decides when to send and the message is a single, time-critical step with no orchestration, such as an OTP, order confirmation or password reset. A journey adds value only when there are waits, branches or several steps.

A subscription app wants a welcome flow that adapts to whether new users engage.

Enter on a unitary 'account created' event. Send a welcome email straight away, wait 2 days, then branch on engagement: users who opened or opened the app get a feature tips email, and the rest get a push nudge. Add an exit criterion on a 'first purchase' event so converters leave the journey. Disable re-entrance.

Clean branching logic, exit criteria and not over-messaging.

An e-commerce brand wants a reminder 1 hour after someone adds to cart without buying, showing the actual items.

Trigger on a cart-add event that carries the product details. Wait 1 hour, then check whether a purchase event arrived for that person; if not, send the email, using the triggering event's contextual attributes to render product names, images and prices. Apply a frequency rule so frequent shoppers aren't spammed, and exit anyone who purchases during the wait.

Use of event context in content and the purchase check before sending.

A retailer wants to notify everyone who asked for an alert when an out-of-stock product returns.

Send a business event 'product restocked' carrying the SKU. The journey reads an audience of people who registered interest in that SKU and sends an email or push with the product details. Remove those people from the interest list afterwards so they aren't notified twice.

Recognising this as a business-event pattern, not a unitary one.

A bank wants each customer's monthly email to show the single most relevant product offer.

Create offers for cards, loans and savings with eligibility rules, for example not already holding the product and meeting an income band, plus a fallback offer. Rank by priority or an AI model. Add an email placement and a decision, and insert the decision into the email template so each recipient sees one ranked, eligible offer.

Understanding eligibility vs ranking, and always having a fallback.

Adobe Analytics collects web and app data into report suites with props and eVars. CJA reports on datasets in AEP, so it can combine web, app, call-centre, CRM and offline data in any XDM schema, joined on a person ID. Configuration such as attribution and persistence is applied at report time in a data view, so changes are retroactive.

A connection links one or more AEP datasets from a sandbox into CJA: event, profile, lookup and summary datasets. Each event dataset must specify a person ID so data from different channels can be joined. You choose whether to backfill history and whether to import new data continuously.

A data view sits on top of a connection and defines how data is interpreted for reporting: which fields become dimensions and metrics, attribution and persistence settings, session definitions, time zone and filters. It's applied at query time, so you can create several data views on one connection and change settings retroactively.

Event datasets are time-series records such as page views, calls or orders. Profile datasets hold attributes joined to events on the person ID, such as loyalty tier. Lookup datasets join on a key field other than the person, for example SKU to product name and category.

Datasets join on a common person ID. Anonymous web events are often keyed by ECID while call-centre data uses a CRM ID, so stitching rekeys anonymous events to the known ID once a link is seen (field-based or graph-based). After stitching, a person's web visits and calls appear in the same journey.

Derived fields create new dimensions or metrics at report time from existing fields, using rule-based functions such as case-when, concatenate, regex replace, URL parse and lookups. Because they're applied in the data view, they work retroactively across all history.

Derived fields transform raw data into new components, usually dimensions such as a cleaned page name or channel. Calculated metrics combine existing metrics with maths, filters and functions, such as conversion rate or revenue per person.

Last touch, first touch, linear, participation, same touch, U-shaped, J-curve, inverse J, time decay, custom and algorithmic, each paired with a lookback window (session, person or custom). Attribution can be set per metric in a table or in the data view.

Freeform tables for breakdowns, Flow for paths, Fallout for drop-off in a sequence, Cohort tables for retention, and attribution panels for comparing models side by side.

CJA counts people rather than visitors, can use different session definitions and time zones, may filter bots or internal traffic differently in the data view, and includes other channels. Late-arriving data and stitching also change counts. Document the definitions rather than expecting a perfect match.

A telecom company wants to know how many customers call the contact centre within 24 hours of visiting a help page.

Ingest web events and call-centre logs with a shared CRM ID and stitch anonymous web data to it. Add both datasets to one CJA connection. Build a fallout or flow from 'help page viewed' to 'call received' with a 24-hour window, and break it down by help article.

Joining channels on one person ID and turning the result into an action list.

The team wants clean marketing-channel reporting, applied to all existing history.

Create a derived field with case-when rules on UTM parameters and referrers, use it as a dimension, and compare first-touch vs linear attribution for orders.

Using derived fields for retroactive logic, and reading attribution models critically.

Leadership wants to see how each AJO journey contributes to conversions.

Bring AJO's message feedback and journey step event datasets into a CJA connection alongside conversion events, report by journey and node, and use attribution to credit journeys for downstream purchases.

Connecting activation (AJO) with measurement (CJA) in one view.