Do DTC brands still need a data engineer on staff?
Natural language query works on clean, modeled data with defined metrics. Someone still owns ingestion, models, and changes: heavy setup, then light support.
Written by Linus Tse, founder of Greyfield Data
· 7 min read
On this page 9 sections
"In a world where there's NLQ plugins, and the way laypeople can query things, we don't need a data engineer on staff like we may have needed 5 years ago. How much time does it save, how much cheaper is it?" It's a fair question for a DTC brand to ask in 2026. The honest answer is that natural language query changes who asks the questions, not who keeps the answers right.
We run this for DTC brands as a fractional team: a heavy warehouse and reporting setup, then light ongoing support. The CAC apportionment demo shows the kind of modeled data that makes plain-English questions safe to ask.
Key takeaways
- Natural language query (NLQ) works well on top of clean, modeled tables with defined metrics. On raw connector tables, it gives confident answers to the wrong question.
- The work that NLQ removes is writing queries and building one-off reports. The work it doesn't remove is ingestion, modeling, metric definitions, and handling change.
- Most DTC brands don't need a full-time data engineer, but they do need someone who owns the data. A fractional or consultant model fits well: setup is heavy, later it's lighter.
- You'll always need some support and tinkering, because sources, products, channels, and questions keep changing.
- Time saved is real but specific to your team, so measure it against the hours spent on reporting today rather than trusting a general figure.
What does natural language query actually do?
It turns a plain-English question into a query against your data, and returns an answer or a chart. Tools like Claude can do this against Snowflake directly, as in how to connect Claude to Snowflake.
The quality of the answer depends on what it's querying. Ask "what was CAC last month?" against raw Shopify and ad tables, and the model has to guess. Which orders count as new customers? Is spend net of agency fees? Does TV count? It will pick something and sound sure.
Ask the same question against a modeled table with a defined CAC metric, and there's nothing to guess. The model reads the definition. That's the job of a semantic layer: one place where metrics, joins, and business terms are written down so every tool, including AI, uses the same ones. Snowflake has semantic views built for exactly this.
What does NLQ replace, and what doesn't it?
It replaces a lot of the asking and very little of the maintaining.
| Work | Before NLQ | With NLQ on modeled data |
|---|---|---|
| Writing ad hoc queries | An analyst or engineer | The person asking, in plain English |
| Building one-off reports | Request, wait, build | Ask, check, save the useful ones |
| Loading sources | Someone owns connectors | Same |
| Modeling orders, refunds, customers | Someone owns models | Same |
| Defining metrics | Often scattered across reports | Must be written down, or NLQ guesses |
| Handling change (new channel, new product, new field) | Someone updates models | Same |
| Access and safety | Permissions on reports | Permissions on what the AI can read, too |
The last row matters more than people expect. Giving a model access to your warehouse needs the same care as giving a person access. We cover the setup in how to give analysts safe AI access to Snowflake.
Why will you always need support and tinkering?
Because the business changes faster than the data model. Every one of these lands on whoever owns the data:
- A new sales channel, such as Amazon or TikTok Shop, with its own orders, fees, and timing.
- A new subscription offer that changes what counts as a subscriber.
- An ad platform that renames or retires a field the model depends on.
- A connector that succeeds but loads a partial day.
- A new question that needs a field nobody loads yet, such as discount code or survey answer.
- A metric definition that finance and marketing need to agree on again.
None of these is big on its own. Together, they're why a data setup with no owner drifts until people stop trusting it. Natural language query makes drift worse, not better, because wrong numbers arrive faster and look more official.
What does a fractional data team look like?
It's front-loaded. The setup phase will be heavy, and later it'll be less, but it doesn't drop to zero.
| Role | Setup phase | Ongoing |
|---|---|---|
| Ingestion | Choose and configure connectors per source, backfill history, set freshness alerts | Watch alerts, fix broken loads, add new sources |
| Modeling | Build clean tables for orders, refunds, customers, subscriptions, and spend | Adjust for new channels, products, and fields |
| Metric definitions | Agree definitions of CAC, revenue, margin, and subscribers with finance and marketing | Revisit when the business changes, record each change |
| Semantic layer | Write metrics and joins so BI and AI tools read the same definitions | Add metrics as new questions come up |
| BI and dashboards | Build the core views people read daily and weekly | Retire unused views, add new ones |
| AI access | Set up NLQ on modeled data, with permissions and tests | Review answers people rely on, tighten definitions where NLQ guesses |
| Support | Train the team on where numbers live | Answer questions, troubleshoot "this looks wrong" |
In-house, that's spread across a data engineer, an analytics engineer, and an analyst. Most DTC brands don't have enough ongoing work for all three full-time. A fractional team covers the setup at full depth, then stays on a lighter retainer for the ongoing column. Someone on your side still needs to own the questions and the decisions.
How much time does it save, and how much cheaper is it?
It depends on how many hours your team spends on reporting today, so we don't quote a general figure. The useful comparison is your current hours spent pulling, pasting, and reconciling numbers, against the hours left once that work moves to modeled data.
Our reporting time calculator gives you that baseline. On cost, compare a full-time hire's loaded cost in your market with the cost of a setup project plus a retainer. The answer differs by brand, and it's worth working through with your own numbers rather than someone else's.
What we can say from the builds we run: the biggest time cost before a warehouse is usually reconciling. Two people pull the same number from two places, get different answers, and spend an afternoon finding out why. Defined metrics remove that, with or without AI. For an example of the cleanup, see why your Google Sheets marketing dashboard keeps breaking.
Do you do the BI side of things as well?
Yes. We build the dashboards, not just the pipes. Our main BI tool is Sigma, on top of Snowflake, because it feels like a spreadsheet to marketing and finance teams while reading modeled warehouse data.
The BI layer and the NLQ layer should read the same definitions. If a dashboard says CAC is one number and an AI answer says another, people stop trusting both. Building the semantic layer first, then the dashboards and AI access on top, avoids that.
Frequently asked questions
Can natural language query replace a data analyst?
It can replace much of the ad hoc query writing. It can't replace someone who knows which question to ask, checks whether the answer makes sense, and owns the metric definitions it relies on.
Does a DTC brand need a full-time data engineer?
Most don't, but they need someone who owns ingestion, models, and definitions. A fractional or consultant model with a heavy setup and a lighter retainer fits many DTC brands.
Does NLQ work on raw Shopify and ad data?
It runs, but it has to guess what each metric means, so answers can be wrong while sounding confident. It works much better on modeled tables with a semantic layer that defines the metrics.
What is a semantic layer for AI?
It's where metrics, joins, and business terms are defined once, so BI tools and AI assistants read the same definitions. See what a semantic layer is for a fuller answer.
How much ongoing support does a DTC data warehouse need?
Less than setup, but not zero. Expect regular work when sources change, new channels launch, or metric definitions need agreeing again.
What to do next
Write down who in your team owns each of the rows in the table above today. Any row with no name is where a fractional team helps most.
To see the kind of modeled data that makes NLQ safe, try the CAC apportionment demo, or book a call with Linus to talk through setup and ongoing support.
Part of the Ecommerce reporting guides, a reading path through related articles.
Linus Tse
Founder of Greyfield Data. Built 400+ dashboards. Certified in Sigma, Snowflake, Tableau, and Power BI.
About Linus
