Purchase value after discount codes: send net revenue or the full order total?

If a store runs 20% off codes on a lot of orders and the purchase tag sends the full pre-discount total, Smart Bidding treats those sales as worth more than the cash that actually comes in. tROAS targets drift and bids get too aggressive. Sending the discounted total fixes that, because the numbers match what the business receives, though discounted sales will show a worse ROAS than full-price ones.

I'd send net value, after discounts but before shipping and tax. That way Google Ads matches what you keep and what your margin reports show. The tradeoff is that the weekly ROAS in the UI will look lower, which can spook people who haven't been told why. Has anyone changed the value rule for discounted orders, and did it change how the bidding behaved?

Agreed on net value. What people usually miss is that switching the value rule changes your baseline, so the tROAS target has to move with it. If discounts average 20%, net value is about 80% of gross, so a 400% target on gross becomes roughly 320% on net and you end up with the same bids. For the discount figure, use the actual average ratio from the last 30 days of orders rather than the code's headline percentage, because plenty of orders don't use a code at all.

Don't change the value rule and the tROAS target in the same week. Bidding needs a couple of weeks to settle on the new value scale, and if you move both at once you can't tell which change caused a swing.

A good rule of thumb is to recalculate the discount ratio monthly. If it moves more than about 5 points, say a sale month pushing it from 15% to 30%, either adjust the target again or send promo orders to a separate conversion action. That way a temporary sale doesn't drag your normal target around.

Monthly check makes sense, but I'd calculate the ratio differently. Take total net revenue divided by total gross revenue for the month instead of averaging each order's discount percentage. A simple average gets dragged around by a few large orders, while the revenue-weighted number reflects what the target is actually paying for.

Also, if there are only a handful of promo orders in the month, a 5-point swing could just be noise. Wait for a decent sample before you move anything.

Waiting for a big sample doesn't hold up for me. A sale month is exactly when your target is most wrong, so holding off just means bidding keeps running on the wrong scale for weeks. If a handful of promo orders are skewing things, split them into their own conversion action now rather than freezing the whole target.

Agreed on splitting now. The catch is that a new conversion action only records from the day it's created, so your existing promo history stays in the main action and keeps skewing the target until it ages out. Check the tag too. If promo orders fire the same event with the same value, the new action stays empty. Give promo orders their own event name, or a parameter the tag can key on, so the split actually separates them.

If you split promo orders into their own action, check that the main action still gets the full set of orders. Otherwise the default conversion will undercount everything that's on a discount code. Google counts each conversion action separately, so a promo order can feed the promo action and still count in the main one.

The include-in-conversions setting is what catches most people. If the promo action is also set to count toward Conversions, Smart Bidding adds up every included action, so a promo order gets valued twice and your tROAS target ends up working off inflated numbers. Setting the promo action to secondary keeps it in reporting while bidding only sees the main action. Which action is your tROAS goal pointed at right now?

Secondary alone doesn't really keep bidding clean, because a secondary action never feeds Smart Bidding. If promo orders only land in that action, the tROAS target trains on full-price buyers and drifts the other way. The main action needs every order at net value, and the secondary one should only exist for reporting.