Debug Piwik Pro Analytics in Chrome DevTools

What Piwik PRO traffic looks like

Piwik PRO speaks the same Tracking API protocol as Matomo (the two share a codebase ancestor), but the traffic is easy to tell apart.

Endpoint pattern

Hits go to the customer's instance at <account>.piwik.pro/ppms.php (or /piwik.php on older containers); the tag manager and consent container load from containers.piwik.pro

Transport

GET requests, or POSTs for larger payloads

Key parameters

idsite a UUID rather than Matomo's small integer (the quick tell) · action_name/url page-view context · e_c/e_a/e_n/e_v custom event category, action, name, value · _id visitor ID · uid user ID · _idn=1 new visitor

Consent signals

uia anonymous-tracking flag, which tells you Piwik PRO's privacy mode is actually on for this hit; other consent parameters describe consent form actions and category decisions, since the suite's own Consent Manager reports through the same pipeline

E-commerce

ec_items, revenue, idgoal carry the e-commerce and goal payloads

Debugging Piwik PRO with Event Watcher

• The Piwik PRO parser derives a per-hit event name (page view, custom event, goal, e-commerce order) and groups parameters into identifier, browser, e-commerce, and request sections.
• Specific to this platform, consent data is extracted: consent categories and actions decode into readable labels, and the uia anonymous-tracking flag is surfaced explicitly.
• URL patterns are anchored on piwik.pro, so hits are attributed to Piwik PRO and never confused with a self-hosted Matomo install, even on sites running both during a migration.

Piwik PRO and consent

The extension checks Piwik PRO against the analytics consent category, a special case since Piwik PRO ships its own Consent Manager and the analytics tool and the CMP can be the same vendor.

Its documented pre-consent behavior is anonymous tracking: hits fire before a decision with uia=1 and no visitor cookie, then de-anonymize after consent, so early hits are technically pre-consent but flagged anonymous.

The real question is whether they carried uia=1 and dropped the flag after acceptance; the decoded consent section answers both.

Common debugging scenarios

• Verifying anonymous mode. Load fresh, don't touch the banner, and check uia on every hit. A pre-consent hit without the flag means the container's privacy setting isn't doing what the DPO was told.
• Consent form events vs analytics events. The consent-action hits travel over the same ppms.php endpoint; the parsed consent section separates them from page traffic.
• Migration from self-hosted Matomo. Both platforms fire the near-identical protocol; the extension splits them by pattern so you can compare idsite values (UUID vs integer) and retire the old tracker confidently.
• Goal conversions missing. Check idgoal and revenue on the wire before opening a support ticket.
• Multiple containers on one site. Compare the UUID idsite per hit across page sections in Grouped view to spot the stray second container.