🚀 𝗧𝗔𝗧𝗔 𝗚𝗿𝗼𝘂𝗽 𝗙𝗥𝗘𝗘 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗜𝗻𝘁𝗲𝗿𝗻𝘀𝗵𝗶𝗽 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝘀 😍

Tata Group/TCS virtual job simulations let you work through industry-style tasks and strengthen your resume.

🎓 3 FREE Virtual Programs:
📊 Data Visualisation
🔐 Cybersecurity
🌱 ESG (Environmental, Social & Governance)

💻 Virtual & flexible
🎓 Free Certificate on Completion
📄 Add the experience to your Resume/LinkedIn

🔗 𝗘𝗻𝗿𝗼𝗹𝗹 𝗳𝗼𝗿 𝗙𝗥𝗘𝗘 👇:-

https://pdlink.in/4yoXEOI

🔥 Perfect for Students • Freshers • Job Seekers

🚀 Data Analyst Roadmap — Part 19

🧠 SQL Level 9 — Query Performance & Optimization

Knowing how to write a SQL query is one skill. Knowing how to write a query that is correct, efficient, scalable, and easy to maintain is another.

As a Data Analyst, you may eventually work with tables containing:

📊 Millions of rows

📦 Large transaction datasets

👥 Millions of customers

📅 Years of historical data

A query that works perfectly on 10,000 rows may become extremely slow on 100 million rows. That's why understanding SQL performance matters.

🔹 1. What Is Query Optimization?

Query optimization means improving a query so that it:

✅ Returns the correct result

✅ Uses fewer resources

✅ Processes less unnecessary data

✅ Executes faster

✅ Scales better as data grows

🔹 2. Select Only the Columns You Need

Avoid:

SELECT * FROM Orders;

when you only need:

SELECT Order_ID, Customer_ID, Sales FROM Orders;

SELECT * can:

• Read unnecessary columns

• Increase data transfer

• Make queries harder to maintain

• Become problematic when tables change

For analytical work, explicitly selecting required columns is usually better.

🔹 3. Filter Data Early

Suppose you only need 2026 orders:

SELECT Customer_ID, SUM(Sales) AS Total_Sales 
FROM Orders 
WHERE Order_Date >= '2026-01-01' 
  AND Order_Date < '2027-01-01' 
GROUP BY Customer_ID;

Filtering reduces the amount of data that later operations need to process.

🔹 4. Understand Indexes

An index is a database structure that can help locate rows more efficiently. Think of it like the index of a book.

Without an index: Database → potentially scan many rows

With a useful index: Database → locate relevant data more efficiently

Indexes can be especially useful for columns frequently used in: WHERE, JOIN, ORDER BY, and sometimes GROUP BY.

Example:

CREATE INDEX idx_orders_customer ON Orders(Customer_ID);

⚠️ Index syntax and behavior vary by database.

🔹 5. Indexes Are Not Always Better

Indexes have costs. They can:

Consume storage, slow down INSERT, UPDATE, DELETE, and require maintenance.

Therefore:

Don't create indexes on every column. Database systems and workloads determine which indexes are useful.

🔹 6. Index Columns Used for JOINs

SELECT c.Customer_Name, o.Sales 
FROM Customers c 
JOIN Orders o ON c.Customer_ID = o.Customer_ID;

The join depends on: Customer_ID.

Appropriate indexing can improve join performance, especially for large tables. But the database optimizer decides whether an index actually provides a benefit.

🔹 7. Avoid Functions on Filtered Columns When Possible

Consider:

WHERE YEAR(Order_Date) = 2026

A range condition is often preferable:

WHERE Order_Date >= '2026-01-01' AND Order_Date < '2027-01-01'

Why?

Applying a function to every row can make it harder for some database systems to use an index efficiently. This is called maintaining sargability.

🔹 8. What Is Sargability?

A condition is generally considered sargable when the database can efficiently use an index to find matching rows.

Compare:

WHERE Order_Date >= '2026-01-01' 

with:

WHERE YEAR(Order_Date) = 2026

The first form usually gives the optimizer more opportunity to use an index on Order_Date.

🔹 9. Use "EXPLAIN"

One of the most important tools for understanding query performance is:

EXPLAIN 
SELECT * FROM Orders WHERE Customer_ID = 1001;

Depending on the database, you may also see:

EXPLAIN ANALYZE

These tools can show how the database plans to execute or actually executes the query.

