AD0-E207 Adobe Analytics Architect Master Exam Topics and Questions

Discovery is where an architect's work either gains traction or quietly falls apart. Before a single variable is named, you need to know what the business actually measures, what the site currently tracks, and where those two things diverge. This topic tests whether you can run a structured audit, surface the gaps stakeholders haven't noticed, and translate vague business intent into a measurement framework that holds up under implementation pressure.

How Discovery is tested

At 18% of the exam, Discovery is the lightest of the three domains, but candidates who treat it as a warm-up pay for that in scenario questions. Items here present a business situation: a stakeholder description, a partial audit finding, or a set of conflicting requirements, and ask you to identify the appropriate next step or the correct framework output. The trap is jumping to a solution design decision before the discovery work is complete. Items reward the sequence: audit first, validate business requirements second, build the framework third. Auditing questions test whether you know which signals in a site audit indicate broken or redundant tracking, not just whether you can run one. Business requirements questions test whether you can distinguish a measurable KPI from a stated goal. Measurement framework questions test whether the framework maps to actual Adobe Analytics constructs, not just abstract metrics. Candidates lose marks by selecting answers that are technically valid but skip a discovery step the scenario has not yet completed.

More than half the exam lives here. Coming out of Discovery, you have a measurement framework and a set of validated business requirements. Solution design is where those inputs become a working Adobe Analytics implementation: variables assigned, report suites configured, collection methods chosen, and specs written precisely enough that an engineer or developer can act on them without guessing. Every decision you make in this domain has a downstream consequence in data quality, so ambiguity is expensive.

– From requirements to variables

Translating business requirements into props, eVars, events, and metrics is the architectural core of this domain. The exam tests whether you can make defensible allocation and expiry choices for eVars, not just assign a variable number. It tests whether you know which events map cleanly to revenue or engagement KPIs and which require calculated metrics to be meaningful. Candidates who treat variable assignment as clerical work lose marks to questions that hinge on a single allocation setting or a counter versus currency event distinction. The measurement framework from Discovery is the input here; the solution design reference document is the output. Items reward selecting the variable type and configuration that satisfies the business requirement without creating reporting ambiguity downstream.

– Report suite strategy and data collection

Report suite settings govern what data can ever be recovered from an implementation, which makes configuration decisions consequential and largely irreversible. The exam tests your ability to choose between global, rollup, and multi-suite approaches given a specific organisational or reporting requirement, and to recognise when a setting like timestamp optional or base currency will affect cross-suite comparability. On the collection side, items present scenarios involving web, mobile, and server-side contexts and ask which collection method fits. AppMeasurement, the Web SDK, and the Mobile SDK each have appropriate contexts, and the exam rewards matching the method to the scenario rather than defaulting to a single approach. Understanding when to use data layer variables versus direct page-level variables also appears here.

– Technical specifications and user administration

Writing specs for tagging engineers and site developers sounds like documentation work, but the exam treats it as an architecture decision. A spec written for a tagging engineer covers implementation layer details: variable mapping, plugin usage, and tag sequencing in a tag management system. A spec written for a developer covers data layer structure, event listener requirements, and what the layer must expose before the tag fires. Items test whether you can identify what belongs in each document and what an incomplete spec would cause to fail. Creating Experience Cloud users and groups rounds out this section. Permission levels in the Admin Console, product profiles, and the difference between organisation-level and report-suite-level access are all testable. Candidates lose marks by conflating the two spec audiences or by selecting permission configurations that grant more access than the scenario requires.

How Solution design is tested

With 54% of the exam weight, this domain determines whether you pass. Expect a sustained run of scenario-based items where a business requirement is given and you must select the implementation approach, the variable configuration, or the spec content that satisfies it. The items are designed to separate architects from implementers: knowing that an eVar exists is not enough; you need to know which expiry setting the scenario's reporting requirement demands. Collection method questions reward eliminating approaches that don't fit the data source or latency constraint in the scenario, not picking a favourite SDK. Report suite questions reward recognising that a setting chosen at creation time cannot easily be changed, making the initial choice load-bearing. Specification questions reward precision: the strongest option is the one a tagging engineer or developer could act on without a follow-up conversation. User administration items are often the shortest in the domain but catch candidates who have not worked with the Admin Console directly. Do not skim that area.

Once the implementation is live, a different set of skills takes over. Post implementation asks you to validate that what was built matches what was specified, manage the ongoing flow of data into Analytics, and ensure the organisation's handling of that data meets governance and privacy obligations. This domain rewards candidates who understand that an implementation is a living system: tracking breaks, data sources drift, and privacy requirements evolve, and the architect is accountable for all of it.

– Validation and quality assurance

Validating tracking through browser developer tools and Adobe reports is the first thing an architect does after go-live, and the exam tests it at a practical level. Items present a scenario where a metric is missing, inflated, or inconsistent across report suites, and ask you to identify the validation step or tool that would isolate the cause. Charles, browser network tabs, the Adobe Experience Platform Debugger, and Omniture's legacy DigitalPulse are all in scope as diagnostic contexts. The exam rewards knowing what a correct network request looks like and what specific malformed or absent parameters indicate. On the reporting side, items test whether you can use data feed output or Workspace behaviour to confirm that variable values are populating as specified. Candidates lose marks by selecting validation steps that are plausible but would not isolate the specific failure mode the scenario describes.

– Data management, sources, and governance

Managing data extraction and relationships covers classification imports, data feeds, and the Data Warehouse, each of which has its own appropriate use case. The exam tests whether you can match the extraction method to the business need: a one-time backfill, a recurring operational export, or a large unsampled dataset for analysis. Data sources and connectors questions ask you to recognise when an offline data import is appropriate and what the file format and processing rules requirements are. Data governance and privacy questions test your ability to identify what a data governance model must address under regulations such as GDPR and CCPA within the context of Adobe Analytics, including variable-level data privacy labels and the Privacy API. Segments and calculated metrics round out this group. Items here test whether a segment definition or a calculated metric formula correctly answers the stated business requirement, not just whether it is syntactically valid in Analytics. The distinction between a sequential segment and a standard segment is a common trap.

How Post implementation is tested

At 28%, Post implementation is the second-largest domain. Items tend to be longer than those in Discovery because they embed a scenario with a live implementation already in place: a tracking discrepancy, a data governance audit, or a business team requesting a new segment. The exam rewards candidates who can read a scenario and identify whether the problem is a collection issue, a processing rule error, a data source misconfiguration, or a reporting definition mismatch, because the fix differs in each case. Privacy and governance items reward selecting the response that satisfies the regulatory requirement without over-restricting data that the business is permitted to use. Segment and calculated metric items reward the definition that precisely matches the business requirement in the scenario, and penalise definitions that are close but include or exclude the wrong population. Candidates who have not worked with data feeds or classification imports in practice often underestimate how specifically the exam tests those mechanics. Treat the data management sub-area as carefully as the validation work.