Analytics

I need to combine these redacted tables [data] for [purpose]. Column meanings and approved identifiers are [definitions]. Propose a join key and show duplicate, missing and conflicting IDs before merging. Do not match people by a similar name or email guess. Produce a separate unresolved-match list, counts before and after, and a sample reconciliation showing whether rows multiplied. Keep source values traceable and do not overwrite either original. Ask who can resolve disputed identities before any combined list is used operationally.

Make it yours: Use pseudonymous stable identifiers; keep personal data out of examples.

Here is my redacted daily sales export [data], date range [range], opening calendar [calendar] and export definitions [definitions]. Identify missing dates, explicit zero rows, closed days and partial records separately. Do not fill an absent day with zero or invent transactions. Show how each treatment changes totals and averages, using only justified values, and leave unresolved dates in a review table. Return questions for the data owner and ask whether the intended metric covers calendar days or trading days before calculating a daily average.

Make it yours: A blank date in an export is not evidence that nothing happened.

Here are the dashboard total [value and definition], redacted detail export [rows], filters [settings], refresh times [times] and status rules [definitions]. Reconcile the reported total with the included rows, testing dates, cancellations, duplicates and currency only where the supplied data allows. Do not silently change the definition to make numbers agree or invent missing orders. Show intermediate sums and an unresolved-difference table. Ask which source is the approved reporting basis before drafting a correction request; leave original data unchanged.

Make it yours: Record refresh time and filters; apparently matching date ranges can still differ.

Here are redacted rows from my imported sheet [data], original file format [format], locale settings [settings] and a few independently confirmed dates [examples]. Identify unambiguous dates, impossible dates and values that could mean day-month or month-day. Do not choose an interpretation merely because the software parsed it. Keep original strings and propose a separate normalised column only for confirmed rules. Return an ambiguity report and validation examples. Ask which source system or owner can confirm the date convention before calculating monthly totals.

Make it yours: Values such as 03/04 need source context; successful parsing does not prove the intended date.

Here are redacted traffic exports [data], definitions [definitions], dates [dates] and a verified internal-visit flag approved by the data owner [field or none]. Show totals with and without only those confirmed internal visits, preserving the inclusion rule across periods. Do not identify employees from browsing patterns, invent bot classifications or assume all short visits are irrelevant. If no reliable flag exists, explain the limitation instead of filtering by intuition. Return a reconciliation and ask what question the adjusted metric is intended to answer before interpreting it.

Make it yours: Use approved aggregate flags; do not expose IP addresses or individual browsing histories.

Here are synthetic or redacted order and return tables [data], field definitions [definitions], the reporting rule agreed by our analyst/accountant [rule] and periods [dates]. Trace matched returns to original orders using supported identifiers, keeping order date, return date and reporting period separate. Do not invent matches or accounting rules, delete records or infer fraud. Return a reconciliation with unmatched lines and scenario totals only where authorised. Ask which date determines the report's treatment before recalculating it.

Make it yours: The data owner must confirm how the report treats returns across periods.

Here is a synthetic or redacted export [data], documented locale, currency and column definitions [facts], plus sample values confirmed by the data owner [examples]. Identify possible decimal/thousands-separator issues and propose a transformation on a copy with before-and-after checks. Do not guess ambiguous formats, overwrite originals or treat punctuation removal as universally correct. Reconcile known samples and totals separately. Ask which value has a verified intended meaning before selecting a parsing rule.

Make it yours: Use confirmed examples and preserve raw data for review.

Here are anonymised survey counts or permitted aggregate rows [data], actual question routing and definitions [text]. Separate asked, answered, skipped and not-applicable responses for each question. Show denominators beside percentages and do not assume a blank means no, invent respondent intent or merge different routing groups. Return a transparent summary and data-owner questions. Ask which participants were never shown the question before calculating its response rate.

Make it yours: Use aggregate data where possible and retain the questionnaire's actual routing logic.

Here is a redacted export with original column positions, repeated headers and its supplied data dictionary [material]. Identify columns whose labels are identical but whose documented meanings differ. Propose an explicit old-position-to-new-label map for owner approval before creating a chart or formula. Do not silently merge columns, choose a total by position alone or invent missing definitions. Ask which repeated header feeds my intended calculation before prioritising clarification.

Make it yours: Keep the original column order in the audit so repeated labels remain distinguishable.

