The Adovo Audience Manager Playbook

Build reliable audiences, understand usable reach and make better investment decisions.

A subscriber sees an acquisition offer they should have been excluded from. An audience stops growing after a website release. A segment looks healthy in Audience Manager, but almost nobody enters the corresponding Target activity. Each problem crosses several teams, and each dashboard shows only part of the explanation.

Adobe Audience Manager, or AAM, connects signals, identities, traits and segments with the systems that use them. A useful implementation also needs an agreed treatment, a meaningful time window and someone who can verify what happened at the destination. Those decisions belong to the business owner and the delivery team together.

This playbook follows that work from the investment decision through collection, customer recognition, qualification, customer choices, receiving evidence and ongoing operation. It draws on Audience Manager community discussions and questions, with current Adobe documentation linked where product behavior affects the decision.

If you own the commercial outcome, start with the decision brief and Chapters 1, 5, 6 and 7. If you approve architecture or investment, use the same brief to challenge dependencies and compare options. Practitioners can follow Chapters 2 through 6 in sequence, using the shared workbook to record the configuration and results.

Explore the Adobe playbooks

All four playbooks | Business owners | Decision makers | Practitioners

Related guides: AEP · AJO · Real-Time CDP

Start with the decision you need to make

Write a use-case brief before creating another trait or changing a destination. Name the treatment in ordinary language: keep active subscribers out of an acquisition campaign, show an eligible reader a subscription offer, or make an approved audience available to a media account.

Then agree on the customer population, the latest useful time for the treatment and the evidence that would justify running it. A large segment can still be a poor investment if the destination cannot recognize its members or the offer arrives after the useful window.

The brief needs eight answers:

1. Outcome: Which customer action or commercial result should change, and how will you measure it?
2. Population: Are you describing browsers, devices, authenticated customers or accounts at the receiving platform?
3. Treatment: What will the website, campaign or media platform actually do with membership?
4. Deadline: When must eligibility and exclusions be available, and what happens if either is late?
5. Permissions: Which customer choices and data-use restrictions govern collection and activation?
6. Dependencies: Which identities, sources, destinations, accounts and teams must work for this route?
7. Cost: What usage, operating effort and commercial commitments apply?
8. Ownership: Who can approve launch, stop the treatment and decide whether to keep it?

A deadline should lead to a fallback. For acquisition suppression, stale subscriber status may mean pausing the affected activation. For an onsite promotion, unavailable eligibility may mean showing ordinary content. Decide that behavior before a missed update forces someone to improvise.

Use the business brief worksheet to keep those answers beside the implementation. Return to it whenever a technical finding changes who can be reached or when the treatment can occur.

Find the problem you are seeing

• Traits stopped populating after a collection change: start with Chapter 2, then check the identity contract in Chapter 3.
• An inbound file was processed, but customers or traits are missing: use the onboarding sequence in Chapter 3.
• A segment contains more devices than the CRM contains people: review Profile Merge Rules in Chapter 3 and metric definitions in Chapter 6.
• Someone remains eligible after their status changes: trace the lifecycle in Chapter 4 and the correct customer-choice mechanism in Chapter 5.
• A promotion appears on the first page of a return visit: separate audience eligibility from presentation timing in Chapter 4.
• AAM and a destination show different audience sizes: use the receiving contract and reconciliation sequence in Chapter 6.
• Usage rises after a release: compare the collection trace in Chapter 2 with the commercial and operating checks in Chapter 7.
• Cleanup or retirement changes a live audience: inspect the dependency chain in Chapter 7.

For broader platform data readiness, see the Adovo AEP Playbook. For journey entry and audience timing, use the AJO Playbook. When the selected activation is owned by Real-Time CDP, use its activation playbook to define that receiving contract.

A publisher with three connected requirements

The example throughout this guide is a fictional subscription publisher. It wants to acquire new subscribers through an approved media route, keep active subscribers out of that acquisition treatment and show an onsite subscription promotion only after a reader's first page in a visit.

The website is changing its collection implementation. Subscriber status arrives from CRM. The media account and the onsite application have their own eligibility and delivery rules. These are connected requirements, but they need separate checks: an audience update cannot by itself establish that an application waited until the second page.

We use eight synthetic situations to make those checks concrete:

1. P01 is an anonymous interested reader whose collection state permits the relevant activity.
2. P02 is a logged-in active subscriber associated with a known customer identifier.
3. P03 is an active CRM subscriber with no established browser match in the selected implementation.
4. P04 is a shared browser after logout or another person's login.
5. P05 is a subscriber whose commercial eligibility changes.
6. P06 is a reader who withdraws the relevant customer choice.
7. P07 uses a browser that blocks third-party behavior required by a particular route.
8. P08 is affected when a live trait moves between folders during cleanup.

These labels describe test situations, not campaign results. The publisher must choose its own update deadlines, allowed purposes and commercial thresholds. The workbook records expected behavior first and actual observations when the team runs its checks.

Chapter 1 Decide which audience use case is worth operating

An audience is useful when it changes a treatment you can deliver and evaluate. Start with that treatment. For the publisher, the acquisition campaign needs a population it may advertise to and a dependable way to avoid advertising to active subscribers. A broader audience is not an improvement if the exclusion becomes unreliable.

Turn the objective into a receiving requirement

Describe the receiving action precisely enough that its owner can accept or reject the proposed route. An onsite application may need membership at a particular decision point. A device-based media route may need a recognized device relationship. A people-based route may depend on an approved hashed identifier and the receiving account's eligibility.

Adobe's destination overview distinguishes cookie, URL, device-based and people-based destinations. Availability of a category does not establish availability of your intended connector or account. Check the actual route before estimating reach or committing a launch date.

