Scenario-Based Data Analytics Interview Questions

Use a star schema, remove unused columns, prefer measures, reduce visuals per page, limit high-cardinality fields and use aggregations or incremental refresh.

Use RFM scoring or clustering on behaviour and value, validate segments with business teams and attach an action to each segment.

Find each user's first activity date as a cohort, join to later activity, and compute the share of each cohort active in day, week or month N.

Confirm data accuracy first → break down by region, product, channel and customer segment → compare with seasonality and last year → check pricing, stock-outs, marketing changes and funnel conversion → present the root causes with clear charts.

Check data pipelines first, then segment by channel, region, product and device, compare to the same period last year, and look for launches, outages or campaigns.

Start from the business questions, show 4–6 top KPIs with trend vs target, allow drill-downs, keep colours consistent, remove clutter, add time/region filters and give one clear insight per visual.

Use XLOOKUP or COUNTIF to flag missing items in each list, or merge them in Power Query with a full outer join and filter unmatched rows.

Read the execution plan, add or fix indexes, select only needed columns, filter early, avoid functions on indexed columns, and replace correlated subqueries with joins.

Understand why it is missing, consider imputation or a missing flag, test sensitivity, and talk to data owners about fixing collection if it is systematic.

Compare with a control group or use difference-in-differences, control for seasonality, and measure incremental sales against campaign cost.

Pull data with SQL or APIs, clean and aggregate with Pandas, build charts and an Excel or PDF output, and schedule it with cron or Airflow with logging and alerts.

Read in chunks with chunksize, load only needed columns, set efficient dtypes or switch to Dask, Polars or a database.

Start with KPIs (revenue, margin, growth), add trend and comparison to target, allow drill-down by region and product, keep it to one screen and test with the audience.

Dynamic array formulas such as FILTER, UNIQUE and SORT return several values that spill into neighbouring cells. #SPILL! appears when that spill range is blocked by existing data, merged cells, or when the formula sits inside an Excel Table, which does not allow spilling. Fix it by clearing the blocking cells, unmerging, or moving the formula outside the Table. Select the error cell to see the dashed border of the range it needs.

First switch calculation to manual to work safely, then find the cause. Replace whole-column references with Tables, swap repeated VLOOKUPs for one XLOOKUP or INDEX-MATCH helper column, and remove volatile functions like OFFSET, INDIRECT and TODAY used in many cells. Better still, move the joins into Power Query or the Data Model so lookups happen once at refresh. Finally paste values for historic data that never changes and keep formulas only where needed.

Separate input cells from calculation cells and colour inputs clearly. Unlock only the input cells through Format Cells, Protection, then protect the sheet so formulas cannot be edited, and optionally hide formulas. Add data validation on inputs to block wrong values such as negative quantities. Protect workbook structure so sheets cannot be deleted, keep a version history, and add a short instructions sheet so users know where to type.

Incremental refresh partitions a large table by date so that each refresh reloads only recent data, for example the last 7 days, while older partitions stay untouched. You create RangeStart and RangeEnd parameters, filter the table with them in Power Query, and set a policy such as store 5 years, refresh 7 days. Refresh becomes faster and lighter on the source. Query folding must work for the filter to be pushed to the database.

Inflated totals usually mean rows are being double counted through the many-to-many path. I would first check whether a proper dimension table can sit between them, turning it into two one-to-many relationships, for example a bridge table of unique customer IDs. I would set single filter direction, test totals against the source with a simple SQL query, and use measures with DISTINCTCOUNT where needed. Many-to-many should be a deliberate choice, not a default.

DIVIDE(numerator, denominator, alternate) handles division by zero or blank safely and returns blank or the alternate value you supply, so visuals do not show errors or infinity. The / operator returns an error or infinity in those cases. For example, DIVIDE([Profit], [Sales]) shows blank for a product with no sales. Use / only when you are certain the denominator can never be zero, because it is marginally faster.

The simplest way is a visual-level Top N filter on Product, by the Total Sales measure, set to 5; it recalculates for every slicer selection. If the number must be user selectable, create a numeric what-if parameter and a ranking measure using RANKX over ALLSELECTED(Product), then filter the visual where rank is less than or equal to the parameter. I would also add an Others row if the business wants totals to still match.

I would first agree on definitions: gross or net, including tax or returns, order date or invoice date. Then compare one small slice, such as one month and one region, in both. I check filters on the report and page, relationships that drop unmatched rows, refresh time versus the Excel extract time, and duplicate rows. Once the gap is explained, I document the definition in the report so the question does not repeat.

