Adobe Client Data Layer (ACDL)

What Is a Data Layer left off at a clean breaking point. The CEDDL digitalData object is a photograph of the page, painted once at load. On a traditional site that is fine, because every click loads a fresh page and repaints it. But a single-page application never reloads, so the moment it swaps from the product view to the cart without a page load, the photograph is stale: the shopper is on the cart, the data layer still describes the product.

The Adobe Client Data Layer fixes this by changing what the data layer fundamentally is. Instead of one snapshot you keep overwriting, it is an array you only ever add to, a running log of what happens, plus a current state that ACDL keeps merged and up to date for you. The fastest way to understand it is not more theory. It is to follow one real thing all the way through. So walk a shopper adding items to a cart, from the developer's first line of code to what you see in the console to what you set up in Launch.

Step 1: the developer declares it

It starts, as before, as just a variable, except this time the variable is an array.

window.adobeDataLayer = window.adobeDataLayer || [];

That single line means "use the adobeDataLayer array if it already exists, otherwise start an empty one." It matters because your tracking library and your page code load independently and either can arrive first. Written this way, nothing you push ever gets wiped out by load order. From here on, the developer adds to the log with .push(), the ordinary array method.

Step 2: something happens, so the developer pushes

First, the steady facts about the page get pushed once. These are state, and they persist:

adobeDataLayer.push({
  page: { name: "Product Detail", type: "product" },
  user: { loginStatus: "logged-in" }
});

Now the shopper clicks "Add to cart." At that exact moment, the developer fires a push describing the event. Notice where the product sits, this is the single most important detail in the whole section:

adobeDataLayer.push({
  event: "cartAdd",
  eventInfo: {
    product: { id: "SKU-123", name: "Blue Widget", price: 49.0, qty: 1 }
  }
});

There are two places data can go in a push, and they behave differently. Anything at the top level (like page and user above) gets merged into the persistent state and stays there. Anything inside eventInfo rides along with this one event and is not kept in the state afterward. The product goes in eventInfo on purpose, and the next step shows exactly why that choice matters.

Step 3: see it, in the console

This is where it becomes real, because you can watch it. Open the browser console and ask for the current state, the same instinct as typing digitalData there:

> adobeDataLayer.getState()

< {
    page: { name: "Product Detail", type: "product" },
    user: { loginStatus: "logged-in" }
  }

Look closely: the product is not there. The cartAdd event fired and carried the product with it, but because the product was in eventInfo, it was never written into the state. getState() only ever returns the persistent snapshot, the page and the user.

Now the shopper adds a second item, a green widget, which fires another cartAdd. Ask the console again:

> adobeDataLayer.getState()

< {
    page: { name: "Product Detail", type: "product" },
    user: { loginStatus: "logged-in" }
  }

Still just page and user. Two add-to-cart events have happened, and the current state shows neither product. So where did those two events go, and this is the question you were probably asking yourself the entire last section: if the state only holds the present, why keep a history at all?

getState, and what the event did not write into it

⤢

Read the two results against each other, because the gap between them is the whole argument. The array above holds ten entries and every one carries an event key naming what happened. The object below, returned by getState(), holds page, account, cta and web, and no event anywhere in it. That is not a display quirk. State is only what the pushes left behind; the event that carried them is not part of it, which is why a rule reading state alone can never tell you what just happened.

Where the history actually earns its keep

Here is the honest answer, and it is worth being precise about, because it is easy to oversell. The data layer's history is not a database. Adobe Analytics and CJA store your history for the long term downstream, that is their job, not the data layer's. The log in the browser is something narrower and genuinely useful: it is working memory for the current session, and it earns its place in exactly three situations.

First, a listener that arrives late still catches what it missed. This is the timing problem from that section, solved by design. You register a handler for the event, and by default it fires for matching events whether they happened in the past or the future:

adobeDataLayer.push(function(dl) {
  dl.addEventListener("cartAdd", function(event) {
    var product = event.eventInfo.product;  // this event's product
    var context = dl.getState();             // current page and user
    // build and send the analytics hit for THIS add-to-cart
  });
});

Because the default reaches into the past, if both cartAdd events already happened before this listener registered, it fires twice the instant it attaches, once for each, and your analytics catches both. Remember the empty-glass-before-the-tap trap, where firing the signal before the data was ready silently lost the hit? It largely disappears here. The log kept both events, so a listener can never truly be too late. That is the replay described earlier, made concrete.

Second, debugging. Mid-session, in a real browser, you can call getState() at any moment to see the current truth, and attach a listener with the past scope to replay everything that already fired, in order. When a tag misbehaves, being able to ask the page "what actually happened, and in what sequence" without a single server round-trip is worth a great deal.

Third, custom logic that needs earlier context. Suppose at checkout you want to know something about the journey that led here. Because the session's state is sitting right there in getState(), your code can read it directly instead of re-fetching from a server. The history and the merged state are local, immediate, and free to read.

There is a shortcut that suggests itself at exactly this point, and it is worth refusing before you reach for it. Clearing a branch with a null push is deliberate and narrow. Emptying the whole array by assigning a fresh one looks like the same idea, only tidier.

Step 4: catching it in Launch

This is where the data layer gets consumed, and it is the modern replacement for the manual _satellite.track() torch that What Is a Data Layer called a legacy method. In Launch you install the Adobe Client Data Layer extension, and then a rule looks like this:

So the persistent state and the event's own data come from two different places, on purpose: Computed State for the steady context, %event.message.eventInfo% for what just happened. The deep mechanics of building rules and data elements belong with Adobe Launch (Tags). The shape is the point here: the page narrates events into the log, and Launch subscribes to the ones it cares about, no torch required.

The honest cost, in one line

ACDL is not a pure upgrade. It asks more of everyone: more code, a real discipline about what belongs in persistent state versus eventInfo (get it wrong and a stray top-level push silently overwrites state), and a tighter partnership with developers who must structure every push deliberately. What you buy for that effort is a data layer that survives single-page applications, defuses the timing race by design, and feeds cleanly into the Web SDK and the Edge.

The two models, side by side

So do you actually need it?

Whether that trade is worth it for your site is a genuine decision, not a foregone conclusion, and it deserves far more than a paragraph. That is exactly what Do You Really Need ACDL? takes on: not whether ACDL works, which you now understand, but whether you actually need it. Whichever way it lands, hold on to one thing. The data layer is the most human part of the whole pipeline, an agreement between the analytics and engineering teams, and quietly the most decisive thing in the entire implementation.