One View Across Amazon, Walmart, and Shopify: What Reconciles and What Never Will

Monday morning, an operator running Amazon, Walmart Marketplace, and a Shopify store opens three tabs to answer one question: how did last week go. The three tabs give three answers, and none of them are wrong. Amazon Ads is showing revenue booked against the day the click happened. Walmart is showing a number that will still be moving tomorrow. Shopify is showing whatever its session logic decided to credit, with everything else filed as direct.

The cost lands in the budget conversation. The discussion anchors on whichever number was loaded most recently, and nobody in the room can say out loud which definition of revenue they are arguing about. Averaging the three does not fix it. It buries it.

A cross-channel dashboard is still worth building. It just has to label its seams rather than hide them. What follows starts with what the finished view looks like, then works back through why each part of it is shaped that way.

Quick answer

• What reconciles. Spend, impressions, clicks, and units ordered. All three platforms count the same events the same way, so these can be summed once the timezone and reporting lag are aligned.
• What does not. Attributed revenue, ROAS, and conversion rate. Amazon reports sales on the click date, Walmart defaults to fourteen days post-click, and Shopify credits the last non-direct session.
• The trap in the middle. Total revenue looks summable and is not, until you fix one definition. Shopify's total sales includes tax and shipping; Amazon's ordered product sales does not.
• What a usable view does. Sums the metrics that reconcile, shows the ones that do not side by side with the window named under each, and normalizes calendar and currency before doing either.
• What you get from it. A Monday conversation that starts from the same definitions every week, so a change in the number means a change in the business rather than a change in who pulled the report.
• Skip blended ROAS. It moves whenever the channel mix moves, which makes it unreadable as a performance signal. Spend as a percentage of that channel's own total revenue is the portable comparison.

What the view looks like when it works

Start from the destination. A cross-channel view that survives contact with a Monday meeting has six blocks and fits on one screen.

• One header block. Spend, units, and net product revenue for the period, every channel, in one currency, on one timezone, using one revenue definition, stated in the header rather than assumed.
• One attributed-revenue block. One column per channel, never a single total, each labelled with the window it uses.
• One efficiency row per channel. Spend as a percentage of that channel's own total revenue. No blended ROAS anywhere on the page.
• One exception list. The three to five things that moved more than your threshold, with the prior-period comparison attached.
• One change list. What you altered in the period, on which channel, and when.
• One footnote line. The pull timestamp, the FX rate used, and the close lag applied.

That is a report a CFO can read and an operator can act on, and it is deliberately less impressive in a screenshot than the version that promises one unified number. Every choice in it is a response to a specific way these platforms disagree with each other. The rest of this post is those reasons, in the order the blocks appear.

Why attributed revenue gets one column per channel

Because the three platforms are not measuring the same week, even when the date filter says the same seven days.

Amazon reports attributed sales against the date of the click rather than the date of the purchase, inside a seven-day window for Sponsored Products and fourteen for Sponsored Brands and Sponsored Display. A Monday click that converts on Thursday lands in Monday's row, which is why last week's ad sales keep growing after last week ended. The Ads API exposes this rather than hiding it: version 3 Sponsored Products reports carry sales1d, sales7d, sales14d, and sales30d as separate columns, so the window is a reporting choice you make. Most dashboards pick one silently and never say which.

Walmart Connect defaults to fourteen days post-click, with three-day and thirty-day windows selectable, and documents a reporting lag of roughly twenty-four hours on advertiser reports. Put that next to Amazon's default and the problem is arithmetic rather than opinion: two numbers describing different windows on different clocks with different settlement lags. Add them and you get a figure whose attribution window is undefined.

Shopify is a different philosophy rather than a different setting. Its marketing reporting is session-scoped and defaults to last non-direct click, so a shopper who clicks an email link on Tuesday evening, browses, and checks out on Wednesday morning starts a new session and gets credited to direct. Shopify runs no post-click window measured in days at all.

So: three columns, three labels. The discipline that makes it work is picking one house posture and labelling every deviation from it. Fourteen days post-click is a defensible choice, because Walmart already defaults there, Amazon Sponsored Brands and Sponsored Display already sit there, and the Ads API will return sales14d for Sponsored Products so the marketplace side lines up on one basis. Shopify will not join that basis, which is exactly why it gets its own column with "last non-direct session" written underneath.

