Catch broken checkouts before your customer emails you.

A button that does nothing with no console error usually has one of four causes: a JavaScript file that failed to load (check Network tab for red rows, not just Console), a transparent element sitting on top of the button and swallowing the click (in DevTools, hover the button and check what element actually highlights), a click handler that never got attached because a plugin loaded out of order, or a caching or minification plugin that broke the script. The hard part is that it often only breaks for some visitors: a specific browser, a cached copy, a plugin conflict you cannot reproduce. Harvv catches this from the visitor side. When real people click an element and nothing happens, that is recorded as a dead click, and repeated dead clicks on the same element automatically become an issue with the exact element, page, browser split, and number of visitors affected.

Crawlers can find broken links (a URL that returns 404), and free tools like a dead link checker do that fine. What a crawler cannot find is a button or link that loads fine but does not respond when clicked, because that failure only happens in a real browser session. The reliable method is behavioral: watch what real visitors click and flag the elements where clicks repeatedly lead nowhere. That is the core of what the Harvv plugin does on WordPress, and it also reports images and scripts that failed to load during real visits, which a page-by-page check misses when the failure depends on cache state or device.

Safari and iOS WebKit handle hover states, fixed positioning, and some tap events differently from Chrome. The usual suspects: a menu that opens on hover (there is no hover on touch), an element that needs a double tap because the first tap triggers a hover state, a sticky header overlapping tap targets, or JavaScript using events Safari fires differently. Because you probably develop on desktop Chrome, you never see it. Harvv splits every dead click and rage click by device and browser, so a Safari-only or iPhone-only failure shows up labeled exactly that way, with the element and page attached.

If people arrive and do not buy or enquire, the answer is almost always visible in what they do: where they stop scrolling, what they click that goes nowhere, which forms they start and abandon, and which pages are slow enough that they leave first (Google's own threshold data says mobile bounce probability rises 32 percent when load goes from 1 to 3 seconds). Guessing from pageview counts cannot tell you which of those it is. Behavioral analytics can: Harvv reports the specific page, element, and visitor segment where momentum dies, ranked by how many sessions are affected.

No. Harvv sets no cookies. Visitor IDs live in sessionStorage, scoped to the browser tab, cleared when the tab closes. Under GDPR, CCPA, and PECR, consent banners are required for non-essential cookies or transmission of personal data — Harvv transmits neither.

No. All outbound calls use wp_remote_post() with 'blocking' => false. The browser tracker uses navigator.sendBeacon or fetch with keepalive. Nothing in the plugin blocks a pageload or checkout.

Fully supported. The plugin declares compatibility via FeaturesUtil::declare_compatibility('custom_order_tables', __FILE__, true) and uses only the WC_Order CRUD API.

Yes. Delete from the Plugins screen. uninstall.php removes harvv_api_key, harvv_site_id, and all related options on both single-site and multisite networks. The plugin creates no custom DB tables.

Yes. The pixel is a single <script> tag with async attribute, served from harvv.com behind global edge caching. WP Rocket, W3 Total Cache, Cloudflare, and Bunny all pass it through normally. We never write back to your DB on a pageview.