The Adovo AEP Playbook

Plan, validate and operate customer data for reliable activation.

Your team agrees which customers should receive an offer. Delivering it depends on several further decisions: which data establishes eligibility, which identifier represents the customer, when that data becomes usable, and what the receiving channel needs. Adobe Experience Platform (AEP) brings those decisions together, but the team still has to define and validate the intended result.

Use this guide to take one customer-data use case from a business requirement to a supported launch decision. Business owners can use the decisions and review questions in each chapter. Practitioners can follow the configuration checks and complete the same workbook with evidence. When an implementation behaves unexpectedly, start with the symptom index.

The chapters focus on B2C customer records and events, Profile and audience readiness, and a bounded consumer handoff. Use the linked product guidance for the exact source, connector and entitlement in your implementation.

The running example is a fictional retailer. Its customers, settings and timestamps are illustrative. The acceptance cases describe expected behavior to test in your own sandbox, rather than results from an Adovo customer implementation.

Choose your path

If you own the business outcome, begin with the decision brief, then read the opening decision and closing review in each chapter. Use the readiness record to agree scope and unresolved conditions with your technical owner.

If you build or operate AEP, work through the chapters and attach the evidence behind each decision. Keep the business deadline visible as you investigate: a configuration can work correctly while delivering too late for the use case.

• Business decision brief
• Find a starting point by symptom
• The running retail example
• 1. Define the outcome and required data
• 2. Prove what arrived and became usable
• 3. Make customer identity explicit
• 4. Explain the profile you are using
• 5. Test audience timing against the deadline
• 6. Confirm the receiving channel can act
• 7. Launch, change and operate with named owners
• Shared workbook
• Glossary
• Further reading

Explore the Adobe playbooks

All four playbooks | Business owners | Decision makers | Practitioners

Related guides: AJO · Real-Time CDP · Audience Manager

Start with the decision the business needs to make

Before adding another source or audience, complete this sentence: we want a defined group of customers to receive a defined treatment under defined conditions, by a deadline that matters to the use case. Name the person accountable for that outcome.

A useful brief answers questions a sponsor can review without opening the schema editor:

• What customer or operational problem are we addressing, and what happens today?
• Which customers are eligible, which must be excluded, and who owns those rules?
• When must the channel act, and how old can each input be at that moment?
• What evidence would show that the delivery works, and what separate measure would show business value?
• What is the smallest useful scope, and what additional work does a wider rollout require?
• Who owns source quality, implementation, channel delivery and the final launch decision?

Compare the proposed use case with the current process and a narrower pilot. A pilot limited to a known customer population and one channel can answer a useful delivery question. It does not establish that the same design will work across every identity, geography or channel. Write down the differences before anyone treats pilot approval as approval for a wider launch.

Estimate implementation effort and continuing operating cost separately. Include source-system work, identity design, receiving-platform setup, monitoring, exception handling and the staff time needed to maintain them. Confirm relevant product entitlements and permissions with the platform owner. Record benefits and costs as assumptions until there is evidence behind them; a platform capability is not a financial forecast.

Use three readiness decisions. Ready means the agreed mandatory criteria have supporting evidence for the stated scope. Ready with agreed conditions means the owner accepts a specific, bounded limitation with an accountable action and review date. Hold means a necessary requirement is unmet or the evidence cannot support the proposed launch. A condition cannot make a mandatory exclusion optional.

Keep delivery and value separate in the review. A timely audience and a successful receiving-side check show that the implementation met its delivery requirements. To claim an improvement in response, conversion or another business outcome, define that measure, its baseline and an appropriate evaluation approach. Where the question is incremental benefit, consider a suitable comparison or holdout and the factors that could bias it.

Complete the business brief and options record before committing to a design. The team can change the brief when it learns more, but the change should be visible to the people funding and operating the use case.

Find your starting point

• The first source load works, but subsequent updates do not arrive: start with incremental ingestion. Capture the source change, watermark and run cutoff.
• Data is queryable, but the expected profile is absent: inspect ingestion evidence, then the actual identities.
• A known customer has an unexpected attribute value: compare the source fragments and selected policy in profile reconciliation.
• A field exists in Profile but not in a snapshot: check the snapshot's policy, field path and observation time in Chapter 4.
• A shared browser links different customers: review the business identity rules and graph settings in Chapter 3.
• An audience estimate is nonzero, but qualified membership is zero: inspect the actual evaluation and rule inputs in Chapter 5.
• A customer leaves an audience without another attribute update: inspect the event window and membership timeline in Chapter 5.
• A connection succeeds, but the export excludes identities: inspect mappings, connector requirements and applicable consent in Chapter 6.
• A customer is qualified in AEP, but Target returns no expected decision: compare the request-time identities and Edge state in Chapter 6.
• A schema or cleanup change threatens working consumers: build the dependency and migration record in Chapter 7.

Choose the route from an observation. An error label or a familiar symptom is a starting point for investigation, not proof that the previous repair applies.

The running example: a member offer

The fictional retailer wants to show an offer to members whose current tier is eligible and who have recently viewed a relevant product category. Its membership team owns tier status. Its web team owns browsing events. Its channel team owns how and where an offer is presented.

There are two business options. A next-visit offer can be useful even if the membership input is refreshed on a schedule. A same-session offer requires the relevant identity and eligibility evidence to be available when the channel makes its decision. The second option needs its own validation; it is not obtained merely by renaming the audience or calling the source real time.

For the examples, the retailer uses a stable customer identifier, a scheduled CRM feed and website events collected through Web SDK. A receiving channel checks the intended identity and eligibility result. SFMC and Target appear later as distinct integration examples; choose the supported channel and entitlements available to your own implementation.

