The Data 360 Web SDK: capturing first-party behavior an agent can actually ground on

Every real-time personalization and agent-grounding pitch runs into the same wall: the model is only as current as the data feeding it, and most customer data arrives in a nightly batch. An agent grounded on last night’s load knows what a customer did, not what they’re doing on your site in this session — the abandoned cart from four minutes ago, the pricing page they’ve now visited three times, the support article they’re stuck on. Closing that gap is exactly what the Data 360 Web SDK exists to do: capture first-party website behavior as it happens and land it in the profile fast enough to act on.

It’s also one of the parts of Data 360 that teams most reliably get stuck on. The SDK is powerful, but the schema model is fiddly, the identity stitching between anonymous and known visitors is subtle, and the difference between “streaming” and “real-time” is a licensing decision that shows up on your credit bill. This post is the practitioner’s build: what the SDK actually is, how the event and identity model works, the 2026 shortcuts that make setup survivable, and the cost and consent realities that decide whether it’s worth turning on.

What it is, and what it’s called this week

First, the naming, because it trips everyone up. The product is the Salesforce Interactions SDK — an extensible data-capture framework with a base SDK plus product-specific modules. The module that authenticates to Data 360 and ships website behavior into it is the Data 360 module (formerly the “Data Cloud module”). So “Data 360 Web SDK,” “Data Cloud Web SDK,” and “Interactions SDK with the Data 360 module” all refer to the same thing — older docs say Data Cloud, current material says Data 360. It’s the same rename that turned Data Cloud into Data 360, applied to the SDK.

Its job is to capture engagement and profile data from your website — for both known and anonymous visitors — and stream it into Data 360, where it becomes part of the unified profile that segments, insights, and agents read from. The anonymous half is the part people underrate: the SDK collects behavior before a visitor ever logs in, so when they finally authenticate you already have their pre-login journey to associate to the known profile.

The event model: two categories, and why it matters

Events split into two categories, distinguished by a category field on the schema, and understanding the split is most of understanding the SDK:

• Engagement events are behavioral — page views, clicks, cart interactions, the clickstream. Critically, all of your engagement events flow into a single data stream, conventionally named something like <connector>-Behavioral events.
• Profile events are identity — who this person is. Each profile event you configure gets its own data stream.

That asymmetry — one shared stream for all behavior, one stream per identity event — is a design fact you build around, not a setting you change. Inside the single behavioral stream, the field that does the real work is eventType: it’s the discriminator that routes each event from the shared stream to the correct destination data model object (DMO). Get eventType wrong and your page views land in the wrong place; omit a required field and Data 360 rejects the event outright.

The SDK auto-injects a set of mandatory fields into every payload so you don’t hand-populate them: category, dateTime, deviceId, eventId, eventType, and sessionId. One more mechanical detail worth knowing before you debug anything: SDK payloads are nested, but Data 360 events are flat. On ingest, the Data 360 module walks the nested structure and flattens it into a single row of columns on the target DMO. When a field you expected doesn’t show up downstream, this flattening step is often where it went.

Configuring capture: schema, sitemap, and standard events

Two artifacts drive what gets captured. The schema is a JSON file describing your event types and their fields — the contract for what a valid event looks like. The sitemap is a set of JavaScript data-collection rules that map page elements and behaviors to schema fields — the glue between “a user clicked this button” and “emit this structured event.”

The SDK ships standard interaction names — View Catalog Object, Add To Cart, Purchase, and others — that trigger pre-built transformation logic in the Data 360 module, so common commerce and content behaviors don’t need bespoke handling. A minimal sitemap rule to capture a product view looks roughly like this:

SalesforceInteractions.init({
  consents: [/* consent signals — see below */]
}).then(() => {
  SalesforceInteractions.sendEvent({
    interaction: {
      name: 'View Catalog Object',
      catalogObject: {
        type: 'Product',
        id: getSku(),                 // your page's product SKU
        attributes: { category: getCategory() }
      }
    }
  });
});

The corresponding schema entry declares the event type and its fields as JSON, and the eventType on that schema is what steers the flattened row to the product-view DMO. Keep the two in sync: the schema is the contract, the sitemap is the implementation, and a mismatch between them is the single most common reason events either get rejected or land somewhere unexpected.

The 2026 shortcut: the GA4 connector

