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.
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.
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.
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:
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.
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.
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.
For the store owner the setup is short, and most of it is checking rather than doing:
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.
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.
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.
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
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.
What AI assistants read, how to feed them one clean catalog, and how to see the sales ChatGPT, Gemini and Perplexity send you.
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.
One or two a month. No hype, no spam.