Debug Salesforce Marketing in Chrome DevTools

What Salesforce Marketing traffic looks like

Marketing Cloud shows up as two distinct request families, reflecting the products folded into it. A site can legitimately run both, and mistaking one for the other sends you to the wrong module.

Endpoint pattern

Collect code (Personalization Builder / predictive tracking) sends to collect.igodigital.com (including the tau.collect.igodigital.com variant); Evergage, now Marketing Cloud Personalization (formerly Interaction Studio), beacons to account-specific evergage.com hosts at /api2/event (older setups use /api)

Transport

Collect uses a self-describing URL structure, /c2/<MID>/<action>?payload=<JSON>, so a single URL-encoded JSON query parameter holds most of the interesting data; Evergage events carry the dataset, user ID, and the interaction/campaign data the personalization engine decides on

Key parameters

MID: the account's member ID, in the request path · action names the event: track_page_view, track_cart, track_conversion, track_wishlist, track_event, set_user_info, and a do_not_track opt-out call · payload: URL-encoded JSON carrying the page, product, cart, or user attributes for that action

Debugging Salesforce Marketing with Event Watcher

• The dedicated Salesforce Marketing parser translates Collect actions into human event names: Page View, Cart Update, Conversion, Set User Info, Do Not Track.
• The payload JSON is unpacked, with parameters grouped into Page Context, Configuration, and remaining payload data; Evergage endpoints route through the same parser.
• The MID surfaces so you can confirm which business unit is receiving the data.
• Every request gets the cookies section and the consent verdict.

Salesforce Marketing and consent

The extension checks Salesforce Marketing against the marketing consent category. The Collect code is built for identified tracking: set_user_info explicitly attaches an email or subscriber key to the browsing session, feeding abandonment journeys and Einstein recommendations.

Pre-consent track_page_view, track_cart, or worse set_user_info calls hitting collect.igodigital.com are marked and totaled in the violations counter. One irony worth checking: do_not_track is itself a request. Verify it fires on opt-out and that tracking actually stops.

Common debugging scenarios

• Abandoned-cart journeys not triggering. Filter the stream and confirm track_cart fires with the expected items, and that a set_user_info call has identified the visitor in the same session. Unidentified carts cannot enter the journey.
• Recommendations empty or wrong. Inspect track_page_view payloads on product pages for the catalog attributes the recommendation model keys on.
• Wrong business unit receiving data. Read the MID out of the parsed request path and compare against the intended MID per site or country.
• Collect vs Evergage confusion. Pivot Grouped view by Endpoint to separate igodigital.com traffic from evergage.com traffic before deciding which module to debug.
• Opt-out verification. Trigger the site's opt-out flow, look for the do_not_track action, and confirm subsequent pages produce no further Collect calls. Cross-check other marketing tools like Braze while you are at it.