For each option, answer four questions in the receiving team's language:

1. What membership or identifier will arrive, and how will the receiver recognize it?
2. Which action becomes possible when it arrives?
3. How will new membership, changed eligibility and removals be handled?
4. Which observation proves that the receiver used the information correctly?

In the publisher example, a receiver could acknowledge an exclusion update while a campaign still targets an older audience configuration. The acknowledgement and the campaign check answer different questions. Both belong in the handoff.

Make the deadline a business input

Ask how old subscriber status can be before the treatment becomes unacceptable. The answer determines whether the proposed source and processing path are suitable. A team that receives a daily file cannot promise every purchase will affect every subsequent decision immediately.

A community question about audience expiry asks how to avoid retaining interest after it becomes stale. There is no universal duration in the question. Decide how long the behavior remains useful for the offer, then select controls that can represent it.

Keep two deadlines in the brief: the latest useful eligibility update and the latest acceptable exclusion update. They can have different consequences. An offer can be delayed; an exclusion failure may require the treatment to stop.

Estimate reach in the unit you can defend

If the brief says customers, a browser count cannot silently become the forecast. Record the population you start with, the identity the chosen route uses and the evidence available at the receiver. Explain where the population changes and where the units stop being directly comparable.

A business owner can approve an initial experiment with uncertain reach if the uncertainty is explicit and the experiment can answer a useful question. A vague promise of audience scale makes it harder to tell whether the implementation worked or the original assumption was wrong.

Give audience expansion a separate decision

Rule-defined audiences, look-alike modelling and Predictive Audiences address different tasks. A rule expresses known conditions. A look-alike approach seeks similarities to a baseline. Predictive Audiences classifies a target population into personas; inspect its current input and merge-rule requirements before proposing it.

The publisher could later explore interest classification to choose a more relevant subscription message. First, it needs trustworthy subscriber exclusion and delivery. Otherwise the model experiment mixes a relevance question with unresolved collection and targeting problems.

A discussion about influential traits shows why a modelling recommendation should be questioned against actual configuration. Influential traits can help explain a model, but neither a score nor a larger audience establishes incremental subscriptions. Define the business experiment separately.

The output of this chapter is a decision to proceed, investigate or pause, with the assumptions that could change that decision. Complete Workbook 1 before implementation work expands beyond the use case.

Chapter 2 Keep collection working through implementation changes

When traits stop growing after a release, avoid changing trait rules until you know whether the expected signal reached Audience Manager. A collection problem, a naming change and a reporting delay need different repairs.

One Web SDK migration discussion includes a useful confirmed follow-up: adding AAM as a service to the Web SDK datastream restored trait population for that implementation. It gives you a configuration check, not a diagnosis for every missing trait.

Follow one event through the chain

Pick an approved test action with a clear expected signal. For the publisher, that could be opening a selected article after the applicable collection choice. Record the page and action, implementation version, environment, datastream and expected AAM trait.

Then collect evidence at each boundary:

1. The application generated the intended action once under the chosen test conditions.
2. The outgoing request carried the expected data and identity state.
3. The request used the intended environment and datastream configuration.
4. The AAM service received the relevant signal through the selected collection path.
5. The trait expression matched that signal and the intended test identity qualified.
6. The response or destination behavior was consistent with the configuration.

Keep the reporting observation after those checks. A graph that has not yet refreshed cannot explain whether the request itself was wrong. Conversely, a populated graph does not prove that the latest deployment is sending the right event today.

If a step has no evidence, investigate that boundary before changing downstream logic. This gives the owner a specific explanation for the delay: the event exists but is routed to the wrong datastream, for example, rather than a general claim that AAM is not working.

Choose the migration path before rewriting traits

An older migration discussion recommends adapting expressions for XDM data and later mentions work to simplify that transition. The right implementation decision now depends on the chosen collection path.

Adobe's AppMeasurement-to-Web-SDK guide documents transformation of Analytics variables into AAM signals. Its guidance also distinguishes the XDM Flattened Fields configuration. Inspect that setting and the actual payload before deciding whether an existing Analytics-based expression needs to change.

Build an inventory of the live traits the release could affect. For each, retain the original signal key, expression, intended action, source and dependent segments. Add the new observation beside the old one. A controlled comparison is easier to assess than changing a large set of expressions and hoping population stabilizes.

Where old and new collection coexist, test both paths. An expression that accommodates the new path can still misinterpret values or qualify too broadly. Set an end date for transitional rules, identify the pages still using the older implementation and preserve a rollback version.

Preserve the integrations that depend on collection

An apparent duplicate-forwarding concern can tempt a team to disable an integration setting. In the documented Web SDK migration configuration, Adobe says to retain report-suite server-side forwarding for Audience Analytics; the Edge flow uses cm.ssf to prevent repeat forwarding. Apply that guidance to the matching architecture, and investigate unexpected activity with the actual configuration in view.

The delivery team should show the before-and-after signal trace, affected audience behavior and usage comparison before the owner signs off. A successful website deployment is only one part of that acceptance.

Investigate activity beyond the browser

A community discussion about Target-related server calls ends with the author challenging the proposed explanation for extra activity. One browser request can initiate work in several systems. Counting visible requests alone does not reconcile every server-side retrieval.

Use the Activity Usage Report to separate Analytics, Target and Other activity where those breakdowns apply, and compare equivalent periods. Record release changes, traffic conditions and enabled integrations beside the usage change.

The commercial question is whether the observed activity is expected, necessary and consistent with the agreement. A reduction in calls may improve headroom without changing the invoice. Keep that conclusion for the contract review in Chapter 7.

