Adobe Analytics Implementation Best Practices, From SDR to CJA

The best Adobe Analytics implementations are designed before anyone writes a tag. A solution design reference ties each variable to a business question, and a data layer feeds the tags. The Adobe Experience Platform Web SDK then sends data in a shape Customer Journey Analytics (CJA) can use later. This guide sets out those Adobe Analytics implementation best practices in order, plus the naming, channel, bot, quality assurance (QA), consent and documentation habits that keep numbers trustworthy.

It's written for the people who own the data: analytics leads, developers and the marketers who rely on the reports. If you're choosing a firm to do the work, read our buyer's playbook for Adobe Analytics partners alongside this.

Why should every Adobe Analytics implementation start with a solution design reference?

Because it's the blueprint everything else follows. Adobe describes the solution design document, also called a solution design reference (SDR), as the place where stakeholder requirements are translated into Analytics variables. Without one, Adobe says, organizations struggle to coordinate reporting needs and tend to miss important data.

Start with outcomes, not variables. List your key performance indicators (KPIs), then the business questions that would help you improve them, then the dimensions and metrics that answer those questions. Be ready to turn requests down. Every variable you add is one more thing to QA, document and explain, so each one needs a question behind it.

Adobe suggests a few helpful columns, and a sample makes the idea concrete:

Name	Variable	Logic	Status
Internal search term	eVar5	Search results pages only, from the q parameter, lowercased	Active
Searches	event12	Fires once per results page load	Active
Page template	prop3	From page.template in the data layer	Planned

Add columns for the data layer source, the owner, the privacy label and the matching field you'd use in CJA. Then name one owner for the document itself. Adobe calls it a living document, and it only stays useful if someone updates it with every release.

Should you implement Adobe Analytics with the Web SDK and XDM?

For a new implementation, yes. Adobe calls the Web SDK tag extension the standardized and recommended method for new customers. It sends data to the Edge Network, which forwards it to Analytics and, when you're ready, to Adobe Experience Platform for CJA.

Adobe documents four client-side methods for websites:

• Web SDK extension in tags: the recommended route for new builds.
• Web SDK JavaScript library (alloy.js): the same SDK without the tags interface.
• Analytics extension in tags: sends data straight to Analytics, without the Edge Network.
• AppMeasurement: the legacy library, still useful for cases tags don't cover, such as AMP pages.

On the Web SDK, data can travel in three formats. The XDM object follows a schema built on Experience Data Model (XDM). The data object suits teams moving from AppMeasurement, because the Edge Network recognizes Analytics fields without a schema. Anything else arrives as context data, which you map with processing rules.

One tip from Adobe is worth repeating. If you plan to move to CJA, Adobe advises against building your schema on the Adobe Analytics ExperienceEvent field group. Create your own schema and use datastream mapping to fill the Analytics variables, so you're not locked into props and eVars later.

If you also run Adobe Target, move both together. Adobe doesn't support the Web SDK for Target alongside AppMeasurement for Analytics on the same page, as our Adobe Target implementation guide explains.

How should you build the data layer?

Build a data layer your developers own, so tags read values from one documented object instead of scraping the page. Adobe recommends the Adobe Client Data Layer for new or restructured implementations, though any specification works if your organization sticks to it.

Adobe is clear about who does what. The site development team makes sure the data layer fills with the right values. The analytics team maps those values: to XDM fields on the Web SDK, or to data elements on the Analytics extension. Adobe also notes that data layers are usually generated server-side, from the same objects that build the page content.

A few practices save pain later:

• Push events for actions such as add to cart or form submit, rather than reading the page after the fact.
• Version the data layer specification and keep it next to the SDR.
• Fire a new page or view event on every route change in single-page applications (SPAs).
• Keep names and values consistent across sites, so one rule works everywhere.
• Validate in the browser console before tagging anything.

How should you use eVars, props and events?

Use eVars for almost all custom dimensions, events for metrics, and props only where you need a value that lasts for a single hit. Adobe now says eVars fulfill "almost all use cases for props".

The differences in brief:

• eVars persist beyond the hit they're set on. You control expiration and allocation in report suite settings. Up to 250 are available, depending on your contract.
• Props don't persist beyond the hit. Up to 75 are available, depending on your contract.
• Events count actions. On the Web SDK, custom event fields run up to event1000, and orders, revenue and cart actions map to standard commerce fields.

Configure every variable in report suite settings before you send data to it, then apply naming rules. Give each variable a plain business name and keep its meaning the same in every report suite. Lowercase values where case doesn't matter. "eVar27 misc" is how implementations die.

Processing rules can fix data as it's collected, but treat them with respect. Adobe warns they can cause data loss if used incorrectly, and tells you to test them in a development report suite before production. Log every rule in the SDR.

How should you set up marketing channels?

Follow Adobe's updated marketing channel best practices, which were written to keep reports consistent with Attribution and CJA. In short: analyze with Attribution, drop Direct and Session Refresh channels and enable Override Last-Touch Channel. Then shorten the engagement period and remove rules for disabled channels.

Here's what each means in practice:

