Tracking is how your store tells the outside world what just happened. A visitor lands from a TikTok ad, looks at a product, adds it to the cart and pays. Tracking records each of those steps and sends them to the tools that need them: your analytics, your ad platforms and your email tool. Without it, you know you made 40 sales yesterday but not which of your three campaigns made them.

The term concerns every seller who spends money or time on traffic and wants to know what came back. Creators comparing a Reel to a Story, brands splitting budget between Meta and Google, and small stores deciding whether an influencer collaboration paid off all rely on the same plumbing. Conversion tracking is the plumbing.

What is conversion tracking?

Conversion tracking is the recording and attribution of valuable actions on your site. A conversion is any action you decided matters: a purchase, an email sign-up, an add to cart, a download. Tracking attaches to each conversion the information needed to answer "where did this come from?" and "how much was it worth?".

It is built from four layers, which people often confuse:

  • Pixels and tags. Small scripts loaded in the visitor's browser. The Meta pixel, the TikTok pixel, the Google tag and the Pinterest tag each report events to their own platform. A tag manager loads them all from one container.
  • Events. Named actions with parameters: PageView, ViewContent with a product ID, AddToCart with a value, Purchase with an order ID, total and currency. The names are standard per platform.
  • Server-side events. The same events sent from your store's server directly to the platform's API (Meta Conversions API, TikTok Events API, Google enhanced conversions). They do not depend on the browser and survive ad blockers and some consent gaps.
  • UTM parameters. Text added to a link, such as ?utm_source=instagram&utm_medium=story&utm_campaign=spring-drop. They tell your own analytics where a visit came from, independently of any ad platform.

What tracking is not: it is not surveillance of individuals, and it does not have to be. Aggregated counts per source are enough to make every decision in this glossary. It is also not a one-time setup: platforms change event names, browsers change what they allow, and a theme update can silently remove a tag.

Related terms: conversion rate is the first number tracking produces, retargeting ads depend on tracked audiences, and return on investment cannot be computed per channel without it.

Why it matters

Consider a store that spends $1,200 a month on ads across Meta, TikTok and Google, with 90 orders at a $60 average. Total revenue $5,400, blended cost per order $13.33. That looks fine. With tracking per channel the picture changes: Meta spent $500 for 55 orders ($9.09 each), Google spent $300 for 30 orders ($10 each), TikTok spent $400 for 5 orders ($80 each). Moving TikTok's $400 to Meta would, at Meta's rate, add roughly 40 orders. Without tracking, the owner keeps funding the channel that loses money because the blended number hides it.

The second reason is the algorithms. Meta, Google and TikTok optimise delivery towards people likely to trigger the event you report. If the Purchase event never reaches them, they optimise for clicks or landing page views instead, and cost per order climbs. Advertisers who fix a broken purchase event routinely see cost per order fall 20% to 40% within two weeks, with no change to the ads.

The third reason is retargeting. Every audience of "viewed a product in the last 14 days" is built from tracked events. No events, no audience.

How it works

Setting up tracking for a small store follows the same order every time.

  • Decide the conversions. Purchase is mandatory. Add to cart and begin checkout help the algorithms and retargeting. Email sign-up if you run a list.
  • Install the base tags. One pixel per ad platform on every page, ideally through a tag manager so you install once and manage from one place. Include the link-in-bio page.
  • Fire events with parameters. Purchase must carry order ID, value, currency and product IDs. The order ID lets the platform deduplicate browser and server events.
  • Add server-side events. Send the same Purchase from the server with the same order ID. The platform keeps one copy. Coverage goes from roughly 60% of purchases to 90% or more.
  • Tag every link you control. Bio link, stories, emails, collaborations, QR codes. utm_source, utm_medium and utm_campaign at minimum. Keep a naming sheet so "instagram" and "Instagram" are not two sources.
  • Handle consent. Load pixels only after the visitor accepts, or run them in a consent mode that sends anonymised signals. Record the consent choice.
  • Verify. Place a test order and watch it appear in each platform with the right value. Use the platforms' event testing tools and the browser's network tab.

The result is three views of the same order: your store's own analytics (the truth), your ad platforms (their claim, each one counting the order for itself if the customer touched several) and your email tool. They will not match. That is normal; the job is to know why.

Benchmarks and examples