Use these synthetic customer states when testing:

• R01 is a known member with a valid customer identifier and an ordinary qualifying event.
• R02 has a source record whose identity payload is invalid for the configured ingestion path.
• R03 has two source updates on one calendar date, followed by a late-arriving change.
• R04 has conflicting tier values in two contributing datasets.
• R05 signs in on a browser that another member also uses.
• R06 changes an email address while retaining the stable customer identifier.
• R07 has a newly populated field that must be reconciled between live Profile and a snapshot.
• R08 has valid audience membership but lacks a required receiving-side identity mapping.

Treat these as starting states. Define the configuration and expected outcome of each individual test before running it. In particular, do not use R05 and R06 to assume that every organization should enforce one email address per person, or use R08 to assume that every exclusion is a mapping error.

What to observe across the implementation

The source system records a business fact. An ingestion path receives and processes it. Depending on the configuration, the data contributes to the data lake, Identity Service and Real-Time Customer Profile. A merge policy determines the assembled Profile view. Audience evaluation determines membership, and the consumer has its own receiving and decision behavior.

These are distinct observations. They do not imply that every path writes to the services in one fixed order. Keep the data lake and Profile as separate evidence surfaces. Querying a stored row establishes something different from looking up a profile or inspecting a channel response.

Record each observation with the relevant identifier and UTC timestamp. Specify whether a count means rows, events, identity values, profile fragments, merged profiles, qualified members or exported records. Different units should not be reconciled as if they were interchangeable.

1. Define the outcome and required data

Decide what is worth delivering first

The business owner needs to choose a useful treatment and an achievable deadline. A requirement such as use our customer data for personalization leaves too many decisions unresolved. A requirement that names the eligible members, necessary tier status, browsing condition, channel and deadline can be tested.

For the retailer, ask whether a recently changed tier must affect the very next page, the next visit or the next scheduled campaign. Ask what should happen if the tier is unknown. Should the channel show a general offer, show nothing, or wait? That fallback is part of the customer experience and should have an owner.

Select the pilot population deliberately. A known-member pilot might exclude anonymous visitors while the team proves the required behavior. Record the exclusion and what must change before expanding it. The business owner should understand whose experience the pilot establishes and whose it leaves untested.

Translate the outcome into a data contract

A data contract states which inputs are needed, what they mean and what behavior depends on them. For each input, record its source owner, identifier, type, update method, allowed age and treatment when missing or invalid. Connect it to a specific rule or receiving field so that an optional convenience does not silently become a launch dependency.

Separate durable record attributes from events. In the example, current membership tier is a record attribute. Viewing a product category is an event with a time and context. An event containing a tier value does not by itself define how the current tier attribute should be maintained. Choose the record-ingestion path that supports that requirement.

Adobe's schema composition guidance distinguishes record and time-series behavior. Use the appropriate schema class and plan identity fields before data arrives. The field structure also needs to accommodate foreseeable evolution; changing an in-use field's type can require a migration rather than an editor adjustment.

A community discussion about Web SDK schemas moves from collecting an event to finding it on a profile and then exporting to a destination. The useful distinction is that these are separate requirements. Establishing one does not complete the other two.

Define acceptance before configuration

Write acceptance criteria in terms a business and technical owner can both review. For example, R01's approved tier must be available to the chosen audience under the named merge policy before the specified decision opportunity. The receiving channel must be able to identify R01 and apply the intended treatment. An excluded synthetic customer must remain excluded.

Add negative and boundary cases. Include a missing customer ID, an old event, conflicting source attributes and a customer outside the pilot scope. Specify the expected fallback for each. A baseline success case cannot establish what happens when the input is incomplete or the customer relationship is ambiguous.

Avoid an unexplained coverage target. Define the denominator, legitimate exclusions and observation period. Coverage of the eligible pilot population is different from coverage of every customer in the source system. A requirement to account for every intended record can coexist with a smaller reachable audience when exclusions are explicit and approved.

Put the work and ownership beside the choice

For each option, identify required source changes, platform configuration, channel work and operating support. Confirm that the people who own those dependencies accept the work. A sponsor should be able to see why the same-session option demands more than a scheduled member update without having to interpret the implementation payload.

Keep the estimate revisable. If identity design or a source's update behavior is uncertain, make that the next validation task with an owner. Do not hide it inside an optimistic delivery date. The team can approve a discovery step without approving the complete rollout.

Review before moving on

The business owner approves the use case, pilot scope, fallback and acceptance criteria. The technical owner confirms that the required inputs and supported paths are identified. Record unresolved dependencies in the configuration record and complete the business brief. Move forward when the team can explain what it intends to prove.

2. Prove what arrived and became usable

Decide whether the source can meet the promise

A successful source run is useful, but the business question is whether the intended data became usable for the agreed population and deadline. A missing update can change eligibility. A rejected identity can remove a customer from reach. Before choosing a replay or a new connector, establish the first observation that differs from expectation.

Start with R01 and one distinctive changed value. Record the source identifier, source change time, dataset, flow run and batch where applicable. Find the corresponding Profile observation under the intended identity. Repeat with R02 so that the process can explain failure as well as success.

Confirm that the intended schema and dataset are configured to contribute to Profile for this path. Record when the relevant settings were enabled and whether the records under investigation arrived before or after that point. If historical data needs processing again, choose a supported, bounded recovery rather than assuming that a current toggle establishes what happened to an earlier load.

Reconcile the stages with named units