Before completing this chapter, put one working collection trace and the affected-trait inventory in Workbook 2. Name the evidence that would trigger rollback if the live audience stops behaving as intended.

Chapter 3 Connect customer identities and interpret onboarding results

An active subscriber in CRM is not automatically a recognized subscriber in every browser or destination. The implementation needs an identifier relationship, an appropriate profile rule and a receiver that can use the result.

For the publisher, P02 represents a subscriber recognized after login. P03 represents the same commercial category without an established browser match. Treat those as distinct situations when forecasting acquisition exclusion. A successful CRM export does not make their onsite behavior equivalent.

Write an identity contract people can inspect

Record what the identifier means, which system issues it and whether it represents a person, account, household or device. Include the AAM data source, namespace symbol used in the SDK identity map, authentication state and applicable destination identity. Retain synthetic values for testing, with production identifiers kept out of shared diagnostic notes.

A Web SDK identity discussion asks whether the namespace must match the old integration code and why an expected namespace is missing. Current Adobe identity guidance distinguishes those entities and describes different behavior for data sources created after February 2024. Use the documented identity symbol for the intended AAM source; do not substitute a similar display name.

Validate the identifier at the point it is sent. A correctly named field with an empty or wrong value will not establish the intended relationship. Also test when the application stops or changes that identity after logout and a different login. The identity contract needs a lifecycle, not just a login example.

Use processing results to choose the next investigation

The question What does No Matching AAM ID mean? raises a reasonable assumption: these are existing customers, so why would they be unmatched? The reply supplies possible causes, but no verified diagnosis for the account.

The Onboarding Status Report distinguishes format problems, invalid identifiers, unmatched identifiers and missing trait realization. Preserve those distinctions in the investigation:

1. Receipt: Did the intended file arrive for the correct source and processing window?
2. Format: Were its records recognizable under the required syntax?
3. Identity: Did the supplied identifiers have the expected type and relevant matching relationship?
4. Qualification: Did the signals correspond to the intended onboarded traits?
5. Availability: Is the resulting state visible at the stage and time being checked?
6. Use: Can the selected destination and treatment act on that state?

For an unmatched identifier, inspect the configured source and identity evidence before blaming a browser blocker. For No Trait Realized, inspect definitions and values. Error sampling can help reveal recurring defects, but a sample is not the complete set of rejected records.

The CRM onboarding discussion illustrates why stages matter. A participant confirms a syntax repair and later visible traits, then raises a different realization problem. Reusing the first repair for every later error would miss the changed condition.

Separate offline storage from online recognition

Adobe's inbound FAQ supports offline-only use cases with appropriate cross-device sources. An unmatched browser does not mean every offline activation is impossible. It means you must establish which route, source and identity relationship the requirement needs.

For a new inbound integration, follow the current S3 guidance rather than copying an old FTP example. Keep the file receipt, processing result and destination observation as separate records. Establish the useful update deadline against that complete path.

Choose which profiles can affect qualification

Profile Merge Rules determine which authenticated and device profiles contribute to segmentation. Inspect the actual options in the merge-rule documentation, then explain their effect using the publisher's shared-browser case.

P04 logs out, or a second person logs in. Which prior data should influence the next promotion? Write the intended answer before selecting a rule. Check whether the active identity state and rule produce that answer; a logged-out request must not be assumed to mean that no historical authenticated profile can be considered.

A segment-population discussion supplies a Last Authenticated plus Profile Link example where device population exceeds the uploaded customer count. Linked-device reach can explain why the units differ. It does not justify calling every additional device an additional customer or diagnosing the account as double-counting people.

For a synthetic counting example, suppose one customer can be associated with two eligible test devices. Two device qualifications can support one customer's treatment across those devices. The commercial forecast still needs its person-level definition and receiving evidence. Record both units without subtracting one from the other as though they were the same measurement.

Finish Workbook 3 with a known matched subscriber, an unmatched CRM subscriber and a shared-device transition. Those cases expose more useful boundaries than a single successful login.

Chapter 4 Define when people qualify, leave and qualify again

The publisher needs an interested reader to become eligible, an active subscriber to be excluded and a changed customer state to reach every relevant treatment. Those are state transitions. Testing only the moment someone first qualifies leaves the most consequential behavior unexamined.

Begin with the commercial meaning of each trait. Reading an article is an event. Being an active subscriber is a state maintained by another system. A former subscriber may become commercially eligible again under an agreed policy, while a person who withdrew a customer choice needs a different handling path. Avoid giving all four situations the same expiry strategy.

Separate the clocks

TTL controls how long trait qualification persists without renewal. Recency and frequency constrain qualifying activity within the supported segment expressions. File processing changes onboarded state on another schedule. A destination has its own processing and retention behavior, and the application decides when it can present an experience.

The TTL and recency discussion includes later corrections to an earlier hour-based explanation. Read the complete timeline before copying an accepted reply into a design. Current TTL documentation places TTL on traits and describes a UTC day-boundary calculation for one-day TTL. In that documented example, qualification at 23:00 UTC expires 25 hours later. That formula does not define session expiry or every recency expression.

For a time-sensitive requirement, write a timeline with the original action, last qualifying activity, expected trait state, segment evaluation and receiving observation. Include activity near a day boundary. Record which clock each expectation uses instead of saying only that the audience lasts one day.

Current recency and frequency documentation limits these controls to supported trait types, including rule-based and folder traits. An onboarded subscriber-state update should not be designed as though it were an arbitrary stream of repeated online realizations.

Put the second-page rule in the presentation design

