If me for some time, you almost certainly know I began my profession as a QA engineer before transitioning into the world of data analytics. I didn’t go to high school for it, didn’t have a mentor, and didn’t land in a proper training program. The whole lot I do know today—from SQL to modeling to storytelling with data—is self-taught. And consider me, it’s been a journey of trial, error, learning, and re-learning.
The Dilemma That Modified My Profession
A couple of years ago, I began occupied with switching organizations. Like many individuals in fast-evolving tech roles, I faced a surprisingly difficult query:
What role am I actually doing? Which roles should I apply for?
On paper, I used to be a Data Analyst. But in point of fact, my role straddled several functions: writing SQL pipelines, constructing dashboards, defining KPIs, and digging into product analytics. I wasn’t sure whether I must be applying for Analyst roles, BI roles, or something entirely different.
To make things worse, back then, job titles were vague, and job descriptions were bloated with buzzwords. You’d discover a posting titled that listed requirements like:
- Construct ML pipelines
- Write complex ETL scripts
- Maintain data lakes
- Create dashboards
- Present executive-level insights
- And oh, by the best way, be great at stakeholder management
It was overwhelming and confusing. And I do know I’m not alone on this.
Fast forward to today: thankfully, things are evolving. There’s still overlap between roles, but organizations have began to define them more clearly. In this text, I need to interrupt down the real differences between data roles, through the lens of a real-world example.
A Real-World Scenario: Meet
Let’s imagine a fictional quick-commerce startup called Quikee, launching across multiple Indian cities. Their value proposition? Deliver groceries and essentials inside 10 minutes.
Customers place orders through the app or website. Behind the scenes, there are micro-warehouses (also called “dark stores”) across cities, and a fleet of delivery partners who make those lightning-fast deliveries.
Now, let’s walk through the information needs of this company—from the moment an order is placed, to the dashboards executives use of their Monday morning meetings.
Step 1: Capturing and Storing Raw Data
The moment a customer places an order, transactional data is generated:
- Timestamps
- Order ID
- Items ordered
- Price
- Discount codes
- Customer location
- Payment method
- Assigned delivery partner
Let’s assume Quikee uses Amazon Kinesis to stream this data in real time to an S3 data lake. That stream is high-volume, time-sensitive, and crucial for business tracking.
But here’s the catch: raw data is messy. You may’t use it directly for decision-making.
So what happens next?
Step 2: Constructing Data Pipelines
Enter the Data Engineers.
They’re answerable for:
- Ingesting real-time data
- Validating schema consistency
- Handling failures and retries
- Writing pipelines to maneuver data from S3 into a knowledge warehouse (say, Snowflake or Redshift)
That is where ETL (Extract, Transform, Load) or ELT pipelines come into play. Data engineers clean, format, and structure the information to make it queryable.
For instance, an order table might get split into:
- Orders → One row per order
- Order_Items → One row per item in an order
- Payments → One row per payment attempt
At this stage, raw logs are changed into structured tables that analysts can work with.
Step 3: Dimensional Modeling & OLAP
As leadership starts asking strategic questions like:
- “Which city brings in essentially the most revenue?”
- “Which store is underperforming?”
- “What’s our average delivery time by zone?”
…it becomes clear that querying transactional data directly won’t scale.
That’s where dimensional modeling is available in.
As an alternative of flat, raw tables, data is structured into Fact and Dimension Tables.
🔸 Fact Tables
- Large, quantitative data tables which contain foreign keys together with measures and metrics ().
- Examples:
fact_orders,fact_payments,fact_deliveries - Contain metrics like revenue, order count, delivery time
🔹 Dimension Tables
- Smaller, descriptive tables that help understand the information in a fact table
- Examples:
dim_store,dim_product,dim_customer,dim_delivery_agent - Help filter, group, and join facts for deeper insights
This structure enables OLAP—fast, analytical querying across multiple dimensions. For instance, you possibly can now run queries like:
“Show me average delivery time by store and hour of day, over the past 7 days.”
This step is completed by Data Engineers at a lot of the organisations but I did construct few Dim and Fact tables once I was working as a Business Intelligence Engineer at Amazon.
Step 4: Defining KPIs and Metrics
That is where Analytics Engineers (or BI Engineers) shine.
They sit between the technical data layer and business users. Their responsibilities often include:
- Defining KPIs (e.g., churn rate, repeat purchase %, time-to-fulfillment)
- Writing logic for complex metrics (e.g., cohort retention, lively users)
- Creating semantic models or metrics layers in tools like dbt or Looker
- Ensuring consistent definitions across the corporate
For instance, at Amazon, our team didn’t query raw data to calculate revenue each time. As an alternative, we created pre-aggregated fact tables at every day, weekly, and monthly grains. That way, dashboards loaded faster, and metrics stayed consistent across teams.
Analytics Engineers act as translators between engineering and the business—defining what we measure and how we measure it.
Step 5: Evaluation, Reporting & Storytelling
Now comes the role of the Data Analyst.
Armed with clean, modeled data, they deal with answering real business questions like:
- “Why did retention drop in Bangalore last month?”
- “Which coupon codes drive essentially the most latest users?”
- “What are the highest products reordered in the primary 30 days?”
They construct dashboards in tools like Tableau, Power BI, or Looker. They run ad-hoc SQL queries. They dive into A/B test results, user behavior trends, and campaign effectiveness.
But above all, they tell stories with data—making complex numbers comprehensible and actionable for stakeholders.
Who’s Who?
TL;DR: Where Do You Fit?
Here’s how I give it some thought:
- Love constructing robust pipelines and solving scalability problems? → You’re a Data Engineer
- Love defining business metrics and organizing complex datasets? → You’re an Analytics Engineer
- Love uncovering insights and storytelling with data? → You’re a Data Analyst
After all, real-world roles often mix these. Especially at smaller corporations, you could wear multiple hats. And that’s okay.
The hot button is not the title—but where you add essentially the most value and what energizes you.
Final Thoughts
It took me an extended time to know what I actually do—not only what my job title says. And when you’ve ever felt that confusion, you’re not alone.
Today, I can clearly say I operate on the intersection of data modeling, business logic, and storytelling—a sweet spot between analytics and engineering. And I’ve learned that the flexibility to attach the dots is more essential than fitting right into a perfect box.
When you’ve walked an identical path—or wear multiple hats in your role—I’d love to listen to your story.
Drop a comment 👇 or share this with someone figuring it out too.