You may encounter concepts such as: Table scan, Index scan, Index seek, Join strategy, Sort, Aggregate, Estimated rows, Actual rows, Execution cost.

🔹 10. Table Scan vs Index Access

A table scan may require reading a large portion of a table. An index-based access path can sometimes locate matching records much more efficiently.

But: ⚠️ A table scan is not automatically bad.

If you need most of the table, scanning it may actually be the best strategy.

The optimizer chooses based on: Data size + statistics + indexes + query conditions + database engine.

🔹 11. Avoid Unnecessary "DISTINCT"

This query:

SELECT DISTINCT Customer_ID FROM Orders; 

may be perfectly valid.

But don't use DISTINCT simply to hide duplicate rows created by an incorrect join.

🔹 12. Be Careful With JOIN Multiplication

Suppose:

Customer A → 10 Orders and each order has 5 Order Items

Joining customers → orders → order items can produce many rows.

If you then calculate: SUM(Order_Sales) you could accidentally multiply the order-level sales.

This is a logic problem, not just a performance problem. Always understand the grain before joining and aggregating.

🔹 13. "UNION" vs "UNION ALL"

"UNION" removes duplicates.

SELECT Customer_ID FROM Current_Customers 
UNION 
SELECT Customer_ID FROM Previous_Customers;

"UNION ALL" simply combines the results:

SELECT Customer_ID FROM Current_Customers 
UNION ALL 
SELECT Customer_ID FROM Previous_Customers;

If you don't need duplicate removal, UNION ALL is generally preferable because it avoids the additional deduplication work.

🔹 14. Avoid Repeating Expensive Logic

Suppose the same complex calculation appears multiple times.

Instead of repeating it, consider using: CTEs, Derived tables, Temporary tables, Views, Pre-aggregated tables.

The objective is: Calculate expensive logic only when necessary.

🔹 15. CTEs and Performance

CTEs make SQL much easier to organize:

WITH Customer_Sales AS (
    SELECT Customer_ID, SUM(Sales) AS Total_Sales 
    FROM Orders 
    GROUP BY Customer_ID
) 
SELECT * FROM Customer_Sales WHERE Total_Sales > 10000;

A CTE is primarily a query organization technique. Whether it improves performance depends on the database engine, query structure, materialization behavior, and optimizer.

🔹 16. Reduce Data Before Expensive Operations

A useful analytical pattern is:

Raw Data → Filter → Select Required Columns → Join → Aggregate → Window Function → Final Result

The exact optimal order depends on the query, but the principle is: Don't process more data than necessary.

🔹 17. Avoid Correlated Subqueries When a Better Approach Exists

A correlated subquery may conceptually execute in relation to each outer row:

SELECT e.Employee, e.Salary 
FROM Employees e 
WHERE e.Salary > (
    SELECT AVG(e2.Salary) 
    FROM Employees e2 
    WHERE e2.Department = e.Department
);

Sometimes a CTE + join or window function can express the same business logic more efficiently:

WITH Employee_Data AS (
    SELECT 
        Employee, 
        Department, 
        Salary, 
        AVG(Salary) OVER (PARTITION BY Department) AS Avg_Dept_Salary 
    FROM Employees
) 
SELECT Employee, Department, Salary 
FROM Employee_Data 
WHERE Salary > Avg_Dept_Salary;

🔹 18. Query Readability Also Matters

A query can be technically fast but difficult to understand.

Bad analytical SQL often contains:

❌ Unclear aliases, repeated logic, huge nested queries, unnecessary columns, unnecessary joins, no explanation of business logic

Good SQL should be:

✅ Correct, efficient, readable, maintainable, easy to troubleshoot

🔹 19. SQL Optimization Checklist

Before finalizing a query, ask:

1. Do I need all these columns?

2. Am I processing unnecessary rows?

3. Are my joins using the correct keys?

4. Did the join change the grain?

5. Am I accidentally multiplying values?

6. Can a date filter be written as a range?

7. Do I really need "DISTINCT"?

8. Could "UNION ALL" be used instead of "UNION"?

9. Can I inspect the execution plan?

10. Will this query still perform well on a much larger dataset?

🎯 SQL Interview Challenge

Question:

A query takes 30 seconds:

SELECT * FROM Orders WHERE YEAR(Order_Date) = 2026;

How could you improve it?

A better approach is:

SELECT Order_ID, Customer_ID, Order_Date, Sales 
FROM Orders 
WHERE Order_Date >= '2026-01-01' 
  AND Order_Date < '2027-01-01';

Why?

✔ Avoids unnecessary columns

✔ Uses a range filter

✔ Can be more index-friendly

✔ Clearly defines the required period

Then use EXPLAIN/EXPLAIN ANALYZE to verify the actual execution plan.

🧠 Double Tap ❤️ For More

🚀 𝗧𝗼𝗽 𝗧𝗲𝗰𝗵 𝗖𝗲𝗿𝘁𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝘁𝗼 𝗟𝗮𝗻𝗱 𝗛𝗶𝗴𝗵-𝗣𝗮𝘆𝗶𝗻𝗴 𝗝𝗼𝗯𝘀 𝗶𝗻 𝟮𝟬𝟮𝟲😍

💰 Highest Salary: ₹41 LPA
📈 Average Salary: ₹7.4 LPA
🎓 2,000+ Students Placed
🏢 500+ Hiring Partners

💻 Full Stack :- https://pdlink.in/3SuUeuD

📊 Data Analytics :- https://pdlink.in/45vk5ph

💫AI Engineering :- https://pdlink.in/4fWJVID

🔥 Take the first step towards your high-paying tech career in 2026!

𝗗𝗮𝘁𝗮 𝗦𝗰𝗶𝗲𝗻𝗰𝗲 𝗙𝗥𝗘𝗘 𝗢𝗻𝗹𝗶𝗻𝗲 𝗠𝗮𝘀𝘁𝗲𝗿𝗰𝗹𝗮𝘀𝘀 😍

💫Accelerate your career in Data Science

💫Discover the skills, tools and career roadmap needed to enter this high-demand field.

🔥 Beginner-friendly online session—no prior experience required!

𝗥𝗲𝗴𝗶𝘀𝘁𝗲𝗿 𝗙𝗼𝗿 𝗙𝗥𝗘𝗘 👇:-

https://pdlink.in/46adC3l

(Only few slots left )

📅 Date: September 11, 2026
⏰ Time: 7:00 PM

🚀 Data Analyst Roadmap — Part 20

🧠 SQL Level 10 — Cohort Analysis, Retention & Customer Analytics

Now we're moving from writing SQL queries to using SQL for real analytical problems.

Customer analytics is one of the most important areas because businesses want to know:

👥 Who are our customers?

🛒 When did they first purchase?

🔄 Do they come back?

📉 When do they stop returning?

💰 Which customers generate most revenue?

📊 How does behavior change over time?

One of the most powerful techniques for this is Cohort Analysis.

🔹 1. What Is Cohort Analysis?

A cohort is a group who share a common starting point.

• Jan 2026 Cohort = first purchase in Jan 2026

• Feb 2026 Cohort = first purchase in Feb 2026

Instead of mixing everyone, we track each group over time.

🔹 2. Why It Matters

Suppose total monthly customers are increasing.

That sounds positive.

But what if new customers are increasing while existing customers stop returning?

A simple monthly report may hide this problem.

Cohort analysis separates New vs Returning customers.

This makes retention problems much easier to identify.

🔹 3. Step 1 — Find Each Customer's First Purchase

SELECT
    Customer_ID,
    MIN(Order_Date) AS First_Order_Date
FROM Orders
GROUP BY Customer_ID;

This gives us the first purchase date for every customer.

Customer | First Order
C101     | 2026-01-10
C102     | 2026-01-18
C103     | 2026-02-05

🔹 4. Step 2 — Assign a Cohort Month

We can convert the first purchase into a month-level cohort.

First Purchase Date → Cohort Month
C101 → 2026-01
C103 → 2026-02

The exact month-truncation syntax varies between SQL databases.

🔹 5. Step 3 — Join Cohort Back to Orders

Now we need both:

Customer's cohort

and

Customer's subsequent activity

WITH Customer_Cohorts AS (
    SELECT Customer_ID, MIN(Order_Date) AS First_Order_Date
    FROM Orders GROUP BY Customer_ID
)
SELECT o.Customer_ID, c.First_Order_Date, o.Order_Date, o.Sales
FROM Orders o
JOIN Customer_Cohorts c ON o.Customer_ID = c.Customer_ID;

Now every transaction knows which cohort the customer belongs to.

🔹 6. Cohort Month vs Activity Month

• Cohort Month: When first purchased

• Activity Month: When purchase happened