In a community question about short-lived qualification, the stakeholder wants a promotion to wait until at least the second page of each visit. The suggested frequency threshold does not, by itself, express that requirement.

Imagine P01 realizes the interest trait, leaves and returns while the qualification is still valid. A historical count of two does not tell the application whether this is the first page of the new visit. The presentation decision needs the application's definition of a visit and its current position within it.

Split the acceptance check. First establish that AAM supplies the intended eligibility under the configured identity and timing. Then establish that the application or Target implementation enforces the agreed page/session condition, including navigation, refresh and a return visit. The owner should see both results before accepting the promotion behavior.

If the application's required decision arrives before audience availability, use the agreed fallback. Avoid hiding an architecture mismatch by repeatedly shortening TTL until one browser test appears to pass.

Choose a deliberate update method

An onboarded-trait removal discussion asks how to change membership when expiry is set to zero. Appending a new status value and removing an existing qualification are different operations.

Use the current file specifications to select the operation:

1. Incremental addition: A .sync file adds data. Adding another value does not automatically prove that an earlier qualified trait has been removed.
2. Scoped replacement: A .overwrite file replaces data within the applicable provider scope. Define the traits that a listed customer's record must retain before using it.
3. Explicit trait removal: The inbound file specification documents d_unsid for onboarded-trait removal and says it is ignored in overwrite files. Match the identifier type, trait and source before preparing an actual file.

Consider P05 with two independent qualifications: active subscriber and an approved interest category. The commercial update should change subscriber eligibility while retaining the unrelated interest state where its continued use is allowed. Expected observations must cover both outcomes. Also test a customer omitted entirely from a subsequent file; omission is a separate input condition, not a substitute for a proven removal operation.

When multiple source files participate, record their scope and processing order assumptions. Do not depend on two near-simultaneous files being processed in the order they were uploaded. Prefer a design whose state transitions remain understandable under the supported processing behavior.

Follow the exit to the receiver

A removed trait in AAM is not the end of the exclusion check. Trace whether the segment changed, which update the destination supports and whether the receiver stopped the treatment. Record a later requalification case so the team knows whether commercial eligibility can return under the intended conditions.

The unanswered offline-exclusion discussion describes a customer appearing eligible despite an uploaded exclusion. Its account-specific cause is unresolved. The practical response is to retain the identity and timing evidence needed to investigate each boundary, rather than assume file presence proves effective suppression.

Complete the lifecycle timeline in Workbook 4. For a late or uncertain subscriber update, use the fallback in the business brief until the intended receiving behavior is established.

Chapter 5 Apply customer choices and data-use restrictions

Keeping a subscriber out of an acquisition campaign is a commercial exclusion. Stopping collection after a customer choice is a different requirement. Deleting historical data is different again. The mechanism must follow the required action and its scope.

The publisher's business owner and privacy owner should agree what each choice means in its products and channels. The practitioner then maps that requirement to the supported implementation path. A single trait named consent is not a complete record of those decisions.

Match the requirement to the mechanism

Use five separate entries in the control worksheet:

1. Collection permission: Which collection may occur in the current state, and which implementation receives changes to that state?
2. Marketing exclusion: Which treatment must omit the customer, while other permitted activity may continue?
3. Opt-out: Which supported request should stop the relevant collection, segmentation or activation, for which identifiers?
4. Access or deletion: Which request and verification process covers the relevant historical data?
5. Data-use restriction: Which source data may be used with which destination purpose?

These entries can apply to the same person. They should still have separate expected observations. A customer excluded from one offer may remain eligible for an allowed service message; a collection opt-out may require broader action than simply omitting that offer.

A community discussion comparing opt-out strategies puts these alternatives side by side. Its useful question is which action actually satisfies the chosen scope. Treat the current product documentation and your approved policy as the implementation inputs, rather than choosing the easiest segment expression.

Make identifier scope visible

Adobe's privacy-request documentation separates access/deletion through Privacy Service from opt-out through DCS. It describes partner-level declared-ID opt-out for the CRM identifier and the last linked device, with no historical deletion. That scope must not silently become a promise about every device previously associated with the customer.

For P06, record the submitted identifier, applicable partner scope, acknowledgement, resulting behavior and receiving-platform response. Check which downstream partners support the required unsegment handling; Adobe documents limitations. Where the automated path does not cover the requirement, assign the exception to an owner who can act at the receiver.

Keep legal response requirements with the organization's privacy owner. The technical record should show what was requested, when each system acted and which cases remain open. A request accepted by one service is a stage in that record, not evidence that every downstream obligation is complete.

Test a change of mind without accumulating contradictory state

Permanent opt-in and opt-out traits can both remain qualified after several changes. A segment expression over those accumulated facts may no longer represent the current permitted action.

Test the sequence the product needs to support: an initial state, a relevant choice change and any later permitted state change under the approved process. At each step, record collection, membership, treatment and receiver state independently. Do not assume an opt-out can be reversed by sending an ordinary positive trait event; use the supported process for the mechanism involved.

The same discipline applies to commercial state. A customer who changes subscription status has not necessarily changed their advertising choices. Keep the source and authority for each change clear, and avoid using a subscription update as a proxy for permission.

Pair export controls with the right destination labels

Data Export Controls classify source use, while destination labels describe how the receiver uses the data. Effective blocking requires the appropriate matching controls and labels. The relevant restrictions can involve trait sources and merge rules; placing a control only on a segment's own data source is insufficient.

The publisher can test an allowed route and a deliberately incompatible route using approved synthetic data. Confirm that the expected restriction applies to the actual trait and merge-rule dependencies. A label visible in an interface is useful configuration evidence, but the acceptance case should also establish that the disallowed combination cannot proceed as designed.

