AxiTrace for PrestaShop

A start-to-finish walkthrough: download the free module, upload it in your PrestaShop back office, paste your workspace public key, and verify the first server-side purchase lands in your AxiTrace dashboard. About ten minutes from blank to fully wired. No SSH, no Composer and no system cron required.

Before you start

You will need:

• An AxiTrace account with at least one workspace. Create one for free (10,000 visits/month, no card required).
• A PrestaShop store running PrestaShop 8.1 or later (including 9.x) on PHP 8.1 or later.
• A back-office account allowed to upload and configure modules.
• About 10 minutes.

Compatibility

The public key (always starts with pk_live_) identifies your AxiTrace workspace. The module uses it for every event it sends.

1. Sign in at axitrace.com/login with your email and password.
2. You land on the Workspaces page. Click the workspace name you want to connect to your store.
3. Click Workspace settings in the sidebar, open Tracking & domains and find the Container Information card.
4. Click the small copy icon next to the Public Key field.

Download the ZIP from axitrace.com/downloads/axitrace-prestashop-module-latest.zip (or use the button at the top of this page). Do not unpack it: PrestaShop installs the ZIP as it is. The archive contains one folder, axitrace/, which is the module’s technical name.

SHA-256 verification

Verify the ZIP integrity before installing. The SHA-256 hash for the current release is published at:

https://axitrace.com/downloads/axitrace-prestashop-module-latest.zip.sha256

Verify the downloaded file with:

shasum -a 256 axitrace-prestashop-module-latest.zip

The two hashes must match exactly. If they differ, delete the file and download it again.

1. In the PrestaShop back office open Modules → Module Manager.
2. Click Upload a module (top right) and drop the ZIP, or click to select it.
3. PrestaShop installs the module. When it reports success, click Configure. You can always come back later: search for AxiTrace in the Module Manager and click Configure.

Updating to a newer version works the same way: upload the new ZIP over the installed module. Your settings, the order bookkeeping and the retry queue are kept.

1. Turn on Enable tracking.
2. Paste the public key you copied in Step 1 into Public key.
3. Optional: paste your secret key into Secret key to send product costs and refunds (see profit tracking).
4. Click Save.

With multistore enabled, pick the shop (or shop group, or all shops) in the shop context selector before saving; see Multistore.

Configuration field reference

1. Open your storefront in a fresh private window, so you are an anonymous visitor and not a logged-in employee.
2. Browse a product, add it to the cart and complete an order.
3. Paid with cash on delivery: the purchase is sent when the order is placed. Paid with bank wire or check: in the back office open Orders, open the order and change its status to Payment accepted. An online payment module that confirms the payment does that on its own.
4. The order appears in Orders & journeys in your AxiTrace workspace within a few minutes, under its PrestaShop order id.

What gets tracked

All events propagate to every ad platform you have connected (Facebook CAPI, TikTok Events API, Google Ads, GA4).

Client-side events are fired by the AxiTrace browser SDK, which the module loads in the page header, and forwarded server-side by AxiTrace. The module calls the SDK directly and never pushes to your dataLayer, so your own Google Tag Manager tags do not fire twice. The server-side transaction.charge is sent by the module from your server and is not affected by ad blockers or iOS privacy restrictions. Refunds are sent too, for profit only (see profit tracking).

Meta browser events and deduplication

When the Meta Pixel is present on the page, the AxiTrace SDK sends every client-side event to Meta twice on purpose: once through the browser pixel and once server-side through the Conversions API, both with the same event id, so Meta counts each event once. Load the Meta Pixel base code with fbq('init', 'YOUR_PIXEL_ID') only and remove your own PageView, ViewContent, AddToCart, InitiateCheckout and Purchase calls (including those of another Meta module): a hand-written call carries no shared event id and is counted twice.

When a purchase is sent

PrestaShop creates an order before the money is in. The module sends the purchase once, at the first moment the order counts as a sale:

