Analytics and Tracking

Tax and Shipping

Also called tax parameter, shipping parameter

Order components reported beside product value, so delivery charges and tax can be analysed without inflating revenue by accident.

Quick facts: Tax and Shipping

Category
Analytics and Tracking
Also called
tax parameter, shipping parameter
Level
Intermediate
Affects
Reported revenue, return on ad spend, product profitability
Where to see it
GA4 DebugView, Google Tag Manager preview, shop platform checkout settings
In this article4
  1. How tax and shipping are reported
  2. Why the split matters
  3. Where it goes wrong
  4. How to get it right

How tax and shipping are reported

An order total is made of parts: the products themselves, delivery charges, and any tax added at checkout. Ecommerce tracking lets you send the delivery and tax amounts as their own parameters on the purchase event, sitting beside the order value rather than hidden inside it.

Sending them separately does not automatically remove them from revenue. The value you attach to the purchase is whatever your code says it is; the tax and shipping parameters are extra detail, useful for reporting but not a deduction. If you want revenue to exclude delivery and tax, you have to subtract them when building the value, and then report them separately so the information is not lost.

The same words appear elsewhere with a different job. In a Merchant Center product feed, the shipping and tax attributes tell Google what to display next to a shopping listing. That is presentation for shoppers, not measurement, and the two should not be confused.

Why the split matters

Delivery and tax are money the business collects but largely does not keep. Tax is passed to the government, and shipping usually pays a courier. Counting both as revenue makes marketing look more profitable than it is, and the distortion is worst exactly where margins are thinnest: low-value orders where delivery is a large slice of the total.

It matters for bidding as well. When purchase values are imported into Google Ads or Meta, the platforms learn which products and audiences are worth pursuing from the values you supply. Inflate every order by its delivery charge and remote customers, who cost more to ship to, start looking like your best ones.

Where it goes wrong

The usual fault is inconsistency. Analytics counts one thing, the ad platform counts another, and the finance team counts a third, so no two reports on return on ad spend agree and everyone assumes the tracking is broken. Often it is not broken — it was simply never defined.

Tax rules cause the second problem. A store selling across borders may show prices inclusive of tax in one market and exclusive in another, so the same product records a different value depending on the buyer’s country. A shop that also offers free delivery above a threshold will see its shipping parameter fall away on larger orders, which is correct but surprises anyone comparing averages.

How to get it right

Decide once whether reported revenue is the amount the customer paid or the amount the business keeps, and write it into the tracking specification before a developer touches anything. Then send tax and shipping as their own parameters regardless of that choice, so the split can be analysed later without rebuilding the tracking.

Test it with a real order that includes delivery, tax and a discount together, and check the numbers add up the way your definition says they should. Finally, make sure the ad platforms receive the same figure as analytics. If Google Ads is fed order totals while GA4 holds product-only values, the two systems will disagree permanently and someone will waste a week trying to reconcile them.

Do and do not

Do

  • Decide whether revenue means amount paid or amount kept
  • Send tax and shipping as their own parameters either way
  • Test one order with delivery, tax and a discount together

Do not

  • Assume sending the parameters removes them from revenue
  • Feed order totals to ads while analytics holds product values
  • Change the definition without updating every report that uses it

Questions people ask about this

Should shipping be included in the revenue I report?

There is no single correct answer, only a consistent one. Including delivery keeps analytics close to what the customer paid, which makes reconciliation with the shop easier. Excluding it keeps revenue closer to what the business keeps, which makes return on ad spend more honest. Choose one, document it, and apply it in every platform.

Does sending the shipping parameter reduce my recorded revenue?

No. The tax and shipping parameters are reported alongside the order value, not deducted from it. If you want revenue to exclude them, your code must subtract them when calculating the value it sends. Sending the parameters is still worth doing, because it lets you analyse delivery costs against orders later without rebuilding anything.

Do these parameters relate to shipping settings in Merchant Center?

No, they are unrelated jobs that share a name. Merchant Center shipping and tax attributes control what a shopper sees beside a product listing before they buy. The ecommerce tracking parameters describe an order that has already happened. Getting one right does nothing for the other, so treat them as separate pieces of work.

Related terms

Found this useful?

Share it, or ask an AI to summarise it

Back to the glossary

Knowing the term is the easy part

Applying it to your own site and budget is the work. Book a call and I will tell you what actually applies to you.