One Walmart-only note: Walmart reports in-store attributed sales in beta, split into advertised SKU sales and halo from other SKUs in the brand. Amazon has no equivalent for a marketplace seller and Shopify has none at all, so any row including Walmart in-store is a Walmart-only row by construction.

Why the header block carries one revenue definition

Because the word revenue does not survive the trip between the three platforms, even setting attribution aside.

Shopify reports gross sales as product price times quantity before tax, shipping, discounts and returns; net sales as that minus discounts and returns; and total sales as gross less discounts and reversals, with tax, shipping and fees added back. Amazon's ordered product sales is item price times units ordered on the order date, including orders the customer later cancels and excluding shipping. Amazon settlement data covers what has shipped and been released for payment, which is a different population of orders entirely.

The failure mode is specific. Drop Shopify total sales next to Amazon ordered product sales in one column and the Shopify side is inflated by tax and shipping while the Amazon side is inflated by orders that never shipped. Both distortions are real, they point the same way, and neither is visible in the chart.

Net product revenue before tax and shipping, on the order date, is the definition that survives all three with the least violence. Pick it, force every channel into it, and say so in the header.

Normalize the calendar and the currency before the money

Amazon Business Reports run on the marketplace's local time while settlement runs on UTC, which opens a window of several hours at the start and end of every month where the same orders land in different periods. Shopify reports on the store's configured timezone. Walmart sits on its own clock with its own lag. A month-end close that pulls all three at midnight local time will cut at least one of them in the wrong place.

Then hold every channel to the same close lag, which in practice means the slowest one. Walmart's roughly twenty-four hour reporting lag sets the floor: a dashboard refreshing Amazon hourly and Walmart daily shows a mix-shift artifact every morning that looks like a Walmart problem and is a refresh-schedule problem.

Currency has a similar quiet edge. Shopify converts orders taken in a customer's presentment currency into the store's currency for admin reporting, and notes those converted values are estimates until the customer is charged. Marketplace figures arrive in the marketplace currency. A single-currency dashboard is doing conversion somewhere, and the honest version says which rate and as of when. That is what the footnote line is for.

Why there is no blended ROAS on the page

Blended ROAS across three channels with three attribution models moves whenever the channel mix moves, which makes it unreadable as a performance signal. A quarter where Shopify grew and Walmart shrank produces a different blended number with no underlying performance change at all.

Spend as a percentage of that channel's total revenue is far more portable, because total revenue is a fact the channel reports without an attribution model attached to it. It is the same logic behind TACoS on Amazon, applied one channel at a time and then stacked. If you want the full vocabulary for the marketplace side, the PPC metrics that matter breakdown covers where each one holds up.

What is safe to sum, and what is not

Where a spreadsheet, a BI tool, and a general-purpose AI each break down

Most operators have already tried at least two of the four options below.

A weekly spreadsheet pull works and is the honest baseline. It fails on repetition: the person who built it holds the definitions in their head, and the next person to run it makes slightly different choices about the attribution column and the revenue column. A BI tool fixes the repetition and the visuals, and gives you a warehouse to join on. It does not decide what a metric means, so the reconciliation logic ends up scattered across transformations that nobody reviews. A general-purpose AI tool is genuinely good at the analysis once you hand it clean exports, and it will spot the mix shift you missed. What it will not do is hold your operating standard across weeks: ask the same question next Monday and the attribution window it assumes may quietly differ, which makes week-over-week comparison unreliable in exactly the place you need it to be reliable.

Note the fourth row. A codified routine is worse than a curious human, and worse than a general-purpose model, at noticing something nobody thought to look for. That is a real tradeoff, and the answer is to keep a human reading the view rather than to pretend the routine covers it.

Where Qore fits: the reporting routine written down once

The break point is the second Monday. The first cross-channel report is a project, and projects get done carefully. The fifty-second one is a chore, and chores get done by whoever is free, with whatever attribution column they happen to click. The definitions drift, and the drift is invisible because the chart still renders.