What well-configured tracking looks like for a small store in 2026:

  • Event match quality (Meta): 6 out of 10 or better, reached by sending hashed email, phone and name with server events.
  • Purchase coverage: browser-only pixels catch 55% to 70% of orders in Europe after consent; adding server events raises this to 85% to 95%.
  • Attribution gap: ad platforms combined usually claim 110% to 160% of the orders your store actually recorded, because each takes credit for shared customers.
  • UTM coverage: aim for 90% of sessions with a known source. Below 60%, most of your traffic is "direct" and you are guessing.
  • Setup time: half a day for pixels plus UTM discipline, one to two days to add server-side events.

Three situations:

A creator posts the same product in a Reel and a Story on the same day. Both link to the bio page, but with different utm_content values. Analytics show 320 visits and 14 orders from the Story, 900 visits and 9 orders from the Reel. She now leads with Stories for launches.

A brand discovers its Purchase event fired on the "order confirmation" page, which customers sometimes reloaded. Meta counted 128 purchases in a month where the store had 91. Adding the order ID for deduplication corrected it and the reported ROAS fell from 4.2 to 3.0, which was the true number all along.

A small store adds server-side events and sees Meta's reported purchases rise from 58 to 84 a month with the same spend. Nothing changed in sales; the platform simply started seeing orders it had missed, and its optimisation improved over the following weeks.

Common mistakes

  • Purchase without a value. The platform sees a conversion worth $0 and cannot optimise for revenue or report ROAS.
  • Events on the wrong page. Firing Purchase on the checkout page instead of the confirmation page counts every attempt as a sale.
  • No deduplication. Browser and server events for the same order both counted, inflating everything by up to 2x.
  • Inconsistent UTMs. "fb", "facebook" and "Facebook" become three sources and the report is useless.
  • Trusting one platform's dashboard. Each ad platform reports its own attribution. Only your store's order count is the truth.
  • Forgetting the consent layer. In the EU, pixels that fire before consent create legal exposure and, once fixed, a sudden drop in reported conversions that looks like a performance problem.

Best practices

  • Own the source of truth. Your store's orders and their sources, exported monthly, is the table every other report is checked against.
  • Send server-side events with the order ID. It is the single biggest improvement available for small advertisers and takes a few hours.
  • Keep a UTM sheet. One document listing every campaign name, medium and source spelling. Generate links from it, never by hand.
  • Use a discount code per campaign as a backup. Codes work when cookies, pixels and UTMs fail, and give a floor for what a campaign produced.
  • Review weekly, not daily. Attribution settles over 3 to 7 days as delayed conversions come in. Daily numbers swing too much to act on.
  • Test after every change. New theme, new app, new page: place a test order and check each platform. Most tracking breaks quietly.
  • Compare platform claims to real orders. Divide total orders claimed by all platforms by your real order count. If the ratio drifts upward, someone is over-claiming.

In Roctify

Roctify is not an ad platform, so pixels, tags and server-side events belong to the tools of the platform you advertise on. What Roctify gives you is the ground truth and the destinations. Every order, whatever the channel, lands in the same shared catalog with its products, customer and amount, and audience analytics and reports (Pro plan) show visitors, product views and orders per channel and can be exported for reconciliation. Your storefront, product pages and link-in-bio page are the pages your tagged links and ads point to, with a built-in checkout and 0% transaction fees. Discount codes give you one code per campaign as a tracking method that does not depend on cookies or consent.

FAQ

Do I need server-side tracking as a small store?

Once you spend more than a few hundred dollars a month on one platform, yes. Browser pixels lose 30% to 45% of purchases in Europe to consent refusals and blockers, and the ad platform optimises on what it sees. Server-side events with an order ID for deduplication recover most of the gap. Below that spend, correct pixels, UTM discipline and a discount code per campaign are enough.

Why do Meta, Google and my store report different sales?

Because each measures something different. Your store counts orders. Meta counts orders by people who saw or clicked a Meta ad within its attribution window, Google does the same for Google, and a customer who touched both is counted by both. Add consent gaps and delayed conversions and the numbers never match. Use your store as the truth and treat platform numbers as relative signals to compare campaigns within the same platform.

What are UTM parameters and do they replace pixels?

UTM parameters are tags added to a link that tell your own analytics where a visit came from: source, medium, campaign and optionally content and term. They work for any link you control, including bio links, emails and QR codes, and need no consent to function at the session level. They do not replace pixels, because ad platforms need their own events to build audiences and optimise delivery. Use both: UTMs for your reports, pixels and server events for the platforms.