Training Data

Essential Questions Interns Should Ask First: The Lessons From My First ELT Transformation

Đăng vào bởi Gong Elijah
The First ETL Push in a T Job: Essential Questions Interns Should Ask First

This is a reflection written about my first ETL push to production after my second T project. The honest version. It is a reflection about what I would have wanted to know looking back at that point of time and a record of the things that slowed everything down, the assumptions that turned out to be wrong, and what knowledge would have been useful for a new intern before your first push.

Understanding The Problem Comes First

When I got my first data ticket at Vatico, I assumed the hard part would be the code. It wasn’t. The hard part was understanding the business well enough to know what I was actually being asked to measure — and that took far longer than writing any query.

Looking back, almost every delay I experienced in the first two weeks came from the same root cause: I didn’t understand the business flows behind the data I was touching. I was querying tables I didn’t fully understand, mapping statuses I hadn’t verified, and building logic on top of assumptions I hadn’t confirmed. The code was fine. The foundation wasn’t.

The cost of misunderstanding scope

The same problem arose even in my second ticket. Imagine being asked to measure courier success rate. While it sounds simple, it can mean three completely different things depending on where the bottleneck lies:

• Warehouse handoff: Did the warehouse successfully hand the package to the courier? (If they failed, it’s a warehouse problem, not the courier’s fault).

• Courier delivery: Did the courier successfully deliver the package to the customer? (If they failed, it’s a courier performance problem).

• System operations: Did Vatico’s servers successfully sync the order details to both the warehouse and the courier? (If they failed, it’s an operations/IT pipeline problem).

Build around the wrong one, and you will spend three days on a ticket that should take one morning. Not because you wrote bad code — because you answered the wrong question.

That distinction alone — understanding which handoff in the order-to-delivery chain you are measuring — is worth more than any SQL optimisation you could learn in your first week.

Recommended Training Material:

Before opening a ticket, review “How to approach a task in a Data Sprint”, “Intentionality — less is more”, and the reference example inside the Data Analytics Training Slides. These materials will equip you with the expectations from your supervisor and the skills to produce intentional work.

The Business Flows You Need to Know First

Use the Vatico bot for table discovery, but don’t rely on it for business logic. The bot tells you what tables exist, not why the business operates the way it does. Read our internal blog posts thoroughly and clarify context directly with your supervisor before opening a ticket.

Why this matters: The bot knows schema structure, not operational and business flow context. Relying on it for business rules leads to querying technically valid tables to answer the wrong questions — wasting days building logic on false assumptions.

Master these core business flows first — missing this context is what causes most early project delays:

01
The order-to-delivery flow
How does a customer’s purchase move from placement on WooCommerce through to final delivery? Know the stages, know what triggers each transition, and know where in the chain each failure type belongs. Without this, you won’t know which tables to query or how to define “success.”
02
Prepaid vs COD — the delivery difference
Prepaid and cash-on-delivery orders behave differently in the fulfilment flow. The difference matters because they have different expected delivery times to meet. Know how each payment type is defined in the dbt models ( what strings they look for in payment_method_title) before you build any logic that segments by payment method.
03
VAT invoice constraints
VAT invoices are tied to the same day as the delivery date. Meaning if a VAT invoice is made at 2359, it must be done by 2359 – it is different from 24 hours. This is not obvious from the data alone, and if you’re building any time-based analysis that touches invoices, not knowing this constraint will break your logic.
04
SLA for order tracking
Know what Vatico’s internal SLA is for tracking orders. If you encounter delays or missing statuses in the data, you need to know whether they represent genuine failures or expected SLA windows — otherwise you’ll flag non-issues or miss real ones.
05
The data pipeline — how dbt fits in
dbt models handle transformation in the pipeline. Know the difference between report tables, staging models, fulfillment tables, and sales tables (insight, KPI, orders, fulfilment). Querying the wrong layer is one of the most common early mistakes — and it produces numbers that look correct but aren’t.

Here are some links to get you started on the business flows, business constraints, SLAs (Service Level Agreements) and processes that VATICO does.

Take a look at the CRM in your free time: we looked at orders to see how orders were processed.

The rule of thumb: if you cannot explain the business flow behind the metric you’re building in plain English to a non-technical person, you are not ready to write the query yet. The code comes last.

Status Values: The Hidden Complexity

A status column isn’t just a string — it’s a business rule encoded as text. Assuming what it means without verification leads to logic that is confidently wrong.