Qore is where you take a review you currently do by hand and write it down as a workflow that runs itself: the pull, the calendar normalization, the revenue definition, the attribution posture, and the flags you want raised, all set out as inspectable steps rather than living in one person's head. Internally we call it the codified-workflow layer of Trellis. Practically, for this job, it means the reconciliation decisions become part of the artifact instead of part of the folklore, and the same inputs return the same output next week. Q, the assistant inside it, helps you shape the skill; Qore is what runs it. Channel coverage spans Amazon, Walmart, Google, Shopify, and TikTok, which is the reason this particular use case fits it rather than a marketplace-only tool.

Built this way, the skill has five parts that map onto the view above: the connectors and the date window, the normalization rules, the metric definitions with their attribution labels, the comparison logic against the prior period, and the exception list. Write it once, run it on a schedule, and the Monday conversation starts from the same definitions every week.

A reporting skill mostly produces a view rather than changes, so the approval question is quieter here than on a bidding workflow. Where a skill does take an action, it starts gated on your sign-off, and that gate is a setting you tune rather than a permanent state: once a routine has made the same call correctly over several runs, you can tighten its rules until the clear-cut cases run unattended and only the judgment calls reach you. Qore is in open beta, and you can sign up here.

A view is only as explainable as the execution underneath it

There is a second reason cross-channel numbers are hard to read, and attribution windows have nothing to do with it. A number moves because something changed, and on most accounts nobody wrote down what. Somebody raised a bid on Tuesday. Somebody moved a price on Thursday. A rule fired at 3am. By the time Monday's view shows Walmart down and Shopify up, the history that would explain it is spread across three consoles and one person's memory, and the reconciliation turns into an argument about what people think happened. That is why the view has a change list in it.

That is also the half of the problem Qinetix addresses. It runs bids continuously inside zones you set with a floor and a ceiling, reprices inside a band you define on demand, margin and inventory cover, and records every move with the rule and the data that caused it. For a cross-channel view, that log is worth more than the automation: when the report surfaces a change, you can put your own change history beside it and separate what the market did from what you did. A reporting layer sitting on top of execution nobody can audit is a chart with a guess attached.

What none of it does is decide anything. The view tells you Walmart ROAS fell and Shopify direct revenue rose, and a person still has to judge whether that is a real mix shift or a session-attribution artifact. Coverage is also not equivalence: Walmart in-store attribution is beta and Walmart-specific, off-marketplace demand creation on Shopify is demand creation rather than a closed attribution loop, and depth differs by channel.

If your problem is management rather than measurement, keeping bids, budgets, and price consistent across the channels you run, that is a different piece of work: see cross-channel retail media and price parity. If you run many accounts and need a shared view for a peak event, the Prime Day command center covers that shape instead.

One honest view beats three consoles

The reason cross-channel reporting has a bad reputation is that most attempts promise reconciliation they cannot deliver, then quietly average three incompatible numbers to keep the promise. The version that holds up does the opposite: it sums the four things that genuinely reconcile, shows the ones that do not side by side with their windows named, and normalizes the calendar and the currency before either.

Build the six blocks first and keep the first version small enough that you will maintain it. If you want a worked example of the single-channel version before you go wide, the Amazon ads dashboard walkthrough is the closest starting point, and the Amazon PPC account audit workflow shows the same discipline applied to a recurring review. Then write the standard down once, let it run, and spend the recovered time on the decisions the view surfaces.

The bottom line for ecommerce teams

• Fix one revenue definition and force every channel into it. Net product revenue before tax and shipping, on the order date, survives all three with the least distortion. Put it in the column header.
• Never sum attributed revenue. One column per channel, one label each, every time.
• Set the close lag to the slowest channel. Walmart's roughly 24-hour reporting lag sets the floor. Refreshing Amazon hourly and Walmart daily manufactures a mix-shift artifact every morning.
• Normalize the calendar before the money. Amazon Business Reports run on marketplace local time, Amazon settlement on UTC, Shopify on the store timezone. A midnight month-end close cuts at least one in the wrong place.
• State the FX rate and its as-of date. Your dashboard converts currency whether or not it admits to it, and Shopify's converted figures are estimates until the customer is charged.
• Keep a change log on the execution side. Knowing what you changed and when answers half the questions a cross-channel view raises, and no attribution model will answer them for you.
• Keep a human reading the view. A codified routine finds what you told it to look for. It will not notice the thing nobody thought to check.

Related reading: selling on Walmart versus Amazon for the mechanical differences between the two marketplaces, and the Shopify integration announcement for how Shopify data enters the picture.