Historically, authoring that schema and sitemap by hand is where Web SDK projects went to die — a genuinely web-developer-grade task that could take days or weeks and stalled on the boundary between the marketing team who wanted the data and the front-end team who had to instrument it. The 2026 answer is the GA4 Website Connector, now generally available, and it’s a real change in who can do this work.

The GA4 connector uses your existing GA4 standard and recommended events to auto-configure the schema, largely eliminating the manual schema-and-sitemap authoring, and it integrates directly with Google Tag Manager to publish the Data 360 tag without hand-editing site code. Practitioners report it collapsing setup from the old “days or weeks” to “minutes to a few hours,” and — more importantly — moving the work from web developers to the CRM admins and marketers who actually own the use case. There’s one boundary worth knowing up front: the GA4 connector can only track events pushed to the GTM data layer. GA4’s automatically-collected events that never hit the data layer aren’t visible to it, so anything you need that isn’t in the data layer still requires deliberate instrumentation.

Even with the connector, the durable advice from teams who’ve done this is to implement progressively: rather than defining your entire event schema upfront, deconstruct it into discrete files — one per event type — and start with a single foundational behavioral event like standard page-view engagement. Get that landing cleanly end to end, then add event types one at a time. A big-bang schema is a big-bang debugging session.

Identity: from anonymous device to known profile

Here’s the mechanism that makes pre-login behavior worth capturing. On a visitor’s first arrival — or whenever their identifier changes — the SDK assigns a new anonymous device identifier and sends a blank initial profile event. From then on, every behavioral event that visitor generates carries that deviceId, and Data 360 instantiates a new Individual per unique device. The person is a ghost, but a ghost with a consistent handle and an accumulating clickstream.

When that visitor authenticates, you dispatch a partyIdentification event carrying their CRM identifier:

SalesforceInteractions.sendEvent({
  user: {
    identities: {
      // ties this device's history to the known CRM record
      partyIdentification: { salesforceId: getLoggedInContactId() }
    }
  }
});

That event populates the Party Identification DMO, which is what your identity resolution rulesets use to unify the anonymous device with the known person. The anonymous browsing history and the authenticated profile collapse into one unified profile, and — this is the payoff — the pre-login behavior is now attached to a customer an agent or a segment can actually reason about. The quality of that stitch is entirely a function of your match rules, which is why the identity-resolution discipline we’ve written about separately isn’t optional here; a loose ruleset over-merges devices, a strict one strands anonymous history that should have been claimed.

Streaming versus real-time: a licensing decision, not just a speed one

This is the distinction that determines whether the “real-time” promise is real for your use case, and it’s easy to conflate two different things.

Standard streaming ingestion — the default path for the Ingestion API and Web SDK — processes events in micro-batches roughly every few minutes and is eventually consistent; you allow a short settling window before the data is queryable. That’s near-real-time, and it’s fine for streaming insights, audience refreshes, and most personalization. It is not sub-second.

Real-Time Ingestion and Actions is a separate, faster path, gated behind the Sub-Second Real-Time Profile and Entities entitlement. Salesforce states that with it, roughly 95% of events complete end-to-end — capture through activation in the real-time layer — within about 500 milliseconds, across Web SDK, Mobile SDK, and server-to-server channels. Treat those as Salesforce’s own figures, but the architectural point stands: genuine sub-second grounding is a distinct, separately-licensed capability, not something the default Web SDK setup gives you for free.

Why it matters for agents: the whole reason to capture behavior in real time is to ground an agent on state that’s current to now. That grounding runs through data graphs — the relationship-aware profile that lets an agent reason across a customer’s core record, live engagements, and predictive scores as one dataset. If your use case is “the agent should know about the itinerary the customer changed ninety seconds ago” — the kind of thing that decides a real-time travel or service agent — then near-real-time streaming may not be tight enough, and the sub-second SKU is the line item that makes it work. If your use case is “refresh the abandoned-cart audience every few minutes,” standard streaming is both sufficient and cheaper. Decide which one you’re actually building before you architect for the expensive one.

The credit bill: behavior is high-volume, and streaming costs more

Behavioral data has a property that makes it a credit-consumption trap if you’re not deliberate: there is a lot of it. Every page view, every scroll, every click is an event, and website traffic dwarfs your CRM write volume. That collides with a Data 360 pricing fact we’ve covered in the credit-optimization playbook: streaming ingestion is materially more expensive than batch. On the rate card, external data ingestion runs on the order of 2,000 credits per million rows in batch against roughly 5,000 streaming — and real-time web capture is, by definition, on the expensive side of that line.