Customer | Cohort | Activity
C101     | Jan    | Jan
C101     | Jan    | Feb
C101     | Jan    | Mar

🔹 7. Measuring Retention

Retention measures how many customers from a cohort remain active in later periods.

Retention = Active in Period / Original Cohort * 100

• Jan cohort: 100 customers

• Feb: 60 active → 60%

• Mar: 40 active → 40%

🔹 8. Retention Month

Months Since Cohort = Activity - Cohort

Eg:

Customer | Cohort | Activity | Months_Since_Cohort
C101     | Jan    | Jan      | 0
C101     | Jan    | Feb      | 1
C101     | Jan    | Mar      | 2

🔹 9. Cohort Retention Matrix

Conceptually, the final result may look like:

Cohort | Month0 | Month1 | Month2 | Month3
Jan    | 100%   | 60%    | 40%    | 30%
Feb    | 100%   | 65%    | 45%    | —
Mar    | 100%   | 70%    | —      | —

This is often called a cohort retention matrix.

It immediately shows whether newer customer cohorts are retaining better or worse.

🔹 10. Customer Lifetime Value (CLV)

Another important customer metric is Customer Lifetime Value (CLV/LTV).

A simplified version can be based on:

Total Revenue Generated by Customer

A more advanced business model may consider:

• Revenue

• Gross margin

• Purchase frequency

• Retention

• Customer lifespan

• Acquisition cost

🔹 11. Average Order Value (AOV)

A basic customer metric is:

Average Order Value = Total Sales ÷ Number of Orders

In SQL:

SELECT Customer_ID, SUM(Sales) / COUNT(DISTINCT Order_ID) AS AOV
FROM Orders GROUP BY Customer_ID;

This tells us how much a customer spends per order on average.

🔹 12. Purchase Frequency

We can also calculate the number of orders per customer:

SELECT Customer_ID, COUNT(DISTINCT Order_ID) AS Number_of_Orders
FROM Orders GROUP BY Customer_ID;

Customers can then be segmented based on activity.

For example:

• 1 order → One-time customer

• 2–5 orders → Repeat customer

• 6+ orders → Highly active customer

⚠️ These thresholds are business rules, not universal definitions.

🔹 13. Recency

SELECT Customer_ID, MAX(Order_Date) AS Last_Order_Date
FROM Orders GROUP BY Customer_ID;

Then compare the last order date with a chosen analysis date.

A customer who purchased recently is generally more active than someone whose last purchase was a long time ago.

🔹 14. RFM Analysis

• R → Recency: How recently?

• F → Frequency: How often?

• M → Monetary: How much?

Example:

Customer | Recency | Frequency | Monetary
C101     | 5 days  | 12 orders | ₹85,000
C102     | 20 days | 6 orders  | ₹42,000
C103     | 120 days| 2 orders  | ₹8,000

This allows businesses to identify:

⭐ High-value customers

🔄 Loyal customers

⚠️ Customers at risk

💤 Inactive customers

🔹 15. Segmentation With CASE

You can convert analytical metrics into business segments.

For example:

SELECT Customer_ID, Total_Sales,
  CASE 
    WHEN Total_Sales >= 50000 THEN 'High Value'
    WHEN Total_Sales >= 20000 THEN 'Medium Value'
    ELSE 'Low Value'
  END AS Customer_Segment
FROM Customer_Sales;

This transforms numerical analysis into a business-friendly classification.

🔹 16. Repeat Customers

SELECT Customer_ID, COUNT(DISTINCT Order_ID) AS Order_Count
FROM Orders GROUP BY Customer_ID
HAVING COUNT(DISTINCT Order_ID) > 1;

This finds customers with more than one order.

🔹 17. First vs Repeat Purchase

You can use ROW_NUMBER() to identify purchase sequence.

WITH Customer_Orders AS (
  SELECT Customer_ID, Order_ID, Order_Date,
  ROW_NUMBER() OVER (PARTITION BY Customer_ID ORDER BY Order_Date) AS Purchase_Number
  FROM Orders
)
SELECT * FROM Customer_Orders;

Now:

Purchase_Number = 1 means the customer's first purchase.

Purchase_Number = 2 means the second purchase.

And so on.

This opens the door to deeper customer behavior analysis.

🔹 18. Time Between Purchases

SELECT Customer_ID, Order_Date,
LAG(Order_Date) OVER (PARTITION BY Customer_ID ORDER BY Order_Date) AS Previous_Order_Date
FROM Orders;

