Home / Blog / Sending verified orders back to Google and Microsoft

Ads

Sending verified orders back to Google and Microsoft

Why the platforms should bid on your real sales. How verified uploads, hashed identifiers, refunds and consent work between the pixel and your ad accounts.

CONVERSION UPLOADSSending verified ordersback to Google andMicrosoftOrkie

Google and Microsoft bid on the conversions they can see. If their tags miss half your orders, their bidding learns from half your business, and the campaigns that start slow sales get starved. Sending verified orders back to the platforms fixes that. This post explains what an upload is, what "verified" means, how refunds and consent are handled, and what changes in your account once the platform's number and yours start to agree.

The problem in one sentence

Automated bidding is only as good as the conversions it is trained on.

A Google or Microsoft tag records a purchase when the browser lets it. Blockers, consent banners, device switches and late orders all remove purchases from what the tag sees. To the bidding system, a campaign whose buyers take three weeks and switch devices looks like a campaign that does not convert. It pulls back. The campaign that was quietly opening your best sales gets less money.

Meanwhile, the campaign that closes same-day orders on the same device looks brilliant, because the tag sees all of it. Budget flows there. The picture is distorted in a consistent direction.

What gets sent back

Orkie's Pixel keeps a server-side copy of every order from Shopify or BigCommerce, joined to the browser session that led to it. Each of those orders can be sent to Google and Microsoft as a conversion, with:

  • The click ID captured on the landing page when the shopper arrived from the ad.
  • Hashed identifiers (email and phone, scrambled one-way) so the platform can match an order to a click even when the click ID is missing. This is what Google calls enhanced conversions.
  • The order value and currency, the real amount, not a default.
  • The order time, so late orders are credited to the click that started them.
  • The order ID, so the same order is never counted twice.

Only orders that clear the shopper's advertising consent are sent. A visitor who allowed analytics but declined ad sharing shows up in your dashboard and is never uploaded. The consent page shows both counts side by side, and the gap between them is the system doing its job.

"Verified" is the word that matters

A conversion the browser saw is a claim. A conversion the store platform confirmed is a fact. The Pixel only uploads verified orders, the ones the store itself reported.

That has a practical effect. Google's conversion count in your account is not an order count; several conversion actions can fire on one purchase. When you plan on the value column and reconcile it to store revenue, the two numbers should be close. If they are not, something in the upload path or the conversion action setup is off, and the workspace can tell you which.

Refunds go back too

An upload that ignores refunds makes the platform's return on ad spend look better than it is. Say a campaign drives $50,000 in orders and $8,000 of that is refunded. If Google keeps counting the full $50,000, it will bid as if the campaign earned more than it did.

When an order that was already uploaded is refunded, the Pixel tells the platform. A full refund removes the conversion. A partial refund replaces the value with the amount you kept. Only orders the Pixel uploaded itself are adjusted, only inside the platform's adjustment window, and never twice. The adjustments go out after each upload run. Where the platform has no automatic path for an adjustment, the affected orders are listed for you to adjust by hand, rather than silently dropped.

What "setup" actually involves

For the store owner the setup is short, and most of it is checking rather than doing:

  1. Connect the ad account in the workspace, with the permissions the platform now requires for uploads.
  2. Keep auto-tagging on so click IDs arrive on the landing URL. The workspace checks tracking templates on active campaigns, ad groups, keywords and Shopping product groups, and repairs missing ones after showing you the plan.
  3. Pick the conversion action the uploads go to. The workspace runs a setup check that confirms the purchase action exists, is enabled, counts one conversion per click, records real order value in your currency, and is primary for bidding. If a second purchase action is also primary, it asks whether to make it secondary, because two primary purchase actions double-count.
  4. Send a test, then let uploads run on their schedule.

On Microsoft, the equivalent is an offline conversion goal, with the same click-ID and hashed-identity matching, and the same primary-versus-secondary choice. If the account is ever disconnected, uploads queue and resume after a reconnect rather than being lost.

What you see afterwards

Two things change over the following weeks.

The platform's number starts to match yours. When the platform's reported conversion value is mostly your verified orders reflected back, the two figures converge. That is not a coincidence, and it is the single best sign the uploads are healthy. The workspace shows Google's campaign table beside the pixel's, so the gap per campaign is visible.

Bidding stops starving the slow campaigns. Late and cross-device orders are now visible to the bidding system, credited to the click that started them. Campaigns that open considered purchases stop looking broken. You may see their spend rise on its own as the platform learns they convert.

Say your store has one product line that people research for a month before buying. Before uploads, that line's campaign showed a return well below the account average and kept getting trimmed. After uploads, the same campaign's reported conversions include the orders that closed on day 20 and day 30, and the return it shows is closer to what the pixel always said it was.

What it does not do

Uploads do not inflate anything. They make the platform's count agree with the store's count. They do not send orders the store did not confirm, orders from shoppers who declined ad sharing, or orders that were refunded. They do not change your attribution model; the pixel's models and the platform's model remain separate lenses on the same orders.

They also do not replace the pixel. The pixel is the record. The upload is one thing the record is used for, alongside feed labels, email lanes and the CRM.

Where this fits

The order is the same on every store. Turn on the pixel. Let it verify orders for a couple of weeks. Connect the ad accounts and run the setup check. Turn uploads on. Then read the platform's numbers with a little more trust than before, because for the first time they were trained on your sales.

Want the platforms bidding on your real orders? Talk to us.


Want this for your business? Talk to us How the pixel works

Keep reading

RELATED PRODUCTSRelated products thatactually fitOrkie
Feeds

Related products that actually fit

Most "you may also like" widgets guess. Set related-product rules in plain words, like same brand or parts that fit, and measure what they really sell.

Sep 27, 2026 · 4 min read
AI SEARCHHow to get your productsinto ChatGPT answersOrkie
Feeds

How to get your products into ChatGPT answers

What AI assistants read, how to feed them one clean catalog, and how to see the sales ChatGPT, Gemini and Perplexity send you.

Sep 27, 2026 · 5 min read
HOW IT WORKSHow Orkie's pieces worktogetherOrkie
AI Workspace

How Orkie's pieces work together

The pixel steers the feeds, measures related products and tells the Outbox what each shopper left behind. CRM lists become ad audiences. The company brain keeps learning.

Sep 27, 2026 · 6 min read

Get new posts by email

One or two a month. No hype, no spam.