Google Sheets

Using Google Sheets as your dropshipping order database

Key takeaways

  • A Google Sheet is a genuinely good dropshipping order database well into the thousands of orders, as long as you treat it with a little discipline.
  • Rule one is one row per order and one fact per column, so automation can write to one cell without disturbing another.
  • Keep tracking statuses to a small, controlled vocabulary; a column with thirty possible values is decoration, not data.
  • Design for the machine: watch out for strict data validation that silently rejects writes, and lock your column positions.
  • Fetch Order Tracking keeps your own sheet as the database and fills the full row per order, including a carrier resolved from the tracking-ID prefix.

Every few months someone tells dropshippers they have "outgrown" spreadsheets and need a real database or a heavyweight ERP. For most eBay × AliExpress sellers, that is bad advice. A Google Sheet is fast to set up, free, shareable, readable by a human at a glance, and — crucially — easy for automation to write into. Treated with a little discipline, it is a genuinely good order database well into the thousands of orders.

The catch is in those words: treated with a little discipline. A sloppy sheet rots fast. A well-designed one scales surprisingly far. Here are the rules that keep it fast, clean, and automation-friendly.

Why Sheets is the right tool, not a compromise

The reason Sheets works is that an order list is not a complex relational problem. It is a flat list of rows where each row is one order and each column is one fact about that order. That is the exact shape a spreadsheet is best at. You also get things a custom database makes you build from scratch:

  • Instant filtering and sorting to find every "Awaiting Dispatch" order in two seconds.
  • Sharing with a partner or VA without provisioning accounts.
  • A familiar interface nobody needs training on.
  • An open surface that any tool with the Sheets API can read and write.

The real question is not "spreadsheet or database" — it is "is your spreadsheet structured like a database, or like a scratchpad?"

Rule 1: One row per order, one fact per column

This is the rule everything else depends on. Resist the urge to cram two pieces of information into one cell ("Evri — delivered 12th"). Split them. You want discrete columns for the things you will filter, sort, and automate on:

  • tracking_id and a separate carrier column
  • tracking_status as a clean, controlled value
  • estimated_delivery_date (EDD) as a real date, not free text
  • ae_order_amount and a refund_state
  • a delivery_proof link and the ae_order_date

When each fact lives in its own column, you can answer real questions instantly — "which orders are past their EDD and still not delivered?" — and automation can write to one cell without disturbing another.

Rule 2: Make statuses a small, controlled vocabulary

AliExpress will throw a dozen different status strings at you. If you let all of them into your sheet raw, your tracking_status column becomes unfilterable noise. Map them down to a short list your eyes and your formulas can rely on — something like Awaiting Dispatch, Shipped, Delivered, Refunded/Cancelled. The mapping logic is where a lot of the real work lives; for the nuance behind it, see seven tracking statuses that should map to Shipped in your sheet.

A status column is only useful if it has a small, predictable set of values. The moment it has thirty, it is just decoration.

Rule 3: Design for the machine that writes to it

If a tool is going to populate your sheet automatically, you have to think about how writes behave. Two things bite people constantly:

  • Data validation that silently rejects writes. A strict dropdown on a column will block an automated write that does not match an allowed value, and your automation will look broken when the data is fine. We cover the gotchas in five Google Sheets data-validation traps for tracking columns.
  • Stable column positions. Automation usually writes by column header or position. Reordering columns by hand mid-season is how you end up with carriers in the EDD column.

Pick a layout once, lock it in, and let it stabilise. If you want a layout proven to survive growth, a spreadsheet column layout that scales from 100 to 10,000 orders is the blueprint.

Rule 4: Keep finished orders out of your working set

A database does not re-process completed records, and neither should you. Delivered, cancelled, and refunded orders are terminal — they are done. If your daily routine keeps re-checking them, your working set grows forever and every sync gets slower. Move terminal rows out of the active queue (a separate tab, or a skip-list the automation respects) so you only ever touch orders that can still change.

Where Fetch Order Tracking fits

All of these rules describe a sheet that a tool can keep current without a human in the loop — and that is exactly what Fetch Order Tracking does. It keeps your own Google Sheet as the database, connects eBay and the AliExpress Dropshipping API, and writes the full row per order: tracking ID, carrier, status, EDD, AE order amount, refund state, a delivery-proof link, and the AE order date. It resolves the real courier from the tracking-ID prefix instead of trusting AliExpress's carrier_name, checks several fields together to catch delivered-then-refunded orders, and uses a built-in skip-list so terminal rows stop getting re-fetched.

You do not give up your spreadsheet. You keep the tool you already understand — Fetch Order Tracking just turns it into a database that fills itself in. Lay the columns out cleanly, control your statuses, respect your validation, retire your terminal rows, and a humble Google Sheet will quietly run an operation far bigger than people expect.

Frequently asked questions

Is Google Sheets really good enough to run a dropshipping order database?

For most eBay and AliExpress sellers, yes. An order list is a flat set of rows where each row is one order and each column is one fact, which is exactly what a spreadsheet is best at. You get instant filtering and sorting, easy sharing with a partner or VA, a familiar interface, and an open surface any tool with the Sheets API can read and write. Treated with discipline, it scales well into the thousands of orders before a heavier database earns its keep.

How should I structure tracking columns so automation does not break?

Use one row per order and one fact per column: keep tracking_id and carrier separate, make estimated_delivery_date a real date rather than free text, and keep tracking_status to a small controlled vocabulary. Avoid strict dropdown validation that silently rejects an automated write, and lock your column positions so a tool writing by header or position does not put carriers in the EDD column. Pick the layout once and let it stabilise.

How do I stop my sheet from getting slower as orders pile up?

Keep finished orders out of your working set. Delivered, cancelled, and refunded orders are terminal, so re-checking them every day only grows your queue and slows every sync. Move terminal rows out of the active queue with a separate tab or a skip-list, so you only touch orders that can still change. Fetch Order Tracking does this for you with a built-in skip-list that stops terminal rows from being re-fetched.

Related guides


Try Fetch Order Tracking More guides