Put a rough number on it: an illustrative two million cart-interaction events ingested via streaming lands in the neighborhood of ten thousand credits — and that’s a modest volume for a busy site. So behavioral event capture absolutely consumes credits, streaming consumes more of them, and the meter runs continuously with your traffic. The current rate-card treatment of engagement events specifically has shifted over the product’s life, so verify the live rate sheet for any hard number — but architect as if every behavioral event is a metered row, because it is. The practical mitigations are the familiar ones: capture the event types your use cases actually need rather than everything the connector can emit, keep engagement-data lookback windows as short as the use case allows, and reserve the sub-second path for the handful of journeys where in-session latency genuinely changes an outcome.

Consent and debugging: the two things that waste a week

Two operational realities cause most of the lost time on Web SDK projects, and both are worth knowing before you start.

The first is consent. The SDK has a built-in consent mechanism — no events are sent until consent is available. This is correct behavior for privacy, and it’s also a debugging trap, because a consent problem and a broken schema produce the identical symptom: no data landing. Before you tear apart your sitemap looking for a bug, confirm consent is actually being granted and passed to the SDK. A large share of “the events aren’t showing up” tickets are consent, not code.

The second is debugging discipline. Turn on the SDK’s verbose logging and watch for the Sending events and Sent event debug lines to confirm the client is actually emitting before you go hunting downstream in Data 360. And know the sharp edge: sitemaps cannot listen to DOM events inside Web Components, because shadow-DOM encapsulation hides them from the collection rules. If your product pages are built on web components and your click events silently never fire, that’s why — and no amount of schema tuning fixes it.

What to actually do

If you want an agent or a personalization surface grounded on live behavior, the Web SDK is the mechanism, but sequence it so you don’t drown. Start with the GA4 connector rather than hand-authoring a schema — it’s the difference between a marketer shipping this in an afternoon and a multi-week front-end project — and implement progressively: one foundational event, landing cleanly, before you add the next. Get the identity stitch right early, because pre-login behavior you can’t attach to a known profile is data you paid to collect and can’t use; that means treating your identity-resolution rulesets as a first-class part of the build, not an afterthought. Decide honestly whether you need genuine sub-second real time or whether near-real-time streaming is enough, because that choice is a licensed SKU and a materially different credit profile, not a config flag. And validate consent and client-side emission first whenever data doesn’t appear, before you suspect the schema.

Do that, and you close the gap between what a customer did last night and what they’re doing right now — which is the whole point of grounding an agent on Data 360 in the first place. Skip the sequencing and you get a half-instrumented site, an over-merged profile, and a streaming bill for events nobody reasons over. The behavior is worth capturing. The discipline is what turns it into something an agent can actually use.

Understanding the basics

What is the Data 360 Web SDK?

It’s the Salesforce Interactions SDK with the Data 360 module — a JavaScript SDK that captures website engagement (behavioral) and profile (identity) data for both anonymous and known visitors and streams it into Data 360. Behavioral events flow into a single shared data stream routed by an eventType field; profile events each get their own stream. The captured behavior becomes part of the unified customer profile that Data 360 segments, insights, and Agentforce agents ground on.

How does the Web SDK connect anonymous browsing to a known customer?

On first visit the SDK assigns an anonymous device identifier and captures behavior against it, instantiating an Individual per device. When the visitor logs in, you send a partyIdentification event carrying their CRM ID, which populates the Party Identification DMO. Identity resolution rulesets then unify the anonymous device history with the known profile, so pre-login behavior is attributed to the real customer. The accuracy of that stitch depends entirely on your match rules.

Does capturing website behavior in Data 360 cost credits?

Yes, and more than you might expect, because behavioral data is high-volume and streaming ingestion costs more than batch — on the order of 5,000 versus 2,000 credits per million rows on the rate card. Every page view and click is a metered event, and the meter runs with your traffic. Genuine sub-second real-time capture is a separately-licensed entitlement on top. Capture only the event types your use cases need, keep lookback windows short, and verify current figures against the live rate sheet.

---

Standing up real-time behavioral capture to ground an agent or personalize in-session, and want the schema, the identity stitch, and the streaming-credit math right the first time? Talk to us — building the Data 360 foundation that agents actually reason on is exactly the work we do.