What Salesforce Data Cloud traffic looks like
Salesforce Data Cloud has been renamed twice, from Customer 360 Audiences to Salesforce CDP to its current name, and its browser-side ingest is easy to miss because it does not use a shared vendor hostname. Each org gets its own subdomain.
- Endpoint pattern
- Web SDK ingest runs on per-tenant subdomains of
c360a.salesforce.com. The subdomain is specific to the org, which means the hostname itself identifies which Data Cloud tenant a page is feeding - Transport
- JSON POSTs carrying interaction events from the Web SDK
- Client API
SalesforceInteractions.init({ … })followed by interaction events. The SDK's sitemap configuration maps URL patterns to page types, so much of what gets sent is decided by configuration rather than by explicit calls in the page's own code- Key parameters
- The interaction name and event type, the page type resolved from the sitemap, and the identity fields the implementation chose to attach
- Notes
- Because the sitemap does the work, a page can be sending events that no developer on the project explicitly wrote. The network view is often the only place the actual behaviour is visible
Debugging Salesforce Data Cloud with Event Watcher
- No dedicated parser. Requests are matched by hostname, named Salesforce Data Cloud, badged with the Customer Data Platforms category, and shown with parsed query and body parameters plus cookies set and sent.
- The tenant subdomain is the first useful fact and it is free: read it from the request host to confirm which Data Cloud org receives the data. On sites that have migrated between orgs, this is where a stale configuration shows up.
- The sitemap-driven behaviour is the reason to watch rather than read the code. Group by Page and compare the page types being reported against what the sitemap is supposed to resolve, which is the fastest way to find a rule matching more URLs than intended.
- Script Tree attributes the SDK to the site's own code, a tag manager, or another script.
Salesforce Data Cloud and consent
Analytics consentEvent Watcher checks Salesforce Data Cloud against the analytics consent category.
Data Cloud sits in an uncomfortable spot for consent classification. The collection is analytics-shaped, which is what the extension checks it against, but the platform's purpose is unifying identities for activation, and the same events can power marketing journeys. If your implementation attaches identity fields to interactions, the analytics classification is doing less work than it appears to, and gating with the marketing stack is more defensible. The request body is what settles it.
Common debugging scenarios
- No data reaching Data Cloud. Confirm requests to the tenant subdomain exist at all. Silence here usually means the SDK never initialized rather than a mapping problem.
- Wrong tenant. Read the hostname. A subdomain from a previous org is the classic post-migration leftover.
- Events on unexpected pages. The sitemap is matching more broadly than intended. Group by Page to see the actual spread.
- Identity not resolving. Check whether identity fields are present on the interaction at all before investigating the resolution rules in Data Cloud.
- Events fire before consent. Filter to the platform and read the consent verdict on the first ingest request.