For the selected run, collect the source cutoff, records expected for that scope, records received, accepted and rejected, and the relevant Profile processing evidence. Label every metric with its unit and time range. Keep an unaccounted difference open until the team can explain it.

The ingestion monitoring guidance exposes observations about received data and Profile processing. Inspect the relevant stage rather than relying on a single success label. An HTTP response accepting a batch for processing is also different from a terminal processing result, as described in batch ingestion troubleshooting.

Do not compare source rows directly with merged profile totals and call the difference missing customers. Several records can contribute to one profile, and one source row can fail to contribute to the expected identity. Reconcile the scoped source records first, then inspect the intended profile set using the identity rules in the next chapter.

Separate parsing from identity and Profile errors

Inspect the actual error and a representative failed record. A file-format failure calls for a different change from an invalid XDM value or an unusable identity. Preserve the failing input and configuration so that a later success can be attributed to a specific change.

In a JSON versus JSONL discussion, the same logical record worked through a UI upload when represented as a single line. The API has a separate multiline JSON option. For that API path, Adobe documents isMultiLineJson under the batch input format at creation. Choose the supported representation for the actual path; do not apply the UI observation as a ban on every multiline payload.

A second HTTP-source discussion provides a more revealing sequence. The author could query records, then supplied an identity error and payload details. They later reported success after removing the identityMap section and retaining the configured email identity. That outcome concerns that schema and path. Web SDK identity handling has different requirements, covered in Chapter 3.

Account for partial failures

Partial ingestion can accept valid data while separating invalid records, subject to its configured threshold. Record whether diagnostics and partial ingestion were enabled, which records failed and what the errors establish. Use Adobe's partial batch ingestion guidance for the selected workflow.

If the team has UI-only access, confirm what that workflow and role expose before promising a failed-record download. An aggregate error count is not the rejected record itself. If the required diagnostic evidence needs API access, identify the person authorized to retrieve it and retain a redacted copy with the investigation.

For a launch decision, explain the affected population and consequence. An accepted error threshold is a processing setting; it does not determine whether the business can tolerate the omitted customers. The owner must review that gap against the use case's acceptance criteria.

Test incremental ingestion independently of the first load

R03 has two changes on one calendar date and a later arrival for an earlier business time. Use those states to test the source's delta selection. Record the actual watermark field, supported type, precision, timezone, run boundary and handling of equal values. Distinguish the time the business fact occurred from the value used to select the next increment.

In a Snowflake incremental-load discussion, the author reported that changing the delta-column timestamp format enabled later ingestion. That is evidence for the reported case. The Snowflake source documentation also identifies UTC and TIMESTAMP_NTZ prerequisites. Check the chosen connector's rules before changing filters or recreating a flow.

Retain a source extract or equivalent query result for each test run. If there is no source change inside the connector's selected range, an empty increment may be correct. If an expected change sits outside that range, the next decision concerns the source or selection contract rather than Profile repair.

Choose a bounded recovery

Before replaying data, identify the failed scope, the destination datasets and consumers, and how this path handles repeated records or events. Preserve source event identifiers and business timestamps as required by the design. Confirm supported update or deduplication behavior rather than assuming that every replay is harmless.

The business owner reviews missing coverage and deadline impact. The technical owner chooses the smallest supported recovery and repeats the affected acceptance cases. Complete the ingestion ledger, including what remains unaccounted for, before declaring the source ready.

3. Make customer identity explicit

Agree what represents a customer

Business owners need to decide which real-world relationship the implementation represents. A browser, a person and an account are different things. Two members can use one device; one member can have several email addresses. State which relationships the offer is allowed to use before configuring identity behavior.

In the retail example, the membership system owns a stable customer ID. An email address is a contact detail that can change. A browser identifier helps associate activity with a device context. The business owner must decide when the offer requires a known member and what an anonymous visitor should see.

Write down who can change the identifying values and whether they can be reassigned. A namespace is the category of an identifier, such as the retailer's customer ID; its value identifies a particular record within that category. Matching a string without its namespace is insufficient to define the intended customer relationship.

Inspect what is actually sent

For R01, inspect the outbound identity payload and the resulting observations. Check the namespace code, actual value, authentication state and applicable primary identity. Record the schema and dataset configuration as well as what the application intended to send. A diagram of the desired mapping cannot show whether a placeholder key or empty value was transmitted.

For Web SDK collection, Adobe's identityMap guidance describes namespace-keyed arrays containing the identity value and related settings. The Edge Network supplies ECID automatically. When sending a known person identity, configure it according to the documented collection behavior; do not fabricate a second ECID mapping just to make the payload look complete.

The community question about identityMap and custom ECID fields includes both anonymous and signed-in cases. The practical check is to capture each case. Verify what is sent before login, on the first authenticated request, after login and after logout. Remove stale application-side identity state according to the supported implementation when the visitor changes.

R02's invalid HTTP-source example belongs in the same evidence record, but it does not establish the Web SDK payload design. A configured record identity and an event identityMap can enter through different paths. Fix the observed contract rather than applying one payload change everywhere.

Distinguish the outgoing flag from Profile identity settings

The primary identity setting in a request and the rules for storing a Profile fragment are not always the same control. Adobe's namespace-priority guidance explains that, when identity settings are configured, namespace priority determines the primary identity of ExperienceEvent fragments in Real-Time Customer Profile. Profile records continue to use their schema identity configuration. Other consuming services can still use the request's primary setting.

Record both configurations. If a team changes only a request flag and expects every Profile and channel behavior to change together, its test may answer the wrong question. Trace the event into the intended fragment and separately inspect the receiving service.