Now you can calculate the number of days between purchases.

→ Helps answer "How frequently do customers return?"

🔹 19. Churn Analysis

Churn means customers stop using or purchasing from a business.

SQL can help identify customers whose activity has fallen below a defined threshold.

For example:

Last Purchase → Days Since → Business Threshold → Active / At Risk / Inactive

SQL finds pattern, business defines churn.

🎯 Interview Challenge

Find customers with ≥3 orders and >50,000 spent:

SELECT Customer_ID, COUNT(DISTINCT Order_ID) AS Order_Count, SUM(Sales) AS Total_Sales
FROM Orders
GROUP BY Customer_ID
HAVING COUNT(DISTINCT Order_ID) >= 3 AND SUM(Sales) > 50000;

🧠 Double Tap ❤️ For More

𝗧𝗼𝗽 𝟱 𝗙𝗥𝗘𝗘 𝗖𝗼𝘂𝗿𝘀𝗲𝘀 𝘁𝗼 𝗞𝗶𝗰𝗸𝘀𝘁𝗮𝗿𝘁 𝗬𝗼𝘂𝗿 𝗗𝗮𝘁𝗮 𝗦𝗰𝗶𝗲𝗻𝗰𝗲 𝗖𝗮𝗿𝗲𝗲𝗿 📊

Want to start a career in Data Science without spending money?

Here are 5 beginner-friendly learning resources covering essential skills such as Python, SQL, Machine Learning and hands-on projects.

🔗 𝗘𝗻𝗿𝗼𝗹𝗹 𝗳𝗼𝗿 𝗙𝗥𝗘𝗘 👇:-

https://pdlink.in/4ilAmok

🎯 Perfect for Students • Freshers • Beginners • Aspiring Data Scientists

💡 Learn → Practice → Build Projects → Create Your Portfolio

🚀 Data Analyst Roadmap — Part 18

🧠 SQL Level 8 — Advanced Analytical Queries & Business Problems

At this stage, you know the core SQL building blocks:

SELECT → WHERE → GROUP BY → HAVING → JOIN → CTE → Window Functions → Date Analysis

Now it's time to combine them.

Real Data Analyst work rarely asks: "Write a query using RANK()"

Instead, you'll get business questions like:

• "Which customers are becoming inactive?"

• "What are our top-selling products in each category?"

• "Which month had the highest revenue growth?"

The real skill is converting a business problem into SQL logic.

🔹 1. Start With the Business Question

Before writing SQL, identify:

• What are we measuring?

• At what level?

• Which tables contain the required data?

• What filters are needed?

• Do we need aggregation?

• Do we need ranking or comparison?

For example: "Find the top 3 products in every category."

Break it down: Product → Category → Sales → Rank within Category → Keep Top 3

🔹 2. Find the Correct Grain

Grain means: What does one row represent?

• Orders → one row per order

• Order_Items → one row per product within an order

• Customers → one row per customer

If you don't understand the grain, you can accidentally double-count revenue.

🔹 3. Revenue by Customer

SELECT
    c.Customer_ID,
    c.Customer_Name,
    SUM(o.Sales) AS Total_Sales
FROM Customers c
JOIN Orders o ON c.Customer_ID = o.Customer_ID
GROUP BY c.Customer_ID, c.Customer_Name;

🔹 4. Rank Customers by Revenue

WITH Customer_Sales AS (
    SELECT Customer_ID, SUM(Sales) AS Total_Sales
    FROM Orders GROUP BY Customer_ID
)
SELECT
    Customer_ID,
    Total_Sales,
    RANK() OVER (ORDER BY Total_Sales DESC) AS Sales_Rank
FROM Customer_Sales;

🔹 5. Top 3 Customers in Each Region

WITH Customer_Sales AS (
    SELECT Customer_ID, Region, SUM(Sales) AS Total_Sales
    FROM Orders GROUP BY Customer_ID, Region
),
Ranked_Customers AS (
    SELECT *, RANK() OVER (PARTITION BY Region ORDER BY Total_Sales DESC) AS Sales_Rank
    FROM Customer_Sales
)

SELECT * FROM Ranked_Customers WHERE Sales_Rank <= 3;

🔹 6. Finding the Second-Highest Salary

WITH Ranked_Employees AS (
    SELECT Employee, Salary,
           DENSE_RANK() OVER (ORDER BY Salary DESC) AS Salary_Rank
    FROM Employees
)