The order confirmation page also reports the purchase from the browser, but only when the order already counts as a sale at that moment (paid, or cash on delivery). A bank wire order shows no browser purchase; the server sends it once you accept the payment. Both paths use the same event id, so the purchase is counted once.

Cash on delivery

PrestaShop does not mark a cash on delivery order as paid until the parcel is paid for, which can take days or never happen in the shop at all. So the module sends cash on delivery orders when they are placed, based on the payment module that took the order:

• Cash on delivery modules lists the payment modules treated this way, by technical name, separated by commas. The default is ps_cashondelivery, PrestaShop’s own module.
• Third-party cash on delivery modules (a carrier’s or marketplace’s COD module, a COD module with a fee): add their technical name. You find it in Modules → Module Manager in the module’s details, or on any order paid with it, under Payment. Without it, orders of that module are sent only when someone sets them to a paid status.
• An order of such a module that is canceled or ends in a payment error before it was sent is never sent. One that is canceled after it was sent is reported as a cancellation refund for profit (see below); nothing already sent to an ad platform is changed.

Profit tracking: secret key, costs and refunds

With the Secret key field set, the module also sends each order line’s purchase cost and reports refunds and cancellations, so AxiTrace can calculate profit and POAS (Profit on Ad Spend). Without it, purchases are tracked as usual, with no costs and no refunds. Where to find the key, which cost each line gets and how refunds count: Profit and POAS - PrestaShop.

• Costs: the purchase price recorded on the order line: the supplier price when the product has one, otherwise the cost price (wholesale price); if the line has neither, the product’s or combination’s current cost price, converted into the order currency. A line without a cost is sent without one, never as 0.
• Refunds: every credit slip (partial refund, standard refund or return) is sent with its products and shipping, including tax, in the order currency. Products cancelled on an order that was already sent (for example a cash on delivery order before delivery) are sent as a line refund. An order set to Refunded or Canceled after it was sent, without any credit slip, is reported as one refund of the rest.
• Refunds are for profit only: they never reach Meta, Google Ads or any other ad platform, and revenue and ROAS do not change.
• The key is encrypted with your shop’s own encryption key. If that key changes (for example after moving the shop), the configuration page asks you to enter the secret key again; until then purchases are sent without costs.
• If AxiTrace refuses the secret key (for example the key of another workspace), the purchase is sent again without costs and the configuration page shows Secret key rejected. Refunds refused because of the key wait in the delivery log and are sent as soon as you save a valid secret key (or click Retry now).

Cookie consent

This section covers the PrestaShop-specific settings. For the workspace-level forwarding policy, consent platforms and how to verify a gate actually works, see the Cookie consent guide.

Consent modes

In the strictest mode, orders with no recorded consent (for example orders created in the back office) are not sent: a missing decision is never treated as a grant.

How a consent grant is detected

In a Wait for consent mode the SDK is not loaded at all until a grant signal arrives: no cookie, no local storage entry, no network request. Two signals are always active:

1. A consent cookie: set Consent cookie name to the cookie your consent module sets on accept. A short poll picks the cookie up within about 500 ms, and a cookie stored earlier is read on the next page view.
2. The JavaScript API: one line from your consent tool’s “on accept” callback:

   window.axitraceConsent && window.axitraceConsent.grant();

   window.axitraceConsent.isGranted() reports the current state.

Withdrawal

In every mode, one line from your consent tool’s withdrawal callback stops the SDK and deletes the identifiers it wrote (vt_vid, vt_sid, vt_uid, their storage copies and queued events):

window.axitraceConsent && window.axitraceConsent.revoke();

Excluding customer groups (B2B)

When the same shop also serves customers you do not want in your marketing data, typically B2B buyers, select their group under Customer groups excluded from tracking (several groups allowed, per shop). A customer counts as excluded when their default customer group is selected:

