I’ve been waiting for this one.

Customer Journey Analytics B2B edition now supports person-to-account stitching, and it does something B2B analysts have been assembling by hand for years: it lets you analyze the journey the way a B2B business actually thinks about it. Not “who viewed the pricing page,” but “which accounts are showing intent right now, and what are the six people inside them doing about it.”

That shift — from person as the unit of analysis to account as the unit of analysis — sounds like a reporting preference. It isn’t. It’s a data modeling decision, and CJA now makes it a native one.

So What Is It, Exactly?

Person-to-account stitching enriches your event datasets with account identities, so that events arriving without an account ID still land in the right account. Somebody hits your site anonymously, reads three product pages, downloads a paper, and eventually authenticates. In a B2C world you’d elevate that behavior to a person and call it a win. In B2B, the person is the middle of the story. The account is the story.

Stitching closes that gap by deriving the account ID for events that arrive without one, so those events land in the account they belong to rather than sitting outside your account-level analysis.

How It Works: Two Moves, In Order

The mechanic is elegant because it borrows something you may already understand.

Move one: elevate the person. Using the identity graph, a persistent person ID — an ECID, typically — is elevated to a configured person identifier namespace, most often Email. If you’ve implemented B2C stitching in CJA, this is the same motion you already know. Anonymous behavior gets attached to a known person.

Move two: find the account. That elevated person ID is then matched against a person-to-account mapping dataset, which returns the account ID. Missing account identities get added. If an event already carries an account identity of its own, that serves as the fallback when the lookup doesn’t return a match.

Two steps, strictly sequential. The second one depends entirely on the first landing cleanly, which is a useful thing to keep in mind when you’re deciding which namespace to elevate to.

The Mapping Dataset Is the Star

This is where the design work lives.

The person-to-account mapping dataset is a lookup dataset — record, non-time-series — and it needs remarkably little:

• A person ID field, with namespace, marked as an identity in the schema
• An account ID field
• Optionally, a mapping creation time field

That’s it. Three columns, one of which is optional, and they carry the entire relationship model between your people and your accounts.

On the event side, any dataset you enable for stitching needs a persistent person ID field, and can optionally carry an account ID field of its own that serves as the fallback described above.

Configuration happens at two levels. At the connection level, you set the Primary ID to Account, choose your person identifier namespace, point at the mapping dataset, and map the fields. At the dataset level, you enable stitching for each event dataset individually and name its persistent person ID field.

Accounts Move. Your Data Can Move With Them.

That optional creation time field deserves its own paragraph, because it’s doing something genuinely thoughtful.

People change accounts. Your champion at one company turns up at another one eighteen months later. A subsidiary gets absorbed. A contact moves from the parent org to a regional division. Without a timestamp on the mapping, that history flattens — every event that person ever generated belongs to whichever account they’re attached to today.

With a creation time field, the mapping becomes temporal. Adobe’s documentation describes it as useful for scenarios where a person switches accounts over time, and the example bears that out: events before the mapping date resolve to one account, events on and after it resolve to the next. Your historical account analysis stays honest, and your current-state analysis stays current.

If your CRM already tracks relationship start dates — and in most B2B stacks, something does — you have what you need to populate this. It’s worth the effort.

What You Decide Up Front, Stays Decided

A few operational realities worth planning around. Once a connection is saved with B2B stitching configured, that configuration is locked — including any optional container selections. And the mapping dataset is load-bearing: deleting it invalidates the connection.

So this is a decision to make deliberately, with your data architect in the room, before anybody clicks save. Which namespace? Which account ID — the CRM account ID, the parent org ID, the billing entity? What’s the grain of “account” in your business, and does everyone in the room agree on it?

On cadence: stitching updates short-term data weekly, covering the last seven days, and long-term data monthly, covering a window that varies by package. Identity mappings are derived from the mapping dataset daily. Plan your validation windows accordingly — a mapping you add today shows up in the derivation tomorrow and in the stitched history on the next cycle.

Worth noting that the B2B edition and the long-term window are both licensing questions, and the specifics depend on your agreement. Your Adobe account team can tell you exactly where you sit before you scope any of this.

One more, for the governance-minded: when a person identity is removed through a privacy or hygiene request, the stitching associated with that person is reversed. The B2B entities themselves — accounts, account IDs — are not removed, because they carry no personally identifiable information. That’s a clean separation, and a defensible one.

This Is What the Taxonomy Work Was For

Back in 2024 I wrote a piece called Nothing is Certain Except Data and Taxonomies, arguing that classification is the unglamorous work that makes everything downstream possible. Campaign hierarchies. Product taxonomies. Channel structures. The stuff nobody puts in the keynote.

Look at what person-to-account stitching actually asks of you. A person identifier you’ve standardized on. An account identifier you’ve agreed to define one way. A mapping between them that someone maintains. A timestamp that reflects a real relationship.

That’s a taxonomy. It’s the same discipline, pointed at identity instead of campaigns, and it’s now the thing that determines whether a sophisticated analytics capability works on your data or works on somebody else’s.

Which is the part I find genuinely satisfying. The organizations that did the boring work — the ones who settled on a single account ID convention, who kept the CRM relationship data clean, who resisted the urge to let six teams define “account” six ways — get to turn this feature on and see it work. The structure was already there. CJA just gave it somewhere to go.

Taxonomy work has always been an investment on a delay. This is one of the returns.

Where to Start

If you’re evaluating this, three questions get you most of the way:

1. What is an account in your business? Parent, subsidiary, buying group, billing entity. Pick one, write it down, and check whether your CRM agrees.
2. Which person namespace carries the most coverage? Email, usually — but verify against your identity graph before you commit, because the elevation step is the foundation for everything after it.
3. Can you produce the mapping dataset today? Person ID, account ID, relationship start date. If the answer is “almost,” that gap is your first sprint.

Account-level journey analysis has been the ask in every B2B measurement conversation I’ve been part of. It’s here, it’s native, and the price of admission is structure you were better off having anyway.

---

What’s your account definition? I’d like to hear how teams are landing on it — reach out at Katie@DataOnTrend.com or find me on LinkedIn.