If I had a while, you probably knew I started my career Quality Inspection Engineer Before transitioning to the world Data Analysis. I didn’t go to school, didn’t have a tutor, and didn’t participate in a formal training program. Everything I know today – from SQL to modeling to storytelling with data – is self-taught. Trust me, it was a journey of trial, error, learning and re-learning.
Changed my career dilemma
A few years ago, I started thinking about switching organizations. Like many people who play fast-growing technical roles, I face a surprisingly difficult problem:
What role am I actually doing? What roles should I apply for?
On paper, I’m a Data Analyst. But in reality, my role spans several features: writing SQL pipelines, building dashboards, defining KPIs, and mining product analytics. I’m not sure if I should apply for an analyst role, a dual role or something completely different.
To make things worse, at that time, the job title was vague and the job description was swollen by buzzwords. You will find a title “Data Analyst” Listed requirements:
- Building an ML pipeline
- Writing complex ETL scripts
- Maintaining the data lake
- Create a dashboard
- In-person executive level insights
- Oh, by the way, it’s excellent in stakeholder management
It’s overwhelming and confusing. And I know I’m not alone.
Fast forward to today: Thankfully, things are moving. There is still overlap between roles, but organizations have begun to define them more clearly. In this article, I want to break it down Actual differences between data rolesthrough a real-world example lens.
Reality: Meet Quak
Let’s imagine a fictional fast business startup called Quaklaunched across multiple Indian cities. What is their value proposition? Grocery and essentials available 10 minutes.
Customers place orders through the app or website. Behind the scenes, there are micro-software in various cities (also known as “dark shops”) and a bunch of delivery partners that make those lightning-fast delivery.
Now, let’s browse the company’s data needs – from the moment the order is placed to the use of dashboard executives in their Monday morning meeting.
Step 1: Capture and store raw data
The moment the customer places an order Transaction data generate:
- Timestamp
- Order ID
- Ordered items
- price
- Discount code
- Customer location
- Payment method
- Assigned delivery partners
Let’s assume Quikee uses Amazon Sports Transfer this data to S3 Data Lake. The stream is massive, time-sensitive and critical for business tracking.
But this is the capture: the raw data is messy. You cannot use it directly for decision making.
So what happens next?
Step 2: Build a Data Pipeline
enter Data Engineer.
They are responsible for:
- Intake of real-time data
- Verify mode consistency
- Processing failed and searched
- Write a pipeline to transfer data from S3 to a data warehouse (e.g., snowflake or redshift)
This is etl (extract, convert, load) or Elter The pipe works. Data engineers clean, format and construct data to make it queryable.
For example, an order table might be divided into:
- Order →Each order
- order_items →One line by line by line by line in the order
- Payment → Payment attempt per line
At this stage, the original log becomes a structured table that analysts can use.
Step 3: Dimensional Modeling and OLAP
As leaders begin to ask strategic questions, such as:
- “Which city brings the most income?”
- “Which store is not doing well?”
- “What is the average delivery time by region?”
…It is obvious that querying transaction data will not directly expand.
That’s where Dimensional modeling Come in.
Make the data into facts and dimension tables, rather than flat original tables.
🔸 Fact Sheet
- Large quantitative data sheets and measures and indicators (OK, most of the time. In fact, there is no measure in the fact sheet.).
- Example:
fact_orders,,,,,fact_payments,,,,,fact_deliveries - Includes metrics such as revenue, order count, delivery time, etc.
🔹 Size chart
- Smaller descriptive tables that can help understand the data in the fact table
- Example:
dim_store,,,,,dim_product,,,,,dim_customer,,,,,dim_delivery_agent - Helps filter, group and join facts for deeper insights
This structure can be enabled OLAP– Quick analytical queries across multiple dimensions. For example, you can now run the following query:
“Show me the store for the past 7 days and the average delivery time of the day.”
This step is done by data engineers in most organizations, but when I worked as a business intelligence engineer at Amazon, I did build very little dim and fact tables.
Step 4: Define KPIs and Metrics
This is Analytical Engineer (or BI Engineer) shine.
They are located between the technical data layer and business users. Their responsibilities usually include:
- Define KPI (e.g. churn rate, repeat purchase %, satisfying time)
- Write logic for complex metrics (e.g., similar retention, active users)
- create Semantic Model or Indicator layer In tools like DBT or Looker
- Ensure consistent definition of the entire company
At Amazon, for example, our team did not query the raw data to calculate revenue per time. Instead, we created Preprocessing fact table Cereals daily, weekly and monthly. This way, the dashboard loads faster and the metrics are consistent across the team.
Analytical Engineer is a translation between engineering and business – Definition What We measure and how We measure it.
Step 5: Analysis, Reporting, and Storytelling
Come now Data Analyst.
They are equipped with clean, modeled data, and they focus on answering actual business questions such as:
- “Why did the retention rate drop in Bengaluru last month?”
- “Which coupon code drives the latest users?”
- “What are the top products that are reordered in the first 30 days?”
They build dashboards in tools like Tableau, Power BI, or Looker. They run temporary SQL queries. They delve into A/B test results, user behavior trends, and campaign effectiveness.
But the most important thing is Tell a story With data – plural numbers that make stakeholders understandable and feasible.
Who is who?
TL; DR: Where is it suitable for you?
This is my thoughts:
- Love building strong pipelines and solving scalability issues? →You are one Data Engineer
- Like to define business metrics and organize complex datasets? →You are one Analytical Engineer
- Like using data to reveal insights and tell stories? →You are one Data Analyst
Of course, real-world characters often blend it together. Especially at smaller companies, you may wear multiple hats. It doesn’t matter.
The key is not the title, but Where to add value and What makes you energetic.
The final thought
It took me a long time to understand what I actually did, not what my job title says. And, if you’ve ever been confused, you’re not alone.
Today, I can clearly say that I am Data Modeling,,,,, Business Logicand storytelling– The best position between analysis and engineering. And I learned that the ability to connect points is more important than installing in a perfect box.
If you’ve gone a similar path, or a character wearing a multi-hat – I’d love to hear your story.
Leave a comment 👇 or share with someone who figured it out.
