Debug ActiveCampaign in Chrome DevTools

What ActiveCampaign traffic looks like

ActiveCampaign's site tracking is unusual in one respect that explains most of the confusion around it: it only records visits for contacts it can already identify. An anonymous visitor produces traffic and no data.

Endpoint pattern

Site tracking posts to trackcmp.net; account assets, forms, and scripts come from app-us1.com or app-eu1.com, where the us1 and eu1 part is the account's data region and is visible in every request

Transport

Beacon requests carrying the account id and the visited URL, sent per page view once tracking is active

Client API

The vgo queue: vgo('setAccount', '<account id>'), vgo('setTrackByDefault', true), then vgo('process')

Key parameters

The account id identifies the ActiveCampaign account · the visited URL is the payload · the contact identity comes from a previous form submission or an email link click rather than from the page itself

Debugging ActiveCampaign with Event Watcher

• No dedicated parser. Requests are matched by hostname, named ActiveCampaign, badged with the Marketing Automation category, and shown with parsed query and body parameters plus cookies set and sent.
• The data region is readable straight from the hostname. An app-eu1.com request means the account is on European infrastructure, which is the kind of thing a data-flow record should state as observed rather than assumed.
• The account id on the tracking call confirms which ActiveCampaign account a site reports to. Two ids means two installations, usually one in the theme and one in a tag manager.
• The Cookies section is where the identification question gets answered: ActiveCampaign's tracking cookies are what carry the visitor between an email click and a later visit.
• Script Tree attributes the tracking script to the site's template, a tag manager, or another script.

ActiveCampaign and consent

Event Watcher checks ActiveCampaign against the marketing consent category.

The classification is right and the reasoning is worth spelling out, because "it is just page tracking" is a common defence of leaving this one ungated. Site tracking exists to attach browsing history to a named contact record and to trigger automations from it. That is marketing processing by purpose, whatever the individual request looks like. The check is whether any trackcmp.net request appears before marketing consent, on the pages a contact actually lands on from an email, which is where this tool does its work.

Common debugging scenarios

• Site tracking shows nothing in ActiveCampaign. The usual cause is not a broken install. Tracking only records visits for identified contacts, so an anonymous test visit correctly produces nothing. Test by arriving through a tracked email link.
• Tracking works for some visitors only. Same mechanism, seen from the other side. Check the cookies to see whether the visitor carries an identity at all.
• Nothing fires anywhere. Confirm vgo('process') actually ran by looking for the trackcmp.net request. A missing setTrackByDefault leaves tracking off.
• Wrong account receiving data. Compare the account id across requests.
• ActiveCampaign fires before consent. Filter to it and read the consent verdict on the first tracking request.