Troubleshooting Guide

Likely Cause: The site key is incorrect, the script is not loading, or a browser/network extension may be suppressing the endpoint.

Fix: Verify that the script tag exists in your HTML source and contains the exact Site Key from settings. Check the browser Console and Network tabs for blocks. We recommend running the Browser Connection Check inside the Setup Doctor.

How to Verify: Look for the "track" network request returning a 200 success response.

Likely Cause: The conversion script was fired before the window.sourcetrack object finished loading, or the script tag did not fire on the thank-you/success page.

Fix: Wrap your conversion script in a load event listener or check that it executes after the main script loads. Ensure the tracking script is installed on the checkout confirmation page.

How to Verify: Paste a manual conversion call into the browser Console on your checkout page and verify it appears in the Event Debugger.

Likely Cause: The conversion script is fired multiple times (e.g., when the user refreshes the thank-you page).

Fix: Pass a unique, stable order_id parameter (such as the order number or payment intent ID) in your conversion options body. SourceTrack automatically skips duplicate payloads carrying the same order_id from a given integration. If more than one order-reporting integration is active for the same store, a duplicate can persist for up to 24 hours until the nightly reconciliation job resolves it — use a single order-reporting integration per store to avoid this.

How to Verify: Trigger the event twice in your console. The first should return success, and the second should be logged as deduplicated.

Likely Cause: Your browser pixel and the CAPI forwarding in SourceTrack each report the same conversion to the ad platform. Meta and TikTok reliably merge the two into one only when both carry the same event ID, and that does not happen by default.

Fix: Generate one stable ID per conversion and send it in both places: as the eventID on your pixel call, and as the event_id field in your window.sourcetrack.conversion() options body. Any stable string works so long as it is byte-identical on both sides — the order number is a common choice. If you do not supply event_id, SourceTrack falls back to an internal identifier that a standard pixel install will not reproduce, so the two reports stay separate and the conversion is counted twice. This applies to Meta and TikTok, which share the same event-ID model. Google Ads and GA4 deduplicate on a different mechanism and are not covered by it.

How to Verify: Send one test conversion, then open that event in Meta Events Manager or TikTok Events Manager. A correctly shared ID shows the browser and server events merged into a single deduplicated event rather than two separate ones.

Likely Cause: The built-in Facebook & Instagram sales channel in Shopify reports purchases to Meta over its own connection. Those events never reach SourceTrack, so no deduplication performed by SourceTrack can apply to them.

Fix: Report each order to Meta from one place only. Either turn off customer data sharing in the Shopify sales channel and let SourceTrack forward the order, or keep the sales channel as your reporting source and leave Meta forwarding switched off for that store. Sharing an event_id does not help here: the sales channel has no knowledge of the ID SourceTrack uses, and the two connections operate independently.

How to Verify: Compare purchase counts in Meta Events Manager against the actual order count in your Shopify admin for the same date range. Roughly double the orders means two connections are reporting, and the source breakdown in Events Manager will name both.

Likely Cause: Not the cause: the site that linked to you needing our script. Referral detection reads document.referrer, which the visitor's own browser sets as it follows the link, so the referring site sends us nothing and needs nothing installed. What actually empties it is the hop: a strict Referrer-Policy on the referring site (no-referrer or same-origin, which many large sites and most email providers set deliberately), an HTTPS page linking to an HTTP one (browsers drop the referrer on that downgrade), or a link opened from a native app, chat client or PDF viewer that never sets one. Private windows and untagged ad clicks land the same way.

Fix: Fix the half you control: serve your own site over HTTPS so inbound HTTPS links keep their referrer, and put UTM parameters on every campaign, email and partner link you own — a UTM survives all of the above because it travels in the URL rather than in a header. The other half is not fixable, and should not be treated as a bug: when a referring site sets no-referrer or a visitor arrives from an app that strips it, that visit is genuinely indistinguishable from someone typing your address in. It belongs in Direct, and no analytics tool can recover it without inventing a source.

How to Verify: On the landing page of a fresh visit, read document.referrer in the console — empty means the browser sent nothing, so the gap is upstream of us, not a tracking failure. To tell "legitimately Direct" from "broken", watch the shape rather than the level: a steady share of Direct is normal, while a source that collapses to Direct suddenly, or Direct jumping right after a site or link change, points at a real regression worth chasing.

Likely Cause: The st_aid attribute was not successfully saved on the Shopify cart object, or the Shopify webhook HMAC check failed.

Fix: Ensure your theme files update the cart attributes successfully before the customer reaches checkout. Check that your Shopify webhook url is configured with the correct site key.

How to Verify: Add items to your cart, fetch the cart JSON (yoursite.com/cart.json), and verify that "st_aid" exists inside the attributes object.

Likely Cause: The st_aid metadata parameter was not forwarded in the Checkout Session or Customer object creation call.

Fix: Verify your backend API code is extracting "st_aid" from requests and passing it in the metadata configurations of the Stripe object creation.

How to Verify: Inspect the Checkout Session object in your Stripe Dashboard logs to verify that the metadata contains the correct st_aid value.