← Back to all thoughts

Day 26 · I Almost Misdiagnosed a Client Twice

Update · 2026-04-20 evening · Day 26’s Third Slap

Hours after publishing, while updating the client’s monthly-performance tab, I discovered the dashboard has been using a 6.8921 CNY/USD internal management rate — not the 7.2 market rate I used in this post. After aligning: ROAS 3.41 → 3.56; distortion multiplier 15.9× → 2.3×.

“Off by 15.9×” was the most dramatic number in my narrative. But it was actually a v1-era calculation I carelessly reused in v3 (v1 treated ¥9,669 as $9,669, producing 9669/609 = 15.9×; v3 corrected ROAS but forgot to recompute distortion). The correct formula: real USD / Google Ads' USD = 1403/609 = 2.3×.

2.3× lacks 15.9בs shock value, but still exceeds the 1.5× threshold, so the three-question check + three-source cross-validation methodology holds unchanged — only the core numbers need replacing. I’ve edited 3.41 and 15.9× inline to 3.56 and 2.3× throughout the post; this callout stays as the third-slap record.

Lesson upgrade: When iterating versions, every number must be recomputed from source. Never copy from the previous version. This rule is now in my Claude collaboration memory.

Today is Day 26.

I ran a Google Ads deep audit for a shopping-agent client — 74 checks, 2,040 API calls, two structured reports.

I wrote the conclusion three times.

First: the account is losing money, ROAS just 1.22. Stop adding budget, stop the bleeding.

Second: the account is crushing it, ROAS of 17.97. A rare scale opportunity — 5× the budget immediately.

Third: the account is healthy but not exceptional, ROAS 3.56, sitting right on the e-commerce benchmark of 3.68. Fix the data pipeline first, then slowly scale.

The gap between my three conclusions was 14.7×.

The client only said two things during the whole back-and-forth. First: “This is our real transaction data.” Second: “Note that the amounts in the spreadsheet are in Chinese Yuan; the Google Ads spend is in US Dollars.”

That’s this post. A complete log with the mistakes, the data, and how the client slapped me awake twice with a single sentence each time. Written for anyone making decisions off cross-system data — because you might be wrong right now too.


Three conclusions side by side

VersionData sourceROASRecommendationWhat I missed
v1Google Ads API all_conversions_value1.22Losing money, stop adding budgetTrusted the dashboard blindly
v2Client’s Metabase GMV treated as USD17.97Rare scale opportunity, 5× budgetNever checked currency unit
v3 (correct)Metabase GMV ÷ 6.8921 (management rate USD)3.56Sitting on benchmark, fix data first

If I’d sent v1 or v2, here’s what would have happened:

  • Sending v1: Client pauses an account that’s actually making money. I personally kill ~$1,800/month in real revenue.
  • Sending v2: Client scales budget from $540/month to $2,700/month. Real ROAS can’t hold 17×, and we burn a full quarter.

Either mistake ends a partnership.


The blow-by-blow of how I got to v3

Beat 1 · v1: Trusting the dashboard blindly

Task: run a “partner-level deep diagnosis” on the client’s Google Ads account. I pulled the API and got these numbers for the last 30 days:

Pmax primary campaign:
  Spend       $499.88
  Clicks      2,040
  "Conversions"  40
  Google Ads "transaction value"  $609.27

$609.27 / $499.88 = 1.22

I immediately wrote the conclusion: “Real ROAS is 1.22. The account is in the red. Do not scale budget. Stop the bleeding first.”

Then I backed it up with a 74-point Google Ads audit checklist:

  • Measurement target is wrong (the system is optimizing for “signup,” not “purchase”)
  • PMax has only one asset group (structurally fragile)
  • Geo targeting is PRESENCE_OR_INTEREST (G11 FAIL)
  • Brand keyword impression share: 86% lost to rank (competitors bidding on your brand)

Every check pointed toward “this account is fragile.” ROAS 1.22 fit these structural problems perfectly. I even added this line:

“The ‘account healthy’ signal you see is an illusion.”

Peak confidence.

Beat 2 · Client sends one message and I flip to the opposite

Client read it and said: “I’ll send you the real transactions from the whole channel. I just exported detailed data from Metabase.”

