| 开发者 |
harvv
ecommercepros505 |
|---|---|
| 更新时间 | 2026年5月14日 00:55 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 6.9 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
woocommerce_payment_complete (never blocks checkout)./wp-content/plugins/harvv-analytics/.No. The plugin sets no cookies and transmits no personal data. Under GDPR, CCPA, and PECR, cookie-consent banners are required only when a site sets non-essential cookies or transmits personal data to third parties. Harvv transmits only behavioral signals (dead clicks, scroll depth, etc.) and a non-reversible customer hash — these are not personal data under any major privacy regime. If your legal counsel interprets the regulations more conservatively than we do, you can still add Harvv to your privacy policy's third-party services section. The plugin provides suggested language at Settings → Privacy → Policy Guide.
Yes. The WooCommerce integration loads conditionally — on a non-Woo WordPress site, the plugin runs as a pure behavioral pixel.
No. All outbound HTTP calls use wp_remote_post() with 'blocking' => false, and the browser tracker uses navigator.sendBeacon() or fetch with keepalive: true. Nothing in the plugin waits on a response from Harvv.
Yes. The plugin declares compatibility with custom_order_tables and uses only the WC_Order CRUD API — never direct $wpdb access against order tables.
The browser tracker queues events locally and attempts to flush on each interval; unsent events are discarded silently when the browser tab closes. WooCommerce order events are fire-and-forget — if your site cannot reach harvv.com at the moment of payment_complete, the event is lost. We do not queue order events for retry on-site because doing so would require creating a custom database table, which this plugin intentionally does not do.
As of 1.0.1 the plugin records the timestamp of the most recent successful Woo sync and surfaces it on the settings page so an admin can spot a silently broken integration before reconciling Stripe and Woo manually.
Delete the plugin from the Plugins screen. All plugin options (harvv_api_key, harvv_site_id, and related) are removed via uninstall.php. The plugin never creates custom database tables on your site, so nothing is left behind.
No. The tracker is enqueued in the footer and is cache-friendly (same output for every visitor). The Connect-flow REST endpoint is under /wp-json/harvv/v1/* and is gated by a one-shot nonce, so caching that endpoint is harmless.
No — the Site key is a public, per-site identifier. Think of it like a Stripe publishable key: it ships embedded in your page source so the browser tracker can authenticate its POSTs to Harvv. It can be used only to send events for the site it was issued for; it cannot be used to read your account data or events from any other site. If you ever need to rotate it, do so from the Harvv dashboard.
As of 1.0.4 the plugin auto-injects the exclusion attribute for every major optimization tool, so most setups are immune out of the box. The exceptions are three tools that match by URL pattern rather than HTML attribute:
harvv.com/px/.https://harvv.com/px/*.harvv.com/px/.Add a filter on harvv_should_load_tracker in your theme's functions.php or a small site-specific plugin:
add_filter( 'harvv_should_load_tracker', function( $load ) { if ( is_admin() || is_cart() || is_checkout() ) { return false; } return $load; } );
The filter fires before wp_enqueue_script runs, so a false return prevents the script tag from ever appearing in HTML.
Define HARVV_API_BASE in wp-config.php before WordPress loads plugins:
define( 'HARVV_API_BASE', 'https://staging.example.com' );
The plugin sends every outbound API call (registration, Woo order sync) to that base URL. The Connect flow always uses https://harvv.com because Harvv's hosted signup page is the only place that can mint a fresh API key.
Settings → Harvv Analytics shows the time since the most recent successful sync underneath the "Connected ✓" badge on WooCommerce sites. If a sync fails (DNS error, sslverify mismatch, etc.) the error message is shown in red and the timestamp is preserved from the last successful send. The plugin never blocks checkout — these signals are surfaced asynchronously so you can spot a failing integration before it becomes a reconciliation problem.
Yes — by default, the plugin sends Harvv a snapshot of which other plugins, theme, WordPress version, and PHP version are installed on the site. This is site metadata, not visitor data. No personal information, no user content, no option values. Why we do this: Harvv's value comes from telling you exactly what's wrong with your site's UX. The browser tracker can see "users are bouncing on /pricing because of a 600ms layout shift" — but without knowing which plugins are running, the diagnosis stops at "something is shifting layout." With the stack snapshot, we can attribute the shift to the specific plugin causing it (e.g. "Yoast 22.8 injects a meta tag late") and tell you exactly what to fix. Faster diagnosis = faster fix = better speed and UX for your visitors. That's what this plugin is for. What's sent (1.0.2 — site context):
yoast-seo, not the human display name), version, active boolean.en_US, fr_FR, …), timezone (America/Chicago), permalink-structure boolean ("pretty" vs "plain"), WP_DEBUG boolean, memory limit, max execution time, object cache backend (external / none), WP-Cron disabled boolean, multisite boolean + blog count.define( 'HARVV_SHARE_INVENTORY', false ); to wp-config.php. This wins over the UI toggle.add_filter( 'harvv_share_inventory', '__return_false' ); in a small mu-plugin.Yes — Harvv Analytics defaults to auto-update from WordPress 5.5+ so new behavioral signals and bug fixes reach your site without you having to remember to click Update. Behavioral pixels are most valuable when they're current; an out-of-date pixel silently misses entire classes of issues, so the default leans toward "stay current."
If you'd prefer to manage updates manually (e.g. on a staging-first workflow), add this line to your wp-config.php:
define( 'HARVV_AUTO_UPDATE', false );
The plugin will then defer to WordPress's normal per-plugin auto-update toggle (which defaults to OFF until you click "Enable auto-updates" on the Plugins screen).
window.dataLayer and ingests GA4 recommended events (add_to_cart, begin_checkout, view_cart, purchase, view_item, generate_lead, sign_up, search) as Harvv cm events with src:'dl'. When a customer's GTM container fires a GA4 conversion event, Harvv captures the same logical event via the dataLayer instead of re-detecting from the DOM. More precise, less noise.window.dataLayer under event: 'harvv_signal' (namespaced — never reuses GA4 event names, so no double-counting in customer's GA4 reports). Customers can set up GTM triggers on harvv_signal to route Harvv signals to Meta Pixel, Klaviyo, or any other tool managed through GTM.pf.deferred event's via field now also detects LiteSpeed Cache and Cloudflare Rocket Loader in addition to WP Rocket, Perfmatters, and NitroPack. Dashboard banner and email alert can name the specific tool deferring the pixel.GA4_NAMES (Harvv→GA4) and GA4_TO_KIND (GA4→Harvv). Adding a new mapping is a one-line change in either object.gtag, google_tag_manager, or dataLayer) and stamps every session with a ga4 flag. Commerce events (cm/ca, cm/co) carry a ga4 alias mapping to the GA4 recommended event names (add_to_cart, begin_checkout) so the Harvv dashboard can label both. Harvv and GA4 stay separate-namespaced — no dataLayer writes by default — which means zero double-counting in the customer's GA4 reports.analytics_storage is denied in the site's consent config, the pixel downgrades to anonymous mode automatically (in-memory visitor ID, no cookie or localStorage writes) — mirroring GA4's own "cookieless ping" behavior so the privacy posture stays consistent across both tools.docs/runbooks/ga4-coexistence.md documents the cross-system contract, expected number-deltas vs GA4, and the canonical answer for "why don't my Harvv numbers match GA4?" support questions.cm, kind ca) — every time a visitor clicks an "Add to cart" / add_to_cart_button / single_add_to_cart_button / [data-add-to-cart] element. Element id + scroll depth at click attached.cm, kind co) — when a visitor focuses any input named coupon / discount / promo. Strong leading indicator for conversion intent.cm, kind ei) — mouse leaves the viewport from the top edge on /cart, /checkout, /basket, or /payment. One emit per pageload. Predicts cart abandonment.ix) event now carries sp = scroll % of the page when the click happened. Lets the dashboard answer "are customers clicking my CTA from above the fold or after scrolling past it?".pf.deferred event now includes the detected optimization tool (wp_rocket, perfmatters, nitropack). The dashboard banner and the email alert can now name the specific plugin causing the delay./wp-json/harvv/v1/dismiss-lazyload-notice (admin-gated; per-user user_meta).<script> tag now ships with the full carpet of vendor-specific exclusion attributes so it is exempt from delay-JS / lazy-load passes in WP Rocket, LiteSpeed Cache, Autoptimize, WP Fastest Cache, NitroPack, and Cloudflare Rocket Loader. Before 1.0.4 these tools could catch our pixel and delay it until first user interaction, which meant we missed the initial-paint Core Web Vitals (LCP / INP / CLS) on every session. After 1.0.4 the pixel boots immediately regardless of which optimization tool is installed.Harvv_Enqueue::inject_exclusion_attrs() method, hooked on script_loader_tag. Attribute set researched 2026-05-13 against each vendor's primary documentation. Conflict-free (each tool only inspects its own attribute).https://harvv.com/px/<site_key>/pixel.js instead of a bundled copy of tracker.min.js. New behavioral signals shipped to the canonical pixel propagate to your site within minutes — no plugin update required. Same source of truth our Laravel package and direct-install path already use.wp_localize_script. The canonical pixel identifies the site via its URL path and the server-injected preamble. Tighter exposure surface for the (public-but-still-best-not-broadcasted) key.define( 'HARVV_PIXEL_URL', '...' ); in wp-config.php. The harvv_pixel_url filter is also available for runtime overrides.window.__harvvLoaded__) so a site running both the WP plugin AND the canonical script tag won't double-fire events. First one to boot wins; second one bails cleanly. The reconciliation event is also recorded server-side via sites.install_sources so the dashboard can show "both paths installed since X".tracker.min.js stays in the plugin directory for backward compat (CDN cache TTLs), but the enqueue no longer references it. Slated for removal in a future release.define( 'HARVV_SHARE_INVENTORY', false ); in wp-config.php or add_filter( 'harvv_share_inventory', '__return_false' );.External Services section enumerates every field that ships.harvv_share_inventory, harvv_last_inventory_sync_ts, harvv_last_inventory_error (cleaned up on uninstall). New WP-Cron hook harvv_inventory_refresh (cleared on uninstall). New REST endpoint /wp-json/harvv/v1/diagnostic-preview (admin-gated; returns the next payload that would be sent).HARVV_AUTO_UPDATE as false in wp-config.php.api.harvv.com (DNS NXDOMAIN) to harvv.com. The Connect flow, registration endpoint, and Woo /v1/track ingest now resolve to the production receiver. Existing installs with HARVV_API_BASE overridden in wp-config.php keep their override.harvv_should_load_tracker filter and the HARVV_API_BASE override constant, both of which existed in code but weren't surfaced anywhere user-facing.Harvv_Multisite::maybe_auto_register_subsite() removed — the logic moved to Harvv_Core::maybe_auto_register(). Network-admin UI and per-subsite override behavior unchanged.payment_complete order sync.