For the business owner, this distinction matters when the same customer appears reachable in one view and absent in another. Ask the technical owner to identify the actual customer ID used at each required boundary. A general statement that stitching is working is too broad to approve a particular treatment.

Test shared-device behavior before extending reach

R05 uses the same browser as another member. Test the identity events for both members, including the transition between them. State the expected associations before sending the sequence. An implementation that succeeds for one person on one browser has not yet established this behavior.

Adobe's Identity Graph Linking Rules provide unique-namespace and priority controls for graph behavior. Choose them according to the organization's actual person and identifier relationships, and use graph simulation to examine the proposed settings. The older shared-browser community discussion describes an interim approach; it should not determine the current configuration.

Do not mark a namespace unique simply because the setting sounds desirable. If the business legitimately allows multiple values of that namespace for one person, the constraint may conflict with the intended relationship. Conversely, an identifier that is shared across people should not silently become proof that those people are the same customer.

Record any difference between the simulated graph and the observed Profile or consumer behavior. Graph configuration, fragment storage and downstream lookups need their own observations. Keep expansion to shared-device or anonymous populations conditional on the relevant acceptance cases.

Handle changed identifiers as a defined lifecycle

R06 changes email while retaining the stable customer ID. Decide whether the old address remains valid for contact, whether it remains useful as an identity, and which system owns that decision. Updating an attribute is not a request to delete the previous identifier everywhere.

The discussion about old email and phone identities distinguishes graph-link constraints from broader deletion. Use supported identity settings for the relationship the business intends. If records must be removed, select the lifecycle operation by its purpose and affected stores, as described in Chapter 7.

Keep prevention and repair separate. New settings and a clean sequence do not prove that all historical associations have been corrected. For existing problematic graphs, document the affected scope and follow the supported remediation or Adobe Support route. Retain the downstream dependencies before making changes.

Review before moving on

The business owner approves the meaning of a customer, the allowed relationships and the fallback for unknown or ambiguous cases. The technical owner provides the payload, graph, fragment and receiving-side evidence relevant to that scope. Record these decisions in the configuration record. A wider population needs its own identity cases, not an assumption that the pilot's relationships generalize.

4. Explain the profile you are using

Decide which source the business trusts

R04 is Gold in the membership system and Silver in a second contributing dataset. Both values may be valid records of what those sources supplied. The business still needs a rule for which one governs the offer and who resolves an unexpected conflict.

Assign an owner to each decision-driving attribute. Ask which source is authoritative, how quickly it updates and what should happen when that source is missing a value. A preference for the newest-looking value can be wrong when a late replay contains older business information.

Separate identity links from attribute selection

Identity links help establish which fragments can belong together. A merge policy determines how data is combined and prioritized for the assembled Profile view. Use Adobe's merge-policy overview to distinguish dataset precedence from timestamp ordering.

Dataset precedence gives priority according to the selected datasets and their order. Timestamp ordering uses the system ingestion timestamp described in the documentation, rather than automatically using the source's business-effective date. Record which policy is used by the lookup and audience involved in the case. A screenshot from another policy does not establish the value the consumer used.

For R04, preserve both source fragments and their observations before changing anything. If the approved policy intentionally selects the membership-system tier, explain why an alternative fragment does not win. If a late ingestion changes the observed value under another policy, compare that behavior with the approved source-of-truth rule.

Test missing values as distinct cases

Do not combine absent fields, explicit nulls and empty strings in one test labelled blank. They can originate differently and pass through different source or mapping behavior. Define the precise input and desired business treatment for each.

The dataset-precedence discussion contains conflicting observations about missing or null values. Use a controlled comparison in your configuration instead of selecting the most convenient explanation. Preserve the source payloads, ingestion order, policy and output for each variant.

A useful test changes one condition at a time. Begin with two explicit conflicting values. Then test an absent field, a null and an empty string using the supported source path. Compare the actual assembled value with the owner-approved expectation. If the required survivorship rule cannot be represented by the selected design, return to the source transformation or data contract rather than silently substituting another rule.

Do not alter a shared default policy just to see whether an attribute changes. Use a controlled environment or otherwise isolated supported test. Identify the audiences and consumers that depend on a policy before proposing a production change.

Compare a live lookup with the right snapshot

Query Service queries data-lake datasets. A profile attribute snapshot available there is a separate observation from a live Profile lookup. Adobe's dashboard dataset guidance describes the mapping from active merge policies to their profile attribute datasets through adwh_dim_merge_policies. Resolve that mapping rather than selecting a familiar-looking snapshot name.

The Profiles dashboard guidance describes a daily snapshot of record attributes, without event data. Record the snapshot observation time and scope before comparing it with a changed profile. A difference between an earlier snapshot and a later lookup may be explained by when they were observed.

The community question about querying the unified profile store illustrates why this distinction matters. A query over a snapshot can help investigate the intended profile population, but it is not a direct SQL query over live Profile. Use the supported Profile lookup for the live identity-level question and the correctly scoped dataset for the snapshot question.

Investigate a field that remains absent

R07 has a value in the source and live Profile, but the expected snapshot field is absent. Check the exact field path and type, identity, policy-to-dataset mapping, relevant processing state and observation times. Determine whether the problem affects one identity or the field across the scoped population. Keep source and output examples with the queries or lookups that produced them.

In a missing snapshot-field discussion, the author ruled out recency and additional merge policies, then reported that Adobe Support recreated the snapshot from the backend. This is a useful escalation example. It does not mean that every missing field requires a rebuild, or that a customer should edit a system-generated snapshot schema.