It warns that you may be modifying a temporary copy of a slice, so the change might not reach the original DataFrame, for example df[df.sales > 0]['flag'] = 1. Avoid it by using a single loc call, df.loc[df.sales > 0, 'flag'] = 1, or by calling .copy() when you intentionally create a new subset. Newer pandas versions with copy-on-write make behaviour more predictable, but clear loc assignments remain best practice.

First profile to find the slow step instead of guessing. Common fixes: replace row-wise apply and loops with vectorised operations, convert repeated strings to category dtype, downcast numeric types, read only needed columns with usecols, and filter early. Push heavy joins and aggregations into SQL. If it is still slow, use a columnar engine such as DuckDB or Polars, or store intermediate data as Parquet instead of CSV.

IN checks whether a value is in a list or subquery result; EXISTS checks whether a subquery returns at least one row and stops at the first match. Results are the same in most cases, and modern optimisers often run them similarly. The big difference is NOT IN with NULLs: if the subquery returns any NULL, NOT IN returns no rows. NOT EXISTS behaves correctly, so prefer it for anti-joins.

This is a join fan-out: an order has more than one matching payment row, for example split payments or retries, so each order line is repeated and sums are inflated. Check by counting rows per key on both sides. Fix it by aggregating payments to one row per order before joining, joining at the correct grain, or using the right key. Always compare row counts and totals before and after a join.

Define one primary metric, such as checkout conversion, plus guardrails like refund rate. State the hypothesis and minimum detectable effect, then calculate sample size and duration for chosen power and significance. Randomise users, not sessions, into control and variant, check the split is balanced, and run for full weeks to cover weekday patterns. Do not peek and stop early. Finally analyse with a proportion test and check key segments.

First confirm it is real: check tracking events, data delays and whether the denominator changed. Then segment by app version, platform, device, payment method and traffic source. If the drop is concentrated in the new version or one payment option, it points to a bug or UX change. Look at funnel steps to find where users drop. Compare with seasonality and campaigns, then share findings with product and engineering quickly.

State assumptions clearly. Of 1 crore people, assume 70 percent drink tea, so 70 lakh. Say half of their cups are bought outside, at an average of one bought cup per drinker every day for that half, giving about 35 lakh purchased cups, with more at offices and stations. So roughly 30 to 40 lakh cups. Interviewers judge the structure, segmentation and sanity check more than the exact number.

Clarify the goal first: profit, cash or market share. Build a store-level dataset with revenue, contribution margin after rent and staff, trend over 24 months, footfall, catchment demographics and cannibalisation with nearby stores. Separate structural losers from stores that are new or temporarily disrupted. Estimate how much revenue would shift to nearby stores or online if a store closes. Present a shortlist with scenarios and risks, not a single answer.

Not yet. Three days misses weekly patterns, and early results are often inflated by novelty effects or by stopping once the p-value looked good. I would check whether the planned sample size was reached, whether the split was balanced, and how guardrail metrics behaved. I would recommend running to the pre-planned duration, at least one or two full weeks, and then deciding, considering the cost of being wrong.

A context filter is applied before other dimension filters and before FIXED LOD calculations, creating a smaller dataset the rest of the view works on. Use it when a Top N filter should operate within a selected category, for example top 10 products within Electronics, or when a FIXED LOD must respect a filter. Add a filter to context from its right-click menu; it turns grey. Too many context filters can hurt performance.

Start with the Performance Recorder to see whether time goes into queries, calculations or rendering. Then reduce work: use an extract with only needed columns and rows, aggregate it to the dashboard's grain, and hide unused fields. Cut the number of sheets and high-mark-count views, replace many quick filters with fewer or with action filters, and avoid show only relevant values. Simplify heavy string and LOD calculations or move them to the database.

Usually it is the order of operations. FIXED LODs are computed before dimension filters, so they ignore a normal region filter, while other measures in the view respect it. That mix makes percentages and totals look inconsistent. Decide what the business wants: if the LOD should respect the filter, add the filter to context; if it should not, keep it and label it clearly, for example share of national sales.

I would ask what they do with it. If they export and work on it in Excel, a crosstab view with a download option or a scheduled extract is fine, and Tableau should not fight Excel. If they actually scan it for exceptions, I would suggest a summary view with highlights and a drill-down to the detail table. Often both: a short visual summary on top and the detailed table on a second tab.

