I put my own brand's Amazon Ads through AdsPlane — the real ledger, including the failure

I'm Jitendra. I own WOODFRESS, a cold-pressed oils brand on Amazon.in, and I built AdsPlane. WOODFRESS is the account AdsPlane has run longest, so it's also the account I can be most honest about. This isn't a customer testimonial I can dress up — it's my own ledger, and I have to live with what's in it.

So this is the honest version. Real figures from the database, the rough months left in, and the section most case studies would delete: the day a guardrail I set wrong cut my live keyword coverage in half.

If you run PPC yourself, you already know which numbers can be massaged. I've left those alone.

At a glance (Dec 28, 2025 → May 29, 2026, ~5 months)

WOODFRESS is my own brand, so I'm withholding its absolute spend and revenue — I'm not going to publish my own account's scale. Everything below is ratios, counts, and the relative shape of the curve. None of it is dressed up.

Attribution note: SP uses Amazon's 7-day click-date window; SB and SD use the 14-day window. The blended figure mixes the two because that's how Amazon reports them — I'm not going to pretend they're the same window. (TACOS — total ad spend ÷ total revenue — would require publishing revenue, so it's out by the same rule.)

This is a mid-size brand, not an enterprise account. The point of this study isn't the size of the spend — it's what controlled, auditable optimization looks like on a real account, and what happens when one setting is wrong.

1. The setup: why I automated my own account

WOODFRESS went live on Amazon.in in September 2019 with two SKUs and one question I asked every morning: how do I get these in front of the most buyers? The answer was Amazon Ads, and within two weeks I'd fallen into the routine that ran my mornings for the next six years — log in to Seller Central, open the Ads Console, check campaign status, open a dozen windows, compare time periods, adjust bids, adjust budgets, read the search terms, decide what to push, what to cut, and what had quietly started wasting money.

Every two or three weeks that became a three-to-four-hour overhaul. Every two or three months, a harder structural refresh just to stay alive in a crowded category. I tried PPC tools. I tried agencies. I tried outside help. The core pain didn't move: almost every morning, I had to do it myself.

The work was repeatable and deterministic — exactly the kind a machine should own. But done by hand it could be skipped, delayed, rushed, or done unevenly depending on factory work, family, or plain fatigue. Some weeks I did it well and the account behaved for a month; then it flattened and I'd do it again. Nothing dramatic — just the quiet tax of inconsistency: spend drifting where it shouldn't, opportunities missed because nobody caught them in time. One person cannot read, correct, and react to a growing ads account with machine-like consistency every single day while also running sourcing, operations, inventory, pricing, and dispatch.

So in early 2026 I built the engine that became AdsPlane — not because I wanted "AI magic," but because the morning job was deterministic and I wanted it done the same way every day, written down, and reversible. Every change explainable, every change logged, nothing live I hadn't seen. The destination was a single switch: the account read, the decisions made, and the day's ads work done before I'd finished my coffee. That requirement — control kept where it matters — is the whole reason AdsPlane looks the way it does, and it's why this study can show you the failure as clearly as the wins.

2. How the engine runs the account

AdsPlane runs a daily loop — the Runbook:

Pull → Analyze → Manifest → Approve → Execute → Reconcile → QC

In plain terms:

• Pull — fetch the SP / SB / SD reports (campaigns, keywords, search terms, placements) and AMC path-to-conversion data.
• Analyze — a deterministic engine scores every campaign, keyword and search term and emits candidate actions (bid changes, negatives, pauses, search-term harvests) with a confidence score and a written rationale. AI never decides anything here; it only narrates the result in plain English.
• Manifest — the candidates are validated against a versioned Guardrail Policy, clamped, ranked, and written into a structured action plan. Pauses get split into their own Manifest so they can be approved separately.
• Approve — I review the Manifest (web or Telegram) and approve, partially approve, reject, or ask for a dry run. Nothing executes without this gate.
• Execute — approved actions go live, with before/after snapshots written to the Execution Ledger.
• Reconcile — the engine checks that what it intended actually happened, and flags drift. If a run was dirty, the next run knows.
• QC — a daily report: action counts, guardrail blocks, results, reconciliation status.

New accounts — including mine, at the start — run in Shadow Mode: the full loop runs and produces a Manifest, but nothing goes live until you opt in. That matters for the honesty of this study: for most of these months, WOODFRESS ran the daily Runbook as advisory and only switched specific lanes (intraday Rally-Control, ML auto-bidding) to live execution after I trusted them. More on that in §3.

A real Manifest action

Here's an actual live intraday move from the ledger, with the campaign name generalized:

action_type:   sp_keyword_bid_change
entity:        a mustard-oil exact-match keyword  (campaign name withheld)
match_type:    EXACT
bid_change:    +14.0%  (raised to the guardrail ceiling; absolute bid withheld)
lane:          Rally-Control (intraday)
guardrail:     passed — within the +14% intraday increase cap
rationale:     intraday conversion strength on a proven keyword; raise bid to
               proven ceiling, capped at the guardrail.

Note the +14.0%. That cap is not decoration — it's the reason this account survived its worst week. §4.

3. The results, honestly — including the rough months

Here is the SP efficiency curve, month by month. I'm showing SP on its own because it's the full window and the cleanest comparison.

Spend and sales are indexed to January 2026 = 100 (absolute figures withheld); orders and ACOS are actual.

First, an honest timeline: this is my account's data window, not five months of full autopilot. The engine's recommendation log begins March 29 and live intraday execution begins April 14. So read Dec–Feb as the manual-era baseline the engine measured against, March as the transition, and April–May as the engine operating with live, approval-gated lanes — including the April mistake. I'm not crediting the engine for the good early months.

I'm not going to tell you ACOS dropped. It didn't. It went the other way into April and May. Here's the honest read of that curve:

• Dec (18.4%) is four days of a low-spend ramp — ignore it as a baseline.
• Feb–Mar is the account in good shape through the transition: ~32–37% ACOS while monthly spend scaled up ~60% (Feb → Mar) — see the index jump 81 → 130.
• April is the failure month. ACOS jumped to 52% — and that's not noise, it's the incident in §4.
• May (56%) is partly real deterioration and partly an artifact: this study was pulled on May 29, and Amazon attributes orders to click date over a 7–14 day window. The last ~2 weeks of May orders were still maturing when I pulled. May's ACOS will settle lower than 56% as attribution completes — but I'm reporting it as it stands, not as I'd like it to land.

SB and SD ran at higher ACOS (74.7% and 52.6% blended) — Sponsored Brands and Display do upper-funnel work, and I run them knowing that. They're in the blended table above; I'm not hiding them to flatter the headline.

What the engine actually did

Over the window, on the WOODFRESS account:

• 8,514 campaign-level recommendations logged to the recommendation ledger (Mar 29 – May 29).
• 51,555 intraday evaluations by Rally-Control (the intraday lane, live from Apr 14) → 2,140 live bid moves (2,023 increases, 117 decreases).
• 241 live ML auto-bidding mutations — out of ~12,000 evaluated. The rest stayed in dry-run / manual-approval. The engine proposes far more than it executes, on purpose.
• 380 search-term harvest candidates + 267 new-campaign recommendations from the Growth Engine.

That ratio — thousands evaluated, hundreds executed — is the product working as designed. It's not aggressive. It's supposed to not be.

4. The failure: the day my keyword coverage halved

This is the part I'd delete if I were selling you something.

In early April, WOODFRESS's live SP keyword coverage collapsed. Here's the daily count of keywords actually serving impressions:

Overnight, on April 9, live keyword breadth roughly halved and stayed there. And here's the part that makes it dangerous rather than obvious:

• Daily spend rose ~82% (Apr 1–8 average vs Apr 9–30 average).
• Impressions rose — from ~17,400/day to ~27,200/day.

So nothing looked "broken" on a dashboard. Spend was up, impressions were up. What had actually happened was that a decrease guardrail I'd set too aggressively pulled bids down hard across a wide set of keywords, dropped them out of contention, and concentrated the budget onto a narrower set — which then spent more, less efficiently. ACOS went from the mid-30s to 52% that month. This was my configuration error. Not a bug, not Amazon — a number I set wrong.

The reason I caught it is the reason the product exists. The engine instruments exactly this: active-keyword breadth, the recommendation ledger, and reconciliation. A halving of live coverage with rising spend is precisely the shape the instrumentation is built to surface — not a number you'd notice by feel while spend and impressions are both green.

The fix was to size the decrease guardrails conservatively. You can see the result in the live ledger today — every intraday move on this account is now bounded:

• Increases capped at +14% (and they average +4.8% — most moves are small).
• Decreases bounded — the mild-decrease lane averages −15%, and the hardest cut the engine will make live caps at −25%.

No single move can do what April did again. A bid can't fall off a cliff in one run; the worst case is a bounded, reversible step that reconciliation will flag.

The lesson isn't "automation is risky." It's narrower and more useful: guardrail sizing is existential, and the approval gate plus conservative caps are the product — not a feature bolted on top. An optimizer with no clamp on how far one action can move is a faster way to make my April mistake, not a safer one.

I learned that the hard way — and, honestly, I was glad about it. The tool did exactly what I told it to. The wrong call was mine: the human setting the guardrail, not the engine executing it. That's the right place for a mistake to live, because it's the place I can see and fix.

5. What this proves — and who it's actually for

What ~5 months of my own ledger shows:

• The engine ran a real account across SP/SB/SD, deterministically, with every action explainable and logged.
• It held efficiency in the low-to-mid 30s% when conditions were normal, and it scaled spend without losing the thread.
• When I broke it, the instrumentation caught the break, and the guardrails were rebuilt so one setting can't do that again.

That last point is the one I'd weigh most if I were you. Any tool can show you a good month. The question is what it does on a bad one, and whether you can see and reverse what it did.

This fits you if you're an established seller who wants the daily PPC grind done the same way every day, written down, and gated behind your approval — and you'd rather start in Shadow Mode and watch it before anything goes live.

It doesn't fit you if you want a hands-off tool that promises to cut your ACOS by some headline percentage while you don't look. I can't sell you that honestly, and this case study is the reason why.

6. See it on your own account

Start in Shadow Mode, free. AdsPlane pulls your reports, runs the full Runbook, and shows you the Manifest it would execute — every recommendation, every confidence score, every guardrail check — with nothing going live. You watch it work on your real account before you trust it with a single bid.

Or run the Scorecard first to see where your account stands.

No card, no urgency, no headline ACOS promise. Look at the Manifest and decide for yourself.

How these numbers were produced

For the skeptics, which is the point:

• Source: every figure is pulled read-only from the WOODFRESS production database, last data point May 29, 2026. None are hand-entered.
• Window: Dec 28, 2025 – May 29, 2026. SP covers the full window; SB/SD begin late January; live intraday execution begins April 14.
• Money: absolute spend and revenue are withheld — this is my own brand. Figures are published only as ratios (ACOS, ROAS, share-of-mix), counts (impressions, clicks, orders, actions), or indices (monthly spend/sales indexed to Jan 2026 = 100). TACOS is omitted because it would require publishing revenue.
• Attribution: Amazon click-date attribution. SP = 7-day window; SB/SD = 14-day window (Amazon hard-codes the window in the report columns). The last ~3–5 days of any pull are still maturing, so recent figures (especially late May) will settle lower.
• Also withheld for competitive reasons: exact campaign names (generalized) and per-product margins. Marked inline where blurred.

Numbers honest. Failure included. That's the whole pitch.