Record who can change these settings and what review a change requires. If a source purpose changes or a new destination is added, revisit the pairing before the data is used there.

The completed customer-choice worksheet should allow a business owner to ask a direct question: when this customer makes this choice, which systems stop which actions, and who checks the exceptions?

Chapter 6 Explain usable reach and prove the receiving result

The useful question is how many eligible members can receive the intended treatment under the selected conditions. Several counts help answer it, but they measure different stages. A discrepancy is a reason to compare definitions before declaring a failure.

For the publisher, a CRM subscriber count, an AAM device population and a media platform's matched audience are different quantities. The onsite promotion adds another requirement: a member must reach the application and satisfy its presentation rules at the decision point.

Give every count a definition

Create a small dictionary beside the report. For each number, record the interface or API, metric name, identifier unit, population scope, interval, timezone and time observed. Include the source version or file when it determines the population.

Separate at least these stages:

1. Source records: The customer or behavioral records submitted for the intended population.
2. Processing results: What the inbound or collection stage accepted, stored or rejected.
3. Trait qualification: Which relevant profile identities carry the required traits.
4. Segment population: Which identities qualify under the segment expression and merge rule in the selected reporting context.
5. Destination addressability or shareability: Which supported members or identifiers can be used with the selected route.
6. Receiver matching and eligibility: What the platform recognizes and can target under its own rules.
7. Exposure: Which eligible visitors or accounts actually received the treatment.
8. Outcome: What happened after exposure, measured under the agreed evaluation method.

Do not subtract a device count from a customer count and call the difference lost customers. Do not sum overlapping segment populations to produce unique reach without a method that resolves the overlap. The count dictionary should expose these mistakes before the forecast reaches an investment meeting.

Adobe's Addressable Audiences documentation defines customer and segment measures with different lookback behavior and notes UTC reporting windows. Its device-based destination measures are not a universal metric for every route. Use the actual receiver contract for a URL, cookie or people-based activation instead of forcing it into the wrong report.

Trace a Target treatment beyond membership

In a community question about a smaller Target audience, the accepted reply calls for investigation of the actual activity. It does not establish a universal reason for the difference.

For the publisher, inspect the relevant activity, environment, audience rule, traffic allocation, visitor identity and timing. Establish whether membership was available when Target made its decision, whether the visitor met all activity conditions and whether the application displayed the returned treatment. A valid audience member can fail another activity condition.

Also distinguish a small observed visit count from a small eligible audience. If few eligible readers return during the observation window, the activity cannot expose every historical member. If those who do return are being excluded incorrectly, that is a separate implementation finding.

Use an approved test identity to retain the decision evidence and the rendered result. A returned offer, a visible promotion and a counted exposure may need different observations. State what the business outcome measure uses so the team can investigate a missing impression without requalifying the audience unnecessarily.

Compare media routes using the same starting population

A Facebook destination discussion asks why a direct upload matches more profiles. The replies assume different destination types. That uncertainty changes the investigation.

Start by naming the actual AAM route, destination account, source population and identifier transformation. Compare the direct-upload population and observation window with that record. Were the same permitted identifiers submitted? Did one route include members or identifiers absent from the other? Did the receiver finish processing both before the comparison?

For a people-based route, use the current prerequisites and considerations, including the permitted data origin and identifier path. For a browser-triggered route, investigate the actual configured request and applicable browser state. A pixel diagnostic cannot resolve a different server-side identity contract.

A supported identifier sent successfully is still not a guaranteed receiver match. Record the receiving platform's own eligibility and reporting restrictions, and let its owner confirm the result. Avoid adopting an old community threshold as the current rule for every account.

Use a reconciliation sequence that narrows the problem

Run these checks in order, preserving the first boundary where expected and observed behavior diverge:

1. Align scope. Confirm that both sides refer to the same treatment, destination account, unit and observation window.
2. Verify collection or input. Inspect the source event or file and the intended implementation version.
3. Verify recognition and qualification. Check identity routing, authentication state, relevant traits, segment expression and merge rule.
4. Verify controls. Establish whether an exclusion, customer choice or data-use restriction explains the result.
5. Verify delivery. Inspect the supported route's membership update, mapping or request evidence.
6. Verify the receiver. Check processing, matching, activity conditions and actual treatment behavior.

If the counts still cannot be reconciled, report the open boundary and its owner. Do not make them appear equal by changing the audience definition during the investigation. Preserve the original comparison so a later repair can be assessed against it.

Include browser conditions and reporting context

P07 represents a browser where the selected route's third-party behavior is blocked. Compare the allowed implementation under those conditions with a permitted baseline test, keeping customer choices and browser settings explicit. A successful test with blocking disabled does not establish the available reach in the blocked condition.

The AAM-versus-Analytics discussion contains a claim of perfect trait-level agreement. Current Adobe visitor-count guidance identifies differences in definitions, timezones and filtering. Match the closest relevant metrics, then explain the remaining supported differences rather than promising exact equality.

Complete Workbook 6 with a known eligible reader and a known excluded subscriber. The receiver must demonstrate both delivery and restraint. Assess subscriptions or another business outcome separately from that delivery acceptance.

Chapter 7 Operate, change and retire audiences with accountable owners

Once a use case works, the next risk is ordinary change: a folder reorganization, a renamed source, a new destination owner or a subscription-status feed that stops updating. Keep the operating record close enough to the business brief that someone can decide whether the treatment is still safe and useful.

Keep a dependency record with owners

Trace the use case from source and identity through traits, folder traits, segment expressions, Profile Merge Rules and destination mappings to the receiving account and treatment. Use stable identifiers alongside human-readable names. Assign a business owner and an implementation owner, then name the people responsible for upstream data, customer-choice handling and receiving-platform access.