Prepare an escalation that establishes the disagreement: sandbox, dataset and policy IDs, field path, one controlled identity, relevant run times, redacted input and observed outputs. Explain the business impact and affected scope. Distinguish a hypothesis from what the evidence actually rules out.

Review before moving on

The business owner approves the source-of-truth rule and understands unresolved differences that affect eligibility or reporting. The technical owner can show which Profile view was used, why its value was selected and how a snapshot comparison was scoped. Complete the profile reconciliation sheet. Keep a persistent unexplained discrepancy open in the readiness decision even when individual jobs show success.

5. Test audience timing against the deadline

Choose the delay the use case can tolerate

An audience defines who qualifies, but the business also needs to specify when a change should take effect. The retailer's next-visit offer and same-session offer have different requirements. If current membership data arrives on a schedule, the owner must decide whether the resulting eligibility delay is acceptable or whether the source and use case need redesign.

Define both entry and exit expectations. A newly eligible member should become reachable within the agreed requirement. A member who no longer qualifies should also stop receiving the treatment within its required interval. Give the channel an explicit fallback when fresh eligibility cannot be established.

Record the method the audience actually uses

Capture the audience ID, saved rule, merge policy, evaluation method and source ingestion mix. Check whether upgraded streaming capabilities apply. Adobe's eligibility criteria update describes conditions involving batch-ingested profile data and mixed ingestion. It also explains that existing streaming or Edge definitions can be affected when edited.

Do not assume that a previously working audience retains the same timing after a rule change. Inspect the resulting method and warnings, then repeat the relevant acceptance cases. Keep the previous definition and approved deadline available for comparison.

The streaming segmentation guide describes eligibility prerequisites, including the applicable merge-policy configuration. Use the rules for your implementation. Setting a method in an editor or API request does not by itself establish that the complete rule and ingestion path support the intended behavior.

Treat estimates and qualification separately

An audience estimate is useful during planning, but it is a different observation from membership produced by evaluation. The community case with an estimate of three and qualified size zero concerns a published batch audience. Its publication state alone does not show that the relevant evaluation has completed.

Inspect the intended evaluation job and a controlled profile's inputs. If a completed evaluation still disagrees with expectation, check the rule, data availability, policy and job scope. Avoid prescribing a fixed wait as the answer to every zero count. The business owner needs to know whether the audience is waiting for the intended job, failing a condition, or affected by an unexplained discrepancy.

Record qualified membership at the identity level when investigating a particular customer. A total count can change for unrelated people while the test customer's outcome remains wrong. Use both aggregate reconciliation and controlled identities for their respective questions.

Build the timeline using actual observations

Imagine the retailer's scheduled evaluation begins at 09:00 UTC and a required CRM update becomes usable at 09:05 UTC. Those illustrative times establish a dependency to investigate. They do not establish which later job will include the update or when a channel can use it. Capture the actual job and receiving observations.

The discussion about batch uploads and streaming audiences shows why moving a shared schedule is not always a sufficient answer. Other sources and consumers may depend on that schedule. Compare the supported alternatives against the whole use case: change source delivery, accept a scheduled outcome, narrow the pilot, or use supported ad-hoc operations within the relevant entitlements and limits.

Keep evaluation and activation separate if considering an ad-hoc path. A completed evaluation is not proof that a destination export, Edge decision or journey entry occurred. Verify each operation and its prerequisites through the relevant current documentation before adding it to the operating process. Adovo's audience freshness guide provides a fuller reconciliation of those timing boundaries.

Exercise a time-window audience deliberately

The community time-window discussion combines a profile condition with an event in a ten-minute lookback. It is useful for designing a test of qualification, expiry and requalification. It does not make the retailer's scheduled CRM plus web-event rule automatically eligible for streaming.

Create a supported fixture under the actual sandbox configuration. Record how each input arrives and confirm the saved evaluation method. Test event-first and attribute-first arrival, a qualifying event that ages beyond the window, and a subsequent qualifying event. Retain both event timestamps and the times membership is observed.

When a rule requires a profile condition and a recent event, both conditions matter. An unchanged attribute does not keep the event recent. Adobe's segmentation FAQ distinguishes event-window expiry from attribute-driven changes. Compare the observed transition with the relevant method and processing behavior; a ten-minute lookback is not a promise that every downstream observation changes at the exact tenth minute.

Include a late event and a controlled requalification case. Establish whether the source event time, arrival time and applicable eligibility rules allow the event to affect the intended decision. Do not silently move the timestamp to make a test succeed.

Review before moving on

The business owner accepts the tested entry and exit behavior for the selected scope and deadline. The technical owner provides the rule version, method, relevant job and membership timeline. Complete the audience record. If the observed timing cannot meet the offer's deadline, record a design or scope change rather than approving the original promise with an unexplained buffer.

6. Confirm the receiving channel can act

Define success at the receiving side

The business outcome depends on what the channel can do with the data. An audience available in AEP may still lack an identifier required by the receiver, arrive after the decision opportunity, or be correctly excluded by consent requirements. Define the receiving-side success condition before enabling the treatment.

For the retail pilot, specify what identifies the member at the receiver, which fields or membership state it needs, and how the team will observe the result. Name the channel owner. If the intended outcome is an offer displayed on a website, an export status alone cannot establish that it was displayed.

Validate the exact connector and mapping

R08 has valid membership but lacks the required destination identity mapping. Capture the exact connector type, connection and dataflow IDs, activation settings, required mapping and redacted receiving response. A similarly named connector can use a different delivery mechanism and identifier contract.