Then sent an Excel file.

I parsed it — 1,837 rows, 28 columns, per-user-per-day detail on orders placed, GMV paid, revenue, total revenue. Past 30 days across the entire SEM channel (= paid traffic from Google Ads):

Paid GMV:      9,669
Total revenue: 13,197

Google Ads saw $609. The client’s system recorded $9,669.

I immediately divided $9,669 by the $538 spend and got a ROAS of 17.97.

Then I flipped and wrote v2:

“I was wrong. ROAS is not 1.22. It’s 17.97. The account is 5× above the benchmark of 3.68. This is a rare scale opportunity — add 5× the budget immediately.”

Almost hit send.

Beat 3 · Client sends one more message and I flip back

Client replied: “Note that the amounts in my spreadsheet are Chinese Yuan. Google Ads spend is US Dollars.”

Exchange rate (client’s internal management rate, fixed at 6.8921).

¥9,669 ÷ 6.8921 = $1,403 ¥13,197 ÷ 6.8921 = $1,915

Real ROAS:

  • By paid GMV: $1,403 / $538 = 2.61
  • By total revenue: $1,915 / $538 = 3.56

E-commerce benchmark is 3.68. We’re at 3.56. Sitting on the line. Not breaking through.

The account isn’t a leaky car (v1 wrong). It isn’t a Ferrari with the pedal un-pressed (v2 wrong). It’s a commuter car sitting on the line — engine is healthy, it runs, but the dashboard can’t see the real speed.

I flipped again. v3.


Why did Google Ads see $609 when the truth is $1,403?

Finding the real ROAS was one thing. But this hid a bigger problem.

The client’s Google Ads system received only $609 in transaction value over the last 30 days. The business backend shows the real paid GMV was $1,403 (USD).

Signal distortion: 2.3× — Google Ads captured only 43% of the real value; 57% of the value signal is simply missing.

In plain English: the ad system has been making bidding decisions with a value signal that’s off by more than half.

Three likely root causes:

  1. The purchase event’s value field isn’t passing actual order amount (might be passing order ID or a static $1)
  2. The purchase event fires on an early funnel page, not on actual payment success
  3. Currency mismatch (but that would inflate the number, not deflate it, so this is ruled out)

What needs fixing is not bidding strategy or budget ratio — it’s the GTM tag on the website. That’s a front-end / engineering fix, not a Google Ads UI change.

My 74-point checklist caught “Measurement target wrong,” but it couldn’t catch “value capture missing 57%.” That required cross-validation against the business backend to surface. 2.3× may sound unremarkable, but for a MAX_CONVERSION_VALUE bidding strategy that allocates traffic by value signal, even a 2× gap flips decisions to the opposite direction — the system funnels spend into segments where “Ads-visible value is high but real value is low.”


Retrospective: both mistakes had the same root cause

Why did I get v1 wrong, then v2 wrong too?

v1’s disease: trusting the dashboard. I took Google Ads’ all_conversions_value as real GMV. Never asked “is this number aligned with the actual paid orders in the business backend?”

v2’s disease: not checking unit. The Excel header said “Order GMV / Paid GMV / Revenue” — and numbers are just numbers, right? Never asked “is this RMB or USD?”

Looks like two different mistakes. Same underlying disease: rushing to a conclusion before confirming what each number actually represents.

Every number has a default meaning, but the default isn’t always right:

  • Google Ads API’s cost field is in micros ($1 = 1,000,000)
  • Metabase “amount” columns default to the account’s bookkeeping currency — this account happens to be RMB
  • “Last 30 days” is in UTC? America/Anchorage? Asia/Shanghai? Google Ads and Metabase use different defaults

Every number has unit, window, definition context. Skip any of the three and you crash.


The method: three questions before any cross-system data decision

Question 1: What’s the unit?

  • Currency (CNY / USD / EUR)?
  • Percentage or decimal (0.15 vs 15)?
  • Count or deduplicated (users)?
  • Micros or dollars (always ask this for Google Ads API)?

Question 2: What’s the window?

  • Single day / last 30 days / YTD / fiscal year?
  • Timezone: UTC / America/Anchorage (Google Ads default) / Asia/Shanghai (most business backends)?
  • Attribution window (click-through lookback): 7 / 30 / 90 days?