The publisher should be able to answer who notices a missing subscriber update, who can pause acquisition treatment and who can confirm the receiver acted on the pause. A generic support queue without those responsibilities leaves the commercial decision unresolved during an incident.

Record expected observations and review triggers. Examples include a collection release, a change to subscriber-status semantics, a new audience source, a destination permission change or unexpected movement in usage. Set review intervals according to the use case rather than copying one cadence across every audience.

Treat taxonomy changes as changes to targeting

The folder-dependency discussion includes a small test of a referenced folder trait. A deletion guard is helpful, but it does not make the preceding move harmless.

Adobe's folder-trait documentation explains that folder traits aggregate their contained traits and that moving a trait changes those relationships. Its management guidance says a folder trait used in a segment expression cannot be deleted until that dependency is removed.

For P08, list the segments that use the original folder trait before moving anything. Record expected membership and receiver effects, then test the proposed structure with a bounded approved population. The change is complete when the dependent treatment behaves as intended, not when the taxonomy looks tidier.

Bulk changes need the same discipline. An old spreadsheet or BAAAM suggestion may help identify a task, but it does not validate today's authentication, permissions or replacement logic. Retain the original expressions, use supported current interfaces and review the exact affected set before applying a change.

Make retirement a receiving-system task too

A DV360 discussion describes audience mappings still visible after distribution ended and the company stopped using AAM. No confirmed cleanup resolves that exchange. It is a useful reason to plan the exit while both account owners are still available.

Retirement should identify the audience, mappings, active campaign dependencies, receiving objects and any remaining retention or privacy actions. Stop the intended treatment, verify the supported update or removal behavior and obtain confirmation from the receiver's owner. Record unresolved objects and the team able to remove or disable them.

Do not use absence of new exports as the only proof of retirement. A receiver may retain an object or continue using a previously populated audience under its own settings. Preserve the identifier and final confirmation so a future team can distinguish an inert historical object from an active dependency.

Connect usage with commercial consequences

Compare the required workflow with actual activity and operating effort. Include implementation maintenance, source and destination support, data preparation, investigation and the commercial commitment. Separate an unexpected technical increase from a finance conclusion about its cost.

The Activity Usage Report helps investigate volume and source categories. It is not a billing report. Use the actual agreement and renewal or overage terms to decide whether a usage change creates headroom, avoids an expense or changes a payable amount. Record the basis and the person who confirmed it.

For business value, ask whether the treatment produces the agreed outcome under a defensible comparison. Avoid attributing every subscription after exposure to the audience. A business owner needs the evaluation method, operating cost and remaining uncertainty to decide whether another round of investment is warranted.

Evaluate expansion or transition against a concrete requirement

Choose among continued operation, a focused repair, a bounded expansion pilot and a scoped transition. For each, record the capability delivered, expected usable reach, implementation effort, operating burden, commercial effect and risk to the live treatment.

If Predictive Audiences is proposed, check current input eligibility and merge rules, and use an evaluation method that supports the resulting segments. Adobe excludes Predictive Audience segments from Audience Lab. Uneven persona populations are not automatically a failure; test whether the classification serves a useful treatment and improves the agreed outcome.

For a collection change, keep the library decision separate from the audience-platform decision. Adobe's DIL notice says DIL development stopped and recommends Web SDK for new collection integrations. That notice does not establish an AAM product retirement deadline.

If future requirements point toward Real-Time CDP or another architecture, make those requirements explicit. Identify the audience definitions, identity behavior, exclusions, receiving contracts and operational responsibilities that must transfer. Compare that work with repairing the current use case. A transition earns approval through capability and business evidence, not through a generic claim that moving platforms will solve matching or timing.

Complete the change and retirement register and investment worksheet. Finish with an owner-approved decision, the next review date and the condition that would cause the treatment to stop.

Shared workbook

Use one record for each treatment and receiving route. The publisher's acquisition activation and onsite promotion share some inputs, but they need separate receiving acceptance. Connect the records through the subscriber exclusion and identity contract so a change to either prompts the appropriate review.

Each worksheet should contain an owner, a version, the date observed and links to redacted evidence. Keep expected and actual behavior in separate fields. When a test fails, retain the original expectation and add the observed result and next action. Editing the expectation to match the failure removes the basis for a useful decision.

Workbook 1 Business brief

Record the outcome, starting population, counting unit, treatment, deadline, exclusion deadline and fallback. Add the commercial owner, implementation owner and receiving owner. Identify which unanswered assumption would change a proceed decision to investigate or pause.

For the fictional publisher, write acquisition and onsite presentation as separate requirements. Active subscribers must be excluded from the agreed acquisition scope. The onsite promotion must wait until the application's specified page/session condition. Decide what the application and media team will do when fresh status cannot be established.

Before approving work, ask:

• Is the treatment specific enough that its receiving owner can verify it?
• Can the team distinguish eligible customers from eligible devices?
• Is the source update path compatible with the required timing?
• Does the proposed experiment measure a business result beyond audience growth?

Retain the reason for proceeding, including assumptions about reachable population and operating effort. The decision remains reviewable when later evidence changes those assumptions.

Workbook 2 Collection trace

Record a synthetic test action, environment, library version, datastream, service settings, expected signal key/value, trait expression and dependent destination response. Identify any transitional collection path and the date it should be removed.

For P01, attach the permitted request observation and explain which trait should qualify. Repeat after the collection change with the same action and conditions. A useful comparison shows that the intended event and identity still take the expected path, rather than merely confirming that some traffic reaches AAM.