In the SFMC exclusion discussion, the error described missing consent. After checking the policy explanation, the author reported that selecting the required namespace mapping rather than an attribute fixed the case. The API Salesforce Marketing Cloud documentation distinguishes required identity and attribute mappings for that streaming connector.

Use the case to justify inspecting the mapping and applicable policies separately. It does not show that consent errors are generally misleading. Keep a genuine consent exclusion as a negative acceptance test, and have the appropriate owner explain why it should remain excluded. Clearing an error is not a reason to weaken a policy.

If the supported receiving interface provides acknowledgments, rejected records or an inspectable contact or audience state, preserve that evidence for the controlled identity. Where it cannot provide a particular observation, document that limitation and select another supported validation method before claiming the receiving step succeeded.

Separate Hub membership from an Edge decision

For a web-personalization path, inspect the request that actually asked for the experience. A Profile view in the central platform, often called the Hub, is not proof of the state available at the Edge when that request was processed.

The fresh-browser Target discussion describes a new ECID associated with a qualified customer, followed by an empty decision response until another qualifying action. The author confirms the primary identity configuration but does not report a verified final repair.

Adobe's known-customer personalization blueprint explains relevant first-login identity and availability considerations. Capture the anonymous request, login transition, first authenticated personalization request and a subsequent request. For each, record the actual identifiers, datastream, audience configuration and decision response. Check the intended activity and rendering separately after a decision is returned.

Do not use a successful QA experience as the only proof of live eligibility. The test must exercise the audience and identity path the customer will use. Likewise, an arbitrary browser delay cannot establish the cause of an availability problem. Use supported tracing, such as the relevant Assurance workflow, to compare failing and succeeding requests.

Adovo's Target timing investigation extends this request-level comparison. Once the selected audience and identity are available to a journey, the AJO playbook covers journey-entry design and acceptance. Keep those consumer checks connected to the same business requirement.

Review before moving on

The business owner reviews who can be reached, who is excluded and what happens when the channel cannot make the intended decision. The channel and technical owners supply the mapping, relevant policy evidence and receiving-side result. Complete the consumer record. Keep a missing receiving observation open; successful upstream jobs cannot resolve it by inference.

7. Launch, change and operate with named owners

Make the launch decision about a defined scope

Bring the business brief, acceptance cases and unresolved gaps together. The approver needs to see the agreed treatment, intended customers, observed delivery behavior, necessary exclusions and operating ownership. A launch date does not replace this evidence.

For each mandatory criterion, link the observation that establishes it and identify any conflicting result. Use ready, ready with agreed conditions or hold for the stated scope. A restricted pilot can be ready even when expansion needs further work, provided the restriction is real, enforceable and visible to the business owner.

If the evidence does not establish that the intended customers can receive the offer in time, choose a supported change: alter the deadline, narrow the population, revise the treatment or address the dependency. Record the decision and who is responsible for the next step. Do not describe a material reduction in scope as successful delivery of the original requirement.

Treat schema and rule changes as changes to behavior

In a community question about an in-use field type, the desired edit becomes a migration problem. A new field can affect source mappings, profile logic, audiences, queries and receiving mappings. Inventory the dependencies before choosing the replacement and load strategy.

Record the old and proposed contracts, the affected writers and readers, and the expected differences. Test representative records through both designs where practical. Decide how historical data is handled, how to distinguish an old value from a new one, and when each consumer changes. Assign an owner to every cutover step.

Keep rollback limits explicit. Redirecting a writer back to an earlier field does not automatically reverse every identity link, membership change or downstream action already produced. Preserve the evidence needed to reconcile the transition, and identify which consequences need a compensating action rather than a simple configuration reversal.

Audience edits deserve the same review. Inspect the resulting evaluation method and compare entry and exit timing with the original requirement. The audience-edit validation guide provides a focused version of that check. Reuse the controlled customers rather than judging the change from an aggregate count alone.

Choose cleanup by its purpose and affected stores

Operational cleanup, identity-link management and a regulatory data-subject request are different tasks. Adobe's lifecycle capability guide explains the supported options and their scope. Use Privacy Service for the applicable regulatory request. Select operational record deletion, retention or expiration according to the intended data-management task and available entitlements.

Identify the exact operation before predicting the result. Name the target identities or dataset, affected services, processing status and expected verification. Removing data from one evidence surface does not by itself establish that all other copies or associations are gone. Prevent unwanted re-ingestion by including the source system in the plan where necessary.

The community question comparing CCPA requests with record deletion contains a later question about identifier reuse without a resolved answer. Do not turn an earlier accepted explanation into a promise of permanent suppression or a general re-registration rule. Establish the supported behavior for the operation and the current source of the identifier.

For identity repair, inventory the writers and consumers first. A discussion involving many journey writers shows how a local cleanup proposal can create a much larger migration. The discussion's conflicting suggestions are not an unstitch recipe. Choose supported remediation with the relevant owner or Adobe Support and validate the resulting associations.

Make ongoing operation affordable and observable

Assign ownership for source delivery, identity settings, Profile reconciliation, audiences, the receiving channel and business acceptance. Include the time needed to investigate exceptions and maintain references in the operating estimate. A solution that depends on an unnamed person checking several screens every day has an unresolved operating dependency.

Define freshness from the source fact or update relevant to the use case to the point where the receiver can use it. Record the separate processing intervals so that a delay can be located. Agree which deviations require action, who responds and which treatment applies while the data is unavailable or stale.

Monitor unexpected population changes alongside failures. A job can finish while processing the wrong scope or no new increment. An audience can retain members longer than the business intended. Review controlled identities and scoped set comparisons when the observed behavior changes.