Question 3: What’s the definition?

In e-commerce / shopping-agent businesses, these can differ by 5-10×:

  • Order GMV (user clicked “place order” but didn’t pay)
  • Paid GMV (actually transacted)
  • Order revenue (after refunds)
  • Total revenue (including shipping/service add-ons)

In Google Ads:

  • Primary conversion or all conversions?
  • include_in_conversions_metric true or false?

Each of these changes the final number.


Hard rule: three-source cross-validation, business backend wins if > 1.5× drift

For any ROAS / CPA / channel efficiency decision, cross-check 3 sources simultaneously:

  1. Ad platform side (Google Ads conversion value)
  2. Analytics side (GA4 revenue)
  3. Business backend side (Shopify / Metabase / internal order system’s paid GMV)

If the 3 numbers differ by more than 1.5×, something in the capture / pipeline is broken. When that happens:

Always trust the business backend. Only the backend sees money actually hitting your account. Everything else is a proxy indicator, and proxies drift.

My v1 was wrong because I looked at one source only. v3 was correct because I finally aligned against the business backend.


Partner-level honesty: both wrong versions are preserved in the report

The audit report I delivered to the client is titled “Day 26 Deep Audit · Partner View v3.1.” At the top, there’s a “Report Revision History” section listing four versions side by side (v3 had a currency rate mismatch; v3.1 is the actually-aligned one):

v1   → ROAS 1.22  → "losing money"   → wrong (trusted the dashboard)
v2   → ROAS 17.97 → "massive winner" → wrong (treated ¥ as $)
v3   → ROAS 3.41  → "on benchmark"   → wrong (used 7.2 market rate; dashboard uses 6.8921 management rate)
v3.1 → ROAS 3.56  → "on benchmark"   → correct (rate aligned + distortion recomputed)

I didn’t delete them because between partners, explicitly preserving your mistakes is more trustworthy than pretending they didn’t happen.

After reading it, my client said: “OK, rewrite everything into the correct version — you’re my partner, after all.”

That one sentence is worth more than any thank-you note. She’s choosing to keep trusting me to do the work after I got publicly proven wrong twice in a row.

Relationships like that aren’t built on never being wrong. They’re built on admitting it immediately, not papering over it, and coming back with a new plan.


Three takeaways

For solo operators

You’ll work with AI on tasks that exceed your technical background (I ran a 74-point Google Ads audit in two hours — the kind of work that cost $200/hour from a paid media specialist five years ago). This is a real capability extension.

But it also means you’ll make mistakes in domains you don’t deeply understand. When you see a number from an API and don’t know if it’s in micros or dollars, you’ll repeat my v1 error.

Countermeasure: before writing any strong conclusion, have AI help you run the three-question check.

For data-driven decision-makers

Dashboards are proxy indicators, not truth. Shopify / business backend is truth. If your ROAS comes from the Google Ads UI, you genuinely don’t know your real ROAS.

Countermeasure: monthly three-source cross-validation. Ad platform × analytics tool × business backend, reconcile 30 days of data. Any gap over 1.5× → investigate immediately.

For anyone doing complex work with AI

AI will give you confidently wrong conclusions. Because AI doesn’t know what AI doesn’t know.

Countermeasure: train the “three-question check” habit into your AI collaboration — unit / window / definition. The 3 seconds here save you 3 days of rework later.


The ledger

Over six days:

  • Day 1: built the site
  • Days 2-5: other work
  • Day 26 (today): deep audit for a client + wrong twice + gained one rule I won’t forget

What Day 26 cost:

  • An afternoon plus an evening
  • 5 git commits
  • Two admissions to the client that I was wrong
  • A 300-line audit report (v1 → v2 → v3, all preserved)

What Day 26 earned:

  • A methodology that speeds up AI collaboration at least 2× (three questions + three sources)
  • Field-tested proof that partners admit errors rather than rationalize them
  • Material for a blog post (this one)

The “one person” in “one person + AI = one army” lost two battles today. But after losing them, the army is stronger.


Related: Day 1 · From $60 to Lighthouse 100×4 · One-Person Ops Infrastructure Notes · Day 1 · I Bought Two Domains Today