Include these acceptance fields:

• Expected event frequency and actual observed requests for the chosen action.
• Expected AAM signal and actual observed signal or matching evidence.
• Expected trait behavior and the time/reporting context of its observation.
• Expected integration and usage changes, plus the observed comparison.
• The failed boundary that would trigger rollback and the person able to perform it.

Where an observation is unavailable, record it as unknown and choose the next check. Avoid representing a blank evidence field as a passed acceptance item.

Workbook 3 Identity and onboarding

Record the source identifier's meaning, issuer, format, intended AAM data source, integration code, SDK namespace symbol, authentication-state behavior and destination identifier. Keep identifiers from different sources distinct even if their example values look the same.

Run P02, P03 and P04 through the intended path. The known subscriber should demonstrate the relevant relationship; the unmatched CRM case should expose the supported offline and browser behavior; the shared-browser case should establish what happens across logout and another login.

For inbound processing, retain:

• File identity, source, operation type and intended population.
• Receipt and processing window, with format and identifier results.
• Trait definitions available for the supplied signals.
• Expected retained and changed qualification.
• Reporting context, destination observation and unresolved cases.

Select the test environment deliberately. Adobe's beta-environment guidance limits inbound testing there to syntax and provides no equivalent live identity mapping or outbound traffic. A beta format pass cannot establish the production receiving result. Use the organization's approved bounded validation process for the integration.

Workbook 4 Qualification lifecycle

Record the business meaning of each trait, its type, TTL, relevant recency/frequency expression, segment rule and Profile Merge Rule. Add the authoritative source of each state and the mechanism used to change it. State which timing belongs to AAM and which belongs to the application or receiver.

For P05, list the desired state before the change, after the source update and after destination processing. Add the unrelated trait that must remain intact. Record separate expectations for a listed customer whose trait changes and a customer omitted from a later file.

The timeline should include:

• Source action or state-change time, with timezone.
• Submission and processing observations.
• Expected qualification and disqualification points under the selected controls.
• Observed receiving state and treatment behavior.
• Any later requalification and the conditions that permit it.

For the onsite promotion, record the application's visit definition and page-position control. Test a return visit while historical interest qualification remains valid. This case should show whether the presentation requirement is satisfied independently of the trait's persistence.

Workbook 5 Customer choices and restrictions

For every required action, record its policy meaning, product mechanism, identifier scope, permitted processing path and receiving obligations. Assign owners for request submission, exception handling and completion evidence. Keep commercial subscriber exclusion separate from a customer's collection or advertising choice.

For P06, document the relevant change, the identifier submitted, the expected product behavior and the observation at each receiving system. Where a partner cannot support the required automated removal, specify the owner's alternative action and evidence instead of closing the case at the AAM acknowledgement.

Include a restricted-export case with:

• The affected trait sources and merge-rule dependencies.
• The matching destination labels and the intended allowed or blocked combination.
• The permissions and version of the configuration being checked.
• The actual result and the owner of any mismatch.

If a later customer choice is supported, describe its authorized handling path explicitly. Never infer reversibility from the presence of an ordinary positive trait event. Preserve the sequence of choices and system actions so the current state can be explained.

Workbook 6 Receiving reconciliation

Create a receiving contract for each route: destination identifier, account, population definition, data origin, identifiers, applicable transformations, mapping, update behavior, removals, processing window and owner. Include the actual treatment configuration that depends on it.

Add a count dictionary with the exact metric name, interface, unit, source, interval, timezone and observation time. If two reports cannot be compared directly, state what comparison is meaningful instead. The receiver's targetable account count may help planning while remaining unsuitable for direct subtraction from a device count.

Record the reconciliation result as a sequence of observations:

• Source population and input evidence.
• Qualification, exclusions and identity behavior.
• Supported delivery evidence.
• Receiver processing and matching information.
• Activity eligibility and observed exposure.
• Remaining discrepancy, its owner and next check.

For P07, record the relevant browser condition and the route's behavior under it. Retain the blocked and permitted baseline observations separately. The outcome decision should use the expected production conditions, not only the easiest environment in which to demonstrate delivery.

Workbook 7 Change and retirement

Record the dependency chain using both names and stable identifiers. Include source owners, authentication, traits, folder traits, segment expressions, merge rules, restrictions, destination mappings, receiving accounts and treatments. Note where a service-generated or externally managed object requires another team to act.

For a proposed change, retain the original configuration, exact affected set, intended behavior, test population, rollback condition and acceptance owner. For P08, show the folder relationship before and after a move and check the actual dependent segment behavior.

For retirement, record:

• The owner-approved treatment stop and the dependencies that must stop using the audience.
• The supported distribution, mapping and membership actions.
• The receiver's confirmation of disabled treatment or completed cleanup.
• Residual audience objects, their status and the team able to manage them.
• Separate retention, privacy or contractual tasks that remain applicable.

Close the record with evidence from both sides. If receiver access is being removed, complete or transfer the cleanup responsibility before that access disappears. A final AAM screenshot alone cannot describe what a media account will continue to do.

Workbook 8 Value and next investment

Compare four options: continue the accepted workflow, repair a defined defect, run a bounded expansion experiment or transition a specified capability. Use the same outcome, population and timing requirements when comparing them. Otherwise a cheaper option may appear attractive because it omits a requirement.

Record current usage, operating effort, actual commercial terms, expected reach under the supported conditions and evidence of business outcome. Identify whether a financial effect is headroom, avoided expense, a renewal consequence or an observed payable saving. Have the appropriate commercial owner confirm the distinction.

For an expansion proposal, specify the model's purpose, eligible inputs, affected customer choices, receiving treatment and valid evaluation method. Do not assume a model population should be evenly distributed or that its score predicts the exact commercial return.

