How do I set up conversion tracking for Shopify?

Tracking problems are usually definition problems wearing a technical disguise, so settle the definitions first and write them down.

The primary conversion is a completed order. Everything else, including add to cart, checkout started, signups and page views, is a secondary event used for diagnosis and audience building, never for bidding. Accounts that optimise towards add to cart because it produces more data end up buying people who add and leave.

Then decide what the order value means. Does it include tax and shipping. Does it net off discounts. Are subscription renewals counted, and if so are they the same conversion as a first order. Do wholesale or point of sale orders belong in the ad platform at all. Each answer changes the number, and having two people assume different answers is how a store ends up with reports nobody trusts.

Decide the deduplication key too. The order number is the natural one, and it should be sent with every purchase event from every source so the same order can never be counted twice.

Finally, decide who owns it. One person should be responsible for the tracking setup, and the accounts should be in the store's own name, not an agency's, so the history stays with the business whoever manages the campaigns.

Once those decisions exist, the installation is a short job. Without them, every future disagreement about numbers restarts from nothing.

Modern checkouts do not allow arbitrary scripts, so the old approach of pasting tags into theme files and the order status page no longer works and should not be attempted.

There are two supported routes. The first is the official sales channel app for the ad platform, connected inside the store admin. That handles the purchase event, the product identifiers and, on most platforms, the server side connection, with the least chance of a mistake. For most stores this is the right choice.

The second is a custom pixel added through the customer events area of the admin. That is where you put anything the channel apps do not cover, including analytics tags and third party tools. Custom pixels run in a controlled environment and are subject to the customer privacy settings, which is the point of them.

Either way, take care with product identifiers. The ad platform needs to match the purchased items to the products in your feed, so the identifier sent in the event has to match the identifier in the product data. When they disagree, the purchase is counted but not attributed to the product, which quietly breaks product level reporting and bidding.

Avoid running two installations of the same tag. A channel app plus a manually added pixel for the same platform is the most common source of doubled revenue, and it makes every campaign look twice as good as it is until somebody notices.

And check the settings for subscription renewals and for draft orders, so recurring charges and internal orders do not silently enter the ad reporting.

Browser based tracking misses orders. Blockers, privacy settings, older devices, network failures and people who bounce between apps all remove events that genuinely happened. A server side connection sends the order from the store's back end, which is not subject to any of that.

Set it up alongside the browser event, not instead of it, and pass the same identifier with both so the platform can deduplicate. If the deduplication key is missing or different, you get double counting, which is worse than the gap you were trying to close.

Send the customer data the platform supports for matching, hashed as required, and only the fields you are permitted to send. Better matching improves attribution more than almost any bidding change, and it is a one time setup.

Consent is the other half. Where you operate under rules that require it, the tracking has to respect the visitor's choice, which means using the platform's consent signalling rather than simply blocking tags. Done properly, you keep modelled data for people who declined instead of losing them entirely. Done badly, either you break the rules or you throw away information you were allowed to keep.

Test the consent states deliberately. Accept, decline, and no choice yet, on a fresh browser, in each region you operate in. The common failure is a banner that blocks everything until a click, on a page where most visitors never click, which removes a large share of your data without anyone noticing for months.

A tracking setup is not finished until a real order has been followed from the checkout to every report it should appear in.

Place a genuine low value order, or use the platform's test mode where one exists, and check four things. The purchase event fired once. The value matches what you decided the value should mean. The order identifier is present. The products are identified with the same codes used in your product feed.

Use the debugging tools on each platform to watch the event arrive, and then check the reports the next day, because real time views and final reports can disagree.

Then check the paths that break most often. Express wallet payments that skip parts of the normal flow, payment methods that redirect to an external page and come back, an order completed on a phone after being started on a desktop, and any subscription or deferred payment route. Each of these can miss the event while the standard credit card flow works perfectly.

Remember to exclude your own traffic and any test orders from analytics, and to cancel or refund the test order so it does not sit in your revenue figures.

After that, make verification routine. Compare ad platform conversions with orders in the admin monthly, and check again after any theme change, app installation, checkout change or platform update. Tracking rarely breaks loudly. It usually breaks a little, on one payment method, and the first sign is a slow unexplained decline in reported performance.