• Before login: a visitor cannot be recognised until they log in, so pages viewed before logging in are collected as an anonymous visit. They contain no order, so they never create a conversion.
• Page cache: the decision is never written into the page HTML, so a page cache cannot leak it between visitors. Before the script loads, the storefront asks a small uncached module URL (/module/axitrace/status) whether the current customer may be tracked.
• Other tags (your own Google Tag Manager container, another module’s pixel) are not affected and need their own exclusion.

Multistore

The module follows PrestaShop’s multistore configuration. Every setting can be saved for all shops, a shop group or a single shop with the shop context selector at the top of the back office; a shop without its own value inherits it from its group, then from all shops.

• Each shop can have its own public key, so each shop can report to its own AxiTrace workspace. One workspace per shop is recommended when the shops sell under different domains or currencies.
• Every order is sent with the settings of the shop it was placed in, including retries and refunds sent later.
• Add every shop’s domain to the workspace under Tracking & domains.

Failed deliveries, retries and the cron URL

The module sends a purchase the moment the order status changes, with a short timeout so your back office and checkout never wait for AxiTrace. If AxiTrace cannot be reached, the purchase is kept in a queue on your shop, with the same event id, and sent again later:

• Retries start after 5 minutes and wait twice as long each time, up to 6 hours between attempts, for at most 10 attempts. After that the entry is marked failed and kept for 30 days in the delivery log.
• The secret key is never stored in the queue; it is read from the configuration at each attempt.
• No cron is required. Due retries run in small batches at the end of ordinary storefront and back-office requests, after the response was sent to the visitor.
• Optional cron URL: on a quiet shop, or a server where PHP cannot finish requests in the background, retries may wait until the next back-office visit. The configuration page shows a Cron URL with a copy button; call it every 5 to 15 minutes from your hosting panel’s cron or any uptime monitor. It looks like:

  https://your-shop.com/module/axitrace/cron?token=<your token>

  or, without friendly URLs, https://your-shop.com/index.php?fc=module&module=axitrace&controller=cron&token=<your token>. The token is generated when the module is installed; a wrong token is refused with 403.

Connection health and delivery log

The module’s configuration page shows:

• Connection health: the last successful delivery, every recorded failure (newest first, with when it last happened and how often), whether product costs are accepted, the module, PrestaShop and PHP versions, and a banner when the public key or the secret key was rejected, the secret key has to be entered again, or refunds wait for a valid secret key. Dismiss failures clears the list once you have fixed the cause; a failure that happens again is shown again.
• Delivery log: the last 50 queued, waiting and failed deliveries with event id, type (purchase or refund), attempts and last error. Retry now sends the queued entries and the refunds waiting for a valid secret key immediately.

Errors are also written to the PrestaShop log (Advanced Parameters → Logs); search for axitrace.

GDPR: the psgdpr module

If PrestaShop’s official GDPR module (psgdpr) is installed, AxiTrace registers with it:

• The module appears in the psgdpr list of modules that process personal data.
• Data export for a customer includes what the module stored for their orders and carts: the attribution snapshot (visitor and click ids, IP address, user agent, landing page) and any queued delivery.
• Data erasure deletes the customer’s cart snapshots and queued deliveries and blanks the IP address, user agent and cookie ids stored for their orders. The order id and the fact that the purchase was sent are kept, so a later status change never sends the order again.

Data already received by AxiTrace is handled by AxiTrace; see our privacy policy.

Staging and test copies of your shop

Google Analytics 4 and ps_googleanalytics

PrestaShop’s Google Analytics module (ps_googleanalytics) can stay installed: it reports to your own GA4 property and does not interfere with AxiTrace.

Troubleshooting

FAQ

Source code & support

The module is open source under the Academic Free License 3.0 (AFL-3.0):

• GitHub: github.com/axitrace/axitrace-prestashop-module

Issues and pull requests are welcome. For direct support, email info@axitrace.com - we will personally help if your install is not working.