Here are the status questions I wish I had asked in week one:

01
What do failed, cancelled, on-hold, processing, and completed actually mean?
These are WooCommerce order statuses. “Cancelled” does not always mean what you think it means in a commerce context. “On-hold” has a specific trigger. Verify each one against the dbt model code, not against your intuition.
02
What does the warehouse mean by ready_to_pick, RT_SHIP, returned, and delivered?
These are not the same even between courier statuses or WooCommerce statuses, always validate to find out what they mean by looking at the data.
03
How are prepaid and COD orders defined in the dbt code?
Don’t rely on the column name alone. Find the model that creates the payment type classification and read the logic directly. The conditions may include edge cases — partial payments, failed COD attempts — that the column name doesn’t hint at.
04
When is a woo_id created, and does it survive cancellation?
WooCommerce order IDs persist even after cancellation. This means a customer can appear to have multiple active orders when they actually have one current and several historical. If you’re doing customer-level analysis, this will skew your counts unless you know to filter correctly.
Don’t ask the bot about statuses. The Vatico bot will generate the actual answer based on the site but not “why is it on-hold? and what does payment failure in this case refer to?” – therefore it can tell you what it is but not why it is like this in the pipeline. For status definitions, go to the dbt model code directly, check the lineage in Datahub, or ask your supervisor. Don’t trust the bot blindly. The bot is for discovery, but if you use it for definitions you must validate it still.

Know Your Tools — Before You Need Them

Early on, I spent time trying to get access to systems I didn’t need yet, while not fully understanding the ones I already had access to. The more useful habit is to know your verification tools well from the start — because when your numbers look wrong, you need to know exactly where to go to check them.

Tool What it’s the source of truth for What to use it for
WooCommerce / WordPress Sale orders and their statuses Verify order states, check customer records, confirm what “cancelled” or “completed” looks like at the source
Courier portal (Courier A / Courier B) Shipment tracking and courier-side statuses Verify delivery outcomes and shipment status labels — especially important to check for inconsistencies between our database and our couriers
Google Data Studio Warehouse’s operational view This is where you can track orders inbound and outbound from the warehouse.
Datahub Data lineage and model documentation Trace where a column comes from, understand how a table is built, use it to track for lineage (upsteam and downstream). So that you know where each table draws data from and who it passes it to.
pgAdmin What is actually in Datahub / the database validate that the data you expect to find for example from Datahub is actually there
Vatico Training Data Blog Posts Business flows and process knowledge Read these to understand why the data is structured the way it is, to gather experience from the past intern, to understand business flows
Vatico Bot Data Discovery and Ticket Refinement Use it to discover where to look for data, to get quick answers to where some data might be, or how to build some basic queries. But never trust it blindly — always validate the information it gives you with the actual data or models

Litmus Test: Test your understanding

Before you write your next ticket or touch any data, can you answer these 10 business and technical questions about how VATICO operates? If you don’t know the answers, research our process docs and blog posts first—because these rules directly affect how we scope problems and build data models.

Q01 Handoff Discrepancies

If I have a shipping order that is marked as ‘returned’ in my database but the warehouse says it is shipped, what could the possible problems be?

Q02 VAT Invoice Issuance

If my courier delivers a package, when must the VAT invoice be issued?

Q03 Warehouse Delays

If the courier says that my order is at their warehouse, but the database says shipped, what could that mean? How long max should the package be stuck at the warehouse before it becomes concerning?

Q04 Payment Terms & SLAs

What is the difference between COD and prepaid for VATICO? How does it affect the expected delivery time to the customer?

Q05 Post-Order Changes

Can a customer refund and change their details for an order? If yes or no, why is it designed like that?

Q06 WooCommerce Order States

What is the difference between an order being “on-hold” versus “cancelled” on WooCommerce?

Q07 Database Time Zones

What timezone should our timestamps be stored in inside our database?

Q08 Staging Data Errors

If there is an error in the staging data, what could be the causes? Should I fix it directly in staging now?

Q09 pgAdmin Verification

In pgAdmin, where can I check records for warehouse orders? Where can I check records for sales orders? Where can I check if something is successfully delivered?

Q10 Marketplace Scopes

How many marketplaces does VATICO support for Vietnam and Singapore?

If you can answer these questions, you should have a good foundation of how VATICO operates.

Reflections on SLA Handover Alert

Start well. Scope tight. Ask early.

→ Define Reality & Business Impact · Expectation · Research First
Gong Elijah