SELECT Employee, Salary FROM Ranked_Employees WHERE Salary_Rank = 2;

🔹 7. Find Products That Never Sold

SELECT p.Product_ID, p.Product_Name
FROM Products p
LEFT JOIN Order_Items oi ON p.Product_ID = oi.Product_ID
WHERE oi.Product_ID IS NULL;

🔹 8. Customers With No Orders

SELECT c.Customer_ID, c.Customer_Name
FROM Customers c
LEFT JOIN Orders o ON c.Customer_ID = o.Customer_ID
WHERE o.Customer_ID IS NULL;

🔹 9. Customers Above Average Spending

WITH Customer_Sales AS (
    SELECT Customer_ID, SUM(Sales) AS Total_Sales
    FROM Orders GROUP BY Customer_ID
)
SELECT Customer_ID, Total_Sales FROM Customer_Sales
WHERE Total_Sales > (SELECT AVG(Total_Sales) FROM Customer_Sales);

🔹 10. Month-over-Month Sales Growth

WITH Monthly_Sales AS (
    SELECT EXTRACT(YEAR FROM Order_Date) AS Year,
           EXTRACT(MONTH FROM Order_Date) AS Month,
           SUM(Sales) AS Total_Sales
    FROM Orders GROUP BY 1, 2
),
Comparison AS (
    SELECT Year, Month, Total_Sales,
           LAG(Total_Sales) OVER (ORDER BY Year, Month) AS Previous_Sales
    FROM Monthly_Sales
)

SELECT Year, Month, Total_Sales, Previous_Sales,
       Total_Sales - Previous_Sales AS Sales_Change
FROM Comparison;

🔹 11. Calculate Growth Percentage

(Total_Sales - Previous_Sales) / NULLIF(Previous_Sales, 0) * 100

NULLIF() prevents division-by-zero errors.

🔹 12. Find the Latest Order for Every Customer

WITH Ranked_Orders AS (
    SELECT Customer_ID, Order_ID, Order_Date,
           ROW_NUMBER() OVER (PARTITION BY Customer_ID ORDER BY Order_Date DESC) AS rn
    FROM Orders
)

SELECT Customer_ID, Order_ID, Order_Date FROM Ranked_Orders WHERE rn = 1;

🔹 13-14. Inactive Customers & Duplicates

Inactive = MAX(Order_Date) vs 90-day threshold.

Business defines the rule, SQL calculates it.

Detect duplicates:

WITH Duplicate_Check AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY Customer_ID, Order_Date, Sales ORDER BY Order_ID) AS rn
    FROM Orders
)

SELECT * FROM Duplicate_Check WHERE rn > 1;

🔹 15. Combining Multiple Tables

SELECT c.Customer_ID, c.Customer_Name, p.Product_Name, oi.Quantity, oi.Sales
FROM Customers c
JOIN Orders o ON c.Customer_ID = o.Customer_ID
JOIN Order_Items oi ON o.Order_ID = oi.Order_ID
JOIN Products p ON oi.Product_ID = p.Product_ID;

⚠️ Every additional join can change the number of rows. Always check the grain.

🔹 16. The Most Important Analytical Pattern

1. Filter raw data → 2. Join tables → 3. Aggregate to correct grain → 4. Apply window functions → 5. Filter analytical result → 6. Present final output

💼 Real-World Business Problems to Practice

Sales: Top 5 products by revenue, Top products within each category, Month with highest sales, Revenue growth by month

Customers: Customers with no orders, declining purchases, most recent purchase, repeat customers, AOV per customer

Operations: Orders taking longer than expected, Products never sold, Duplicate transactions, Most active regions

🎯 SQL Interview Challenge: Find the highest-selling product in each category.

WITH Product_Sales AS (
    SELECT Product_ID, Category, SUM(Sales) AS Total_Sales
    FROM Product_Sales_Data GROUP BY Product_ID, Category
),
Ranked_Products AS (
    SELECT *, RANK() OVER (PARTITION BY Category ORDER BY Total_Sales DESC) AS Sales_Rank
    FROM Product_Sales
)
SELECT Product_ID, Category, Total_Sales FROM Ranked_Products WHERE Sales_Rank = 1;

🧠 SQL Resources: https://whatsapp.com/channel/0029VanC5rODzgT6TiTGoa1v

Double Tap ❤️ For More