← All posts AI & automation

AI agent that catches discount codes eating your margin

9 Sep 2026 · 5 min read · Twinslytics
AI Agent Pipeline for Discount Cannibalization01Join DataSourcesorders+customer+code02Build Baselinewould-be full price03Compute MarginDeltareal cost vs revenue04Detect Anomaliesleaks, stacking, …
A sample pipeline showing how raw order data becomes a real-time margin-leak alert.

A discount code that "drove $50k in revenue" sounds like a win until you check what it actually cost you. Most of that revenue might have converted at full price anyway. Some of it might be going to customers who were never supposed to see the code in the first place. And none of your dashboards are built to tell the difference, because they stop at revenue attributed to the code and never touch the margin that code quietly ate. This is discount-code cannibalization, and it's one of the most common ways ecommerce brands overstate their real profitability.

Building an AI agent to catch this isn't about replacing your promo strategy. It's about giving your team a system that watches every code in real time, compares it against what would have happened without it, and flags the ones bleeding margin before finance finds out three months later during a P&L review.

Why discount tracking lies to you

Standard reporting treats every order with a code as incremental revenue the code "caused." That's rarely true. A repeat customer who buys from you every month doesn't need 15% off to convert — they were coming back regardless. When they use a code, you're not gaining a sale, you're giving away margin on a sale you already had.

None of this shows up if you're only measuring revenue attributed to a code. You need to measure margin lost relative to a baseline of what would have happened anyway.

What the agent needs to watch

An agent that can actually catch cannibalization needs access to more than the coupon table. It needs a joined view across several data sources, updated close to real time:

This is a data engineering problem before it's an AI problem. If your COGS numbers are stale, or your customer table doesn't reliably flag repeat buyers, the agent will flag noise instead of real leaks. Get the joins right first — orders to customers to product costs to code logs — before you build any logic on top.

Building the flagging logic

Once the data is joined, the agent runs a handful of concrete rules instead of a vague "watch for weirdness" model. Specificity is what makes this useful.

The cohort comparison is the piece most teams skip, and it's the one that actually answers the real question: would this customer have bought anyway? Without it, you're guessing. With it, you get a defensible number for how much of the discount was genuinely necessary to close the sale.

From flag to action

The agent's job is not to auto-kill codes. Promo strategy involves tradeoffs a rules engine shouldn't make alone — a leaking influencer code might still be worth keeping if it's bringing in enough new customers to offset the margin hit. The agent's job is to surface the decision with the numbers attached, not to make the call.

That last point matters more than people expect. Teams get nervous about killing a "high revenue" code even when it's cannibalizing margin, because the top-line number looks scary in isolation. Tracking what actually happens after you restrict a leaking code builds the internal case for trusting the agent's flags next time.

The pipeline underneath the agent

None of this works off a spreadsheet pull once a month. You need a pipeline that keeps COGS current as suppliers change pricing, keeps customer identity resolved across channels so "repeat customer" actually means something, and ingests code usage logs fast enough to catch a leak within hours instead of after the code has already been posted everywhere. The agent is a thin layer of logic sitting on top of that pipeline — it's only as sharp as the data feeding it.

If you're already running a warehouse with clean order, customer, and cost tables, adding this agent is mostly a matter of writing the join logic and the threshold rules. If you're not, building the agent forces you to fix the underlying data gaps you were probably going to need to fix anyway.

Discount codes aren't the enemy. Blind spots in margin tracking are. An agent that flags cannibalization doesn't tell you to stop discounting — it tells you which discounts are actually buying you something and which ones are just quietly taxing sales you already had. That's the difference between a promo calendar built on guesses and one built on real numbers.

Further reading

283/408 sessions reattributed — Fixed attribution, returned conversions to Google Ads

Want your attribution reconciled like this?

We patch the join between clicks and closed revenue so bidding optimizes on what actually happened, not what the checkout referrer claims.