Server-side tracking

What server-side tracking does

The browser pixels on your checkout only report what the buyer's browser lets through. Ad blockers, browser privacy settings and a tab closed too early drop a share of the events, so fewer purchases reach your ad account than you really made.

With server-side tracking, LatchPay's server also sends each checkout's steps and its purchase straight to the platform: from your own token, to your own pixel, dataset, data stream or ad account. These events arrive even when the pixel was blocked. The browser pixel keeps running next to it, and both send each event with the same id, so the platform counts it once.

Five platforms are supported. Each has a card on Tracking and a step-by-step guide:

• Meta Conversions API
• TikTok Events API
• Google Analytics 4 Measurement Protocol
• Pinterest Conversions API
• Snapchat Conversions API

You connect a platform by pasting a token from its ads tool. Settings are per store: switch the store with the business button and each store sends to the accounts you connect for it. The page works on every plan.

Which events are sent, and when

Three events per checkout, only to the platforms you connected:

• Checkout opened, when the buyer first opens the checkout page. A link preview in a chat app or a browser that loads the page ahead of time does not count. Meta and TikTok: InitiateCheckout. Pinterest: initiate_checkout. Snapchat: START_CHECKOUT.
• Payment started, when the buyer presses pay and a payment is started. Meta and TikTok: AddPaymentInfo. Pinterest: add_payment_info. Snapchat: ADD_BILLING.
• Purchase, when the payment is confirmed. It is sent from the payment confirmation itself, not from the thank-you page, so it also arrives when the buyer closes the tab. Meta and TikTok: Purchase. Google Analytics 4: purchase. Pinterest: checkout. Snapchat: PURCHASE.

Google Analytics 4 gets only the purchase from the server; the two checkout steps reach it from the browser, as before (see Google Analytics 4 and Google Ads).

Each event carries the checkout total at that moment (shipping and tax included, the same number the pixel sends), the currency, and the products: the Shopify variant id, quantity and price of each line. Events are sent within seconds; the checkout and the payment never wait for a platform.

Counted once: the event id

The pixel in the browser and LatchPay's server send every event with the same event id, and each platform keeps one of the two:

• The checkout steps use the checkout's own id with the event name, for example 6f1c…-begin_checkout. The checkout link itself is never part of it.
• The purchase uses the payment id, the same id the order shows on Orders.

Meta, TikTok, Pinterest and Snapchat drop a second event with the same name and id within 48 hours. Google Analytics 4 keeps one purchase per transaction id. A refresh of the thank-you page or a repeated payment confirmation never sends a purchase twice.

What helps a platform recognise the buyer

A platform can only credit a purchase to an ad when it recognises the buyer. The better it matches, the higher Meta's event match quality and TikTok's event quality. With each event LatchPay's server sends:

• the email address, phone number and first and last name the buyer entered, always turned into a SHA-256 hash on LatchPay's server first, in the format each platform asks for;
• the city, region, postal code and country, hashed the same way where the platform asks for it, and sent in plain text to Google Analytics (and the city, region and country to TikTok), as their APIs require;
• a hashed form of the random browser id your store's theme line gives each visitor;
• the IP address and browser (user agent) of the buyer's checkout request at that moment;
• the ad click ids from the landing page address (fbclid, ttclid, epik, ScCid) and the ad cookies the platforms' own pixels set on your store (Meta's _fbp and _fbc, TikTok's _ttp, Google Analytics' _ga, Pinterest's _epik, Snapchat's _scid).

The click ids and cookies come from your storefront: on a store with at least one token saved, the theme line reads them and hands them to the checkout. It keeps a click id for 30 days in the browser and reads ad cookies but never creates or changes one. It does this also when the browser sends Global Privacy Control or Do Not Track, unless you respect those signals (see Browser privacy signals). The checkout also reads the ad cookies your pixels set on the checkout itself. Nothing needs setting up for this.

Consent is your responsibility

The platforms receive the data under your own agreements with them. How LatchPay handles it is in the privacy notice.

Browser privacy signals (Global Privacy Control, Do Not Track)

Some browsers tell every site that the buyer does not want to be tracked: Global Privacy Control (sent by Brave, DuckDuckGo and privacy extensions) and the older Do Not Track. On Tracking, under the consent note, each store has one switch for them: Respect browser privacy signals (Global Privacy Control / Do Not Track). It is off by default.

• Off (the default): LatchPay ignores these signals for ad tracking. The theme line reads the ad click ids and ad cookies, and the server sends the checkout steps and the purchase, for every buyer. The browser pixels still do not load in such a browser, as before, and LatchPay's own storefront events stop there too.
• On: a checkout whose browser sends either signal gets no ad tracking at all. The theme line reads no click ids or ad cookies, no pixel loads on the checkout, the thank-you page or the post-purchase offer, and the server sends nothing for that checkout: not the checkout steps, not the purchase, not the purchase of a post-purchase second order. Buyers without a signal are tracked as usual.