• Use Attribution for analysis. Adobe provides generic Marketing Channel and Marketing Channel Detail dimensions to use with any attribution model.
• No Direct or Session Refresh channels. Adobe doesn't recommend them with custom attribution models.
• Override Last-Touch Channel should be enabled for all channels except those two.
• Set the Visitor Engagement period to 1 day, the minimum, and control lookback through attribution models instead.
• Keep processing rules only for enabled channels.

Order your channels with care. A report suite allows up to 25 channels, and Adobe suggests a catch-all "Other Campaigns" channel placed after paid channels and before organic ones. Agree one tracking code format across teams, because channel rules are only as good as the campaign codes they read.

How do you keep bot traffic out of Adobe Analytics?

Turn on IAB bot filtering at a minimum and add custom rules for known crawlers and monitors. Adobe also suggests testing the impact on a small report suite before you touch production.

The standard option uses the Interactive Advertising Bureau (IAB) International Spiders and Bots List, which Adobe updates monthly. Custom rules can match user agents, IP addresses or IP ranges. The interface allows 500 rules, with bulk import for more, and changes take effect within about 30 minutes. Traffic that matches is kept out of your report suite and appears only in the Bots and Bot Pages reports.

Two details surprise people. Hits marked as bots are still billed as server calls. And on the Web SDK, the Edge Network's bot detection only adds a bot score to each event rather than dropping it. Analytics runs its own filtering separately, though both use the same IAB list.

Warn stakeholders before you switch rules on. Removing bots lowers traffic and often raises conversion rates, which can look like a sudden win. For recent changes to bot exceptions on the Web SDK, see our post on segment date range limits and bot exception rules.

How do you handle privacy and consent in Adobe Analytics?

Design consent before go-live, not after a legal review. On the Web SDK, you set a default consent state, update it when the visitor chooses, and label your variables so privacy requests work. Adobe is clear that customers, as data controllers, are responsible for complying with privacy law, so involve your legal team.

The Web SDK's defaultConsent setting takes three values. "in" collects data normally, "out" discards it, and "pending" holds data locally until the visitor opts in. If you don't set it, the default is "in".

Adobe's own example sets "pending" where the General Data Protection Regulation (GDPR) applies and "in" elsewhere. It reads the gdprApplies flag from your consent management platform (CMP).

A few points to plan around:

• defaultConsent doesn't persist between page loads, so set it in every configure call.
• The visitor's choice, set with setConsent, is stored in a cookie and reapplied on later visits.
• The Web SDK supports the Adobe 1.0 and 2.0 standards and the IAB Transparency and Consent Framework (TCF) 2.0.
• Consent in the Web SDK is currently all or nothing, not per purpose.

Label variables in Analytics data governance, such as I1 for directly identifying data and I2 for indirectly identifying data. Better still, keep names and email addresses out of Analytics variables entirely.

How do you QA and document an Adobe Analytics implementation?

Test every change in a development report suite, validate the requests with a debugger, and record what changed. Bad data often comes from small releases nobody checked, rather than from the original build.

Adobe's debugging guidance groups tools into three types. There are Analytics and tag debuggers such as the Adobe Experience Platform Debugger, browser developer tools, and HTTP debugging proxies for apps and other clients. For each release, check a fixed list of pages and actions. Confirm page views, key events, product data and campaign codes, and compare orders against your back office with an agreed tolerance.

Documentation is what lets the next person trust the data. Keep these together, with an owner for each:

• the SDR and data layer specification;
• a log of tag releases and datastream changes;
• processing rules, marketing channel rules and bot rules;
• known data issues, with dates, so analysts can annotate reports.

How do you make Adobe Analytics ready for Customer Journey Analytics?

Adobe's recommended path is a new Web SDK implementation that sends data to Experience Platform, plus the Analytics source connector to bring history across. You then compare old and new data side by side until you're confident.

The source connector is a bridge, not a destination. It copies each hit after processing rules but before visit processing, so fields like visit number aren't included. For production sandboxes, the backfill defaults to 13 months. Adobe says that using the connector on its own isn't a recommended long-term method, citing high latency, cluttered schemas and reliance on Analytics naming.

Readiness work you can start now:

• Build your own XDM schema rather than the Analytics field group.
• Plan identities: the device ID, plus any logged-in ID you'll use to join channels.
• Turn classifications into lookup datasets, and marketing channels into a CJA derived field.
• Recreate privacy labels in Experience Platform, which doesn't copy them from Analytics.

Note one privacy difference. Analytics obfuscates identifiers on a deletion request and keeps the rest of the hit. Experience Platform deletes the matching rows instead, which can change metrics. If you'd like help with the move, the Customer Journey Analytics partner directory lists firms that work with CJA.

Adobe Analytics implementation best practices: what to do next

Use this as a starting audit of your own setup:

• Is there a current SDR with an owner, and does every live variable appear in it?
• Is the data layer owned by developers and versioned?
• Is the collection method chosen with CJA in mind, on your own XDM schema?
• Are variable names and values consistent across report suites?
• Do marketing channels follow Adobe's updated best practices?
• Are IAB bot rules on, with custom rules logged?
• Are consent defaults set per region and variables labelled?
• Does every release go through a development report suite and a debugger check?

When you're ready for outside help, shortlist from the Adobe Analytics partner directory or the filtered partner list, then brief everyone with our Adobe Analytics RFP template.