Directory / plugin
WebDig.DEV Analytics
v1.2.0 · by Joao Costa
Self-hosted Umami analytics, visitor insights, Core Web Vitals and WooCommerce events in your WordPress dashboard.
About this plugin
Connect WordPress to your own HTTPS Umami server. A dedicated reports page and dashboard widget display visits, visitor estimates, page views, average visit duration and bounce rate. Choose 24 hours, 7 days, 30 days or a custom range of up to 366 dates. Visitor, visit and page-view totals include comparisons with the preceding interval of equal duration.
Browse pages, traffic sources, custom events, Core Web Vitals, WooCommerce revenue, browsers, languages, operating systems, devices and visitor countries. A configurable share URL opens the full Umami report in a new tab.
Features:
* Automatic page views and configurable link/button/contact/download events, with the button or link label.
* Optional scroll milestones and form submission attempts; successful Contact Form 7 submissions.
* Official Umami real-user performance collection (LCP, INP, CLS, FCP and TTFB), shown in WordPress with good / needs improvement / poor ratings and the slowest pages.
* WooCommerce product, cart, checkout and purchase events; HPOS compatibility.
* Server-side purchase tracking: paid orders are sent when WooCommerce marks them as paid, including delayed Multibanco and bank-transfer payments, and are not affected by ad blockers.
* Revenue, orders and average order value in the dashboard.
* Campaign attribution: utm_* parameters and ad click IDs are kept; every other parameter, including order keys, is removed.
* Staging protection: only the configured domains and production environments send data.
* Automatic consent detection for the WP Consent API, Complianz, CookieYes and Cookiebot, plus a JavaScript API for other consent managers. Optional Do Not Track / Global Privacy Control support.
* Custom tracker script name for servers that set TRACKER_SCRIPT_NAME, and an internal API URL for Umami on the same server or a private network.
* Server-side report requests, encrypted API keys, capability and nonce checks.
* Shared WebDig.DEV menu and installed-plugin hub, with independent operation.
* Read-only report access by WordPress role or individual site user; settings stay administrator-only.
* Saved-connection diagnostics, tracking exclusions and optional consent-gated tracker loading.
* English source strings with bundled pt_PT, es_ES, fr_FR, de_DE and it_IT PHP and JavaScript translations.
* No analytics data or credentials are sent to WebDig. Data goes to the Umami server you configure.
Requirements: a self-hosted Umami server version 3.2 or later (the Performance and Revenue tabs were verified with Umami 3.4); HTTPS connectivity from visitor browsers to the public server URL. Dashboard access needs an API key or a valid Bearer token. Use a separate Umami account that can only access the relevant website.
External service and privacy
The plugin loads the official tracker from your configured server (by default /script.js). The tracker sends page views, event data, browser/device information and, when enabled, performance measurements to that server. It uses the visitor IP for Umami processing and geographic estimates. With server-side purchase tracking, WordPress sends paid-order events to the same server with the customer IP address and browser user agent stored by WooCommerce, so the purchase joins the visitor’s Umami session. Refer to your Umami server’s privacy policy and configuration. Umami documentation: https://docs.umami.is/docs/ . No central WebDig analytics service is required.
Automatic tracking excludes form values, customer names, customer emails and addresses. Email and phone link events do not include the link text. Tracked URLs keep only the query parameters listed in the settings (campaign parameters by default); fragments and order keys are always removed. External referrers are reduced to their origin. User-supplied custom event data remains the site owner’s responsibility. Add data-webdig-ignore to any element whose clicks should not be recorded.
Purchase deduplication stores an order marker in the visitor’s localStorage. By default the plugin does not wait for consent. Enable “Wait for consent before loading the tracker” to prevent tracker loading and analytics requests until consent is granted. The plugin does not include a consent banner. Its analytics settings do not determine your website’s legal obligations.
Purchase tracking scope
Browser mode (default): purchases are tracked when the order is paid and the customer returns to a valid order confirmation URL. The order key is verified and is not sent to Umami. Reloads are deduplicated in the same browser, but cross-device or cleared-storage duplicates remain possible.
Server mode (recommended): at checkout the plugin records whether the order may be tracked, applying the consent, privacy-signal and role-exclusion settings. When WooCommerce marks the order as paid, the purchase is sent once from the server through Action Scheduler, with up to three attempts; a final failure is noted on the order. Orders created in the admin or through the REST API are not sent. When consent is required, the tracker mirrors consent in a first-party wda_consent cookie, or the WP Consent API is used, so the server can respect it.
In both modes, refunds do not amend the original Umami event. Analytics revenue is not an accounting record.
Legacy AJAX cart events and WooCommerce Blocks events are supported. Non-AJAX product form submissions are recorded as add_to_cart_attempt, not confirmed cart additions. Custom cart extensions can require their own integration.
Portuguese (Portugal) documentation is included in readme-pt_PT.txt. / A documentação em português de Portugal está incluída em readme-pt_PT.txt.
Frequently requested configuration
Consent manager integration
Enable “Wait for consent before loading the tracker”. In automatic mode the plugin follows the “statistics” category of the WP Consent API, Complianz and Cookiebot, and the “analytics” category of CookieYes. Any other consent manager can call window.WebDigAnalytics.setConsent(true) after analytics consent and window.WebDigAnalytics.setConsent(false) when it is withdrawn, after the plugin script has initialized. Before approval no Umami script is inserted, no events are queued and purchase localStorage markers are not accessed. Withdrawal stops subsequent sends; it cannot recall requests already sent. Granting consent again does not create an extra page view. Test your consent manager on the real site.
Tracking exclusions
Select roles to exclude or enter one path per line. /private/* excludes paths with that prefix; /account/ excludes that exact path. Rules use the request path, including any WordPress subdirectory. Clear page/CDN caches after changing tracking, exclusions or consent settings. Existing cached HTML can otherwise retain previous settings; role exclusions require a cache that separates logged-in traffic correctly.
Umami share URLs
Share links are hidden from non-administrators unless you explicitly enable them. A public share URL may permit access outside WordPress; removing report permissions does not revoke a URL someone already knows. Revoke or rotate it in Umami when needed.
Diagnostics and custom periods
Save settings before using “Test saved connection”. Authentication, missing endpoints, network failures and invalid JSON are reported separately, and the test warns when this environment does not send data. Custom dates use the WordPress timezone and include the final date, capped at the current time. Daily buckets are used for longer/custom periods; boundary buckets can be partial. A failed comparison does not prevent current-period data from displaying. Reports are cached for two minutes; no reports are stored permanently in WordPress.
Development
Source tooling (not included in the distributed ZIP): composer install, then composer lint (WordPress Coding Standards) and composer test (PHPUnit). npm test runs the tracker tests in Chromium with Playwright; npm run format applies Prettier. python3 bin/i18n.py regenerates the POT, PO, MO and JSON catalogs. bash bin/build.sh creates the distribution ZIP.