Set review triggers around source, schema, identity, audience-method and connector changes, as well as relevant product updates. Repeat the affected acceptance cases and retain the previous result. A review date is useful when it leads to an accountable check of a specific contract.

Close the business and delivery reviews separately

The delivery review asks whether the implementation met the agreed population, freshness, exclusion and receiving criteria. The business review asks whether the treatment improved the chosen outcome compared with its baseline or comparison. A healthy delivery path can support a use case that produces little benefit; that finding should inform investment and scope.

Complete the change and operations record and readiness decision. The business approver owns the scope and accepted limitations. Technical and channel owners own the supporting evidence and operating actions. Reopen the decision when those conditions change.

Shared workbook

Use one record per use case and a linked investigation per observed discrepancy. Keep customer identifiers masked in material shared outside the authorized working environment, while retaining a controlled way for the responsible team to reproduce the lookup. Link evidence to a specific configuration version and observation time.

Complete these sections as the work progresses. Record the observation after running each acceptance case. When a result differs from expectation, preserve both and explain the next investigation or decision. A later successful run should not overwrite the earlier failure record.

Business brief and data contract

Write the outcome and treatment in a short paragraph a business owner can approve. Then record:

• Business owner, technical owner, channel owner and intended approver.
• Customer population, eligibility rule, exclusions and fallback treatment.
• Current process and the problem the proposed use case addresses.
• Business deadline, maximum acceptable age of each required input and coverage criteria.
• Outcome measure, baseline, evaluation approach and relevant limitations.
• Required attributes and events, their source owners, identifying fields and meanings.
• Missing or invalid input behavior, including who approves an exception.
• Mandatory delivery criteria and the evidence required to accept each.

For the retailer, state whether the offer is intended for the next visit or the same session. Include who owns tier status and what the channel should do when that status is unavailable. Keep that paragraph beside every later configuration decision.

Options and delivery assumptions

Compare the current process, a restricted pilot and the proposed wider rollout using the same requirements. For each option, record:

• Customer and channel scope, expected benefit and the evidence behind that expectation.
• Source, identity, platform and channel work, with the owner of each dependency.
• Implementation effort, continuing operating effort and applicable product or service costs.
• Entitlements and permissions requiring confirmation.
• Assumptions about source delivery, customer reach, exclusions and measurement.
• What the pilot can establish and what remains untested for expansion.
• Next decision, person responsible and the evidence needed by that decision.

Use comparable units and periods for costs. Separate an estimate from a committed resource or observed expense. If an expected benefit is still a hypothesis, identify how the organization will evaluate it instead of inserting an unsupported financial return.

Configuration and identity specification

Record the sandbox and configuration used for each acceptance run:

• Schema IDs, classes, relevant field paths and dataset IDs.
• Source, connection, dataflow and datastream IDs where applicable.
• Identifier namespaces, stable customer key, valid relationships and source ownership.
• Actual anonymous, authenticated, logout and changed-customer payloads.
• Unique-namespace and priority settings, their business rationale and simulation evidence.
• Profile-record identity configuration and relevant ExperienceEvent fragment observations.
• Merge policy ID, selected datasets and precedence or ordering method.
• Audience definition/version, actual evaluation method and applicable capability settings.
• Consumer type, connection, identity requirements and mapping version.

Attach the shared-device and changed-email expectations before running R05 and R06. Record graph, Profile and consumer observations separately. Keep historical remediation as a named task if the tested settings do not establish the state of existing associations.

Ingestion and recovery ledger

For a selected source change and run, record:

• Source change time, business-effective time, selected cutoff and source query or extract.
• Watermark field, type, precision, timezone and relevant tie/late-arrival behavior.
• Dataflow run, batch and dataset IDs, processing state and observation times.
• Expected, received, accepted and rejected counts, with a defined scope and unit for each.
• Relevant Profile processing evidence and controlled identity lookup.
• Error code, diagnostic configuration and representative redacted failed input.
• Unaccounted records, affected business population and deadline consequence.
• Proposed recovery scope, repeated-record behavior, owner and acceptance cases to rerun.

Include a baseline run, R02's identity failure and R03's same-date updates. Keep file parsing and Profile contribution as separate findings. The ledger should explain what was processed and why a replay is justified, rather than merely recording that a retry button was pressed.

Profile reconciliation sheet

For every decision-driving field under investigation, record:

• Controlled customer ID and namespace.
• Intended attribute value, authoritative source and business owner.
• Source fragment values, their field paths and relevant ingestion observations.
• Named lookup policy and resulting Profile value with observation time.
• Conflicting-value, absent-field, null and empty-string test inputs and outputs.
• Snapshot dataset ID, policy mapping, relevant snapshot observation and compared scope.
• Exact query or lookup used, its parameters and a redacted result.
• First unexplained difference, proposed cause and evidence that would establish or reject it.
• Repair or escalation decision, responsible owner and observed result after the action.

Use R04 for precedence and R07 for snapshot comparison. State whether the discrepancy concerns one identity, one field or a wider population. Keep that scope consistent in an Adobe Support escalation and the business readiness review.

Audience timing and acceptance matrix

Create a case record for each controlled sequence. Include:

• Audience ID, saved rule/version, merge policy and actual evaluation method.
• Ingestion path for every required record and event input.
• Event time, source update time, arrival time and relevant completed job ID.
• Expected qualification or exit and the business deadline it supports.
• Observed membership, observation time and method used to inspect it.
• Event-first and attribute-first cases, expiry, late arrival and requalification.
• Estimated, qualified and exported counts where relevant, with distinct scopes and times.
• Receiver availability and journey entry as separate observations when required.
• Result against the acceptance criterion and the decision on any difference.

