Debug Bloomreach in Chrome DevTools

What Bloomreach traffic looks like

Bloomreach's customer data platform is the former Exponea, and the SDK still carries that name on the wire. It is worth knowing before debugging, because the hostnames a page shows will not match the vendor name anyone said out loud.

Endpoint pattern

The SDK loads from cdn.exponea.com and reports to api.exponea.com, with regional API variants in use depending on where the project is hosted; bloomreach.com and exponea.com hosts are matched more broadly

Transport

JSON POSTs for tracking, identification, and customer-attribute updates, plus separate calls that fetch personalization content to render on the page

Client API

exponea.initialize({ target, token }), then exponea.track('event', { … }), exponea.identify({ registered: … }), and exponea.update({ … }) for customer attributes

Key parameters

The project token identifies the workspace and appears in the SDK initialization · the registered identifier passed to identify is usually an email address · event name and properties on each track call

Notes

Bloomreach also renders weblayers, its on-page personalization banners, so it is not only collecting. It can modify the page, which puts it in the same flicker and timing territory as an experimentation tool

Debugging Bloomreach with Event Watcher

• No dedicated parser. Requests are matched by hostname, named Bloomreach, badged with the Customer Data Platforms category, and shown with parsed query and body parameters plus cookies set and sent.
• The identify call is the one to open. registered typically carries an email address, so this is the request where a browsing session becomes a named person, and it is worth knowing exactly when in the page lifecycle that happens.
• Grouping by Endpoint separates ordinary tracking from the personalization fetches, which is what tells you whether a weblayer failed to render because the content never arrived or because it arrived and was suppressed.
• The __exponea cookies in the Cookies section carry the visitor identity that ties anonymous browsing to the later identification.
• Script Tree attributes the SDK to the site's own code, a tag manager, or another script.

Bloomreach and consent

Event Watcher checks Bloomreach against the marketing consent category.

The awkward part of gating a commerce CDP is that one SDK does the measuring and the merchandising. Hold it for consent and personalization does not render; release it and a marketing-category tool collects before a decision. Teams usually load the SDK in a restricted mode and release full tracking on consent, which is reasonable and easy to believe without checking. What is verifiable is whether any track or identify call reached api.exponea.com before the CMP answered.

Common debugging scenarios

• Events are not appearing in the project. Confirm the project token in the initialization matches the intended workspace. Two tokens on one site means two projects receiving split data.
• Customers stay anonymous. Look for the identify call and read the registered value. Without it, every session is a separate anonymous customer.
• A weblayer does not show. Check whether the personalization fetch happened at all before investigating targeting rules.
• Attributes not updating. Open the update call and confirm the attribute names match what the project expects.
• Bloomreach fires before consent. Filter to Bloomreach and read the consent verdict on the first API call, not on the CDN load.