AxiTrace for WooCommerce

Changelog

1.5.3

• Fix: a secret key AxiTrace does not recognise is now reported: a critical log entry, a note on the order and a warning on the settings page. Before, every order quietly lost its product costs.
• Fix: refunds name the workspace they belong to, so a secret key copied from another workspace can no longer record them there.
• Change: with a secret key (profit tracking) and server-side events on, the purchase is sent only by the server, which carries the product costs. AxiTrace keeps the first purchase it receives for an order, and the copy sent from the confirmation page, which never carries costs, would otherwise always arrive first.
• Fix: the purchase sent from the order confirmation page was rejected by AxiTrace (HTTP 400) because the buyer’s email was handed to the tracking script in the wrong shape. Only the background server-side purchase reached AxiTrace; now both do, and whichever arrives first is kept.
• Fix: shoppers who had completed a purchase with an earlier version carried a broken user id ([object Object]) in the vt_uid cookie and were all reported as the same person. The broken value is removed on their next page view.

1.5.2

• Add: server-side purchases and add-to-cart events now carry the Microsoft Advertising (msclkid), X (twclid), Pinterest (epik), LinkedIn (li_fat_id) and Snapchat (sccid) click ids. The AxiTrace tracking script 0.24.0 stores them on the landing page like the Google and TikTok ones, in the cookies _axi_msclkid, _axi_twclid, _axi_epik, _axi_li_fat_id and _axi_sccid.
• Each one is read from the page URL first (Snapchat’s own ScCid parameter as well as sccid), then from the AxiTrace cookie while it is inside the platform’s longest click window (90 days for Microsoft and X, 60 for Pinterest, 30 for LinkedIn, 28 for Snapchat), and finally from the cookie the platform’s own tag sets (_uetmsclkid, _twclid, _epik, li_fat_id). Those platform cookies are only read, never changed. An old click replayed from a bookmarked link is not sent.
• The ids are stored on the order at checkout like the other click ids, so the purchase sent later in the background still carries them. Uninstall removes the new order meta keys.

1.5.1

• Fix: server-side purchases and add-to-cart events now carry the Google Ads click ids (gclid, gbraid, wbraid) and the TikTok click id (ttclid). They were never read, so a purchase made after a Google or TikTok ad click reached AxiTrace without the click, and Google Ads and TikTok could not attribute it to the ad.
• Fix: the Reddit click id is now sent as the bare id. Earlier versions sent the whole stored cookie value (v2|<time>|<id>), which Reddit cannot match to a click. Orders placed before the update are sent with the bare id as well.
• Add: the OpenAI Ads click id (oppref) and browser reference (__obref cookie) are captured and forwarded.
• Each click id is read from the page URL first (a fresh ad click) and otherwise from the cookie the AxiTrace tracking script stored it in on the landing page, with the same limits the script applies: a click older than 90 days (28 days for Reddit and OpenAI Ads) is not sent, and neither is an old click replayed from a bookmarked link.
• The ids are stored on the order at checkout, so the purchase sent later in the background, after a payment gateway callback, still carries them.
• Fix: an order marked as paid by a store manager in wp-admin (for example a bank transfer) no longer picks up the manager’s own browser cookies and ad clicks.
• Uninstall now also removes the new order meta keys.

1.5.0

• Add: profit tracking support. A new optional “AxiTrace secret key” setting. With it, server-side purchases carry each product’s cost from the WooCommerce Cost of Goods Sold field (WooCommerce 9.5 or later, when the feature is on), so AxiTrace can report profit and POAS next to revenue and ROAS. Without the key no cost data and no refunds are sent; purchases only gain the tax flag and line identity described below.
• Add: with the secret key, refunds (partial and full) and cancellations of paid orders are reported to AxiTrace so profit and POAS account for them. Revenue, ROAS and the ad platforms are not affected.
• Add: purchases carry whether your catalog prices include tax and a catalog identity per line item (woocommerce:<product or variation id>), used to match products to the costs in your AxiTrace workspace.
• Add: if AxiTrace rejects the secret key, purchases are still delivered (without costs) and the rejection is logged critical in WooCommerce > Status > Logs and noted on the order.
• Fix: refunds and cancellations are matched to their purchase by the order number, so stores with an order-numbering plugin are covered.
• Product costs are never added to a storefront page or to the browser-side purchase; they travel only in the server-side request authenticated with the secret key.

1.4.0