For the time-window fixture, confirm eligibility before expecting streaming behavior. For the retailer's scheduled CRM input, use the method and dependencies actually configured. Retain a failing timeline so that a later changed method or source can be compared with it.

Consumer handoff evidence

Record how the intended channel identifies and treats the customer:

• Consumer and connector type, connection/dataflow IDs and owning team.
• Required identity namespaces and attribute mappings.
• Applicable consent or usage-policy requirements and expected exclusion cases.
• Activation configuration, export or delivery observation and relevant times.
• Receiving acknowledgment, rejected-record detail or another supported observation.
• Expected and actual contact, audience or decision state for the controlled identity.
• Fresh-browser and first authenticated request traces for a relevant Edge/Target case.
• Decision delivery and rendering observations when the website treatment requires both.
• Known receiving-side limitations, next action, owner and business fallback.

Keep R08's missing mapping separate from a test customer legitimately excluded by consent. The record should show which condition caused the observed outcome and what evidence supports that conclusion.

Change and operating record

Before a change, capture:

• Original and proposed data or behavior contract, with the reason for changing it.
• Affected schemas, datasets, flows, identity settings, policies, audiences and consumers.
• Writers and readers, their owners and the sequence in which they must change.
• Historical data treatment, bounded replay scope and handling of overlapping versions.
• Expected differences, regression cases and criteria for completing the transition.
• Rollback limits and consequences requiring separate remediation.
• For cleanup, the exact supported operation, purpose, targets, affected services and verification.
• Operating ownership, freshness observations, alert conditions and fallback treatment.
• Review trigger, previous acceptance result and required revalidation.

Assign work to named owners before scheduling cutover. Include expected investigation and support effort in the operating plan. A change is complete when the required behavior is re-established for the agreed scope and the receiving owners can operate it.

Readiness and launch decision

For every mandatory requirement, record the criterion, evidence, outcome and unresolved gap. Then complete the decision:

• Approved customer population, channel, treatment and deadline.
• Ready, ready with agreed conditions or hold, with the reason.
• Business approver and technical/channel owners.
• Accepted limitation or condition, enforceable scope and completion owner.
• Consequence of an unresolved gap and the fallback in use.
• Next action, review date and triggers that reopen approval.
• Business outcome measurement owner and the planned evaluation.

For a conditional pilot, describe the restriction in operational terms: which population is selected, which treatment is enabled and how excluded cases are handled. Obtain a new decision before expanding beyond that scope. Retain delivery acceptance and business outcome evaluation as separate parts of the record.

Glossary

• Data contract: the agreed meaning, required inputs, ownership and behavior of a data-dependent use case.
• XDM: Experience Data Model, the schema framework used to describe and validate data in AEP.
• Record attribute: information about a subject, such as a member's current tier, represented through the relevant record design.
• ExperienceEvent: time-series data describing an occurrence and its context, such as a product-category view.
• Dataset: a storage and management construct for data associated with a schema.
• Data lake: the repository containing datasets that can be investigated through tools such as Query Service.
• Profile fragment: contributing record or event information associated with an identity before the applicable assembly into a Profile view.
• Identity namespace: the category that gives an identity value its meaning, such as a particular customer-ID system.
• ECID: Experience Cloud ID, used in Adobe collection to identify a browser or device context.
• Identity graph: the associations among identifiers established through the applicable Identity Service behavior.
• Namespace priority: identity settings that rank namespaces and affect the documented graph and Profile behavior.
• Merge policy: the rules governing which data is combined and how conflicting values are prioritized in a Profile view.
• Profile snapshot: a point-in-time dataset observation of profile attributes, separate from a live Profile lookup.
• Audience evaluation: processing that determines whether profiles meet an audience's rule under the applicable method.
• Hub and Edge: the central-platform and Edge Network contexts whose identity, profile and decision observations must be compared for the relevant integration.
• Activation: making selected audience or profile information available through a supported downstream path; the receiver still needs its own validation.
• Watermark: the source-selection value used to determine the relevant increment, according to the connector's supported behavior.
• Acceptance criterion: an observable requirement that the responsible owners use to decide whether a defined scope is ready.

Further reading

Technical reference date: 5 November 2026. Use the current guidance for the capabilities and entitlements enabled in your environment when configuring or changing the implementation.

Adobe product guidance

• XDM schema composition.
• Ingestion monitoring, batch troubleshooting and partial ingestion.
• Snowflake source prerequisites.
• Data Collection identityMap, Identity Graph Linking Rules and namespace priority.
• Merge policies, dashboard datasets and Profiles dashboard.
• Streaming evaluation, eligibility updates and audience FAQ.
• API SFMC connector and known-customer Target personalization.
• Choosing a data lifecycle capability.

AEP community discussions and questions

The discussions linked within each chapter include follow-up observations and unresolved cases. Use the reported outcome in its stated configuration, alongside the current product guidance and your own acceptance evidence.

For related investigations, see Adovo's audience freshness guide, batch-to-Profile investigation, audience-edit checks and Target request timeline. The AJO playbook continues into journey-entry design and testing.

Adobe documentation attribution

Technical guidance draws on the linked Adobe Experience Platform and architecture documentation. The Experience Platform documentation license and architecture documentation license contain the following notice for that material:

MIT License

© Copyright 2021 Adobe. All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Bring one use case to review

Bring the intended outcome, customer scope, deadline and known dependencies to an Adovo use-case and data-readiness review. Add a redacted ingestion, Profile, audience or consumer record where available. Identify the next delivery decision and the evidence needed to make it.