Here are the original counts, denominators, displayed percentages and rounding convention [table and rules]. Recalculate only from those supplied inputs, showing exact fractions and the rounded display separately. Identify whether a displayed total differs because of rounding or because the underlying categories overlap or omit cases. Do not force figures to add up by changing data. Ask whether the categories are meant to be mutually exclusive before proposing a presentation note.

Make it yours: Keep the underlying counts available when presenting rounded percentages.

Average order value rose, but ordinary orders seem smaller. Here is anonymised order data [data], column definitions [definitions], period [dates] and treatment of returns, tax and currency [rules]. Check whether rows are orders or order lines before calculating. Compare count, total, mean, median and a defined distribution. Keep legitimate large orders in the main result; label any sensitivity calculation separately. Flag incomplete periods and missing values. Do not infer motives or call valid orders errors because they are unusual. Show reproducible calculations, not invented results.

Make it yours: State whether each row is an order or an order line.

Analyse this sales export for [months]. First check column meanings, currency, missing rows, refunds and whether months have comparable coverage. Break the change down by order count, average order value and product where the data allows. Show reproducible calculations and reconcile to the totals. Separate observed contributions from possible causes; do not claim a campaign caused the change without evidence. End with three checks I should make in our systems.

Make it yours: Remove customer identifiers and include export filters and metric definitions.

Can I compare the sales total in Export A with Export B? Here are both files and their definitions [files]. Check dates, time zones, currencies, refunds and whether each row is an order, an order line or a payment. Show which totals can be compared and which need clarification. Do not silently change the definitions to make them match or guess why sales changed.

Make it yours: Provide the export settings and a known total from each system if available.

Explain this chart for [audience] and [decision]. Read the axes, units, period and annotations first. Distinguish what is visible from a causal interpretation. Identify missing context and potentially misleading scale choices. Draft a concise caption that preserves the important caveat.

Make it yours: Supply the underlying data if calculations are required.

Our support team wants to know whether service is improving. We can record [available data] and need to decide [staffing or process decision]. Propose a small set of measures with plain-language definitions, time period and calculation examples clearly labelled fictional. Explain how a faster reply could still leave a customer unresolved. List missing data and do not claim improvement before we measure it.

Make it yours: Explain what action the team could take if a measure changes.

Inspect this spreadsheet before calculating [total I need]. Explain what each row represents, what each column means, the units used and how a record can be identified. Flag missing values and possible duplicates. Separate definitions I supplied from your guesses. Ask about anything that could change the total before calculating it. Return a plain-language table of columns, meanings and questions.

Make it yours: Tell the assistant whether the export contains orders, order lines, invoices or payments.

Using [confirmed metric definition], calculate the total for [period] from this export and reconcile it with [source-system total]. Show filters, exclusions and steps. Investigate discrepancies using available records. Do not change definitions simply to force a match. Return unresolved differences separately.

Make it yours: Include the timezone, currency and treatment of refunds.

Analyse the change in [revenue or average value] between [periods]. Where the data supports it, separate volume, product mix and unit-value effects. Show definitions and calculations. Identify alternative explanations that cannot be tested from these fields. Do not describe association as a causal finding.

Make it yours: Provide consistent product identifiers and explain changes in the export structure.

Inspect this dashboard and the supplied metric definitions. Identify where chart titles, axes, periods or denominators could mislead a reader making [decision]. Separate visible presentation issues from calculations that cannot be verified from the screenshot. Suggest the smallest clarification for each issue.

Make it yours: A screenshot alone cannot establish whether the underlying calculation is correct.

Inspect this spreadsheet before drawing conclusions about [question]. Report sheets, row counts, field types, missing values, duplicates and inconsistent units. Identify date coverage and the unit represented by a row. Propose cleaning decisions for review and keep the original data unchanged. Then suggest analyses the available fields can actually support.

Make it yours: State what each row should represent and provide a data dictionary if one exists.

Use these Search Console and analytics exports to investigate the change between [periods]. Check date coverage and metric definitions first. Break changes down by page, query, device and country where those dimensions are available. Distinguish fewer impressions, lower click-through rate and position changes. Show the largest contributors with calculations and label possible causes as hypotheses.

Make it yours: Use comparable date ranges. A correlation in these exports alone does not prove the cause.

Before I analyse why sales changed, review my plan [plan] and the available fields [list]. Check whether the periods, currencies, refunds and product groups are comparable. Identify missing definitions and other explanations the data may not distinguish. Rank three checks to do first and explain them in plain language. Do not calculate from data I have not supplied or turn a correlation into proof of a cause.

Make it yours: State the business decision the analysis should help make.