First normalise: trim and lower-case names, collapse spaces, and strip country codes and symbols from phones and emails. Then match on strong keys such as phone or email. For remaining records use fuzzy matching on names with a similarity score, restricted to the same city or pin code to limit comparisons. Review borderline scores manually, keep a mapping from old IDs to a master ID, and fix entry at the source.

Find out which system or region produced each format, since a source column often explains it. Values with a day above 12 reveal the format unambiguously. Parse with an explicit format per source, for example pd.to_datetime(col, format='%d/%m/%Y', errors='coerce'), rather than letting the tool guess. Check failed or suspicious parses, such as future dates, and ask the source team to send ISO format yyyy-mm-dd going forward.

Reconcile against the source: compare row counts, total amount, and counts by day and by store between source and target. Check for duplicate keys, nulls in mandatory columns, and dates outside the expected month. Compare with the previous month to spot big unexplained jumps. Spot-check a few individual transactions end to end. Automate these checks so each future load produces a small pass or fail report.

Never add mixed units. Identify the unit for each row from a currency or unit column, or infer it from the source system. Convert to one standard, for example INR using a dated exchange rate table joined on transaction date, and kilograms using a conversion factor. Keep the original value and unit columns for audit. Document which rates were used, and flag rows where the unit could not be determined.

Orphan records are child rows whose foreign key has no matching parent, such as orders with a customer_id that does not exist in the customer table. They break joins silently: an inner join drops them and totals fall short. Find them with a LEFT JOIN from the child to the parent and filter where the parent key IS NULL. Then fix the source, add an Unknown member, or report them separately.

Agree a data contract with the vendor if possible. In the pipeline, normalise headers by trimming, lower-casing and replacing spaces, then map known variants to standard names through a lookup table you maintain. Validate that all required columns exist after mapping and fail with a clear message if not, instead of producing silent blanks. Select columns by name, never by position, and log any unexpected new columns for review.

This is an encoding mismatch: a UTF-8 file was read as a different encoding such as Latin-1 or Windows-1252. Re-read it with the right encoding, for example pd.read_csv(path, encoding='utf-8') or 'utf-8-sig' for files with a byte order mark, or set the file origin in Excel and Power Query import. Avoid re-saving through tools that change encoding, and agree on UTF-8 for all exchanges, especially for Hindi or other Indian language text.

Do not delete them blindly. First find out what they mean: often they are returns, cancellations or credit notes, which are valid business events. Check with the source team or a documentation note. If they are returns, keep them but report gross sales, returns and net sales separately. If some are clearly entry errors, such as a negative quantity on a new order, flag and correct them and log the rule.

Excel guessed the column was a number and dropped leading zeros; the same happens with long IDs turning into scientific notation. Identifiers that are not used in arithmetic should be stored as text. Import through Data, From Text/CSV or Power Query and set the column type to Text, or read it in pandas with dtype={'pincode': str}. To repair, use =TEXT(A2, "000000") when the original length is known.

I would ask which decisions each new visual supports and how often they will look at it. Usually a few are essential and the rest are nice to have. I would propose keeping the main page focused on core KPIs and moving detail into drill-through pages, tooltips or a separate analysis tab. Showing a quick mock-up of both versions helps them see that the cleaner page answers questions faster.

Core KPIs: headcount, monthly and annualised attrition rate, voluntary versus involuntary split, and early attrition within the first 90 days or first year. Breakdowns by department, location, manager, tenure band, performance rating and salary band show where it concentrates. Add hiring metrics such as time to fill and offer acceptance rate, and exit reasons from exit interviews. Protect privacy by hiding very small groups.

Volume and staffing: calls offered, answered, abandoned rate and average speed of answer. Efficiency: average handle time and occupancy. Quality and outcome: first contact resolution, customer satisfaction or CSAT score, and repeat contacts within 7 days. Service level, for example 80 percent of calls answered in 20 seconds, ties them together. Balance speed metrics with quality, otherwise agents rush calls to cut handle time.

Write a clear definition in a shared metric dictionary: formula, filters, time window, grain, owner and source table, for example a customer with at least one paid order in the last 90 days. Implement it once, in a governed dataset or semantic layer, and have all dashboards reuse it rather than recalculating. Version changes, announce them and show the definition in the dashboard tooltip. Review new metrics before they are published.

Start by listing both definitions: gross or net of returns and discounts, with or without tax, booking date or invoice date, and which entities are included. Compare at a detailed level for one region to find exactly where the difference arises. Usually both are correct for their purpose. Agree with both owners which is the official revenue KPI, rename the other clearly, such as booked sales, and document it in the metric dictionary.

