Workflow

Spreadsheet macros vs a real fetcher: an honest comparison

Every dropshipper who can read a code snippet eventually tries it: a Google Apps Script macro that fetches tracking into the sheet. It feels clever and free. For a while, it even works. We ran the home-grown macro route for a long stretch before building a proper fetcher, so this is not a strawman — it is a post-mortem.

Here is the honest tally. Macros win on exactly one axis, and a real fetcher wins on the rest. Whether that trade is worth it depends entirely on how many orders you push through it.

Where macros genuinely win

Credit where it's due. A spreadsheet macro has real advantages, especially at the start:

• Zero subscription. It runs inside a sheet you already own.
• Total control. You can tweak any line of logic yourself.
• No new tool to learn. It lives where your data already lives.

If you do 20 orders a month and enjoy writing UrlFetchApp calls on a Sunday, a macro is a perfectly rational choice. The trouble starts when the order count and the API surface both grow up.

Where macros quietly fall apart

The cracks don't show on day one. They show three months in, when volume climbs and the AliExpress API stops being polite.

Execution limits

Apps Script caps how long a single run can take. Tracking calls are slow — a real-world batch hits that ceiling and dies halfway through, leaving half your rows updated and you guessing which half.

Rate limits and retries

The AliExpress Dropshipping API throws Api access frequency exceeds the limit the moment you push it. A serious fetcher needs retry-with-backoff so a momentary limit doesn't drop the order. Most hand-written macros just let the row fail silently.

The same-rows loop

Without a skip-list, your macro happily re-processes rows it already finished, burning quota on orders that were done an hour ago. We wrote a whole piece on this exact failure: where your day actually goes covers the time cost of re-doing work.

The macro doesn't fail loudly. It fails quietly — a half-finished batch here, a missed refund there — and you only find out when a buyer opens a case.

The fields a macro almost never gets right

Even a working macro tends to fetch the easy stuff and skip the stuff that actually protects you. The hard parts are:

1. Real net earnings. Pulling gross prices from the Order API and subtracting a guessed fee is wrong. The eBay Finances API gives you the number that actually hit your payout. Most macros never bother.
2. Carrier resolution. AliExpress's carrier_name is unreliable. You have to resolve the real courier — Evri, Yodel, Royal Mail — from the tracking-ID prefix. That's a lookup table most people never build.
3. Refund detection. Catching a delivered-then-refunded order means checking issue_status, the gmt_refund_* fields, and child orders together. One field is never enough.

What a real fetcher buys you

A purpose-built fetcher like Fetch Order Tracking isn't magic — it's just all the edge cases handled once, properly, so you never re-discover them at 2am. It syncs straight into the same Google Sheet you already use, so you don't trade your familiar workflow for someone else's dashboard. What you get on top:

• Batch processing with auto-chaining — roughly 25 orders per click, a small delay between calls, and a skip-list so a run finishes in one pass instead of looping forever.
• Real refund detection across all the fields that matter, not just the obvious one.
• Correct carrier mapping from the tracking prefix.
• True net earnings from the Finances API.
• Multi-store and multi-region — run eBay UK, US, and AU from one workspace.

So which should you use?

Be honest about your stage. Tiny volume and you like tinkering? Keep the macro. But the moment tracking becomes a chore you dread, or a buyer case catches you off guard, the macro has already cost you more than a subscription would have — in defects, missed refunds, and your weekends.

Fetch Order Tracking runs on simple monthly plans with no per-order fees, so it scales with you instead of punishing growth. If you've outgrown the macro phase, point Fetch Order Tracking at your sheet and let the edge cases be someone else's problem. For the pure ROI argument, see why tracking automation pays for itself.

Frequently asked questions

Is a Google Apps Script macro ever the right choice for AE tracking?

Yes, at very low volume. If you do around 20 orders a month and enjoy writing UrlFetchApp calls, a macro costs nothing extra and gives you total control over the logic. The trouble starts when both the order count and the API surface grow up, because that is when execution limits and rate limits begin to bite.

Why do spreadsheet macros break as order volume grows?

Three reasons usually stack up. Apps Script caps how long a single run can take, so a large tracking batch hits the ceiling and dies halfway through. The AliExpress Dropshipping API returns frequency-limit errors that a macro rarely retries with backoff. And without a skip-list, the macro re-processes rows it already finished, burning quota and looping forever.

What does a real fetcher do that my macro probably does not?

It handles the fields that actually protect you. That means pulling true net earnings from the eBay Finances API instead of subtracting a guessed fee, resolving the real carrier from the tracking-ID prefix because carrier_name is unreliable, and detecting refunds across the issue status, refund timestamps, and child orders together. Fetch Order Tracking does all three and syncs into the same Google Sheet you already use.

Related guides

• Why tracking automation pays for itself in the first week
• Why your auto-update keeps looping on the same 25 rows
• A practical guide to AE rate-limit retry-with-backoff

---