Conclude with a decision, owner, review date and stop condition. List the assumptions that remain material to that decision. For the publisher, a sensible next investment might be repairing subscriber exclusion before testing a new relevance model; the recorded evidence should explain why that order serves its objective.

Twelve acceptance cases

Run these as bounded checks under the approved integration and test process. They specify expected behavior; they are not a statement that a particular tenant has passed. For each, record the configuration, expected result, actual observation, owner and action on failure.

1. Collection continuity: Perform P01's approved action before and after the release. Verify the intended event, environment, datastream and AAM signal. If the signal is absent, investigate the first failing collection boundary before changing the audience rule.
2. Trait-rule continuity: Exercise each affected old and new collection path. Verify that the live trait still means the intended action and does not qualify on an unrelated value. Preserve the prior expression and rollback evidence.
3. Namespace routing: Send the approved synthetic customer identity using the documented symbol for the intended AAM source. Verify the identifier relationship and authentication state. A similar namespace display name is not acceptance evidence.
4. Inbound stages: Submit a bounded population containing a valid record and controlled format, identity and trait-definition variations where the test process permits them. Check that each result is explained at the correct processing stage and that the valid case reaches the intended receiving observation.
5. Shared-device transition: Use P04 to test logout and a second approved login. Compare actual qualification and treatment with the intended merge-rule behavior. Escalate any case where one person's prior state affects another person's treatment contrary to the requirement.
6. Expiry boundary: Observe the intended trait and segment rule across the selected day boundary without renewing the relevant event. Record UTC and local times separately. Check the receiver after the supported update path rather than stopping at the trait report.
7. Scoped subscriber change: Change P05's subscriber qualification using the selected supported mechanism. Verify that the unrelated retained trait remains intact, that the subscriber-related segment changes correctly and that the receiver reflects the intended treatment. Test whole-ID omission separately.
8. Second-page presentation: Return as an interested reader while historical qualification is valid. Confirm no promotion on the first page under the application's visit definition, then check the eligible later page. Include refresh and navigation behavior that could reset or duplicate the presentation decision.
9. Choice and restriction: Apply P06's relevant customer-choice action and check its documented identifier scope and receiving response. Separately exercise an incompatible export-control/label pairing. Record any downstream exception rather than treating local acknowledgement as completion.
10. Receiver and browser conditions: Test a known eligible reader and a known excluded subscriber through the exact selected route. Repeat the relevant browser case for P07. Record matching, activity eligibility and treatment evidence separately, with aligned report windows.
11. Folder change: Record P08's original dependencies and expected membership, perform only the approved bounded change, and inspect the dependent segments and treatment. A blocked deletion does not compensate for an unintended membership change caused by a move.
12. Retirement: Stop a bounded test treatment, execute its supported distribution and receiver cleanup steps, and obtain receiving-owner confirmation. Record residual objects and remaining responsibilities before closing access or declaring the use case retired.

Glossary

• Signal: A data value received through the collection or inbound path and available to the relevant qualification logic.
• Trait: A qualification based on its defined type and rules. Its type affects how realization, persistence and controls work.
• Segment: An audience definition combining traits and other supported conditions under its assigned profile rule.
• Device profile: Data associated with the relevant device identifier, whose use depends on the selected merge rule.
• Cross-device identifier: A customer-provided identifier used in the configured source and authenticated-profile relationship.
• Authentication state: The implementation's indication of the identity's current state, which must follow the actual login and logout behavior.
• Namespace symbol: The symbol that identifies the relevant identity namespace in an SDK identity map; it must route to the intended source.
• Integration code: An identifier used for an AAM data source or other supported object; it is not automatically interchangeable with a namespace display name.
• Profile Merge Rule: The configured selection of authenticated and device profiles used for segmentation.
• TTL: The persistence interval assigned to a trait, whose renewal and expiry must fit the use case.
• Recency and frequency: Controls over supported qualifying activity and daily intervals; they do not inherently identify the current page of a visit.
• Addressable audience: A destination-specific measure whose definition, identifier unit and reporting context must accompany its count.
• Shareable audience: A people-based destination concept concerned with the identifiers that AAM can share through that route; it does not establish receiver matching or exposure.
• Data Export Control: A source-use restriction that works with relevant destination labels and dependencies.
• Receiving contract: The team's record of what a route sends, how the receiving system uses it and which evidence establishes the result.
• Retirement: The controlled end of a use case, including dependent treatments and receiving-system responsibilities.

Sources and related guidance

The Audience Manager community discussions linked in each chapter supply the questions and account-specific experiences. The applicable implementation still depends on the configured collection path, identities, audience logic and destination. Product guidance below was checked on 6 November 2026.

• Collection: AppMeasurement migration, Web SDK setup and DIL development notice.
• Identity and ingestion: Namespace relationship, onboarding report, inbound FAQ and file specification.
• Qualification: Merge rules, TTL and recency/frequency.
• Choices and use: Privacy requests and Data Export Controls.
• Delivery and measurement: Destination types, people-based prerequisites, addressable audiences and Analytics comparison.
• Operation: Usage reporting, folder traits, folder management, Predictive Audiences and beta environment limits.

Adobe documentation attribution

Technical guidance draws on the linked Adobe Audience Manager documentation. The AdobeDocs source repository license contains 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.

Review your Audience Manager use case

Bring the treatment you want to improve, the population you intend to reach and the decision you need to make. Add a redacted collection trace, identity contract or receiving comparison where available. Adovo can help assess the dependencies, isolate the uncertain boundary and define the work needed for a supported decision.