Talk to the intended users before redesigning. Find out whether they know it exists, whether it answers their real questions, whether they trust the numbers, and whether it fits their routine. Common fixes are fewer, sharper KPIs, faster loading, a scheduled email snapshot, or embedding it in a meeting that already happens. Then measure usage again. Sometimes the honest answer is that the dashboard is not needed and can be retired.

Match refresh to how quickly decisions are made. A monthly board pack needs daily refresh at most, while a warehouse dispatch board may need 15-minute or live updates. Faster refresh costs more in source load, licensing and complexity, and can show incomplete data. Ask how quickly someone will act on a change, check when upstream systems finish loading, and always display the last refreshed time on the dashboard.

A good model is a governed core plus self-service on top. The central team builds certified datasets with agreed metric definitions and a small set of official dashboards for key KPIs. Business users then build their own views on those certified datasets, not on raw extracts. This gives speed and flexibility without twenty versions of revenue. Training, naming conventions and periodic clean-up of unused content keep it healthy.

A pie chart works only for showing parts of a whole with very few categories, two to four, where one share clearly dominates, such as 70 percent of orders are prepaid. Avoid it when there are many slices, when values are close, or when comparing across periods, because people judge angles poorly. A sorted bar chart is almost always easier to read and compare. Never use 3D pies.

Prepare carefully and stay factual. Share the finding early with the initiative owner privately so they are not surprised in a big meeting. Lead with the question asked, the method and the evidence, acknowledge limitations and what is working, and avoid blaming anyone. Offer options, such as fixing a specific step, narrowing the scope or stopping, with estimated impact. Bad news delivered with solutions is received far better.

Do not guess. Say clearly that you do not have that cut ready, restate the question to confirm it, and give a time by which you will reply, for example by end of day. If you know a partial answer or a reasonable expectation, share it with a caveat. Then follow up on time with a short, precise answer. Being honest and reliable builds more trust than a confident wrong number.

For the CEO, lead with the headline and money: churn rose 2 points, costing about 3 crore annually, mainly from one segment, with two recommended actions and their expected impact, all on one or two slides. For the support team, go deeper into drivers they control: ticket types, resolution times and specific customer pain points, with operational next steps and how progress will be tracked. Same data, different level and call to action.

Show ranges, not just a single number: a forecast line with a shaded prediction interval, or a statement like revenue will likely be between 48 and 55 crore, most likely 51. Explain the main assumptions and what would change the outcome, perhaps with best, base and worst scenarios. Use plain words such as likely or unlikely consistently. Hiding uncertainty makes a forecast look precise but leads to bad decisions when reality differs.

Stay respectful and focus on evidence, not opinions. Ask what they are seeing that leads to their view, as they may know context you lack. Walk through your method transparently, show the specific numbers, and test their hypothesis together on a cut they suggest. If the data still disagrees, present both views with their assumptions to the decision maker. Never adjust the analysis to fit a preferred answer.

Write the single key message first, then keep only slides that directly support it, usually three to five: the headline finding, the main driver, the impact in money, and the recommendation with next steps. Merge related charts, use action titles, and move everything else to an appendix for questions. Rehearse to fit in about seven minutes, leaving time for discussion, because the discussion is where decisions are made.

First agree the business rule: should a sale belong to the manager in charge on the sale date, or to the current manager? For history, track the manager on the store dimension as SCD Type 2, or keep a separate store-manager assignment table with start and end dates and join on the sale date. Add a current-manager attribute too, so both views are possible. Document the rule on the report.

Keep two fact tables at their natural grains: fact_sales at order line and fact_target at region-month. Never spread targets onto order lines. Both share conformed dimensions at a common level, such as a month attribute in the date dimension and region in the geography dimension. In reports, compare them only at month and region or higher. In Power BI, relate targets to month-level or region-level tables, not to daily keys.

These are late-arriving dimensions. Do not drop the orders, or revenue will be understated. Common practice is to insert a placeholder customer row with the natural key and 'Unknown' attributes, link the order to it, and update that row when full details arrive. Alternatively map to a single Unknown member with key -1. Also monitor how many such rows appear daily, because a spike usually means a broken feed.

Partition the table by date so the engine can prune partitions outside the filtered week, and cluster or sort by frequently filtered columns such as store or customer. Make sure the filter is on the partition column directly, not wrapped in a function like CAST or DATE_TRUNC that blocks pruning. Select only needed columns, because storage is columnar. For dashboards, also consider a pre-aggregated daily summary table.

