Adobe Analytics Partners

What an SDR has to contain to be worth anything

A solution design reference, usually shortened to SDR, is the spreadsheet or document that maps business questions to the technical variables that answer them. A thin SDR lists variable numbers and names. A useful one adds, for every variable: the exact value format, the event or page condition that sets it, the expiry and allocation settings, the system of record the value comes from, the person accountable for it, and a worked example of a real captured value. Without those columns you get a naming convention rather than a specification, and six months later nobody can tell whether eVar23 is empty because the feature is unused or because a release broke it.

Insist that the SDR is written before implementation starts and maintained as the source of truth afterwards, not reconstructed from the live deployment at the end. The practical test is whether a developer who has never seen your site could implement a tagging ticket from one SDR row, and whether an analyst reading the same row would know when the number is trustworthy.

Who owns the data layer once the build is finished

The data layer is the structured object your site or app exposes so that tags can read values without scraping the page. It is the single most fragile part of an Adobe Analytics deployment because it lives in your product code, changes whenever the product changes, and is usually written by engineers who have no reason to care about reporting. Decide before the work starts whether the specification for that object belongs to your engineering team, your analytics team or the implementer, and write it down.

The healthiest arrangement is that the data layer schema is versioned in your own repository alongside the application, with the analytics side owning the contract and engineering owning the implementation. Make data layer assertions part of your normal test suite, so a missing purchase object fails a build rather than quietly zeroing out revenue for a fortnight.

Variable governance that survives staff turnover

• Reserve ranges deliberately — keep blocks of eVars and props for known future domains rather than allocating sequentially as requests arrive.
• Never silently repurpose — a variable that changes meaning corrupts every historical comparison built on it; retire it and use a new one.
• Record the retirement date — disabled variables should carry the date and reason in the SDR so old reports can be interpreted.
• Tie classifications to a source — classification uploads that nobody owns go stale within a quarter and quietly break campaign reporting.
• Review quarterly against usage — Adobe reports component usage, so unused variables can be reclaimed with evidence rather than guesswork.

Global suite, rollups and virtual report suites

Report suite structure is an early decision with long consequences. A global suite that collects every property gives you cross-property paths, a single set of variables and one place to maintain, but it forces shared definitions on business units that may genuinely measure different things. Separate suites per brand or region preserve local autonomy and make permissions simple, but cross-property journeys become awkward and every configuration change has to be repeated.

In most cases the answer is a global suite plus virtual report suites, which are filtered views with their own component visibility, for individual teams. That gives local groups a workspace they cannot break while keeping one physical collection. Be aware that virtual report suites using report-time processing define visits differently from classic suites, so agree that behavior explicitly rather than discovering it when two teams report different visit counts for the same week.

Keeping props and eVars from sprawling

• Start from questions, not inventory — each variable should trace to a decision someone makes, otherwise it is storage with a maintenance cost.
• Be deliberate about persistence — eVar expiry and allocation settings are the single most common cause of attribution arguments between teams.
• Prefer events over counter eVars — using a metric for something that is conceptually a dimension makes later migration painful.
• Cap the initial build — a first release of forty well-documented variables beats a hundred and twenty that nobody validated.
• Document list variables carefully — multi-value dimensions behave differently in attribution and routinely surprise analysts who inherit them.

AppMeasurement, the Web SDK and the Edge Network

There are now two real ways to get data into Adobe Analytics. The legacy path uses the AppMeasurement library, typically deployed through Adobe's tag manager, sending hits directly to Adobe's data collection servers. The newer path uses the Web SDK, which sends a single XDM-shaped payload to the Edge Network and lets Adobe fan it out to Analytics, Target, Real-Time CDP and other destinations from one request. For any new build the Web SDK is the sensible choice, because it is the only path that positions you for Customer Journey Analytics and for server-side forwarding without a second implementation.

The trade-off is that the Web SDK is a different mental model, not a drop-in replacement. You map an XDM schema to Analytics variables rather than setting variables directly, and some legacy plugins and behaviors have no exact equivalent. Ask specifically how the delivery handles that mapping, how it treats existing custom code, and whether the Analytics mapping will be maintained in the Edge configuration or in processing rules, because the answer determines who can change tracking later without a code release.

What server-side collection actually buys you

• Resilience to blockers — a first-party server-side collection endpoint is less affected by browser and extension blocking than a direct client call.
• Enrichment before storage — server-side forwarding lets you attach values from your own systems that never existed in the browser.
• A smaller page payload — moving logic off the client reduces the tag weight that shows up in your performance budget.
• New operational burden — you now own an endpoint, its monitoring, its certificate rotation and its failure modes.
• Harder debugging — the browser network tab no longer tells the whole story, so insist on a documented way to trace a single event end to end.

Build as though Customer Journey Analytics is next

Adobe's direction of travel is clear: Customer Journey Analytics on Experience Platform is where product investment goes, and traditional Adobe Analytics is the mature estate. That does not mean you should refuse to invest in Analytics today, but it does mean every implementation decision should be checked against whether it makes a later move easier or harder. Collecting through the Web SDK, keeping values in structured fields rather than concatenated strings, and avoiding logic that depends on Analytics-specific processing rules all reduce future cost.

Ask for an explicit written position on this. A delivery that specifies variables in classic prop and eVar terms only, with no XDM equivalent, is quietly committing you to doing the specification work twice. One that models the schema first and maps down to Analytics gives you a migration path where the hard thinking is already done. The difference in effort during the build is modest; the difference when you migrate is measured in months.

Reconciling against source systems before you sign off

Analytics numbers are only credible if somebody has compared them to a system that does not use Analytics. Before go-live, reconcile order counts and revenue against your order management or finance extract, form submissions against the CRM records they create, and logged-in sessions against your authentication logs. Agree an acceptable variance in advance and, more importantly, agree the explanation for the variance you find. Analytics will usually be lower than the back end because of blockers, bots and consent, and knowing that gap is nine percent rather than unknown is what lets people use the tool.

Turn that reconciliation into something that runs repeatedly rather than once. A scheduled comparison of key totals against the source system, alerting when the gap moves outside its normal band, catches broken tags far faster than anyone noticing a strange dashboard.

Programs rarely stop at one product. Buyers hiring for Adobe Analytics often pair it with Adobe Brand Visibility partners , Adobe Campaign partners or Adobe Commerce partners , or review the whole Adobe landscape before committing.