Why draft orders and manual orders are not tracked as conversions

By the HonestTag team · Published October 27, 2026

Your phone and draft orders never show up in Meta or Google. Here's why, and why that's usually right.

What these orders are

• Draft order. Shopify describes a draft order as "An order that a merchant creates on behalf of a customer," used among other things to "Create new orders for sales made by phone, in person, by chat, or elsewhere" and to "Send invoices to customers to pay with a secure checkout link." A draft turns into a real order when it is completed, either because the buyer paid the invoice or because staff completed it, for example by marking it as paid (DraftOrder, draftOrderComplete).
• Manual or phone order. Not a separate Shopify order type. It is what merchants call an order a staff member keyed in for a buyer who called, emailed or messaged, usually as a draft order.
• Point-of-sale order. A sale rung up in person on Shopify POS.
• The order's source. A Shopify order can carry a source name, "The name of the source associated with the order, such as "web", "mobile_app", or "pos"" (Order). Shopify's own filter examples on that page include source_name:web and source_name:shopify_draft_order. The field is a string, and an app that completes a draft can set a channel handle as its source instead.

A browser pixel runs in the buyer's browser while they shop and check out. Shopify's pixel event for a purchase, checkout_completed, "logs when a visitor completes a purchase" and is "triggered once for each checkout" (checkout_completed). An order that staff create and mark as paid, or ring up at a register, has no checkout in the buyer's browser, so there is nothing for a pixel to see.

A month of orders, by source

The numbers below are illustrative, not from a real store. A store takes 200 orders in a month:

• 150 online store checkouts.
• 20 draft orders the buyer paid through the invoice link, in their own browser.
• 15 draft orders for phone and wholesale buyers that staff marked as paid.
• 10 point-of-sale orders at a market stall.
• 5 more draft orders a rep keyed in for buyers who sent a message, then marked as paid.

The store's own count is all 200. A browser pixel can see at most 170: the 150 checkouts and the 20 invoice checkouts. It never sees the other 30 (15 + 10 + 5), because none of them had a checkout in the buyer's browser. A tool that forwards every Shopify order to the platform from a server sends all 200, including the 30 that did not pass through a checkout in the buyer's browser.

So the same month reads as 200 orders in Shopify, up to 170 to a browser pixel, and 200 to a server tool that forwards everything. Only Shopify's 200 is the store's count. The other two are what each method lets the platform see.

Why these orders go missing, or get counted wrongly

• No checkout, no pixel. A draft order marked as paid, a register sale and an order keyed in by staff all skip the browser checkout. The checkout purchase event does not fire, so a pixel never tells the platform about the sale. The platform learns of it only if something else sends the sale.
• The invoice link is a checkout. Shopify sends the buyer "a secure checkout link." When the buyer opens it and pays in their own browser, a pixel on that checkout can see the purchase, and the platform can credit it to an ad click that browser had.
• The wrong browser opens the link. If a sales rep opens the invoice link and pays on the buyer's behalf, the checkout happens in the rep's browser. A click that browser has, for example from a link tagged for an ad in a marketing email, can then get the credit for a sale the rep took by phone.
• Forwarding every order. Server-side delivery that sends every Shopify order, whatever its source, hands the platform sales that never passed through a checkout. Crediting one of those to an ad can make that ad look better than it was, when the ad did not bring the sale in.

What the platforms offer for sales off the website

Google Ads and Meta both have a route for a sale that did not happen on the website. Google says that by importing offline conversions "you can measure what happens in the offline world after your ad results in a click or call to your business" (About offline conversion imports). Meta's Conversions API asks where each conversion happened, with values such as website, phone_call ("Conversion was made over the phone") and physical_store, and says that by using it "you agree that the action_source parameter is accurate to the best of your knowledge" (server event parameters). A phone sale sent as a website purchase is not that.

The trade-off

Sending every manual order to the platforms makes each platform's number bigger and less true: a repeat wholesale buyer who phones in an order was not brought by the ad that last reached them. Keeping manual orders out makes the platforms undercount real revenue, including sales an ad did start. Neither platform number is the store's total. The full count belongs in the store's own report, and a platform should get only the sales it can honestly be tied to.

What HonestTag does with these orders

• Kept out by default. Draft orders and orders whose source is iphone or android are kept out of ad platform delivery unless phone and draft order matching is on for the store, which sends such a sale only to the platform of the buyer's own first ad click or ad-tagged link.
• How the match works. With matching on, a draft order the buyer paid in their own browser is credited to that browser's first ad click or ad-tagged link (or, when that browser has none, matched by email or phone as below), and sent to that one platform as its normal website purchase. Any other such order needs the buyer's email, then phone, to match an earlier web order; the sale then goes only to the platform of that visit's first ad click or ad-tagged link, labeled with that platform's own phone or offline source, never as a website purchase. With no match, a first click that was not a paid ad click, or a platform with no documented phone route, no platform receives it. Orders whose source is iphone or android follow the same rules. A browser your staff mark with a one-time staff link is never used for anyone's order, so an invoice a rep pays on the buyer's behalf is not credited to the rep's clicks.
• Point of sale. Register sales are kept out unless you switch them on, and are never sent as a website purchase. Switched on, they go only to a platform that documents a source for them; every other platform keeps them out.
• $0 orders. HonestTag has no rule that holds back an order for being $0. A free order from your online store is sent like any other purchase, with a value of 0 (Pinterest gets it with no value). A sample or replacement keyed in as a draft order follows the same rules as any other draft order.
• Your own numbers. Every one of these orders still counts in your store's own numbers, whether or not any platform receives it.

The server-side delivery docs say what is sent for each of these. If another tool also sends purchases to the same platform, read duplicate purchase events first.

Frequently asked questions