A flat table is quick to start and fine for a small one-off analysis. But at scale it bloats the model because repeated text attributes compress poorly, makes DAX filters and time intelligence harder, and breaks when you add a second fact like targets or returns. I would show them a star schema with one fact and a few dimensions, compare model size and measure speed, and let the results convince them.

Use Go To Special and select Constants with Numbers to highlight hard-typed values inside formula areas. Show Formulas (Ctrl+`) to scan columns for inconsistencies, and use Trace Precedents and Dependents on key totals. Inquire or Spreadsheet Compare, if available, can flag inconsistent formulas. Then fix the overwritten cells, protect formula ranges and add check totals that compare with the source data each month.

Totals in DAX are not the sum of visible rows; the measure is recalculated in the total's filter context. A measure like a distinct count, a ratio or an IF condition can give a different result at total level. If the business wants the sum of row values, iterate explicitly, for example SUMX ( VALUES ( Product[Name] ), [My Measure] ). Confirm with stakeholders which total is correct before changing it.

SELECT DISTINCT often hides a real problem, such as a join on the wrong key or a one-to-many join that multiplies rows. The output looks clean, but sums computed before the DISTINCT, or legitimate repeated rows, can be wrong, and DISTINCT adds a costly sort on large tables. Instead, find why duplicates appear, fix the join or aggregate the child table first, and add a uniqueness test on the key.

This is a sample ratio mismatch. A chi-square test on these counts gives a tiny p-value, so the gap is not chance. Something is filtering users unevenly, such as the treatment page crashing on some devices, a redirect losing tracking, bots in one arm or a bug in assignment. The results cannot be trusted until the cause is found. Check splits by browser, platform and day to locate it.

Look at the metric that reflects business value, such as revenue or margin per visitor, which combines both effects. Here revenue per visitor is roughly 1.03 times 0.95, about 2% lower, so the change may hurt. Check whether the drop is significant, which segments drive it, and whether new buyers are making smaller first orders that grow later. Without a strong reason, I would not ship it as is.

Not straight away. Slicing results into many segments makes a chance finding likely, so this is a hypothesis, not a conclusion. Check whether the segment was planned in advance, how many segments were examined, and whether there is a plausible reason, such as slower networks benefiting from a lighter page. If it still looks promising, run a follow-up test targeted at that segment with enough sample to confirm it.

I would explain that early results swing a lot and stopping on a good day inflates false positives, and that four days miss weekly patterns like weekend shopping. I would show how the lift has moved day by day and agree to the planned end date. If speed really matters, we can agree a sequential testing rule for future tests, but changing the rule mid-test after seeing data is not valid.

A flat result is still useful. Report the observed difference with its confidence interval, for example -0.3% to +0.8%, which shows the range of effects still possible. State whether the test had enough power for the planned MDE. If it did, conclude that any effect is probably small and the team can choose based on cost or simplicity. Share learnings so the same idea is not retested blindly.

With 1,000 per group and a typical click rate of 3%, only a very large difference, roughly 70% relative or more, would be detectable, so a small real lift would look like noise. I would suggest testing on a larger send, pooling several campaigns, or using open-to-click rate with a bigger effect. If they still run it, report the confidence interval and treat the result as directional.

An average can improve while the tail gets worse. I would look at the distribution: median, 90th and 95th percentiles and the share of orders beyond the promised time. Then break it down by city, time slot and restaurant to see where late orders cluster. Also check whether promised times changed, whether complaint tracking changed and whether a few very fast orders pulled the mean down.

Click the unknown indicator at the bottom right of the map and choose Edit Locations. Usually Tableau cannot match names because of spelling variants, such as 'Bengaluru' versus 'Bangalore', or an ambiguous city that needs the state and country set. Make sure fields have the correct geographic role, add a country or state field to the view, clean names in the data source, or use latitude and longitude columns.

Convert timestamps to the business time zone before deriving the date. IST is UTC plus 5 hours 30 minutes, so an order at 20:00 UTC belongs to the next day in IST. In SQL use AT TIME ZONE or CONVERT_TZ, and in pandas use tz_localize('UTC') followed by tz_convert('Asia/Kolkata'). Store raw UTC, add a local date column in the model, and document which one each report uses.

First check whether it is a tracking problem: did the analytics tag break on some templates, did consent settings change, does server log or backend order data show the same fall? If the drop is real, check the search console for impressions and rankings, recent site releases such as changed URLs, missing redirects, noindex tags or robots.txt changes, and whether a search algorithm update or seasonal pattern matches. Then break the drop down by page group.

This is very likely bot or spam traffic, or a misfiring tag. Check the user agents, IP ranges, hostnames, screen resolutions and landing pages for that traffic. If it is bots, exclude it with filters or data segments in analytics and in your reporting layer, and inform the web team so they can block it. Then restate the affected dashboard numbers, because bots inflate sessions and pull down conversion rate.

The order database is the source of truth for counts and revenue. Analytics usually undercounts because of ad blockers, declined cookie consent, users closing the page before the confirmation tag fires, and payment redirects that break sessions. It can also overcount from duplicate tags on page refresh. Quantify the gap per month; if it is stable around 15%, use analytics for channel mix and trends and the database for totals.

Direct is the default bucket when the source is unknown, so a jump usually means attribution broke. Common causes are redirects that strip UTM parameters, a new referrer policy hiding the referring site, the analytics tag missing on landing pages so sessions start later on the site, payment or login domains not added to the cross-domain or referral exclusion list, and HTTPS to HTTP transitions. Compare landing pages and campaign traffic before and after.

Brand search ROAS is usually inflated because people searching the brand name were already looking for you and would often click the free organic result anyway. Before increasing spend, I would propose an incrementality test, such as pausing brand ads in some matched cities or time periods and measuring the drop in total brand-search orders. The incremental ROAS is often far lower, so the extra budget may work better elsewhere.

Check the components: sessions may have fallen, for example after cutting paid campaigns, which removes low-intent traffic and lifts the rate without new sales. Average order value may have dropped because of discounts or a mix shift towards cheaper products. Also check whether conversion definitions or tracking changed. Revenue equals sessions times conversion rate times AOV, so break down the change across those three factors by channel.

I would compare channels on incremental return, not last-click ROAS. Gather spend, attributed conversions under two models, customer quality such as repeat rate and margin, and any lift test or mix model results. Look at diminishing returns: the last rupee in a saturated channel is worth less than the average. Then recommend cutting where marginal return is lowest, ideally phased with a holdout to confirm the impact.

Check traffic quality first: is the right audience coming, and does the ad message match the page? Then look at page behaviour by device: load time, scroll depth, form start versus form submit, and which form field users abandon. Session recordings or heatmaps help. Test the form on mobile for errors. Common fixes are faster pages, fewer form fields, a clear call to action above the fold and matching the ad's offer.

No. Privacy features in some mail apps pre-load email images, which fires the open tracking pixel even if the person never reads the email, so open rates get inflated. Check opens by email client to confirm. Move reporting towards clicks, click-to-send rate, conversions and unsubscribes, which reflect real behaviour, and avoid using opens alone to pick winning subject lines or to define engaged subscribers.

Lead with the fact clearly, then show where the gap came from, such as which regions, products or deal stages, so it becomes actionable rather than a blame session. Separate controllable causes like lower conversion from uncontrollable ones like a delayed product launch. Highlight what did work, and end with two or three specific actions and the metrics to track them. Share the numbers with sales leaders privately first, to avoid surprises.

First check the data: did the refresh load duplicate rows, did a filter or definition change, did late data from the previous day arrive, or did a new source or currency get added? Compare the raw count with the source system. Then check business reasons, such as a big promotion, a bulk order or a holiday. Only after the number is confirmed should it be communicated, with the reason attached.

order_date is probably a DATETIME or TIMESTAMP column, so the filter matches only rows at exactly midnight, 2026-03-31 00:00:00. Use a half-open range instead: WHERE order_date >= '2026-03-31' AND order_date < '2026-04-01'. This keeps the index usable, unlike wrapping the column in CAST or DATE(), and it correctly includes orders at 23:59:59.500. Also check the time zone of the stored timestamps.

Add logging to a file or central log, wrap the main steps in try and except that send an alert by email or chat on failure, and exit with a non-zero code so the scheduler marks the job failed. Add data checks, such as row counts above a minimum and no missing dates, before sending output. Use a proper scheduler or orchestrator with retries, and include the data date in every report.

Open the semantic model's refresh history in the Service to see whether refreshes failed, for example due to expired credentials, an offline gateway or a timeout. Check whether the report is connected to a different copy of the model, whether the source itself was updated, and whether incremental refresh only covers some partitions. Also confirm the schedule time zone. Finally, add a 'data as of' timestamp on the report.