• Change: consent is now governed by your AxiTrace workspace settings. The tracking SDK is loaded on every page and asks AxiTrace whether it may run, so turning “Respect cookie consent” on in your workspace gates every storefront page – including stores with no consent plugin at all – without touching any code.
• Change: with the WP Consent API present the SDK is still gated on the marketing category, but it is now the SDK itself that stays inert (no cookie, no storage, no request) instead of the script not being loaded. The site gate and the workspace policy apply together, so a page can only tighten the workspace setting, never loosen it.
• Add: a consent withdrawal reported by wp_listen_for_consent_change now stops tracking immediately and deletes the identifiers AxiTrace wrote, instead of taking effect only on the next page view.

1.3.0

• Fix: the browser-side purchase on the thank-you page never fired on stores with pretty permalinks (the default), so the Meta Pixel bridge never engaged for purchases. It now reads the order from the order-received query var.
• Fix: the browser-side purchase now carries the full order (line items, phone, name, billing address, order number, tax, shipping). AxiTrace keeps whichever of the two purchase events arrives first; a thin browser event would have left the ad platforms without buyer data.
• Fix: the browser-side purchase fires only for orders WooCommerce considers paid. On-hold bank transfers and pending gateway returns are reported by the server-side event once the payment lands.
• Fix: server-side AddToCart now carries the shopper’s AxiTrace visitor and session ids, real IP and User-Agent, ad-platform cookies, value and line item instead of the shop server’s identity.
• Fix: the SDK now loads on every storefront page. Homepage, landing pages and blog posts were skipped, so ad clicks landing there were never attributed.
• Fix: WP Consent API support actually works now, is cache-safe (the decision is made in the browser), gates on the marketing category, and a later grant boots the SDK without a reload.
• Fix: transient delivery failures (AxiTrace unreachable, timeout, 5xx) are retried with backoff for up to 24 hours instead of being lost after the first attempt.
• Add: purchases carry the human-readable order number (GA4 transaction_id), gross tax, shipping and discount amounts, a catalog id per line item, and the shopper’s consent decision.

1.2.1

• Fix: the links in this listing and on the settings screen pointed at pages that do not exist. “Visit plugin site” led to axitrace.com/woocommerce and the install instructions sent you to axitrace.com/admin; both answered with an error page. They now point at the WooCommerce integration page and the sign-in page. No tracking behaviour changes – upgrading is optional.

1.2.0

• Add: purchase events now include the shopper’s first name, last name and state/province from the billing address. Facebook Conversions API and TikTok Events API hash and match on these, so including them measurably improves event match quality.
• Add: the TikTok browser ID (_ttp) and Reddit browser and click IDs (_rdt_uuid, _rdt_cid) are captured at checkout and forwarded, so TikTok and Reddit receive an identifier of their own instead of matching on e-mail alone.
• Add: the Google Analytics client and session cookies are captured at checkout, so the server-side purchase reaches GA4 as the shopper’s own session instead of an unattributed new user.
• Add: the AxiTrace visitor and session IDs are captured and sent as the external ID, stitching the server-side purchase to the shopper’s browsing profile. The WooCommerce customer ID could not serve this purpose: it is a WordPress user ID and is empty for guest checkouts.

1.1.0

• Fix: InitiateCheckout (begin_checkout) now reports the real cart total and currency instead of value=0. Also deduplicated to fire once per checkout session instead of on every reload.
• Add: AddPaymentInfo now fires when a shopper selects a payment method on the checkout page (classic/shortcode checkout), giving ad platforms a mid-funnel signal between InitiateCheckout and Purchase.
• Fix: AddToCart no longer double-fires. It was previously tracked independently from both the server and the browser with no shared ID, recording every add-to-cart twice. The server-side hook (which covers every add-to-cart path, including ad-blocked and JS-disabled browsers) is now the sole source; the redundant browser-side listener was removed.

1.0.2

• Improvement: purchase events now include the customer’s own Meta browser pixel cookies (_fbp/_fbc) when present, captured at checkout time and forwarded to Facebook Conversions API for better browser/server event matching. No change for stores without their own Meta Pixel.

1.0.1

• Fix: settings saved through WooCommerce > Settings > Integrations > AxiTrace are now read correctly at runtime. The public key, server-side events toggle, and tracking domain entered in the form are picked up immediately. Previously these values were not detected, so no events were sent. Re-saving the settings is not required after upgrading.

1.0.0

• Initial release.
• Server-side purchase event via Action Scheduler.
• Deterministic UUID v5 dedup for Facebook CAPI, TikTok, Google Ads, GA4.
• Server-side AddToCart event for ad-blocked customers.
• HPOS and Cart/Checkout Blocks compatibility.
• WP Consent API detect-and-check support.
• GDPR personal-data exporter and eraser hooks.