Trackdolphin – Server-Side Tracking for WooCommerce
| 开发者 | trackdolphinhq |
|---|---|
| 更新时间 | 2026年10月13日 23:12 |
| PHP版本: | 8.0 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
Trackdolphin reports what happens in your WooCommerce shop to the advertising and analytics platforms you use (Google Ads, Meta, GA4 and others) from the server, not from the browser. Ad blockers, Safari's tracking prevention and abandoned redirects no longer swallow your conversions, and eligible purchases are reported with the value WooCommerce actually invoiced.
This plugin is an interface to the Trackdolphin service (serviceware). All functionality included in the plugin is available without restrictions: there is no license key, trial period or locked feature. It requires a Trackdolphin account (service pricing). The activation code only links your shop to its project in the dashboard; without that link, no data leaves your shop.
What the plugin does
- Reports paid orders (and refunds) from the server, with hashed match signals (e-mail, phone, name, address) in the format Google Ads and Meta expect. Value and line items come from the WooCommerce order, not from a data layer.
- Adds a small first-party script to the storefront that records page views, product views, add-to-cart, checkout start and payment info. The script talks to your own shop (
/wp-json/trackdolphin/v1/collect); the shop relays the event to Trackdolphin. If the shop REST route is unavailable, browser events can fall back to your project collector directly. - Reads the visitor's consent decision from the WP Consent API, Google Consent Mode, Cookiebot, Usercentrics, IAB TCF and Trackdolphin's own banner. Only an explicit analytics or marketing grant unlocks event delivery; identifiers and cookies additionally require their respective consent. A page-level default never grants permission.
- Delivers purchases in the background through the WooCommerce Action Scheduler, signed with an installation key, with retries for up to seven days. The thank-you page never waits for Trackdolphin.
- Optionally serves the Trackdolphin consent banner you design in the dashboard, using the readable GPL-licensed JavaScript bundled in the plugin.
- Shows a status line in WordPress: link state, last confirmed connection, consent management detected, purchases the server declined, and pending delivery jobs.
安装:
- Install and activate the plugin. WooCommerce 8.0 or newer must be active.
- The integration requires a Trackdolphin account (service pricing). Create an account and a project at app.trackdolphin.com. Under Setup you find the code for linking the shop.
- In WordPress open Trackdolphin (top-level menu entry, also under Settings), paste the activation code and click "Connect". The code carries the collector address, the project id and a one-time secret; it is valid for 24 hours and can be redeemed once.
- Click "Check connection". The status line then reads "Connection: established".
- Make sure WP-Cron runs (or a system cron calls
wp-cron.phpevery few minutes): purchases are delivered by the WooCommerce Action Scheduler in the background.
td_ to trackdolphin_ on first load. Credentials, settings and counters are carried over automatically; delivery jobs that were already scheduled are still processed; the old REST route td/v1 keeps answering for cached pages.屏幕截图:
常见问题:
Does the plugin respect visitor consent?
Yes. Browser events and server-side orders require an explicit analytics or marketing grant before leaving the shop, including the visitor’s IP address and user agent. No event is sent before a decision or after full rejection, regardless of the service mode. The script reads the WP Consent API (opt-in), Google Consent Mode, Cookiebot, Usercentrics, IAB TCF 2 and Trackdolphin's banner. Defaults never count as decisions. Purchases use the consent snapshot saved at checkout; missing or ineligible snapshots are not transmitted. The same local check applies to queued purchases after an update. Marketing identifiers require marketing consent. After updating, purge any external full-page/CDN cache so visitors receive the new script. The plugin invalidates supported WordPress page caches once; cached HTML outside WordPress must be purged by the site operator.
Does it work with HPOS (High-Performance Order Storage)?
Yes. The plugin declares compatibility with custom_order_tables and only reads and writes order data through the WC_Order object.
Does it work with the block checkout?
Yes. Consent and identifiers are captured through woocommerce_store_api_checkout_update_order_meta for the block checkout and through woocommerce_checkout_create_order for the classic checkout. The plugin declares compatibility with cart_checkout_blocks.
What happens without a Trackdolphin account?
Nothing. Until the shop is linked with an activation code, no script is added to your pages, no cookie is set and no data is sent anywhere. Paid orders that arrive while the plugin is unlinked are counted in the status line ("Unreported purchases") so you can see what was missed.
Which cookies does the plugin set?
_td_vid (first-party visitor id, 365 days, only with marketing consent) and _td_consent (the consent decision the script saw, 180 days, only after a decision). Click ids (gclid, gbraid, wbraid, _fbc) are stored as cookies only with marketing consent. LinkedIn's click ID (li_fat_id) is stored in _td_li_fat_id for 30 days, also only with marketing consent.
Where is the data stored?
Trackdolphin stores the events of your project on its own infrastructure. Nothing about the visitor is stored in the WooCommerce database except the consent snapshot and identifiers on the order (_td_* order meta) and a small encrypted delivery queue in the options table while a purchase is waiting to be sent.
Purchases, cancellations and refunds are always delivered to the project the shop is currently linked to, also after the project or collector address has changed. For orders anonymized by WooCommerce's privacy tools, pending and later events are still sent, but without personal data (no identifiers, hashes, address, IP address or user agent; only amount, currency, items and the country code).
What is deleted when I uninstall the plugin?
Uninstalling revokes the installation key at Trackdolphin, removes the credentials, settings, counters and the delivery queue. Orders keep their _td_* meta so that a later reinstall does not report the same purchase twice.
更新日志:
0.7.7 (2026-10-12)
- Includes the changes prepared for 0.7.6, which was not released in the WordPress.org directory.
- All plugin settings, notices, status messages, errors and order notes use translatable English source strings. Bundled German and German (formal) translations preserve the current informal wording; a translation template is included.
- Rebuilt the locally bundled consent banner from the current shared source, including German, English and French language packs and French dashboard wording.
- The controller name is shown above the first-layer notice by default. The dashboard can hide that line with layout.noticeController; the settings dialog and privacy links remain available.
- The banner's accessible name includes the controller when shown. Withdrawal instructions describe the configured way to reopen settings, and the reopen button follows the banner configuration.
- Accept and decline choices use equal first-layer styling. External brand logos are blocked before a decision; optional services and tracking remain blocked until consent.
- Clear page caches after updating so visitors receive the new local banner.
- Links to trackdolphin.com now carry the language prefix (
/en/docs/…); the old addresses keep working as permanent redirects. - Purchases, cancellations, refunds and queued deliveries are sent to the currently linked project, also after a project or collector address change.
- Orders anonymized by WooCommerce's privacy tools: pending and later events are still sent, without personal data.
- The delivery queue marks an event as delivered only after the collector confirms it.
- Per-service consent: with service switches in the Trackdolphin banner, a "no" to a single service (e.g. Google Ads while Meta is allowed) now reaches the consent record, the browser events and the purchase. The consent relay also keeps
origin: migratedandsource: placeholder; invalid entries in the service map are dropped one by one instead of rejecting the record. A retry carries a service the visitor has meanwhile switched off._td_consentstays purpose-based; the purchase reads only the denials from the banner cookie. No new cookie; nothing leaves the shop before the visitor decides. - Consent banner runtime rebuilt from the current banner package. With service switches, a "no" to Google Ads or Google Analytics now also sets the matching Google Consent Mode signals to
denied, even when another service of the same purpose is allowed; the dataLayer eventtd_consent_updatecarries the service map astd_services; if the cookie gets too large, the denials are kept and only the "yes" entries are dropped. Embeds marked withdata-td-cm-srcstay unloaded behind a placeholder until the visitor loads them. The runtime still makes no network request of its own; nothing leaves the shop before the visitor decides.
- Block browser events and queued orders locally until explicit visitor consent, regardless of service mode; show the override in settings.
- Validate and sanitize browser payloads before forwarding, preserving consent, identifiers and commerce values.
- Defer cron scheduling and migrations until init to prevent early translation notices.
- Gate advertising identifiers on marketing consent and remove plugin cookies on withdrawal.
- Added: captures LinkedIn's click ID (li_fat_id) with marketing consent and passes it to the server-side conversion.
- Fixed: pages cached before 0.7.2 keep loading the consent banner via a redirect from the old script address to the bundled file.
- Security: invalid consent requests no longer use up the shop's consent limit; limits apply per visitor plus a shop-wide cap.
- Changed: the readable, unminified consent banner runtime is bundled in the plugin under GPL-2.0-or-later and loaded locally with the plugin version. Removed the remote runtime download, its cache and the
/consent.jsREST route. Clear page caches after updating so cached pages load the local script. - Fixed: unlinked or disabled shops emit no consent scripts and make no banner requests.
- Security: consent relaying has a separate limit of 60 requests per shop per minute, a 64 KiB body limit and strict validation of the decision, four boolean purposes and metadata. Public consent and collect routes document why anonymous access is needed and how it is protected.
- Security: reject unexpected input types in forms, activation codes, request bodies, server values and identifier parameters; validate identifier cookies.
- Clarified: Trackdolphin is serviceware. The linking code is not a license key; the plugin contains no trials, paid feature locks or quotas.
- Changed: the admin notice asking for the link code can now be dismissed, and the choice is remembered. A real error (failed connection test, damaged code) still shows and is never hidden behind the dismissal.
- Changed: plugin tags no longer name third-party brands.
- Added: three tracking modes (after consent, collect, always). The mode says what happens BEFORE the visitor has decided: "after consent" stays silent (no event, no cookie, no reading); "collect" sends everything that is known without touching the device (page including its parameters, referrer, products, value) and leaves the device alone, so there is no visitor id and no session; "always" measures right away with identifiers and a cookie. Which mode applies is decided in the Trackdolphin dashboard, per country; the collector tells the plugin. A decision by the visitor always wins over the mode.
- Added: the consent mode default is now announced in the head of every page, before the shop's own Google tag: all four signals denied with wait_for_update, or granted in "always" mode. Without an announcement a Google tag behaves as if consented and sets cookies; in the EEA Google reads missing signals as no consent and does not use the data at all. Switchable, and off by default when another consent tool is detected, because two contradicting defaults are worse than none.
- Changed: the settings page now has a section "Trackingverhalten und Zustimmungssignal (Profi-Einstellungen)" with one sentence per mode and a link into the dashboard. The old, technical note about the visitor cookie is gone (Christopher Motz, 11.9.: "too technical and it makes no sense, because we want to leave the choice to the user"). The country list stays in the dashboard on purpose: maintained twice it would contradict itself.
- Added: a red admin notice on every admin page as soon as the collector declines events for lack of consent and no consent tool hands over a decision. It offers both ways out: "set up consent banner" (opens the Trackdolphin dashboard for this project) and "change tracking settings" (the plugin settings), plus the note that switching to "always collect" runs counter to local regulations in Europe. Dismissible per state; a changed state shows it again. Without declined events the previous, quieter warning stays.
- Added: consent tools are now detected without the plugin list as well, through constants, classes, functions and options. A tool no longer goes unnoticed just because its folder was renamed, it runs as a must-use plugin, or it is not distributed through the WordPress directory at all. Every marker is backed by the tool's source or its vendor documentation; where no evidence was found, nothing is claimed.
- Added: three more plugin folders recognised: gdpr-cookie-consent (WebToffee, NOT the same product as CookieYes although both set the same cookies), uk-cookie-consent (Termly) and cookie-notice (hu-manity.co).
- Added: the finding now distinguishes three cases: none found, found but it hands us nothing, and found and reporting. The wording follows them: a merchant who HAS a consent tool is no longer told he has none, but is told which tool it is and how to wire it up. The self-report to the dashboard carries the case as consent_status.
- Fixed: after a click on "accept all" the page view of the CURRENT page is now sent again. The WP Consent API reports every category on its own and synchronously (
wp_set_consent()fireswp_listen_for_consent_changeper call), so the first event still said "marketing denied" and the catch-up was rejected by the collector with 403consent_required. The script now reads the consent state once, after all categories have been set. - Changed: everything the plugin stores or registers in WordPress now carries the prefix
trackdolphin_instead oftd_: options, transients, the delivery hook (trackdolphin_deliver_event), the daily heartbeat, admin actions, nonces, the settings group and the REST namespace (trackdolphin/v1). A one-time migration copies existing options and transients to the new names and removes the old ones; delivery jobs scheduled under the old hook are still processed; the old REST namespacetd/v1stays registered as an alias for pages served from a cache. Cookies (_td_vid,_td_consent), order meta (_td_*) and signature headers (X-Td-*) are unchanged: they are the contract with the collector, not WordPress namespace. ConstantsTRACKDOLPHIN_VERSIONandTRACKDOLPHIN_PATHreplaceTD_VERSIONandTD_PATH(kept as aliases). - Removed: the update channel introduced in 0.4.1 (
Trackdolphin_Updates,pre_set_site_transient_update_plugins). Plugins in the WordPress.org directory receive their updates from the directory; a custom updater is not permitted there. - Changed: licensed under the GPLv2 or later.
- Changed: the relay rate limit uses a transient instead of direct database writes; the inline configuration and script tags are printed through
wp_print_inline_script_tag()andwp_print_script_tag(); every file guards against direct access; inputs are unslashed and sanitized;parse_url()replaced bywp_parse_url(); noerror_log()in production code (the reason now lands in the status line). Plugin Check reports no errors and no warnings for the shipped files. - Changed: outdated admin texts that still mentioned the "personal plugin package" now point to the activation code.
- Changed: the personal plugin package is gone. The plugin is the same ZIP for everyone; linking happens with a single activation code from the dashboard (Setup), pasted under WordPress → Trackdolphin. The code carries collector address, project id, installation id and the one-time secret; it is valid 24 hours and redeemable once. Existing linked shops keep working.
- Changed: the consent banner runtime is no longer shipped inside the plugin. The shop serves it from its own route (
/wp-json/trackdolphin/v1/consent.js, fetched from the Trackdolphin service and cached for an hour), so the browser still sees only the shop domain and a new banner release needs no plugin update. - Added: Trackdolphin Consent, the project's own cookie banner. Once a version is published in the dashboard, the plugin fetches it from the collector (cached five minutes) and writes it as an inline configuration into the page head: first-party, no third-party request before the decision.
- Added: the banner's decisions reach everything that reads consent; every decision is relayed as a consent record to the collector through the shop.
- Added: when the collector declines browser events for lack of consent (
403 consent_required), the status line says so, with the last time it happened and what helps. - Fixed: timestamps in the status line are shown in the shop's timezone instead of raw UTC.
- Added: the buyer's identifiers are captured at checkout and travel with the purchase: visitor id,
gclid/gbraid/wbraid(also from Google's_gcl_awcookie),_fbc/_fbp, GA client id; fallback is the entry URL of WooCommerce's order attribution. - Added: compatibility declared for HPOS (
custom_order_tables) and the block checkout (cart_checkout_blocks). - Added: the plugin reports its version, PHP/WP/WC versions, HPOS state, consent finding and delivery counters to the collector with every connection check, on activation and once a day.
- Added: status line warns when five or more delivery jobs are waiting, with the WP-Cron hint.
- Fixed: the server-side visitor cookie decision now reads the full consent snapshot, not only the WP Consent API.
- Changed: the plugin no longer decides about consent; the server does. Every paid order is sent with the consent snapshot and its origin (
source: cmporsource: default); the collector answers 202 or 403consent_required. - Added:
country_codein the purchase payload so the server can apply the per-country rule. - Added: a 403
consent_requiredfrom the server is counted once per order, shown in the status line and never retried. - Fixed: orders without a consent snapshot (admin, import, subscription renewals) are sent with
source: default. - Fixed: the snippet ignored the WP Consent API unless the banner set
window.wp_consent_type; it now also readswindow.wp_fallback_consent_type. - Added: the snippet writes the banner decision it sees to the first-party cookie
_td_consent; the server-side snapshot reads it as a second source. - Changed: without a decision the snippet sends an anonymous page view and lets the server decide.
- Fixed: browser events relayed through the first-party proxy lost the visitor's IP and user agent; the relay is now signed with the installation credentials.
- Fixed: a Consent Mode
defaultwas treated like anupdate. A preset never unlocks events or cookies, only a decision does. - Every browser event and the purchase snapshot now carry
consent.sourceandconsent.cmp. - WP Consent API: the visitor has decided only once the API has written its cookie.
- Consent management detection and WP Consent API check on the settings page, with a dismissable admin notice when a banner is not bridged to the API.
- Fixed: the server-side consent snapshot queried a filter that does not exist; every purchase was recorded as "no consent" even with a correctly bridged banner.
- Removed the "visitor cookie only after consent" settings row and the "delete settings on uninstall" checkbox; uninstall always removes the settings, orders are never touched.
- Activation errors show their cause; activation redirect and top-level admin menu.