With the switch on, LatchPay notes on the checkout that its browser sent a signal (nothing else), so the purchase is left out even though the payment is confirmed later, without the buyer's browser. A signal seen at any step counts for the whole checkout; events already sent before it are not called back. Turning the switch off again applies to events from then on. Whether you must respect these signals depends on where your buyers live (in California, for example, Global Privacy Control is a legal opt-out of sharing); ask your own advisor.

Another app already sends purchases (WeTracked, TrackBee and others)

Some tracking apps, such as WeTracked and TrackBee, send a purchase to your ad platforms for every Shopify order, and LatchPay creates a Shopify order for every paid checkout. Such an app then sends its own purchase for a LatchPay order next to LatchPay's. The two carry different event ids, so the platform may count the order twice.

LatchPay cannot reuse the other app's id: these apps do not publish the event id they give a purchase. So each platform card has a switch, Another app already sends purchases to the platform. With it on, LatchPay sends no purchase to that platform, from the browser or the server, and keeps sending the two checkout steps (the other app never sees LatchPay's checkout, so those are not doubled). The switch is off by default.

For WeTracked, LatchPay also writes the storefront's cart token on every Shopify order it creates, as the order attribute shopify-cart-token (under Additional details). That is the name WeTracked reads to join an order made outside Shopify's checkout to the visit it tracked on your store, so its purchase can carry the ad click that brought the buyer. A post-purchase second order has no cart of its own and carries none.

LatchPay also copies every attribute of the storefront cart onto the order, as Shopify's own checkout does: the tracking data apps such as TrackBee keep in the cart, gift notes, delivery dates. LatchPay's own attributes and your custom fields win when a name is the same.

How to find out whether you need it

• Place a small test order with the switch off and look at the Purchase events for that order in the platform's events tool a few minutes later.
• Two purchases (the other app's and LatchPay's): the other app sends LatchPay orders too. Switch it on for that platform only.
• One purchase: the other app skips LatchPay orders. Leave the switch off.
• When you connect the other app to a new platform later, or remove it, check again and change the switch to match.

Google Analytics 4 and Google Ads

Google Analytics 4 only merges a duplicate purchase, by its transaction id; it cannot merge a checkout step sent twice. So LatchPay's server sends Google Analytics 4 the purchase only, with the payment id as transaction id. The checkout steps keep coming from the browser tag.

With the API secret saved, the checkout's browser tag and the server use the same Google Analytics client id as your storefront, so the purchase joins the visitor's session and keeps the source that brought them. Listing your store's domain under unwanted referrals in the data stream helps with that (the Google Analytics guide shows where).

Google Ads: LatchPay does not connect to Google Ads itself. Import the Google Analytics 4 purchase as a conversion in Google Ads and it counts the server purchases too.

Google's server accepts every event it receives, even with a wrong API secret, so "sent" on the Google Analytics card means Google's server accepted it. Check DebugView or Realtime to see it arrive.

Test events, statuses and retries

Each platform card on Tracking shows where it stands:

• Off: nothing is saved. Pixel only (Pinterest: Tag only): the browser pixel runs, no server events. Pixel + server: both run.
• Needs a new token: the platform refused the token, for example because it was deleted or your access changed. Events wait; paste a new token and they are sent within minutes.
• Check the setup: in the last 24 hours something other than the token went wrong, such as a refused event or a platform that did not answer. The card says what in plain words.

Under it: when LatchPay last sent an event, how many it sent and how many failed in the last 7 days, and how many are waiting. Send test event checks the token without touching your reports; each guide says what it sends and where to look.

When a platform does not answer or asks LatchPay to slow down, LatchPay tries again after 1, 5 and 15 minutes, then after 1, 3, 6, 12 and 24 hours. The platforms refuse events older than 7 days (Google Analytics 4: 72 hours), so an event still waiting by then is dropped and counted under failed. Remove deletes the token; events still waiting for that platform are dropped and the browser pixel keeps running.

What is never sent

• Test orders. A store whose payment account is in test mode sends no server events at all.
• The checkout link, card details, the order note, gift messages or custom fields.
• Refunds, cancellations and chargebacks: the purchase stays in the platform's reports. Storefront events (product views, add to cart) are not sent from the server either: your Shopify pixel apps keep covering the storefront.
• Anything to a platform you did not connect, or with a token other than yours.

How long LatchPay keeps it

The buyer's IP address and browser are stored encrypted, next to the click ids and ad cookies, only until the events that need them are sent: at most 8 days. The send log keeps the event name, time, value and product ids, without any personal data, for 30 days, for the counts on the card. None of it is ever written to LatchPay's logs. Tokens are stored encrypted and the page only ever shows their last four characters.