Ponte Analytics for Umami

Yes. Ponte Analytics for Umami connects to a self-hosted Umami instance that you control - it does not include or host analytics itself. See umami.is to get started.

No. The plugin is entirely client-side: the tracker script in your visitors' browsers sends data directly to your own Umami instance. Nothing passes through, or is stored on, any server operated by nquare.

Enter the full script URL instead of just the host. Umami's tracker script name does not need to end in .js and can be any path you choose - for example https://example.com/analytics/app or https://example.com/stats/script.js. If your Umami installation lives at a nested base path and you have not renamed the script, make sure the Host URL ends with a trailing slash (e.g. https://example.com/analytics/) so the plugin knows it's a folder, not a script name.

A few common causes: (1) your own account's role may be excluded from tracking by default - Administrator, Editor, and Shop Manager are excluded out of the box on the Advanced tab, so test as a logged-out visitor or in a private/incognito window; (2) an ad blocker or privacy extension in your browser may be blocking the tracker script or its requests; (3) double-check the Host URL - if Umami is in a subfolder or the tracker script was renamed, see the FAQ above.

Yes. The plugin declares full compatibility with HPOS and uses WooCommerce's order API (not raw post meta) to track purchases, so it works correctly whether HPOS is enabled or not.

When WooCommerce considers the order paid - that is, once its status is Processing or Completed. Orders awaiting an offline payment (bank transfer, cheque, and similar "pay later" methods) are not counted at checkout time, since they aren't paid yet; they are counted if and when the customer returns to the order-received page after the order has been marked paid. Marking an order Completed is a fulfilment step, not what triggers the event - an order already sitting in Processing is already paid and already counted.

The purchase event was already sent to Umami at the time of the sale, and this plugin is purely client-side - it has no way to retract an event once sent, and Umami's tracker doesn't offer one either. A refunded order's revenue therefore stays in your Umami revenue report. Refunding an order does not send a second event.

If your site uses a full-page caching plugin, make sure your order-received (thank you) page is excluded from the cache. A cached copy of that page would replay the same purchase event to every later visitor who happens to land on it. Most caching plugins already exclude WooCommerce cart, checkout, and account pages by default - just double-check the order-received page specifically.

Rarely, and only in one specific way. The plugin already ignores prefetch requests for the order-received page, so a prefetch alone never consumes the one-shot tracking flag. But if the browser later reuses that prefetched response to serve the actual page view (no second request is made), the visitor sees a page with no purchase event - the flag stays unburned, so a reload of the same page still tracks it correctly. This is a bounded, self-healing edge case: the order-received page is reached via a checkout redirect, which is rarely a prefetchable link in the first place.

Contact Form 7 and WPForms. A successful submission of either fires a custom Umami event that you name and configure from the form's own editor - a validation error or a failed submission never fires it. WPForms confirmations that redirect off your own site are the one exception: if you configure WPForms to redirect to a page/URL on a different domain after a successful submission, whether the event is tracked depends on whether the form's AJAX submission setting is on. With AJAX off, the plugin cannot confirm the success on a page it does not control, and the event is not tracked. With AJAX on, WPForms fires its success event on your own site before the browser navigates away, so the event is tracked. Confirmations that stay on your own site (including the default "Message" confirmation and same-origin Page/Redirect confirmations) are tracked normally.

Yes - the tracker script and page-view tracking work with any theme or page builder. Elementor is a detected integration (Events & integrations tab, on by default when Elementor is active): Elementor buttons are tracked automatically as link events with their destination URL, even when "Link clicks" is off. If you have just turned this integration on, an already-cached Elementor page won't pick up tracking until you clear Elementor's cache or re-save the page - turning the integration back off takes effect immediately, with no cache action needed. For other builders:

• Page builders usually render their "button" elements as links rather than native HTML buttons. To record clicks on them, turn on "Link clicks" (and, for buttons that point to another site, "Outbound links") on the Events & integrations tab - they are recorded as link events with the destination URL. The "Button clicks" option covers native, standalone HTML buttons; a submit button inside a form is covered by "Form submissions" instead, not "Button clicks".
• Interactive widgets that only change what's shown on the page without navigating - accordions, tabs, toggles, sliders - are not recorded as events. (Some image lightboxes are built as a plain link to the image file; those are recorded as a link click, with the image URL, when "Link clicks" is on.) To track a widget that fires nothing, send your own event with the developer API (window.ponteAnalytics.track).

Call window.ponteAnalytics.track( 'event_name', { key: 'value' } ) from your own JavaScript to send a custom event - for example, to track a widget that fires nothing on its own. A few things to know:

• It runs on the front end for visitors who are actually tracked. Excluded roles (for example administrators) get no tracker and no API, so test while logged out or in a private/incognito window.
• Call it after the page has loaded, or on a user interaction. Events fired before the Umami tracker has loaded are not queued, so a call at the very top of the page can be missed.
• The event name is capped at 50 characters, matching Umami's own limit - characters outside the Basic Multilingual Plane, such as most emoji, count as two. Your data object is passed to Umami as-is and is subject to Umami's own data limits.

Umami itself is cookie-free by design, and you control your own Umami instance and its data retention. Ponte Analytics for Umami adds no cookies of its own. As with any analytics tool, you remain responsible for your own privacy notice and compliance.

Deactivate and delete Stats Umami first, then activate this plugin. This matters: the plugin folder is different, so WordPress installs this one alongside the old one instead of replacing it - if both end up active at once, the tracker loads twice and every page view and event is counted twice. After switching over:

• Your settings do not carry over. Re-enter your Umami Host URL and Website ID and turn tracking back on.
• Per-form event settings do not carry over either. Contact Form 7 and WPForms event names and data are stored per form, so open each form you had configured and set its event again.
• Analytics you already collected are unaffected - they live on your own Umami server, not in WordPress. Past WooCommerce orders that were already reported are not counted a second time.