📊260 prompts · 13 categories

The Data Analyst Prompt Pack

260 data analyst prompts to turn raw data into decisions.

Cleaning, exploration, SQL, spreadsheets, metrics, dashboards, forecasting and data storytelling — the full analytics workflow, prompt by prompt.

Get all 260 prompts — free

Drop your email and the full library unlocks instantly.

No spam. Instant access. Unsubscribe anytime.

  • 260 copy-paste prompts across 13 categories
  • Works with ChatGPT, Claude & Gemini
  • From SQL and cleaning to dashboards and stakeholder reporting

Joined by 5,200+ founders & marketers

260 prompts

#001Business Goal to Analysis Objective Converter

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, business analysts, product analysts, founders, operations managers, marketing teams, finance teams, and anyone starting analysis from an unclear business request.

Turn a broad business goal into a clear data analysis objective, decision context, success metric, and practical analysis scope.

You are a senior data analyst who connects business goals to practical analytical work. Convert the business goal below into a clear analysis objective that can guide a real data project. Business context: Company or project: [COMPANY / PROJECT] Industry: [INDUSTRY] Business goal: [BUSINESS GOAL] Current situation: [CURRENT SITUATION] Business problem: [PROBLEM] Stakeholders: [STAKEHOLDERS] Decision that needs to be made: [DECISION] Available data sources: [DATA SOURCES] Timeframe: [TIMEFRAME] Constraints: [CONSTRAINTS] Known assumptions: [ASSUMPTIONS] Expected output: [REPORT / DASHBOARD / PRESENTATION / MODEL / RECOMMENDATION] Convert the goal into an analysis plan: 1. Business goal clarification Rewrite the goal in clearer business language. Identify: - what the business wants to improve - why it matters now - who is affected - what decision depends on the analysis - what outcome would count as success 2. Analysis objective Create: - one primary analysis objective - 3 to 5 supporting analysis objectives - what is in scope - what is out of scope - what the analysis will not prove 3. Decision connection Explain how the analysis will support a decision. Include: - decision owner - decision options - data needed to compare options - risks of making the decision without analysis - deadline for decision 4. Success metrics Define: - primary metric - secondary metrics - guardrail metrics - leading indicators - lagging indicators - data quality requirements 5. First analysis questions Create 10 specific questions the analysis should answer. For each question include: - business reason - data needed - likely method - expected output - stakeholder value 6. Final project brief Write a concise analyst-ready brief with: - objective - business context - scope - metrics - data sources - deliverable - timeline - open questions Rules: - Do not start with charts before defining the decision. - Do not create vanity metrics that do not affect action. - Do not assume the business goal is already well-defined. - The final output must make the analysis useful for real business decisions. --------------------------------------------------------------------------------

#002Stakeholder Decision Needs Interview Script

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, BI analysts, analytics managers, consultants, product teams, operations teams, and anyone gathering requirements before analysis.

Create a structured stakeholder interview that reveals decision needs, expectations, constraints, definitions, metrics, risks, and what “useful analysis” means.

Act as a business-focused data analyst preparing for a stakeholder discovery call. Build an interview script that helps me understand what analysis is actually needed. Stakeholder context: Stakeholder name or role: [STAKEHOLDER] Department: [DEPARTMENT] Business area: [BUSINESS AREA] Initial request: [REQUEST] Known business problem: [PROBLEM] Expected deliverable: [DELIVERABLE] Deadline: [DEADLINE] Available data: [DATA] Current reports or dashboards: [CURRENT REPORTS] Known tension or disagreement: [TENSION] Create the interview system: A. Opening Write a short opening script that sets expectations and keeps the conversation business-focused. B. Decision questions Create questions to uncover: - what decision the stakeholder needs to make - what options they are considering - what happens if no decision is made - how urgent the decision is - who approves or uses the result C. Metric questions Create questions to clarify: - key metrics - metric definitions - current baseline - target level - acceptable tradeoffs - guardrail metrics D. Context questions Ask about: - business process - customer or user behavior - operational constraints - market context - seasonality - recent changes - known data issues E. Deliverable questions Ask about: - report format - dashboard needs - level of detail - audience - update frequency - expected recommendation style F. Risk questions Ask what could make the analysis misleading, incomplete, ignored, or politically sensitive. G. Closing script Create a closing summary template that confirms: - decision - objective - metrics - scope - timeline - next steps - unresolved questions Rules: - Do not accept “we just need insights” as a sufficient requirement. - Do not ask only technical data questions. - Do not assume the stakeholder knows the right metric. - The interview must convert vague demand into a decision-ready analysis brief. --------------------------------------------------------------------------------

#003Analysis Question Quality Refiner

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, BI teams, product analysts, marketing analysts, finance analysts, students, consultants, and teams improving analytics requirements.

Transform vague, broad, or poorly framed data questions into precise, answerable, decision-connected analytical questions.

You are an analytical question editor. Improve the data questions below so they are specific, measurable, answerable, and connected to business decisions. Raw questions: [PASTE QUESTIONS] Business context: Business area: [BUSINESS AREA] Stakeholders: [STAKEHOLDERS] Decision to support: [DECISION] Available data sources: [DATA SOURCES] Time period: [TIME PERIOD] Business goal: [GOAL] Current concern: [CONCERN] Constraints: [CONSTRAINTS] Refine the questions: 1. Question diagnosis For each raw question, classify the problem: - too vague - not decision-connected - no metric - no timeframe - no segment - no comparison group - not answerable with available data - asks for causation without design - mixes multiple questions - unclear business value 2. Rewritten question Rewrite each question into a stronger version. Each rewritten question must include: - metric - segment - timeframe - comparison - business purpose - expected action 3. Analysis type For each rewritten question, identify the analysis type: - descriptive - diagnostic - comparative - trend - segmentation - cohort - funnel - forecasting - causal investigation - prioritization 4. Data needs List required data fields, filters, joins, and quality checks. 5. Decision use Explain how the answer would change a decision. 6. Final question set Create a prioritized list of the best 10 analysis questions. Rules: - Do not treat every question as equally valuable. - Do not ask for causality if the data can only support correlation. - Do not produce questions that cannot be answered with available data. - Every final question must be useful for a business decision. --------------------------------------------------------------------------------

#004Business Metric Definition Framework

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, BI teams, product managers, finance teams, marketing teams, RevOps, operations leaders, and analytics governance.

Define business metrics clearly so teams agree on formulas, data sources, filters, interpretation, ownership, and decision use.

Act as a metrics definition specialist. Create a complete metric definition framework for [METRIC / KPI]. Metric context: Metric name: [METRIC] Business area: [AREA] Why the metric matters: [WHY] Stakeholders: [STAKEHOLDERS] Current definition, if any: [CURRENT DEFINITION] Data sources: [DATA SOURCES] Reporting frequency: [FREQUENCY] Decision use: [DECISION USE] Known disagreements: [DISAGREEMENTS] Known data issues: [DATA ISSUES] Build the metric definition: A. Metric purpose Explain: - what the metric measures - what it does not measure - why the business needs it - what decision it supports B. Exact formula Define: - numerator - denominator - calculation logic - filters - exclusions - time window - aggregation level - rounding rules C. Data lineage Map: - source systems - tables or reports - required fields - joins - refresh timing - known limitations - data owner D. Interpretation guide Explain: - what increase means - what decrease means - what normal variation may look like - what could create false movement - what segments should be checked E. Guardrails Define related metrics that prevent bad decisions. F. Governance Create: - metric owner - review cadence - change request process - documentation template - stakeholder approval checklist Rules: - Do not define a metric with vague words like “active” or “quality” without exact rules. - Do not create formulas that different teams can interpret differently. - Do not let one KPI stand alone without guardrails. - The metric definition must be precise enough for dashboard, SQL, and executive reporting. --------------------------------------------------------------------------------

#005KPI Tree and Business Driver Map

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, strategy teams, product teams, finance teams, growth teams, operations teams, founders, and analytics leaders designing measurement systems.

Build a KPI tree that connects top-level business outcomes to drivers, sub-drivers, operational metrics, and actionable levers.

You are a business analytics strategist. Build a KPI tree and driver map for [BUSINESS GOAL]. Business context: Company or product: [COMPANY / PRODUCT] Business model: [BUSINESS MODEL] Primary business goal: [GOAL] Revenue model: [REVENUE MODEL] Customer journey: [CUSTOMER JOURNEY] Main departments involved: [DEPARTMENTS] Current KPIs: [CURRENT KPIS] Known business constraints: [CONSTRAINTS] Decision horizon: [TIMEFRAME] Create the KPI tree: 1. North star outcome Define the highest-level business outcome. Explain: - why it matters - how it connects to strategy - what behavior it should encourage - what behavior it should not encourage 2. Driver breakdown Break the outcome into 3 to 6 major drivers. Examples: - acquisition - activation - retention - monetization - efficiency - quality - satisfaction - capacity - risk 3. Sub-driver metrics For each major driver define: - metric - formula - business meaning - team owner - action lever - data source - reporting frequency 4. Leading and lagging indicators Separate: - leading indicators - lagging indicators - input metrics - output metrics - guardrail metrics 5. Action map Connect each metric to possible actions. 6. Risk review Identify where the KPI tree could create bad incentives or misleading conclusions. Rules: - Do not create a flat list of disconnected KPIs. - Do not select metrics that no team can influence. - Do not optimize one metric in a way that damages another. - The KPI tree must help teams understand what actually drives the business outcome. --------------------------------------------------------------------------------

#006Data Availability and Feasibility Audit

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, BI teams, analytics managers, consultants, product teams, operations teams, and anyone scoping analysis before promising results.

Check whether a business question can actually be answered with available data and identify gaps, proxies, limitations, and collection needs.

Act as a data feasibility auditor. Determine whether the analysis request below can be answered with available data. Analysis request: [PASTE REQUEST] Business context: Business question: [QUESTION] Decision to support: [DECISION] Available data sources: [DATA SOURCES] Known tables or files: [TABLES / FILES] Time range available: [TIME RANGE] Data granularity: [GRANULARITY] Known missing data: [MISSING DATA] Data quality concerns: [CONCERNS] Deadline: [DEADLINE] Stakeholder expectation: [EXPECTATION] Run the feasibility audit: A. Answerability rating Classify the request as: - directly answerable - answerable with assumptions - answerable with proxy metrics - partially answerable - not answerable with current data B. Required data map List: - required entities - required fields - required time range - required joins - required filters - required definitions C. Gap analysis Identify missing or weak data. For each gap include: - why it matters - possible proxy - risk of using proxy - collection method - impact on confidence D. Analysis limitations Write a clear limitations section for stakeholders. E. Revised feasible question Rewrite the business question into the strongest version that current data can support. F. Recommendation Explain whether to proceed, delay, collect more data, or change scope. Rules: - Do not promise precision the data cannot support. - Do not hide limitations. - Do not use proxy metrics without explaining risk. - The final answer must protect trust between analyst and stakeholder. --------------------------------------------------------------------------------

#007Stakeholder Alignment Analytics Brief

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, consultants, analytics leads, BI teams, product teams, cross-functional projects, executive reporting, and teams that need agreement before analysis work starts.

Create a one-page analytics brief that aligns stakeholders on the problem, decision, metrics, scope, assumptions, deliverable, and timeline before analysis begins.

You are an analytics project lead. Create a stakeholder alignment brief for the analysis project below. Project context: Project name: [PROJECT NAME] Business problem: [PROBLEM] Primary stakeholder: [PRIMARY STAKEHOLDER] Other stakeholders: [OTHER STAKEHOLDERS] Decision to support: [DECISION] Business goal: [GOAL] Timeline: [TIMELINE] Data sources: [DATA SOURCES] Expected deliverable: [DELIVERABLE] Known assumptions: [ASSUMPTIONS] Known risks: [RISKS] Requested by: [REQUESTER] Create the brief: 1. Executive summary Write a short summary of what this analysis will do and why it matters. 2. Decision statement Define: - decision owner - decision deadline - options under consideration - decision criteria - what data will influence the decision 3. Analysis scope Define: - in scope - out of scope - assumptions - dependencies - limitations 4. Metrics and definitions List: - primary metric - secondary metrics - guardrails - required definitions - unresolved metric questions 5. Deliverable plan Specify: - final output format - audience - level of detail - update frequency, if recurring - review process 6. Open questions List what must be clarified before analysis begins. 7. Approval checklist Create a stakeholder sign-off checklist. Rules: - Do not begin analysis before scope and decision are clear. - Do not bury assumptions. - Do not let every stakeholder define success differently. - The brief must be short enough to review but specific enough to prevent rework. --------------------------------------------------------------------------------

#008Decision-First Analytics Framework

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, strategy analysts, product analysts, finance analysts, growth teams, operations teams, founders, and executive decision support.

Design an analysis around a specific business decision instead of exploring data randomly or producing disconnected insights.

Act as a decision-first analytics advisor. Build an analysis framework around the business decision below. Decision context: Decision to make: [DECISION] Decision owner: [OWNER] Deadline: [DEADLINE] Options available: [OPTIONS] Business goal: [GOAL] Risks: [RISKS] Stakeholders: [STAKEHOLDERS] Current evidence: [EVIDENCE] Data available: [DATA] Constraints: [CONSTRAINTS] Build the framework: A. Decision framing Clarify: - what decision is actually being made - what is not being decided - why now - what happens if the decision is delayed - what would make a recommendation credible B. Decision criteria Create decision criteria such as: - revenue impact - cost impact - customer impact - operational feasibility - risk - speed - strategic fit - confidence level C. Evidence plan For each decision criterion define: - metric - data source - analysis method - minimum evidence needed - risk of misinterpretation D. Analysis structure Create the analysis sections in the order decision-makers need: - current state - option comparison - tradeoff analysis - risk analysis - sensitivity analysis - recommendation - next steps E. Recommendation logic Create a recommendation template with: - recommended option - reason - supporting evidence - tradeoffs - confidence level - what to monitor after decision Rules: - Do not produce insights that do not affect the decision. - Do not pretend the analysis can remove all uncertainty. - Do not recommend an option without explaining tradeoffs. - The output must help the decision-maker act. --------------------------------------------------------------------------------

#009Business Assumptions and Risk Register

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, business analysts, strategy teams, product teams, consultants, finance analysts, operations analysts, and teams working with incomplete data.

Identify assumptions behind an analysis, test which ones matter, and document risks that could affect interpretation or decision quality.

You are an analytical risk manager. Build an assumptions and risk register for the analysis below. Analysis context: Business question: [QUESTION] Business goal: [GOAL] Decision to support: [DECISION] Data sources: [DATA SOURCES] Known limitations: [LIMITATIONS] Stakeholders: [STAKEHOLDERS] Deadline: [DEADLINE] Expected recommendation: [EXPECTED RECOMMENDATION] Uncertain areas: [UNCERTAINTIES] Create the register: 1. Assumption inventory List assumptions across: - business process - customer behavior - data completeness - metric definitions - time period - segment selection - attribution - seasonality - external factors - data quality - stakeholder interpretation 2. Assumption scoring For each assumption include: - assumption - why it matters - evidence supporting it - evidence missing - impact if wrong - likelihood of being wrong - test method - owner - status 3. Risk register Identify risks such as: - misleading metric - biased sample - incomplete data - wrong comparison group - overgeneralization - causation claim risk - stakeholder misuse - outdated data - dashboard misinterpretation 4. Mitigation plan For each major risk create: - mitigation action - limitation wording - confidence label - decision warning - follow-up analysis 5. Stakeholder note Write a concise explanation of the most important risks in plain business language. Rules: - Do not hide uncertainty to make the analysis look stronger. - Do not treat all assumptions as equally important. - Do not make causal claims without appropriate evidence. - The register must improve decision quality and analytical trust. --------------------------------------------------------------------------------

#010Analytics Prioritization Matrix

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData teams, analytics managers, BI teams, solo analysts, consultants, product analysts, RevOps, finance teams, and anyone managing too many data requests.

Prioritize analysis requests based on business impact, urgency, stakeholder value, data readiness, effort, risk, and decision importance.

Act as an analytics prioritization lead. Rank the analysis requests below and decide what should be done first. Requests: [PASTE REQUEST LIST] Team context: Analytics capacity: [CAPACITY] Business goals: [GOALS] Stakeholders: [STAKEHOLDERS] Current deadlines: [DEADLINES] Data readiness: [DATA READINESS] Strategic priorities: [PRIORITIES] Known recurring reports: [REPORTS] Urgent fire drills: [FIRE DRILLS] Build the prioritization system: A. Scoring criteria Create a score from 1 to 5 for: - decision importance - business impact - urgency - stakeholder reach - data readiness - effort required - reusability - risk reduction - strategic alignment - confidence in value B. Request scoring table For each request include: - request summary - stakeholder - decision supported - impact score - urgency score - effort score - data readiness score - total priority score - recommendation C. Priority categories Classify requests as: - do now - schedule next - clarify first - automate or template - delegate - reject or deprioritize - combine with another request D. Stakeholder communication Write messages for: - accepted request - delayed request - request needing clarification - deprioritized request - request that should become a dashboard E. Operating rule Create rules for handling new requests without chaos. Rules: - Do not prioritize based only on who asks the loudest. - Do not accept requests without decision context. - Do not spend high effort on low-impact reporting. - Prioritization must protect analyst time and maximize business value. --------------------------------------------------------------------------------

#011Business Process Understanding Map

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, BI analysts, operations analysts, product analysts, finance analysts, consultants, and anyone analyzing data from complex workflows.

Understand the real business process behind the data so analysis reflects how work, customers, systems, and decisions actually happen.

You are a business process analyst supporting data analysis. Build a process understanding map before analyzing the data. Business process context: Process name: [PROCESS] Business area: [AREA] Stakeholders involved: [STAKEHOLDERS] Systems used: [SYSTEMS] Data generated: [DATA] Current problem: [PROBLEM] Decision to support: [DECISION] Known process exceptions: [EXCEPTIONS] Known data issues: [ISSUES] Time period: [TIME PERIOD] Map the process: 1. Process overview Explain the process in plain business language. 2. Step-by-step flow For each process step include: - step name - owner - trigger - action - system used - data captured - possible delay - possible error - business meaning 3. Data creation map Show where each key data field is created, updated, or lost. 4. Exception handling Identify: - manual workarounds - skipped steps - late entries - duplicate records - cancellations - rework - approvals - edge cases 5. Analysis implications Explain how the process affects: - metric definitions - filters - joins - time windows - segment logic - data quality - interpretation 6. Questions for stakeholders Create 15 questions to confirm the process map. Rules: - Do not analyze data without understanding how it is generated. - Do not assume system timestamps equal real-world events. - Do not ignore manual exceptions. - The process map must prevent wrong conclusions from misunderstood data. --------------------------------------------------------------------------------

#012Success Metrics and Guardrails Designer

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, product managers, growth teams, marketing teams, operations leaders, finance teams, founders, and experiment owners.

Create a balanced measurement framework that includes success metrics, guardrails, tradeoffs, segments, and decision thresholds.

Act as a measurement strategy expert. Design success metrics and guardrails for [INITIATIVE / PROJECT / DECISION]. Initiative context: Initiative name: [INITIATIVE] Business objective: [OBJECTIVE] Target audience or segment: [SEGMENT] Expected change: [CHANGE] Decision owner: [OWNER] Time horizon: [TIME HORIZON] Available data: [DATA] Risks or tradeoffs: [RISKS] Current baseline: [BASELINE] Target result: [TARGET] Build the measurement framework: A. Primary success metric Define: - metric name - formula - reason it matters - expected direction - baseline - target - timeframe - owner B. Supporting metrics Create 5 to 8 supporting metrics that explain the primary metric. C. Guardrail metrics Define metrics that protect against harmful tradeoffs. Examples: - revenue vs margin - conversion vs retention - speed vs quality - cost vs satisfaction - usage vs support burden - growth vs churn D. Segment view Define which segments must be monitored separately. E. Decision thresholds Create: - success threshold - warning threshold - failure threshold - inconclusive range - action for each result F. Reporting plan Explain how results should be communicated to stakeholders. Rules: - Do not use one metric when tradeoffs matter. - Do not create metrics that cannot be measured reliably. - Do not set targets without baseline or rationale. - The framework must help decision-makers know what to do next. --------------------------------------------------------------------------------

#013Analytical Hypothesis Builder

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, growth analysts, product analysts, marketing analysts, operations analysts, consultants, and teams moving from vague problem to structured investigation.

Turn a business problem into testable hypotheses, supporting evidence, required data, analysis methods, and expected business actions.

You are a hypothesis-driven analysis strategist. Build a hypothesis plan for investigating [BUSINESS PROBLEM]. Problem context: Business problem: [PROBLEM] Business goal: [GOAL] Observed symptom: [SYMPTOM] Affected segment: [SEGMENT] Time period: [TIME PERIOD] Stakeholders: [STAKEHOLDERS] Available data: [DATA SOURCES] Known recent changes: [RECENT CHANGES] Current theories: [THEORIES] Decision needed: [DECISION] Build the hypothesis system: 1. Problem framing Separate: - symptom - possible causes - affected business outcome - decision that depends on the analysis 2. Hypothesis list Create 10 to 15 hypotheses. For each hypothesis include: - hypothesis statement - business logic - expected evidence if true - expected evidence if false - data needed - analysis method - segment to check - confidence before analysis - possible action if confirmed 3. Hypothesis tree Group hypotheses by theme: - customer behavior - product or service change - pricing - marketing - operations - sales process - seasonality - data quality - external factor 4. Prioritization Rank hypotheses by: - likelihood - business impact - ease of testing - actionability - urgency 5. Investigation plan Create the recommended order of analysis. Rules: - Do not start with only one favorite explanation. - Do not confuse symptoms with causes. - Do not test hypotheses that would not change action. - The final plan must make investigation structured and efficient. --------------------------------------------------------------------------------

#014Executive Analytics One-Pager Generator

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, analytics managers, consultants, strategy teams, product teams, finance teams, and anyone preparing leadership-facing analysis work.

Create a concise executive-ready analysis framing document with objective, decision, metrics, approach, timeline, risks, and expected business value.

Act as an executive analytics communicator. Create a one-page analysis brief for leadership. Analysis context: Project title: [TITLE] Executive audience: [AUDIENCE] Business issue: [ISSUE] Decision needed: [DECISION] Why now: [WHY NOW] Expected business value: [VALUE] Metrics: [METRICS] Data sources: [DATA SOURCES] Analysis approach: [APPROACH] Timeline: [TIMELINE] Known risks: [RISKS] Ask from leadership: [ASK] Create the one-pager: 1. Headline Write a clear executive headline that explains the point of the analysis. 2. Business context Summarize: - current situation - business impact - decision urgency - stakeholders affected 3. Analysis objective Define what the analysis will answer. 4. Decision support Explain how the analysis will guide action. 5. Metrics List: - primary metric - secondary metrics - guardrails - baseline, if available - target, if available 6. Approach Summarize the analysis method in simple language. 7. Risks and limitations State what could limit confidence. 8. Timeline and deliverables Show: - milestones - final deliverable - review date - decision date 9. Leadership ask Write what you need from leadership. Rules: - Do not include unnecessary technical detail. - Do not hide uncertainty. - Do not make the brief longer than one page. - The one-pager must help executives understand value, risk, and next steps quickly. --------------------------------------------------------------------------------

#015Business Impact Estimation Framework

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTAnalytics teams, product teams, finance analysts, operations leaders, consultants, data leaders, founders, and teams prioritizing analytical work.

Estimate the potential financial, operational, customer, or strategic impact of an analysis project before investing time in it.

You are a business impact analyst. Estimate the potential impact of this analysis project before we commit time to it. Project context: Analysis idea: [ANALYSIS IDEA] Business problem: [PROBLEM] Affected metric: [METRIC] Current baseline: [BASELINE] Target improvement: [TARGET] Affected population or volume: [VOLUME] Revenue or cost context: [REVENUE / COST] Decision enabled: [DECISION] Implementation owner: [OWNER] Expected effort: [EFFORT] Data availability: [DATA] Confidence level: [CONFIDENCE] Estimate impact: A. Impact pathway Map how the analysis could create value: - insight discovered - decision changed - action taken - metric improved - business value realized B. Value model Build a simple impact model. Include: - formula - assumptions - inputs - low case - base case - high case - confidence rating C. Non-financial impact Estimate possible impact on: - customer experience - retention - operational speed - quality - risk reduction - strategic clarity - team alignment D. Effort vs impact Compare expected value to analysis effort. E. Decision recommendation Classify the project as: - high priority - worth doing - clarify first - low priority - not worth current effort F. Stakeholder summary Write a short explanation of why the project is or is not worth doing. Rules: - Do not invent precise ROI without assumptions. - Do not ignore implementation feasibility. - Do not count insight as value unless it can change action. - The model must be transparent and decision-ready. --------------------------------------------------------------------------------

#016Data Analysis Scope Control System

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, consultants, analytics teams, BI teams, product analysts, finance analysts, and anyone managing stakeholder requests.

Prevent analysis projects from becoming too broad by defining scope, exclusions, milestones, deliverables, and change-control rules.

Act as an analytics project scope controller. Create a scope control system for the analysis project below. Project context: Project name: [PROJECT] Initial request: [REQUEST] Business objective: [OBJECTIVE] Stakeholders: [STAKEHOLDERS] Decision needed: [DECISION] Deadline: [DEADLINE] Available data: [DATA] Expected deliverable: [DELIVERABLE] Potential extra requests: [EXTRA REQUESTS] Team capacity: [CAPACITY] Known risks: [RISKS] Define scope: 1. Core scope Define the essential analysis that must be completed. Include: - main question - required metrics - required segments - required timeframe - required deliverable - acceptance criteria 2. Out of scope List what will not be included. Explain why each item is excluded. 3. Optional extensions Identify possible add-ons that can be done only after core work is complete. 4. Milestones Create milestones: - requirement confirmation - data validation - first findings - stakeholder review - final deliverable - decision support 5. Change request rules Define how new stakeholder requests will be handled. Create categories: - accept now - add to backlog - replace existing scope - reject - requires new project 6. Communication script Write a professional message to stakeholders explaining scope boundaries. Rules: - Do not let exploratory curiosity expand the project endlessly. - Do not accept new questions without tradeoffs. - Do not remove essential context just to save time. - Scope control should protect both business value and delivery quality. --------------------------------------------------------------------------------

#017Dashboard Purpose and Business Use Case Designer

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTBI analysts, data analysts, product managers, executives, operations teams, finance teams, marketing teams, and anyone building dashboards that must drive action.

Define why a dashboard should exist, who uses it, what decisions it supports, what metrics it needs, and what actions should follow.

You are a dashboard strategy consultant. Design the business purpose and use case for a dashboard before any visuals are created. Dashboard context: Dashboard name or idea: [DASHBOARD] Business area: [AREA] Users: [USERS] User roles: [ROLES] Business goal: [GOAL] Decisions supported: [DECISIONS] Current reporting pain: [PAIN] Existing reports: [REPORTS] Data sources: [DATA SOURCES] Refresh needs: [REFRESH] Tools: [TOOLS] Define the dashboard strategy: A. Dashboard purpose Write: - why the dashboard should exist - who uses it - when they use it - what question it answers - what decision it supports B. User stories Create 8 user stories in this format: As a [role], I need to know [metric / pattern] so I can [action]. C. Metric selection Create: - primary metrics - diagnostic metrics - segment filters - trend views - guardrail metrics - alert thresholds D. Action design For each metric define: - what good looks like - what bad looks like - likely cause to investigate - action owner - recommended next action E. Dashboard exclusions List what should not be included and why. F. Success criteria Define how to know the dashboard is useful after launch. Rules: - Do not build a dashboard just because data exists. - Do not include metrics with no action owner. - Do not create a dashboard that is only for passive viewing. - The dashboard must make decisions faster or better. --------------------------------------------------------------------------------

#018Business Context Data Story Framer

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, consultants, BI analysts, product analysts, marketing analysts, finance analysts, and anyone presenting insights to non-technical stakeholders.

Frame an analysis as a business story with context, tension, evidence, interpretation, tradeoffs, recommendation, and next steps.

Act as a data storytelling strategist. Turn the analysis topic below into a business story structure before the final report is written. Analysis context: Topic: [TOPIC] Business problem: [PROBLEM] Audience: [AUDIENCE] Decision to support: [DECISION] Key metrics: [METRICS] Known findings, if any: [FINDINGS] Business tension: [TENSION] Recommended action, if known: [ACTION] Risks or caveats: [RISKS] Desired format: [SLIDES / MEMO / DASHBOARD NOTES / EXECUTIVE SUMMARY] Build the story frame: 1. Situation Explain the current business context. 2. Complication Identify what changed, what is unclear, or why the issue matters now. 3. Key question Write the central question the analysis answers. 4. Evidence path Create the sequence of evidence: - baseline - trend - segment difference - driver analysis - comparison - root cause clue - impact estimate - tradeoff 5. Interpretation Explain what the evidence likely means and what it does not mean. 6. Recommendation Create a recommendation structure: - action - reason - expected impact - confidence level - risk - next test or follow-up 7. Final narrative Write a concise executive narrative in 5 to 7 sentences. Rules: - Do not present charts without a story. - Do not overstate what the data proves. - Do not bury the business decision under technical detail. - The story must help stakeholders understand what happened, why it matters, and what to do. --------------------------------------------------------------------------------

#019Analytics Project Charter Builder

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTAnalytics teams, consultants, data analysts, BI teams, product analysts, operations analysts, finance teams, and cross-functional analysis projects.

Create a complete project charter for a data analysis initiative with objective, stakeholders, scope, metrics, data, timeline, deliverables, risks, and acceptance criteria.

You are an analytics project manager. Create a complete project charter for [ANALYTICS PROJECT]. Project context: Project name: [PROJECT NAME] Business sponsor: [SPONSOR] Request owner: [OWNER] Business problem: [PROBLEM] Decision to support: [DECISION] Expected outcome: [OUTCOME] Stakeholders: [STAKEHOLDERS] Data sources: [DATA SOURCES] Timeline: [TIMELINE] Deliverable format: [DELIVERABLE] Constraints: [CONSTRAINTS] Dependencies: [DEPENDENCIES] Known risks: [RISKS] Create the charter: 1. Project summary Write a short summary of the analysis initiative. 2. Business objective Define: - business goal - analytical objective - decision supported - success criteria 3. Stakeholder map List: - sponsor - decision owner - data owner - subject matter experts - end users - reviewers - approvers 4. Scope Define: - in scope - out of scope - assumptions - dependencies - constraints 5. Metrics and data List: - primary metrics - secondary metrics - guardrails - required data sources - data quality checks - metric definitions needed 6. Timeline Create phases: - discovery - data access - data validation - analysis - draft findings - review - final delivery - decision support 7. Risks and mitigation Create a risk table. 8. Acceptance criteria Define what “done” means. Rules: - Do not start analysis without a clear owner and decision. - Do not let deliverables stay vague. - Do not ignore data access and data quality dependencies. - The charter should reduce rework and align expectations. --------------------------------------------------------------------------------

#020Full Data Analysis Strategy and Business Context Audit

DATA ANALYSIS STRATEGY & BUSINESS CONTEXTData analysts, analytics leaders, BI teams, consultants, product analysts, operations analysts, finance analysts, growth teams, and anyone preparing serious business-facing analysis.

Audit and rebuild the full strategic foundation of a data analysis project across goals, stakeholders, decisions, metrics, questions, data readiness, scope, risks, and business impact.

Act as an independent data analysis strategy and business context auditor. Review my analysis request and rebuild it into a clear, decision-connected, business-ready analytics plan. Full context: Company or project: [COMPANY / PROJECT] Industry: [INDUSTRY] Business model: [BUSINESS MODEL] Original analysis request: [REQUEST] Business goal: [GOAL] Current business problem: [PROBLEM] Decision to support: [DECISION] Decision owner: [OWNER] Stakeholders: [STAKEHOLDERS] Current metrics: [METRICS] Available data sources: [DATA SOURCES] Known data issues: [DATA ISSUES] Relevant time period: [TIME PERIOD] Customer or operational segments: [SEGMENTS] Current reports or dashboards: [REPORTS] Known assumptions: [ASSUMPTIONS] Constraints: [CONSTRAINTS] Deadline: [DEADLINE] Expected deliverable: [DELIVERABLE] Business impact expectation: [IMPACT] Audit across 60 dimensions: 1. Business goal clarity 2. Decision clarity 3. Decision owner clarity 4. Stakeholder alignment 5. Stakeholder expectations 6. Analysis objective 7. Scope definition 8. Out-of-scope clarity 9. Business process understanding 10. Customer or user context 11. Operational context 12. Market or external context 13. Timeframe relevance 14. Segment relevance 15. Metric definition quality 16. Primary metric fit 17. Secondary metric fit 18. Guardrail metric fit 19. KPI tree connection 20. Baseline availability 21. Target clarity 22. Success threshold 23. Decision threshold 24. Data source availability 25. Data granularity 26. Data freshness 27. Data quality 28. Data completeness 29. Data consistency 30. Data ownership 31. Data access risk 32. Required joins 33. Business rule clarity 34. Assumptions 35. Analysis limitations 36. Causality risk 37. Bias or sample risk 38. Seasonality risk 39. Confounding factors 40. Hypothesis quality 41. Analysis question quality 42. Prioritization 43. Feasibility 44. Expected method fit 45. Deliverable fit 46. Dashboard need 47. Report need 48. Executive communication need 49. Data story potential 50. Business impact estimate 51. Implementation feasibility 52. Action owner clarity 53. Monitoring plan 54. Review cadence 55. Risk register 56. Stakeholder sign-off 57. Timeline realism 58. Rework risk 59. Strategic value 60. Overall analysis readiness For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - business risk if ignored - analytical risk if ignored - recommended fix - priority - effort - confidence level Then synthesize: A. Hard truth Explain the biggest reason this analysis request may fail to create useful business action. B. Rebuilt analysis strategy Create: - clarified business goal - decision statement - stakeholder map - analysis objective - scope - out-of-scope items - KPI tree - metric definitions - analysis questions - hypothesis list - data requirements - feasibility notes - risk register - deliverable plan C. First 10 actions Rank the first 10 steps to take before analysis begins. For each include: - action - owner - why it matters - expected output - time estimate - risk reduced D. Stakeholder alignment brief Write a one-page brief that can be shared before work starts. E. Analyst execution roadmap Create a phased roadmap: - discovery - metric definition - data access - data validation - analysis - interpretation - stakeholder review - final delivery - decision follow-up F. Executive summary Write a direct summary with: - strongest part of the request - weakest part of the request - first thing to clarify - most important metric - biggest data risk - biggest stakeholder risk - one operating principle for this analysis Rules: - Do not jump into SQL, charts, or dashboards before strategy is clear. - Do not fabricate missing business context. - Do not claim causality without proper evidence. - Use [NEEDS STAKEHOLDER INPUT], [NEEDS DATA OWNER REVIEW], [NEEDS METRIC DEFINITION], [NEEDS BUSINESS PROCESS REVIEW], or [NEEDS DATA QUALITY CHECK] where required. - The final plan should make the analysis decision-ready, realistic, and connected to business outcomes.

#021Data Source Discovery Map

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI analysts, analytics managers, business analysts, product analysts, consultants, operations teams, and anyone starting analysis before knowing where the data lives.

Identify every possible data source connected to a business question and classify sources by relevance, ownership, availability, quality, and analysis value.

You are a senior data analyst responsible for discovering all relevant data sources before analysis begins. Build a complete data source discovery map for the business question below. Business context: Company or project: [COMPANY / PROJECT] Business question: [BUSINESS QUESTION] Decision to support: [DECISION] Business area: [BUSINESS AREA] Stakeholders: [STAKEHOLDERS] Known systems: [KNOWN SYSTEMS] Known reports or dashboards: [REPORTS] Known data owners: [DATA OWNERS] Time period needed: [TIME PERIOD] Expected deliverable: [DELIVERABLE] Constraints: [CONSTRAINTS] Create the discovery map: 1. Source categories Identify possible sources across: - transactional systems - CRM - ERP - product analytics - web analytics - marketing platforms - finance systems - support systems - operations tools - spreadsheets - manual logs - survey data - third-party data - historical reports - data warehouse tables - API sources 2. Source relevance table For each source include: - source name - business process captured - owner - key entities - key fields - time range available - update frequency - granularity - likely relevance - known limitations - access status - confidence level 3. Data source priority Classify sources as: - must-have - helpful - optional - validation source - backup source - not useful for this question 4. Source verification questions Create questions to ask data owners for each must-have source. 5. Collection plan Create an ordered plan for requesting, validating, and combining sources. 6. Risk notes Identify risks such as: - missing source - duplicate records - inconsistent definitions - stale data - manual entry errors - access restrictions - ownership ambiguity Rules: - Do not assume the most visible dashboard is the source of truth. - Do not ignore manual spreadsheets if they drive business decisions. - Do not recommend analysis until source relevance and ownership are clear. - The final map must help the analyst know exactly where to look first. --------------------------------------------------------------------------------

#022Data Requirements Specification Builder

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, analytics engineers, BI teams, product analysts, business analysts, data requesters, and teams preparing a reliable data pull.

Convert a business analysis need into a detailed data requirements specification with entities, fields, filters, timeframes, granularity, joins, quality checks, and access needs.

Act as a data requirements specialist. Create a complete data requirements specification for the analysis request below. Analysis context: Analysis request: [REQUEST] Business objective: [OBJECTIVE] Decision to support: [DECISION] Stakeholders: [STAKEHOLDERS] Expected deliverable: [DELIVERABLE] Required timeframe: [TIMEFRAME] Known data sources: [SOURCES] Known metrics: [METRICS] Known segments: [SEGMENTS] Tool or environment: [TOOL / ENVIRONMENT] Deadline: [DEADLINE] Build the specification: A. Business requirement Write: - business problem - analytical objective - decision supported - expected output - success criteria B. Data entities Identify required entities such as: - customer - user - account - order - transaction - product - session - campaign - ticket - location - employee - event - subscription For each entity include: - business definition - required fields - grain - source system - owner - join keys - quality concerns C. Field requirements Create a field-level table with: - field name - business meaning - data type - required or optional - allowed values - source - transformation needed - example value - validation rule D. Filters and exclusions Define: - date filters - status filters - segment filters - exclusions - edge cases - duplicate handling E. Data quality acceptance Define minimum acceptable standards for: - completeness - accuracy - freshness - consistency - uniqueness - valid ranges F. Access and delivery Specify: - who provides the data - format needed - refresh cadence - secure transfer method - approval needed - open questions Rules: - Do not request “all data” without field-level requirements. - Do not leave entity grain undefined. - Do not ignore filters, exclusions, and edge cases. - The specification must be clear enough for a data owner or engineer to deliver the right dataset. --------------------------------------------------------------------------------

#023Dataset Inventory and Availability Matrix

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI teams, analytics leaders, data governance teams, consultants, product teams, and new analysts onboarding to a data environment.

Create a structured inventory of available datasets and evaluate each one by business relevance, coverage, quality, ownership, freshness, and usability.

You are a data inventory analyst. Build a dataset inventory and availability matrix for the business area below. Context: Business area: [BUSINESS AREA] Analysis goals: [GOALS] Known datasets: [DATASETS] Known systems: [SYSTEMS] Stakeholders: [STAKEHOLDERS] Data warehouse or storage location: [WAREHOUSE / STORAGE] Reporting tools: [TOOLS] Known data problems: [PROBLEMS] Required analysis timeframe: [TIMEFRAME] Create the inventory: 1. Dataset list Identify or organize datasets into categories: - raw source data - cleaned tables - aggregated tables - dashboards - exports - operational reports - external files - manual spreadsheets - archived data 2. Dataset matrix For each dataset include: - dataset name - source system - business process - owner - description - grain - key fields - time coverage - refresh frequency - access method - documentation status - quality score - relevance score - known limitations 3. Availability status Classify each dataset as: - ready to use - usable with caveats - needs validation - needs access approval - needs transformation - deprecated - unknown 4. Coverage gaps Identify missing datasets or missing time periods. 5. Recommended foundation Recommend which datasets should be used first for analysis and why. 6. Documentation backlog Create a prioritized list of documentation tasks. Rules: - Do not treat a dataset as reliable just because it exists. - Do not ignore undocumented datasets. - Do not mix raw, cleaned, and aggregated sources without labeling them. - The matrix must help analysts choose the safest data foundation. --------------------------------------------------------------------------------

#024Missing Data Request Brief

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, business analysts, BI teams, consultants, product managers, operations teams, finance analysts, and anyone asking another team for data.

Write a clear request for missing data that explains business need, required fields, timeframe, format, owner responsibilities, and urgency.

Act as a data request writer. Create a clear, professional request for missing data needed for analysis. Request context: Analysis project: [PROJECT] Business question: [QUESTION] Decision supported: [DECISION] Data owner or team: [OWNER / TEAM] Missing data needed: [MISSING DATA] Why it is needed: [WHY] Required fields: [FIELDS] Required timeframe: [TIMEFRAME] Required format: [FORMAT] Deadline: [DEADLINE] Security or privacy constraints: [CONSTRAINTS] Current workaround, if any: [WORKAROUND] Create the request package: A. Short message Write a concise message suitable for Slack, Teams, or email. B. Detailed request Write a full data request with: - context - business reason - exact fields needed - timeframe - granularity - filters - delivery format - deadline - contact person - approval requirements C. Data field table Create a table with: - field name - definition - required or optional - example value - reason needed - acceptable alternative D. Priority explanation Explain what happens if the data is not available by the deadline. E. Follow-up questions Create questions for the data owner: - source of truth - refresh cadence - field definitions - access process - quality issues - historical coverage - privacy restrictions F. Alternative plan Suggest proxy data or revised scope if the requested data cannot be provided. Rules: - Do not send vague requests like “can you share the data?” - Do not ask for sensitive data unless necessary. - Do not hide why the data is needed. - The request must make it easy for the data owner to respond accurately. --------------------------------------------------------------------------------

#025Field Dictionary and Data Documentation Builder

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI analysts, analytics engineers, data governance teams, product analysts, operations analysts, finance analysts, and teams standardizing datasets.

Create a field-level data dictionary that explains names, definitions, types, owners, business logic, allowed values, examples, and quality rules.

You are a data documentation specialist. Build a clear data dictionary for the dataset below. Dataset context: Dataset name: [DATASET NAME] Business area: [BUSINESS AREA] Source system: [SOURCE SYSTEM] Dataset purpose: [PURPOSE] Owner: [OWNER] Users: [USERS] Known fields: [PASTE FIELD LIST] Sample rows, if available: [SAMPLE ROWS] Known metric definitions: [METRICS] Known issues: [ISSUES] Create the data dictionary: 1. Dataset overview Write: - dataset description - business process represented - grain - primary entity - source system - refresh cadence - owner - intended use - not intended for 2. Field documentation table For every field include: - field name - business definition - technical definition - data type - example value - allowed values - null meaning - source logic - transformation logic - owner - quality rule - common misuse warning 3. Key fields Identify: - primary key - foreign keys - date fields - status fields - metric fields - segment fields - sensitive fields 4. Business rules Document rules such as: - active vs inactive - completed vs canceled - valid record - duplicate handling - timezone rules - currency rules - unit rules 5. Open questions List fields that need clarification from data owners. Rules: - Do not define fields only by their column names. - Do not ignore null values and edge cases. - Do not leave business rules undocumented. - The dictionary must be useful for analysts, stakeholders, and future reporting. --------------------------------------------------------------------------------

#026Data Ownership and Stewardship Map

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI managers, analytics engineers, data governance teams, cross-functional projects, operations teams, finance teams, and business process owners.

Identify who owns, maintains, approves, defines, and uses each dataset or metric so analysis work has accountable data contacts.

Act as a data governance analyst. Create a data ownership and stewardship map for the datasets and metrics below. Context: Business area: [BUSINESS AREA] Datasets: [DATASETS] Metrics: [METRICS] Systems involved: [SYSTEMS] Teams involved: [TEAMS] Known owners: [KNOWN OWNERS] Known confusion: [CONFUSION] Data access process: [ACCESS PROCESS] Reporting use cases: [USE CASES] Build the ownership map: A. Ownership roles Define and assign where possible: - business owner - technical owner - data steward - metric owner - access approver - documentation owner - quality owner - dashboard owner - user group B. Dataset ownership table For each dataset include: - dataset name - business owner - technical owner - source system owner - access approver - refresh owner - data quality contact - documentation status - escalation path C. Metric ownership table For each metric include: - metric name - business definition owner - formula owner - dashboard owner - approval group - change process - related guardrail metrics D. Responsibility gaps Identify where ownership is unclear or risky. E. Governance actions Create a practical plan to: - confirm owners - document definitions - set review cadence - handle metric changes - manage access requests - report quality issues Rules: - Do not assume the dashboard creator is the metric owner. - Do not leave access approval unclear. - Do not let multiple teams define the same metric differently. - The map must make data accountability visible. --------------------------------------------------------------------------------

#027Source System and Business Process Alignment

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, analytics engineers, operations analysts, product analysts, finance analysts, BI teams, and consultants analyzing system-generated data.

Understand how source systems capture real business processes so analysts know what each timestamp, status, record, and field actually means.

You are a source system analyst. Map how the source system creates data from the real business process. System context: Source system: [SYSTEM] Business process: [PROCESS] Business area: [AREA] Users of the system: [USERS] Records created: [RECORDS] Important statuses: [STATUSES] Important timestamps: [TIMESTAMPS] Known manual steps: [MANUAL STEPS] Known exceptions: [EXCEPTIONS] Analysis need: [ANALYSIS NEED] Create the alignment map: 1. Business process flow Describe the real-world process step by step. 2. System event flow For each business step identify: - system action - record created or updated - fields changed - timestamp captured - status assigned - user responsible - possible delay - possible error 3. Record meaning Define what each record represents in the real world. Examples: - customer - order - invoice - session - event - ticket - payment - subscription - shipment - lead 4. Timestamp interpretation Clarify each timestamp: - what event it represents - whether it is system-generated or manual - timezone - delay risk - overwrite risk - best use case 5. Status logic Explain status values and transitions. 6. Analysis implications List how this system behavior affects metrics, filters, joins, and conclusions. Rules: - Do not assume system fields are self-explanatory. - Do not treat manual timestamps as exact without validation. - Do not ignore status transitions and overwritten values. - The final map must prevent business-process misunderstanding during analysis. --------------------------------------------------------------------------------

#028Data Access Request and Approval Plan

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI teams, analytics managers, consultants, data governance teams, finance teams, HR analysts, product analysts, and teams handling sensitive data.

Create a responsible data access plan with purpose, minimum necessary fields, approval path, security controls, privacy considerations, and usage boundaries.

Act as a data access planning specialist. Create a responsible access request for the analysis project below. Access context: Analysis project: [PROJECT] Business purpose: [PURPOSE] Requested dataset or system: [DATASET / SYSTEM] Data owner: [OWNER] Fields needed: [FIELDS] Sensitive fields involved: [SENSITIVE FIELDS] Users needing access: [USERS] Access duration: [DURATION] Tool or environment: [TOOL] Security requirements: [SECURITY] Privacy requirements: [PRIVACY] Approval process: [APPROVAL PROCESS] Build the access plan: A. Access purpose Write a clear justification for why access is needed. B. Minimum necessary data Separate fields into: - required - optional - not needed - sensitive and needs justification - should be anonymized - should be aggregated C. Access request message Write a professional request with: - business purpose - data needed - timeframe - users - access duration - security handling - expected output - approval ask D. Risk controls Recommend controls for: - anonymization - aggregation - limited access duration - read-only access - secure storage - audit logs - deletion after project - sharing restrictions E. Usage boundaries Define what the data may and may not be used for. F. Approval checklist Create a checklist for data owner, privacy, security, and manager approval. Rules: - Do not request more data than necessary. - Do not include sensitive personal data unless required and approved. - Do not bypass data owner approval. - The access plan must support analysis while protecting data responsibly. --------------------------------------------------------------------------------

#029Data Grain and Entity Relationship Planner

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, analytics engineers, BI developers, product analysts, finance analysts, operations analysts, and anyone joining multiple datasets.

Define dataset grain, entities, relationships, join keys, aggregation rules, and risks before combining data sources.

You are a data modeling and analysis readiness expert. Help me define the grain and entity relationships before analysis. Analysis context: Business question: [QUESTION] Datasets involved: [DATASETS] Known entities: [ENTITIES] Possible join keys: [JOIN KEYS] Expected metrics: [METRICS] Timeframe: [TIMEFRAME] Current confusion: [CONFUSION] Sample fields: [FIELDS] Known duplicates: [DUPLICATES] Expected output: [OUTPUT] Create the grain and relationship plan: 1. Entity inventory Identify each entity: - customer - account - user - order - transaction - product - event - session - campaign - location - employee - subscription - ticket For each entity define: - business meaning - primary key - expected uniqueness - source dataset - analysis role 2. Dataset grain For each dataset define: - one row represents - lowest level of detail - time granularity - duplicate risk - aggregation risk - valid use cases 3. Relationship map Define relationships: - one-to-one - one-to-many - many-to-one - many-to-many - unknown For each relationship include: - join keys - join type - risk - validation query idea - expected row count behavior 4. Aggregation plan Define how metrics should be calculated at: - record level - customer level - account level - date level - segment level - business unit level 5. Join risk warnings Identify risks such as: - row multiplication - dropped records - duplicate keys - mismatched time windows - stale dimensions - invalid foreign keys Rules: - Do not join datasets before grain is defined. - Do not assume IDs are unique without validation. - Do not calculate metrics at the wrong aggregation level. - The plan must protect analysis from silent join errors. --------------------------------------------------------------------------------

#030Data Freshness and Refresh Requirement Planner

DATA COLLECTION, SOURCES & REQUIREMENTSBI analysts, dashboard builders, data engineers, analytics teams, operations managers, executives, product teams, and anyone designing recurring reporting.

Define how fresh data needs to be, how often it should update, who needs it, what latency is acceptable, and how stale data affects decisions.

Act as a data freshness requirements analyst. Define refresh needs for the reporting or analysis use case below. Use case context: Report, dashboard, or analysis: [USE CASE] Business decision supported: [DECISION] Users: [USERS] Current refresh cadence: [CURRENT CADENCE] Desired refresh cadence: [DESIRED CADENCE] Source systems: [SOURCES] Business process timing: [PROCESS TIMING] Decision urgency: [URGENCY] Data latency tolerance: [TOLERANCE] Cost or technical constraints: [CONSTRAINTS] Known data delays: [DELAYS] Create the freshness plan: A. Decision freshness need Explain how fresh the data must be for the decision. Classify as: - real-time - near real-time - hourly - daily - weekly - monthly - ad hoc B. Metric-specific refresh needs For each metric define: - required refresh frequency - acceptable latency - source availability - business risk of stale data - technical effort - recommended cadence C. Refresh schedule Create a schedule with: - source extraction - transformation - validation - report update - stakeholder notification - exception handling D. Staleness warnings Define when users should be warned that data is outdated. E. Tradeoff explanation Explain the tradeoff between freshness, cost, reliability, and business value. Rules: - Do not ask for real-time data if the decision does not need it. - Do not hide data latency from users. - Do not refresh dashboards faster than source systems reliably update. - Freshness requirements must match decision urgency. --------------------------------------------------------------------------------

#031Pre-Analysis Data Quality Requirements

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI teams, analytics engineers, data quality teams, finance analysts, product analysts, operations analysts, and consultants.

Define data quality checks and minimum acceptance criteria before analysis begins, including completeness, validity, consistency, uniqueness, accuracy, and freshness.

You are a data quality requirements specialist. Create a pre-analysis data quality checklist for [DATASET / PROJECT]. Project context: Analysis project: [PROJECT] Dataset or sources: [DATASET / SOURCES] Business question: [QUESTION] Key metrics: [METRICS] Critical fields: [FIELDS] Time period: [TIME PERIOD] Known data issues: [ISSUES] Stakeholders: [STAKEHOLDERS] Risk level: [LOW / MEDIUM / HIGH] Deadline: [DEADLINE] Build the quality requirements: 1. Critical field classification Classify fields as: - business-critical - metric-critical - join-critical - filter-critical - descriptive - optional 2. Quality checks Define checks for: - completeness - uniqueness - validity - consistency - freshness - accuracy - referential integrity - duplicate records - outliers - unexpected values - date logic - negative or impossible values 3. Acceptance criteria For each check include: - field or dataset - rule - acceptable threshold - failure threshold - business impact - action if failed - owner 4. Validation workflow Create a step-by-step process: - source confirmation - schema check - row count check - field validation - join validation - metric sanity check - stakeholder review - approval to analyze 5. Data quality report Create a template for summarizing quality issues to stakeholders. Rules: - Do not analyze critical data before quality checks are complete. - Do not treat all fields as equally important. - Do not hide quality failures in technical notes only. - The checklist must protect business conclusions from bad data. --------------------------------------------------------------------------------

#032Privacy, Security and Sensitive Data Requirements

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, HR analysts, finance analysts, healthcare analysts, education analysts, product teams, BI teams, consultants, and data governance teams.

Identify privacy and security requirements before collecting, accessing, joining, sharing, or analyzing sensitive data.

Act as a privacy-aware data requirements analyst. Review the analysis request and identify privacy, security, and sensitive data requirements. Analysis context: Analysis request: [REQUEST] Business purpose: [PURPOSE] Data sources: [DATA SOURCES] Data fields requested: [FIELDS] Sensitive data involved: [SENSITIVE DATA] Users of analysis: [USERS] Output format: [OUTPUT] Sharing audience: [AUDIENCE] Jurisdiction or policy constraints: [POLICIES] Retention needs: [RETENTION] Access environment: [ENVIRONMENT] Create the requirements: A. Sensitive data classification Classify fields as: - non-sensitive - internal confidential - personal data - sensitive personal data - financial data - health data - education data - employee data - customer confidential - business confidential B. Minimum data principle Identify: - fields required - fields that can be removed - fields that can be aggregated - fields that should be anonymized - fields that should be pseudonymized - fields that need approval C. Access requirements Define: - who needs access - why they need access - duration - approval required - storage rules - sharing restrictions D. Output safety Recommend how results should be shared: - aggregate only - suppress small groups - remove identifiers - mask values - limit exports - add caveats E. Review checklist Create a checklist for privacy, security, legal, and data owner review. Rules: - Do not request identifiable data if aggregated data is enough. - Do not expose small groups where individuals can be inferred. - Do not provide legal advice. - Use [NEEDS PRIVACY REVIEW], [NEEDS LEGAL REVIEW], or [NEEDS DATA OWNER APPROVAL] where required. --------------------------------------------------------------------------------

#033Historical Data Coverage and Time Window Planner

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, finance analysts, growth analysts, operations analysts, product analysts, BI teams, and anyone selecting analysis timeframes.

Determine the correct historical data range for analysis by considering business cycles, seasonality, data availability, system changes, and decision needs.

You are a time-window planning specialist for business analysis. Determine the right historical data coverage for this analysis. Analysis context: Business question: [QUESTION] Business process: [PROCESS] Decision supported: [DECISION] Metric or outcome: [METRIC] Available history: [AVAILABLE HISTORY] Known seasonality: [SEASONALITY] Known business changes: [CHANGES] System changes: [SYSTEM CHANGES] Data gaps: [GAPS] Reporting cadence: [CADENCE] Stakeholder expectation: [EXPECTATION] Create the time window plan: 1. Decision horizon Explain whether the decision needs: - recent data - long-term trend - seasonal comparison - before-and-after analysis - cohort maturity - baseline period - forecast foundation 2. Recommended time windows Recommend: - primary analysis window - comparison window - baseline window - exclusion window - historical context window - monitoring window after decision 3. Time risks Identify risks such as: - incomplete recent data - seasonality - one-time events - system migration - policy changes - campaign effects - holidays - missing periods - delayed reporting 4. Data coverage checklist Create checks for: - earliest reliable date - latest complete date - gaps - schema changes - metric definition changes - timezone issues - calendar alignment 5. Stakeholder explanation Write a concise explanation of why this time window is recommended. Rules: - Do not choose the longest possible period by default. - Do not compare periods that are not business-comparable. - Do not include incomplete recent data without warning. - The time window must match the decision and metric behavior. --------------------------------------------------------------------------------

#034Join Keys and Dataset Relationship Verification

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, analytics engineers, BI developers, product analysts, finance analysts, operations analysts, and anyone preparing multi-source analysis.

Verify that datasets can be joined safely by checking keys, grain, duplicates, missing values, relationship type, and row count behavior.

Act as a dataset relationship verification analyst. Create a join validation plan for the datasets below. Join context: Dataset A: [DATASET A] Dataset B: [DATASET B] Business purpose of join: [PURPOSE] Possible join keys: [KEYS] Expected relationship: [EXPECTED RELATIONSHIP] Metrics affected: [METRICS] Known data issues: [ISSUES] Sample schemas: [SCHEMAS] Time period: [TIME PERIOD] Tool used: [SQL / PYTHON / BI TOOL / SPREADSHEET] Create the verification plan: A. Relationship hypothesis State the expected relationship: - one-to-one - one-to-many - many-to-one - many-to-many - unknown B. Key validation checks Define checks for: - null keys - duplicate keys - invalid keys - changing keys - missing foreign keys - format mismatch - case sensitivity - leading zeros - whitespace - date-dependent keys C. Join behavior tests Create tests for: - row count before and after join - unmatched records - duplicated records - metric totals before and after join - sample record inspection - segment-specific mismatches D. Risk interpretation Explain what each failure means for analysis. E. Safe join recommendation Recommend: - join type - filters - deduplication rules - aggregation before join - exclusions - caveats - validation summary Rules: - Do not join on fields just because names match. - Do not ignore row multiplication. - Do not calculate metrics after a many-to-many join without control. - The plan must prevent silent join errors. --------------------------------------------------------------------------------

#035Event Tracking Requirement Builder

DATA COLLECTION, SOURCES & REQUIREMENTSProduct analysts, growth teams, digital marketers, app teams, SaaS companies, data engineers, analytics implementation teams, and product managers.

Define event tracking requirements for digital products, websites, apps, funnels, or user behavior analysis.

You are a product analytics tracking requirements specialist. Create event tracking requirements for [PRODUCT / FEATURE / FUNNEL]. Tracking context: Product or website: [PRODUCT] Feature or funnel: [FEATURE / FUNNEL] Business goal: [GOAL] User actions to measure: [ACTIONS] Decisions supported: [DECISIONS] Analytics tool: [TOOL] Current tracking: [CURRENT TRACKING] Known gaps: [GAPS] User segments: [SEGMENTS] Privacy constraints: [PRIVACY] Implementation owner: [OWNER] Create the tracking plan: 1. Measurement objective Define: - business question - user behavior to understand - decision supported - success metric - guardrail metric 2. Event inventory Create event requirements with: - event name - event description - trigger condition - user action - page or screen - required properties - optional properties - user identifier - timestamp - platform - example payload 3. Naming conventions Define rules for: - event names - property names - values - casing - versioning - deprecated events 4. Funnel map Show the event sequence for the user journey. 5. QA plan Create tests for: - event fires once - correct trigger - correct properties - correct user ID - correct timestamp - cross-device behavior - missing values - duplicate events 6. Privacy review Identify fields that should not be tracked. Rules: - Do not track everything without a decision need. - Do not include sensitive personal data in event properties unless approved. - Do not use vague event names like “clicked button.” - Tracking requirements must be clear enough for implementation and analysis. --------------------------------------------------------------------------------

#036External and Third-Party Data Source Evaluation

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, market analysts, consultants, strategy teams, finance analysts, growth teams, product teams, and businesses considering external data.

Evaluate whether an external dataset, vendor data, public source, benchmark, API, or purchased data source is reliable and useful for analysis.

Act as an external data evaluation analyst. Assess whether the external data source below should be used for analysis. External data context: Data source name: [SOURCE] Provider: [PROVIDER] Data description: [DESCRIPTION] Business use case: [USE CASE] Decision supported: [DECISION] Coverage: [COVERAGE] Time range: [TIME RANGE] Update frequency: [FREQUENCY] Access method: [API / FILE / DASHBOARD / SCRAPE / PURCHASE] Cost: [COST] License terms: [TERMS] Known alternatives: [ALTERNATIVES] Evaluate the source: A. Relevance Assess: - business fit - metric fit - geography coverage - segment coverage - time coverage - granularity - benchmark usefulness B. Reliability Evaluate: - provider credibility - methodology transparency - collection method - sample bias - update consistency - missing data - revision history - documentation quality C. Usability Check: - format - schema stability - identifiers - joinability - API limits - historical access - cost - maintenance effort D. Legal and ethical considerations Identify: - license restrictions - privacy risks - sharing restrictions - attribution requirements - prohibited uses - review needed E. Recommendation Classify as: - use confidently - use with caveats - use only for directional insight - validate against internal data first - do not use Rules: - Do not trust external data only because it is from a known provider. - Do not ignore methodology and licensing. - Do not compare external benchmarks to internal data without checking definitions. - Use [NEEDS LEGAL REVIEW] or [NEEDS PRIVACY REVIEW] where required. --------------------------------------------------------------------------------

#037New Data Collection Plan

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, product managers, operations teams, researchers, startup teams, survey owners, customer success teams, and business teams creating new data foundations.

Design a plan for collecting data that does not currently exist, including what to collect, how, from whom, when, with what quality controls, and why.

You are a data collection planning strategist. Create a plan to collect new data for the business need below. Collection context: Business question: [QUESTION] Decision supported: [DECISION] Current missing data: [MISSING DATA] Why existing data is insufficient: [WHY] Population to collect from: [POPULATION] Collection method options: [METHODS] Timeline: [TIMELINE] Tools available: [TOOLS] Privacy constraints: [PRIVACY] Budget or resource constraints: [CONSTRAINTS] Who will use the data: [USERS] Design the collection plan: 1. Data collection objective Define exactly what the new data should answer. 2. Data elements Create a table with: - field name - definition - data type - allowed values - required or optional - collection method - owner - validation rule - reason needed 3. Collection method Compare options: - form - survey - system event tracking - manual log - interview coding - operational checklist - API integration - spreadsheet intake - database field addition For each include: - pros - risks - effort - data quality impact 4. Process design Create: - who collects - when collected - where stored - how validated - how corrected - how accessed - how retired 5. Pilot plan Design a small pilot to test the collection method. 6. Governance Define ownership, privacy, documentation, and review cadence. Rules: - Do not collect data without a clear decision use. - Do not create fields that people will not fill accurately. - Do not collect sensitive data unless necessary and approved. - The plan must create reliable data, not just more data. --------------------------------------------------------------------------------

#038Manual Data Collection Template Designer

DATA COLLECTION, SOURCES & REQUIREMENTSOperations teams, analysts working with spreadsheets, small businesses, field teams, researchers, customer success teams, schools, finance teams, and manual tracking processes.

Create structured templates for manual data collection that reduce errors, standardize inputs, clarify ownership, and prepare data for analysis.

Act as a manual data collection template designer. Build a structured template for collecting [DATA TYPE]. Collection context: Data to collect: [DATA TYPE] Who enters data: [USERS] How often: [FREQUENCY] Business purpose: [PURPOSE] Analysis use: [ANALYSIS USE] Tool: [SPREADSHEET / FORM / NOTION / CRM / OTHER] Current collection problem: [PROBLEM] Required fields: [FIELDS] Validation needs: [VALIDATION] Privacy concerns: [PRIVACY] Design the template: A. Template structure Create columns or fields with: - field name - plain-language instruction - data type - required or optional - allowed values - example - validation rule - error warning B. Data entry rules Create rules for: - date format - naming format - status values - IDs - currency - units - missing values - corrections - duplicates C. User instructions Write simple instructions for people entering data. D. Quality controls Add: - dropdown lists - required fields - conditional checks - duplicate checks - locked formula fields - review column - last updated timestamp E. Analyst-readiness Explain how the collected data should be exported, cleaned, and used. F. Maintenance plan Define who reviews the template and how often. Rules: - Do not use free-text fields where standard options are needed. - Do not create ambiguous status values. - Do not make the template too complicated for the users who enter data. - The template must balance usability and analysis quality. --------------------------------------------------------------------------------

#039Analytics Data Intake Form

DATA COLLECTION, SOURCES & REQUIREMENTSAnalytics teams, BI teams, data analysts, data managers, consultants, internal service desks, RevOps teams, and organizations managing incoming data requests.

Create a data intake form that captures the context needed before accepting a data request, including business objective, decision, metrics, sources, timeframe, urgency, and stakeholders.

You are an analytics operations designer. Build a data request intake form that helps analysts collect the right requirements before work begins. Team context: Analytics team type: [TEAM TYPE] Requesters: [REQUESTERS] Common request types: [REQUEST TYPES] Current intake problem: [PROBLEM] Tools used: [TOOLS] Approval process: [APPROVAL] Priority rules: [PRIORITY RULES] Data sources available: [SOURCES] SLA or timeline expectations: [SLA] Create the intake form: 1. Request overview section Include fields for: - request title - requester - department - date needed - urgency - expected deliverable - audience 2. Business context section Include questions for: - business problem - decision to support - action that will be taken - stakeholder owner - why now - risk if not answered 3. Metrics and data section Include fields for: - metrics needed - definitions, if known - segments - filters - timeframe - data sources - known data issues - required fields 4. Output section Ask about: - dashboard - one-time analysis - spreadsheet - presentation - automated report - raw data export - recommendation memo 5. Priority scoring Create a built-in scoring method for impact, urgency, data readiness, and effort. 6. Analyst review checklist Create what the analyst checks before accepting the request. Rules: - Do not let requesters submit “pull some data” without business context. - Do not make the form so long that people avoid using it. - Do not accept high-priority labels without justification. - The form should reduce back-and-forth and improve analysis quality. --------------------------------------------------------------------------------

#040Full Data Collection, Sources and Requirements Audit

DATA COLLECTION, SOURCES & REQUIREMENTSData analysts, BI teams, analytics engineers, data governance teams, consultants, product analysts, operations analysts, finance analysts, and any team preparing for reliable analysis.

Audit and rebuild the complete data foundation for an analysis project, including sources, requirements, ownership, field definitions, quality checks, access, privacy, joins, and missing data.

Act as an independent data collection, sources, and requirements auditor. Review the data foundation for my analysis project and rebuild it into a reliable, documented, analysis-ready plan. Full context: Analysis project: [PROJECT] Business question: [QUESTION] Decision to support: [DECISION] Stakeholders: [STAKEHOLDERS] Expected deliverable: [DELIVERABLE] Known data sources: [DATA SOURCES] Known datasets: [DATASETS] Known fields: [FIELDS] Known metrics: [METRICS] Required timeframe: [TIMEFRAME] Required segments: [SEGMENTS] Known data owners: [OWNERS] Known data gaps: [GAPS] Known data quality issues: [QUALITY ISSUES] Access constraints: [ACCESS] Privacy or security constraints: [PRIVACY / SECURITY] Tool environment: [TOOLS] Deadline: [DEADLINE] Current documentation: [DOCUMENTATION] Audit across 60 dimensions: 1. Business question alignment 2. Decision connection 3. Source discovery completeness 4. Source relevance 5. Source of truth clarity 6. Dataset inventory 7. Dataset descriptions 8. Dataset grain 9. Entity definitions 10. Primary keys 11. Foreign keys 12. Join keys 13. Join relationship clarity 14. Duplicate risk 15. Row multiplication risk 16. Required fields 17. Optional fields 18. Field definitions 19. Data types 20. Allowed values 21. Null handling 22. Status logic 23. Date and timestamp logic 24. Timezone handling 25. Historical coverage 26. Freshness requirements 27. Refresh cadence 28. Source system behavior 29. Business process alignment 30. Metric field availability 31. Segment field availability 32. Filter field availability 33. Data access status 34. Data owner clarity 35. Data steward clarity 36. Approval process 37. Privacy classification 38. Sensitive fields 39. Minimum necessary data 40. Security controls 41. Data transfer method 42. Data storage location 43. Documentation completeness 44. Data dictionary quality 45. Data quality requirements 46. Completeness checks 47. Validity checks 48. Consistency checks 49. Uniqueness checks 50. Referential integrity 51. Outlier detection 52. Missing data handling 53. Proxy data risks 54. External data suitability 55. Manual data collection needs 56. Intake process 57. Data request clarity 58. Feasibility 59. Rework risk 60. Overall analysis readiness For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - analysis risk if ignored - business risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current data foundation may fail or create misleading analysis. B. Rebuilt data requirements plan Create: - source inventory - dataset matrix - required entity map - field requirements - data dictionary draft - ownership map - access plan - privacy requirements - quality acceptance criteria - join validation plan - missing data request plan - collection plan for new data C. First 10 data foundation actions Rank the first 10 actions to complete before analysis begins. For each include: - action - owner - why it matters - expected output - risk reduced - time estimate D. Data owner communication pack Write: - data request message - missing field request - definition clarification request - quality issue escalation - access approval request E. Analyst readiness checklist Create a checklist that must be completed before analysis starts. F. Executive summary Write a direct summary with: - strongest data source - weakest data source - biggest missing field - biggest ownership gap - biggest quality risk - biggest privacy risk - first validation check to run - one operating principle for reliable data collection Rules: - Do not move into analysis until critical data requirements are clear. - Do not assume data is reliable without validation. - Do not request unnecessary sensitive data. - Use [NEEDS DATA OWNER REVIEW], [NEEDS PRIVACY REVIEW], [NEEDS SECURITY REVIEW], [NEEDS FIELD DEFINITION], [NEEDS DATA QUALITY CHECK], or [NEEDS ACCESS APPROVAL] where required. - The final plan should create a reliable, documented, analysis-ready data foundation.

#041Messy Dataset Cleaning Strategy Builder

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI analysts, analytics engineers, business analysts, spreadsheet users, Python/R users, SQL analysts, and anyone preparing unreliable raw data for analysis.

Turn an unknown or messy dataset into a clear cleaning plan with priorities, risks, validation steps, and a documented transformation workflow.

You are a senior data analyst specializing in messy dataset preparation. Build a complete cleaning strategy for the dataset described below before any analysis begins. Dataset context: Dataset name: [DATASET NAME] Business purpose: [BUSINESS PURPOSE] Source system or file: [SOURCE] Dataset format: [CSV / EXCEL / SQL TABLE / API / OTHER] Number of rows: [ROWS] Number of columns: [COLUMNS] Key fields: [KEY FIELDS] Expected grain: [GRAIN] Known issues: [KNOWN ISSUES] Analysis goal: [ANALYSIS GOAL] Stakeholders: [STAKEHOLDERS] Tool to use: [SQL / PYTHON / R / EXCEL / POWER BI / TABLEAU / OTHER] Deadline: [DEADLINE] Create the cleaning strategy: 1. Initial inspection plan List what to inspect first: - schema - row count - column names - data types - missing values - duplicates - date formats - text formats - numeric ranges - categories - IDs and keys - unexpected values 2. Cleaning priority map Classify issues into: - critical before analysis - important but manageable - cosmetic - needs stakeholder decision - needs data owner review - should not be changed without approval 3. Cleaning workflow Create a step-by-step workflow: - backup raw data - profile dataset - document assumptions - standardize schema - fix data types - handle missing values - remove or flag duplicates - standardize categories - validate ranges - check outliers - create clean dataset - produce quality report 4. Risk register Identify cleaning risks such as: - changing business meaning - deleting valid records - hiding data quality problems - over-cleaning outliers - merging distinct categories - creating false precision 5. Documentation template Create a cleaning log with: - issue - affected field - rows affected - action taken - reason - approval needed - validation result Rules: - Do not overwrite the raw dataset. - Do not clean values without documenting the rule. - Do not remove records before understanding business meaning. - The final plan must make the dataset trustworthy and the cleaning process auditable. --------------------------------------------------------------------------------

#042Missing Values Diagnosis and Treatment Plan

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI teams, data scientists, finance analysts, product analysts, operations analysts, spreadsheet users, and anyone working with incomplete datasets.

Diagnose missing values, understand why they occur, decide whether to impute, remove, flag, preserve, or escalate them, and document the impact.

Act as a missing data specialist. Analyze the missing values in my dataset and create a treatment plan that protects analytical accuracy. Dataset context: Dataset name: [DATASET NAME] Business question: [BUSINESS QUESTION] Critical fields: [CRITICAL FIELDS] Known missing fields: [MISSING FIELDS] Expected grain: [GRAIN] Data source: [SOURCE] Time period: [TIME PERIOD] Missing value examples: [EXAMPLES] Business rules: [BUSINESS RULES] Tool used: [TOOL] Analysis output: [OUTPUT] Build the missing value plan: A. Missingness profile For each field with missing values, create: - field name - missing count - missing percentage - business meaning of missing - whether missing is expected - affected segments - affected time periods - risk level B. Missingness diagnosis Classify likely missingness causes: - not collected - not applicable - system error - manual entry skipped - delayed entry - source mismatch - join failure - privacy masking - historical system change - true zero confused with blank C. Treatment options For each field recommend one of: - leave as missing - create missing flag - impute value - replace with default - use “not applicable” - remove records - exclude from specific metric - request source correction - escalate to data owner D. Impact analysis Explain how each treatment affects: - metric calculations - segmentation - trend analysis - model readiness - stakeholder interpretation - confidence level E. Documentation Create a missing value handling log. Rules: - Do not fill missing values just to make the dataset look complete. - Do not treat blank, zero, unknown, and not applicable as the same thing. - Do not remove rows without quantifying impact. - Use [NEEDS DATA OWNER REVIEW] where missingness requires business interpretation. --------------------------------------------------------------------------------

#043Duplicate Record Investigation System

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, analytics engineers, BI developers, CRM analysts, finance analysts, operations analysts, SQL users, spreadsheet users, and anyone preparing data with duplicate risks.

Detect, classify, and resolve duplicate records by understanding keys, grain, business rules, source behavior, and the analytical impact of deduplication.

You are a duplicate record investigation expert. Build a deduplication plan for the dataset below. Dataset context: Dataset name: [DATASET NAME] Business process represented: [PROCESS] Expected grain: [GRAIN] Primary key, if known: [PRIMARY KEY] Possible duplicate fields: [FIELDS] Known duplicate examples: [EXAMPLES] Business question: [QUESTION] Metrics affected: [METRICS] Source system: [SOURCE] Tool used: [TOOL] Investigate duplicates: 1. Duplicate definition Define what counts as a duplicate in this business context. Separate: - exact duplicate row - duplicate entity - duplicate transaction - duplicate event - duplicate customer - duplicate caused by join - valid repeated record 2. Detection checks Create checks for: - full-row duplicates - duplicate primary keys - duplicate business keys - near-duplicates - same entity with different IDs - same timestamp and value - repeated events - duplicates after joins 3. Classification table For each duplicate type include: - detection logic - likely cause - business meaning - metric risk - example - confidence level 4. Resolution rules Recommend how to handle: - keep first - keep latest - aggregate - merge records - flag duplicates - remove exact duplicate - preserve all records - escalate to source owner 5. Validation plan Define how to confirm deduplication did not break totals, counts, or business logic. 6. Documentation Create a deduplication log with rows affected and rule applied. Rules: - Do not remove duplicate-looking records before confirming grain. - Do not deduplicate events the business intentionally records multiple times. - Do not use only one field unless it is a validated unique key. - The final deduplication plan must protect metrics from inflation or accidental loss. --------------------------------------------------------------------------------

#044Data Type and Format Standardization Planner

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI analysts, spreadsheet users, Python/R users, SQL analysts, analytics engineers, and anyone preparing data from multiple systems or messy exports.

Standardize inconsistent formats for dates, numbers, text, currencies, IDs, categories, booleans, and units before analysis.

Act as a data standardization specialist. Create a format standardization plan for the dataset below. Dataset context: Dataset name: [DATASET NAME] Source systems: [SOURCES] Fields with format issues: [FIELDS] Sample values: [SAMPLE VALUES] Analysis goal: [GOAL] Expected output tool: [OUTPUT TOOL] Locale or region: [LOCALE] Currency or unit rules: [RULES] Known formatting problems: [PROBLEMS] Create the standardization plan: A. Field format audit Review each field type: - dates - timestamps - numbers - percentages - currencies - IDs - text fields - category labels - booleans - phone numbers - emails - addresses - units of measure For each field include: - current observed formats - target format - transformation rule - validation rule - risk if standardized incorrectly B. Date and time rules Define: - date format - timezone - timestamp precision - start/end date logic - fiscal calendar handling - invalid date handling C. Numeric rules Define: - decimal separator - thousands separator - rounding - negative values - percentage conversion - currency conversion - unit conversion D. Text rules Define: - trimming whitespace - case standardization - special characters - spelling variants - category mapping - null-like text values E. QA checks Create checks to confirm standardization worked. Rules: - Do not convert formats without preserving original values when risk is high. - Do not assume dates are in one locale without validation. - Do not mix currencies, units, or timezones without explicit conversion. - The final dataset must be consistent, readable, and analysis-ready. --------------------------------------------------------------------------------

#045Category and Label Normalization Engine

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, CRM analysts, marketing analysts, operations teams, survey analysts, product analysts, spreadsheet users, BI developers, and data quality projects.

Normalize inconsistent categorical values, spelling variants, labels, statuses, segments, and manually entered text categories.

You are a categorical data normalization expert. Build a normalization plan for inconsistent labels in my dataset. Dataset context: Dataset name: [DATASET NAME] Categorical fields: [FIELDS] Sample values: [SAMPLE VALUES] Business meaning: [BUSINESS MEANING] Current problem: [PROBLEM] Expected categories: [EXPECTED CATEGORIES] Source system: [SOURCE] Analysis use: [USE CASE] Stakeholder definitions: [DEFINITIONS] Create the normalization system: 1. Category profile For each categorical field identify: - unique values - value counts - spelling variants - capitalization variants - abbreviations - null-like values - deprecated labels - unexpected values - low-frequency values 2. Mapping table Create a category mapping table with: - raw value - standardized value - category group - business definition - confidence level - approval needed - notes 3. Business rule classification Classify category decisions as: - obvious formatting cleanup - business definition required - data owner approval required - should remain separate - should be grouped - should be flagged as unknown 4. Normalization rules Define rules for: - case - whitespace - spelling - abbreviations - synonyms - old vs new labels - “other” categories - unknown values 5. Validation Create checks to verify: - no unexpected categories remain - totals still reconcile - business meaning preserved - grouped categories are accepted by stakeholders Rules: - Do not merge categories that have different business meanings. - Do not hide rare but important values inside “other” without review. - Do not assume similar labels are equivalent. - The final mapping must be transparent and reusable. --------------------------------------------------------------------------------

#046Outlier Detection and Business Review Plan

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, finance analysts, operations analysts, product analysts, data scientists, BI teams, and anyone preparing numeric or behavioral data for analysis.

Detect outliers, distinguish valid extreme values from errors, assess business meaning, and decide whether to keep, cap, flag, exclude, or investigate.

Act as an outlier investigation analyst. Create an outlier detection and treatment plan for my dataset. Dataset context: Dataset name: [DATASET NAME] Business question: [QUESTION] Numeric fields to check: [FIELDS] Expected ranges: [EXPECTED RANGES] Known extreme values: [EXAMPLES] Time period: [TIME PERIOD] Segments: [SEGMENTS] Metrics affected: [METRICS] Tool used: [TOOL] Business rules: [BUSINESS RULES] Create the outlier plan: A. Outlier definition Define outliers by: - statistical method - business rules - valid range - historical behavior - segment-specific expectations - operational constraints B. Detection methods Recommend methods such as: - min/max checks - percentile thresholds - IQR - z-score - rolling averages - segment-level comparison - time-series spike detection - business rule validation C. Outlier review table For each outlier type include: - field - detection rule - rows affected - possible cause - business interpretation - metric impact - recommended action - owner to review - confidence level D. Treatment options Recommend when to: - keep - flag - exclude - cap or winsorize - correct from source - separate in analysis - investigate manually E. Stakeholder explanation Write a plain-language note explaining how outliers will be handled. Rules: - Do not delete outliers only because they are extreme. - Do not cap values without explaining business impact. - Do not use one statistical rule for all segments if behavior differs. - Outlier handling must be documented and defensible. --------------------------------------------------------------------------------

#047Accuracy Validation Against Source of Truth

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI teams, analytics engineers, finance analysts, operations analysts, dashboard builders, and consultants validating data before reporting.

Validate dataset accuracy by comparing against trusted systems, totals, sample records, business reports, and data owner expectations.

You are a data accuracy validation specialist. Create a validation plan to compare my dataset against the correct source of truth. Validation context: Dataset to validate: [DATASET] Source of truth: [SOURCE OF TRUTH] Business process: [PROCESS] Key metrics: [METRICS] Critical fields: [FIELDS] Expected totals: [EXPECTED TOTALS] Sample records: [SAMPLE RECORDS] Time period: [TIME PERIOD] Stakeholders: [STAKEHOLDERS] Known discrepancies: [DISCREPANCIES] Build the validation plan: 1. Source of truth confirmation Clarify: - official source - owner - refresh cadence - business definition - known limitations - approval contact 2. Reconciliation checks Create checks for: - row counts - total amounts - unique entity counts - date-level totals - segment totals - status counts - key metric values - sample record match 3. Field-level validation For each critical field define: - expected source - allowed values - range check - sample check - transformation check - mismatch threshold 4. Discrepancy investigation Create a process to investigate differences: - timing difference - filter difference - definition difference - join issue - duplicate issue - missing records - transformation error - source update delay 5. Validation report Create a report template with: - check - result - variance - explanation - risk - action - approval status Rules: - Do not assume a transformed dataset is accurate because code ran successfully. - Do not compare totals without matching filters and definitions. - Do not hide unexplained discrepancies. - Accuracy validation must happen before stakeholder-facing analysis. --------------------------------------------------------------------------------

#048Cleaning Decision Log Generator

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, analytics engineers, compliance-heavy teams, finance analysts, consultants, BI developers, research analysts, and anyone documenting data preparation.

Create a detailed log of cleaning decisions, transformation rules, assumptions, approvals, and validation results so analysis is auditable and reproducible.

Act as a data preparation documentation specialist. Create a cleaning decision log for the dataset preparation work below. Preparation context: Dataset name: [DATASET] Analysis project: [PROJECT] Raw data source: [SOURCE] Cleaning steps performed or planned: [STEPS] Fields affected: [FIELDS] Known issues: [ISSUES] Stakeholders or reviewers: [REVIEWERS] Tool used: [TOOL] Version or date: [VERSION / DATE] Create the cleaning log structure: A. Dataset version record Include: - raw dataset location - clean dataset location - version number - date prepared - prepared by - review status - approved by B. Cleaning decision table For each cleaning action include: - issue ID - issue description - affected field - affected rows - rule applied - reason - alternative considered - approval needed - validation performed - result - risk - notes C. Assumption log Document assumptions about: - missing values - duplicates - categories - outliers - dates - currency - units - business rules - filters D. Reproducibility notes Explain: - code or formula location - manual steps - dependencies - order of operations - rollback method E. Stakeholder summary Write a short summary of major cleaning decisions in business language. Rules: - Do not make undocumented manual changes. - Do not mix raw and cleaned data without version labels. - Do not hide assumptions inside code only. - The log must allow another analyst to understand and reproduce the cleaning process. --------------------------------------------------------------------------------

#049Data Cleaning SQL Plan

DATA CLEANING, PREPARATION & QUALITY CHECKSSQL analysts, BI developers, analytics engineers, data analysts, warehouse users, and teams preparing data in databases before analysis.

Translate data cleaning requirements into a SQL-based preparation plan with staging tables, validation checks, transformations, and final clean output logic.

You are a SQL data preparation architect. Create a SQL cleaning plan for the dataset and issues below. SQL context: Database or warehouse: [DATABASE / WAREHOUSE] Raw table: [RAW TABLE] Expected clean table: [CLEAN TABLE] Business purpose: [PURPOSE] Primary key: [PRIMARY KEY] Expected grain: [GRAIN] Fields to clean: [FIELDS] Known issues: [ISSUES] Metrics affected: [METRICS] SQL dialect: [POSTGRES / BIGQUERY / SNOWFLAKE / SQL SERVER / MYSQL / OTHER] Build the SQL plan: 1. Staging approach Design: - raw table preservation - staging table - cleaned table - validation views - audit table, if needed 2. Cleaning transformations Create SQL-ready logic for: - trimming text - standardizing case - parsing dates - converting data types - handling null-like values - standardizing categories - removing exact duplicates - flagging duplicate keys - validating numeric ranges - flagging outliers - creating quality flags 3. Validation queries Write query templates for: - row count comparison - duplicate check - null check - category check - min/max check - join key check - metric reconciliation 4. Final output schema Define the clean table fields: - field name - type - source - transformation - quality flag - business meaning 5. Deployment notes Explain how to run, review, and document the cleaning process. Rules: - Do not update raw tables directly. - Do not delete rows without creating a rejected or flagged record log. - Do not assume SQL dialect functions are identical; mark dialect-specific areas. - The plan must produce a clean table and validation evidence. --------------------------------------------------------------------------------

#050Data Cleaning Python Workflow Builder

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, data scientists, Python users, pandas workflows, notebook users, analytics teams, research analysts, and anyone cleaning files programmatically.

Create a Python-based data cleaning workflow with profiling, transformations, validation, logging, and export-ready cleaned data.

Act as a Python data cleaning workflow designer. Create a structured cleaning workflow for the dataset below. Python context: Dataset file or source: [FILE / SOURCE] File format: [CSV / XLSX / JSON / PARQUET / OTHER] Analysis goal: [GOAL] Expected grain: [GRAIN] Key columns: [KEY COLUMNS] Known issues: [ISSUES] Column list: [COLUMNS] Sample rows: [SAMPLE ROWS] Output format needed: [OUTPUT FORMAT] Environment: [JUPYTER / SCRIPT / NOTEBOOK / OTHER] Create the Python workflow: A. Project structure Recommend: - raw data folder - processed data folder - notebook or script name - logs folder - output file - data dictionary file B. Cleaning steps Create a workflow using pandas-style logic for: - load data - inspect schema - standardize column names - convert data types - handle missing values - clean strings - parse dates - remove or flag duplicates - normalize categories - validate numeric ranges - detect outliers - create quality flags - export cleaned data C. Code skeleton Write a clean Python code skeleton with comments and placeholders. D. Validation checks Create checks for: - row count - null counts - duplicates - unique categories - date ranges - numeric ranges - expected keys - metric reconciliation E. Cleaning report Create a report structure summarizing actions and issues. Rules: - Do not overwrite the raw file. - Do not silently drop rows. - Do not hard-code business rules without comments. - The workflow must be reproducible, readable, and auditable. --------------------------------------------------------------------------------

#051Spreadsheet Data Cleaning Checklist

DATA CLEANING, PREPARATION & QUALITY CHECKSBusiness analysts, operations teams, finance users, marketers, small business owners, spreadsheet-heavy teams, junior analysts, and non-technical users.

Create a practical cleaning checklist for Excel or Google Sheets users working with messy data without advanced coding tools.

You are a spreadsheet data cleaning coach. Create a step-by-step cleaning checklist for preparing messy spreadsheet data for analysis. Spreadsheet context: Tool: [EXCEL / GOOGLE SHEETS] Dataset purpose: [PURPOSE] Sheet structure: [STRUCTURE] Number of rows: [ROWS] Number of columns: [COLUMNS] Known issues: [ISSUES] Key fields: [KEY FIELDS] Expected final output: [OUTPUT] User skill level: [BEGINNER / INTERMEDIATE / ADVANCED] Create the checklist: 1. Safety setup Include: - duplicate original file - create raw tab - create clean tab - freeze headers - add cleaning log tab - protect formulas if needed 2. Structure cleanup Check: - merged cells - blank rows - repeated headers - inconsistent columns - hidden rows or filters - totals mixed with raw data - notes inside data cells 3. Field cleanup Create steps for: - trimming spaces - standardizing dates - converting numbers - fixing currency format - standardizing text case - normalizing categories - handling blanks - checking duplicates 4. Validation checks Create spreadsheet-friendly checks for: - duplicates - missing values - invalid categories - impossible values - date ranges - totals reconciliation - formula errors 5. Final readiness checklist Confirm: - one row per record - one column per field - clear headers - no mixed data types - no hidden calculations - clean export-ready format Rules: - Do not edit the only copy of the data. - Do not use formatting as data. - Do not leave totals or notes mixed inside the dataset. - The checklist must be usable by someone cleaning data manually. --------------------------------------------------------------------------------

#052Data Quality Rule Library Builder

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI teams, analytics engineers, data governance teams, operations analysts, finance analysts, and organizations standardizing quality checks.

Create reusable data quality rules for a dataset, metric, report, dashboard, or recurring pipeline.

Act as a data quality rule designer. Build a reusable quality rule library for [DATASET / DOMAIN]. Quality context: Dataset or domain: [DATASET / DOMAIN] Business process: [PROCESS] Critical metrics: [METRICS] Critical fields: [FIELDS] Known issues: [ISSUES] Data owner: [OWNER] Refresh cadence: [CADENCE] Risk level: [LOW / MEDIUM / HIGH] Tool environment: [SQL / PYTHON / BI / DATA QUALITY TOOL / OTHER] Create the rule library: A. Rule categories Create rules for: - completeness - uniqueness - validity - consistency - accuracy - freshness - referential integrity - business logic - range checks - format checks - anomaly checks B. Rule table For each rule include: - rule ID - rule name - field or table - rule logic - expected result - warning threshold - failure threshold - severity - owner - action if failed - review cadence C. Business rules Create rules based on business logic such as: - valid status transitions - date order - positive amounts - allowed categories - closed records cannot change - completed records need completion date - active records need owner D. Alert design Define when alerts should go to: - analyst - data owner - engineer - business stakeholder E. Rule maintenance Create a process for adding, changing, and retiring rules. Rules: - Do not create rules nobody will act on. - Do not make every failure equally urgent. - Do not use purely technical rules when business logic matters. - The library must be reusable, prioritized, and operational. --------------------------------------------------------------------------------

#053Data Preparation for Dashboard Readiness

DATA CLEANING, PREPARATION & QUALITY CHECKSBI analysts, dashboard developers, Power BI/Tableau/Looker users, data analysts, analytics engineers, and teams building recurring reporting.

Prepare data specifically for dashboarding by cleaning fields, defining metrics, creating dimensions, validating refresh logic, and preventing misleading visuals.

You are a BI data preparation specialist. Prepare the dataset for a dashboard that business users can trust. Dashboard context: Dashboard name: [DASHBOARD] Business users: [USERS] Business decisions supported: [DECISIONS] Source datasets: [DATASETS] Metrics: [METRICS] Dimensions: [DIMENSIONS] Refresh cadence: [CADENCE] BI tool: [POWER BI / TABLEAU / LOOKER / OTHER] Known data issues: [ISSUES] Expected filters: [FILTERS] Create the dashboard data readiness plan: 1. Dashboard grain Define the required grain for dashboard tables. 2. Metric preparation For each metric define: - formula - source fields - filters - aggregation level - date logic - guardrails - validation check 3. Dimension preparation For each dimension define: - source field - standardized values - hierarchy - grouping logic - unknown handling - filter behavior 4. Data model readiness Plan: - fact tables - dimension tables - relationships - date table - join keys - refresh logic - row-level security, if needed 5. Dashboard QA checks Create checks for: - totals vs source - filters - drilldowns - date ranges - missing categories - duplicate rows - refresh timestamp - stakeholder sanity check 6. User trust notes Write dashboard caveats and definitions for business users. Rules: - Do not build visuals before metric definitions are validated. - Do not use raw messy categories as filters. - Do not hide refresh time or data limitations. - The prepared data must support accurate, stable dashboard reporting. --------------------------------------------------------------------------------

#054Clean Data Acceptance Criteria Builder

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, analytics managers, consultants, BI teams, data quality teams, finance analysts, and anyone needing to decide when data is ready.

Define what “clean enough” means for a specific analysis, including thresholds, required validations, known limitations, and stakeholder sign-off.

Act as a data readiness acceptance criteria designer. Define what must be true before this dataset is approved for analysis. Project context: Analysis project: [PROJECT] Dataset: [DATASET] Business question: [QUESTION] Critical metrics: [METRICS] Critical fields: [FIELDS] Stakeholders: [STAKEHOLDERS] Risk level: [LOW / MEDIUM / HIGH] Known issues: [ISSUES] Deadline: [DEADLINE] Output use: [INTERNAL / EXECUTIVE / CUSTOMER-FACING / REGULATORY / OTHER] Create acceptance criteria: A. Readiness definition Write what “analysis-ready” means for this dataset. B. Must-pass checks Define required checks for: - schema - row count - critical field completeness - duplicate keys - valid date range - valid categories - numeric ranges - join integrity - metric reconciliation - source-of-truth comparison C. Thresholds Create thresholds for: - acceptable missingness - duplicate tolerance - variance vs source - stale data tolerance - outlier review requirement - unmatched join percentage D. Conditional approval Define when analysis can proceed with caveats. E. Rejection criteria Define when analysis must stop. F. Sign-off Create an approval checklist for: - analyst - data owner - stakeholder - privacy or compliance reviewer, if needed Rules: - Do not require perfect data when “fit for purpose” is enough. - Do not approve data if critical issues can change conclusions. - Do not hide caveats from decision-makers. - Acceptance criteria must match business risk and analysis use. --------------------------------------------------------------------------------

#055Dirty Data Root Cause Analysis

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, data quality teams, operations teams, analytics engineers, process owners, BI teams, and organizations fixing recurring data issues.

Investigate why data quality problems exist by tracing them back to source systems, processes, ownership, training, validation rules, or manual entry.

You are a data quality root cause analyst. Investigate why the data quality issue below keeps happening and recommend prevention. Issue context: Data quality issue: [ISSUE] Dataset or field: [DATASET / FIELD] Business process: [PROCESS] Source system: [SYSTEM] How issue was discovered: [DISCOVERY] Frequency: [FREQUENCY] Rows affected: [ROWS AFFECTED] Business impact: [IMPACT] Current workaround: [WORKAROUND] Teams involved: [TEAMS] Known process steps: [STEPS] Run the root cause analysis: 1. Issue definition Describe the issue in measurable terms. 2. Impact assessment Explain impact on: - metrics - dashboards - decisions - operations - customers - compliance - analyst time 3. Root cause hypotheses Create hypotheses across: - source system design - missing validation rules - manual entry error - unclear definitions - process workaround - delayed updates - integration failure - duplicate process - ownership gap - training gap 4. Evidence plan For each hypothesis include: - evidence to collect - person to ask - system check - data check - confidence level 5. Prevention plan Recommend fixes: - system validation - required fields - dropdowns - training - process change - automated checks - ownership assignment - documentation - exception handling 6. Escalation summary Write a concise message to the data owner or process owner. Rules: - Do not treat cleaning as the only solution. - Do not blame users before checking system and process design. - Do not fix symptoms without preventing recurrence. - The final plan should reduce future data quality issues. --------------------------------------------------------------------------------

#056Clean Dataset Handoff Package

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, consultants, analytics engineers, BI teams, research analysts, finance analysts, and anyone sharing cleaned data with another person or team.

Create a professional handoff package for a cleaned dataset with documentation, assumptions, transformations, quality checks, known limitations, and usage guidance.

Act as a data handoff documentation specialist. Create a complete handoff package for a cleaned dataset. Handoff context: Clean dataset name: [DATASET] Raw source: [RAW SOURCE] Analysis project: [PROJECT] Prepared by: [PREPARED BY] Prepared for: [AUDIENCE] Cleaning date: [DATE] Tool used: [TOOL] Fields included: [FIELDS] Rows included: [ROWS] Known limitations: [LIMITATIONS] Expected use: [USE] Do not use for: [DO NOT USE FOR] Create the handoff package: A. Dataset summary Include: - purpose - source - grain - time coverage - refresh status - key fields - intended users - intended analysis use B. Transformation summary Document: - fields renamed - fields removed - data type conversions - missing value handling - duplicate handling - category normalization - outlier treatment - derived fields - filters applied C. Quality check results Report: - row count validation - completeness checks - duplicate checks - range checks - category checks - source reconciliation - known unresolved issues D. Data dictionary Create field documentation for included columns. E. Usage notes Explain: - recommended filters - caveats - common misuse risks - metrics supported - metrics not supported - next refresh or update process F. Sign-off section Create approval fields for analyst, reviewer, and stakeholder. Rules: - Do not hand off data without explaining cleaning decisions. - Do not imply the dataset is suitable for every use case. - Do not omit known limitations. - The handoff package must make reuse safe and transparent. --------------------------------------------------------------------------------

#057Pre-Modeling Data Preparation Checklist

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, data scientists, ML practitioners, analytics teams, forecasting analysts, experimentation teams, and anyone moving from cleaned data to modeling.

Prepare data for modeling or advanced analysis by checking target leakage, feature consistency, missingness, outliers, encoding, sampling, and train-test readiness.

You are a pre-modeling data preparation reviewer. Check whether the dataset is ready for modeling or advanced statistical analysis. Modeling context: Business problem: [PROBLEM] Modeling goal: [GOAL] Target variable: [TARGET] Dataset: [DATASET] Features: [FEATURES] Time period: [TIME PERIOD] Prediction horizon: [HORIZON] Unit of analysis: [UNIT] Known missing values: [MISSING] Known outliers: [OUTLIERS] Model type planned: [MODEL TYPE] Business constraints: [CONSTRAINTS] Create the preparation checklist: 1. Target definition Check: - target meaning - target availability - target timing - target leakage risk - class balance - business relevance 2. Feature readiness Evaluate: - feature definitions - data types - missing values - outliers - categorical encoding - numeric scaling needs - high-cardinality fields - text fields - date-derived features - leakage risk 3. Dataset split readiness Define: - train/test split - time-based split, if needed - validation set - leakage prevention - segment representation 4. Quality checks Create checks for: - duplicates - inconsistent labels - impossible values - missing target - rare categories - distribution shifts - sampling bias 5. Modeling caveats Identify what must be fixed before modeling and what can be handled during modeling. Rules: - Do not move into modeling before target timing is clear. - Do not include features that would not be available at prediction time. - Do not ignore sampling bias or class imbalance. - The dataset must be prepared for trustworthy modeling, not just technically accepted. --------------------------------------------------------------------------------

#058Data Cleaning Code Review Checklist

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, analytics engineers, Python users, SQL users, spreadsheet reviewers, BI teams, data science teams, and anyone checking data preparation work.

Review cleaning code or formulas for correctness, reproducibility, hidden assumptions, destructive steps, edge cases, and validation coverage.

Act as a data cleaning code reviewer. Review the cleaning logic below and identify risks, bugs, missing validations, and documentation gaps. Cleaning logic: [PASTE SQL / PYTHON / R / FORMULAS / WORKFLOW STEPS] Context: Dataset: [DATASET] Business purpose: [PURPOSE] Expected grain: [GRAIN] Key metrics affected: [METRICS] Known data issues: [ISSUES] Tool or language: [TOOL / LANGUAGE] Expected output: [OUTPUT] Risk level: [LOW / MEDIUM / HIGH] Review the cleaning logic: A. Correctness review Check for: - wrong filters - destructive operations - incorrect joins - wrong date parsing - wrong data type conversions - row loss - row multiplication - missing null handling - bad category mapping - invalid deduplication - outlier over-removal B. Reproducibility review Check: - hard-coded paths - undocumented manual steps - unstable sorting - non-deterministic logic - missing versioning - no raw backup - no cleaning log C. Validation review Check whether code validates: - row counts - null counts - duplicates - category values - numeric ranges - joins - metric totals - source reconciliation D. Documentation review Identify missing comments, assumptions, and business rule explanations. E. Improvement plan Provide: - critical fixes - recommended fixes - optional improvements - tests to add - approval questions Rules: - Do not rewrite code unless asked; focus on review and improvement. - Do not approve code that changes raw data without backup. - Do not ignore business meaning. - The review must protect analysis from silent cleaning errors. --------------------------------------------------------------------------------

#059Data Quality Issue Stakeholder Communication

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, analytics managers, BI teams, consultants, finance analysts, operations analysts, and anyone explaining data problems to non-technical stakeholders.

Communicate data quality issues clearly to business stakeholders, explaining impact, limitations, actions, timelines, and decision risks without overloading them with technical detail.

You are a business-facing data quality communicator. Draft a clear stakeholder update about a data quality issue affecting analysis. Issue context: Analysis project: [PROJECT] Stakeholder audience: [AUDIENCE] Data quality issue: [ISSUE] Affected dataset or metric: [DATASET / METRIC] How it was discovered: [DISCOVERY] Business impact: [IMPACT] Rows or period affected: [SCOPE] Current confidence level: [CONFIDENCE] Actions already taken: [ACTIONS TAKEN] Next steps: [NEXT STEPS] Decision deadline: [DEADLINE] Help needed: [HELP NEEDED] Create the communication package: A. Short update Write a concise message for Slack, Teams, or email. B. Detailed explanation Write a business-friendly explanation covering: - what happened - what data is affected - what analysis is impacted - what is still reliable - what is not reliable yet - what action is being taken - when the next update will happen C. Decision risk statement Explain what risk exists if stakeholders use the affected data now. D. Options Provide options: - proceed with caveat - wait for correction - use proxy data - narrow scope - exclude affected period - escalate to data owner E. Questions for stakeholder Ask what decision tradeoff they prefer. Rules: - Do not hide the issue. - Do not use overly technical language. - Do not create panic if the issue is limited. - Communication should preserve trust and support informed decisions. --------------------------------------------------------------------------------

#060Full Data Cleaning, Preparation and Quality Audit

DATA CLEANING, PREPARATION & QUALITY CHECKSData analysts, BI teams, analytics engineers, data scientists, consultants, finance analysts, operations analysts, product analysts, and anyone preparing data for trustworthy analysis.

Audit and rebuild the full data preparation process across missing values, duplicates, formats, outliers, validation, documentation, reproducibility, and readiness.

Act as an independent data cleaning, preparation, and quality auditor. Review my dataset preparation process and rebuild it into a trustworthy, documented, reproducible cleaning workflow. Full context: Dataset name: [DATASET] Business question: [QUESTION] Analysis goal: [GOAL] Source system or file: [SOURCE] Expected grain: [GRAIN] Key fields: [FIELDS] Critical metrics: [METRICS] Known data issues: [KNOWN ISSUES] Cleaning already performed: [CLEANING PERFORMED] Tool used: [TOOL] Sample rows or schema: [SAMPLE / SCHEMA] Expected output: [OUTPUT] Stakeholders: [STAKEHOLDERS] Risk level: [LOW / MEDIUM / HIGH] Deadline: [DEADLINE] Audit across 60 dimensions: 1. Raw data preservation 2. Dataset grain clarity 3. Schema inspection 4. Column naming 5. Data type correctness 6. Date parsing 7. Timestamp and timezone handling 8. Numeric field conversion 9. Currency handling 10. Unit consistency 11. Text cleanup 12. Category normalization 13. Status value mapping 14. Missing value profiling 15. Missing value treatment 16. Null meaning 17. Zero vs missing distinction 18. Duplicate detection 19. Deduplication logic 20. Primary key validation 21. Join key validation 22. Row count validation 23. Row loss detection 24. Row multiplication detection 25. Outlier detection 26. Outlier treatment 27. Business range checks 28. Impossible value checks 29. Referential integrity 30. Source reconciliation 31. Metric reconciliation 32. Segment validation 33. Time period coverage 34. Freshness 35. Historical consistency 36. Source of truth comparison 37. Manual correction logging 38. Transformation documentation 39. Cleaning decision log 40. Assumption documentation 41. Reproducibility 42. Code or formula review 43. Version control 44. Audit trail 45. Privacy-safe handling 46. Sensitive field masking 47. Data quality rules 48. Data quality thresholds 49. Acceptance criteria 50. Stakeholder caveats 51. Data owner review 52. Analyst handoff readiness 53. Dashboard readiness 54. Modeling readiness 55. Spreadsheet safety 56. SQL workflow safety 57. Python workflow safety 58. Cleaning risk level 59. Rework risk 60. Overall analysis readiness For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - analysis risk if ignored - business risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current dataset may not be trustworthy yet. B. Rebuilt cleaning workflow Create: - raw data protection plan - profiling plan - missing value plan - duplicate plan - standardization plan - category normalization plan - outlier plan - validation plan - quality rule library - cleaning log - final acceptance criteria C. First 10 cleaning actions Rank the first 10 actions to complete. For each include: - action - field or table affected - why it matters - validation check - owner - expected result D. Quality report template Create a stakeholder-ready data quality report with: - summary - issues found - rows affected - actions taken - unresolved risks - approved caveats - readiness status E. Analyst execution checklist Create a step-by-step checklist for cleaning the dataset in order. F. Executive summary Write a direct summary with: - strongest part of the data - weakest quality issue - first validation check to run - biggest missing value risk - biggest duplicate risk - biggest format risk - biggest stakeholder caveat - one operating principle for data cleaning Rules: - Do not overwrite raw data. - Do not remove or change values without documenting the rule. - Do not approve analysis if critical quality issues can change decisions. - Use [NEEDS DATA OWNER REVIEW], [NEEDS SOURCE VALIDATION], [NEEDS QUALITY CHECK], [NEEDS STAKEHOLDER APPROVAL], or [NEEDS PRIVACY REVIEW] where required. - The final workflow should make the data clean, documented, reproducible, and trustworthy for analysis.

#061First-Look Dataset Profiling Analyst

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, BI analysts, business analysts, data scientists, consultants, students, and anyone starting EDA on a new dataset.

Create a structured first-look exploration of a dataset to understand its shape, fields, distributions, missingness, risks, and early analytical opportunities.

You are a senior data analyst performing the first exploratory review of a dataset. Your job is to understand what is inside the data before jumping into conclusions, charts, or modeling. Dataset context: Dataset name: [DATASET NAME] Business question: [BUSINESS QUESTION] Business area: [BUSINESS AREA] Dataset source: [SOURCE] Expected grain: [GRAIN] Rows and columns, if known: [ROWS / COLUMNS] Key fields: [KEY FIELDS] Target metric or outcome: [TARGET METRIC] Time period: [TIME PERIOD] Stakeholders: [STAKEHOLDERS] Tool used: [SQL / PYTHON / R / EXCEL / BI TOOL] Known concerns: [CONCERNS] Run a first-look EDA: 1. Dataset structure review Profile: - row count - column count - column names - data types - expected grain - key identifiers - date fields - categorical fields - numeric fields - text fields - potential target variables 2. Data completeness review Identify: - missing values - missing value percentage - fields with unusual blanks - fields that should never be missing - rows with many missing values - possible missingness patterns 3. Uniqueness and grain check Check: - primary key candidates - duplicate records - one row represents what - repeated IDs - duplicate business keys - unexpected row multiplication risks 4. Early distribution review For key numeric fields, summarize: - min - max - mean - median - standard deviation - percentiles - skew - suspicious values For categorical fields, summarize: - unique count - top categories - rare categories - unexpected categories - category imbalance 5. Early insight opportunities Create a list of 10 promising EDA directions. For each include: - pattern to investigate - business reason - fields needed - recommended chart or table - risk of misinterpretation 6. Readiness summary Classify the dataset as: - ready for EDA - ready with caveats - needs cleaning first - needs data owner review - not ready Rules: - Do not interpret patterns before checking dataset structure. - Do not assume column names reflect business meaning. - Do not ignore missingness, grain, or duplicates. - The output should give a safe foundation for deeper EDA. --------------------------------------------------------------------------------

#062Distribution and Shape Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, data scientists, BI teams, finance analysts, product analysts, operations analysts, marketing analysts, and anyone understanding variable behavior before analysis.

Explore the shape, spread, skew, concentration, tails, and unusual values in numerical and categorical variables.

Act as a distribution analysis specialist. Explore the distribution patterns in the dataset fields below and explain what they may mean for business analysis. Data context: Dataset: [DATASET] Business question: [QUESTION] Numeric fields: [NUMERIC FIELDS] Categorical fields: [CATEGORICAL FIELDS] Segments to compare: [SEGMENTS] Time period: [TIME PERIOD] Expected ranges: [EXPECTED RANGES] Known business rules: [BUSINESS RULES] Tool used: [TOOL] Analyze distributions: A. Numeric distribution profile For each numeric field, evaluate: - min and max - mean and median - quartiles - spread - skew - long tail - zero values - negative values - extreme values - clustering - unusual gaps B. Categorical distribution profile For each categorical field, evaluate: - number of unique values - top categories - long-tail categories - dominant category share - rare categories - unexpected labels - imbalance - unknown or missing categories C. Segment comparison Compare distributions across key segments. For each segment difference include: - what changed - possible business meaning - whether the difference is large enough to investigate - what could explain it - what data quality issue could mimic it D. Visual plan Recommend the best visuals: - histogram - boxplot - density plot - bar chart - Pareto chart - violin plot - percentile table - cumulative distribution E. Business interpretation Translate distribution patterns into possible actions or questions. Rules: - Do not rely only on averages. - Do not ignore skew and long tails. - Do not treat rare categories as useless without checking business value. - Distribution analysis should reveal how the data behaves before deeper analysis. --------------------------------------------------------------------------------

#063Time Trend and Movement Scanner

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, BI analysts, finance analysts, product analysts, marketing analysts, operations teams, growth teams, and anyone analyzing time-based data.

Explore how metrics change over time, detect direction, volatility, step changes, momentum, dips, peaks, and unusual periods.

You are a time trend exploration analyst. Scan the dataset for meaningful movement over time and separate real patterns from noise or data issues. Time-series context: Dataset: [DATASET] Date field: [DATE FIELD] Metric fields: [METRICS] Business question: [QUESTION] Time grain: [DAILY / WEEKLY / MONTHLY / QUARTERLY] Time period: [TIME PERIOD] Important events: [EVENTS] Segments: [SEGMENTS] Known data gaps: [GAPS] Reporting calendar: [CALENDAR] Run the trend scan: 1. Time coverage check Verify: - earliest date - latest date - missing periods - incomplete recent periods - irregular frequency - timezone issues - reporting calendar issues 2. Metric trend review For each metric identify: - overall direction - growth or decline rate - volatility - spikes - dips - plateaus - step changes - recovery periods - unusual periods 3. Period comparison Compare: - current period vs previous period - current period vs same period last year - rolling average vs actual - before and after key events - weekday vs weekend, if relevant 4. Segment trend comparison Identify which segments are driving movement. Include: - segment name - direction - contribution to total change - whether pattern is unique or broad-based 5. Anomaly candidates Flag time periods requiring investigation. For each include: - date or period - metric affected - size of change - possible business cause - possible data quality cause - recommended follow-up 6. Insight summary Write a concise trend narrative for stakeholders. Rules: - Do not interpret incomplete recent data as a full trend. - Do not compare non-equivalent periods. - Do not ignore business events or system changes. - Trend exploration should explain what changed, when, and where to look next. --------------------------------------------------------------------------------

#064Segment Discovery and Comparison Map

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYProduct analysts, marketing analysts, customer analysts, revenue analysts, BI teams, consultants, operations analysts, and growth teams.

Discover meaningful differences across customer, product, region, channel, cohort, behavior, or operational segments.

Act as a segmentation discovery analyst. Explore the dataset to find meaningful segment-level differences that may explain business performance. Analysis context: Business question: [QUESTION] Primary metric: [METRIC] Possible segment fields: [SEGMENT FIELDS] Dataset: [DATASET] Time period: [TIME PERIOD] Business goal: [GOAL] Known segments: [KNOWN SEGMENTS] Stakeholder assumptions: [ASSUMPTIONS] Minimum segment size: [MINIMUM SIZE] Create the segment discovery map: A. Candidate segment scan Evaluate segment fields such as: - customer type - acquisition channel - geography - product - plan - lifecycle stage - cohort - device - behavior level - sales rep - store - region - campaign - support tier For each segment field include: - number of categories - coverage - business relevance - data quality concerns - whether it is worth comparing B. Segment performance table For top candidate segments, compare: - count - share of total - primary metric - secondary metric - change over time - contribution to overall result - difference from average - confidence level C. Segment pattern types Classify findings as: - high-value segment - underperforming segment - fast-growing segment - declining segment - volatile segment - small but important segment - data-quality-risk segment D. Follow-up questions Create 15 follow-up questions based on segment differences. E. Stakeholder summary Write a business-friendly summary of which segments deserve deeper analysis. Rules: - Do not overinterpret tiny segments. - Do not compare segments without checking sample size. - Do not assume segment difference means causation. - Segment discovery should reveal where performance differs and why that may matter. --------------------------------------------------------------------------------

#065Anomaly and Spike Triage System

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, monitoring teams, BI analysts, product analysts, operations teams, finance analysts, risk teams, and dashboard owners.

Detect unusual values, spikes, drops, sudden shifts, and strange records, then triage whether they are business events, data errors, or investigation leads.

You are an anomaly triage analyst. Find and classify unusual patterns in the dataset so the team knows what needs investigation. Anomaly context: Dataset: [DATASET] Metric or field: [METRIC / FIELD] Time period: [TIME PERIOD] Normal behavior, if known: [NORMAL BEHAVIOR] Segments: [SEGMENTS] Known events: [EVENTS] Known data issues: [DATA ISSUES] Business impact area: [IMPACT AREA] Urgency level: [URGENCY] Run anomaly triage: 1. Anomaly detection setup Define anomaly candidates using: - historical average - rolling average - percentage change - standard deviation - percentile threshold - business rule - segment comparison - peer comparison - sudden record-level change 2. Anomaly list For each anomaly include: - date or record - metric affected - actual value - expected value or baseline - absolute difference - percentage difference - segment affected - severity - confidence 3. Classification Classify each anomaly as: - likely real business event - likely data issue - likely operational issue - expected seasonal pattern - needs more context - false alarm 4. Investigation path For each high-priority anomaly recommend: - data checks - stakeholder questions - source system checks - related metrics to inspect - comparison segments - possible explanations 5. Business impact estimate Estimate what the anomaly could affect: - revenue - costs - conversion - retention - customer experience - operations - risk 6. Triage summary Create an action list: - investigate now - monitor - explain in report - exclude with caveat - escalate to data owner Rules: - Do not label every unusual point as a problem. - Do not ignore known events or data pipeline changes. - Do not remove anomalies before understanding them. - The output should help the team decide what deserves attention. --------------------------------------------------------------------------------

#066Correlation and Relationship Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, data scientists, product analysts, finance analysts, growth analysts, operations analysts, researchers, and anyone exploring variable relationships.

Explore relationships between variables, identify correlations, possible drivers, confounding risks, and relationships worth deeper investigation.

Act as a relationship exploration analyst. Explore possible relationships between variables without overstating causality. Dataset context: Dataset: [DATASET] Business question: [QUESTION] Outcome variable: [OUTCOME VARIABLE] Candidate explanatory variables: [VARIABLES] Segments: [SEGMENTS] Time period: [TIME PERIOD] Known confounders: [CONFOUNDERS] Data quality concerns: [CONCERNS] Analysis tool: [TOOL] Explore relationships: A. Relationship map For each candidate variable, evaluate relationship with the outcome: - direction - strength - shape - linear or non-linear pattern - segment differences - time sensitivity - outlier influence - missing data impact B. Correlation table Create a table with: - variable pair - relationship measure - interpretation - business logic - caveats - recommended next step C. Visual exploration plan Recommend visuals such as: - scatter plot - grouped bar chart - boxplot by category - heatmap - trend overlay - binned comparison - partial relationship view D. Confounding and false signal check Identify: - variables that may move together because of another factor - time trends that may inflate correlation - segment mix effects - seasonality - outlier-driven correlations - reverse causality risk E. Business hypothesis list Create hypotheses worth testing further. For each include: - hypothesis - supporting pattern - alternative explanation - next analysis needed - action if confirmed Rules: - Do not claim causation from correlation. - Do not rely only on correlation coefficients. - Do not ignore non-linear or segment-specific relationships. - Relationship exploration should generate better hypotheses, not premature conclusions. --------------------------------------------------------------------------------

#067Behavioral Signal Discovery

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYProduct analysts, customer analysts, growth teams, retention analysts, sales analysts, operations analysts, HR analysts, and SaaS or marketplace teams.

Explore user, customer, employee, or operational behavior patterns and identify signals that may predict value, risk, churn, conversion, retention, or performance.

You are a behavioral data analyst. Explore the dataset to identify behavioral signals that may matter for business outcomes. Behavior context: Entity analyzed: [USER / CUSTOMER / ACCOUNT / EMPLOYEE / STORE / OTHER] Outcome of interest: [OUTCOME] Behavioral fields or events: [FIELDS / EVENTS] Time window: [TIME WINDOW] Business goal: [GOAL] Segments: [SEGMENTS] Known behaviors: [KNOWN BEHAVIORS] Data source: [SOURCE] Minimum activity threshold: [THRESHOLD] Discover behavioral signals: 1. Behavior inventory List measurable behaviors such as: - frequency - recency - intensity - duration - sequence - feature use - repeat actions - inactivity - support contact - purchase pattern - browsing behavior - completion behavior - failed attempts 2. Signal construction Create candidate signals: - days since last action - number of actions in period - active days - first-week activity - repeated use - feature adoption - usage depth - abandonment point - support burden - activity acceleration or decline 3. Outcome comparison Compare behaviors across groups: - converted vs not converted - retained vs churned - high value vs low value - completed vs dropped off - satisfied vs dissatisfied 4. Early signal ranking Rank signals by: - business logic - strength of difference - availability - actionability - stability - risk of bias 5. Next action map For each promising signal include: - possible intervention - owner - timing - data needed - caution Rules: - Do not treat behavior signals as proven predictors without validation. - Do not ignore timing between behavior and outcome. - Do not use signals that cannot be acted on. - The output should identify behavioral patterns worth deeper testing. --------------------------------------------------------------------------------

#068Funnel Exploration and Drop-Off Finder

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYProduct analysts, growth analysts, sales analysts, marketing analysts, ecommerce teams, SaaS teams, operations analysts, and BI teams.

Explore conversion, activation, sales, onboarding, checkout, support, or operational funnels to find drop-off points, bottlenecks, and segment differences.

Act as a funnel exploration analyst. Analyze the funnel below to identify where people or records drop off and what patterns deserve deeper investigation. Funnel context: Funnel name: [FUNNEL NAME] Business goal: [GOAL] Funnel steps: [STEPS] Entity moving through funnel: [USER / CUSTOMER / LEAD / ORDER / TICKET / OTHER] Dataset: [DATASET] Time period: [TIME PERIOD] Segments: [SEGMENTS] Expected conversion: [EXPECTED CONVERSION] Known issues: [ISSUES] Decision to support: [DECISION] Explore the funnel: A. Funnel definition check Clarify: - step order - required vs optional steps - event or status definitions - time window between steps - exclusion rules - duplicate handling B. Overall funnel performance Calculate or describe: - count at each step - conversion rate between steps - cumulative conversion - biggest drop-off - average time between steps - median time between steps C. Segment funnel comparison Compare funnel performance by: - channel - cohort - device - geography - customer type - campaign - product - sales owner - plan - first action D. Bottleneck diagnosis For each major drop-off include: - step - size of loss - affected segment - possible user or process reason - possible tracking issue - related metric to inspect E. Next investigation plan Recommend: - qualitative question - data check - experiment idea - dashboard view - stakeholder to consult Rules: - Do not analyze a funnel before step definitions are precise. - Do not ignore time between steps. - Do not assume drop-off is bad if the step filters poor-fit users. - Funnel EDA should reveal where and for whom the journey breaks. --------------------------------------------------------------------------------

#069Seasonality and Calendar Pattern Detector

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYFinance analysts, revenue analysts, operations analysts, marketing analysts, ecommerce analysts, product analysts, BI teams, and forecasting preparation.

Explore weekly, monthly, quarterly, holiday, fiscal, event-driven, and operational calendar patterns in business metrics.

You are a seasonality exploration analyst. Detect calendar-based patterns in the metric below and explain what they may mean. Seasonality context: Metric: [METRIC] Dataset: [DATASET] Date field: [DATE FIELD] Business process: [PROCESS] Time coverage: [TIME COVERAGE] Geography or market: [GEOGRAPHY] Business calendar: [CALENDAR] Known holidays or events: [EVENTS] Segments: [SEGMENTS] Decision supported: [DECISION] Explore seasonality: 1. Calendar breakdown Analyze patterns by: - day of week - week of month - month - quarter - season - holiday period - fiscal period - campaign period - pay cycle - operational cycle 2. Baseline vs seasonal movement For each calendar pattern include: - average value - variation - peak periods - low periods - consistency - business explanation - data caveat 3. Year-over-year comparison If data allows, compare same calendar periods across years. 4. Segment seasonality Identify whether seasonality differs by: - region - product - customer segment - channel - store - team - device - plan 5. Adjustment guidance Recommend how seasonality should affect: - trend interpretation - forecasting - target setting - staffing - inventory - marketing - dashboard alerts 6. Stakeholder explanation Write a simple summary of seasonal patterns and how to avoid misreading them. Rules: - Do not call a short-term spike a seasonality pattern without repeated evidence. - Do not compare periods with different calendar lengths without adjustment. - Do not ignore holidays, fiscal calendars, or business cycles. - Seasonality exploration should improve interpretation and planning. --------------------------------------------------------------------------------

#070Metric Decomposition Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, finance teams, product analysts, growth analysts, revenue analysts, operations analysts, BI teams, and executive reporting.

Break a metric movement into component drivers, segments, time periods, mix effects, and operational levers.

Act as a metric decomposition analyst. Explain what is driving the change in [METRIC]. Metric context: Metric: [METRIC] Business question: [QUESTION] Current period: [CURRENT PERIOD] Comparison period: [COMPARISON PERIOD] Segments available: [SEGMENTS] Component metrics: [COMPONENT METRICS] Dataset: [DATASET] Known events: [EVENTS] Business owner: [OWNER] Decompose the metric movement: A. Metric formula Define the metric formula and its components. B. Overall change Calculate or describe: - current value - previous value - absolute change - percentage change - direction - business significance C. Component decomposition Break movement into drivers such as: - volume - rate - mix - price - frequency - conversion - retention - cost - quality - timing - segment composition D. Segment contribution For each segment include: - segment size - metric change - contribution to total change - whether it improved or worsened - business explanation - follow-up question E. Mix effect check Identify whether total movement is driven by: - real performance change - segment mix shift - outlier segment - data quality issue - seasonality - one-time event F. Explanation summary Write a stakeholder-ready explanation of what changed and why. Rules: - Do not report that a metric changed without decomposing drivers. - Do not confuse segment performance with segment mix. - Do not ignore component metrics. - Decomposition should explain what levers may move the metric next. --------------------------------------------------------------------------------

#071Long-Tail and Pareto Pattern Finder

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYRevenue analysis, customer analysis, product analysis, operations analysis, supplier analysis, marketing analysis, finance analysis, and risk analysis.

Identify concentration patterns, top contributors, long-tail categories, Pareto effects, and hidden dependency on a small number of records or segments.

You are a Pareto and concentration analysis specialist. Explore whether performance is concentrated in a small number of categories, customers, products, or records. Analysis context: Dataset: [DATASET] Primary metric: [METRIC] Entity or category field: [ENTITY / CATEGORY] Business question: [QUESTION] Time period: [TIME PERIOD] Segments: [SEGMENTS] Known concentration risk: [RISK] Minimum threshold: [THRESHOLD] Find concentration patterns: 1. Contribution ranking Rank entities by contribution to the primary metric. Calculate or describe: - top 1 contribution - top 5 contribution - top 10 contribution - top 20 percent contribution - bottom segment contribution - long-tail size 2. Pareto curve Describe the cumulative contribution pattern. Classify as: - highly concentrated - moderately concentrated - evenly distributed - long-tail dominated - unstable concentration 3. Segment concentration Check whether concentration differs across: - time periods - regions - channels - product categories - customer types - teams - campaigns 4. Risk and opportunity interpretation Identify: - dependency risk - diversification opportunity - underperforming long tail - high-value segment - operational burden - marketing focus - retention priority 5. Follow-up actions Recommend what the business should investigate next. Rules: - Do not focus only on averages when concentration matters. - Do not ignore small segments that create large risk. - Do not assume the long tail is low value without checking cost or strategic role. - Pareto analysis should reveal where the business is dependent or where opportunity is concentrated. --------------------------------------------------------------------------------

#072Cohort and Lifecycle Pattern Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYSaaS, ecommerce, subscriptions, product analytics, customer success, retention analysis, education analytics, HR analytics, and any lifecycle-based analysis.

Explore how groups behave over time based on start date, signup cohort, purchase cohort, activation month, customer age, or lifecycle stage.

Act as a cohort and lifecycle exploration analyst. Analyze how behavior or performance changes across cohorts and lifecycle stages. Cohort context: Entity: [USER / CUSTOMER / ACCOUNT / STUDENT / EMPLOYEE / OTHER] Cohort definition: [COHORT DEFINITION] Start date field: [START DATE FIELD] Outcome metric: [OUTCOME METRIC] Activity or behavior fields: [FIELDS] Dataset: [DATASET] Time period: [TIME PERIOD] Lifecycle stages: [STAGES] Segments: [SEGMENTS] Business question: [QUESTION] Explore cohort patterns: A. Cohort definition check Clarify: - how cohorts are assigned - cohort grain - inclusion rules - exclusion rules - time zero - maturity window B. Cohort table design Create a table structure showing: - cohort period - cohort size - period 0 value - period 1 value - period 2 value - later period values - retention or activity rate - cumulative value, if relevant C. Lifecycle analysis Explore behavior by lifecycle stage: - new - activated - engaged - at risk - dormant - retained - churned - reactivated - high value D. Pattern detection Identify: - stronger cohorts - weaker cohorts - early drop-off - delayed activation - retention decay - cohort seasonality - improvement over time E. Business interpretation Explain which cohorts or stages need action. Rules: - Do not compare immature cohorts to mature cohorts unfairly. - Do not use calendar time when lifecycle time is needed. - Do not ignore cohort size differences. - Cohort EDA should reveal how behavior develops over time. --------------------------------------------------------------------------------

#073Geographic and Location Pattern Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYRetail analytics, operations analytics, sales analytics, logistics, marketing, education, healthcare, local business analysis, and regional performance reviews.

Explore differences by geography, store, region, market, territory, branch, warehouse, school, or physical location.

You are a geographic pattern analyst. Explore location-based differences in the dataset and identify what may explain performance variation. Location context: Dataset: [DATASET] Location fields: [LOCATION FIELDS] Metric: [METRIC] Business question: [QUESTION] Time period: [TIME PERIOD] Location hierarchy: [COUNTRY / REGION / CITY / STORE / BRANCH / TERRITORY] Known market differences: [DIFFERENCES] Operational constraints: [CONSTRAINTS] External data available: [EXTERNAL DATA] Explore location patterns: 1. Location data quality Check: - missing locations - inconsistent names - duplicate locations - hierarchy mismatches - inactive locations - new or closed locations - location code issues 2. Location performance table For each location include: - volume - metric value - rank - change over time - variance from average - contribution to total - data confidence 3. Peer grouping Compare locations against fair peers based on: - size - region - customer base - age - format - capacity - seasonality - market type 4. Pattern types Classify locations as: - high performing - underperforming - improving - declining - volatile - new and not mature - data quality risk 5. Investigation plan For priority locations, suggest: - operational questions - external context to check - process differences - staffing or capacity factors - local market factors - data validation checks Rules: - Do not rank locations without considering size and context. - Do not compare new locations to mature locations without caveats. - Do not ignore location hierarchy quality. - Location analysis should reveal where performance differs and what context is needed. --------------------------------------------------------------------------------

#074Before-and-After Change Explorer

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYProduct analysts, marketing analysts, operations analysts, finance analysts, HR analysts, consultants, business analysts, and teams evaluating recent changes.

Explore patterns before and after a business change, product release, campaign, pricing update, policy shift, process change, or operational event.

Act as a before-and-after exploratory analyst. Analyze what changed around the event below while avoiding premature causal claims. Change context: Business change or event: [CHANGE / EVENT] Event date: [DATE] Metric or outcome: [METRIC] Dataset: [DATASET] Affected population: [POPULATION] Unaffected comparison group, if any: [COMPARISON GROUP] Pre-period: [PRE-PERIOD] Post-period: [POST-PERIOD] Known confounders: [CONFOUNDERS] Segments: [SEGMENTS] Decision supported: [DECISION] Explore before-and-after patterns: A. Event definition Clarify: - what changed - when it changed - who was affected - expected effect - how long effect may take - what was not changed B. Pre/post comparison Compare: - metric level before - metric level after - absolute change - percentage change - trend before - trend after - volatility before and after C. Comparison group check If available, compare affected vs unaffected groups. If not available, explain limitations. D. Segment analysis Identify which segments changed most or least. E. Alternative explanation scan Check possible confounders: - seasonality - marketing - pricing - data tracking change - external events - sample mix shift - operational changes - delayed effects F. Conclusion language Write careful interpretation language: - what the data suggests - what it does not prove - confidence level - follow-up analysis needed Rules: - Do not claim the event caused the change without proper design. - Do not use arbitrary pre/post windows without reasoning. - Do not ignore trends that started before the event. - The analysis should identify patterns and next questions, not overstate certainty. --------------------------------------------------------------------------------

#075Exploratory Visualization Plan

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, BI analysts, dashboard builders, Python/R users, Tableau/Power BI users, students, consultants, and anyone planning EDA visuals.

Choose the right charts and tables for exploring data patterns, distributions, trends, segments, anomalies, and relationships before final reporting.

You are an exploratory data visualization strategist. Create a visualization plan for exploring the dataset below. EDA context: Dataset: [DATASET] Business question: [QUESTION] Main metrics: [METRICS] Dimensions: [DIMENSIONS] Date fields: [DATE FIELDS] Segments: [SEGMENTS] Known issues: [ISSUES] Audience for exploration: [AUDIENCE] Tool: [TOOL] Output needed: [NOTEBOOK / DASHBOARD DRAFT / REPORT / PRESENTATION] Create the visualization plan: 1. Exploration goals Define what the visuals must help discover: - distributions - trends - anomalies - segments - relationships - seasonality - concentration - missingness - data quality issues 2. Chart plan Create a chart list with: - chart title - question answered - chart type - x-axis - y-axis - color or segment - filters - data grain - interpretation guide - risk of misreading 3. Visual types to include Recommend visuals such as: - histogram - boxplot - line chart - scatter plot - heatmap - bar chart - stacked bar - cohort table - funnel chart - Pareto chart - missingness matrix - distribution table 4. Exploration sequence Order the visuals from broad overview to deeper investigation. 5. Visual QA Create checks for: - correct aggregation - axis scale - missing values - outlier influence - segment sizes - misleading averages - incomplete periods Rules: - Do not pick charts because they look impressive. - Do not use final-report polish during early exploration if speed matters. - Do not visualize data before checking grain and aggregation. - The plan must help reveal patterns safely and clearly. --------------------------------------------------------------------------------

#076SQL EDA Query Pack Generator

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYSQL analysts, BI analysts, analytics engineers, data analysts, warehouse users, and anyone doing EDA directly in a database.

Generate a structured set of SQL queries for profiling, distributions, missingness, trends, segments, anomalies, and relationship checks.

You are a SQL exploratory analysis assistant. Create a practical SQL query pack for exploring the table below. SQL context: Database dialect: [POSTGRES / BIGQUERY / SNOWFLAKE / SQL SERVER / MYSQL / OTHER] Table name: [TABLE NAME] Expected grain: [GRAIN] Primary key: [PRIMARY KEY] Date field: [DATE FIELD] Metric fields: [METRIC FIELDS] Categorical fields: [CATEGORICAL FIELDS] Business question: [QUESTION] Time period: [TIME PERIOD] Known filters: [FILTERS] Create SQL query templates for: A. Table profile Queries for: - row count - column checks - min and max date - unique key count - duplicate key count B. Missingness Queries for missing counts and missing percentages by field. C. Distributions Queries for: - numeric summaries - percentiles - top categories - rare categories - zero or negative values - invalid values D. Time trends Queries for: - daily or monthly metric trend - rolling average - incomplete period check - spike and drop candidates E. Segment comparisons Queries for: - metric by segment - segment share - segment contribution - segment change over time F. Relationship checks Queries for: - grouped correlation-style summaries - binned comparisons - cross-tabs - funnel step counts, if relevant G. EDA summary table Create one query that produces a compact exploratory summary. Rules: - Do not assume SQL functions are identical across dialects; mark dialect-specific syntax. - Do not write queries that hide duplicate or missing key risks. - Do not aggregate before grain is understood. - The query pack must help an analyst explore safely and efficiently. --------------------------------------------------------------------------------

#077Python EDA Notebook Blueprint

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYPython analysts, data scientists, pandas users, Jupyter notebook users, students, analytics teams, consultants, and anyone doing EDA programmatically.

Create a notebook structure for exploring a dataset with profiling, cleaning checks, distributions, visuals, relationships, anomalies, and insight notes.

Act as a Python EDA notebook architect. Build a notebook plan for exploring the dataset below. Python context: Dataset path or source: [SOURCE] File type: [CSV / XLSX / PARQUET / SQL / API] Business question: [QUESTION] Target metric: [METRIC] Date field: [DATE FIELD] ID fields: [ID FIELDS] Categorical fields: [CATEGORICAL FIELDS] Numeric fields: [NUMERIC FIELDS] Segments: [SEGMENTS] Tool environment: [JUPYTER / COLAB / SCRIPT] Output needed: [EDA NOTEBOOK / REPORT / FINDINGS SUMMARY] Create the notebook blueprint: 1. Notebook sections Create sections for: - imports and settings - load data - dataset overview - schema review - missing value profile - duplicate check - data type review - numeric distributions - categorical distributions - trend analysis - segment analysis - anomaly scan - relationship exploration - early insights - limitations - next steps 2. Code skeleton Write Python/pandas code skeleton for each section. Include placeholders for: - file path - columns - filters - plots - quality checks - summary tables 3. Visualization plan Recommend plots using standard Python libraries. 4. Insight capture cells Create markdown templates for documenting: - observation - business interpretation - caveat - follow-up analysis 5. Reproducibility checklist Include: - raw data preserved - environment noted - transformations documented - random seeds, if relevant - output saved Rules: - Do not mix final conclusions with early observations. - Do not create plots without interpretation prompts. - Do not skip data quality checks. - The notebook should make exploration systematic, readable, and reproducible. --------------------------------------------------------------------------------

#078Early Insight Hypothesis Generator

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, product analysts, growth teams, finance analysts, operations analysts, consultants, BI teams, and anyone turning EDA into next-step analysis.

Convert initial EDA observations into structured hypotheses, business interpretations, validation needs, and deeper analysis directions.

You are an exploratory insight strategist. Turn the initial EDA observations below into structured hypotheses and follow-up analysis opportunities. EDA observations: [PASTE OBSERVATIONS / CHART NOTES / TABLE FINDINGS] Business context: Business question: [QUESTION] Business goal: [GOAL] Primary metric: [METRIC] Stakeholders: [STAKEHOLDERS] Dataset limitations: [LIMITATIONS] Known events: [EVENTS] Decision to support: [DECISION] Timeframe: [TIMEFRAME] Transform observations into insight hypotheses: A. Observation cleanup For each observation, rewrite it as a precise analytical statement. Include: - what changed or differs - where it appears - how large it is - over what time period - which segment is affected B. Hypothesis creation For each observation, generate: - business hypothesis - possible explanation - alternative explanation - data quality explanation - confidence level - evidence needed C. Prioritization Rank hypotheses by: - business impact - likelihood - actionability - ease of validation - urgency - stakeholder relevance D. Follow-up analysis plan For each high-priority hypothesis define: - analysis method - data needed - comparison group - chart or table - decision implication - risk if ignored E. Stakeholder question list Create questions to ask business owners before deeper analysis. Rules: - Do not turn every observation into a conclusion. - Do not ignore data quality explanations. - Do not prioritize interesting patterns over actionable patterns. - EDA should generate hypotheses that can be validated or rejected. --------------------------------------------------------------------------------

#079EDA Findings Readout Builder

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, BI analysts, consultants, product teams, finance teams, operations teams, and anyone presenting early analysis without overclaiming.

Create a clear readout from exploratory analysis that separates facts, patterns, hypotheses, caveats, recommended next steps, and stakeholder questions.

Act as a business-facing EDA communicator. Create an exploratory analysis readout from the findings below. Input findings: [PASTE EDA FINDINGS / NOTES / CHART OBSERVATIONS] Readout context: Audience: [AUDIENCE] Business question: [QUESTION] Decision context: [DECISION] Primary metric: [METRIC] Dataset used: [DATASET] Time period: [TIME PERIOD] Known limitations: [LIMITATIONS] Desired format: [SLIDES / MEMO / EMAIL / MEETING NOTES] Build the readout: 1. Executive snapshot Write a short summary of what the EDA found and why it matters. 2. What we looked at Summarize: - dataset - time period - metrics - segments - methods - exclusions 3. Key patterns Create 5 to 10 key patterns. For each include: - observation - evidence - business interpretation - caveat - follow-up question 4. What we do not know yet List what the EDA cannot prove. 5. Hypotheses to test Create prioritized hypotheses from the patterns. 6. Recommended next steps Classify next steps as: - data validation - deeper analysis - stakeholder interview - experiment - dashboard - operational investigation - decision-ready analysis 7. Stakeholder discussion questions Create questions for the meeting. Rules: - Do not present exploratory patterns as final conclusions. - Do not hide caveats. - Do not overload stakeholders with every chart. - The readout should create alignment on what is known, unknown, and worth investigating next. --------------------------------------------------------------------------------

#080Full Exploratory Data Analysis and Pattern Discovery Audit

EXPLORATORY DATA ANALYSIS & PATTERN DISCOVERYData analysts, BI analysts, data scientists, consultants, product analysts, finance analysts, operations analysts, marketing analysts, and analytics teams preparing for deeper analysis or reporting.

Audit and rebuild an EDA process across dataset profiling, distributions, trends, anomalies, segments, correlations, seasonality, behavioral signals, visual exploration, and early insights.

Act as an independent exploratory data analysis and pattern discovery auditor. Review my dataset, business question, and current exploratory work, then rebuild the EDA into a structured, trustworthy pattern discovery process. Full context: Dataset name: [DATASET] Business question: [QUESTION] Business objective: [OBJECTIVE] Decision to support: [DECISION] Primary metric: [METRIC] Secondary metrics: [SECONDARY METRICS] Dataset source: [SOURCE] Expected grain: [GRAIN] Rows and columns: [ROWS / COLUMNS] Key fields: [KEY FIELDS] Date fields: [DATE FIELDS] Categorical fields: [CATEGORICAL FIELDS] Numeric fields: [NUMERIC FIELDS] Segments: [SEGMENTS] Known data quality issues: [ISSUES] Time period: [TIME PERIOD] Known business events: [EVENTS] Current EDA findings: [FINDINGS] Tool used: [TOOL] Stakeholders: [STAKEHOLDERS] Expected output: [OUTPUT] Audit across 60 dimensions: 1. Business question alignment 2. Dataset grain clarity 3. Dataset structure profile 4. Field type review 5. Missingness review 6. Duplicate review 7. Key uniqueness check 8. Time coverage 9. Incomplete period risk 10. Numeric distribution review 11. Categorical distribution review 12. Long-tail category review 13. Outlier detection 14. Outlier interpretation 15. Anomaly detection 16. Time trend analysis 17. Volatility review 18. Seasonality review 19. Period-over-period comparison 20. Segment selection 21. Segment size validation 22. Segment performance comparison 23. Segment contribution analysis 24. Cohort exploration 25. Lifecycle exploration 26. Funnel exploration 27. Behavioral signal discovery 28. Geographic pattern review 29. Product or category pattern review 30. Customer pattern review 31. Correlation exploration 32. Relationship shape review 33. Confounder awareness 34. Mix effect awareness 35. Before-and-after exploration 36. External event context 37. Data quality explanation checks 38. Business explanation checks 39. Visual selection quality 40. Chart interpretation quality 41. Aggregation correctness 42. Metric decomposition 43. Pareto analysis 44. Peer comparison 45. Baseline comparison 46. Hypothesis generation 47. Hypothesis prioritization 48. Follow-up analysis plan 49. Caveat documentation 50. Stakeholder question list 51. Insight actionability 52. Overclaiming risk 53. Causality risk 54. Reproducibility 55. EDA notebook or query organization 56. Exploratory readout quality 57. Decision relevance 58. Next-step clarity 59. Business value potential 60. Overall EDA maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - analytical risk if ignored - business risk if ignored - recommended fix - priority - effort - confidence level Then synthesize: A. Hard truth Explain the biggest weakness in the current EDA process and why it may lead to weak or misleading insights. B. Rebuilt EDA plan Create: - profiling plan - distribution plan - trend plan - segment plan - anomaly plan - correlation plan - seasonality plan - funnel or cohort plan, if relevant - behavioral signal plan - visualization plan - hypothesis generation plan - stakeholder readout plan C. First 10 EDA actions Rank the first 10 exploration steps. For each include: - action - fields needed - method - chart or table - expected learning - risk reduced D. EDA output structure Create a final EDA notebook or report outline with: - data overview - quality checks - key distributions - key trends - key segments - anomalies - relationships - hypotheses - caveats - next steps E. Stakeholder readout Write an early-readout summary that separates: - facts - patterns - hypotheses - caveats - decisions not ready yet - recommended next work F. Executive summary Write a direct summary with: - strongest pattern found - weakest evidence point - biggest anomaly - most important segment - biggest caveat - first hypothesis to test - one operating principle for EDA Rules: - Do not treat EDA as final proof. - Do not skip data quality checks before pattern interpretation. - Do not claim causation from exploratory patterns. - Use [NEEDS DATA QUALITY CHECK], [NEEDS STAKEHOLDER CONTEXT], [NEEDS SOURCE VALIDATION], [NEEDS SEGMENT SIZE REVIEW], or [NEEDS DEEPER ANALYSIS] where required. - The final process should reveal useful patterns while protecting analytical trust.

#081Business Question to SQL Logic Translator

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, BI analysts, SQL beginners, analytics engineers, business analysts, product analysts, finance analysts, and anyone converting stakeholder requests into SQL.

Translate a plain-language business question into precise SQL logic with tables, joins, filters, metrics, grouping, and validation checks.

You are a senior SQL analyst. Translate the business question below into a clear SQL query plan before writing the final query. Business context: Business question: [BUSINESS QUESTION] Decision to support: [DECISION] Expected output: [TABLE / EXPORT / DASHBOARD / METRIC / ANALYSIS] Database dialect: [POSTGRES / BIGQUERY / SNOWFLAKE / SQL SERVER / MYSQL / OTHER] Available tables: [TABLES] Relevant columns: [COLUMNS] Metric definitions: [METRICS] Required filters: [FILTERS] Time period: [TIME PERIOD] Grain needed: [GRAIN] Segments needed: [SEGMENTS] Known data issues: [DATA ISSUES] Build the SQL logic: 1. Business interpretation Rewrite the business question in precise analytical language. Clarify: - metric being calculated - entity being counted or analyzed - timeframe - filters - grouping - expected grain - exclusions - business assumptions 2. Required tables Identify: - fact tables - dimension tables - lookup tables - bridge tables - date table, if needed - source of truth for each field 3. Join plan For every join include: - left table - right table - join key - join type - expected relationship - risk of row multiplication - validation check 4. Query structure Design the query using: - base CTE - cleaning or filtering CTE - join CTE - aggregation CTE - final SELECT 5. Final SQL Write the SQL query in the selected dialect. 6. Validation checks Create companion queries to check: - row counts - duplicates - missing join keys - metric totals - date coverage - unexpected nulls Rules: - Do not write SQL before clarifying grain and metric logic. - Do not assume table relationships without validation. - Do not use SELECT * in final analytical output. - If definitions are missing, mark [NEEDS METRIC DEFINITION] or [NEEDS TABLE RELATIONSHIP REVIEW]. --------------------------------------------------------------------------------

#082Multi-Table Join Query Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSQL analysts, analytics engineers, BI developers, data analysts, data warehouse users, product analysts, finance analysts, and anyone joining several tables.

Build safe SQL joins across multiple tables while controlling grain, duplicate keys, many-to-many relationships, and metric inflation.

Act as a SQL join architect. Build a safe multi-table join query for the analysis below. Join context: Analysis goal: [GOAL] Database dialect: [DIALECT] Main table: [MAIN TABLE] Additional tables: [ADDITIONAL TABLES] Available schemas: [SCHEMAS] Expected final grain: [FINAL GRAIN] Join keys: [JOIN KEYS] Metrics to calculate: [METRICS] Filters: [FILTERS] Known duplicate risks: [RISKS] Time period: [TIME PERIOD] Create the join plan: A. Grain definition Define: - grain of each source table - expected grain of final output - one row should represent - aggregation needed before joining B. Relationship map For each table pair define: - relationship type - join key - join direction - join type - risk level - validation query C. Pre-join preparation Create CTEs for: - filtering raw records - deduplicating dimension tables - aggregating fact tables to safe grain - selecting only needed columns - standardizing join keys D. Final query Write SQL with clear CTEs and comments. E. Join validation Write validation queries for: - row count before and after each join - unmatched records - duplicate joined keys - metric totals before and after join - many-to-many risk F. Result interpretation Explain how to know if the join is safe. Rules: - Do not join many-to-many tables without pre-aggregation or bridge logic. - Do not calculate metrics after a join that changes row count unexpectedly. - Do not assume IDs are unique without checking. - The final SQL must protect against silent metric inflation. --------------------------------------------------------------------------------

#083Aggregation and Metric SQL Generator

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONBI analysts, dashboard builders, data analysts, finance analysts, marketing analysts, product analysts, operations analysts, and reporting teams.

Write SQL for aggregating business metrics correctly by date, segment, customer, product, campaign, location, or other dimensions.

You are a SQL metric aggregation expert. Create a query that calculates the requested metrics at the correct level of detail. Metric context: Database dialect: [DIALECT] Source table or view: [TABLE / VIEW] Metric names: [METRICS] Metric formulas: [FORMULAS] Required grain: [DAILY / WEEKLY / MONTHLY / CUSTOMER / PRODUCT / OTHER] Group by dimensions: [DIMENSIONS] Filters: [FILTERS] Time period: [TIME PERIOD] Date field: [DATE FIELD] Exclusions: [EXCLUSIONS] Expected output columns: [OUTPUT COLUMNS] Build the aggregation query: 1. Metric logic review For each metric define: - numerator - denominator - aggregation function - filters - exclusions - null handling - division-by-zero handling - rounding rule 2. Grouping logic Define: - date grain - segment dimensions - entity dimensions - required rollups - whether totals are needed 3. SQL query Write the query using CTEs: - base filtered data - metric components - final aggregation - final formatted output 4. Validation checks Write checks for: - total rows - date range - grouped totals vs source totals - denominator zero cases - null counts - duplicate group rows 5. Business caveats List any assumptions that could affect interpretation. Rules: - Do not average already-averaged rates unless weighted correctly. - Do not calculate ratios without controlling denominator. - Do not group by unnecessary columns that change grain. - The final query must calculate metrics in a business-safe way. --------------------------------------------------------------------------------

#084CTE-Based Analytical Query Refactor

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSQL analysts, analytics engineers, BI developers, data analysts, dashboard builders, and anyone improving query readability and maintainability.

Refactor a complex or messy SQL query into readable CTEs with clear logic, comments, validation points, and safer structure.

Act as a SQL refactoring specialist. Refactor the query below into a clean CTE-based analytical query without changing its intended result. Original SQL: [PASTE SQL QUERY] Context: Database dialect: [DIALECT] Business purpose: [PURPOSE] Expected output: [OUTPUT] Known problems: [PROBLEMS] Tables involved: [TABLES] Metrics calculated: [METRICS] Performance concerns: [CONCERNS] Do not change: [DO NOT CHANGE] Refactor the query: A. Query diagnosis Identify issues such as: - unclear logic - repeated subqueries - nested complexity - risky joins - unclear filters - ambiguous aliases - mixed aggregation levels - missing comments - performance issues - hard-to-validate calculations B. CTE structure Create CTEs with clear roles: - params - base_data - filtered_data - deduped_data - joined_data - metric_components - final_aggregation - final_output C. Refactored SQL Write the improved SQL with: - clear names - comments - consistent aliases - explicit filters - clean joins - readable metric logic - final SELECT D. Validation plan Provide queries or checks to confirm the refactor matches the original. E. Improvement summary Explain what changed and what did not change. Rules: - Do not change business logic unless explicitly requested. - Do not optimize by removing necessary filters or joins. - Do not hide assumptions. - If the original query is ambiguous, mark [NEEDS BUSINESS LOGIC REVIEW]. --------------------------------------------------------------------------------

#085SQL Debugging and Error Diagnosis Assistant

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSQL learners, data analysts, BI developers, analytics engineers, dashboard builders, finance analysts, product analysts, and anyone troubleshooting SQL.

Diagnose SQL errors, wrong results, unexpected row counts, broken joins, null issues, slow queries, and aggregation bugs.

You are a SQL debugging expert. Diagnose the issue in my query and provide a safe fix. Problem context: Database dialect: [DIALECT] SQL query: [PASTE QUERY] Error message, if any: [ERROR MESSAGE] Expected result: [EXPECTED RESULT] Actual result: [ACTUAL RESULT] Tables involved: [TABLES] Sample schema: [SCHEMA] Recent changes: [CHANGES] Known data issues: [DATA ISSUES] Performance issue: [YES / NO] Debug the query: 1. Error classification Classify the problem as: - syntax error - missing column - wrong alias - wrong function for dialect - aggregation error - join error - filter error - date logic error - null handling error - duplicate inflation - performance issue - business logic issue 2. Root cause analysis Explain the most likely cause using evidence from the query. 3. Fix plan Provide: - minimal fix - safer version - optional performance improvement - validation query 4. Corrected SQL Write the corrected query. 5. Result validation Create checks to confirm: - row count is expected - key totals reconcile - joins behave correctly - filters work - nulls are handled - date logic is correct 6. Prevention note Explain how to avoid this type of error next time. Rules: - Do not rewrite the entire query if a small fix is enough. - Do not assume business logic that is not provided. - Do not ignore wrong-result bugs just because the query runs. - If table schemas are missing, mark [NEEDS SCHEMA] and state assumptions clearly. --------------------------------------------------------------------------------

#086Analytical Dataset Extraction Query

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, data scientists, BI analysts, analytics engineers, consultants, product analysts, finance analysts, and anyone pulling data for analysis.

Create SQL to extract a clean, analysis-ready dataset from database tables with proper filters, joins, field selection, quality flags, and export structure.

Act as an analytical data extraction specialist. Create a SQL extraction query that produces an analysis-ready dataset. Extraction context: Analysis goal: [GOAL] Database dialect: [DIALECT] Source tables: [TABLES] Required entities: [ENTITIES] Required fields: [FIELDS] Date range: [DATE RANGE] Filters: [FILTERS] Expected grain: [GRAIN] Join keys: [JOIN KEYS] Exclusions: [EXCLUSIONS] Output format: [CSV / TABLE / VIEW / TEMP TABLE] Sensitive fields: [SENSITIVE FIELDS] Build the extraction: A. Dataset definition Define: - one row represents - required fields - optional fields - excluded fields - derived fields - quality flags B. SQL extraction query Write SQL with CTEs for: - source filtering - safe joins - field standardization - derived columns - quality flags - final export C. Quality flags Add fields such as: - missing_key_flag - missing_metric_flag - duplicate_candidate_flag - outlier_flag - invalid_status_flag - incomplete_period_flag D. Export validation Create checks for: - row count - distinct entity count - date range - missing required fields - duplicate output rows - sensitive field removal - sample record review E. Handoff notes Write notes explaining how the extracted dataset should and should not be used. Rules: - Do not extract unnecessary sensitive fields. - Do not export raw joined data without checking grain. - Do not leave derived field logic undocumented. - The output must be analysis-ready, not just database-readable. --------------------------------------------------------------------------------

#087SQL Window Function Query Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONIntermediate SQL analysts, BI analysts, analytics engineers, product analysts, finance analysts, operations analysts, and data analysts building advanced queries.

Use SQL window functions for ranking, running totals, moving averages, percentiles, lag/lead comparisons, cohorts, deduplication, and within-group calculations.

You are a SQL window function specialist. Build a query using window functions for the analytical task below. Task context: Business question: [QUESTION] Database dialect: [DIALECT] Source table: [TABLE] Partition field: [PARTITION FIELD] Order field: [ORDER FIELD] Metric field: [METRIC FIELD] Time period: [TIME PERIOD] Desired calculation: [RANK / RUNNING TOTAL / LAG / LEAD / MOVING AVG / DEDUP / OTHER] Filters: [FILTERS] Expected output: [OUTPUT] Design the window logic: 1. Use case selection Identify the correct window function pattern: - ROW_NUMBER - RANK - DENSE_RANK - LAG - LEAD - SUM OVER - AVG OVER - COUNT OVER - MIN/MAX OVER - NTILE - percentile function, if supported 2. Window definition Define: - partition by - order by - frame clause - tie handling - null handling - date logic 3. SQL query Write the query with: - base CTE - window calculation CTE - final filter or aggregation - readable aliases - comments 4. Validation Create checks for: - row count preservation - partition correctness - ranking ties - first and last row behavior - window frame behavior - duplicate ordering risk 5. Business explanation Explain what the window calculation means in plain language. Rules: - Do not use window functions when simple GROUP BY is sufficient. - Do not rank without defining tie behavior. - Do not use LAG or LEAD without a reliable order field. - The query must be correct for the business grain. --------------------------------------------------------------------------------

#088SQL Date Logic and Time Period Query Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, finance analysts, growth analysts, product analysts, BI developers, dashboard builders, and anyone working with time-based metrics.

Build SQL queries with correct date filtering, period grouping, rolling windows, fiscal calendars, cohort windows, and incomplete period handling.

Act as a SQL date logic expert. Create a date-safe query for the time-based analysis below. Date context: Database dialect: [DIALECT] Source table: [TABLE] Date or timestamp field: [DATE FIELD] Business question: [QUESTION] Required time grain: [DAY / WEEK / MONTH / QUARTER / YEAR / FISCAL PERIOD] Time period: [TIME PERIOD] Timezone: [TIMEZONE] Fiscal calendar rules: [FISCAL RULES] Metric: [METRIC] Segments: [SEGMENTS] Need rolling window: [YES / NO] Need exclude incomplete period: [YES / NO] Build the date logic: A. Date requirement Define: - date field to use - business meaning of date - timezone conversion - start date - end date - inclusive or exclusive boundaries - incomplete period handling B. Period grouping Create SQL logic for: - daily grouping - weekly grouping - monthly grouping - fiscal period grouping, if relevant - rolling period, if relevant C. Final SQL Write the query using CTEs: - date parameters - base filtered records - periodized records - aggregated output - final period labels D. Validation checks Create checks for: - min and max dates - missing periods - incomplete periods - timezone boundary issues - row counts by period - same-period comparison E. Business caveats Explain how date logic affects interpretation. Rules: - Do not use date filtering without defining inclusive or exclusive boundaries. - Do not mix timestamps and dates without timezone awareness. - Do not include incomplete periods unless labeled. - The query must make time logic explicit and auditable. --------------------------------------------------------------------------------

#089SQL Funnel Query Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONProduct analysts, growth analysts, ecommerce analysts, SaaS analysts, marketing analysts, sales analysts, BI teams, and conversion analysis.

Build SQL for funnel analysis using ordered steps, user/event logic, conversion rates, drop-offs, time between steps, and segment comparison.

You are a SQL funnel analysis expert. Build a funnel query for the user or process journey below. Funnel context: Database dialect: [DIALECT] Event or status table: [TABLE] Entity ID: [USER / CUSTOMER / LEAD / ORDER ID] Timestamp field: [TIMESTAMP] Funnel steps: [STEPS] Step definitions: [STEP DEFINITIONS] Time window: [TIME WINDOW] Segments: [SEGMENTS] Filters: [FILTERS] Conversion metric needed: [METRIC] Need time-between-steps: [YES / NO] Build the funnel query: 1. Funnel definition Clarify: - step order - step event or condition - whether steps must happen in order - whether repeated events count - maximum time allowed between steps - exclusion rules 2. Step CTEs Create CTEs for each step with: - entity ID - first step timestamp - step-specific attributes - segment fields 3. Ordered funnel logic Write SQL that ensures: - step 2 happens after step 1 - step 3 happens after step 2 - duplicate events are controlled - first occurrence or relevant occurrence is used 4. Final funnel output Return: - step name - entities at step - step conversion rate - cumulative conversion rate - drop-off count - drop-off rate - optional segment 5. Validation checks Create checks for: - duplicate entity events - out-of-order steps - impossible timestamps - missing steps - segment totals Rules: - Do not count events as funnel completion if order is wrong. - Do not ignore repeated events. - Do not calculate conversion without a clear denominator. - Funnel SQL must match the real user or process journey. --------------------------------------------------------------------------------

#090SQL Cohort Analysis Query Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSaaS analysts, ecommerce analysts, product analysts, education analysts, subscription teams, customer success teams, BI analysts, and retention analysis.

Build SQL for cohort analysis using cohort assignment, lifecycle periods, retention, activity, revenue, completion, or other cohort metrics.

Act as a SQL cohort analysis specialist. Create a cohort query for the analysis below. Cohort context: Database dialect: [DIALECT] Entity table: [ENTITY TABLE] Activity table: [ACTIVITY TABLE] Entity ID: [ENTITY ID] Cohort date field: [COHORT DATE] Activity date field: [ACTIVITY DATE] Cohort grain: [WEEK / MONTH / QUARTER] Lifecycle period grain: [DAY / WEEK / MONTH] Metric: [RETENTION / ACTIVITY / REVENUE / COMPLETION / OTHER] Time window: [TIME WINDOW] Segments: [SEGMENTS] Filters: [FILTERS] Build the cohort query: A. Cohort assignment Define: - cohort event - cohort date - cohort period - inclusion rules - exclusions - cohort size logic B. Lifecycle period logic Define: - period 0 - period number calculation - activity qualification - maturity rules - incomplete cohort handling C. SQL query Write SQL with CTEs for: - cohort_base - cohort_sizes - activity_by_period - cohort_metrics - final_cohort_table D. Output format Return: - cohort period - lifecycle period - cohort size - active or retained count - metric value - percentage - segment, if needed E. Validation Create checks for: - cohort sizes - duplicate activity - negative period numbers - activity before cohort date - incomplete periods - cohort maturity Rules: - Do not compare immature cohorts to mature cohorts without labeling. - Do not calculate retention without defining activity. - Do not use calendar time when lifecycle time is required. - The query must produce a reliable cohort table. --------------------------------------------------------------------------------

#091SQL Data Quality Check Query Pack

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, analytics engineers, BI teams, data quality teams, dashboard owners, finance analysts, and warehouse users.

Generate SQL checks for missing values, duplicates, invalid ranges, referential integrity, unexpected categories, freshness, and source reconciliation.

You are a SQL data quality engineer. Create a SQL quality check pack for the table or dataset below. Quality context: Database dialect: [DIALECT] Table name: [TABLE] Expected grain: [GRAIN] Primary key: [PRIMARY KEY] Critical fields: [FIELDS] Date field: [DATE FIELD] Allowed categories: [CATEGORIES] Expected ranges: [RANGES] Reference tables: [REFERENCE TABLES] Business rules: [RULES] Refresh cadence: [CADENCE] Create SQL checks for: A. Completeness Missing values by critical field. B. Uniqueness Duplicate primary keys and duplicate business keys. C. Validity Invalid categories, impossible numeric values, invalid dates, malformed IDs. D. Consistency Business rule violations such as: - end date before start date - completed status without completion date - revenue below zero - active record with inactive owner - quantity zero where not allowed E. Referential integrity Missing foreign key matches in reference tables. F. Freshness Latest data timestamp and stale data warning. G. Reconciliation Totals compared against expected source totals. For each check include: - SQL query - expected result - failure interpretation - severity - owner to notify - next action Rules: - Do not create checks that no one will act on. - Do not treat warnings and failures the same. - Do not rely only on row counts. - The query pack must help detect problems before analysis or dashboard use. --------------------------------------------------------------------------------

#092Analytical SQL View Designer

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONAnalytics engineers, BI developers, data analysts, dashboard teams, data warehouse users, and teams moving from ad hoc SQL to reusable assets.

Design a reusable SQL view or analytical table that standardizes joins, metrics, dimensions, filters, and business logic for repeated reporting.

Act as an analytics engineering view designer. Design a reusable SQL view for [BUSINESS USE CASE]. View context: Business use case: [USE CASE] Database dialect: [DIALECT] Source tables: [TABLES] Expected view grain: [GRAIN] Users: [USERS] Metrics needed: [METRICS] Dimensions needed: [DIMENSIONS] Filters or exclusions: [FILTERS] Refresh needs: [REFRESH] Known data quality issues: [ISSUES] Naming convention: [NAMING] Design the analytical view: 1. View purpose Explain: - why the view should exist - who will use it - what questions it supports - what it should not be used for 2. Schema design Define output columns: - column name - business definition - data type - source - transformation logic - nullable - quality flag 3. SQL logic Write SQL with clear CTEs: - base facts - dimensions - safe joins - derived fields - metrics - quality flags - final view output 4. Validation checks Create SQL checks for: - row count - grain uniqueness - joins - metrics - nulls - category values - date coverage 5. Documentation Create view documentation with caveats and example queries. Rules: - Do not build a reusable view with unclear grain. - Do not hide business logic in undocumented calculations. - Do not include fields just because they are available. - The view should reduce repeated query mistakes and support trusted reporting. --------------------------------------------------------------------------------

#093SQL Performance Optimization Review

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSQL analysts, analytics engineers, BI developers, dashboard builders, data warehouse users, and analysts working with large datasets.

Review and improve slow SQL queries by analyzing joins, filters, aggregations, CTEs, indexes, partitions, scanned data, and execution risk.

You are a SQL performance optimization reviewer. Review the query below and recommend safe improvements without changing business logic. Query: [PASTE SQL QUERY] Performance context: Database dialect: [DIALECT] Table sizes: [TABLE SIZES] Indexes or partitions: [INDEXES / PARTITIONS] Current runtime: [RUNTIME] Expected runtime: [EXPECTED] BI or export use: [USE CASE] Business logic that must not change: [MUST NOT CHANGE] Known bottleneck: [BOTTLENECK] Execution plan, if available: [EXECUTION PLAN] Review performance: A. Bottleneck diagnosis Look for: - full table scans - missing filters - late filters - unnecessary columns - expensive joins - many-to-many joins - repeated subqueries - unneeded DISTINCT - unneeded ORDER BY - inefficient date filters - non-sargable filters - over-aggregation - CTE materialization issues B. Optimization recommendations For each recommendation include: - change - why it helps - risk - expected impact - whether business logic changes - validation needed C. Refactored query Write an optimized version if enough context exists. D. Validation plan Create checks to confirm results match original: - row count - metric totals - sample records - group totals - edge cases E. Long-term improvements Recommend indexes, partitions, materialized views, summary tables, or model changes if relevant. Rules: - Do not optimize by changing the answer. - Do not remove DISTINCT unless duplicate logic is understood. - Do not assume indexes or partitions exist. - Mark dialect-specific advice clearly. --------------------------------------------------------------------------------

#094SQL Business Logic Documentation Assistant

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, analytics engineers, BI teams, auditors, finance analysts, consultants, dashboard teams, and anyone inheriting SQL.

Document the business logic inside a SQL query so stakeholders and future analysts understand filters, joins, metrics, exclusions, and assumptions.

Act as a SQL business logic documentation specialist. Explain and document the query below so it is understandable and maintainable. SQL query: [PASTE QUERY] Context: Business purpose: [PURPOSE] Database dialect: [DIALECT] Audience: [ANALYSTS / BUSINESS STAKEHOLDERS / ENGINEERS] Known metric definitions: [METRICS] Known table meanings: [TABLE MEANINGS] Known assumptions: [ASSUMPTIONS] Documentation level: [SHORT / DETAILED] Create documentation: A. Plain-language summary Explain what the query does in business language. B. Query structure Break down each CTE or section: - section name - purpose - source tables - filters - transformations - output fields - business meaning C. Join documentation For each join explain: - why it is needed - join key - join type - expected relationship - risk D. Metric documentation For each calculated field explain: - formula - numerator - denominator - filters - null handling - business interpretation E. Assumptions and caveats List: - time period assumptions - exclusions - data quality risks - metric definition risks - fields needing confirmation F. Reuse guide Explain when this query can and cannot be reused. Rules: - Do not explain only syntax; explain business meaning. - Do not hide assumptions. - Do not claim the query is correct if logic is unclear. - Mark [NEEDS BUSINESS OWNER REVIEW] where definitions are uncertain. --------------------------------------------------------------------------------

#095SQL Subquery to CTE Teaching Converter

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONSQL learners, junior analysts, mentors, training teams, analytics teams, BI developers, and anyone trying to make SQL more understandable.

Convert difficult subqueries or nested SQL into readable CTEs while explaining each step for learning or team review.

You are a SQL teaching assistant. Convert the nested or difficult query below into a clear CTE version and explain how it works. Original SQL: [PASTE SQL] Context: Database dialect: [DIALECT] Learner level: [BEGINNER / INTERMEDIATE / ADVANCED] Business purpose: [PURPOSE] Expected output: [OUTPUT] Parts that are confusing: [CONFUSING PARTS] Do not change result: [YES / NO] Create the teaching conversion: 1. Plain explanation Explain what the original query is trying to do. 2. Logic steps Break the query into simple steps: - get base records - filter records - join data - calculate fields - aggregate - rank or filter final output 3. CTE version Rewrite the query using CTEs with comments. 4. Section explanation For each CTE include: - what it does - why it exists - input fields - output fields - common mistake to avoid 5. Result equivalence Explain how to validate that the CTE version matches the original. 6. Learning notes Explain any SQL concepts used: - GROUP BY - HAVING - window functions - joins - subqueries - CASE WHEN - date functions Rules: - Do not change logic while simplifying. - Do not over-explain basic syntax if learner level is advanced. - Do not omit validation. - The result should be both usable and educational. --------------------------------------------------------------------------------

#096SQL CASE WHEN and Business Classification Builder

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, BI developers, product analysts, customer analysts, finance analysts, operations analysts, and dashboard builders.

Create SQL classification logic using CASE WHEN for segments, statuses, bands, flags, risk groups, lifecycle stages, and business rules.

Act as a SQL business classification designer. Create CASE WHEN logic for the classification below. Classification context: Business classification needed: [CLASSIFICATION] Database dialect: [DIALECT] Source table: [TABLE] Fields available: [FIELDS] Business rules: [RULES] Priority order of rules: [PRIORITY] Default category: [DEFAULT] Expected categories: [CATEGORIES] Edge cases: [EDGE CASES] Output field name: [FIELD NAME] Use case: [DASHBOARD / ANALYSIS / EXPORT / VIEW] Build the classification: A. Rule clarification Turn the business rules into precise logic. For each category include: - category name - condition - required fields - priority - example record - edge case B. Conflict resolution Define what happens if a record matches multiple categories. C. SQL CASE WHEN Write the CASE WHEN expression. D. Full query example Show how the classification fits into a SELECT query or CTE. E. Validation checks Create SQL checks for: - category counts - uncategorized records - overlapping conditions - unexpected nulls - sample records per category - category distribution by segment F. Documentation note Write a business definition for each category. Rules: - Do not create overlapping categories without priority logic. - Do not leave ELSE undefined unless null is intentional. - Do not hard-code rules that need business approval without marking them. - Use [NEEDS BUSINESS RULE CONFIRMATION] where needed. --------------------------------------------------------------------------------

#097SQL Sampling and Record Inspection Query Pack

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, analytics engineers, QA analysts, BI teams, data quality teams, and anyone validating query logic through record-level inspection.

Create SQL queries for inspecting sample records, edge cases, outliers, duplicates, missing values, and representative examples.

You are a SQL record inspection specialist. Create a sampling query pack to manually inspect the dataset and validate analytical logic. Inspection context: Database dialect: [DIALECT] Table or query: [TABLE / QUERY] Business question: [QUESTION] Key fields: [FIELDS] Metric or classification to validate: [METRIC / CLASSIFICATION] Known concerns: [CONCERNS] Segments: [SEGMENTS] Date range: [DATE RANGE] Expected grain: [GRAIN] Create sampling queries for: A. Random sample Return a random sample of records. B. Stratified sample Return sample records from each key segment or category. C. Edge case sample Return records with: - null critical fields - zero values - negative values - extreme values - rare categories - old dates - recent dates - unusual statuses D. Duplicate sample Return records with duplicate keys or suspicious repeated business keys. E. Join failure sample Return records that fail to match across joined tables. F. Metric validation sample Return records contributing to a metric calculation so logic can be checked manually. G. Before-and-after sample Show records before and after transformation or classification. For each query include: - purpose - SQL - what to inspect - what a problem looks like Rules: - Do not validate only with aggregate totals. - Do not rely on random samples when edge cases matter. - Do not expose sensitive fields unnecessarily. - Record inspection should increase trust in query logic. --------------------------------------------------------------------------------

#098SQL Export and Data Pull QA Checklist

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, BI teams, analytics engineers, consultants, finance analysts, product analysts, operations analysts, and reporting teams.

Create a QA checklist for SQL exports before sharing datasets with stakeholders, analysts, dashboards, or external tools.

Act as a SQL data export QA reviewer. Create a checklist to verify the SQL export below before it is shared. Export context: SQL query: [PASTE QUERY OR QUERY SUMMARY] Database dialect: [DIALECT] Export purpose: [PURPOSE] Audience: [AUDIENCE] Output format: [CSV / EXCEL / TABLE / VIEW / DASHBOARD SOURCE] Expected row count: [EXPECTED ROW COUNT] Expected grain: [GRAIN] Fields included: [FIELDS] Sensitive fields: [SENSITIVE FIELDS] Time period: [TIME PERIOD] Known risks: [RISKS] Create the QA checklist: 1. Structure checks Verify: - expected columns - clear column names - correct data types - no unnecessary fields - no sensitive fields unless approved - one row per expected grain 2. Query logic checks Verify: - filters - joins - date logic - aggregations - CASE WHEN logic - null handling - duplicate handling - exclusions 3. Data checks Verify: - row count - date range - missing values - duplicate keys - numeric ranges - category values - totals vs source - sample records 4. Export readiness Verify: - file naming - version date - field dictionary - caveats - refresh status - storage location - sharing permissions 5. Stakeholder note Create a short handoff note explaining what is included, excluded, and any caveats. Rules: - Do not share exports before checking grain and sensitive fields. - Do not send raw IDs or personal data unless approved. - Do not hide caveats. - The QA checklist must prevent wrong or unsafe data sharing. --------------------------------------------------------------------------------

#099SQL Query Review for Business Accuracy

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, analytics managers, BI reviewers, finance analysts, product analysts, consultants, and teams reviewing stakeholder-facing SQL.

Review a SQL query for whether it answers the intended business question correctly, not just whether it runs.

You are a business-accuracy SQL reviewer. Review the query below and determine whether it answers the business question correctly. Business question: [BUSINESS QUESTION] SQL query: [PASTE QUERY] Context: Database dialect: [DIALECT] Expected metric definition: [METRIC DEFINITION] Expected grain: [GRAIN] Expected filters: [FILTERS] Expected timeframe: [TIMEFRAME] Known table relationships: [RELATIONSHIPS] Stakeholder use: [USE CASE] Risk level: [LOW / MEDIUM / HIGH] Review the query: A. Business alignment Check whether the query matches: - business question - metric definition - timeframe - segment logic - filters - exclusions - expected output grain B. Logic risks Inspect for: - wrong table - wrong date field - wrong denominator - wrong join type - duplicate inflation - missing filters - incorrect aggregation - null handling issue - ratio calculation issue - incomplete period issue C. Query result risk Explain how each issue could change the business conclusion. D. Required fixes Provide: - critical fixes - recommended fixes - optional improvements - questions for stakeholder - questions for data owner E. Corrected SQL If enough context exists, write a corrected version. F. Approval status Classify as: - approved - approved with caveats - needs revision - needs business definition - needs data owner review Rules: - Do not approve a query only because syntax is valid. - Do not assume unclear metrics. - Do not ignore business grain. - The review must protect business decisions from incorrect SQL logic. --------------------------------------------------------------------------------

#100Full SQL Queries, Database Analysis and Data Extraction Audit

SQL QUERIES, DATABASE ANALYSIS & DATA EXTRACTIONData analysts, BI teams, analytics engineers, SQL learners, consultants, product analysts, finance analysts, operations analysts, and anyone producing business-critical SQL.

Audit and rebuild SQL work across business logic, joins, filters, aggregations, CTEs, date logic, performance, extraction, validation, and documentation.

Act as an independent SQL analytics auditor. Review my SQL query, database logic, or extraction workflow and rebuild it into a correct, readable, validated, business-ready SQL solution. Full context: Business question: [QUESTION] Decision to support: [DECISION] Database dialect: [DIALECT] Current SQL query: [PASTE QUERY] Available tables: [TABLES] Schemas: [SCHEMAS] Expected output: [OUTPUT] Expected grain: [GRAIN] Metric definitions: [METRICS] Required filters: [FILTERS] Required timeframe: [TIMEFRAME] Join keys: [JOIN KEYS] Known table relationships: [RELATIONSHIPS] Known data quality issues: [DATA ISSUES] Performance constraints: [CONSTRAINTS] Audience: [AUDIENCE] Risk level: [LOW / MEDIUM / HIGH] Audit across 60 dimensions: 1. Business question alignment 2. Metric definition alignment 3. Expected grain clarity 4. Source table selection 5. Fact table choice 6. Dimension table choice 7. Join key correctness 8. Join type correctness 9. Join relationship safety 10. Row multiplication risk 11. Missing join key handling 12. Duplicate handling 13. Filter logic 14. Date field selection 15. Date boundary logic 16. Timezone handling 17. Incomplete period handling 18. Aggregation level 19. GROUP BY correctness 20. HAVING usage 21. WHERE usage 22. CASE WHEN logic 23. Null handling 24. Division-by-zero handling 25. Ratio calculation 26. Weighted average logic 27. Window function logic 28. Ranking logic 29. Deduplication logic 30. CTE readability 31. Alias clarity 32. Column selection 33. SELECT * risk 34. Output field naming 35. Data type handling 36. Categorical logic 37. Numeric range handling 38. Funnel logic, if relevant 39. Cohort logic, if relevant 40. Extraction readiness 41. Dashboard readiness 42. View design readiness 43. Sensitive field handling 44. Row count validation 45. Metric reconciliation 46. Source-of-truth comparison 47. Sample record inspection 48. Quality check coverage 49. Performance efficiency 50. Scanned data volume 51. Index or partition use 52. Reusable logic 53. Documentation 54. Comment quality 55. Dialect-specific compatibility 56. Maintainability 57. Reviewer readability 58. Stakeholder caveats 59. Error risk 60. Overall SQL readiness For each dimension provide: - score from 1 to 10 - diagnosis - evidence from the query or context - analytical risk if ignored - business risk if ignored - recommended fix - priority - effort - confidence level Then synthesize: A. Hard truth Explain the biggest reason this SQL may produce wrong, misleading, slow, or hard-to-maintain results. B. Rebuilt SQL solution Create: - business logic summary - table map - join plan - metric logic - filter logic - date logic - final SQL query - validation queries - performance notes - documentation block C. First 10 SQL fixes Rank the first 10 improvements. For each include: - issue - fix - why it matters - validation check - risk reduced D. Query validation pack Write SQL checks for: - row counts - missing keys - duplicate keys - unmatched joins - metric totals - date coverage - category values - sample records E. Stakeholder handoff note Write a concise explanation of what the query returns, what it excludes, and what caveats remain. F. Executive summary Write a direct summary with: - strongest part of the SQL - weakest part of the SQL - biggest join risk - biggest metric risk - biggest date logic risk - first validation query to run - one operating principle for trustworthy SQL Rules: - Do not approve SQL just because it runs. - Do not change business logic silently. - Do not ignore grain, joins, date logic, or metric definitions. - Use [NEEDS SCHEMA], [NEEDS METRIC DEFINITION], [NEEDS JOIN VALIDATION], [NEEDS DATA OWNER REVIEW], [NEEDS PERFORMANCE REVIEW], or [NEEDS PRIVACY REVIEW] where required. - The final SQL solution must be correct, readable, validated, and aligned with the business question.

#101Spreadsheet Cleaning Workflow Designer

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISData analysts, business analysts, operations teams, finance users, marketers, spreadsheet-heavy teams, small businesses, and anyone cleaning data manually.

Create a practical spreadsheet cleaning workflow that turns messy Excel or Google Sheets data into a structured, analysis-ready table.

You are a spreadsheet data cleaning specialist. Build a step-by-step cleaning workflow for the spreadsheet dataset below. Spreadsheet context: Tool: [EXCEL / GOOGLE SHEETS] Dataset purpose: [PURPOSE] Business question: [QUESTION] Raw sheet structure: [STRUCTURE] Number of rows: [ROWS] Number of columns: [COLUMNS] Known issues: [ISSUES] Important columns: [COLUMNS] Expected final output: [OUTPUT] User skill level: [BEGINNER / INTERMEDIATE / ADVANCED] Must preserve: [MUST PRESERVE] Create the cleaning workflow: 1. File safety setup Design a safe structure with: - raw data tab - cleaned data tab - lookup tables tab - formulas tab - QA checks tab - notes or cleaning log tab - version naming rule 2. Structure cleanup Explain how to handle: - merged cells - blank rows - repeated headers - totals inside raw data - hidden rows - inconsistent columns - comments inside cells - multiple tables on one sheet 3. Field cleanup Create steps for: - trimming spaces - standardizing headers - fixing date formats - converting text numbers to real numbers - standardizing currencies - normalizing categories - splitting combined fields - filling or flagging blanks - removing exact duplicates - flagging possible duplicates 4. Formula recommendations Suggest spreadsheet formulas for each cleaning task. Include both Excel and Google Sheets options where different. 5. Quality checks Create checks for: - row count before and after cleaning - missing values - duplicate keys - invalid categories - impossible numeric values - date range - totals reconciliation 6. Final readiness checklist Create a checklist that confirms the dataset is ready for pivot tables, formulas, dashboards, or export. Rules: - Do not edit the only copy of the raw data. - Do not use cell colors as the only source of meaning. - Do not delete rows before documenting the reason. - The workflow must be usable by someone working directly inside a spreadsheet. --------------------------------------------------------------------------------

#102Business Question to Spreadsheet Formula Translator

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, analysts, finance teams, operations teams, marketers, founders, and anyone turning business logic into spreadsheet formulas.

Convert a business question into exact spreadsheet formulas, helper columns, required fields, assumptions, and validation checks.

Act as a spreadsheet formula architect. Translate the business question below into formulas I can use in Excel or Google Sheets. Business context: Business question: [QUESTION] Tool: [EXCEL / GOOGLE SHEETS] Dataset columns: [COLUMNS] Sheet names: [SHEET NAMES] Required metric: [METRIC] Required filters: [FILTERS] Required grouping: [GROUPING] Time period: [TIME PERIOD] Expected output cell or table: [OUTPUT] Known edge cases: [EDGE CASES] Formula skill level: [BEGINNER / INTERMEDIATE / ADVANCED] Build the formula solution: A. Formula logic Explain: - what needs to be calculated - which columns are required - what filters apply - what grouping is needed - what assumptions are being made B. Helper column design Recommend helper columns if needed. For each helper column include: - column name - purpose - formula - expected result - validation check C. Final formula Provide formulas for: - Excel - Google Sheets, if different D. Formula breakdown Explain each part of the formula in plain language. E. Edge case handling Account for: - blanks - text numbers - errors - missing lookup matches - zero denominators - duplicate values - dates stored as text F. QA checks Create test cases with expected results. Rules: - Do not create a formula before defining the business logic. - Do not ignore blank cells, errors, or division by zero. - Do not use overly complex formulas if helper columns make the workbook safer. - The final formula must be copyable and practical. --------------------------------------------------------------------------------

#103Lookup and Matching Formula Builder

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, data analysts, finance teams, operations teams, sales ops, HR teams, and anyone matching data across spreadsheets.

Build reliable lookup formulas for matching records across sheets, handling missing matches, duplicate keys, approximate matches, and fallback logic.

You are a lookup formula specialist. Build a reliable lookup system for matching data between sheets. Lookup context: Tool: [EXCEL / GOOGLE SHEETS] Main sheet: [MAIN SHEET] Lookup sheet: [LOOKUP SHEET] Main key column: [MAIN KEY] Lookup key column: [LOOKUP KEY] Value to return: [RETURN VALUE] Expected match type: [EXACT / APPROXIMATE / MULTIPLE MATCHES] Known key issues: [ISSUES] Duplicate key risk: [DUPLICATES] Missing match handling: [MISSING HANDLING] Desired formula type: [XLOOKUP / VLOOKUP / INDEX MATCH / FILTER / QUERY] Create the lookup solution: 1. Match logic Define: - what record is being matched - key field - return field - expected uniqueness - match type - fallback behavior 2. Key preparation Create helper formulas to standardize keys: - trim spaces - lower or upper case - remove hidden characters - convert numbers stored as text - combine multiple key fields - flag blank keys 3. Lookup formulas Provide formulas for: - XLOOKUP - INDEX MATCH - VLOOKUP, if needed - FILTER for multiple matches - Google Sheets alternative, if different 4. Error handling Show how to handle: - missing match - duplicate match - blank key - invalid key - multiple possible matches 5. Validation checks Create formulas to check: - unmatched records - duplicate keys in lookup table - duplicate keys in main table - match rate - sample matched records 6. Recommendation Choose the best formula approach and explain why. Rules: - Do not use VLOOKUP if columns may move and a safer option exists. - Do not assume lookup keys are clean. - Do not hide missing matches with blank output unless intentional. - The lookup system must be reliable and auditable. --------------------------------------------------------------------------------

#104Pivot Table Analysis Planner

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, BI beginners, business analysts, finance teams, sales teams, marketers, operations teams, and managers using pivots.

Design pivot tables that summarize business data by metrics, segments, periods, categories, and drilldowns without misleading aggregation.

Act as a pivot table analysis designer. Build a pivot table plan for the dataset and business question below. Pivot context: Tool: [EXCEL / GOOGLE SHEETS] Dataset columns: [COLUMNS] Business question: [QUESTION] Primary metric: [METRIC] Secondary metrics: [SECONDARY METRICS] Date field: [DATE FIELD] Segments: [SEGMENTS] Filters: [FILTERS] Expected audience: [AUDIENCE] Decision to support: [DECISION] Design the pivot analysis: A. Source data readiness Check whether the data has: - one header row - one row per record - no merged cells - no totals inside the data - clean date field - clean category fields - numeric metric fields - no hidden filter issue B. Pivot table designs Create 5 pivot table views: 1. Overall summary 2. Trend by time period 3. Segment comparison 4. Top and bottom categories 5. Exception or anomaly view For each view include: - pivot purpose - rows - columns - values - filters - calculated fields - sorting - formatting - business question answered C. Metric aggregation rules Explain whether to use: - sum - count - distinct count - average - weighted average - percentage of total - running total D. Pivot QA checks Create checks for: - grand totals vs source data - date grouping accuracy - blank categories - duplicate source records - wrong average calculation - filter consistency Rules: - Do not build a pivot from messy source data. - Do not average percentages unless weighted logic is correct. - Do not hide blank categories if they affect interpretation. - The pivot table must answer business questions, not just summarize data. --------------------------------------------------------------------------------

#105Period Comparison Spreadsheet Model

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISFinance analysts, sales teams, marketing analysts, operations teams, founders, ecommerce teams, dashboards, and recurring performance reviews.

Build a spreadsheet model for comparing current vs previous period, month over month, year over year, plan vs actual, or before vs after changes.

You are a spreadsheet performance comparison analyst. Create a period comparison model for the metric below. Comparison context: Tool: [EXCEL / GOOGLE SHEETS] Metric: [METRIC] Dataset columns: [COLUMNS] Date field: [DATE FIELD] Current period: [CURRENT PERIOD] Comparison period: [COMPARISON PERIOD] Segments: [SEGMENTS] Filters: [FILTERS] Business goal: [GOAL] Expected output: [TABLE / DASHBOARD / CHART] Known calendar issues: [ISSUES] Build the model: 1. Period definitions Define: - current period - prior period - same period last year - rolling period, if needed - incomplete period rule - fiscal calendar rule, if relevant 2. Spreadsheet structure Create tabs: - raw data - cleaned data - period mapping - metric calculations - comparison summary - charts - QA checks 3. Formula design Create formulas for: - current period value - comparison period value - absolute difference - percentage difference - contribution to change - rank by change - segment share - rolling average, if useful 4. Comparison table Design a table with columns: - segment - current value - previous value - absolute change - percentage change - share of total change - status - notes 5. Visuals Recommend charts for: - trend - variance - segment contribution - top changes - waterfall-style explanation 6. QA checks Create checks for: - date grouping - incomplete periods - totals reconciliation - blank segments - negative or zero denominator issues Rules: - Do not compare incomplete periods without labeling them. - Do not calculate percentage change when the denominator is zero without a rule. - Do not ignore seasonality or fiscal calendars. - The model must make period movement easy to understand and trust. --------------------------------------------------------------------------------

#106Spreadsheet Metric Calculator Framework

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISData analysts, finance teams, operations teams, marketers, founders, product teams, revenue teams, and anyone building metric spreadsheets.

Create a reusable spreadsheet framework for calculating business metrics with inputs, formulas, definitions, assumptions, and checks.

Act as a spreadsheet metric framework designer. Build a reusable calculator for the business metrics below. Metric context: Tool: [EXCEL / GOOGLE SHEETS] Metrics needed: [METRICS] Business definitions: [DEFINITIONS] Source data columns: [COLUMNS] Required filters: [FILTERS] Segments: [SEGMENTS] Time period: [TIME PERIOD] Stakeholders: [STAKEHOLDERS] Expected use: [ONE-TIME / RECURRING / DASHBOARD] Known assumptions: [ASSUMPTIONS] Create the framework: A. Metric definition table For each metric include: - metric name - business purpose - formula in plain language - numerator - denominator - source columns - filters - exclusions - owner - caveats B. Spreadsheet layout Design tabs for: - raw data - assumptions - metric definitions - calculations - summary output - QA checks - documentation C. Formula implementation For each metric provide: - helper column formulas - final metric formula - segmented metric formula - date-filtered metric formula - error handling D. Assumption controls Create editable input cells for: - date range - segment filter - status filter - target value - threshold - currency or unit E. QA and validation Create checks for: - numerator does not exceed denominator - denominator not zero - totals match source - formulas copied correctly - metric values within expected range Rules: - Do not define metrics only inside formulas. - Do not hard-code assumptions across multiple cells without documentation. - Do not mix raw data and calculations in the same area. - The framework must be reusable and easy to audit. --------------------------------------------------------------------------------

#107Conditional Formatting QA System

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, operations dashboards, finance trackers, QA sheets, sales reports, inventory files, and recurring analysis workflows.

Use conditional formatting to highlight errors, risks, trends, thresholds, missing values, duplicates, and business exceptions in spreadsheets.

You are a spreadsheet QA and conditional formatting designer. Build a conditional formatting system for the spreadsheet below. Spreadsheet context: Tool: [EXCEL / GOOGLE SHEETS] Sheet purpose: [PURPOSE] Columns: [COLUMNS] Key metrics or fields: [FIELDS] Business thresholds: [THRESHOLDS] Known error types: [ERROR TYPES] Users: [USERS] Frequency of use: [FREQUENCY] Risk level: [LOW / MEDIUM / HIGH] Create the conditional formatting system: 1. Formatting goals Define what the formatting should help users notice: - missing values - duplicate records - invalid entries - metric thresholds - late dates - negative values - outliers - status conflicts - approaching deadlines - formula errors 2. Rule library Create conditional formatting rules for: - blanks in required fields - duplicate IDs - dates older than expected - values above threshold - values below threshold - invalid category - formula error - high-risk status - changed value - mismatch between fields For each rule include: - field or range - condition - formatting style - meaning - action user should take 3. Priority and conflict order Explain which rules should override others. 4. Legend Create a legend explaining each color or icon. 5. QA sheet Create formulas that count how many issues are flagged. 6. Maintenance rules Explain how to update thresholds and ranges safely. Rules: - Do not use too many colors that confuse users. - Do not rely on formatting without a written rule. - Do not flag values without explaining required action. - Conditional formatting should make spreadsheet review faster and safer. --------------------------------------------------------------------------------

#108Spreadsheet Error Audit and Formula QA

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISFinance analysts, data analysts, business analysts, spreadsheet reviewers, operations teams, founders, and anyone relying on important workbook formulas.

Audit a spreadsheet for broken formulas, hardcoded values, inconsistent ranges, hidden errors, incorrect references, and risky calculations.

Act as a spreadsheet formula auditor. Review the spreadsheet logic below and identify errors, risks, and fixes. Workbook context: Tool: [EXCEL / GOOGLE SHEETS] Workbook purpose: [PURPOSE] Important formulas: [PASTE FORMULAS OR DESCRIBE] Sheet names: [SHEETS] Critical outputs: [OUTPUTS] Known issues: [ISSUES] Users: [USERS] Risk level: [LOW / MEDIUM / HIGH] Review goal: [GOAL] Audit the workbook: A. Formula risk scan Check for: - broken references - inconsistent copied formulas - hardcoded values inside formulas - wrong absolute or relative references - incorrect ranges - hidden rows affecting formulas - formulas skipping new rows - circular references - divide-by-zero errors - date formula errors - lookup errors - manual overrides B. Output validation For each critical output, check: - formula source - input cells - assumptions - calculation logic - expected range - test case - sensitivity to missing data C. Formula improvement Recommend safer formulas using: - named ranges - tables - helper columns - IFERROR with caution - LET, if Excel supports it - XLOOKUP instead of VLOOKUP where appropriate - SUMIFS / COUNTIFS / AVERAGEIFS - pivot tables where formulas are too fragile D. QA checklist Create a workbook review checklist. E. Fix priority Classify issues as: - critical - important - cleanup - documentation Rules: - Do not hide errors with IFERROR unless the fallback is meaningful. - Do not approve formulas with inconsistent ranges. - Do not mix manual overrides with formulas without clear marking. - The audit must protect business outputs from spreadsheet mistakes. --------------------------------------------------------------------------------

#109Spreadsheet Summary Dashboard Builder

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel dashboards, Google Sheets dashboards, business reviews, sales trackers, finance reports, marketing reports, operations dashboards, and founder reporting.

Design a practical spreadsheet dashboard with KPIs, charts, filters, period comparisons, notes, and QA checks.

You are a spreadsheet dashboard designer. Build a simple, reliable dashboard layout for the dataset and business question below. Dashboard context: Tool: [EXCEL / GOOGLE SHEETS] Business area: [AREA] Audience: [AUDIENCE] Dataset columns: [COLUMNS] Main KPIs: [KPIS] Time period: [TIME PERIOD] Segments or filters: [FILTERS] Refresh frequency: [FREQUENCY] Decision supported: [DECISION] Preferred style: [STYLE] Known data risks: [RISKS] Design the dashboard: 1. Dashboard purpose Define: - who uses it - when they use it - what decision it supports - what action should follow - what it should not be used for 2. Dashboard layout Create sections: - headline KPI cards - period comparison - trend chart - segment breakdown - top and bottom contributors - exception list - notes and caveats - refresh timestamp 3. Calculation layer Define where formulas or pivots should live. For each KPI include: - formula - source columns - filters - comparison logic - target or threshold - QA check 4. Chart plan Recommend charts with: - chart type - data range - metric shown - interpretation note - risk of misreading 5. User controls Design filters such as: - date range - segment - product - region - channel - status 6. QA and maintenance Create checks for refresh, source range, formula errors, and totals. Rules: - Do not build a dashboard directly on messy raw data. - Do not include charts without decision purpose. - Do not hide caveats or refresh date. - The dashboard must be practical, readable, and trustworthy. --------------------------------------------------------------------------------

#110Repetitive Spreadsheet Analysis Automation Plan

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISAnalysts, operations teams, finance users, marketers, sales ops, spreadsheet-heavy businesses, and anyone repeating the same analysis manually.

Automate recurring spreadsheet tasks using formulas, pivots, Power Query, Apps Script, macros, templates, or structured workflows.

Act as a spreadsheet automation strategist. Create a plan to automate the recurring spreadsheet task below. Automation context: Tool: [EXCEL / GOOGLE SHEETS] Recurring task: [TASK] Current manual steps: [STEPS] Input data source: [SOURCE] Output needed: [OUTPUT] Frequency: [DAILY / WEEKLY / MONTHLY / AD HOC] Current pain points: [PAIN POINTS] User skill level: [SKILL LEVEL] Allowed tools: [FORMULAS / PIVOTS / POWER QUERY / MACROS / APPS SCRIPT / OTHER] Risk tolerance: [LOW / MEDIUM / HIGH] Design the automation plan: A. Automation suitability Classify each step as: - formula-based - pivot-based - Power Query or import-based - macro or script-based - template-based - should remain manual - requires human review B. Workflow redesign Create a new workflow: - import data - clean data - validate data - calculate metrics - update summary - refresh charts - export or share - archive version C. Formula and tool recommendations Recommend exact spreadsheet functions or tools for: - importing - cleaning - matching - summarizing - checking errors - updating reports D. Human review gates Define where the user must still check results. E. Implementation roadmap Create: - quick win automation - medium automation - advanced automation - testing plan - rollback plan F. Time savings estimate Estimate what time can be saved and what risk remains. Rules: - Do not automate a broken process without fixing logic first. - Do not use scripts if formulas or pivots are safer and enough. - Do not automate outputs without QA checks. - The plan must reduce repetitive work while keeping control and accuracy. --------------------------------------------------------------------------------

#111Data Validation and Input Control Designer

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel forms, Google Sheets trackers, manual data collection, operations logs, CRM exports, finance trackers, team templates, and data collection workflows.

Create spreadsheet input controls using dropdowns, validation rules, protected ranges, required fields, error messages, and user instructions.

You are a spreadsheet input control designer. Build data validation rules for the spreadsheet template below. Template context: Tool: [EXCEL / GOOGLE SHEETS] Template purpose: [PURPOSE] Users entering data: [USERS] Columns to fill: [COLUMNS] Required fields: [REQUIRED FIELDS] Allowed categories: [CATEGORIES] Date rules: [DATE RULES] Numeric rules: [NUMERIC RULES] Current data entry errors: [ERRORS] Privacy or access constraints: [CONSTRAINTS] Create the validation system: 1. Field rules table For each input column include: - field name - required or optional - allowed input type - dropdown values - validation formula, if needed - error message - example correct value - example incorrect value 2. Input protection Recommend: - locked formula cells - editable input cells - protected tabs - named ranges - hidden support tables - version control 3. Error prevention Create rules for: - duplicate IDs - invalid dates - negative numbers - future dates - missing required values - inconsistent status values - invalid email format - invalid category 4. User instructions Write clear instructions for people entering data. 5. QA summary Create a summary area that counts validation problems. Rules: - Do not allow free text where standardized values are required. - Do not protect the sheet so much that users cannot do their work. - Do not rely on memory or training only. - Validation must make data entry easier and cleaner. --------------------------------------------------------------------------------

#112Multi-Sheet Consolidation Planner

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISFinance teams, operations teams, sales reporting, monthly reporting, analysts, spreadsheet users, small businesses, and manual consolidation workflows.

Combine multiple sheets, tabs, files, or monthly reports into one reliable master table with consistent columns, labels, dates, and source tracking.

Act as a spreadsheet consolidation expert. Create a plan to combine multiple sheets or files into one clean master dataset. Consolidation context: Tool: [EXCEL / GOOGLE SHEETS] Files or tabs to combine: [FILES / TABS] Business purpose: [PURPOSE] Expected master table grain: [GRAIN] Common columns: [COMMON COLUMNS] Inconsistent columns: [INCONSISTENT COLUMNS] Time periods: [TIME PERIODS] Known naming differences: [NAMING DIFFERENCES] Need source tracking: [YES / NO] Current consolidation problem: [PROBLEM] Build the consolidation plan: A. Structure audit For each sheet or file check: - header row - column names - column order - data types - missing columns - extra columns - date format - totals inside data - notes or merged cells B. Standard master schema Create a master column list with: - field name - definition - data type - required or optional - source mapping - transformation needed C. Source mapping table Map each source column to the master schema. D. Consolidation method Recommend the best method: - copy-paste into master template - Excel Power Query - Google Sheets QUERY - IMPORTRANGE - VSTACK - Apps Script - manual controlled process E. QA checks Create checks for: - row counts by source - missing columns - duplicate rows - totals reconciliation - date coverage - source tab tracking F. Maintenance process Explain how to add new monthly or weekly files safely. Rules: - Do not combine sheets before standardizing columns. - Do not lose source file or tab identity. - Do not mix summary rows with raw records. - The master table must be stable, traceable, and analysis-ready. --------------------------------------------------------------------------------

#113Spreadsheet Reconciliation Template Builder

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISFinance teams, accounting, operations, sales ops, inventory, payroll, data analysts, revenue teams, and anyone comparing reports or systems.

Create a spreadsheet reconciliation process for comparing two data sources, finding mismatches, explaining variances, and documenting resolution.

You are a spreadsheet reconciliation specialist. Build a reconciliation template for comparing two datasets. Reconciliation context: Tool: [EXCEL / GOOGLE SHEETS] Dataset A: [DATASET A] Dataset B: [DATASET B] Business purpose: [PURPOSE] Matching key: [KEY] Metrics or values to reconcile: [VALUES] Expected tolerance: [TOLERANCE] Time period: [TIME PERIOD] Known mismatch reasons: [REASONS] Output needed: [OUTPUT] Create the reconciliation system: 1. Reconciliation logic Define: - what should match - match key - match type - tolerance rule - expected timing differences - acceptable variance - unacceptable variance 2. Template structure Create tabs: - source A - source B - standardized A - standardized B - matched records - unmatched records - variance summary - resolution log 3. Matching formulas Provide formulas for: - key standardization - lookup match - match status - amount variance - percentage variance - missing in A - missing in B - duplicate key flag 4. Variance classification Create categories: - exact match - within tolerance - timing difference - missing in source A - missing in source B - value mismatch - duplicate issue - needs investigation 5. Summary dashboard Design summary metrics and charts for reconciliation status. 6. Resolution log Create fields for owner, reason, action, and final status. Rules: - Do not compare values before standardizing keys and formats. - Do not hide unmatched records. - Do not treat timing differences as errors without checking business process. - The reconciliation must make mismatches visible and resolvable. --------------------------------------------------------------------------------

#114Dynamic Spreadsheet Report Formula Builder

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISGoogle Sheets users, Excel 365 users, analysts, reporting teams, sales ops, marketing teams, operations teams, and anyone building dynamic reports without a BI tool.

Build dynamic spreadsheet reports using formulas like FILTER, SORT, UNIQUE, QUERY, SUMIFS, COUNTIFS, INDEX, MATCH, XLOOKUP, and dynamic arrays.

Act as a dynamic spreadsheet report builder. Create formulas for a report that updates automatically based on inputs and filters. Report context: Tool: [EXCEL 365 / GOOGLE SHEETS] Source table name or range: [SOURCE] Columns: [COLUMNS] Report purpose: [PURPOSE] User controls: [FILTER INPUTS] Metrics needed: [METRICS] Segments: [SEGMENTS] Sorting rule: [SORTING] Output layout: [OUTPUT] Known constraints: [CONSTRAINTS] Build the dynamic report: A. Report controls Define input cells for: - start date - end date - segment - category - status - top N - metric selection - search term B. Formula architecture Recommend formulas for: - dynamic filtering - unique list generation - sorted output - grouped summaries - lookup fields - error handling - dynamic headers C. Formula set Provide formulas using: - FILTER - SORT - UNIQUE - SUMIFS - COUNTIFS - AVERAGEIFS - QUERY, if Google Sheets - LET, if Excel - XLOOKUP or INDEX MATCH D. Output table design Create the final report layout: - columns - formulas - formatting - totals - notes - refresh instructions E. QA checks Create tests for: - no matching records - blank filters - invalid dates - top N larger than results - missing values - formula spill errors Rules: - Do not hard-code filters into formulas if users need controls. - Do not build fragile formulas that break when rows are added. - Do not hide errors without meaningful fallback messages. - The report must update safely when source data changes. --------------------------------------------------------------------------------

#115Scenario and Sensitivity Analysis Spreadsheet Model

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISFinance teams, business analysts, founders, revenue planning, operations planning, pricing analysis, forecasting, budgeting, and decision modeling.

Build a spreadsheet model that tests scenarios, assumptions, ranges, drivers, sensitivities, and best/base/worst cases.

You are a spreadsheet scenario modeling expert. Build a scenario and sensitivity analysis model for the decision below. Model context: Decision or question: [DECISION] Business metric to estimate: [METRIC] Key assumptions: [ASSUMPTIONS] Input drivers: [DRIVERS] Base values: [BASE VALUES] Possible ranges: [RANGES] Output needed: [OUTPUT] Tool: [EXCEL / GOOGLE SHEETS] Audience: [AUDIENCE] Risk level: [LOW / MEDIUM / HIGH] Design the model: 1. Model objective Define: - decision supported - output metric - time horizon - key business drivers - model limitations 2. Input section Create editable input cells for: - base assumptions - best-case assumptions - worst-case assumptions - custom scenario assumptions - sensitivity ranges 3. Calculation logic Build formulas for: - base case - best case - worst case - custom case - variance from base - percentage change - contribution by driver 4. Sensitivity table Create a table that varies one driver at a time. Include: - driver - low value - base value - high value - output impact - risk level 5. Scenario dashboard Design charts and tables for: - scenario comparison - driver impact - sensitivity ranking - break-even point - decision threshold 6. QA checks Create checks for: - impossible inputs - negative values - circular references - inconsistent units - formula ranges - missing assumptions Rules: - Do not hide assumptions inside formulas. - Do not present scenarios as forecasts. - Do not make the model more precise than the assumptions allow. - The spreadsheet must make decision tradeoffs visible. --------------------------------------------------------------------------------

#116Text Parsing and Standardization Formula System

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISSpreadsheet users, analysts, operations teams, marketers, CRM teams, sales teams, survey analysts, ecommerce teams, and anyone cleaning text-heavy data.

Create formulas to split, extract, clean, standardize, and classify messy text fields in spreadsheets.

Act as a spreadsheet text-cleaning formula specialist. Build formulas to parse and standardize the messy text field below. Text context: Tool: [EXCEL / GOOGLE SHEETS] Text field name: [FIELD] Sample raw values: [SAMPLE VALUES] Desired output fields: [OUTPUT FIELDS] Common patterns: [PATTERNS] Known problems: [PROBLEMS] Need classification: [YES / NO] Need extraction: [YES / NO] Need standardization: [YES / NO] Create the text formula system: A. Pattern diagnosis Identify: - delimiters - inconsistent spacing - capitalization issues - extra characters - prefixes or suffixes - mixed values in one cell - embedded IDs - dates inside text - category labels - invalid text B. Cleaning formulas Provide formulas for: - TRIM / CLEAN - lower / upper / proper case - remove extra characters - replace text - standardize spelling variants - remove line breaks - normalize spaces C. Extraction formulas Provide formulas for: - extract text before delimiter - extract text after delimiter - extract between characters - extract numbers - extract email or domain pattern, if possible - split full names or codes - parse combined category and ID D. Classification formulas Create formulas using: - IF - IFS - SWITCH - SEARCH - REGEXMATCH, if Google Sheets - TEXTBEFORE / TEXTAFTER, if Excel E. QA checks Create checks for: - blanks - failed extraction - unexpected patterns - duplicate standardized values - manual review needed Rules: - Do not assume all text follows one pattern. - Do not overwrite original text values. - Do not create formulas that fail silently. - The system should make messy text usable for analysis. --------------------------------------------------------------------------------

#117Date and Time Analysis Formula Builder

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, finance analysts, operations teams, HR teams, sales teams, support teams, project trackers, and recurring reports.

Build spreadsheet formulas for parsing dates, grouping by periods, calculating duration, aging, deadlines, cohorts, and time-based metrics.

You are a spreadsheet date and time formula expert. Create formulas for the time-based analysis below. Date analysis context: Tool: [EXCEL / GOOGLE SHEETS] Date fields: [DATE FIELDS] Timestamp fields: [TIMESTAMP FIELDS] Business question: [QUESTION] Needed outputs: [OUTPUTS] Date format issues: [ISSUES] Timezone or locale: [TIMEZONE / LOCALE] Period grouping needed: [DAY / WEEK / MONTH / QUARTER / YEAR] Deadline rules: [RULES] Current date reference: [TODAY / FIXED DATE / CELL REFERENCE] Build the date formula system: A. Date parsing Create formulas for: - converting text to dates - detecting invalid dates - extracting year - extracting month - extracting week - creating month label - creating quarter - creating fiscal period, if needed B. Duration calculations Create formulas for: - days between dates - business days between dates - age of record - time since last activity - time to deadline - overdue days - cycle time C. Period grouping Create formulas to group records by: - day - week start - month start - month name - quarter - year - fiscal period D. Status classification Create formulas for: - overdue - due soon - on track - completed late - completed on time - missing date - future date issue E. QA checks Create checks for: - end date before start date - blank date - future date - impossible old date - text stored as date - timestamp timezone risk Rules: - Do not mix date text and real date values without conversion. - Do not rely on visual formatting only. - Do not calculate duration before checking missing dates. - Date formulas must be reliable for filtering, pivots, and reporting. --------------------------------------------------------------------------------

#118Spreadsheet Performance and File Stability Optimizer

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel power users, Google Sheets users, analysts, finance teams, operations teams, dashboard builders, and teams with large or slow workbooks.

Improve slow, fragile, or oversized spreadsheets by reducing volatile formulas, optimizing ranges, restructuring tabs, and improving calculation logic.

Act as a spreadsheet performance optimizer. Review the workbook structure below and recommend how to make it faster, safer, and easier to maintain. Workbook context: Tool: [EXCEL / GOOGLE SHEETS] Workbook purpose: [PURPOSE] Approximate rows: [ROWS] Approximate columns: [COLUMNS] Number of tabs: [TABS] Slow areas: [SLOW AREAS] Formula types used: [FORMULAS] External links or imports: [LINKS / IMPORTS] Pivot tables: [PIVOTS] Charts or dashboards: [CHARTS] Known errors: [ERRORS] Create the optimization plan: A. Performance diagnosis Check for: - full-column formulas - volatile functions - too many array formulas - excessive conditional formatting - repeated lookups - unnecessary calculations - too many charts - external links - large unused ranges - hidden old tabs - complex nested formulas B. Optimization recommendations For each issue provide: - problem - why it slows the file - safer alternative - expected benefit - risk - effort level C. Formula optimization Suggest improvements such as: - helper columns - lookup tables - pivot tables - named ranges - structured tables - QUERY or FILTER alternatives - Power Query - Apps Script or macro only if needed D. Workbook structure Recommend a cleaner tab structure. E. Stability checks Create checks for: - broken formulas - source range expansion - external link failure - refresh failure - hidden manual inputs Rules: - Do not optimize by making the workbook harder to understand. - Do not use scripts where formulas or pivots are enough. - Do not remove auditability for speed. - Optimization should improve speed, reliability, and maintainability. --------------------------------------------------------------------------------

#119Spreadsheet Handoff and Documentation Pack

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISAnalysts, consultants, finance teams, operations teams, founders, reporting teams, spreadsheet owners, and anyone handing over an important workbook.

Create documentation for a spreadsheet so another person can understand, refresh, audit, and reuse it safely.

You are a spreadsheet documentation and handoff specialist. Create a handoff pack for the workbook below. Workbook context: Workbook name: [WORKBOOK] Purpose: [PURPOSE] Audience: [AUDIENCE] Tool: [EXCEL / GOOGLE SHEETS] Tabs included: [TABS] Data sources: [SOURCES] Refresh frequency: [FREQUENCY] Important formulas: [FORMULAS] Important pivots or dashboards: [PIVOTS / DASHBOARDS] Known limitations: [LIMITATIONS] Owner: [OWNER] Next user: [NEXT USER] Create the handoff pack: A. Workbook overview Write: - what the workbook does - who uses it - business decisions supported - main outputs - refresh cadence - owner B. Tab guide For each tab include: - purpose - user should edit or not edit - source data or calculated - key formulas - dependencies - risks C. Formula and logic documentation Document: - key calculations - assumptions - named ranges - lookup logic - pivot sources - manual inputs - protected cells D. Refresh instructions Create a step-by-step process for: - updating source data - refreshing formulas - refreshing pivots - checking outputs - exporting reports - archiving old version E. QA checklist Create checks for: - source row counts - formula errors - dashboard totals - blank values - duplicate records - date coverage - external links F. Known caveats List what the workbook should not be used for. Rules: - Do not hand off a spreadsheet with undocumented formulas. - Do not leave manual steps hidden. - Do not assume the next user knows the logic. - The handoff pack must make the workbook reusable and safer. --------------------------------------------------------------------------------

#120Full Spreadsheets, Formulas and Practical Analysis Audit

SPREADSHEETS, FORMULAS & PRACTICAL ANALYSISExcel users, Google Sheets users, data analysts, business analysts, finance teams, operations teams, marketing teams, founders, consultants, and spreadsheet-heavy workflows.

Audit and rebuild a spreadsheet-based analysis workflow across cleaning, formulas, pivots, metrics, dashboards, automation, QA, documentation, and reliability.

Act as an independent spreadsheet analysis auditor. Review my workbook, spreadsheet model, or formula-based analysis workflow and rebuild it into a cleaner, faster, more reliable, and more auditable system. Full context: Tool: [EXCEL / GOOGLE SHEETS] Workbook purpose: [PURPOSE] Business question: [QUESTION] Audience: [AUDIENCE] Sheets or tabs: [TABS] Source data: [SOURCE DATA] Key columns: [COLUMNS] Key formulas: [FORMULAS] Pivot tables: [PIVOTS] Dashboards: [DASHBOARDS] Manual steps: [MANUAL STEPS] Known problems: [PROBLEMS] Refresh frequency: [FREQUENCY] Risk level: [LOW / MEDIUM / HIGH] Expected output: [OUTPUT] Audit across 60 dimensions: 1. Raw data preservation 2. Workbook structure 3. Tab naming 4. Source data layout 5. Header consistency 6. Merged cell risk 7. Hidden row or column risk 8. Data type consistency 9. Date formatting 10. Numeric formatting 11. Currency and unit consistency 12. Text cleanup 13. Category standardization 14. Missing value handling 15. Duplicate handling 16. Key field reliability 17. Formula correctness 18. Formula consistency 19. Formula range coverage 20. Absolute vs relative references 21. Hardcoded values 22. IFERROR use 23. Lookup reliability 24. XLOOKUP or VLOOKUP risk 25. SUMIFS logic 26. COUNTIFS logic 27. Ratio calculations 28. Weighted averages 29. Period comparison logic 30. Pivot table source range 31. Pivot aggregation method 32. Pivot refresh process 33. Dynamic report formulas 34. Conditional formatting 35. Data validation rules 36. Input control 37. Manual override risk 38. Dashboard KPI clarity 39. Chart selection 40. Filter logic 41. Scenario model assumptions 42. Reconciliation process 43. Multi-sheet consolidation 44. Automation opportunity 45. Script or macro risk 46. Performance and file speed 47. External links 48. Protected ranges 49. Version control 50. QA checks 51. Error flags 52. Totals reconciliation 53. Sensitivity to new rows 54. Documentation 55. Handoff readiness 56. User instructions 57. Privacy and sharing risk 58. Business interpretation risk 59. Maintenance effort 60. Overall spreadsheet reliability For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - business risk if ignored - spreadsheet risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason this spreadsheet may produce errors, waste time, or become hard to maintain. B. Rebuilt spreadsheet system Create: - recommended tab structure - data cleaning workflow - formula architecture - pivot table plan - metric calculator design - dashboard layout - QA check system - automation plan - documentation pack - handoff process C. First 10 fixes Rank the first 10 improvements. For each include: - issue - fix - why it matters - formula or tool needed - validation check - risk reduced D. Formula improvement pack Rewrite or recommend formulas for: - lookups - metric calculations - period comparisons - text cleanup - date grouping - error flags - summary tables E. QA checklist Create a reusable checklist for every refresh. F. Executive summary Write a direct summary with: - strongest part of the workbook - weakest part of the workbook - biggest formula risk - biggest pivot risk - biggest manual process risk - first QA check to add - one operating principle for reliable spreadsheet analysis Rules: - Do not mix raw data, calculations, and dashboards without clear structure. - Do not hide errors with formatting. - Do not recommend complex automation before fixing formulas and QA. - Use [NEEDS FORMULA REVIEW], [NEEDS DATA VALIDATION], [NEEDS PIVOT QA], [NEEDS OWNER REVIEW], or [NEEDS PRIVACY REVIEW] where required. - The final system should make spreadsheet work faster, safer, easier to audit, and more reliable.

#121KPI Definition and Business Alignment Builder

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, BI analysts, product managers, growth teams, finance teams, operations leaders, executives, founders, and teams building KPI systems.

Define KPIs that are connected to business goals, decisions, owners, formulas, targets, and real actions instead of vague reporting.

You are a senior analytics strategist. Help me define strong KPIs for the business goal below and make sure each KPI is measurable, actionable, and aligned with real decisions. Business context: Company or project: [COMPANY / PROJECT] Business model: [BUSINESS MODEL] Business goal: [GOAL] Department or team: [TEAM] Current metrics used: [CURRENT METRICS] Key stakeholders: [STAKEHOLDERS] Decision supported: [DECISION] Available data sources: [DATA SOURCES] Reporting frequency: [FREQUENCY] Current problems with reporting: [PROBLEMS] Time horizon: [TIME HORIZON] Build the KPI framework: 1. Business goal translation Rewrite the business goal into measurable language. Identify: - outcome the business wants - behavior the KPI should encourage - decision the KPI supports - team that can influence it - risk if the KPI is wrong 2. KPI candidates Create 10 KPI candidates. For each include: - KPI name - business purpose - formula - data source - owner - update frequency - decision use - action triggered - risk of misuse - confidence level 3. KPI selection Classify each KPI as: - primary KPI - secondary KPI - diagnostic metric - guardrail metric - vanity metric - not recommended 4. Final KPI set Choose the best KPI set and explain: - why each KPI matters - what it does not measure - how it connects to the business goal - what action should happen if it moves 5. KPI documentation Create a KPI definition card for each selected KPI. Rules: - Do not choose KPIs only because they are easy to measure. - Do not include vanity metrics that do not support action. - Do not use vague definitions like “active,” “quality,” or “engaged” without exact logic. - The final KPI set must be decision-connected and business-useful. --------------------------------------------------------------------------------

#122Metric Dictionary Architect

METRICS, KPIs & PERFORMANCE TRACKINGData teams, BI teams, analytics managers, dashboard owners, finance teams, product teams, marketing teams, RevOps, and organizations standardizing reporting.

Create a complete metric dictionary with definitions, formulas, owners, sources, filters, caveats, examples, and usage rules.

Act as a metric documentation architect. Build a metric dictionary for the business area below. Metric context: Business area: [BUSINESS AREA] Current metrics: [METRICS] Stakeholders: [STAKEHOLDERS] Data sources: [DATA SOURCES] Reporting tools: [TOOLS] Known definition conflicts: [CONFLICTS] Dashboard or report names: [REPORTS] Teams using the metrics: [TEAMS] Governance owner: [OWNER] Create the metric dictionary: A. Metric inventory List all metrics and group them by: - growth - revenue - customer - product - operations - finance - quality - risk - retention - efficiency B. Metric definition table For each metric include: - metric name - plain-language definition - business purpose - exact formula - numerator - denominator - grain - source table or system - filters - exclusions - refresh cadence - owner - related metrics - caveats - example calculation C. Usage rules Define: - when to use the metric - when not to use the metric - common mistakes - dashboard placement - decision use - audience D. Conflict resolution Identify metrics with unclear or competing definitions. For each conflict include: - conflicting definitions - business impact - recommended standard - approval needed - migration note E. Maintenance process Create rules for: - adding metrics - changing formulas - retiring metrics - reviewing ownership - communicating updates Rules: - Do not document metrics only at a technical column-name level. - Do not allow multiple teams to use different formulas silently. - Do not omit caveats and exclusions. - The dictionary must be usable by analysts and business stakeholders. --------------------------------------------------------------------------------

#123Leading and Lagging Indicator Map

METRICS, KPIs & PERFORMANCE TRACKINGStrategy teams, executives, product teams, growth teams, operations teams, finance teams, sales teams, marketing teams, and performance management.

Separate leading indicators, lagging indicators, input metrics, output metrics, and guardrails so teams can track progress before final outcomes move.

You are a performance measurement strategist. Build a leading and lagging indicator map for [BUSINESS GOAL / INITIATIVE]. Context: Business goal: [GOAL] Initiative or strategy: [INITIATIVE] Primary outcome: [OUTCOME] Team responsible: [TEAM] Decision horizon: [TIME HORIZON] Current metrics: [CURRENT METRICS] Available data: [DATA] Known delay between action and outcome: [DELAY] Business risks: [RISKS] Create the indicator map: 1. Outcome definition Define the final business outcome and why it is lagging. 2. Indicator categories Classify metrics into: - input metrics - activity metrics - leading indicators - intermediate indicators - lagging indicators - guardrail metrics - diagnostic metrics 3. Indicator chain Create a cause-and-effect style chain: Action → input → leading signal → intermediate result → lagging outcome → business impact 4. Metric table For each indicator include: - metric name - category - formula - owner - expected movement - how soon it should move - data source - interpretation - action if it changes - risk of false signal 5. Monitoring plan Define: - daily checks - weekly checks - monthly checks - decision thresholds - escalation triggers 6. Executive explanation Write a concise explanation of why the team should not wait for lagging outcomes alone. Rules: - Do not label a lagging metric as leading just because it updates frequently. - Do not assume a leading indicator is valid without business logic. - Do not track activity metrics without linking them to outcomes. - The map must help teams act earlier and avoid false confidence. --------------------------------------------------------------------------------

#124Performance Tracking Operating System

METRICS, KPIs & PERFORMANCE TRACKINGAnalytics teams, managers, founders, executives, team leads, operations teams, sales teams, marketing teams, product teams, and business review processes.

Build a recurring performance tracking system with cadence, owners, metrics, dashboards, review meetings, alerts, and action follow-up.

Act as a performance tracking operations designer. Create a system for tracking performance for [TEAM / BUSINESS AREA / INITIATIVE]. Tracking context: Business area: [AREA] Main goals: [GOALS] KPIs: [KPIS] Stakeholders: [STAKEHOLDERS] Decision cadence: [DAILY / WEEKLY / MONTHLY / QUARTERLY] Current reporting process: [PROCESS] Current problems: [PROBLEMS] Available dashboards: [DASHBOARDS] Data refresh cadence: [REFRESH] Team owners: [OWNERS] Action follow-up process: [FOLLOW-UP] Build the operating system: A. Tracking architecture Define: - primary KPIs - diagnostic metrics - guardrails - owner per metric - reporting frequency - review audience - action owner B. Review cadence Create routines for: - daily pulse - weekly performance review - monthly business review - quarterly strategic review For each routine include: - purpose - attendees - metrics reviewed - questions asked - decisions made - output - follow-up owner C. Performance thresholds Create thresholds for: - on track - watch - warning - critical - investigation required - decision required D. Action log Design a follow-up tracker with: - issue - metric affected - owner - action - deadline - expected impact - status - result E. Reporting hygiene Create rules for keeping reports useful and avoiding metric clutter. Rules: - Do not create performance tracking that only observes and never acts. - Do not review every metric at every meeting. - Do not let metrics have no owner. - The system must turn tracking into decisions and action. --------------------------------------------------------------------------------

#125Metric Movement Diagnostic Framework

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, BI teams, product analysts, finance analysts, growth analysts, marketing analysts, operations analysts, executives, and performance review teams.

Diagnose why a KPI or metric moved by decomposing change across time, segments, components, mix effects, data quality, and external factors.

You are a metric movement diagnostic analyst. Explain why [METRIC] changed and identify what should be investigated or acted on. Metric context: Metric: [METRIC] Current value: [CURRENT VALUE] Previous value: [PREVIOUS VALUE] Comparison period: [COMPARISON PERIOD] Business area: [AREA] Segments available: [SEGMENTS] Component metrics: [COMPONENTS] Known business events: [EVENTS] Known data issues: [DATA ISSUES] Stakeholder question: [QUESTION] Decision needed: [DECISION] Diagnose the movement: 1. Movement summary Calculate or describe: - absolute change - percentage change - direction - business significance - confidence level 2. Component decomposition Break the metric into components. Analyze whether movement is driven by: - numerator - denominator - volume - rate - price - cost - conversion - retention - mix - timing - outliers 3. Segment contribution Identify which segments contributed most to the change. For each segment include: - current value - prior value - change - contribution to total movement - possible explanation - action owner 4. Data quality check Check whether movement could be caused by: - missing data - duplicate records - tracking change - delayed refresh - definition change - join issue - incomplete period 5. Business explanation scan Check: - campaign changes - pricing changes - product changes - seasonality - market events - operational changes - customer mix shift 6. Final diagnosis Classify the movement as: - likely real business change - likely data issue - likely mixed cause - expected seasonal movement - needs deeper investigation Rules: - Do not say “metric went up/down” without explaining drivers. - Do not ignore denominator changes. - Do not assume movement is real before checking data quality. - The output must help stakeholders know what changed, why, and what to do next. --------------------------------------------------------------------------------

#126Misleading Dashboard Risk Detector

METRICS, KPIs & PERFORMANCE TRACKINGBI analysts, dashboard owners, data analysts, analytics managers, executives, product teams, finance teams, and reporting QA.

Identify dashboard design, metric, aggregation, filter, date, denominator, and visualization problems that could mislead stakeholders.

Act as a dashboard risk auditor. Review the dashboard or reporting setup below and identify where it may mislead business users. Dashboard context: Dashboard name: [DASHBOARD] Audience: [AUDIENCE] Business decisions supported: [DECISIONS] Metrics shown: [METRICS] Filters available: [FILTERS] Date logic: [DATE LOGIC] Data sources: [DATA SOURCES] Visuals used: [VISUALS] Known complaints: [COMPLAINTS] Refresh cadence: [REFRESH] Screenshots or description: [PASTE DESCRIPTION] Audit for misleading risks: A. Metric risks Check for: - unclear definitions - wrong denominators - mixed grains - unweighted averages - vanity metrics - missing guardrails - stale targets - no owner B. Data risks Check for: - incomplete periods - missing data - duplicate records - delayed refresh - source mismatch - inconsistent filters - hidden exclusions - small sample sizes C. Visualization risks Check for: - misleading axes - too many charts - poor chart choice - unclear labels - color misuse - missing context - lack of baseline - no comparison period D. Interpretation risks Check whether users may: - confuse correlation with causation - overreact to noise - compare unfair segments - ignore seasonality - miss caveats - optimize wrong behavior E. Fix plan For each risk include: - issue - why it matters - affected decision - recommended fix - priority - effort Rules: - Do not focus only on dashboard aesthetics. - Do not assume users understand metric caveats. - Do not hide incomplete data periods. - The audit must make the dashboard safer for business decisions. --------------------------------------------------------------------------------

#127Metric Target and Threshold Setter

METRICS, KPIs & PERFORMANCE TRACKINGPerformance teams, executives, analytics teams, finance teams, operations managers, product teams, growth teams, sales teams, and KPI owners.

Set practical targets, warning thresholds, success thresholds, and escalation rules based on baseline, variability, business goals, and decision needs.

You are a KPI target-setting advisor. Help me set realistic and useful targets and thresholds for [METRIC]. Metric context: Metric name: [METRIC] Business goal: [GOAL] Current baseline: [BASELINE] Historical values: [HISTORICAL VALUES] Business target or ambition: [TARGET] Time horizon: [TIME HORIZON] Owner: [OWNER] Segments: [SEGMENTS] Known seasonality: [SEASONALITY] Known volatility: [VOLATILITY] Business constraints: [CONSTRAINTS] Risk tolerance: [LOW / MEDIUM / HIGH] Build the target system: 1. Baseline review Analyze: - current average - recent trend - normal variation - best historical performance - worst historical performance - seasonal range - segment differences 2. Target recommendation Recommend: - minimum acceptable target - realistic target - stretch target - unacceptable threshold - investigation threshold 3. Threshold logic Create rules for: - green status - yellow status - red status - critical escalation - inconclusive movement - ignore as normal noise 4. Segment-specific targets Recommend whether targets should differ by segment. Explain why or why not. 5. Action rules For each threshold define: - required action - owner - timeline - follow-up metric - escalation path 6. Target caveats List where targets may be misleading or need revision. Rules: - Do not set targets without baseline and variability context. - Do not use one target for all segments if segments operate differently. - Do not treat every small movement as meaningful. - Targets must support action, not just pressure. --------------------------------------------------------------------------------

#128KPI Tree and Driver-Based Reporting Builder

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, executives, business leads, product teams, marketing teams, finance teams, operations teams, revenue teams, and performance reporting systems.

Build a KPI tree that connects top-level performance to driver metrics, diagnostic metrics, owners, and actions.

Act as a KPI tree architect. Build a driver-based performance framework for [BUSINESS OUTCOME]. Business context: Business outcome: [OUTCOME] Company or team: [COMPANY / TEAM] Business model: [BUSINESS MODEL] Current KPIs: [CURRENT KPIS] Key processes: [PROCESSES] Stakeholders: [STAKEHOLDERS] Available data: [DATA] Decision cadence: [CADENCE] Current reporting gaps: [GAPS] Create the KPI tree: A. Top-level outcome Define the top-level KPI and why it matters. B. Driver hierarchy Break it into: - level 1 business drivers - level 2 operational drivers - level 3 input or activity metrics - guardrails - diagnostic metrics C. Driver table For each driver include: - metric name - formula - business meaning - owner - lever to influence it - reporting frequency - source - leading or lagging status - risk of misuse D. Performance narrative Explain how movement in lower-level drivers should explain movement in the top-level KPI. E. Reporting layout Recommend dashboard or report sections: - executive outcome - driver breakdown - segment view - trend view - exceptions - recommended actions F. Governance Define who owns each metric and who approves changes. Rules: - Do not create a disconnected list of KPIs. - Do not include drivers that no one can influence. - Do not ignore guardrails. - The KPI tree must help teams diagnose performance and choose actions. --------------------------------------------------------------------------------

#129Performance Review Meeting Pack

METRICS, KPIs & PERFORMANCE TRACKINGWeekly business reviews, monthly performance reviews, QBRs, team leads, executives, analysts, operations teams, sales teams, marketing teams, and finance teams.

Create a structured performance review pack with KPIs, trends, drivers, variances, risks, actions, owners, and meeting questions.

You are a performance review analyst. Build a meeting-ready performance review pack for [TEAM / BUSINESS AREA]. Review context: Business area: [AREA] Review period: [PERIOD] Audience: [AUDIENCE] Primary KPIs: [KPIS] Targets: [TARGETS] Previous period results: [PREVIOUS RESULTS] Current period results: [CURRENT RESULTS] Known business events: [EVENTS] Key risks: [RISKS] Actions from last review: [LAST ACTIONS] Decision needed: [DECISION] Create the review pack: 1. Executive snapshot Write a short summary of performance this period. 2. KPI scorecard Create a scorecard with: - KPI - target - current value - prior value - variance - status - owner - comment 3. Movement diagnosis For each KPI with major movement include: - what changed - likely driver - segment affected - data caveat - recommended follow-up 4. Action review Review prior actions: - action - owner - due date - status - result - next step 5. Risk and opportunity section Identify: - biggest risk - biggest opportunity - metric to watch - decision required 6. Meeting agenda Create a 45-minute agenda with discussion questions and decision points. 7. Follow-up tracker Create action items with owners and deadlines. Rules: - Do not make the meeting pack a chart dump. - Do not discuss every metric equally. - Do not omit owners and next actions. - The pack must help the team make decisions and follow through. --------------------------------------------------------------------------------

#130Metric Alert and Escalation System

METRICS, KPIs & PERFORMANCE TRACKINGBI teams, data analysts, operations teams, growth teams, product teams, support teams, finance teams, dashboard owners, and monitoring workflows.

Design a metric alert system with thresholds, severity levels, owners, investigation steps, escalation rules, and false-positive control.

Act as a metric monitoring and alerting designer. Build an alert system for [METRIC / DASHBOARD / BUSINESS PROCESS]. Monitoring context: Metric or dashboard: [METRIC / DASHBOARD] Business process: [PROCESS] Owner: [OWNER] Normal range: [NORMAL RANGE] Historical volatility: [VOLATILITY] Refresh frequency: [REFRESH] Business impact of issue: [IMPACT] Segments to monitor: [SEGMENTS] Known seasonality: [SEASONALITY] Preferred alert channel: [EMAIL / SLACK / TEAMS / DASHBOARD] False-positive concerns: [CONCERNS] Design the alert system: A. Alert objective Define what the alert should detect and what it should ignore. B. Alert rules Create rules for: - absolute threshold - percentage change - rolling average deviation - period-over-period drop - missing data - stale data - segment-specific spike - guardrail breach C. Severity levels Define: - informational - warning - high priority - critical For each include: - trigger - owner - response time - required action - escalation path D. Investigation playbook For each alert type include: - first check - data quality check - related metrics to inspect - stakeholder to contact - possible business causes - resolution note E. False-positive control Recommend ways to reduce noise: - minimum volume threshold - rolling window - segment size rule - seasonality adjustment - confirmation check - suppression rule Rules: - Do not alert on every small movement. - Do not create alerts without owners. - Do not ignore data freshness alerts. - Alerts must trigger useful investigation, not panic. --------------------------------------------------------------------------------

#131Performance Metric Segmentation Strategy

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, product analysts, marketing analysts, finance teams, revenue teams, operations analysts, BI teams, and strategic reporting.

Decide which segments should be used to understand KPI performance and how to avoid misleading segment comparisons.

You are a metric segmentation strategist. Build a segmentation plan for analyzing [KPI / METRIC]. Metric context: Metric: [METRIC] Business goal: [GOAL] Available segment fields: [SEGMENT FIELDS] Business question: [QUESTION] Time period: [TIME PERIOD] Current dashboard segments: [CURRENT SEGMENTS] Stakeholder assumptions: [ASSUMPTIONS] Minimum segment size: [MINIMUM SIZE] Known data issues: [DATA ISSUES] Create the segmentation strategy: 1. Segment candidate review Evaluate possible segments such as: - customer type - product - geography - channel - plan - cohort - lifecycle stage - sales owner - campaign - device - location - behavior level For each segment include: - business relevance - data quality - expected actionability - sample size risk - owner - recommendation 2. Segment comparison rules Define: - minimum size - comparison period - fair baseline - peer group logic - outlier handling - when to suppress or combine categories 3. Segment performance table Design output columns: - segment - volume - KPI value - target - variance - contribution to total - trend - status - action owner 4. Misleading comparison warnings Identify risks such as: - small sample sizes - mix effects - seasonality - different maturity levels - data quality gaps - overlapping segments 5. Final recommendation Choose the best segment views for dashboard and deep analysis. Rules: - Do not segment just because a field exists. - Do not compare tiny segments with large segments without caveats. - Do not ignore whether a team can act on a segment. - Segmentation must help explain performance and guide action. --------------------------------------------------------------------------------

#132Metric Governance and Change Control System

METRICS, KPIs & PERFORMANCE TRACKINGData teams, analytics leaders, BI managers, executives, RevOps, finance, product, operations, and organizations with conflicting KPI definitions.

Create governance rules for adding, changing, approving, retiring, and communicating metric definitions across teams.

Act as a metric governance lead. Create a governance system for managing metric definitions and reporting changes. Governance context: Organization or team: [ORGANIZATION / TEAM] Metrics affected: [METRICS] Current definition problems: [PROBLEMS] Teams using metrics: [TEAMS] Dashboard or reports affected: [REPORTS] Data owners: [OWNERS] Decision owners: [DECISION OWNERS] Current approval process: [PROCESS] Reporting risk: [RISK] Build the governance system: A. Metric ownership model Define roles: - metric business owner - technical owner - data steward - dashboard owner - approval group - end-user group B. Change request process Create steps for: - request submitted - business reason documented - impact assessed - formula reviewed - data validated - stakeholders approved - dashboard updated - users notified - old definition archived C. Metric lifecycle Define stages: - proposed - draft - approved - active - under review - deprecated - retired D. Impact assessment Create a checklist for changes affecting: - dashboards - historical reporting - targets - incentives - automated alerts - executive reports - downstream analyses E. Communication template Write a metric change announcement with: - what changed - why it changed - when it takes effect - reports affected - how historical values are handled - who to contact Rules: - Do not allow silent changes to executive KPIs. - Do not let technical teams change business definitions alone. - Do not keep deprecated metrics active without warning. - Governance should protect trust and consistency. --------------------------------------------------------------------------------

#133Metric Quality and Trust Audit

METRICS, KPIs & PERFORMANCE TRACKINGAnalytics teams, BI managers, executives, finance teams, product teams, consultants, dashboard owners, and metric governance teams.

Audit whether a KPI or metric is accurate, stable, trusted, actionable, consistently defined, and safe for decision-making.

You are a metric trust auditor. Evaluate whether [METRIC] is reliable enough for business decisions. Metric context: Metric name: [METRIC] Business use: [USE CASE] Decision supported: [DECISION] Current formula: [FORMULA] Data sources: [SOURCES] Dashboard or report: [REPORT] Stakeholders: [STAKEHOLDERS] Known complaints: [COMPLAINTS] Known discrepancies: [DISCREPANCIES] Historical usage: [USAGE] Risk level: [LOW / MEDIUM / HIGH] Audit metric trust: 1. Definition audit Check: - clarity - formula precision - numerator - denominator - filters - exclusions - ownership - interpretation 2. Data audit Check: - source reliability - data freshness - completeness - duplicates - missing values - join logic - historical consistency - source-of-truth alignment 3. Business audit Check whether the metric is: - actionable - decision-connected - aligned to goals - not easily gamed - not misleading alone - paired with guardrails 4. Stakeholder trust audit Identify: - who trusts it - who disputes it - why disagreement exists - what evidence would resolve it 5. Trust score Score the metric from 1 to 10 across: - definition clarity - data reliability - business usefulness - stability - actionability - governance 6. Fix plan Create a prioritized improvement plan. Rules: - Do not declare a metric trustworthy because it is widely used. - Do not ignore stakeholder disagreement. - Do not rely on a metric without source reconciliation. - The audit must decide whether the metric is safe for business use. --------------------------------------------------------------------------------

#134KPI Dashboard Requirements Builder

METRICS, KPIs & PERFORMANCE TRACKINGBI analysts, dashboard builders, analytics managers, executives, product teams, finance teams, sales teams, marketing teams, and operations teams.

Define KPI dashboard requirements including metrics, filters, views, definitions, drilldowns, owners, refresh cadence, alerts, and caveats.

Act as a KPI dashboard requirements specialist. Build requirements for a dashboard that tracks [BUSINESS AREA / GOAL]. Dashboard context: Business area: [AREA] Dashboard audience: [AUDIENCE] Primary decisions: [DECISIONS] KPIs needed: [KPIS] Current reports: [REPORTS] Pain points: [PAIN POINTS] Required filters: [FILTERS] Required drilldowns: [DRILLDOWNS] Refresh cadence: [REFRESH] Data sources: [SOURCES] Success criteria: [SUCCESS CRITERIA] Create dashboard requirements: A. Dashboard purpose Define: - why the dashboard exists - who uses it - when they use it - what decisions it supports - what actions should result B. KPI specification For each KPI include: - name - definition - formula - owner - target - status logic - refresh cadence - source - caveat C. View structure Design sections: - executive summary - KPI scorecard - trends - driver metrics - segment breakdown - exceptions - action log - definitions D. Filters and drilldowns Define: - filter name - field source - allowed values - default setting - risk of misuse - required drilldown path E. Alert and threshold rules Create status rules for each KPI. F. Acceptance criteria Define what must be true before the dashboard is approved. Rules: - Do not include metrics that do not support decisions. - Do not build a dashboard without metric definitions. - Do not hide caveats in separate documentation only. - Requirements must prevent dashboard rework and misuse. --------------------------------------------------------------------------------

#135Performance Scorecard Designer

METRICS, KPIs & PERFORMANCE TRACKINGExecutives, department leads, analysts, operations managers, sales leaders, marketing teams, product teams, finance teams, and performance management.

Build a balanced scorecard that tracks outcomes, drivers, guardrails, targets, status, owners, and follow-up actions.

You are a performance scorecard designer. Create a scorecard for [TEAM / BUSINESS UNIT / INITIATIVE]. Scorecard context: Team or unit: [TEAM / UNIT] Business objectives: [OBJECTIVES] Stakeholders: [STAKEHOLDERS] Reporting period: [PERIOD] Current KPIs: [KPIS] Targets: [TARGETS] Available data: [DATA] Decision cadence: [CADENCE] Current reporting issues: [ISSUES] Build the scorecard: 1. Scorecard dimensions Choose 4 to 6 dimensions such as: - growth - revenue - cost - efficiency - quality - customer experience - retention - risk - people - operations 2. Metric selection For each dimension include: - outcome KPI - driver metric - guardrail metric - owner - target - current value - status logic 3. Status system Define: - green - yellow - red - gray or insufficient data - critical escalation 4. Scorecard layout Create the table structure with: - metric - definition - target - current - prior - variance - trend - status - owner - action needed 5. Review questions Create questions leaders should ask when reviewing the scorecard. 6. Follow-up mechanism Design a system for action items and accountability. Rules: - Do not overload the scorecard with too many metrics. - Do not mix unrelated metrics without structure. - Do not use targets without clear status logic. - The scorecard should make performance review faster and more actionable. --------------------------------------------------------------------------------

#136KPI Narrative and Executive Summary Writer

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, BI analysts, finance analysts, executives, managers, consultants, and anyone writing performance summaries.

Convert KPI results into a clear executive narrative explaining performance, movement, drivers, risks, and recommended action.

Act as an executive KPI narrative writer. Turn the performance results below into a concise business summary. Performance context: Audience: [AUDIENCE] Reporting period: [PERIOD] Business area: [AREA] KPI results: [RESULTS] Targets: [TARGETS] Previous period: [PREVIOUS PERIOD] Major changes: [CHANGES] Known drivers: [DRIVERS] Known caveats: [CAVEATS] Decisions needed: [DECISIONS] Tone: [DIRECT / FORMAL / EXECUTIVE / ACTION-ORIENTED] Write the narrative: A. Headline Create one clear headline summarizing performance. B. Executive summary Write 5 to 7 sentences covering: - overall performance - KPIs above target - KPIs below target - biggest movement - likely drivers - key risk - recommended action C. KPI-by-KPI notes For each KPI write: - current result - comparison to target - comparison to prior period - interpretation - caveat - next action D. Risk and opportunity section Identify: - biggest performance risk - biggest upside opportunity - metric to monitor next - owner E. Action summary Create a table with: - action - owner - due date - expected impact - KPI affected Rules: - Do not just describe numbers; interpret them. - Do not overstate causality. - Do not hide caveats. - The narrative must help executives understand what happened and what to do next. --------------------------------------------------------------------------------

#137Metric Movement Root Cause Tree

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, operations teams, growth teams, product analysts, finance teams, business reviewers, and problem-solving workshops.

Build a structured root cause tree for explaining why a KPI changed and what analysis is needed to confirm each possible cause.

You are a KPI root cause analyst. Build a root cause tree for the metric movement below. Metric movement context: KPI: [KPI] Movement: [MOVEMENT] Time period: [TIME PERIOD] Business area: [AREA] Affected segments: [SEGMENTS] Known events: [EVENTS] Current theories: [THEORIES] Available data: [DATA] Decision needed: [DECISION] Create the root cause tree: 1. Top event State the KPI movement as a measurable problem or opportunity. 2. Cause categories Build cause branches across: - volume change - rate change - mix shift - pricing or cost change - customer behavior - product or service change - operational process - channel performance - seasonality - external factor - data quality issue - metric definition change 3. Hypotheses under each branch For each hypothesis include: - possible cause - business logic - evidence needed - analysis method - data source - expected pattern if true - action if confirmed 4. Prioritization Rank causes by: - likelihood - business impact - ease of validation - actionability - urgency 5. Investigation roadmap Create the analysis order and expected outputs. Rules: - Do not jump to one cause too early. - Do not ignore data quality as a possible cause. - Do not list causes that cannot be tested or acted on. - The root cause tree must guide efficient investigation. --------------------------------------------------------------------------------

#138KPI Noise vs Signal Interpreter

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, executives, dashboard users, product teams, growth teams, finance teams, operations teams, and anyone avoiding overreaction to normal metric movement.

Determine whether metric changes are meaningful signals or normal variation by using baselines, volatility, sample size, thresholds, and business context.

Act as a KPI signal-vs-noise analyst. Help me decide whether the metric movement below is meaningful or just normal variation. Metric context: Metric: [METRIC] Current value: [CURRENT VALUE] Previous value: [PREVIOUS VALUE] Historical values: [HISTORICAL VALUES] Sample size: [SAMPLE SIZE] Normal range: [NORMAL RANGE] Reporting frequency: [FREQUENCY] Business context: [CONTEXT] Known events: [EVENTS] Decision at stake: [DECISION] Risk tolerance: [RISK TOLERANCE] Evaluate signal vs noise: A. Movement summary Calculate or describe: - absolute change - percentage change - historical percentile - distance from normal range - sample size adequacy - persistence of movement B. Signal criteria Evaluate whether movement is: - large enough - sustained enough - broad enough - segment-specific - outside normal variation - aligned with related metrics - connected to a known event C. Noise indicators Check for: - small sample - short time window - random fluctuation - incomplete data - holiday or calendar effect - data refresh delay - outlier impact - metric volatility D. Decision guidance Classify the movement as: - act now - investigate - monitor - ignore as normal variation - wait for more data - data quality check required E. Stakeholder explanation Write a plain-language explanation of whether to react and why. Rules: - Do not overreact to one data point. - Do not ignore sustained movement. - Do not treat statistical variation as business failure. - The output should help teams respond proportionally. --------------------------------------------------------------------------------

#139Metric-to-Action Playbook Builder

METRICS, KPIs & PERFORMANCE TRACKINGPerformance teams, operations teams, product teams, marketing teams, sales teams, support teams, managers, dashboard owners, and business review processes.

Create a playbook that defines what teams should do when KPIs improve, decline, miss targets, exceed targets, or show unusual patterns.

You are a KPI action playbook designer. Create a practical playbook for responding to changes in [METRIC / KPI SET]. Playbook context: Metric or KPI set: [METRICS] Business area: [AREA] Metric owners: [OWNERS] Current targets: [TARGETS] Available levers: [LEVERS] Review cadence: [CADENCE] Common metric movements: [MOVEMENTS] Decision authority: [AUTHORITY] Team constraints: [CONSTRAINTS] Build the playbook: A. Movement scenarios Create response plans for: - KPI above target - KPI slightly below target - KPI sharply below target - sudden spike - sudden drop - sustained decline - sustained improvement - high volatility - data missing - guardrail breach B. Scenario table For each scenario include: - trigger condition - first question to ask - data check - business check - owner - recommended action - escalation rule - follow-up metric - timeline C. Levers map Connect each metric to possible business levers. Examples: - pricing - staffing - product change - marketing spend - process improvement - customer support - quality control - training - inventory - sales follow-up D. Communication templates Write short messages for: - warning alert - investigation request - action assignment - executive update - resolved issue E. Learning loop Create a process for updating the playbook after each review cycle. Rules: - Do not create metrics without actions. - Do not make every movement an emergency. - Do not ignore guardrails when primary KPI improves. - The playbook must connect performance tracking to real operating behavior. --------------------------------------------------------------------------------

#140Full Metrics, KPIs and Performance Tracking Audit

METRICS, KPIs & PERFORMANCE TRACKINGData analysts, analytics leaders, BI teams, executives, finance teams, product teams, marketing teams, operations teams, growth teams, and business performance owners.

Audit and rebuild a company’s metric system across KPI definitions, dictionaries, dashboards, targets, movement diagnosis, guardrails, governance, reporting, and action tracking.

Act as an independent metrics, KPIs, and performance tracking auditor. Review my current metric system and rebuild it into a clear, trusted, action-oriented performance tracking framework. Full context: Company or team: [COMPANY / TEAM] Business model: [BUSINESS MODEL] Business goals: [GOALS] Current KPIs: [CURRENT KPIS] Current dashboards or reports: [DASHBOARDS / REPORTS] Metric definitions: [DEFINITIONS] Targets: [TARGETS] Stakeholders: [STAKEHOLDERS] Metric owners: [OWNERS] Data sources: [DATA SOURCES] Reporting cadence: [CADENCE] Performance review process: [PROCESS] Known metric conflicts: [CONFLICTS] Known dashboard issues: [ISSUES] Known data quality concerns: [DATA QUALITY] Decision needs: [DECISIONS] Current pain points: [PAIN POINTS] Audit across 60 dimensions: 1. Business goal alignment 2. Decision connection 3. KPI selection quality 4. Primary KPI clarity 5. Secondary metric clarity 6. Diagnostic metric coverage 7. Guardrail metric coverage 8. Leading indicator quality 9. Lagging indicator quality 10. Input metric relevance 11. Output metric relevance 12. Metric dictionary completeness 13. Formula clarity 14. Numerator definition 15. Denominator definition 16. Filter logic 17. Exclusion logic 18. Grain definition 19. Data source clarity 20. Source of truth alignment 21. Data freshness 22. Data quality trust 23. Metric ownership 24. Dashboard ownership 25. Target logic 26. Threshold logic 27. Baseline quality 28. Historical context 29. Seasonality awareness 30. Segment strategy 31. Segment size control 32. KPI tree structure 33. Driver metric mapping 34. Movement diagnosis process 35. Root cause analysis process 36. Signal vs noise handling 37. Alert rules 38. Escalation rules 39. Performance review cadence 40. Meeting pack quality 41. Action tracking 42. Follow-up accountability 43. Dashboard clarity 44. Dashboard misleading risk 45. Chart and visualization fit 46. Definitions visible in reports 47. Caveats visible in reports 48. Executive summary quality 49. Stakeholder trust 50. Metric governance 51. Metric change control 52. Deprecated metric handling 53. Incentive risk 54. Gaming risk 55. Vanity metric risk 56. Over-reporting risk 57. Under-reporting risk 58. Maintenance burden 59. Business actionability 60. Overall performance tracking maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - business risk if ignored - reporting risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current metric system may fail to drive better decisions or performance. B. Rebuilt performance tracking framework Create: - KPI hierarchy - KPI tree - metric dictionary structure - leading and lagging indicator map - guardrail framework - target and threshold logic - dashboard requirements - performance review cadence - action tracking system - metric governance process C. First 10 metric system fixes Rank the first 10 improvements. For each include: - issue - fix - why it matters - owner - expected output - risk reduced - effort D. Reporting redesign Recommend: - executive scorecard - team dashboard - driver analysis view - exception report - action log - metric dictionary page E. Metric governance pack Create templates for: - new metric request - metric definition card - metric change request - metric retirement note - dashboard caveat - KPI review agenda F. Executive summary Write a direct summary with: - strongest KPI - weakest KPI - biggest definition risk - biggest dashboard risk - biggest target risk - first guardrail to add - one operating principle for performance tracking Rules: - Do not recommend more dashboards before fixing metric definitions. - Do not optimize KPIs without guardrails. - Do not ignore ownership and action follow-up. - Use [NEEDS METRIC OWNER], [NEEDS DATA QUALITY CHECK], [NEEDS BUSINESS DEFINITION], [NEEDS DASHBOARD QA], [NEEDS TARGET REVIEW], or [NEEDS GOVERNANCE REVIEW] where required. - The final system should make metrics clear, trusted, actionable, and aligned with business goals.

#141Dashboard Purpose and Stakeholder Use Case Designer

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI analysts, data analysts, dashboard builders, product teams, finance teams, operations teams, executives, founders, and anyone creating dashboards that must drive action.

Define the real purpose of a dashboard before building visuals, including users, decisions, actions, metrics, cadence, and success criteria.

You are a dashboard strategy consultant. Help me design a dashboard that is useful for real stakeholder decisions, not just a collection of charts. Dashboard context: Dashboard name or idea: [DASHBOARD NAME] Business area: [BUSINESS AREA] Primary users: [USERS] User roles: [ROLES] Business goal: [GOAL] Decisions supported: [DECISIONS] Current reporting pain: [PAIN] Existing dashboards or reports: [EXISTING REPORTS] Data sources: [DATA SOURCES] Refresh cadence: [REFRESH CADENCE] Required filters: [FILTERS] Expected action after viewing: [ACTION] Tool: [POWER BI / TABLEAU / LOOKER / EXCEL / GOOGLE SHEETS / OTHER] Create the dashboard strategy: 1. Dashboard purpose Define: - why the dashboard should exist - who uses it - when they use it - what decision it supports - what action should happen after viewing it - what it should not be used for 2. User stories Create 10 user stories in this format: As a [role], I need to know [metric / pattern / exception] so I can [business action]. 3. Decision map For each decision include: - decision owner - frequency of decision - metric needed - view needed - threshold or trigger - action if metric is good - action if metric is bad 4. Dashboard scope Define: - must-have sections - nice-to-have sections - out-of-scope items - future version ideas - risks of overloading the dashboard 5. Success criteria Define how we will know the dashboard is useful after launch. Include: - usage signal - decision signal - time saved - stakeholder satisfaction - action follow-through - reporting reduction Rules: - Do not build a dashboard because data exists. - Do not include metrics without decisions or owners. - Do not optimize for visual beauty before utility. - The final dashboard strategy must make the dashboard purposeful, focused, and action-oriented. --------------------------------------------------------------------------------

#142Executive Dashboard Layout Architect

DASHBOARDS, DATA VISUALIZATION & REPORTINGExecutives, founders, analytics leaders, BI teams, finance teams, business review dashboards, board reporting, and leadership performance tracking.

Design an executive dashboard layout that highlights top KPIs, movement, risks, opportunities, drivers, and next actions in a concise leadership-friendly format.

Act as an executive dashboard architect. Design a dashboard layout that helps leadership understand performance quickly and make decisions. Executive context: Company or business unit: [COMPANY / UNIT] Executive audience: [AUDIENCE] Main business goals: [GOALS] Top KPIs: [KPIS] Decision cadence: [DAILY / WEEKLY / MONTHLY / QUARTERLY] Comparison period: [COMPARISON PERIOD] Targets: [TARGETS] Key business drivers: [DRIVERS] Known risks: [RISKS] Data refresh cadence: [REFRESH] Dashboard tool: [TOOL] Design the executive dashboard: A. Dashboard hierarchy Create the dashboard in this order: 1. Executive summary strip 2. KPI scorecards 3. Trend section 4. Driver breakdown 5. Segment or business unit comparison 6. Risks and exceptions 7. Action tracker 8. Definitions and caveats B. KPI card design For each KPI card include: - KPI name - current value - target - variance - previous period - trend indicator - status - owner - one-line interpretation C. Visual plan Recommend chart types for: - KPI trend - variance to target - driver contribution - segment comparison - exception list - forecast or projection, if relevant D. Executive notes Write short dashboard copy for: - what changed - why it matters - what needs attention - what action is recommended E. Interaction design Define: - filters executives actually need - drilldowns they should have - filters to avoid - default view F. Risk controls Add visible warnings for: - stale data - incomplete period - missing target - low sample size - metric definition caveat Rules: - Do not make executives hunt for the main message. - Do not include operational detail that belongs in a lower-level dashboard. - Do not hide caveats that affect decisions. - The dashboard must communicate performance in under 60 seconds. --------------------------------------------------------------------------------

#143Chart Selection Decision Tree

DASHBOARDS, DATA VISUALIZATION & REPORTINGData analysts, dashboard builders, BI developers, reporting teams, consultants, students, and anyone deciding how to visualize data.

Choose the right chart type based on the analytical question, metric type, comparison, trend, distribution, relationship, ranking, part-to-whole, or geography.

You are a data visualization advisor. Help me choose the best chart types for the data and questions below. Visualization context: Audience: [AUDIENCE] Business question: [QUESTION] Metric or values: [METRICS] Dimensions: [DIMENSIONS] Time field: [TIME FIELD] Comparison needed: [COMPARISON] Number of categories: [CATEGORY COUNT] Need to show change over time: [YES / NO] Need to show distribution: [YES / NO] Need to show relationship: [YES / NO] Need to show ranking: [YES / NO] Need to show geography: [YES / NO] Tool: [POWER BI / TABLEAU / LOOKER / EXCEL / OTHER] Choose the visualization: 1. Question diagnosis Classify each visual need as: - trend over time - comparison across categories - part-to-whole - ranking - distribution - relationship - composition over time - flow or funnel - geography - variance to target - anomaly or exception 2. Chart recommendation table For each question include: - best chart type - second-best option - chart to avoid - why this chart fits - required fields - aggregation level - sorting rule - labeling rule - risk of misreading 3. Design rules Provide guidance for: - axes - labels - legends - color use - scale - sorting - grouping small categories - handling nulls - showing targets - showing comparisons 4. Final visual set Recommend a clean set of charts for the dashboard or report. 5. Anti-pattern warnings List chart choices that would mislead the audience. Rules: - Do not recommend pie charts for too many categories. - Do not use dual axes unless there is a strong reason and clear labeling. - Do not use complex charts if a bar or line chart answers the question. - Chart choice must serve interpretation, not decoration. --------------------------------------------------------------------------------

#144Dashboard Wireframe and BI View Planner

DASHBOARDS, DATA VISUALIZATION & REPORTINGPower BI, Tableau, Looker, Mode, Metabase, Excel dashboards, Google Sheets dashboards, BI teams, and product/reporting designers.

Convert dashboard requirements into a BI-ready wireframe with pages, sections, filters, visuals, tables, drilldowns, and user flow.

Act as a BI dashboard wireframe designer. Turn the requirements below into a clear dashboard wireframe and view structure. Dashboard requirements: Dashboard title: [TITLE] Audience: [AUDIENCE] Business goal: [GOAL] Decisions supported: [DECISIONS] KPIs: [KPIS] Metrics: [METRICS] Dimensions: [DIMENSIONS] Filters: [FILTERS] Drilldowns: [DRILLDOWNS] Data refresh: [REFRESH] Tool: [BI TOOL] Known constraints: [CONSTRAINTS] Must include: [MUST INCLUDE] Must avoid: [MUST AVOID] Create the wireframe: A. Dashboard pages Recommend pages such as: - executive overview - trend analysis - segment analysis - driver analysis - exception list - operational detail - definitions and notes For each page include: - purpose - target user - decision supported - visuals included - filters - drilldowns - caveats B. Page layout For each page describe: - top section - left section - main section - right section - bottom section - visual priority - reading order C. Visual specification For every visual include: - visual name - chart type - metric - dimension - date grain - filter behavior - tooltip fields - interaction behavior - interpretation note D. Navigation Design: - page tabs - drill-through path - back buttons - bookmarks, if relevant - default filters E. Build checklist Create the BI build checklist for the developer. Rules: - Do not place important insights below low-value details. - Do not create too many pages if one focused page works. - Do not add interactions that confuse users. - The wireframe must be detailed enough for a BI developer to build. --------------------------------------------------------------------------------

#145Visual Clarity and Dashboard Cleanup Auditor

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI analysts, dashboard owners, data analysts, managers, consultants, product teams, finance dashboards, executive reports, and reporting QA.

Audit a dashboard or report for visual clutter, unclear labels, bad chart choices, poor hierarchy, confusing filters, and weak stakeholder readability.

You are a dashboard clarity auditor. Review the dashboard or report description below and recommend improvements that make it easier to understand. Dashboard or report description: [PASTE DESCRIPTION / SCREENSHOT NOTES / VISUAL LIST] Context: Audience: [AUDIENCE] Business purpose: [PURPOSE] Tool: [TOOL] Metrics shown: [METRICS] Decisions supported: [DECISIONS] Known user complaints: [COMPLAINTS] Constraints: [CONSTRAINTS] Desired tone: [EXECUTIVE / OPERATIONAL / ANALYTICAL / SIMPLE] Audit visual clarity: 1. Layout clarity Check: - visual hierarchy - reading flow - wasted space - too many visuals - important metrics hidden - inconsistent sectioning - unclear page purpose 2. Chart clarity Check: - chart type fit - axis labels - number formatting - sorting - legends - titles - comparisons - annotations - target lines - outlier visibility 3. Filter and interaction clarity Check: - default filters - filter overload - confusing slicers - hidden filter effects - drilldown confusion - missing reset option 4. Text and labeling clarity Check: - chart titles - KPI names - definitions - caveats - insight notes - tooltip usefulness 5. Cleanup plan Create a table with: - issue - why it matters - recommended fix - priority - effort - expected user benefit 6. Rebuilt layout Describe the improved dashboard structure. Rules: - Do not focus only on making the dashboard prettier. - Do not remove useful context just to simplify. - Do not assume users understand every metric. - The cleanup must improve comprehension and decision-making. --------------------------------------------------------------------------------

#146Reporting Narrative and Insight Story Builder

DASHBOARDS, DATA VISUALIZATION & REPORTINGData analysts, BI analysts, consultants, finance teams, executives, business review decks, reporting emails, and stakeholder updates.

Turn dashboard data, charts, or analysis results into a clear narrative with context, movement, drivers, implications, caveats, and next steps.

Act as a data reporting narrative strategist. Turn the findings below into a clear business story that stakeholders can understand and act on. Input findings: [PASTE FINDINGS / KPI RESULTS / CHART NOTES / DASHBOARD OBSERVATIONS] Reporting context: Audience: [AUDIENCE] Business question: [QUESTION] Reporting period: [PERIOD] Primary metrics: [METRICS] Targets or benchmarks: [TARGETS] Known drivers: [DRIVERS] Known caveats: [CAVEATS] Decision needed: [DECISION] Tone: [DIRECT / EXECUTIVE / FORMAL / PLAIN LANGUAGE] Output format: [EMAIL / SLIDE NOTES / MEMO / DASHBOARD COMMENTARY] Build the narrative: A. One-line headline Write a concise headline that summarizes the main message. B. Situation Explain the business context and why this report matters. C. What changed Summarize the key movement in metrics. D. Why it likely changed Explain the likely drivers and supporting evidence. E. What it means Translate findings into business implications. F. What to do next Recommend next steps: - decision - investigation - action - monitoring - data validation G. Caveats State limitations clearly without weakening useful conclusions. H. Final version Write the final stakeholder-ready narrative. Rules: - Do not list numbers without interpretation. - Do not overclaim causality. - Do not bury the main message. - The narrative must explain what happened, why it matters, and what should happen next. --------------------------------------------------------------------------------

#147Executive Report One-Pager Generator

DASHBOARDS, DATA VISUALIZATION & REPORTINGExecutives, founders, finance teams, BI analysts, monthly reports, board updates, QBRs, business reviews, and leadership reporting.

Create a concise executive one-page report with KPI summary, key movements, drivers, risks, decisions, and recommended actions.

You are an executive reporting specialist. Create a one-page report for leadership based on the performance context below. Report context: Business area: [AREA] Reporting period: [PERIOD] Audience: [AUDIENCE] Top KPIs: [KPIS] Current results: [RESULTS] Targets: [TARGETS] Prior period results: [PRIOR RESULTS] Main drivers: [DRIVERS] Risks: [RISKS] Opportunities: [OPPORTUNITIES] Decisions needed: [DECISIONS] Data caveats: [CAVEATS] Create the one-pager: 1. Executive headline Write one clear headline that captures the overall performance story. 2. KPI snapshot Create a compact table with: - KPI - current value - target - prior period - variance - status - owner 3. Key takeaways Write 3 to 5 takeaways. Each takeaway must include: - finding - business meaning - evidence - action or implication 4. Risks and opportunities Create two short sections: - risks to monitor - opportunities to act on 5. Decision section List decisions leadership needs to make. For each include: - decision - recommendation - supporting metric - confidence level - deadline 6. Next actions Create an action table with owner and due date. Rules: - Do not make the report longer than one page. - Do not include low-level operational detail unless it affects leadership decisions. - Do not hide caveats that affect interpretation. - The report must be fast to read and useful for decision-making. --------------------------------------------------------------------------------

#148Dashboard Tooltip and Annotation Writer

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI dashboards, executive dashboards, Power BI, Tableau, Looker, self-serve analytics, product dashboards, finance reports, and metric education.

Create useful dashboard tooltips, annotations, metric explanations, caveats, and user guidance that help stakeholders interpret visuals correctly.

Act as a dashboard interpretation copywriter. Write tooltips, annotations, and guidance text for the dashboard visuals below. Dashboard context: Dashboard name: [DASHBOARD] Audience: [AUDIENCE] Metrics: [METRICS] Visuals: [VISUALS] Business purpose: [PURPOSE] Known caveats: [CAVEATS] Metric definitions: [DEFINITIONS] User skill level: [BEGINNER / INTERMEDIATE / ADVANCED] Tone: [SHORT / EXECUTIVE / INSTRUCTIONAL / FRIENDLY] Create interpretation text: A. Metric tooltips For each metric write: - plain-language definition - formula summary - when to use it - what it does not show - caveat - owner or source B. Chart annotations Write annotations for: - spikes - drops - target misses - target beats - outliers - incomplete periods - system changes - known business events C. Filter guidance Write short guidance explaining: - what each filter changes - default filter logic - dangerous filter combinations - how to reset view D. Dashboard notes Create: - top-page instruction - refresh timestamp wording - data limitation note - definitions link text - caveat footer E. Microcopy rules Create rules for writing future dashboard notes. Rules: - Do not write long tooltips that users will ignore. - Do not hide important caveats only in documentation. - Do not use technical jargon where plain language works. - Tooltip text should reduce misinterpretation. --------------------------------------------------------------------------------

#149BI View Structure and Drilldown Path Designer

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI developers, data analysts, product teams, finance teams, operations teams, sales teams, Power BI/Tableau/Looker users, and self-service analytics teams.

Design dashboard drilldowns, detail tables, filters, hierarchies, and navigation paths so users can move from overview to root cause.

You are a BI information architecture specialist. Design the view structure and drilldown paths for the dashboard below. BI context: Dashboard purpose: [PURPOSE] Primary audience: [AUDIENCE] Top-level KPIs: [KPIS] Business dimensions: [DIMENSIONS] Available hierarchy fields: [HIERARCHIES] Common user questions: [QUESTIONS] Detail-level data available: [DETAIL DATA] Tool: [POWER BI / TABLEAU / LOOKER / OTHER] Security constraints: [SECURITY] Performance constraints: [PERFORMANCE] Design the BI navigation: 1. Overview-to-detail flow Create a path from: - executive overview - KPI detail - driver breakdown - segment view - record-level detail - action list 2. Drilldown hierarchy Define hierarchies such as: - company → region → location - category → product → SKU - channel → campaign → ad group - team → owner → account - month → week → day For each hierarchy include: - business use - field names - default level - drilldown rule - caveat 3. Detail pages Design detail pages for: - KPI detail - segment detail - exception detail - customer or record detail - trend detail 4. Filter behavior Define: - global filters - page filters - visual filters - drill-through filters - filters that should not interact 5. User safety Add rules to prevent misleading drilldowns or privacy issues. Rules: - Do not give record-level drilldown if users should only see aggregates. - Do not create drilldowns without a clear question. - Do not make users click through too many layers to find the answer. - The view structure should help users move from what happened to why it happened. --------------------------------------------------------------------------------

#150Report Refresh and Distribution Workflow Builder

DASHBOARDS, DATA VISUALIZATION & REPORTINGReporting analysts, BI teams, finance teams, operations teams, weekly reports, monthly reports, executive updates, and recurring stakeholder communications.

Create a reliable reporting workflow for refreshing data, validating metrics, generating outputs, distributing reports, and collecting feedback.

Act as a reporting operations designer. Build a repeatable workflow for refreshing and distributing [REPORT / DASHBOARD]. Reporting context: Report name: [REPORT] Audience: [AUDIENCE] Reporting cadence: [CADENCE] Data sources: [SOURCES] Refresh method: [MANUAL / AUTOMATED / MIXED] Validation checks: [CHECKS] Distribution channel: [EMAIL / SLACK / BI PORTAL / PDF / PRESENTATION] Owner: [OWNER] Backup owner: [BACKUP OWNER] Known issues: [ISSUES] Deadline: [DEADLINE] Create the workflow: A. Refresh process List steps for: - source data update - data pipeline refresh - manual file import - transformation update - dashboard refresh - cache refresh, if relevant B. Validation process Create checks for: - row counts - date coverage - KPI totals - missing data - refresh timestamp - filter defaults - visual errors - broken links - prior period comparison C. Distribution process Define: - who receives it - when it is sent - format - access link - message text - caveats - escalation contact D. Failure handling Create a plan for: - late data - failed refresh - wrong KPI - missing source - broken dashboard - urgent correction E. Feedback loop Create a process to collect report improvement requests without creating chaos. Rules: - Do not distribute reports before validation. - Do not rely on one person without a backup process. - Do not send reports without caveats when data is incomplete. - The workflow must make reporting repeatable and trustworthy. --------------------------------------------------------------------------------

#151Insight Highlighting and Exception Reporting System

DASHBOARDS, DATA VISUALIZATION & REPORTINGExecutive reports, operational dashboards, BI alerts, weekly reviews, finance reporting, sales dashboards, product analytics, and management reporting.

Design reports that highlight important changes, exceptions, risks, outliers, and action areas instead of forcing stakeholders to scan everything.

You are an insight highlighting specialist. Design a reporting system that automatically surfaces what stakeholders should pay attention to. Report context: Business area: [AREA] Audience: [AUDIENCE] Metrics: [METRICS] Dimensions: [DIMENSIONS] Targets or thresholds: [TARGETS] Historical baseline: [BASELINE] Reporting cadence: [CADENCE] Known business risks: [RISKS] Tool: [TOOL] Action owners: [OWNERS] Create the insight system: 1. Highlight criteria Define what should be highlighted: - KPI missed target - KPI exceeded target - sharp increase - sharp decrease - unusual volatility - new outlier - segment underperformance - data quality issue - stale data - action overdue 2. Exception table Design an exception table with: - issue - metric - segment - current value - expected value - variance - severity - owner - recommended action - due date 3. Highlight logic Create rules for: - high priority - medium priority - low priority - ignore as normal variation - needs human review 4. Dashboard placement Recommend where highlights should appear: - top banner - sidebar - exception table - KPI card - tooltip - email summary 5. Action connection Create an action log linked to each exception. Rules: - Do not highlight every small movement. - Do not create alerts without owners. - Do not let exceptions replace root cause analysis. - The report should direct attention to what matters most. --------------------------------------------------------------------------------

#152Data Story Slide Deck Planner

DASHBOARDS, DATA VISUALIZATION & REPORTINGAnalysts, consultants, executives, board reporting, performance reviews, business cases, stakeholder presentations, and insight storytelling.

Structure a data presentation deck with clear storyline, charts, evidence, caveats, recommendations, and decisions.

You are a data story presentation strategist. Create a slide deck outline for the analysis below. Presentation context: Audience: [AUDIENCE] Business question: [QUESTION] Decision needed: [DECISION] Key findings: [FINDINGS] Metrics: [METRICS] Charts available: [CHARTS] Business context: [CONTEXT] Recommended action: [ACTION] Caveats: [CAVEATS] Presentation length: [NUMBER OF SLIDES] Tone: [EXECUTIVE / CONSULTING / INTERNAL / BOARD] Create the deck: A. Storyline Build the story using: - situation - complication - question - evidence - implication - recommendation - next steps B. Slide outline For each slide include: - slide title - slide purpose - key message - visual needed - supporting evidence - speaker note - caveat - decision or action C. Chart placement Recommend which charts belong in the main deck vs appendix. D. Executive summary slide Write a concise executive summary slide. E. Recommendation slide Create the recommendation slide with: - recommendation - evidence - expected impact - risk - next step - decision ask F. Appendix plan List supporting slides for technical details. Rules: - Do not make slide titles generic like “Results.” - Do not show charts without a key message. - Do not put every analysis output in the main deck. - The deck should help the audience decide, not just learn. --------------------------------------------------------------------------------

#153Self-Service Dashboard Requirements Guardrail

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI teams, analytics leaders, self-service analytics programs, Power BI/Tableau/Looker developers, business users, and data governance teams.

Design self-service dashboard requirements that let stakeholders explore data safely without misunderstanding filters, metrics, drilldowns, or permissions.

Act as a self-service BI governance designer. Create guardrails for a dashboard that business users can explore without analyst support. Self-service context: Dashboard name: [DASHBOARD] User groups: [USER GROUPS] Business questions supported: [QUESTIONS] Metrics: [METRICS] Available dimensions: [DIMENSIONS] Filters: [FILTERS] Drilldowns: [DRILLDOWNS] Data sensitivity: [SENSITIVITY] User skill level: [SKILL LEVEL] Tool: [BI TOOL] Known misuse risks: [RISKS] Design self-service guardrails: A. Safe exploration scope Define: - what users can explore - what users should not infer - which filters are safe - which filters need warnings - which data should be restricted B. Metric guidance For each metric include: - definition - formula summary - correct interpretation - common misuse - related guardrails C. User interface guardrails Recommend: - default filters - locked date ranges - tooltip explanations - visible caveats - data freshness label - warning banners - drilldown limits - restricted exports D. Training guide Create a short user guide: - how to use the dashboard - how to filter - how to interpret KPIs - when to ask analytics team - how to request changes E. Governance process Define how requests, new filters, new metrics, and access changes are approved. Rules: - Do not make self-service mean no governance. - Do not expose sensitive detail unnecessarily. - Do not allow users to create misleading cuts without warnings. - The dashboard must balance exploration and trust. --------------------------------------------------------------------------------

#154Data Visualization Accessibility Reviewer

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI teams, dashboard designers, accessibility reviews, public reports, executive dashboards, education dashboards, healthcare reporting, and stakeholder-facing analytics.

Review charts and dashboards for accessibility, readable design, color safety, labeling, contrast, cognitive load, and inclusive interpretation.

You are a data visualization accessibility reviewer. Audit the dashboard or chart set below for accessibility and inclusive readability. Visualization context: Dashboard or report: [DESCRIPTION] Audience: [AUDIENCE] Visuals included: [VISUALS] Tool: [TOOL] Accessibility requirements: [REQUIREMENTS] Color palette: [COLORS] Text size or layout: [LAYOUT] Users with possible accessibility needs: [NEEDS] Output format: [DASHBOARD / PDF / SLIDES / WEB / PRINT] Review accessibility: A. Visual accessibility scan Check: - color contrast - color-only meaning - font size - label clarity - axis readability - chart density - small multiples readability - legend placement - tooltip dependence - mobile or small-screen readability B. Cognitive load scan Check: - too many visuals - unclear hierarchy - complex chart types - excessive filters - unexplained metrics - visual clutter - too much precision - missing summary C. Alternative interpretation support Recommend: - text summaries - annotations - data tables - alt text - descriptive titles - glossary - definitions - keyboard or screen reader considerations, if relevant D. Accessibility fix table For each issue include: - issue - affected users - why it matters - recommended fix - priority - effort E. Accessible redesign Describe the improved layout and visual treatment. Rules: - Do not rely on color alone to show status. - Do not assume users can read tiny labels or dense legends. - Do not remove analytical meaning while simplifying. - The final design should be easier to read, interpret, and trust. --------------------------------------------------------------------------------

#155Operational Reporting Dashboard Builder

DASHBOARDS, DATA VISUALIZATION & REPORTINGOperations teams, support teams, logistics, warehouses, fulfillment, sales ops, HR operations, finance operations, managers, and team leads.

Design an operational dashboard focused on daily/weekly execution, bottlenecks, exceptions, workload, SLAs, capacity, and action ownership.

Act as an operational reporting dashboard designer. Build a dashboard that helps a team manage day-to-day execution. Operational context: Business process: [PROCESS] Team: [TEAM] Users: [USERS] Operational goals: [GOALS] Current bottlenecks: [BOTTLENECKS] Metrics: [METRICS] SLAs or targets: [SLAS] Data sources: [SOURCES] Update frequency: [FREQUENCY] Action owners: [OWNERS] Tool: [TOOL] Design the dashboard: 1. Operational purpose Define: - what the team must monitor - what decisions happen daily or weekly - what exceptions require action - who owns each action 2. Dashboard sections Create sections for: - workload volume - backlog - SLA status - throughput - cycle time - quality - exceptions - capacity - owner-level view - action queue 3. Metrics and visuals For each section include: - metric - chart or table - target - threshold - owner - refresh need - action if off track 4. Exception management Design an exception list with: - item ID - issue type - severity - age - owner - next action - due date 5. Team workflow Explain how the dashboard should be used in: - daily standup - weekly review - escalation meeting - capacity planning Rules: - Do not design an operational dashboard like an executive dashboard. - Do not hide the action queue. - Do not include metrics without owners. - The dashboard must help the team act faster and reduce bottlenecks. --------------------------------------------------------------------------------

#156Dashboard QA and Acceptance Checklist

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI developers, data analysts, analytics managers, dashboard QA, Power BI/Tableau/Looker teams, consultants, and reporting teams.

Create a dashboard QA checklist covering data accuracy, filters, visuals, calculations, refresh, performance, permissions, usability, and stakeholder acceptance.

You are a BI dashboard QA lead. Create a complete QA and acceptance checklist for the dashboard below. Dashboard context: Dashboard name: [DASHBOARD] BI tool: [TOOL] Audience: [AUDIENCE] Data sources: [SOURCES] Metrics: [METRICS] Filters: [FILTERS] Pages: [PAGES] Refresh cadence: [REFRESH] Security rules: [SECURITY] Known risks: [RISKS] Launch deadline: [DEADLINE] Build the QA checklist: A. Data validation Check: - source totals - row counts - metric formulas - date coverage - refresh timestamp - missing data - duplicate records - source-of-truth reconciliation B. Filter and interaction QA Check: - filter defaults - filter combinations - slicer behavior - drilldowns - cross-filtering - reset behavior - hidden filters C. Visual QA Check: - titles - labels - axis scales - sorting - formatting - target lines - conditional colors - tooltips - legends - number formats D. Performance QA Check: - load time - query performance - heavy visuals - unnecessary fields - refresh failure risk E. Security QA Check: - row-level security - export permissions - sensitive fields - user access groups F. Stakeholder acceptance Create sign-off criteria and test scenarios. Rules: - Do not launch a dashboard based only on visual review. - Do not skip filter testing. - Do not ignore permissions and sensitive data. - QA must prove the dashboard is accurate, usable, and safe. --------------------------------------------------------------------------------

#157Report Redesign From Raw Tables to Insight View

DASHBOARDS, DATA VISUALIZATION & REPORTINGAnalysts improving old reports, finance packs, operations reports, sales reports, marketing reports, spreadsheet reports, and dashboard modernization.

Transform a raw table-heavy report into an insight-focused view with summaries, trends, exceptions, charts, and stakeholder-friendly narrative.

Act as a reporting redesign consultant. Turn this raw or table-heavy report into a clear insight-driven report. Current report: [PASTE REPORT DESCRIPTION / TABLE STRUCTURE / CURRENT SECTIONS] Context: Audience: [AUDIENCE] Business purpose: [PURPOSE] Decisions supported: [DECISIONS] Metrics included: [METRICS] Current pain points: [PAIN POINTS] Report cadence: [CADENCE] Tool: [TOOL] Constraints: [CONSTRAINTS] Redesign the report: 1. Current report diagnosis Identify issues such as: - too many tables - no summary - no prioritization - unclear metrics - no comparisons - no trend context - no action guidance - poor layout - hard-to-read formatting 2. New report structure Create sections: - executive summary - KPI snapshot - key changes - trend view - segment breakdown - exception table - action items - definitions and caveats 3. Table-to-visual conversion For each existing table recommend: - keep as table - summarize - convert to chart - move to appendix - remove - use as drilldown 4. Insight layer Create rules for highlighting: - top drivers - biggest changes - exceptions - risks - opportunities - decisions needed 5. Final report blueprint Write the improved report outline with page or section descriptions. Rules: - Do not remove detail that stakeholders need for action. - Do not keep raw tables as the main view if a summary is better. - Do not create visuals without interpretation. - The redesigned report must be easier to scan and more decision-oriented. --------------------------------------------------------------------------------

#158Stakeholder Reporting Requirements Interview

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI analysts, data analysts, analytics managers, consultants, dashboard builders, product teams, finance teams, and reporting redesign projects.

Create a stakeholder interview script to define reporting needs, dashboard expectations, metrics, decisions, cadence, format, and pain points.

You are a reporting requirements interviewer. Create an interview script to discover what stakeholders actually need from a dashboard or report. Stakeholder context: Stakeholder role: [ROLE] Department: [DEPARTMENT] Current reports used: [REPORTS] Reporting pain points: [PAIN POINTS] Business decisions: [DECISIONS] Metrics discussed: [METRICS] Expected cadence: [CADENCE] Tool preference: [TOOL] Known disagreements: [DISAGREEMENTS] Create the interview script: A. Opening script Set expectations and explain that the goal is decision-focused reporting. B. Business decision questions Ask: - what decisions they make - how often they make them - what information changes the decision - what happens after reviewing a report - what action they take when metrics move C. Metric questions Ask about: - primary KPIs - definitions - targets - comparisons - guardrails - segments - thresholds D. Report usage questions Ask: - when they use the report - what they look at first - what they ignore - what takes too long - what they export - what they screenshot - what they ask analysts repeatedly E. Format questions Ask about: - dashboard vs PDF vs spreadsheet vs slides - summary vs detail - filters - drilldowns - email commentary - mobile needs F. Closing summary Create a recap template confirming requirements, scope, owners, and next steps. Rules: - Do not ask only “what charts do you want?” - Do not accept metric requests without decision context. - Do not let stakeholders design visuals before defining use case. - The interview must produce dashboard-ready requirements. --------------------------------------------------------------------------------

#159BI Dashboard Documentation and User Guide Builder

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI teams, analytics teams, dashboard owners, self-service analytics, Power BI/Tableau/Looker dashboards, internal reporting portals, and stakeholder training.

Create documentation for a dashboard including purpose, metric definitions, data sources, refresh cadence, filters, caveats, user instructions, and owner contacts.

Act as a dashboard documentation specialist. Create a user guide for the dashboard below. Dashboard context: Dashboard name: [DASHBOARD] Audience: [AUDIENCE] Business purpose: [PURPOSE] BI tool: [TOOL] Pages or tabs: [PAGES] Metrics: [METRICS] Data sources: [SOURCES] Refresh cadence: [REFRESH] Filters: [FILTERS] Known caveats: [CAVEATS] Owner: [OWNER] Support contact: [CONTACT] Create the documentation: A. Dashboard overview Write: - what the dashboard is for - who should use it - when to use it - decisions it supports - what it does not cover B. Page guide For each page include: - purpose - main visuals - metrics shown - filters available - recommended interpretation - caveats C. Metric definitions For each metric include: - definition - formula summary - source - refresh cadence - owner - common misuse warning D. Filter guide Explain: - what each filter does - default values - dangerous combinations - reset instructions - drilldown behavior E. Data notes Document: - data sources - refresh timing - limitations - historical coverage - known issues - privacy restrictions F. FAQ Create answers to common stakeholder questions. Rules: - Do not assume users understand the dashboard. - Do not hide definitions in a separate technical file only. - Do not omit limitations. - Documentation must make the dashboard easier and safer to use. --------------------------------------------------------------------------------

#160Full Dashboards, Data Visualization and Reporting Audit

DASHBOARDS, DATA VISUALIZATION & REPORTINGBI analysts, data analysts, analytics leaders, dashboard owners, executives, consultants, finance teams, product teams, operations teams, and reporting teams.

Audit and rebuild a dashboard or reporting system across purpose, metrics, layout, chart choice, clarity, usability, narrative, QA, documentation, and stakeholder action.

Act as an independent dashboard, data visualization, and reporting auditor. Review my dashboard or reporting system and rebuild it into a clearer, more trusted, more actionable stakeholder-facing product. Full context: Dashboard or report name: [NAME] Business area: [AREA] Audience: [AUDIENCE] Business goal: [GOAL] Decisions supported: [DECISIONS] Current metrics: [METRICS] Current visuals: [VISUALS] Pages or sections: [PAGES] Data sources: [SOURCES] Refresh cadence: [REFRESH] Filters and drilldowns: [FILTERS / DRILLDOWNS] Known user complaints: [COMPLAINTS] Known data issues: [DATA ISSUES] Tool: [TOOL] Current reporting workflow: [WORKFLOW] Desired outcome: [OUTCOME] Audit across 60 dimensions: 1. Business purpose clarity 2. Decision connection 3. Audience fit 4. Dashboard scope 5. KPI selection 6. Metric definitions 7. Metric ownership 8. Data source clarity 9. Refresh visibility 10. Data freshness 11. Data quality caveats 12. Dashboard hierarchy 13. Page structure 14. Reading flow 15. KPI card design 16. Chart type selection 17. Chart title clarity 18. Axis clarity 19. Label clarity 20. Number formatting 21. Sorting logic 22. Color use 23. Accessibility 24. Visual clutter 25. Cognitive load 26. Filter usefulness 27. Filter risk 28. Drilldown logic 29. Tooltip usefulness 30. Annotation quality 31. Trend context 32. Comparison context 33. Target visibility 34. Baseline visibility 35. Segment clarity 36. Exception highlighting 37. Actionability 38. Root cause support 39. Executive summary 40. Reporting narrative 41. Insight prioritization 42. Caveat visibility 43. Self-service safety 44. Data export safety 45. Security and permissions 46. Performance and load time 47. Mobile or small-screen usability 48. Report refresh workflow 49. Distribution workflow 50. QA process 51. Acceptance criteria 52. Documentation 53. User guide 54. Stakeholder training 55. Feedback loop 56. Maintenance burden 57. Redundant reports 58. Misleading dashboard risk 59. Business trust 60. Overall reporting maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - stakeholder risk if ignored - decision risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the dashboard or report may not be helping stakeholders understand or act. B. Rebuilt reporting system Create: - dashboard purpose statement - audience map - KPI and visual hierarchy - redesigned layout - recommended chart set - filter and drilldown strategy - insight highlighting system - reporting narrative structure - QA checklist - documentation plan - refresh and distribution workflow C. First 10 redesign actions Rank the first 10 improvements. For each include: - issue - fix - why it matters - visual or section affected - owner - validation check - expected stakeholder benefit D. Dashboard wireframe Describe the improved dashboard page by page. E. Stakeholder readout Write a short reporting narrative that explains what users should understand and do. F. Executive summary Write a direct summary with: - strongest part of the dashboard - weakest part of the dashboard - biggest visual risk - biggest metric risk - biggest filter risk - first chart to redesign - one principle for better reporting Rules: - Do not recommend more visuals before clarifying decisions. - Do not ignore data quality caveats. - Do not make dashboards visually impressive but operationally useless. - Use [NEEDS METRIC DEFINITION], [NEEDS DATA QUALITY CHECK], [NEEDS DASHBOARD QA], [NEEDS STAKEHOLDER INPUT], [NEEDS ACCESSIBILITY REVIEW], or [NEEDS SECURITY REVIEW] where required. - The final system should make data easier to understand, trust, and act on.

#161Customer Behavior Pattern Discovery Map

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISCustomer analysts, product analysts, growth teams, ecommerce teams, SaaS teams, CRM teams, retention teams, marketing analysts, and business analysts studying customer behavior.

Explore customer behavior patterns across purchases, activity, frequency, recency, value, engagement, support usage, and lifecycle stages.

You are a senior customer behavior analyst. Analyze customer behavior from the dataset below and identify patterns that can support better product, growth, retention, or customer success decisions. Business context: Company or product: [COMPANY / PRODUCT] Business model: [BUSINESS MODEL] Customer type: [CUSTOMER TYPE] Main business question: [QUESTION] Customer dataset: [DATASET DESCRIPTION] Customer ID field: [CUSTOMER ID] Behavior fields: [BEHAVIOR FIELDS] Revenue or value fields: [VALUE FIELDS] Date fields: [DATE FIELDS] Segments available: [SEGMENTS] Time period: [TIME PERIOD] Decision to support: [DECISION] Known data limitations: [LIMITATIONS] Analyze customer behavior: 1. Customer activity profile Create a profile of customer behavior using: - total customers - active customers - inactive customers - new customers - returning customers - repeat behavior - average activity frequency - median activity frequency - activity distribution - customer value distribution 2. Behavior dimensions Explore behavior through: - recency - frequency - monetary value - product usage - feature usage - purchase behavior - support behavior - channel behavior - engagement depth - lifecycle stage 3. Segment comparison Compare customer behavior across key segments. For each segment include: - customer count - share of total - key behavior difference - value difference - engagement difference - retention or churn risk - business opportunity 4. Pattern discovery Identify patterns such as: - high-value behaviors - low-engagement behaviors - early warning signals - repeat usage signals - conversion behaviors - abandonment behaviors - reactivation signals 5. Business interpretation Turn patterns into: - growth opportunities - retention opportunities - product improvements - marketing actions - customer success actions - data gaps to close Rules: - Do not treat all customers as one average group. - Do not assume behavior causes outcomes without validation. - Do not ignore inactive or low-frequency customers. - The output must identify actionable customer behavior patterns, not just summarize activity. --------------------------------------------------------------------------------

#162Product Usage Health Analyzer

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analysts, SaaS teams, product managers, growth teams, customer success teams, founders, UX teams, and product-led growth teams.

Analyze product usage patterns to understand adoption, depth, frequency, stickiness, active usage, underused areas, and product health.

Act as a product usage analyst. Review product usage data and explain how users are actually using the product. Product context: Product name: [PRODUCT] Product type: [PRODUCT TYPE] User type: [USER TYPE] Main product goal: [GOAL] Usage events or actions: [EVENTS] Feature list: [FEATURES] User ID field: [USER ID] Account ID field, if any: [ACCOUNT ID] Date field: [DATE FIELD] Activation definition: [ACTIVATION DEFINITION] Engagement definition: [ENGAGEMENT DEFINITION] Time period: [TIME PERIOD] Segments: [SEGMENTS] Build the usage analysis: A. Usage overview Analyze: - active users - active accounts - new users - returning users - sessions or visits - actions per user - active days - usage frequency - usage depth - usage consistency B. Feature usage For each feature include: - users who used it - usage frequency - share of active users - repeat usage - time to first use - segment adoption - trend over time - business interpretation C. Usage health groups Classify users into: - power users - healthy users - occasional users - new users - at-risk users - dormant users - one-time users Define the logic for each group. D. Product health signals Identify: - sticky behaviors - underused features - confusing areas - usage drop-off - expansion signals - retention signals - support-risk signals E. Recommended product actions Create actions for: - onboarding - feature education - UX improvement - lifecycle messaging - customer success - product roadmap Rules: - Do not define “active” vaguely. - Do not count feature views as meaningful adoption unless justified. - Do not ignore repeat usage. - Product usage analysis must connect behavior to product decisions. --------------------------------------------------------------------------------

#163Activation Funnel Diagnostic

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISSaaS teams, mobile apps, marketplaces, PLG companies, onboarding teams, product analysts, growth teams, and founders improving new user activation.

Analyze user activation from signup or first touch to meaningful product value, identifying drop-offs, delays, segments, and activation blockers.

You are an activation funnel analyst. Diagnose where new users fail to reach the first meaningful value moment. Activation context: Product: [PRODUCT] New user definition: [NEW USER DEFINITION] Activation event: [ACTIVATION EVENT] Signup or start event: [START EVENT] Onboarding steps: [STEPS] Event table or dataset: [DATASET] User ID field: [USER ID] Timestamp field: [TIMESTAMP] Time window for activation: [TIME WINDOW] Segments: [SEGMENTS] Known onboarding changes: [CHANGES] Business goal: [GOAL] Diagnose activation: 1. Activation definition check Clarify: - what activation means - why this event represents value - maximum time allowed - events that should not count - edge cases 2. Funnel step analysis For each activation step calculate or describe: - users entering step - users completing step - step conversion rate - cumulative conversion - drop-off count - drop-off rate - median time to next step 3. Segment activation comparison Compare activation by: - acquisition channel - device - geography - plan - persona - account size - signup cohort - campaign - onboarding path 4. Activation blocker diagnosis Identify possible blockers: - unclear value proposition - too many steps - technical friction - missing data - poor first experience - irrelevant onboarding - delayed value moment - feature discoverability issue 5. Action recommendations Create: - quick fixes - experiment ideas - onboarding changes - lifecycle messages - product analytics follow-up - qualitative research questions Rules: - Do not optimize activation before defining real value. - Do not treat signup as activation. - Do not ignore time to activation. - Activation analysis should reveal where users fail to experience value. --------------------------------------------------------------------------------

#164Retention Cohort Analysis Blueprint

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISSaaS, subscriptions, ecommerce, mobile apps, education products, communities, marketplaces, customer success teams, and growth analysts.

Analyze retention by cohorts, lifecycle periods, segments, product usage, activation behavior, and customer value.

Act as a retention cohort analyst. Build a cohort analysis that explains how users or customers return, stay active, or continue paying over time. Retention context: Entity: [USER / CUSTOMER / ACCOUNT / STUDENT / MEMBER] Cohort definition: [COHORT DEFINITION] Retention definition: [RETENTION DEFINITION] Start date field: [START DATE] Activity or payment field: [ACTIVITY FIELD] Dataset: [DATASET] Time grain: [DAILY / WEEKLY / MONTHLY] Retention window: [WINDOW] Segments: [SEGMENTS] Activation events: [ACTIVATION EVENTS] Business question: [QUESTION] Create the retention analysis: A. Cohort setup Define: - cohort assignment rule - period 0 - retention event - cohort maturity rule - inclusion and exclusion rules - minimum cohort size B. Retention table Design output with: - cohort period - cohort size - period number - retained users - retention rate - cumulative retention - segment, if needed - maturity status C. Retention pattern review Identify: - strongest cohorts - weakest cohorts - early drop-off - retention plateau - recent cohort changes - segment differences - activation-linked retention D. Driver investigation Explore possible retention drivers: - onboarding completion - key feature adoption - usage frequency - first-week behavior - support interactions - plan type - acquisition channel - product category E. Retention action plan Recommend: - onboarding changes - engagement campaigns - customer success interventions - product improvements - segment-specific retention plays Rules: - Do not compare immature cohorts to mature cohorts unfairly. - Do not define retention without a meaningful return behavior. - Do not hide cohort size. - Retention analysis must show when users drop off and what may improve retention. --------------------------------------------------------------------------------

#165Churn Risk Signal Explorer

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISSaaS, subscriptions, customer success, revenue teams, product analysts, retention teams, ecommerce, memberships, and customer lifecycle teams.

Identify behavioral, product, support, billing, lifecycle, and engagement signals that may indicate churn risk.

You are a churn risk analyst. Identify early warning signals that customers or users may churn. Churn context: Business model: [BUSINESS MODEL] Entity analyzed: [USER / CUSTOMER / ACCOUNT] Churn definition: [CHURN DEFINITION] Dataset: [DATASET] Churn date or status field: [CHURN FIELD] Behavior fields: [BEHAVIOR FIELDS] Usage fields: [USAGE FIELDS] Support fields: [SUPPORT FIELDS] Billing fields: [BILLING FIELDS] Time window before churn: [WINDOW] Segments: [SEGMENTS] Current churn concern: [CONCERN] Discover churn signals: 1. Churn definition validation Clarify: - what counts as churn - voluntary vs involuntary churn - inactive vs canceled - account-level vs user-level churn - grace period - reactivation handling 2. Churned vs retained comparison Compare groups on: - usage frequency - usage recency - feature adoption - engagement depth - support contacts - billing issues - failed payments - plan changes - customer value - lifecycle stage 3. Early warning signals Create candidate signals such as: - drop in usage - fewer active days - no key feature usage - support escalation - failed payment - reduced team activity - seat removal - low onboarding completion - declining engagement trend 4. Signal scoring For each signal include: - business logic - data required - time before churn - actionability - false-positive risk - recommended intervention 5. Churn prevention playbook Create recommended actions for: - high-risk accounts - medium-risk accounts - newly inactive users - billing-risk customers - low-adoption customers Rules: - Do not claim predictive accuracy without validation. - Do not confuse inactivity with churn unless business rules support it. - Do not ignore involuntary churn. - Churn signal analysis should support early intervention. --------------------------------------------------------------------------------

#166Feature Adoption and Stickiness Analyzer

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct managers, product analysts, SaaS teams, app teams, PLG teams, UX teams, growth teams, and feature launch analysis.

Analyze whether users discover, try, repeat, and depend on features, and identify which features correlate with activation, retention, or value.

Act as a feature adoption analyst. Analyze adoption and stickiness for the product features below. Feature context: Product: [PRODUCT] Features to analyze: [FEATURES] Feature events: [EVENTS] User ID field: [USER ID] Account ID field: [ACCOUNT ID] Timestamp field: [TIMESTAMP] Feature launch date, if relevant: [LAUNCH DATE] Activation or retention metric: [METRIC] Segments: [SEGMENTS] Time period: [TIME PERIOD] Business question: [QUESTION] Analyze feature adoption: A. Adoption funnel For each feature measure: - eligible users - exposed users - first-time users - repeat users - active users - users who abandoned - time to first use - repeat usage rate B. Stickiness measures Evaluate: - frequency of use - repeat usage - active days with feature - feature usage depth - usage within first week - usage after 30 days - share of active users using feature C. Segment comparison Compare adoption by: - plan - persona - company size - geography - acquisition channel - lifecycle stage - device - cohort D. Outcome relationship Explore whether feature usage differs between: - retained vs churned users - activated vs not activated users - high-value vs low-value customers - expanded vs non-expanded accounts E. Product recommendations Recommend actions: - improve discoverability - redesign onboarding - remove friction - educate users - sunset or rethink feature - deepen usage - test feature messaging Rules: - Do not count one accidental click as meaningful adoption. - Do not claim a feature causes retention from correlation alone. - Do not compare features with different eligibility without adjustment. - Feature analysis must separate discovery, trial, repeat use, and value. --------------------------------------------------------------------------------

#167User Journey Path Analysis

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analysts, UX researchers, growth teams, ecommerce teams, onboarding teams, app teams, SaaS teams, and customer journey optimization.

Analyze the sequence of user actions across a journey to understand common paths, drop-offs, loops, friction, and conversion routes.

You are a user journey path analyst. Explore how users move through the product or experience before reaching or failing to reach [OUTCOME]. Journey context: Product or site: [PRODUCT / SITE] User journey: [JOURNEY] Desired outcome: [OUTCOME] Events or steps: [EVENTS / STEPS] Dataset: [DATASET] User ID field: [USER ID] Timestamp field: [TIMESTAMP] Session ID field, if any: [SESSION ID] Time window: [TIME WINDOW] Segments: [SEGMENTS] Known friction points: [FRICTION POINTS] Analyze user paths: 1. Journey definition Clarify: - start point - endpoint - required steps - optional steps - repeated actions - abandonment definition - conversion definition 2. Common paths Identify: - most common successful paths - most common unsuccessful paths - shortest successful path - longest successful path - loops and repeated steps - skipped steps - unexpected paths 3. Friction analysis Find: - steps with repeated attempts - steps with long delay - steps before abandonment - paths with high support contact - confusing loops - backtracking behavior 4. Segment path comparison Compare journeys by: - new vs returning users - channel - device - plan - cohort - geography - persona - customer value 5. Journey improvement recommendations Create: - UX improvements - onboarding improvements - messaging improvements - product changes - tracking improvements - research questions Rules: - Do not assume the intended journey is the actual journey. - Do not ignore loops and repeated actions. - Do not analyze only users who converted. - Journey analysis must reveal how users actually move and where they struggle. --------------------------------------------------------------------------------

#168Engagement Quality Score Builder

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analytics, communities, SaaS, mobile apps, ecommerce, education platforms, media products, lifecycle marketing, and user health scoring.

Build an engagement scoring framework based on meaningful behavior, frequency, recency, depth, value, and retention relevance.

Act as an engagement scoring strategist. Design an engagement quality score for [PRODUCT / CUSTOMER BASE]. Engagement context: Product or business: [PRODUCT] Users or customers: [USERS] Business goal: [GOAL] Available behavior data: [BEHAVIOR DATA] Important actions: [ACTIONS] Low-value actions: [LOW VALUE ACTIONS] Retention or conversion outcome: [OUTCOME] Time window: [TIME WINDOW] Segments: [SEGMENTS] Current engagement definition: [CURRENT DEFINITION] Build the engagement score: A. Engagement philosophy Define what “good engagement” means for this product. Separate: - activity - meaningful usage - habit - depth - value realization - retention signal B. Candidate score components Create components such as: - recency - frequency - feature depth - session depth - completion behavior - social or collaboration behavior - purchase or value behavior - content consumption - support-free success - consistency over time C. Scoring model Design: - component weights - point values - time decay - minimum activity rule - penalty rules - missing data handling - score range D. User tiers Classify users into: - highly engaged - healthy - casual - low engagement - at risk - dormant E. Validation plan Explain how to test whether the score relates to retention, conversion, or value. Rules: - Do not reward meaningless clicks. - Do not create a score that cannot be explained to stakeholders. - Do not use the score for high-stakes decisions without validation. - Engagement scoring must reflect meaningful behavior, not noise. --------------------------------------------------------------------------------

#169Customer Segmentation for Growth Decisions

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISGrowth teams, marketing teams, product teams, SaaS, ecommerce, CRM teams, customer success teams, revenue teams, and founders.

Create actionable customer segments based on behavior, value, lifecycle, needs, usage, acquisition source, and business potential.

You are a customer segmentation analyst. Build practical customer segments that help the business make better growth, retention, product, or marketing decisions. Segmentation context: Business model: [BUSINESS MODEL] Customer dataset: [DATASET] Customer fields: [FIELDS] Behavior fields: [BEHAVIOR FIELDS] Value fields: [VALUE FIELDS] Lifecycle fields: [LIFECYCLE FIELDS] Acquisition fields: [ACQUISITION FIELDS] Business goal: [GOAL] Decision to support: [DECISION] Minimum segment size: [MINIMUM SIZE] Current segments: [CURRENT SEGMENTS] Create the segmentation: 1. Segmentation objective Define what decision the segmentation should support. 2. Segmentation dimensions Evaluate potential dimensions: - value - frequency - recency - product usage - lifecycle stage - acquisition channel - needs or use case - company size - geography - churn risk - expansion potential 3. Segment creation Create 6 to 10 practical segments. For each segment include: - segment name - definition - customer count - business meaning - key behaviors - value level - risk level - opportunity - recommended action - owner 4. Segment prioritization Rank segments by: - business impact - actionability - growth potential - retention risk - ease of targeting 5. Activation plan Recommend campaigns, product changes, or success motions for each priority segment. Rules: - Do not create segments that cannot be acted on. - Do not over-segment small data. - Do not use demographic segments if behavior is more useful. - The segmentation must support clear business actions. --------------------------------------------------------------------------------

#170Product Funnel Experiment Opportunity Finder

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct managers, growth teams, product analysts, ecommerce teams, SaaS teams, experiment owners, UX teams, and conversion optimization.

Use funnel and behavior data to identify where experiments can improve activation, conversion, retention, engagement, or revenue.

Act as a product growth experiment analyst. Analyze the funnel and behavior patterns below to identify the best experiment opportunities. Experiment context: Product or flow: [PRODUCT / FLOW] Business goal: [GOAL] Funnel steps: [FUNNEL STEPS] Current conversion rates: [CONVERSION RATES] Behavior observations: [OBSERVATIONS] Segments: [SEGMENTS] Known friction points: [FRICTION] Available experiment surfaces: [SURFACES] Constraints: [CONSTRAINTS] Risk tolerance: [LOW / MEDIUM / HIGH] Find experiment opportunities: A. Funnel opportunity scan Identify: - biggest drop-off - highest-volume step - highest-intent step - slowest step - confusing step - segment-specific problem - step with poor repeat behavior B. Experiment hypotheses Create 10 experiment hypotheses. For each include: - hypothesis - user problem - business metric affected - expected behavior change - experiment idea - target segment - primary metric - guardrail metric - risk - confidence level C. Prioritization Rank experiments by: - potential impact - effort - confidence - speed to learn - risk - strategic fit D. Measurement plan For top experiments define: - success metric - guardrail metric - test population - minimum detectable impact, if known - runtime consideration - decision rule E. Learning plan Explain what the team should learn even if the experiment fails. Rules: - Do not suggest experiments without a behavior hypothesis. - Do not optimize low-volume steps first unless strategically important. - Do not ignore guardrail metrics. - Experiments should be tied to user behavior and business outcomes. --------------------------------------------------------------------------------

#171Account-Level Product Health Review

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISB2B SaaS, customer success teams, account managers, revenue teams, product analytics, enterprise products, and subscription businesses.

Analyze account-level health using usage, adoption, engagement, seat activity, expansion signals, support signals, renewal risk, and value realization.

You are a B2B account health analyst. Create an account-level product health review using the available usage and customer data. Account context: Business model: [BUSINESS MODEL] Account dataset: [ACCOUNT DATA] User activity dataset: [USER ACTIVITY] Account ID field: [ACCOUNT ID] User ID field: [USER ID] Plan or contract fields: [PLAN / CONTRACT] Renewal date field: [RENEWAL DATE] Feature usage fields: [FEATURES] Support fields: [SUPPORT] Revenue fields: [REVENUE] Health goal: [GOAL] Build the account health review: 1. Account profile For each account calculate or describe: - account size - active users - total users - active user share - usage frequency - feature adoption - key workflow completion - support activity - contract value - renewal timing 2. Health dimensions Score account health across: - adoption - engagement - breadth of usage - depth of usage - value realization - support risk - renewal risk - expansion potential 3. Account segments Classify accounts as: - healthy and growing - under-adopted - single-user dependency - expansion-ready - support-heavy - renewal-risk - dormant - needs onboarding 4. Risk and opportunity list Create prioritized lists: - top renewal risks - top expansion opportunities - accounts needing customer success outreach - accounts needing product education - accounts needing executive review 5. Action plan Create recommended next actions by account type. Rules: - Do not judge account health only by revenue. - Do not ignore user-level activity inside accounts. - Do not treat one power user as broad adoption. - Account health should help customer success and revenue teams act. --------------------------------------------------------------------------------

#172Customer Lifecycle Stage Classifier

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISCRM teams, lifecycle marketers, customer success, SaaS, ecommerce, subscriptions, product teams, growth teams, and retention analysis.

Define customer lifecycle stages and classify users or customers based on behavior, timing, value, activation, engagement, retention, and churn signals.

Act as a customer lifecycle analytics specialist. Build a lifecycle stage classification system for my users or customers. Lifecycle context: Business model: [BUSINESS MODEL] Customer or user entity: [ENTITY] Dataset fields: [FIELDS] Start event: [START EVENT] Activation event: [ACTIVATION EVENT] Purchase or value event: [VALUE EVENT] Engagement events: [ENGAGEMENT EVENTS] Churn or inactivity definition: [CHURN / INACTIVITY] Time windows: [TIME WINDOWS] Segments: [SEGMENTS] Business use: [USE CASE] Create the lifecycle system: A. Lifecycle stage definitions Define stages such as: - prospect - new user - onboarding - activated - engaged - repeat user - high-value customer - at risk - dormant - churned - reactivated For each stage include: - entry criteria - exit criteria - key behavior - time window - business meaning - owner - recommended action B. Classification logic Create rules using: - dates - events - activity count - usage frequency - purchase behavior - recency - value - churn status C. Priority order Define what happens when a customer matches multiple stages. D. Reporting view Design a lifecycle report showing: - count per stage - share per stage - movement between stages - stage value - risk - next action E. Lifecycle playbook Recommend messages, product actions, or success actions per stage. Rules: - Do not create overlapping lifecycle stages without priority logic. - Do not define lifecycle stages that no team will use. - Do not confuse dormant with churned unless business rules support it. - Lifecycle classification must support action and measurement. --------------------------------------------------------------------------------

#173User Engagement Drop-Off Investigation

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct teams, growth teams, retention analysts, SaaS, mobile apps, communities, media products, education platforms, and customer success.

Diagnose why user engagement declined by analyzing activity frequency, feature usage, cohorts, segments, product changes, lifecycle shifts, and external factors.

You are an engagement decline investigator. Diagnose why engagement has dropped and what the team should investigate or change. Engagement context: Product: [PRODUCT] Engagement metric: [METRIC] Current value: [CURRENT VALUE] Previous value: [PREVIOUS VALUE] Time period: [TIME PERIOD] User segments: [SEGMENTS] Feature usage data: [FEATURE DATA] Recent product changes: [PRODUCT CHANGES] Recent marketing changes: [MARKETING CHANGES] Known data issues: [DATA ISSUES] Business concern: [CONCERN] Investigate the drop: 1. Metric validation Check: - definition stability - tracking changes - data freshness - incomplete periods - missing events - duplicate events - segment mix changes 2. Engagement decomposition Break engagement into: - active users - activity frequency - sessions per user - active days - feature usage - content or workflow completion - new vs returning users - power users vs casual users 3. Segment diagnosis Identify which segments declined: - acquisition channel - cohort - device - geography - plan - lifecycle stage - persona - usage level 4. Product behavior scan Look for: - feature adoption drop - onboarding decline - workflow friction - increased errors - slower time to value - repeated failed actions - support increase 5. Explanation ranking Rank possible causes by likelihood, impact, and evidence needed. 6. Recovery plan Create actions for: - data validation - product investigation - user research - lifecycle campaign - feature education - experiment ideas Rules: - Do not assume engagement drop is product failure before checking data. - Do not ignore new vs returning user mix. - Do not rely on one engagement metric alone. - The investigation must separate real behavior change from measurement issues. --------------------------------------------------------------------------------

#174Customer Value and RFM Analysis Builder

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISEcommerce, retail, subscriptions, marketplaces, CRM, lifecycle marketing, customer analytics, finance teams, and growth teams.

Analyze customers by recency, frequency, monetary value, repeat behavior, loyalty, and revenue contribution.

Act as a customer value analyst. Build an RFM-style analysis and customer value segmentation for the business below. Customer value context: Business model: [BUSINESS MODEL] Customer dataset: [DATASET] Customer ID field: [CUSTOMER ID] Transaction date field: [DATE FIELD] Revenue or value field: [VALUE FIELD] Order or activity ID field: [ORDER / ACTIVITY ID] Time period: [TIME PERIOD] Segments: [SEGMENTS] Business goal: [GOAL] Marketing or retention use case: [USE CASE] Create the RFM analysis: A. RFM calculation Define: - recency - frequency - monetary value - active period - customer eligibility - order exclusions - refund or cancellation handling B. Score design Create scoring logic for: - recency score - frequency score - monetary score - combined RFM score - tier assignment C. Customer segments Create segments such as: - champions - loyal customers - high potential - new customers - promising - need attention - at risk - cannot lose - hibernating - lost For each segment include: - definition - customer count - value - behavior - risk - recommended action D. Business opportunities Identify: - retention opportunities - upsell opportunities - win-back opportunities - loyalty opportunities - low-value cost-control opportunities E. Reporting plan Create a dashboard or spreadsheet structure for tracking RFM segments over time. Rules: - Do not use RFM scoring without explaining business meaning. - Do not ignore refunds, cancellations, or inactive periods. - Do not treat all high-frequency customers as high value. - RFM analysis must lead to specific customer actions. --------------------------------------------------------------------------------

#175Product Adoption Cohort Comparison

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analysts, SaaS teams, mobile apps, onboarding teams, growth teams, feature launch reviews, PLG teams, and product managers.

Compare product adoption patterns across cohorts to understand whether new users are adopting faster, deeper, or differently over time.

You are a product adoption cohort analyst. Compare product adoption across user cohorts and identify whether adoption is improving or declining. Adoption context: Product: [PRODUCT] Cohort definition: [COHORT DEFINITION] Adoption event or behavior: [ADOPTION EVENT] Feature or workflow: [FEATURE / WORKFLOW] User ID field: [USER ID] Timestamp field: [TIMESTAMP] Dataset: [DATASET] Cohort periods: [PERIODS] Adoption window: [WINDOW] Segments: [SEGMENTS] Known product changes: [CHANGES] Analyze adoption cohorts: 1. Cohort setup Define: - cohort event - adoption event - adoption window - eligibility criteria - cohort maturity rule - minimum cohort size 2. Adoption metrics Calculate or describe: - adoption rate - time to adoption - repeat adoption - adoption depth - adoption by feature - adoption by segment - abandonment after trial 3. Cohort comparison Compare cohorts by: - first-day adoption - first-week adoption - first-month adoption - time to first value - repeat behavior - adoption plateau 4. Product change interpretation Identify whether adoption changes align with: - onboarding changes - feature launch - pricing change - UX change - messaging change - acquisition mix shift - tracking change 5. Product recommendations Create recommendations for improving adoption. Rules: - Do not compare immature cohorts with mature cohorts without caveats. - Do not count exposure as adoption unless the user actively uses the feature. - Do not ignore acquisition mix changes. - Adoption cohort analysis should explain whether product changes improve user behavior. --------------------------------------------------------------------------------

#176Support Behavior and Product Friction Analysis

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct teams, customer support analytics, customer success, SaaS, ecommerce, UX teams, operations teams, and quality improvement.

Analyze support tickets, complaints, chat logs, help center usage, product errors, and user behavior to identify friction points and product improvement opportunities.

Act as a product friction analyst. Use support and behavior data to identify where customers struggle and what the product team should improve. Friction context: Product or service: [PRODUCT / SERVICE] Support dataset: [SUPPORT DATASET] Product usage dataset: [USAGE DATASET] Customer ID or user ID: [ID FIELD] Ticket category field: [CATEGORY] Ticket date field: [DATE] Severity or priority field: [SEVERITY] Feature or area field: [FEATURE] Business goal: [GOAL] Known friction points: [KNOWN FRICTION] Time period: [TIME PERIOD] Analyze friction: A. Support issue profile Summarize: - ticket volume - tickets per active user - top categories - top features mentioned - high-severity issues - repeat contacts - time to resolution - unresolved issues B. Behavior before support Explore what users did before contacting support: - feature used - failed action - repeated attempt - abandoned flow - error event - time since signup - lifecycle stage C. Segment friction Compare support behavior by: - plan - customer type - device - geography - lifecycle stage - feature usage - account size - acquisition channel D. Product opportunity map For each friction area include: - issue - affected users - business impact - evidence - product change idea - support process change - priority - owner E. Measurement plan Define how to measure whether the fix reduces friction. Rules: - Do not treat support volume as only a support team problem. - Do not ignore silent friction from users who abandon without contacting support. - Do not overgeneralize from a few tickets without volume context. - The analysis must connect support signals to product and customer experience improvements. --------------------------------------------------------------------------------

#177User Journey Metrics Framework

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct managers, growth teams, product analysts, lifecycle teams, customer success, SaaS, ecommerce, marketplaces, apps, and journey mapping.

Define metrics for each stage of a user journey, from acquisition and onboarding to activation, engagement, retention, expansion, support, and churn.

You are a user journey measurement strategist. Build a metric framework for the full user journey below. Journey context: Product or service: [PRODUCT / SERVICE] User journey stages: [STAGES] Business model: [BUSINESS MODEL] Primary business goal: [GOAL] User value moment: [VALUE MOMENT] Available data: [DATA SOURCES] Current metrics: [CURRENT METRICS] Stakeholders: [STAKEHOLDERS] Decision cadence: [CADENCE] Known journey problems: [PROBLEMS] Create the framework: A. Journey stages Define stages such as: - acquisition - signup - onboarding - activation - first value - habit formation - engagement - retention - expansion - support - churn or reactivation B. Stage metrics For each stage include: - stage goal - user behavior to measure - primary metric - diagnostic metrics - guardrail metrics - owner - data source - action if metric moves C. Stage transitions Define conversion between stages: - entry event - exit event - success threshold - failure point - time window D. Journey dashboard structure Recommend views for: - funnel - cohort - lifecycle stage - segment - behavior path - friction points E. Measurement risks Identify risks such as: - tracking gaps - misleading averages - unclear activation - overlapping stages - wrong time windows Rules: - Do not measure only acquisition if retention matters. - Do not define journey stages without measurable entry and exit events. - Do not ignore guardrails. - The framework must show how users move toward value and where they get stuck. --------------------------------------------------------------------------------

#178Behavioral Cohort Deep Dive

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analysts, growth teams, SaaS, mobile apps, education platforms, ecommerce, retention teams, and lifecycle marketing.

Compare groups based on early behaviors and understand how those behaviors relate to later retention, conversion, revenue, or engagement.

Act as a behavioral cohort analyst. Compare users based on early behavior and identify which behaviors are associated with better later outcomes. Behavioral cohort context: Product or business: [PRODUCT / BUSINESS] User ID field: [USER ID] Start event: [START EVENT] Early behavior window: [WINDOW] Early behaviors to compare: [BEHAVIORS] Outcome metric: [OUTCOME] Outcome window: [OUTCOME WINDOW] Dataset: [DATASET] Segments: [SEGMENTS] Business decision: [DECISION] Build the behavioral cohort analysis: 1. Cohort definitions Create cohorts based on early behaviors such as: - completed onboarding - used key feature - invited teammate - made first purchase - created first project - returned on day 2 - watched tutorial - contacted support - reached usage threshold 2. Outcome comparison For each behavioral cohort compare: - cohort size - retention - conversion - revenue - engagement - churn - support burden - expansion - confidence level 3. Behavior timing Analyze whether timing matters: - same day - first 24 hours - first 3 days - first 7 days - first 30 days 4. Segment adjustment Compare behavior-outcome patterns by segment. 5. Recommendation Identify which early behaviors should be encouraged through product, onboarding, marketing, or success actions. Rules: - Do not claim causation from behavior-outcome association. - Do not ignore self-selection bias. - Do not compare cohorts without size and maturity checks. - The analysis should identify behaviors worth encouraging and testing. --------------------------------------------------------------------------------

#179Product and Growth Decision Readout

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct managers, growth leads, founders, customer success, marketing teams, product analysts, executives, and cross-functional decision meetings.

Turn customer, product, and user behavior analysis into a clear decision-ready readout with findings, implications, recommendations, caveats, and next steps.

You are a product and growth analytics communicator. Convert the behavior analysis findings below into a decision-ready readout. Analysis findings: [PASTE FINDINGS / CHART NOTES / TABLES / OBSERVATIONS] Business context: Product or business: [PRODUCT / BUSINESS] Audience: [AUDIENCE] Decision to support: [DECISION] Primary metric: [METRIC] User segments: [SEGMENTS] Time period: [TIME PERIOD] Known limitations: [LIMITATIONS] Recommended action, if any: [ACTION] Readout format: [MEMO / SLIDES / EMAIL / MEETING NOTES] Create the readout: A. Executive summary Write 5 to 7 sentences covering: - main behavior pattern - biggest opportunity - biggest risk - affected segment - likely implication - recommended next step - confidence level B. Key findings Create 5 to 8 findings. For each include: - finding - evidence - affected users - business implication - caveat - action or follow-up C. Decision options Present 2 to 4 possible decisions. For each include: - option - supporting evidence - expected impact - risk - effort - recommended owner D. Open questions List what still needs validation through: - deeper analysis - user research - experiment - tracking fix - stakeholder context E. Final recommendation Write a concise recommendation with next steps. Rules: - Do not dump charts without interpretation. - Do not overstate causality. - Do not hide caveats. - The readout must help product and growth teams decide what to do next. --------------------------------------------------------------------------------

#180Full Customer, Product and User Behavior Analysis Audit

CUSTOMER, PRODUCT & USER BEHAVIOR ANALYSISProduct analysts, growth teams, SaaS teams, ecommerce teams, customer success, marketing analytics, product managers, founders, BI teams, and retention teams.

Audit and rebuild a behavior analysis system across customer behavior, product usage, funnels, activation, retention, cohorts, churn, engagement, segmentation, feature adoption, and user journeys.

Act as an independent customer, product, and user behavior analytics auditor. Review my current behavior data, product analytics, and customer analysis workflow, then rebuild it into a decision-ready system for product and growth decisions. Full context: Product or business: [PRODUCT / BUSINESS] Business model: [BUSINESS MODEL] Primary goal: [GOAL] Primary users or customers: [USERS / CUSTOMERS] Current analysis questions: [QUESTIONS] Datasets available: [DATASETS] Event tracking available: [EVENTS] Customer fields: [CUSTOMER FIELDS] Product usage fields: [USAGE FIELDS] Revenue fields: [REVENUE FIELDS] Support fields: [SUPPORT FIELDS] Date fields: [DATE FIELDS] User ID and account ID logic: [ID LOGIC] Current KPIs: [KPIS] Segments: [SEGMENTS] Known data quality issues: [ISSUES] Current dashboards or reports: [REPORTS] Decisions to support: [DECISIONS] Stakeholders: [STAKEHOLDERS] Audit across 60 dimensions: 1. Business goal alignment 2. Decision connection 3. User identity logic 4. Account identity logic 5. Event tracking completeness 6. Event naming clarity 7. Product usage definition 8. Active user definition 9. Activation definition 10. First value definition 11. Engagement definition 12. Retention definition 13. Churn definition 14. Reactivation definition 15. Feature adoption definition 16. Funnel step definition 17. Journey stage definition 18. Customer lifecycle logic 19. Segment strategy 20. Segment size control 21. Customer value measurement 22. Recency analysis 23. Frequency analysis 24. Monetary value analysis 25. Product usage depth 26. Product usage breadth 27. Feature discovery 28. Feature trial 29. Feature repeat usage 30. Feature stickiness 31. Onboarding analysis 32. Activation funnel analysis 33. Conversion funnel analysis 34. Drop-off diagnosis 35. Time-to-value analysis 36. Cohort setup 37. Retention cohort analysis 38. Behavioral cohort analysis 39. Churn signal analysis 40. Account health analysis 41. Engagement score quality 42. Support friction analysis 43. User journey path analysis 44. Product experiment opportunities 45. Growth lever mapping 46. Lifecycle messaging opportunities 47. Customer success actionability 48. Revenue impact connection 49. Data quality caveats 50. Tracking gaps 51. Correlation vs causation risk 52. Segment mix risk 53. Cohort maturity risk 54. Dashboard usefulness 55. Reporting narrative quality 56. Stakeholder action clarity 57. Experiment readiness 58. Product decision readiness 59. Growth decision readiness 60. Overall behavior analytics maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - product risk if ignored - growth risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current behavior analysis may fail to support better product or growth decisions. B. Rebuilt behavior analytics system Create: - customer behavior analysis plan - product usage framework - activation funnel framework - retention cohort framework - churn risk signal map - engagement scoring system - segmentation strategy - feature adoption analysis - user journey analysis - account health model, if relevant - reporting and decision readout structure C. First 10 behavior analysis actions Rank the first 10 actions to complete. For each include: - action - data needed - why it matters - business decision supported - owner - expected output - risk reduced D. Dashboard and reporting structure Recommend views for: - executive product health - activation funnel - retention cohorts - engagement segments - churn risk - feature adoption - customer journey - growth opportunities E. Product and growth recommendations Create recommended actions for: - onboarding - activation - engagement - retention - churn prevention - feature adoption - customer success - lifecycle marketing F. Executive summary Write a direct summary with: - strongest behavior signal - weakest data area - biggest activation problem - biggest retention risk - highest-value segment - first product experiment to run - one operating principle for behavior analytics Rules: - Do not analyze behavior without clear user and account identity logic. - Do not treat exploratory behavior patterns as proof of causation. - Do not ignore cohort maturity, segment size, or tracking quality. - Use [NEEDS TRACKING REVIEW], [NEEDS COHORT MATURITY CHECK], [NEEDS PRODUCT OWNER REVIEW], [NEEDS DATA QUALITY CHECK], [NEEDS USER RESEARCH], or [NEEDS EXPERIMENT VALIDATION] where required. - The final system should connect user behavior to product decisions, growth actions, and business outcomes.

#181Sales Performance Diagnostic Analyst

SALES, MARKETING & REVENUE ANALYTICSSales analysts, RevOps teams, sales leaders, founders, revenue teams, finance teams, CRM analysts, and anyone diagnosing sales performance.

Analyze sales performance across reps, teams, regions, products, segments, deal sizes, win rates, cycle length, and revenue contribution.

You are a senior sales performance analyst. Analyze sales performance using the available data and identify what is driving revenue growth, underperformance, and pipeline risk. Business context: Company or product: [COMPANY / PRODUCT] Sales model: [SALES MODEL] Sales team structure: [TEAM STRUCTURE] Dataset description: [DATASET] CRM or source system: [CRM / SOURCE] Time period: [TIME PERIOD] Revenue metric: [REVENUE METRIC] Sales stages: [STAGES] Sales reps or owners: [REPS / OWNERS] Segments: [SEGMENTS] Products or plans: [PRODUCTS / PLANS] Targets or quotas: [TARGETS] Business question: [QUESTION] Analyze sales performance: 1. Revenue overview Summarize: - total revenue - new revenue - expansion revenue - renewal revenue - lost revenue - average deal size - median deal size - revenue by period - revenue vs target 2. Sales team performance Compare: - rep performance - team performance - quota attainment - win rate - average deal size - pipeline created - deals closed - sales cycle length - activity-to-outcome relationship 3. Segment and product performance Analyze revenue by: - customer segment - industry - region - acquisition source - product - plan - deal size band - account type 4. Performance drivers Identify what is driving performance: - volume - conversion rate - deal size - sales cycle - product mix - segment mix - rep productivity - pipeline quality - discounting - seasonality 5. Risk and opportunity Create: - top revenue opportunities - biggest sales risks - underperforming areas - overperforming areas - coaching opportunities - pipeline actions Rules: - Do not evaluate sales performance using revenue alone. - Do not compare reps without accounting for territory, segment, and pipeline mix. - Do not ignore sales cycle length or pipeline quality. - The output must identify what sales leaders should do next. --------------------------------------------------------------------------------

#182Marketing Campaign Performance Analyzer

SALES, MARKETING & REVENUE ANALYTICSMarketing analysts, growth marketers, paid acquisition teams, founders, CMOs, media buyers, ecommerce teams, SaaS teams, and campaign managers.

Evaluate marketing campaigns by spend, reach, clicks, leads, conversions, CAC, ROAS, revenue, channel mix, and funnel quality.

Act as a marketing campaign performance analyst. Review campaign data and explain which campaigns are working, which are wasting budget, and what should be optimized. Campaign context: Business model: [BUSINESS MODEL] Campaigns: [CAMPAIGNS] Channels: [CHANNELS] Dataset: [DATASET] Time period: [TIME PERIOD] Spend fields: [SPEND FIELDS] Conversion fields: [CONVERSION FIELDS] Revenue fields: [REVENUE FIELDS] Attribution model, if any: [ATTRIBUTION MODEL] Target audience: [AUDIENCE] Campaign objective: [OBJECTIVE] Budget constraints: [CONSTRAINTS] Analyze campaign performance: A. Campaign scorecard For each campaign include: - spend - impressions - clicks - CTR - CPC - leads - conversion rate - CAC - revenue - ROAS - pipeline generated - quality score - status B. Funnel quality Analyze: - click to lead - lead to qualified lead - qualified lead to opportunity - opportunity to customer - customer to revenue - drop-off points - lead quality by campaign C. Budget efficiency Classify campaigns as: - scale - optimize - monitor - pause - test further - attribution unclear - tracking issue D. Segment insight Compare performance by: - audience - creative - offer - device - geography - landing page - keyword - placement - campaign type E. Optimization plan Recommend: - budget shifts - creative tests - landing page improvements - audience changes - tracking fixes - funnel follow-up - reporting improvements Rules: - Do not judge campaigns only by clicks or impressions. - Do not scale campaigns without checking conversion quality and revenue. - Do not ignore attribution and tracking limitations. - Campaign analysis must connect spend to business outcomes. --------------------------------------------------------------------------------

#183Revenue Funnel Conversion Analyst

SALES, MARKETING & REVENUE ANALYTICSSales and marketing teams, RevOps, SaaS businesses, B2B funnels, ecommerce funnels, founders, growth teams, and revenue operations.

Analyze the revenue funnel from traffic or leads to qualified opportunities, closed deals, revenue, retention, and expansion.

You are a revenue funnel analyst. Diagnose where the funnel is converting, leaking, or creating low-quality volume. Funnel context: Business model: [BUSINESS MODEL] Funnel stages: [FUNNEL STAGES] Dataset: [DATASET] Entity tracked: [VISITOR / LEAD / ACCOUNT / DEAL / ORDER] Date field: [DATE FIELD] Revenue field: [REVENUE FIELD] Stage timestamp fields: [STAGE TIMESTAMPS] Channels: [CHANNELS] Segments: [SEGMENTS] Time period: [TIME PERIOD] Business goal: [GOAL] Known funnel issues: [ISSUES] Analyze the revenue funnel: 1. Funnel definition check Clarify: - stage order - stage entry rules - stage exit rules - duplicate handling - time window - exclusions - source of truth 2. Funnel metrics Calculate or describe: - count at each stage - stage-to-stage conversion - cumulative conversion - drop-off count - drop-off rate - average time between stages - median time between stages - revenue per stage 3. Channel and segment comparison Compare funnel by: - acquisition channel - campaign - source or medium - customer segment - region - product - deal size - sales owner - cohort 4. Leak diagnosis For each major leak include: - funnel stage - size of loss - affected segment - likely cause - data caveat - action owner - recommended fix 5. Revenue impact estimate Estimate impact if conversion improves at key stages. Rules: - Do not analyze funnel stages before definitions are clear. - Do not optimize lead volume if lead quality is poor. - Do not ignore time between stages. - The analysis must show where revenue is lost and what action could recover it. --------------------------------------------------------------------------------

#184CAC and Payback Analysis Builder

SALES, MARKETING & REVENUE ANALYTICSSaaS teams, ecommerce businesses, startups, finance teams, growth marketers, founders, marketing analysts, and revenue leaders.

Calculate customer acquisition cost, blended CAC, paid CAC, channel CAC, payback period, and acquisition efficiency.

Act as a CAC and acquisition efficiency analyst. Build a CAC analysis and explain whether acquisition spend is efficient. CAC context: Business model: [BUSINESS MODEL] Acquisition channels: [CHANNELS] Marketing spend: [SPEND DATA] Sales spend, if included: [SALES SPEND] New customers: [CUSTOMERS] New revenue: [REVENUE] Gross margin: [GROSS MARGIN] Time period: [TIME PERIOD] Attribution model: [ATTRIBUTION MODEL] Customer segments: [SEGMENTS] Payback target: [PAYBACK TARGET] Known data issues: [ISSUES] Build the CAC analysis: A. CAC definitions Define: - blended CAC - paid CAC - channel CAC - sales-assisted CAC - fully loaded CAC - marginal CAC - CAC payback B. Calculation table For each channel or segment include: - spend - new customers - CAC - new MRR or revenue - gross margin - gross profit - payback period - comparison to target - data confidence C. Efficiency diagnosis Classify channels as: - efficient and scalable - efficient but limited - promising but early - inefficient - attribution unclear - needs tracking fix D. Payback analysis Calculate or describe: - revenue payback - gross margin payback - payback by channel - payback by segment - payback risk E. Recommendations Create actions for: - budget allocation - channel testing - pricing - sales process - targeting - attribution cleanup Rules: - Do not calculate CAC without defining which costs are included. - Do not compare channels with different attribution logic without caveats. - Do not ignore gross margin when payback matters. - The analysis must support acquisition investment decisions. --------------------------------------------------------------------------------

#185LTV and Customer Value Model

SALES, MARKETING & REVENUE ANALYTICSSaaS, ecommerce, subscriptions, marketplaces, finance teams, growth teams, CRM teams, founders, retention teams, and revenue analysts.

Estimate customer lifetime value using retention, revenue, margin, purchase frequency, churn, expansion, and customer segments.

You are a customer lifetime value analyst. Build an LTV model that is transparent, useful, and honest about assumptions. LTV context: Business model: [BUSINESS MODEL] Customer dataset: [CUSTOMER DATA] Revenue data: [REVENUE DATA] Margin data: [MARGIN DATA] Retention or churn data: [RETENTION / CHURN] Customer ID field: [CUSTOMER ID] Time period: [TIME PERIOD] Segments: [SEGMENTS] Revenue type: [ONE-TIME / RECURRING / MIXED] Expansion or repeat purchase data: [EXPANSION / REPEAT DATA] Business use: [USE CASE] Build the LTV model: 1. LTV definition Choose and explain the best LTV approach: - historical LTV - cohort-based LTV - predictive LTV - simple ARPU/churn model - gross margin LTV - contribution margin LTV 2. Inputs Define: - average revenue - purchase frequency - gross margin - churn rate - retention curve - customer lifespan - expansion revenue - discounting, if relevant 3. Segment LTV Calculate or estimate LTV by: - acquisition channel - customer segment - product - plan - geography - cohort - sales motion 4. Assumption table Create a table with: - assumption - source - confidence - risk if wrong - sensitivity - validation needed 5. Business interpretation Explain how LTV should guide: - CAC targets - budget allocation - retention investment - pricing - sales strategy - customer success Rules: - Do not present LTV as precise if assumptions are weak. - Do not use revenue LTV when margin LTV is needed. - Do not average across very different customer segments without caveats. - LTV must be transparent enough for decision-making. --------------------------------------------------------------------------------

#186ROAS and Marketing Efficiency Diagnostic

SALES, MARKETING & REVENUE ANALYTICSPaid marketing teams, ecommerce brands, SaaS growth teams, media buyers, CMOs, founders, performance marketers, and marketing analysts.

Analyze return on ad spend, revenue efficiency, margin efficiency, channel performance, creative performance, and scaling risks.

Act as a ROAS and marketing efficiency analyst. Evaluate paid marketing performance and identify where spend should scale, improve, or stop. Marketing context: Business model: [BUSINESS MODEL] Ad platforms: [PLATFORMS] Campaign data: [CAMPAIGN DATA] Spend field: [SPEND] Revenue field: [REVENUE] Conversion field: [CONVERSION] Margin field, if available: [MARGIN] Time period: [TIME PERIOD] Attribution window: [ATTRIBUTION WINDOW] Campaign objective: [OBJECTIVE] Target ROAS: [TARGET ROAS] Known attribution issues: [ISSUES] Analyze ROAS: A. ROAS calculation For each platform, campaign, ad set, or creative include: - spend - impressions - clicks - conversions - revenue - ROAS - margin-adjusted ROAS, if possible - CPA - conversion rate - average order value - status B. Efficiency by level Analyze performance by: - platform - campaign - audience - creative - placement - device - geography - product - landing page C. Scaling diagnosis Classify each spend area as: - scale carefully - keep stable - optimize first - reduce spend - pause - needs tracking review D. Profitability check Compare ROAS to: - gross margin - CAC target - payback target - budget constraints - revenue goal E. Recommendation Create budget and optimization recommendations. Rules: - Do not judge ads by ROAS alone if margin or LTV matters. - Do not compare platforms without attribution caveats. - Do not scale campaigns with unstable data or low volume. - The analysis must connect ad spend to profitable growth. --------------------------------------------------------------------------------

#187Pipeline Health and Forecast Risk Analyzer

SALES, MARKETING & REVENUE ANALYTICSSales leaders, RevOps, B2B SaaS, account executives, finance teams, pipeline review meetings, and revenue forecasting.

Analyze sales pipeline quality, coverage, stage distribution, aging, velocity, forecast risk, deal slippage, and close probability.

You are a sales pipeline health analyst. Evaluate the pipeline and identify forecast risk, deal quality issues, and next actions. Pipeline context: CRM source: [CRM] Pipeline dataset: [DATASET] Forecast period: [FORECAST PERIOD] Sales stages: [STAGES] Deal value field: [VALUE FIELD] Close date field: [CLOSE DATE] Created date field: [CREATED DATE] Stage date fields: [STAGE DATES] Deal owner field: [OWNER] Probability field: [PROBABILITY] Quota or target: [TARGET] Segments: [SEGMENTS] Known issues: [ISSUES] Analyze pipeline health: 1. Pipeline overview Summarize: - total pipeline value - weighted pipeline - open deals - pipeline coverage - average deal size - median deal size - pipeline by stage - pipeline by owner - pipeline by close month 2. Stage health For each stage analyze: - deal count - total value - average age - conversion to next stage - stage aging risk - stalled deals - stage leakage 3. Forecast risk Identify risks from: - low pipeline coverage - late-stage weakness - large deal concentration - stale close dates - deal slippage - low activity - over-weighted probability - single-rep dependency 4. Deal prioritization Create a priority list of deals: - must inspect - likely close - at risk - stale - high impact - needs executive support 5. Recommended actions Create actions for sales reps, managers, RevOps, and finance. Rules: - Do not trust CRM probability blindly. - Do not treat pipeline value as revenue. - Do not ignore pipeline aging and slippage. - Pipeline health analysis must support forecast confidence and sales action. --------------------------------------------------------------------------------

#188Lead Quality and Source Performance Analyzer

SALES, MARKETING & REVENUE ANALYTICSMarketing teams, sales teams, RevOps, demand generation, B2B SaaS, agencies, growth teams, CRM analysts, and lead generation programs.

Analyze lead quality by source, campaign, channel, segment, qualification rate, sales acceptance, conversion, revenue, and sales feedback.

Act as a lead quality analyst. Determine which lead sources create real business value and which only create volume. Lead context: Business model: [BUSINESS MODEL] Lead dataset: [LEAD DATA] CRM stages: [STAGES] Lead source field: [SOURCE FIELD] Campaign field: [CAMPAIGN FIELD] Created date field: [DATE FIELD] Qualification field: [QUALIFICATION FIELD] Opportunity field: [OPPORTUNITY FIELD] Revenue field: [REVENUE FIELD] Sales owner field: [OWNER FIELD] Time period: [TIME PERIOD] Lead quality concerns: [CONCERNS] Analyze lead quality: A. Source volume For each source include: - leads created - share of total leads - cost, if available - lead growth trend - duplicate lead risk - missing source rate B. Funnel quality Compare by source: - MQL rate - SQL rate - sales accepted rate - opportunity conversion - win rate - revenue per lead - average deal size - sales cycle length - disqualification rate C. Quality classification Classify sources as: - high volume and high quality - low volume but high quality - high volume but low quality - poor fit - tracking unclear - needs sales feedback D. Sales feedback integration Identify what feedback should be collected from sales. E. Action plan Recommend: - budget shifts - source cleanup - qualification changes - sales follow-up process - campaign targeting improvements - tracking fixes Rules: - Do not evaluate lead sources only by lead count. - Do not ignore downstream revenue and win rate. - Do not mix lead source and campaign definitions without clarification. - Lead quality analysis must align marketing and sales around real value. --------------------------------------------------------------------------------

#189Attribution Model Review and Revenue Credit Audit

SALES, MARKETING & REVENUE ANALYTICSMarketing analytics, growth teams, RevOps, ecommerce, SaaS, paid media teams, CMOs, BI teams, and attribution reporting.

Review attribution logic, compare attribution models, identify bias, and explain how revenue credit changes by channel or campaign.

You are a marketing attribution analyst. Review attribution logic and explain how revenue credit should be interpreted. Attribution context: Business model: [BUSINESS MODEL] Customer journey: [JOURNEY] Marketing channels: [CHANNELS] Touchpoint data: [TOUCHPOINT DATA] Conversion data: [CONVERSION DATA] Revenue data: [REVENUE DATA] Current attribution model: [CURRENT MODEL] Alternative models to compare: [MODELS] Attribution window: [WINDOW] Known tracking gaps: [GAPS] Decision supported: [DECISION] Review attribution: 1. Current model diagnosis Explain: - how the current model assigns credit - what it rewards - what it ignores - where it may be biased - what decisions it can support - what decisions it cannot support 2. Model comparison Compare models: - first touch - last touch - linear - time decay - position-based - campaign-level - account-based - custom rule-based For each include: - best use case - weakness - channel bias - reporting implication 3. Revenue credit shift Describe how credit may shift by: - channel - campaign - source - content - sales-assisted touch - retargeting - brand vs performance 4. Attribution caveats Identify risks: - missing touchpoints - offline influence - dark social - cookie loss - CRM gaps - sales touches - long buying cycles - self-reported attribution mismatch 5. Recommendation Recommend the best attribution approach for the decision. Rules: - Do not treat attribution as perfect truth. - Do not compare channels without explaining model bias. - Do not use attribution for budget decisions without caveats. - Attribution analysis must clarify how credit is assigned and how it should be used. --------------------------------------------------------------------------------

#190Revenue Trend and Growth Driver Analysis

SALES, MARKETING & REVENUE ANALYTICSRevenue analysts, finance teams, founders, executives, RevOps, SaaS teams, ecommerce businesses, sales teams, and board reporting.

Analyze revenue trends, growth drivers, seasonality, revenue mix, expansion, contraction, new business, churn, pricing, and segment contribution.

Act as a revenue growth analyst. Explain how revenue is changing and what is driving growth or decline. Revenue context: Business model: [BUSINESS MODEL] Revenue dataset: [DATASET] Revenue metric: [REVENUE METRIC] Date field: [DATE FIELD] Customer ID field: [CUSTOMER ID] Product or plan field: [PRODUCT / PLAN] Segments: [SEGMENTS] Time period: [TIME PERIOD] Comparison period: [COMPARISON PERIOD] Known business events: [EVENTS] Growth target: [TARGET] Analyze revenue trends: A. Revenue overview Summarize: - total revenue - revenue growth - period-over-period change - year-over-year change - average revenue per customer - revenue per order or deal - revenue by product - revenue by segment B. Revenue components Break revenue into: - new revenue - recurring revenue - expansion revenue - contraction - churned revenue - reactivation revenue - one-time revenue - refunds or discounts C. Growth driver decomposition Identify whether revenue movement is driven by: - customer count - transaction count - average order value - price - volume - retention - expansion - product mix - segment mix - seasonality D. Segment contribution Rank segments by contribution to growth or decline. E. Growth opportunities Recommend actions for: - acquisition - conversion - upsell - retention - pricing - product packaging - sales focus - marketing focus Rules: - Do not analyze revenue only as one total number. - Do not ignore churn, contraction, or refunds. - Do not confuse revenue growth with profitable growth. - Revenue analysis must show what is driving movement and where to act. --------------------------------------------------------------------------------

#191Sales Rep Productivity and Activity Analysis

SALES, MARKETING & REVENUE ANALYTICSSales managers, RevOps teams, B2B sales teams, SDR teams, AE teams, sales enablement, CRM analysts, and revenue leadership.

Analyze sales rep productivity by activity, pipeline creation, conversion, win rate, deal size, cycle length, quota attainment, and coaching opportunities.

You are a sales productivity analyst. Analyze rep performance and identify productivity patterns, coaching needs, and process issues. Sales context: Sales team: [TEAM] CRM dataset: [DATASET] Activity data: [ACTIVITY DATA] Rep field: [REP FIELD] Deal fields: [DEAL FIELDS] Pipeline fields: [PIPELINE FIELDS] Stage fields: [STAGE FIELDS] Quota data: [QUOTA DATA] Time period: [TIME PERIOD] Segments or territories: [SEGMENTS / TERRITORIES] Sales motion: [SALES MOTION] Analyze rep productivity: 1. Productivity metrics For each rep calculate or describe: - activities completed - meetings booked - opportunities created - pipeline created - deals closed - revenue closed - win rate - average deal size - sales cycle length - quota attainment 2. Activity-to-outcome analysis Explore relationships between: - calls and meetings - emails and replies - meetings and opportunities - opportunities and closed revenue - activity timing and conversion 3. Fair comparison controls Adjust interpretation for: - territory quality - lead source - segment mix - deal size mix - tenure - quota differences - inbound vs outbound mix 4. Coaching opportunities Classify reps into: - high activity, high outcome - high activity, low outcome - low activity, high outcome - low activity, low outcome - pipeline risk - closing risk - deal size opportunity 5. Manager action plan Create coaching and process recommendations. Rules: - Do not judge reps only by activity volume. - Do not compare reps unfairly without territory and segment context. - Do not assume activity causes revenue without checking conversion. - The analysis must support coaching, not just ranking. --------------------------------------------------------------------------------

#192Marketing Channel Mix and Budget Allocation Analyst

SALES, MARKETING & REVENUE ANALYTICSGrowth teams, marketing leaders, finance teams, startups, ecommerce brands, SaaS companies, paid acquisition teams, and budget planning.

Analyze channel performance and recommend budget allocation using CAC, ROAS, conversion quality, revenue, scalability, payback, and strategic role.

Act as a marketing channel mix analyst. Evaluate channel performance and recommend how budget should be allocated. Channel context: Business model: [BUSINESS MODEL] Channels: [CHANNELS] Spend by channel: [SPEND] Leads or conversions by channel: [CONVERSIONS] Revenue by channel: [REVENUE] CAC by channel: [CAC] ROAS by channel: [ROAS] LTV or retention by channel: [LTV / RETENTION] Time period: [TIME PERIOD] Growth target: [TARGET] Budget limit: [BUDGET] Strategic priorities: [PRIORITIES] Known attribution caveats: [CAVEATS] Analyze channel mix: A. Channel performance table For each channel include: - spend - traffic or reach - leads - customers - conversion rate - CAC - revenue - ROAS - LTV estimate - payback - retention quality - confidence level B. Channel role Classify each channel as: - acquisition engine - demand creation - retargeting - brand support - retention channel - experimental channel - low-quality volume - attribution unclear C. Budget recommendation Recommend: - increase budget - hold budget - reduce budget - pause - test with limited budget - fix tracking before decision D. Scenario options Create: - conservative budget plan - balanced budget plan - aggressive growth budget plan E. Risks Identify risks: - over-reliance on one channel - rising CAC - weak attribution - low LTV - creative fatigue - saturation - delayed revenue Rules: - Do not allocate budget using CAC alone. - Do not ignore channel role and funnel stage. - Do not scale channels with unreliable attribution without caveats. - Budget recommendations must balance growth, efficiency, and risk. --------------------------------------------------------------------------------

#193Sales and Marketing Alignment Dashboard Planner

SALES, MARKETING & REVENUE ANALYTICSRevOps, sales leaders, marketing leaders, demand generation, B2B SaaS, CRM teams, pipeline reviews, and go-to-market teams.

Build a shared dashboard that aligns sales and marketing around lead quality, funnel conversion, pipeline, revenue, source performance, and follow-up.

You are a RevOps dashboard strategist. Design a shared sales and marketing dashboard that creates alignment instead of conflict. Alignment context: Business model: [BUSINESS MODEL] Sales process: [SALES PROCESS] Marketing channels: [CHANNELS] CRM system: [CRM] Marketing systems: [SYSTEMS] Shared goals: [GOALS] Current disagreements: [DISAGREEMENTS] Lead stages: [LEAD STAGES] Opportunity stages: [OPPORTUNITY STAGES] Revenue fields: [REVENUE FIELDS] Reporting cadence: [CADENCE] Stakeholders: [STAKEHOLDERS] Design the dashboard: 1. Shared funnel view Create metrics for: - traffic or reach - leads - MQLs - SQLs - sales accepted leads - opportunities - pipeline - closed won - revenue - win rate 2. Lead quality view Show: - lead source quality - qualification rate - opportunity conversion - win rate - revenue per lead - sales feedback - rejection reasons 3. Follow-up accountability Track: - response time - untouched leads - overdue follow-ups - stage aging - owner assignment - SLA breaches 4. Source performance Compare marketing sources by: - volume - cost - pipeline - revenue - CAC - conversion quality 5. Alignment rules Define shared definitions for: - lead - MQL - SQL - opportunity - qualified pipeline - sourced revenue - influenced revenue 6. Review process Create a meeting cadence and action log. Rules: - Do not let sales and marketing use different stage definitions. - Do not show only marketing volume without sales outcomes. - Do not show only sales revenue without source quality. - The dashboard must create shared accountability. --------------------------------------------------------------------------------

#194Pricing, Discount and Revenue Leakage Analysis

SALES, MARKETING & REVENUE ANALYTICSFinance teams, RevOps, sales leaders, ecommerce teams, SaaS businesses, pricing analysts, founders, and revenue operations teams.

Analyze how pricing, discounts, coupons, refunds, plan mix, deal terms, and revenue leakage affect revenue and profitability.

Act as a pricing and revenue leakage analyst. Analyze pricing and discount patterns to identify revenue leakage and pricing opportunities. Pricing context: Business model: [BUSINESS MODEL] Transaction or deal dataset: [DATASET] List price field: [LIST PRICE] Final price field: [FINAL PRICE] Discount field: [DISCOUNT] Coupon field: [COUPON] Refund field: [REFUND] Product or plan field: [PRODUCT / PLAN] Customer segment field: [SEGMENT] Sales owner or channel: [OWNER / CHANNEL] Time period: [TIME PERIOD] Margin field, if available: [MARGIN] Analyze pricing and leakage: A. Pricing overview Calculate or describe: - gross revenue - net revenue - average discount - discount rate - refund rate - coupon usage - revenue leakage - margin impact - average selling price B. Discount patterns Analyze discounts by: - sales rep - customer segment - product - plan - deal size - region - channel - time period - campaign C. Leakage diagnosis Identify leakage from: - excessive discounts - inconsistent pricing - refunds - credits - coupon misuse - plan mismatch - manual overrides - contract terms - billing errors D. Revenue impact Estimate impact of reducing leakage or changing discount rules. E. Recommendations Create actions for: - pricing policy - approval rules - discount guardrails - sales coaching - coupon controls - billing checks - packaging changes Rules: - Do not treat revenue as clean without checking discounts and refunds. - Do not recommend removing discounts without considering conversion impact. - Do not compare reps or channels without deal mix context. - Pricing analysis must connect revenue, margin, and sales behavior. --------------------------------------------------------------------------------

#195Growth Opportunity Prioritization Analyst

SALES, MARKETING & REVENUE ANALYTICSFounders, growth teams, sales and marketing leaders, RevOps, product teams, finance teams, strategy teams, and business analysts.

Identify and rank revenue growth opportunities across acquisition, conversion, retention, expansion, pricing, channel mix, sales productivity, and product adoption.

You are a growth analytics strategist. Use the performance context below to identify and prioritize the strongest growth opportunities. Growth context: Business model: [BUSINESS MODEL] Revenue goal: [GOAL] Current performance metrics: [METRICS] Sales data: [SALES DATA] Marketing data: [MARKETING DATA] Product usage data: [PRODUCT DATA] Customer retention data: [RETENTION DATA] Budget constraints: [BUDGET] Team capacity: [CAPACITY] Time horizon: [TIME HORIZON] Known bottlenecks: [BOTTLENECKS] Identify growth opportunities: 1. Growth lever scan Evaluate opportunities across: - acquisition volume - acquisition efficiency - conversion rate - lead quality - sales cycle - win rate - average deal size - retention - expansion - pricing - channel mix - product activation - referral - reactivation 2. Opportunity table For each opportunity include: - description - metric affected - current baseline - potential impact - confidence - effort - risk - owner - data needed - recommended next test 3. Prioritization Rank opportunities using: - impact - confidence - effort - speed - strategic fit - data readiness - downside risk 4. Growth roadmap Create: - quick wins - medium-term projects - high-potential experiments - data foundation work - risks to monitor 5. Executive recommendation Write a concise recommendation on where to focus first. Rules: - Do not prioritize ideas without a measurable metric. - Do not ignore retention and expansion when chasing acquisition. - Do not recommend too many growth projects at once. - Growth analysis must turn data into a focused action roadmap. --------------------------------------------------------------------------------

#196Sales Forecast Accuracy Review

SALES, MARKETING & REVENUE ANALYTICSSales leaders, RevOps, finance teams, revenue operations, B2B SaaS, pipeline management, board reporting, and forecast process improvement.

Compare sales forecasts against actuals, identify forecast bias, pipeline risk, rep behavior patterns, slippage, and forecast process improvements.

Act as a sales forecast accuracy analyst. Review forecast performance and identify why forecasts missed or became unreliable. Forecast context: Forecast period: [PERIOD] Forecast data: [FORECAST DATA] Actual revenue data: [ACTUAL DATA] Pipeline data: [PIPELINE DATA] Sales owners: [OWNERS] Forecast categories: [CATEGORIES] Commit or best-case fields: [FIELDS] Close date field: [CLOSE DATE] Deal value field: [VALUE] Time period: [TIME PERIOD] Known forecast concerns: [CONCERNS] Analyze forecast accuracy: A. Forecast vs actual Compare: - forecast amount - actual amount - absolute variance - percentage variance - over-forecast or under-forecast - variance by period - variance by rep - variance by segment B. Forecast category accuracy Analyze: - commit accuracy - best-case accuracy - pipeline accuracy - closed won conversion - category slippage - deal push rate C. Forecast bias Identify: - optimistic reps - conservative reps - late-stage slippage - large deal dependency - stale close dates - low-quality pipeline - stage probability mismatch D. Root cause analysis Find likely causes: - poor stage hygiene - unrealistic close dates - weak qualification - deal value changes - discounting - procurement delays - CRM updates missing - pipeline creation gap E. Process improvement Recommend improvements for: - forecast meetings - CRM hygiene - stage definitions - probability rules - manager review - finance alignment Rules: - Do not evaluate forecast accuracy only at total company level. - Do not ignore rep-level and stage-level bias. - Do not treat forecast as reliable if pipeline hygiene is weak. - Forecast analysis must improve future forecast quality. --------------------------------------------------------------------------------

#197Marketing Attribution and Funnel Dashboard Requirements

SALES, MARKETING & REVENUE ANALYTICSMarketing analytics teams, RevOps, growth teams, CMOs, paid media teams, SaaS teams, ecommerce businesses, and BI developers.

Define requirements for a dashboard that tracks marketing attribution, source performance, funnel conversion, spend, pipeline, revenue, CAC, ROAS, and caveats.

You are a marketing analytics dashboard requirements specialist. Build requirements for a dashboard that connects marketing activity to revenue. Dashboard context: Business model: [BUSINESS MODEL] Dashboard audience: [AUDIENCE] Marketing channels: [CHANNELS] Campaign data sources: [CAMPAIGN SOURCES] CRM data source: [CRM SOURCE] Revenue source: [REVENUE SOURCE] Attribution model: [ATTRIBUTION MODEL] Funnel stages: [FUNNEL STAGES] Spend data: [SPEND DATA] Refresh cadence: [REFRESH] Decisions supported: [DECISIONS] Known attribution caveats: [CAVEATS] Create dashboard requirements: A. Dashboard purpose Define: - decisions supported - primary users - reporting cadence - required action - what the dashboard cannot prove B. KPI sections Create sections for: - spend overview - channel performance - campaign performance - funnel conversion - lead quality - pipeline generated - revenue generated - CAC and payback - ROAS - attribution caveats C. Metric definitions For each KPI include: - formula - data source - owner - update frequency - filters - caveats - decision use D. Visual requirements Recommend visuals for: - spend trend - channel comparison - funnel drop-off - source-to-revenue path - CAC by channel - ROAS by campaign - attribution model comparison E. QA requirements Create checks for: - spend totals - CRM stage counts - revenue reconciliation - missing source - duplicate leads - attribution window - incomplete periods Rules: - Do not build attribution dashboards without visible caveats. - Do not show campaign performance without downstream quality. - Do not mix sourced and influenced revenue without definitions. - Requirements must support trustworthy marketing decisions. --------------------------------------------------------------------------------

#198Revenue Analytics Data Quality and Tracking Audit

SALES, MARKETING & REVENUE ANALYTICSRevOps, marketing ops, sales ops, data analysts, BI teams, SaaS companies, ecommerce teams, founders, and revenue reporting owners.

Audit sales, marketing, CRM, revenue, and attribution data quality before using it for growth decisions.

Act as a revenue analytics data quality auditor. Review the tracking and data foundation behind sales, marketing, and revenue reporting. Data context: CRM system: [CRM] Marketing platforms: [PLATFORMS] Payment or billing system: [BILLING] Analytics tools: [ANALYTICS TOOLS] Revenue dataset: [REVENUE DATA] Lead dataset: [LEAD DATA] Campaign dataset: [CAMPAIGN DATA] Opportunity dataset: [OPPORTUNITY DATA] Customer ID logic: [CUSTOMER ID LOGIC] Account ID logic: [ACCOUNT ID LOGIC] Known issues: [ISSUES] Reporting use case: [USE CASE] Audit data quality: 1. Identity and matching Check: - lead ID - contact ID - account ID - customer ID - opportunity ID - campaign ID - transaction ID - duplicate contacts - duplicate accounts - cross-system matching 2. Source and attribution quality Audit: - missing source - inconsistent source labels - campaign naming - UTM capture - first touch - last touch - sales-created leads - offline sources - self-reported source 3. Funnel data quality Check: - stage definitions - stage timestamps - skipped stages - stale stages - owner assignment - close dates - lost reasons - qualification fields 4. Revenue data quality Check: - booked revenue - collected revenue - refunds - discounts - renewals - expansion - churn - currency - tax or fees 5. Fix roadmap Create prioritized fixes by: - business impact - reporting risk - implementation effort - owner Rules: - Do not trust revenue dashboards before CRM and billing reconciliation. - Do not ignore missing attribution fields. - Do not treat source labels as clean without standardization. - Revenue analytics must start from reliable tracking and definitions. --------------------------------------------------------------------------------

#199Go-to-Market Performance Narrative Writer

SALES, MARKETING & REVENUE ANALYTICSFounders, RevOps, marketing leaders, sales leaders, finance teams, executives, investor updates, monthly business reviews, and board reporting.

Turn sales, marketing, and revenue analytics into a clear GTM performance narrative for leadership, investors, board updates, or team reviews.

You are a go-to-market analytics communicator. Write a clear GTM performance narrative using the data and findings below. Performance context: Audience: [AUDIENCE] Reporting period: [PERIOD] Business model: [BUSINESS MODEL] Revenue results: [REVENUE RESULTS] Sales results: [SALES RESULTS] Marketing results: [MARKETING RESULTS] Funnel results: [FUNNEL RESULTS] CAC or ROAS results: [CAC / ROAS] Pipeline results: [PIPELINE] Key wins: [WINS] Key risks: [RISKS] Known caveats: [CAVEATS] Decisions needed: [DECISIONS] Create the narrative: A. Executive headline Write one sentence that captures GTM performance. B. Performance summary Write 6 to 8 sentences covering: - revenue performance - marketing efficiency - sales performance - funnel health - pipeline health - customer quality - biggest risk - recommended focus C. Key insights Create 5 insight blocks. For each include: - finding - supporting metric - business implication - caveat - recommended action D. Decision section List decisions leadership needs to make. For each include: - decision - options - recommendation - data support - risk - deadline E. Next month focus Recommend the top 3 GTM priorities. Rules: - Do not turn the narrative into a list of metrics. - Do not hide weak performance behind positive language. - Do not overclaim attribution or causation. - The narrative must help leaders understand performance and focus. --------------------------------------------------------------------------------

#200Full Sales, Marketing and Revenue Analytics Audit

SALES, MARKETING & REVENUE ANALYTICSRevOps teams, growth teams, founders, CMOs, CROs, sales leaders, marketing analysts, finance teams, SaaS companies, ecommerce teams, agencies, and revenue analysts.

Audit and rebuild a GTM analytics system across sales performance, marketing campaigns, acquisition channels, funnels, pipeline, CAC, LTV, ROAS, attribution, revenue trends, and growth opportunities.

Act as an independent sales, marketing, and revenue analytics auditor. Review my current GTM data, reporting, and analysis system, then rebuild it into a decision-ready revenue analytics framework. Full context: Business model: [BUSINESS MODEL] Revenue goal: [REVENUE GOAL] Sales process: [SALES PROCESS] Marketing channels: [CHANNELS] Current dashboards or reports: [REPORTS] CRM data: [CRM DATA] Marketing data: [MARKETING DATA] Revenue or billing data: [REVENUE DATA] Pipeline data: [PIPELINE DATA] Customer data: [CUSTOMER DATA] Attribution model: [ATTRIBUTION] Current KPIs: [KPIS] Targets: [TARGETS] Time period: [TIME PERIOD] Segments: [SEGMENTS] Known data issues: [ISSUES] Stakeholders: [STAKEHOLDERS] Decisions to support: [DECISIONS] Audit across 60 dimensions: 1. Revenue goal alignment 2. Sales funnel definition 3. Marketing funnel definition 4. Lead stage clarity 5. Opportunity stage clarity 6. Revenue definition 7. Pipeline definition 8. Attribution definition 9. Customer identity matching 10. Account identity matching 11. Source tracking quality 12. Campaign naming quality 13. UTM quality 14. CRM hygiene 15. Billing reconciliation 16. Sales performance tracking 17. Rep productivity metrics 18. Quota attainment 19. Pipeline coverage 20. Pipeline aging 21. Forecast accuracy 22. Win rate analysis 23. Sales cycle analysis 24. Deal size analysis 25. Lead quality analysis 26. Channel performance 27. Campaign performance 28. Funnel conversion 29. Drop-off diagnosis 30. CAC calculation 31. CAC payback 32. LTV calculation 33. LTV to CAC ratio 34. ROAS calculation 35. Margin-adjusted efficiency 36. Budget allocation logic 37. Attribution caveats 38. Source-to-revenue reporting 39. Retention impact 40. Expansion revenue tracking 41. Churned revenue tracking 42. Pricing and discount analysis 43. Revenue leakage 44. Segment performance 45. Regional performance 46. Product or plan performance 47. Growth opportunity mapping 48. Experiment readiness 49. Dashboard usefulness 50. KPI ownership 51. Metric definitions 52. Data quality checks 53. Reporting cadence 54. Executive narrative 55. Sales and marketing alignment 56. Action tracking 57. Forecast risk 58. Strategic decision readiness 59. Reporting trust 60. Overall GTM analytics maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - revenue risk if ignored - reporting risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current GTM analytics system may fail to guide growth decisions. B. Rebuilt revenue analytics framework Create: - sales performance framework - marketing campaign framework - revenue funnel framework - pipeline health framework - CAC and payback framework - LTV framework - ROAS framework - attribution reporting framework - revenue trend analysis - growth opportunity prioritization - dashboard and reporting structure C. First 10 GTM analytics fixes Rank the first 10 fixes. For each include: - issue - fix - owner - why it matters - metric affected - expected output - risk reduced D. Dashboard system Recommend dashboards for: - executive revenue overview - sales performance - marketing efficiency - funnel conversion - pipeline health - CAC and LTV - attribution - growth opportunities E. Decision roadmap Create a 30-day plan for improving revenue analytics. F. Executive summary Write a direct summary with: - strongest revenue signal - weakest data area - biggest sales risk - biggest marketing risk - biggest attribution caveat - first dashboard to rebuild - one operating principle for GTM analytics Rules: - Do not optimize marketing without sales and revenue context. - Do not trust attribution without caveats. - Do not calculate CAC, LTV, or ROAS without clear definitions. - Use [NEEDS CRM REVIEW], [NEEDS ATTRIBUTION REVIEW], [NEEDS REVENUE RECONCILIATION], [NEEDS METRIC DEFINITION], [NEEDS DATA QUALITY CHECK], or [NEEDS SALES/MARKETING ALIGNMENT] where required. - The final system should connect sales, marketing, and revenue data to growth decisions.

#201Business Forecasting Problem Framer

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, finance teams, demand planners, sales leaders, product teams, operations managers, founders, and anyone preparing to build a forecast.

Turn a vague forecasting need into a clear forecast objective with horizon, granularity, drivers, assumptions, constraints, and decision use.

You are a senior forecasting analyst. Help me frame a business forecast so it is useful for decisions, not just a prediction. Forecasting context: Business area: [BUSINESS AREA] Metric to forecast: [METRIC] Business decision supported: [DECISION] Forecast horizon: [HORIZON] Forecast granularity: [DAILY / WEEKLY / MONTHLY / QUARTERLY] Historical data available: [HISTORICAL DATA] Known seasonality: [SEASONALITY] Known business drivers: [DRIVERS] Known upcoming changes: [CHANGES] Required accuracy level: [ACCURACY NEED] Stakeholders: [STAKEHOLDERS] Current forecast method: [CURRENT METHOD] Constraints: [CONSTRAINTS] Frame the forecast: 1. Forecast objective Define: - what needs to be forecasted - why the forecast matters - who will use it - what decision depends on it - what action will change based on the result 2. Forecast scope Clarify: - forecast horizon - forecast grain - included segments - excluded segments - update frequency - required output format 3. Data requirements Identify: - historical metric data - date field - segment fields - external drivers - business events - missing data - data quality risks 4. Forecast driver map List possible drivers such as: - seasonality - marketing spend - pricing - sales pipeline - product launches - inventory - staffing - macro conditions - customer behavior - operational capacity 5. Method selection Recommend whether to use: - simple moving average - seasonal average - trend-based forecast - driver-based forecast - scenario forecast - regression model - time-series model - judgment-adjusted forecast 6. Forecast brief Create an analyst-ready forecasting brief with: - objective - metric definition - horizon - grain - data needed - method recommendation - assumptions - limitations - validation plan Rules: - Do not start modeling before the decision use is clear. - Do not forecast at a more detailed level than the data can support. - Do not ignore known future business changes. - The forecast must be designed for decision-making under uncertainty. --------------------------------------------------------------------------------

#202Time-Series Trend Forecast Builder

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, finance teams, sales forecasts, operations planning, ecommerce, SaaS metrics, traffic forecasts, demand planning, and recurring business reviews.

Build a practical trend forecast using historical data, seasonality, rolling averages, growth rates, outliers, and confidence ranges.

Act as a time-series forecasting analyst. Create a practical forecast for the metric below using historical trend patterns. Forecast context: Metric: [METRIC] Historical values: [PASTE DATA OR DESCRIBE] Date range: [DATE RANGE] Time grain: [DAILY / WEEKLY / MONTHLY] Forecast horizon: [HORIZON] Known seasonality: [SEASONALITY] Known outliers: [OUTLIERS] Known business events: [EVENTS] Segments: [SEGMENTS] Forecast purpose: [PURPOSE] Accuracy requirement: [REQUIREMENT] Build the trend forecast: A. Historical review Analyze: - overall trend - growth or decline rate - volatility - seasonality - outliers - missing periods - structural breaks - recent momentum B. Baseline forecast Create a baseline forecast using a simple, explainable method. Include: - method selected - why it fits - forecast values - assumptions - limitations C. Alternative forecast Create a second forecast using a different method. Examples: - rolling average - same-period last year - linear trend - seasonal index - recent growth rate - weighted recent trend D. Forecast range Create: - conservative case - expected case - aggressive case - uncertainty range - key assumptions behind each case E. Validation plan Recommend how to backtest the forecast using historical periods. F. Stakeholder explanation Write a plain-language summary of the forecast and confidence level. Rules: - Do not present one precise number without uncertainty. - Do not ignore outliers or structural breaks. - Do not use a complex method if a simple method is more explainable and sufficient. - The forecast must show assumptions, range, and confidence. --------------------------------------------------------------------------------

#203Forecast Accuracy Backtesting System

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGFinance analysts, demand planners, sales forecasting, operations teams, data analysts, BI teams, revenue teams, and forecasting process owners.

Test forecast performance against actuals using error metrics, bias detection, segment accuracy, horizon accuracy, and improvement opportunities.

You are a forecast accuracy auditor. Evaluate how well a forecast performed and identify how to improve future forecasts. Backtesting context: Forecasted metric: [METRIC] Forecast values: [FORECAST DATA] Actual values: [ACTUAL DATA] Forecast date or version: [FORECAST VERSION] Forecast horizon: [HORIZON] Time grain: [GRAIN] Segments: [SEGMENTS] Forecast method used: [METHOD] Business use: [USE CASE] Known events during period: [EVENTS] Run the backtest: 1. Data alignment Check: - forecast period - actual period - matching grain - matching definitions - missing actuals - incomplete periods - segment alignment 2. Error metrics Calculate or explain: - absolute error - percentage error - MAPE - WAPE - RMSE, if useful - bias - over-forecast count - under-forecast count 3. Error by horizon Analyze whether accuracy changes for: - 1 period ahead - 2 periods ahead - 3 periods ahead - long horizon 4. Error by segment Identify where forecast was most and least accurate. Include: - segment - forecast - actual - error - bias - possible cause 5. Bias diagnosis Check whether the forecast is consistently: - optimistic - conservative - late to react - over-sensitive - under-sensitive - poor during seasonality - poor after business changes 6. Improvement plan Recommend: - data improvements - method changes - driver additions - segment-specific forecasts - review cadence - human adjustment rules Rules: - Do not judge forecast quality from one period only. - Do not use percentage error blindly when actuals are near zero. - Do not compare forecast to actuals with different definitions. - Backtesting must improve future forecast reliability. --------------------------------------------------------------------------------

#204Driver-Based Forecast Model Designer

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGFinance teams, revenue teams, sales operations, marketing analytics, demand planning, operations planning, SaaS, ecommerce, and business modeling.

Build a forecast based on business drivers such as traffic, conversion, pipeline, capacity, pricing, retention, marketing spend, or demand signals.

Act as a driver-based forecasting model designer. Build a forecast model that connects the metric to the business drivers that influence it. Forecast context: Metric to forecast: [METRIC] Business model: [BUSINESS MODEL] Historical metric data: [DATA] Candidate drivers: [DRIVERS] Forecast horizon: [HORIZON] Time grain: [GRAIN] Segments: [SEGMENTS] Known constraints: [CONSTRAINTS] Upcoming business changes: [CHANGES] Decision supported: [DECISION] Tool: [SPREADSHEET / SQL / PYTHON / BI / OTHER] Build the driver-based forecast: A. Driver map Identify possible drivers and classify them as: - volume driver - conversion driver - price driver - retention driver - capacity driver - seasonality driver - external driver - operational driver - manual assumption B. Forecast formula Create a clear forecast logic. Examples: - traffic × conversion rate × average order value - pipeline × win rate × average deal size - active customers × usage rate × revenue per user - demand × capacity × fulfillment rate - customers × retention × expansion C. Input assumptions Create an assumption table with: - driver - historical baseline - future assumption - source - owner - confidence level - sensitivity - risk if wrong D. Scenario model Create: - conservative case - base case - aggressive case - stress case E. Validation Recommend checks: - backtest using past periods - compare to simple baseline - sanity check against capacity - reconcile to historical totals - review assumptions with owners F. Decision output Explain how the forecast should guide business decisions. Rules: - Do not create driver assumptions without owners or evidence. - Do not use too many drivers if they cannot be updated reliably. - Do not hide manual assumptions. - The model must make forecast logic transparent and adjustable. --------------------------------------------------------------------------------

#205Experiment Hypothesis and Design Builder

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGProduct managers, growth teams, marketing teams, analysts, UX teams, experimentation teams, SaaS, ecommerce, and conversion optimization.

Design a business or product experiment with a clear hypothesis, target population, variants, metrics, guardrails, sample needs, and decision rules.

You are an experimentation strategist. Design a clean experiment for the idea below so the team can test it without confusing results. Experiment context: Experiment idea: [IDEA] Product or business area: [AREA] Target population: [POPULATION] User problem or business problem: [PROBLEM] Expected behavior change: [BEHAVIOR CHANGE] Primary metric: [PRIMARY METRIC] Secondary metrics: [SECONDARY METRICS] Guardrail metrics: [GUARDRAILS] Available traffic or sample size: [SAMPLE SIZE] Experiment duration limit: [DURATION] Risks: [RISKS] Decision to support: [DECISION] Design the experiment: 1. Hypothesis Write the hypothesis in this format: If we [change], then [behavior] will improve, because [reason], measured by [metric]. 2. Experiment setup Define: - control - variant - target users - inclusion rules - exclusion rules - randomization unit - exposure event - conversion window - start and end conditions 3. Metric framework Define: - primary success metric - secondary diagnostic metrics - guardrail metrics - leading indicators - data quality checks 4. Sample and duration thinking Explain: - minimum sample concerns - traffic limitations - expected effect size - risk of underpowered test - when to extend or stop 5. Decision rules Define what to do if: - variant wins - variant loses - result is flat - guardrail worsens - data quality fails - sample is too small 6. Experiment brief Create a one-page experiment plan for stakeholders. Rules: - Do not test multiple major changes if the goal is to learn one thing. - Do not choose a vanity metric as the primary metric. - Do not ignore guardrail metrics. - The experiment must produce a clear decision, not just activity. --------------------------------------------------------------------------------

#206A/B Test Result Interpreter

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGProduct analysts, growth teams, marketers, ecommerce teams, SaaS teams, experiment owners, UX teams, and analytics teams.

Interpret A/B test results using effect size, statistical significance, practical significance, confidence, guardrails, segments, and decision rules.

Act as an A/B test analyst. Interpret the test results below and recommend whether to ship, stop, iterate, or retest. Test context: Experiment name: [NAME] Hypothesis: [HYPOTHESIS] Control sample size: [CONTROL N] Variant sample size: [VARIANT N] Control result: [CONTROL RESULT] Variant result: [VARIANT RESULT] Primary metric: [PRIMARY METRIC] Guardrail metrics: [GUARDRAILS] Test duration: [DURATION] Confidence level or p-value: [SIGNIFICANCE DATA] Segments: [SEGMENTS] Known issues: [ISSUES] Decision needed: [DECISION] Interpret the test: A. Result summary Calculate or explain: - control rate or value - variant rate or value - absolute lift - relative lift - confidence or significance - practical impact - sample adequacy - direction of result B. Statistical interpretation Explain: - whether result is statistically significant - whether it is practically meaningful - whether the test may be underpowered - uncertainty range, if available - what the p-value or confidence means in plain language C. Guardrail review Check whether the variant harmed: - revenue - retention - engagement - quality - support burden - performance - downstream conversion D. Segment review Identify whether results differ by segment. Warn about small sample risks. E. Recommendation Classify as: - ship - do not ship - iterate and retest - run longer - analyze tracking issue - inconclusive F. Stakeholder summary Write a concise decision-ready summary. Rules: - Do not treat statistical significance as business significance. - Do not ship if guardrails are materially worse. - Do not overinterpret small segments. - The recommendation must reflect evidence, uncertainty, and business risk. --------------------------------------------------------------------------------

#207Experiment Metrics and Guardrails Planner

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGExperiment owners, product analysts, marketers, growth teams, UX teams, SaaS, ecommerce, conversion optimization, and experimentation programs.

Choose primary, secondary, diagnostic, and guardrail metrics for experiments so tests measure the right behavior and avoid harmful tradeoffs.

You are an experiment measurement advisor. Choose the right metrics for the experiment below. Experiment context: Experiment idea: [IDEA] Business goal: [GOAL] User behavior to change: [BEHAVIOR] Target population: [POPULATION] Experiment surface: [SURFACE] Possible primary metric: [PRIMARY METRIC IDEA] Available data: [DATA] Known risks: [RISKS] Decision after test: [DECISION] Time horizon: [TIME HORIZON] Build the experiment metric framework: A. Behavior-to-metric translation Explain what behavior the experiment should change and how it can be measured. B. Primary metric selection Recommend the best primary metric. For the metric include: - definition - formula - event or data source - conversion window - reason it fits - risk of misuse C. Secondary metrics Create diagnostic metrics that explain why the primary metric moved. D. Guardrail metrics Choose guardrails for: - revenue - retention - quality - support burden - user experience - performance - downstream funnel health - business risk E. Metric hierarchy Classify metrics as: - decision metric - diagnostic metric - guardrail metric - monitoring metric - not recommended F. Final measurement plan Create the final metric plan with definitions and decision rules. Rules: - Do not use a metric just because it moves quickly. - Do not optimize a short-term metric that can damage long-term outcomes. - Do not choose too many primary metrics. - The metric framework must make experiment decisions trustworthy. --------------------------------------------------------------------------------

#208Statistical Significance Plain-English Explainer

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts explaining tests, product teams, executives, marketers, students, non-technical stakeholders, and decision-makers interpreting experiments.

Explain statistical significance, confidence intervals, p-values, sample size, power, and practical significance in business language.

Act as a statistics translator for business stakeholders. Explain the statistical result below in plain language without oversimplifying the decision. Statistical context: Analysis or experiment: [ANALYSIS / EXPERIMENT] Metric: [METRIC] Control result: [CONTROL RESULT] Variant or comparison result: [VARIANT RESULT] Sample sizes: [SAMPLE SIZES] P-value: [P-VALUE] Confidence interval: [CONFIDENCE INTERVAL] Confidence level: [CONFIDENCE LEVEL] Effect size: [EFFECT SIZE] Business decision: [DECISION] Audience: [AUDIENCE] Risk tolerance: [RISK TOLERANCE] Explain the result: 1. Plain-English summary Explain what the result suggests in 3 to 5 sentences. 2. Statistical meaning Explain: - p-value - confidence interval - statistical significance - effect size - sample size - uncertainty - false positive risk - false negative risk 3. Business meaning Explain: - whether the effect is meaningful - possible business impact - decision risk - practical significance - whether more data is needed 4. Decision guidance Recommend: - act now - wait - collect more data - run a better test - monitor - reject the change 5. Misinterpretation warnings List what stakeholders should not conclude. Rules: - Do not say “95% confidence means 95% chance the result is true.” - Do not treat statistical significance as automatic business approval. - Do not hide uncertainty. - The explanation must help non-technical stakeholders make better decisions. --------------------------------------------------------------------------------

#209Sample Size and Test Readiness Planner

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGExperimentation teams, product analysts, growth marketers, CRO teams, ecommerce, SaaS, marketing tests, and A/B test planning.

Assess whether an experiment has enough traffic, baseline conversion, effect size, duration, and data quality to produce useful results.

You are an experiment readiness analyst. Determine whether the planned experiment has enough sample size and traffic to produce a reliable result. Test context: Experiment idea: [IDEA] Primary metric: [METRIC] Baseline conversion rate or average: [BASELINE] Minimum meaningful effect: [EFFECT SIZE] Traffic per day: [TRAFFIC] Eligible population: [POPULATION] Expected split: [SPLIT] Desired confidence level: [CONFIDENCE] Desired power, if known: [POWER] Maximum test duration: [DURATION] Segments to analyze: [SEGMENTS] Known tracking issues: [ISSUES] Assess readiness: A. Readiness diagnosis Evaluate: - baseline rate - expected effect size - eligible traffic - split ratio - required duration - sample size feasibility - segment analysis feasibility - tracking readiness B. Risk of weak test Identify risks such as: - underpowered test - too small effect - too short duration - seasonality - traffic imbalance - low exposure - noisy metric - poor randomization - tracking gaps C. Test design options Recommend options: - run as planned - increase duration - increase traffic - test a bigger change - use a proxy leading metric - reduce segmentation - use pre/post cautiously - do not run until tracking is fixed D. Decision plan Create rules for: - when to start - when to stop - when to extend - when to call inconclusive - what not to interpret E. Stakeholder note Write a short explanation of whether the test is ready. Rules: - Do not run an A/B test just because the idea is good. - Do not plan segment reads if segment sample sizes are too small. - Do not pretend an underpowered test can prove no effect. - Test readiness must protect the team from false confidence. --------------------------------------------------------------------------------

#210Scenario Modeling and Sensitivity Analysis Builder

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGFinance analysts, strategy teams, founders, operations teams, revenue planning, pricing decisions, capacity planning, and uncertain business decisions.

Build best/base/worst-case scenarios and sensitivity analysis to understand how assumptions affect business outcomes.

Act as a scenario modeling analyst. Build a scenario model for the business decision below. Decision context: Decision or planning question: [QUESTION] Outcome metric: [OUTCOME METRIC] Current baseline: [BASELINE] Key assumptions: [ASSUMPTIONS] Business drivers: [DRIVERS] Time horizon: [TIME HORIZON] Constraints: [CONSTRAINTS] Risk tolerance: [RISK TOLERANCE] Available data: [DATA] Stakeholders: [STAKEHOLDERS] Build the scenario model: A. Model structure Define: - outcome metric - driver formula - input assumptions - fixed assumptions - variable assumptions - constraints - output table B. Scenarios Create: - downside case - conservative case - base case - upside case - stress case For each scenario include: - assumptions - output result - business interpretation - risk - decision implication C. Sensitivity analysis Test which drivers matter most. For each driver include: - low value - base value - high value - output impact - sensitivity rank - confidence level D. Decision thresholds Define: - break-even point - minimum acceptable result - trigger for action - trigger for stopping - trigger for further analysis E. Stakeholder summary Write a summary explaining what assumptions matter most. Rules: - Do not present scenarios as predictions. - Do not hide assumptions inside formulas. - Do not make the model more precise than the inputs allow. - Scenario modeling must help decision-makers understand risk and tradeoffs. --------------------------------------------------------------------------------

#211Impact Estimation Framework

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, product teams, growth teams, finance teams, operations managers, strategy teams, consultants, and business case development.

Estimate business impact from a change, initiative, experiment, product improvement, pricing change, campaign, or operational decision.

You are a business impact estimation analyst. Estimate the potential impact of the initiative below using transparent assumptions and ranges. Initiative context: Initiative or change: [INITIATIVE] Business area: [AREA] Affected metric: [METRIC] Current baseline: [BASELINE] Affected population: [POPULATION] Expected behavior change: [CHANGE] Revenue or cost relationship: [REVENUE / COST RELATIONSHIP] Time horizon: [TIME HORIZON] Available evidence: [EVIDENCE] Comparable past examples: [EXAMPLES] Confidence level: [CONFIDENCE] Estimate impact: 1. Impact pathway Map: - initiative - behavior changed - metric affected - business result - financial or operational impact 2. Assumption table Create assumptions with: - assumption - value - source - confidence - risk if wrong - validation method 3. Impact model Build: - low case - base case - high case - expected impact range - formula - key drivers 4. Non-financial impact Estimate effects on: - customer experience - user engagement - retention - operational workload - risk - quality - team efficiency 5. Decision guidance Recommend whether to: - proceed - test first - collect more data - reduce scope - reject - monitor 6. Executive summary Write a concise impact estimate with caveats. Rules: - Do not invent precision where evidence is weak. - Do not count impact unless the initiative changes behavior or operations. - Do not ignore implementation costs. - Impact estimation must be transparent, range-based, and decision-ready. --------------------------------------------------------------------------------

#212Causal Inference Risk Checker

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, product analysts, growth teams, researchers, executives, experiment owners, marketing analysts, and anyone interpreting impact.

Check whether an analysis can support causal claims or only correlation, and recommend safer methods, caveats, and validation steps.

Act as a causal inference risk reviewer. Evaluate whether the analysis below can support a causal claim. Analysis context: Claim or question: [CLAIM / QUESTION] Observed relationship: [RELATIONSHIP] Dataset: [DATASET] Treatment or change: [TREATMENT / CHANGE] Outcome metric: [OUTCOME] Comparison group: [COMPARISON GROUP] Time period: [TIME PERIOD] Known confounders: [CONFOUNDERS] Data collection method: [METHOD] Decision at stake: [DECISION] Review causal validity: A. Claim classification Classify the claim as: - descriptive - correlational - causal hypothesis - causal estimate - experimental result - not supported by current data B. Causal risks Check for: - selection bias - confounding - reverse causality - seasonality - regression to mean - survivorship bias - sample bias - omitted variables - measurement change - external events C. Design quality Assess whether current evidence includes: - random assignment - control group - pre-period baseline - comparable groups - stable measurement - enough sample size - consistent treatment exposure D. Better methods Recommend possible approaches: - randomized experiment - difference-in-differences - matched comparison - regression adjustment - interrupted time series - pre/post with caveats - qualitative validation - no causal claim E. Safe wording Rewrite the conclusion using accurate language. Rules: - Do not allow causal language from correlation alone. - Do not ignore confounders. - Do not recommend complex causal methods if data cannot support them. - The output must protect decision-makers from false causal confidence. --------------------------------------------------------------------------------

#213Trend Break and Structural Change Detector

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGForecasting, product analytics, finance, operations, marketing performance, revenue analytics, time-series monitoring, and business reviews.

Detect whether a metric experienced a real structural change, trend break, level shift, or temporary fluctuation.

You are a trend break analyst. Determine whether the metric below has experienced a meaningful structural change or only a temporary fluctuation. Trend context: Metric: [METRIC] Historical data: [DATA] Date field: [DATE FIELD] Potential change date: [CHANGE DATE] Known business events: [EVENTS] Known tracking changes: [TRACKING CHANGES] Time grain: [DAILY / WEEKLY / MONTHLY] Segments: [SEGMENTS] Decision affected: [DECISION] Risk tolerance: [RISK TOLERANCE] Analyze trend break: 1. Baseline behavior Review: - pre-period average - pre-period trend - volatility - seasonality - normal range - outliers - data completeness 2. Post-change behavior Compare: - post-period average - post-period trend - level shift - slope change - volatility change - persistence - segment differences 3. Alternative explanations Check: - data tracking change - source system change - seasonality - campaign - pricing - product release - operational change - external event - mix shift 4. Evidence classification Classify as: - likely structural change - possible structural change - temporary spike or dip - normal variation - data issue - needs more data 5. Recommended response Advise whether to: - update forecast - monitor - investigate - adjust targets - communicate caveat - validate source data Rules: - Do not call one unusual point a structural break. - Do not ignore tracking or definition changes. - Do not update forecasts without evidence of persistence. - Trend break analysis must separate real change from noise. --------------------------------------------------------------------------------

#214Pre/Post Analysis Design and Caveat Builder

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGProduct launches, pricing changes, marketing campaigns, operations changes, policy changes, website updates, and business initiatives without randomized tests.

Design a careful before-and-after analysis with baseline, post-period, comparison group, confounders, effect size, and caveats.

Act as a pre/post analysis designer. Create a careful before-and-after analysis plan for the change below. Change context: Change or initiative: [CHANGE] Change date: [DATE] Affected population: [POPULATION] Outcome metric: [OUTCOME] Pre-period: [PRE-PERIOD] Post-period: [POST-PERIOD] Comparison group, if any: [COMPARISON GROUP] Known confounders: [CONFOUNDERS] Known seasonality: [SEASONALITY] Data sources: [DATA SOURCES] Decision supported: [DECISION] Design the analysis: A. Analysis setup Define: - treatment group - comparison group - pre-period - post-period - inclusion rules - exclusion rules - metric definition - expected effect timing B. Comparison logic Create comparisons: - pre vs post - affected vs unaffected - same period last year - trend before vs trend after - segment-level change - guardrail metrics C. Confounder scan Identify risks from: - seasonality - marketing campaigns - pricing changes - external events - customer mix - operational changes - data collection changes D. Result interpretation Create templates for: - positive result - negative result - mixed result - inconclusive result - data quality issue E. Caveat language Write stakeholder-safe wording that does not overclaim causality. Rules: - Do not claim causation from pre/post alone unless design supports it. - Do not choose periods arbitrarily. - Do not ignore external changes during the analysis window. - Pre/post analysis must be useful while honest about uncertainty. --------------------------------------------------------------------------------

#215Forecast Assumption Challenge Workshop

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGFinance teams, executives, sales forecasting, demand planning, operations planning, startup planning, strategy teams, and board preparation.

Stress-test forecast assumptions with stakeholders by identifying weak assumptions, upside/downside risks, data gaps, and decision triggers.

You are a forecast assumption challenge facilitator. Create a workshop plan to pressure-test the forecast assumptions below. Forecast context: Forecast metric: [METRIC] Forecast horizon: [HORIZON] Forecast owner: [OWNER] Current forecast: [FORECAST] Key assumptions: [ASSUMPTIONS] Stakeholders: [STAKEHOLDERS] Business decision supported: [DECISION] Known risks: [RISKS] Data sources: [DATA SOURCES] Confidence concerns: [CONCERNS] Design the workshop: 1. Workshop objective Define what the group must decide or improve. 2. Assumption review table For each assumption include: - assumption - current value - source - owner - confidence - upside risk - downside risk - evidence needed - decision impact 3. Challenge questions Create questions for: - sales assumptions - demand assumptions - pricing assumptions - capacity assumptions - retention assumptions - seasonality assumptions - external market assumptions - data quality assumptions 4. Stress-test scenarios Create: - base case - downside case - upside case - unexpected shock case - capacity constraint case 5. Decision triggers Define what signals should trigger forecast revision. 6. Workshop output Create a final forecast assumption update template. Rules: - Do not let forecast assumptions remain unowned. - Do not accept optimistic assumptions without evidence. - Do not challenge assumptions in a vague way. - The workshop must improve forecast quality and stakeholder alignment. --------------------------------------------------------------------------------

#216Experiment Postmortem and Learning Report

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGProduct teams, growth teams, marketing teams, experimentation programs, analysts, UX teams, and teams building a learning culture.

Create a structured postmortem for an experiment, including hypothesis, execution quality, results, statistical interpretation, learnings, and next decisions.

Act as an experiment postmortem analyst. Create a learning report for the completed experiment below. Experiment context: Experiment name: [NAME] Hypothesis: [HYPOTHESIS] Control: [CONTROL] Variant: [VARIANT] Target population: [POPULATION] Primary metric: [PRIMARY METRIC] Secondary metrics: [SECONDARY METRICS] Guardrails: [GUARDRAILS] Sample sizes: [SAMPLE SIZES] Result summary: [RESULTS] Execution issues: [ISSUES] Decision made or pending: [DECISION] Create the postmortem: A. Experiment recap Summarize: - hypothesis - setup - audience - duration - variants - metrics - decision rule B. Execution quality Review: - randomization - exposure tracking - sample balance - duration - data quality - implementation issues - external events C. Results Summarize: - primary metric result - secondary metric result - guardrail result - effect size - statistical significance - practical significance - segment notes D. Interpretation Explain: - what we learned - what we did not learn - alternative explanations - uncertainty - product or business implication E. Decision and next steps Recommend: - ship - roll back - iterate - retest - monitor - launch follow-up experiment F. Learning archive Create a reusable experiment learning card. Rules: - Do not call a failed experiment useless. - Do not hide execution problems. - Do not overstate segment results. - The postmortem must improve future decisions and experiments. --------------------------------------------------------------------------------

#217Decision Under Uncertainty Framework

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGExecutives, product managers, analysts, founders, operations leaders, finance teams, strategy teams, and cross-functional decision meetings.

Make better decisions when data is incomplete, noisy, uncertain, or inconclusive by weighing evidence, risks, reversibility, and decision cost.

You are a decision analyst. Help me make a business decision under uncertainty using the evidence available. Decision context: Decision to make: [DECISION] Options: [OPTIONS] Business goal: [GOAL] Evidence available: [EVIDENCE] Evidence missing: [MISSING EVIDENCE] Uncertainty: [UNCERTAINTY] Risks: [RISKS] Cost of waiting: [COST OF WAITING] Cost of being wrong: [COST OF ERROR] Reversibility: [REVERSIBILITY] Stakeholders: [STAKEHOLDERS] Deadline: [DEADLINE] Build the decision framework: A. Decision clarity Define: - decision owner - decision deadline - options - what is not being decided - success criteria B. Evidence assessment Classify evidence as: - strong - directional - weak - missing - conflicting - biased - outdated C. Risk assessment For each option include: - upside - downside - cost - reversibility - operational impact - customer impact - revenue impact - confidence level D. Decision matrix Score options by: - expected impact - confidence - risk - speed - cost - strategic fit - reversibility E. Recommendation Recommend one option and explain: - why it is best - what could make it wrong - what to monitor - when to revisit - what small test could reduce uncertainty Rules: - Do not pretend uncertainty can be eliminated. - Do not delay decisions when waiting costs more than acting. - Do not treat all risks equally. - The framework must help the team act responsibly with imperfect information. --------------------------------------------------------------------------------

#218Statistical Analysis Interpretation Reviewer

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, data scientists, researchers, product analysts, marketing analysts, finance teams, students, and technical reviewers.

Review statistical analysis outputs for correct interpretation, assumptions, limitations, effect size, confidence, bias, and business relevance.

Act as a statistical interpretation reviewer. Review the statistical analysis below and identify what can and cannot be concluded. Analysis output: [PASTE STATISTICAL RESULTS / TABLE / MODEL OUTPUT / TEST RESULT] Context: Business question: [QUESTION] Data source: [DATA SOURCE] Sample size: [SAMPLE SIZE] Variables analyzed: [VARIABLES] Method used: [METHOD] Assumptions made: [ASSUMPTIONS] Decision supported: [DECISION] Audience: [AUDIENCE] Known limitations: [LIMITATIONS] Review the interpretation: A. Method fit Evaluate whether the method matches: - data type - sample size - question - assumptions - business decision - comparison needed B. Result interpretation Explain: - main result - effect size - uncertainty - statistical significance - practical significance - confidence level - what the result means in business terms C. Assumption check Review assumptions such as: - independence - normality - equal variance - sample representativeness - measurement stability - random assignment - missing data handling D. Limitation review Identify: - bias - confounding - small sample - multiple comparisons - outliers - data quality issues - overfitting - model misuse E. Safe conclusion Rewrite the conclusion in accurate language. Rules: - Do not accept statistical output without checking assumptions. - Do not confuse significance with importance. - Do not allow causal claims unless design supports them. - The review must make the analysis safer for business use. --------------------------------------------------------------------------------

#219Forecast and Experiment Reporting Narrative

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGAnalysts, product teams, finance teams, executives, growth teams, strategy teams, consultants, and business review presentations.

Turn forecast, experiment, statistical, or scenario analysis into a clear stakeholder narrative with uncertainty, impact, confidence, and decision guidance.

You are a data storytelling specialist for uncertainty-heavy analysis. Turn the analysis below into a clear business narrative. Input analysis: [PASTE FORECAST / EXPERIMENT RESULT / SCENARIO MODEL / STATISTICAL OUTPUT] Reporting context: Audience: [AUDIENCE] Business decision: [DECISION] Metric: [METRIC] Time horizon: [TIME HORIZON] Confidence level: [CONFIDENCE] Known caveats: [CAVEATS] Recommended action: [ACTION] Output format: [EMAIL / MEMO / SLIDE NOTES / EXECUTIVE SUMMARY] Tone: [DIRECT / EXECUTIVE / FORMAL / PLAIN LANGUAGE] Create the narrative: A. Headline Write one sentence that communicates the main conclusion and uncertainty. B. Result summary Explain: - what was analyzed - what the result suggests - expected impact - confidence level - uncertainty range - what decision it supports C. Evidence Summarize the key evidence: - forecast trend - experiment lift - scenario range - statistical result - driver analysis - caveat D. Decision guidance Recommend: - act now - test further - monitor - wait for more data - choose low-risk option - change plan E. Caveats State limitations clearly. F. Final stakeholder-ready version Write the final narrative in the requested format. Rules: - Do not hide uncertainty to sound confident. - Do not overload stakeholders with statistical detail. - Do not present scenarios as predictions. - The narrative must make uncertainty understandable and decision-ready. --------------------------------------------------------------------------------

#220Full Forecasting, Experiments and Statistical Thinking Audit

FORECASTING, EXPERIMENTS & STATISTICAL THINKINGData analysts, product teams, growth teams, finance teams, executives, operations teams, strategy teams, experimentation teams, and business decision-makers.

Audit and rebuild analytical decision systems across forecasts, trend analysis, experiments, A/B tests, statistical significance, scenarios, impact estimates, and uncertainty.

Act as an independent forecasting, experimentation, and statistical thinking auditor. Review my current forecast, experiment, statistical analysis, or uncertainty-heavy decision process, then rebuild it into a clearer, more reliable, decision-ready system. Full context: Business question: [QUESTION] Decision to support: [DECISION] Metric or outcome: [METRIC] Historical data: [HISTORICAL DATA] Forecasting method, if any: [FORECAST METHOD] Experiment design, if any: [EXPERIMENT DESIGN] Statistical method, if any: [STATISTICAL METHOD] Sample size: [SAMPLE SIZE] Time horizon: [TIME HORIZON] Segments: [SEGMENTS] Known assumptions: [ASSUMPTIONS] Known uncertainty: [UNCERTAINTY] Known risks: [RISKS] Stakeholders: [STAKEHOLDERS] Current output: [OUTPUT] Business deadline: [DEADLINE] Audit across 60 dimensions: 1. Decision clarity 2. Business question clarity 3. Metric definition 4. Forecast objective 5. Forecast horizon 6. Forecast grain 7. Historical data coverage 8. Data quality 9. Seasonality handling 10. Trend handling 11. Outlier handling 12. Structural break awareness 13. Forecast method fit 14. Forecast assumption quality 15. Driver-based logic 16. Scenario design 17. Sensitivity analysis 18. Forecast backtesting 19. Forecast accuracy metrics 20. Bias detection 21. Confidence range 22. Uncertainty communication 23. Experiment hypothesis 24. Experiment design 25. Control group quality 26. Randomization quality 27. Sample size readiness 28. Power concern 29. Primary metric fit 30. Guardrail metrics 31. Test duration 32. Exposure tracking 33. Segment analysis risk 34. Statistical significance 35. Practical significance 36. Effect size 37. Confidence interval interpretation 38. P-value interpretation 39. Multiple comparison risk 40. Causal claim risk 41. Confounding risk 42. Pre/post design quality 43. Difference-in-differences need 44. Regression to mean risk 45. Selection bias risk 46. Impact estimation logic 47. Impact assumptions 48. Cost of error 49. Cost of waiting 50. Decision reversibility 51. Risk assessment 52. Decision thresholds 53. Monitoring plan 54. Stakeholder interpretation 55. Executive narrative 56. Caveat visibility 57. Recommendation quality 58. Follow-up learning plan 59. Decision readiness 60. Overall statistical thinking maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - decision risk if ignored - analytical risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current forecast, experiment, or statistical analysis may mislead decision-makers. B. Rebuilt decision analysis system Create: - forecast framing - data readiness plan - forecast method recommendation - assumption table - scenario model - backtesting plan - experiment design plan - metric and guardrail framework - statistical interpretation guide - causal caveat review - impact estimation model - decision under uncertainty framework C. First 10 analytical fixes Rank the first 10 improvements. For each include: - issue - fix - why it matters - owner - expected output - risk reduced D. Reporting pack Create: - forecast summary - experiment result summary - scenario summary - statistical interpretation note - stakeholder caveat language - decision recommendation template E. Decision roadmap Create a 30-day roadmap for improving forecasting, experimentation, or uncertainty-based decisions. F. Executive summary Write a direct summary with: - strongest evidence - weakest assumption - biggest uncertainty - biggest decision risk - first validation step - first experiment or forecast improvement - one operating principle for statistical thinking Rules: - Do not present uncertain estimates as facts. - Do not claim causality without the right design. - Do not treat statistical significance as automatic business significance. - Use [NEEDS DATA QUALITY CHECK], [NEEDS SAMPLE SIZE REVIEW], [NEEDS EXPERIMENT DESIGN REVIEW], [NEEDS FORECAST BACKTEST], [NEEDS CAUSAL REVIEW], or [NEEDS STAKEHOLDER DECISION] where required. - The final system should make decisions stronger under uncertainty, not create false confidence.

#221Analysis Findings to Clear Insight Converter

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, BI analysts, consultants, product analysts, marketing analysts, finance analysts, operations analysts, and anyone translating analysis into business insight.

Turn raw analysis findings into clear, useful insights that explain what happened, why it matters, what evidence supports it, and what action should follow.

You are a senior data insights analyst. Convert the raw findings below into clear, business-ready insights that stakeholders can understand and act on. Analysis context: Business area: [BUSINESS AREA] Audience: [AUDIENCE] Business question: [QUESTION] Decision to support: [DECISION] Raw findings: [PASTE FINDINGS] Metrics analyzed: [METRICS] Segments analyzed: [SEGMENTS] Time period: [TIME PERIOD] Known caveats: [CAVEATS] Expected output format: [MEMO / SLIDES / EMAIL / DASHBOARD NOTES] Transform findings into insights: 1. Finding cleanup For each raw finding, rewrite it as a precise observation. Include: - what changed - where it changed - how much it changed - over what period - which segment is affected - what evidence supports it 2. Insight creation Turn each observation into an insight. For each insight include: - insight statement - business meaning - supporting evidence - confidence level - caveat - stakeholder implication - recommended follow-up 3. Insight quality filter Classify each insight as: - decision-ready - needs more evidence - interesting but not actionable - likely data quality issue - too weak to include - needs stakeholder context 4. Prioritization Rank insights by: - business impact - urgency - actionability - confidence - stakeholder relevance 5. Final insight summary Create a concise final summary with: - top 3 insights - what stakeholders should do - what still needs validation - what should not be concluded Rules: - Do not confuse a data point with an insight. - Do not overstate what the analysis proves. - Do not include weak findings just because they are interesting. - Each final insight must connect evidence to business meaning and action. --------------------------------------------------------------------------------

#222Executive Summary Writer for Data Analysis

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONExecutives, founders, leadership teams, analysts, consultants, board updates, monthly business reviews, and decision memos.

Write concise executive summaries that highlight the main conclusion, evidence, business impact, risks, and recommended decision.

Act as an executive analytics communicator. Write a clear executive summary from the analysis below. Input: Analysis topic: [TOPIC] Audience: [AUDIENCE] Business context: [CONTEXT] Main findings: [FINDINGS] Metrics: [METRICS] Business impact: [IMPACT] Recommended action: [ACTION] Known risks: [RISKS] Known caveats: [CAVEATS] Decision needed: [DECISION] Tone: [DIRECT / FORMAL / BOARD-READY / INTERNAL / SIMPLE] Create the executive summary: A. Headline Write one sentence that communicates the main takeaway. B. Short summary Write 5 to 7 sentences covering: - what was analyzed - what changed or was discovered - why it matters - strongest evidence - business impact - key risk or caveat - recommended decision or next step C. Decision box Create a short decision box with: - recommended action - owner - timeline - expected impact - confidence level - what to monitor D. Risk note Write a short risk note explaining what could change the recommendation. E. What not to conclude List 3 things stakeholders should not infer from the analysis. Rules: - Do not include unnecessary technical detail. - Do not bury the recommendation. - Do not hide uncertainty. - The summary must help a busy executive understand the decision in under one minute. --------------------------------------------------------------------------------

#223Findings to Recommendations Builder

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, strategy teams, product teams, marketing teams, sales teams, operations teams, finance analysts, and consultants.

Convert analysis findings into specific recommendations with actions, owners, expected impact, risks, effort, and follow-up metrics.

You are a recommendation strategist. Turn the analysis findings below into practical business recommendations. Analysis context: Business question: [QUESTION] Findings: [PASTE FINDINGS] Audience: [AUDIENCE] Business goal: [GOAL] Decision owner: [OWNER] Available levers: [LEVERS] Constraints: [CONSTRAINTS] Metrics affected: [METRICS] Confidence level: [CONFIDENCE] Time horizon: [TIME HORIZON] Build recommendations: 1. Finding interpretation For each finding explain: - what it means - why it matters - what business lever it relates to - what risk exists if ignored 2. Recommendation options For each major finding create 2 to 3 possible actions. For each action include: - recommendation - rationale - expected impact - affected metric - owner - effort - risk - dependency - timeline - confidence level 3. Prioritization Rank recommendations by: - impact - confidence - effort - urgency - strategic fit - reversibility - risk 4. Final recommendation set Create: - do now - test first - monitor - defer - reject 5. Follow-up measurement For each accepted recommendation define: - success metric - guardrail metric - review date - expected signal - decision threshold Rules: - Do not recommend actions that are not supported by findings. - Do not recommend too many actions at once. - Do not hide tradeoffs. - Recommendations must be specific enough for stakeholders to assign ownership. --------------------------------------------------------------------------------

#224Non-Technical Stakeholder Explainer

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts presenting to executives, operations teams, clients, sales teams, product teams, founders, HR teams, and non-technical business users.

Explain analytical findings, metrics, methods, caveats, and recommendations in plain language for stakeholders who do not work with data.

Act as a plain-language data translator. Explain the analysis below to a non-technical stakeholder so they understand the meaning, risk, and decision. Context: Audience: [AUDIENCE] Audience knowledge level: [BEGINNER / NON-TECHNICAL / MIXED] Analysis topic: [TOPIC] Business question: [QUESTION] Main findings: [FINDINGS] Metrics used: [METRICS] Method used: [METHOD] Recommended action: [ACTION] Known limitations: [LIMITATIONS] Decision needed: [DECISION] Tone: [CLEAR / FRIENDLY / EXECUTIVE / DIRECT] Create the explanation: A. Simple summary Explain the analysis in 3 to 5 sentences without technical jargon. B. What the numbers mean Explain each important metric: - metric name - plain-language meaning - why it matters - what good looks like - what bad looks like C. What we learned Write the findings as simple insight statements. D. What we do not know Explain uncertainty and limitations clearly. E. Recommended action Explain what should happen next and why. F. Analogy or example Use one simple analogy if it helps understanding. G. Questions they may ask Create answers to 8 likely stakeholder questions. Rules: - Do not use statistical or technical terms without explaining them. - Do not dumb down the business meaning. - Do not hide uncertainty. - The explanation must help the stakeholder make a better decision. --------------------------------------------------------------------------------

#225Data Story Arc Builder

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts, consultants, BI teams, product teams, finance teams, executive presentations, slide decks, memos, and stakeholder meetings.

Structure analysis into a compelling data story with context, tension, evidence, interpretation, recommendation, and next steps.

You are a data storytelling strategist. Build a clear story arc for the analysis below. Story context: Analysis topic: [TOPIC] Audience: [AUDIENCE] Business situation: [SITUATION] Business problem or tension: [PROBLEM] Key question: [QUESTION] Findings: [FINDINGS] Metrics: [METRICS] Evidence available: [EVIDENCE] Recommendation: [RECOMMENDATION] Decision needed: [DECISION] Format: [SLIDES / MEMO / REPORT / TALK TRACK] Build the story arc: 1. Situation Explain the current business context. 2. Tension Define what changed, what is unclear, or what risk creates urgency. 3. Key question Write the central question the analysis answers. 4. Evidence path Create the sequence of evidence: - baseline - trend - segment difference - driver analysis - comparison - exception - implication 5. Interpretation Explain what the evidence means and what it does not prove. 6. Recommendation Create a recommendation with: - action - rationale - expected impact - confidence - risk - owner 7. Final story outline Create the final narrative structure with section titles and key messages. Rules: - Do not start with charts before the story is clear. - Do not make the story longer than the decision requires. - Do not overclaim causality. - The story must help the audience understand what happened, why it matters, and what to do. --------------------------------------------------------------------------------

#226Insight Prioritization and Message Hierarchy

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, consultants, BI teams, research teams, performance reports, executive summaries, slide decks, and dashboards.

Prioritize many findings into a clear message hierarchy so reports focus on the most important insights instead of overwhelming stakeholders.

Act as an insight prioritization editor. I have many findings and need to decide what belongs in the main story, what belongs in appendix, and what should be removed. Input: Findings list: [PASTE FINDINGS] Audience: [AUDIENCE] Business decision: [DECISION] Business goal: [GOAL] Report format: [FORMAT] Time available for presentation: [TIME] Stakeholder concerns: [CONCERNS] Known caveats: [CAVEATS] Prioritize the insights: A. Finding classification Classify each finding as: - main message - supporting evidence - risk or caveat - operational detail - appendix - not useful - needs more validation B. Scoring Score each finding by: - business impact - decision relevance - confidence - urgency - novelty - actionability - stakeholder interest C. Message hierarchy Create: - primary message - 3 supporting messages - evidence under each message - caveats under each message - recommended action D. Report structure Recommend where each finding should go: - executive summary - main report - dashboard annotation - appendix - follow-up analysis - remove E. Final communication plan Write a concise outline for the stakeholder-facing version. Rules: - Do not give equal weight to every finding. - Do not include low-confidence findings in the main message without caveats. - Do not overload executives with appendix-level details. - The output must create a clear, focused communication hierarchy. --------------------------------------------------------------------------------

#227Uncertainty and Caveat Communication Builder

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts, executives, product teams, finance teams, statistical analysis, forecasts, experiments, dashboards, and decision memos.

Explain uncertainty, limitations, assumptions, confidence levels, and risks without weakening useful recommendations or confusing stakeholders.

You are an uncertainty communication expert. Help me explain the uncertainty in this analysis clearly and responsibly. Analysis context: Analysis topic: [TOPIC] Audience: [AUDIENCE] Main conclusion: [CONCLUSION] Evidence: [EVIDENCE] Known limitations: [LIMITATIONS] Assumptions: [ASSUMPTIONS] Data quality issues: [DATA ISSUES] Confidence level: [CONFIDENCE] Decision supported: [DECISION] Risk if wrong: [RISK] Tone: [DIRECT / EXECUTIVE / CAREFUL / SIMPLE] Create the uncertainty communication: 1. Confidence statement Write a clear confidence statement: - high confidence - medium confidence - low confidence - directional only - not decision-ready 2. Limitation explanation Explain each limitation in plain language. For each include: - limitation - why it matters - how it could affect the result - whether it changes the recommendation - what would reduce uncertainty 3. Assumption statement List assumptions and classify them as: - safe - reasonable but needs review - risky - unknown 4. Caveat wording Write caveat wording for: - executive summary - slide note - dashboard tooltip - email update - detailed appendix 5. Decision guidance Explain whether stakeholders should: - act now - act with monitoring - test first - wait for more data - avoid decision Rules: - Do not hide uncertainty. - Do not over-explain caveats so much that the main message is lost. - Do not use vague words like “maybe” without explaining what is uncertain. - The communication must preserve trust and support action. --------------------------------------------------------------------------------

#228Data Limitation and Assumption Register

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, consultants, analytics managers, research teams, finance teams, product analysts, and decision documentation.

Build a structured register of analysis assumptions, limitations, evidence gaps, risk level, mitigation plans, and stakeholder wording.

Act as an analysis risk documentation specialist. Create an assumption and limitation register for the analysis below. Analysis context: Project: [PROJECT] Business question: [QUESTION] Method: [METHOD] Data sources: [DATA SOURCES] Findings: [FINDINGS] Assumptions: [ASSUMPTIONS] Known limitations: [LIMITATIONS] Stakeholders: [STAKEHOLDERS] Decision to support: [DECISION] Risk tolerance: [RISK TOLERANCE] Create the register: A. Assumption table For each assumption include: - assumption - why it was made - evidence supporting it - evidence missing - impact if wrong - likelihood of being wrong - risk level - owner to validate - mitigation B. Limitation table For each limitation include: - limitation - affected analysis area - impact on conclusion - severity - whether recommendation changes - wording for stakeholders - follow-up needed C. Evidence gaps Identify what data, context, or validation is missing. D. Mitigation plan Create actions to reduce risk or improve confidence. E. Final caveat section Write a short caveat section suitable for a report or memo. Rules: - Do not bury limitations in footnotes only. - Do not treat all limitations as equally important. - Do not use caveats to avoid making a recommendation. - The register must make risk visible and manageable. --------------------------------------------------------------------------------

#229Decision Memo from Analysis

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONExecutives, product managers, operations leaders, founders, consultants, finance teams, strategy teams, and analysts supporting business decisions.

Turn analysis into a decision memo with recommendation, options, evidence, tradeoffs, risks, implementation steps, and follow-up metrics.

You are a decision memo writer. Convert the analysis below into a clear memo that helps stakeholders make a decision. Decision context: Decision to make: [DECISION] Decision owner: [OWNER] Audience: [AUDIENCE] Business goal: [GOAL] Analysis findings: [FINDINGS] Options considered: [OPTIONS] Recommended option: [RECOMMENDATION] Evidence: [EVIDENCE] Risks: [RISKS] Constraints: [CONSTRAINTS] Timeline: [TIMELINE] Metrics to monitor: [METRICS] Write the decision memo: 1. Recommendation upfront Start with the recommended decision in 1 to 2 sentences. 2. Context Explain why the decision matters now. 3. Options Compare each option: - option - expected benefit - cost - risk - evidence supporting it - evidence against it - reversibility - time to implement 4. Evidence summary Summarize the strongest analytical evidence. 5. Tradeoffs Explain what the team gains and gives up. 6. Implementation plan Create: - first step - owner - timeline - dependencies - success metric - guardrail metric 7. Decision request Write the final ask for the decision owner. Rules: - Do not hide the recommendation at the end. - Do not present options without tradeoffs. - Do not include irrelevant analysis detail. - The memo must make the decision easier, faster, and better grounded. --------------------------------------------------------------------------------

#230Chart-to-Insight Interpretation Writer

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONDashboard notes, presentation slides, BI reports, executive summaries, analyst commentary, and visual storytelling.

Convert chart observations into stakeholder-ready explanations that describe the pattern, evidence, meaning, caveat, and next action.

Act as a chart interpretation writer. Turn the chart or visual description below into clear insights and captions. Chart context: Chart type: [CHART TYPE] Chart title: [TITLE] Metric shown: [METRIC] Dimensions shown: [DIMENSIONS] Time period: [TIME PERIOD] Audience: [AUDIENCE] Business question: [QUESTION] Observed pattern: [PATTERN] Known caveats: [CAVEATS] Decision supported: [DECISION] Create chart interpretation: A. Better chart title Write a title that states the insight, not just the metric. B. Short caption Write a 1 to 2 sentence caption explaining the key takeaway. C. Detailed interpretation Explain: - what the chart shows - what changed or differs - how large the pattern is - why it matters - what could explain it - what caveat applies D. Stakeholder implication Explain what the audience should consider doing. E. Follow-up question Write 3 follow-up analysis questions. F. Misread warning Explain how someone might misinterpret the chart. Rules: - Do not describe the visual without interpreting it. - Do not claim the chart proves causation unless design supports it. - Do not use vague titles like “Revenue by Month.” - Chart commentary must help stakeholders understand the business meaning. --------------------------------------------------------------------------------

#231Stakeholder Q&A Preparation Pack

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, consultants, BI teams, finance teams, product analysts, executive presentations, board updates, and stakeholder meetings.

Prepare analysts for stakeholder questions by anticipating objections, clarification requests, caveat concerns, data trust issues, and decision tradeoffs.

You are a stakeholder Q&A preparation coach. Prepare me to present the analysis below and answer difficult questions clearly. Presentation context: Analysis topic: [TOPIC] Audience: [AUDIENCE] Main findings: [FINDINGS] Recommendation: [RECOMMENDATION] Metrics used: [METRICS] Data sources: [DATA SOURCES] Known caveats: [CAVEATS] Likely stakeholder concerns: [CONCERNS] Decision needed: [DECISION] Meeting format: [FORMAT] Create the Q&A pack: A. Likely questions Generate questions across: - data accuracy - metric definitions - methodology - caveats - recommendation - business impact - risks - alternative explanations - implementation - timing B. Answer bank For each question provide: - short answer - detailed answer - evidence to reference - caveat to mention - what not to say C. Objection handling Prepare responses for: - “I do not trust the data” - “This does not match my experience” - “Why did this happen?” - “Can we prove causation?” - “What should we do next?” - “What if we are wrong?” D. Escalation notes Identify questions that require follow-up instead of guessing. E. Closing statement Write a strong closing that restates the decision and next step. Rules: - Do not bluff answers when data does not support them. - Do not get defensive about caveats. - Do not answer technical questions with unnecessary jargon. - The Q&A pack must help the analyst stay clear, credible, and decision-focused. --------------------------------------------------------------------------------

#232Recommendation Tradeoff and Risk Explainer

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONStrategy decisions, product changes, pricing decisions, marketing investments, operations changes, finance decisions, and executive reviews.

Explain the tradeoffs, risks, benefits, costs, and uncertainties behind a recommendation so stakeholders can make informed decisions.

Act as a recommendation risk and tradeoff analyst. Explain the recommendation below in a balanced, decision-ready way. Recommendation context: Recommendation: [RECOMMENDATION] Business goal: [GOAL] Supporting evidence: [EVIDENCE] Alternative options: [OPTIONS] Expected impact: [IMPACT] Implementation effort: [EFFORT] Risks: [RISKS] Constraints: [CONSTRAINTS] Stakeholders affected: [STAKEHOLDERS] Decision deadline: [DEADLINE] Build the tradeoff explanation: 1. Recommendation summary State the recommendation clearly. 2. Why this recommendation Explain: - evidence supporting it - business logic - expected benefit - affected metrics - confidence level 3. Tradeoffs List what the business gains and gives up. Include: - financial tradeoff - customer tradeoff - operational tradeoff - speed tradeoff - strategic tradeoff - data confidence tradeoff 4. Risk map For each risk include: - risk - likelihood - impact - early warning signal - mitigation - owner 5. Alternatives Compare alternatives and explain why they were not chosen. 6. Final decision guidance Write a concise recommendation statement for leadership. Rules: - Do not sell the recommendation without explaining downside. - Do not overstate confidence. - Do not ignore implementation feasibility. - The explanation must help stakeholders choose with eyes open. --------------------------------------------------------------------------------

#233Data Story Slide Outline Builder

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONConsultants, analysts, executives, board decks, product reviews, business reviews, performance updates, and decision presentations.

Create a slide-by-slide data story that turns analysis into a clear presentation with titles, visuals, evidence, caveats, and recommendations.

You are a data presentation strategist. Create a slide outline for the analysis below. Presentation context: Audience: [AUDIENCE] Presentation goal: [GOAL] Business question: [QUESTION] Key findings: [FINDINGS] Recommendation: [RECOMMENDATION] Metrics: [METRICS] Charts available: [CHARTS] Caveats: [CAVEATS] Decision needed: [DECISION] Number of slides: [NUMBER] Tone: [EXECUTIVE / CONSULTING / INTERNAL / BOARD] Build the slide outline: A. Story flow Create a logical flow: - why this matters - what we analyzed - what we found - what it means - what we recommend - what decision is needed B. Slide list For each slide include: - slide number - insight-driven title - slide purpose - key message - visual needed - supporting evidence - speaker note - caveat - transition to next slide C. Executive summary slide Write the first slide summary. D. Recommendation slide Create the final recommendation slide. E. Appendix plan List what should go in appendix instead of main deck. Rules: - Do not use generic slide titles. - Do not put every chart in the main deck. - Do not separate recommendation from evidence. - The outline must make the presentation decision-ready. --------------------------------------------------------------------------------

#234Insight Validation Checklist

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts, analytics managers, consultants, BI teams, research teams, executive reporting, and quality control before presentations.

Validate whether an insight is accurate, supported, meaningful, actionable, and safe to present before it reaches stakeholders.

Act as an insight quality reviewer. Validate the insight below before it is shared with stakeholders. Insight to validate: [PASTE INSIGHT] Context: Business question: [QUESTION] Supporting evidence: [EVIDENCE] Data sources: [DATA SOURCES] Metrics used: [METRICS] Segments involved: [SEGMENTS] Time period: [TIME PERIOD] Known caveats: [CAVEATS] Recommendation linked to insight: [RECOMMENDATION] Audience: [AUDIENCE] Validate the insight: A. Evidence check Evaluate: - data source reliability - metric definition - calculation logic - segment size - time period - comparison baseline - data quality caveats B. Logic check Assess: - whether evidence supports the insight - whether alternative explanations exist - whether causality is implied incorrectly - whether the insight is overstated - whether the conclusion follows C. Business value check Determine: - decision relevance - actionability - urgency - business impact - stakeholder relevance D. Communication check Improve: - wording clarity - caveat placement - confidence statement - recommended next step - what not to conclude E. Approval status Classify as: - ready to present - present with caveat - needs more evidence - rewrite - do not present Rules: - Do not approve insights that are only interesting but not useful. - Do not allow causal wording without causal evidence. - Do not hide weak evidence. - The checklist must prevent misleading stakeholder communication. --------------------------------------------------------------------------------

#235Cross-Functional Action Plan from Insights

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONProduct teams, marketing teams, sales teams, operations teams, finance teams, customer success, executives, and cross-functional projects.

Convert insights into an action plan across teams with owners, timelines, dependencies, risks, metrics, and review cadence.

You are a cross-functional action planning facilitator. Turn the insights below into a coordinated action plan. Input: Insights: [PASTE INSIGHTS] Business goal: [GOAL] Teams involved: [TEAMS] Stakeholders: [STAKEHOLDERS] Decision owner: [OWNER] Available resources: [RESOURCES] Constraints: [CONSTRAINTS] Timeline: [TIMELINE] Metrics to improve: [METRICS] Risks: [RISKS] Create the action plan: 1. Insight-to-action mapping For each insight define: - business implication - recommended action - team responsible - owner - expected output - metric affected - priority 2. Action sequencing Organize actions into: - immediate - this week - this month - next quarter - monitor only - needs more analysis 3. Dependency map Identify: - data dependency - product dependency - sales dependency - marketing dependency - operations dependency - finance dependency - leadership decision dependency 4. Risk and mitigation For each action include: - risk - likelihood - impact - mitigation - owner 5. Review cadence Create a follow-up process with: - review meeting - status fields - success metric - guardrail metric - decision checkpoint Rules: - Do not leave insights without owners. - Do not create actions that no team can execute. - Do not ignore dependencies. - The action plan must turn analysis into accountable business movement. --------------------------------------------------------------------------------

#236Bad News Data Communication Script

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts, managers, executives, consultants, finance teams, product teams, operations teams, client reporting, and crisis communication.

Communicate negative findings, underperformance, risks, failed experiments, forecast misses, or data quality issues honestly and constructively.

Act as a data communication advisor. Help me communicate a difficult or negative analytical finding without creating panic or hiding the truth. Situation: Bad news or difficult finding: [FINDING] Audience: [AUDIENCE] Business area: [AREA] Evidence: [EVIDENCE] Impact: [IMPACT] Cause, if known: [CAUSE] Cause uncertainty: [UNCERTAINTY] Recommended next step: [NEXT STEP] Risks: [RISKS] Tone needed: [CALM / DIRECT / EXECUTIVE / CLIENT-FACING] Create the communication: A. Direct opening Write a clear opening that states the issue honestly. B. Evidence summary Explain the evidence without overloading the audience. C. Impact explanation Explain: - what is affected - how serious it is - what is not affected - what could happen if ignored D. Cause and uncertainty Explain what is known, what is unknown, and what is being checked. E. Action plan Create: - immediate action - owner - timeline - next update - metric to monitor F. Versions Write three versions: - short Slack or Teams update - executive email - meeting talking points Rules: - Do not soften the truth so much that the risk is unclear. - Do not assign blame without evidence. - Do not make the issue sound larger than it is. - The communication must be honest, calm, and action-oriented. --------------------------------------------------------------------------------

#237Technical Analysis Simplifier

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, data scientists, analytics engineers, consultants, product teams, executives, finance teams, and non-technical stakeholders.

Convert technical analysis, SQL logic, statistical methods, or model outputs into simple explanations without losing accuracy.

You are a technical-to-business translator. Simplify the technical analysis below so non-technical stakeholders understand what was done and why it matters. Technical input: [PASTE TECHNICAL ANALYSIS / SQL LOGIC / MODEL OUTPUT / METHOD] Context: Audience: [AUDIENCE] Business question: [QUESTION] Decision supported: [DECISION] Metric or outcome: [METRIC] Technical method: [METHOD] Known caveats: [CAVEATS] Output format: [EMAIL / MEMO / SLIDE NOTE / TALK TRACK] Tone: [SIMPLE / EXECUTIVE / FORMAL / TEACHING] Simplify the analysis: A. Plain-language explanation Explain what was done in simple terms. B. Why it was done Connect the technical work to the business question. C. What the result means Explain the key result and business implication. D. What to trust Explain which parts are solid and why. E. What to be careful about Explain limitations and assumptions. F. Final version Write a stakeholder-ready version. G. Optional technical appendix Create a short appendix for technical readers. Rules: - Do not use jargon without explaining it. - Do not remove caveats that affect decisions. - Do not make the method sound more certain than it is. - The simplified version must remain accurate. --------------------------------------------------------------------------------

#238Insight Library and Knowledge Base Card Builder

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalytics teams, knowledge management, research repositories, product teams, growth teams, BI teams, consultants, and organizations reusing analysis.

Turn analysis outputs into reusable insight cards that preserve context, evidence, caveats, recommendations, and follow-up decisions.

Act as an analytics knowledge management specialist. Convert the analysis below into reusable insight cards for an internal knowledge base. Analysis context: Analysis title: [TITLE] Business area: [AREA] Original question: [QUESTION] Findings: [FINDINGS] Data sources: [DATA SOURCES] Metrics: [METRICS] Time period: [TIME PERIOD] Segments: [SEGMENTS] Recommendation: [RECOMMENDATION] Decision made: [DECISION] Known caveats: [CAVEATS] Owner: [OWNER] Create insight cards: A. Insight card template Create a reusable structure with: - title - one-sentence insight - business question - context - evidence - data sources - metrics used - caveats - recommendation - decision made - follow-up needed - owner - date - tags B. Convert findings Create one insight card per major finding. C. Reuse guidance For each card explain: - when this insight applies - when it does not apply - what should be revalidated - which teams may benefit D. Knowledge gaps List unanswered questions and future analysis ideas. E. Search tags Create useful tags for finding the insight later. Rules: - Do not store insights without context. - Do not omit caveats or time period. - Do not turn weak findings into permanent truths. - The insight cards must make analysis reusable and trustworthy. --------------------------------------------------------------------------------

#239Stakeholder Decision Workshop Facilitator

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONAnalysts, consultants, product managers, executives, finance teams, operations leaders, strategy sessions, and cross-functional decision meetings.

Facilitate a stakeholder meeting where analysis is reviewed, options are compared, uncertainty is discussed, and a decision or next step is agreed.

You are a data-driven decision workshop facilitator. Create a meeting plan that helps stakeholders move from analysis to decision. Workshop context: Decision to make: [DECISION] Audience: [AUDIENCE] Stakeholders: [STAKEHOLDERS] Analysis findings: [FINDINGS] Options: [OPTIONS] Recommendation: [RECOMMENDATION] Known disagreements: [DISAGREEMENTS] Uncertainty: [UNCERTAINTY] Time available: [TIME] Desired outcome: [OUTCOME] Design the workshop: 1. Meeting objective State what the meeting must accomplish. 2. Pre-read structure Create a pre-read outline with: - context - main findings - recommendation - options - risks - decision needed 3. Agenda Create a timed agenda including: - opening - analysis recap - clarification questions - option comparison - risk discussion - decision criteria - decision - next steps 4. Decision criteria Define criteria such as: - impact - confidence - effort - risk - speed - reversibility - strategic fit 5. Facilitation prompts Write questions to ask stakeholders when discussion gets unclear or opinion-based. 6. Decision output Create a decision log template with: - decision - rationale - owner - timeline - risks accepted - follow-up metrics Rules: - Do not let the meeting become a chart review only. - Do not allow opinions to override evidence without documenting why. - Do not end without owner and next step. - The workshop must convert analysis into an explicit decision or action plan. --------------------------------------------------------------------------------

#240Full Data Storytelling, Insights and Stakeholder Communication Audit

DATA STORYTELLING, INSIGHTS & STAKEHOLDER COMMUNICATIONData analysts, analytics leaders, consultants, BI teams, product teams, finance teams, operations teams, executives, and anyone turning analysis into decisions.

Audit and rebuild the communication layer of an analytics project across insights, executive summaries, recommendations, caveats, narratives, decisions, stakeholder Q&A, and action follow-up.

Act as an independent data storytelling, insights, and stakeholder communication auditor. Review my analysis communication and rebuild it into a clear, credible, decision-ready stakeholder package. Full context: Analysis topic: [TOPIC] Business question: [QUESTION] Business goal: [GOAL] Audience: [AUDIENCE] Stakeholders: [STAKEHOLDERS] Findings: [FINDINGS] Metrics: [METRICS] Data sources: [DATA SOURCES] Time period: [TIME PERIOD] Segments: [SEGMENTS] Charts or visuals: [VISUALS] Current summary: [CURRENT SUMMARY] Current recommendation: [RECOMMENDATION] Known caveats: [CAVEATS] Decision needed: [DECISION] Meeting or report format: [FORMAT] Desired outcome: [OUTCOME] Audit across 60 dimensions: 1. Business question clarity 2. Audience fit 3. Decision connection 4. Main message clarity 5. Insight quality 6. Finding vs insight distinction 7. Evidence strength 8. Metric explanation 9. Segment explanation 10. Time period context 11. Baseline context 12. Comparison context 13. Business impact clarity 14. Recommendation clarity 15. Recommendation specificity 16. Actionability 17. Owner assignment 18. Timeline clarity 19. Risk explanation 20. Tradeoff explanation 21. Caveat visibility 22. Assumption visibility 23. Uncertainty communication 24. Confidence level 25. Causality wording 26. Overclaiming risk 27. Underclaiming risk 28. Technical jargon 29. Plain-language quality 30. Executive summary quality 31. Narrative flow 32. Story arc 33. Chart interpretation 34. Chart title quality 35. Visual-to-message alignment 36. Appendix structure 37. Q&A readiness 38. Objection handling 39. Stakeholder trust 40. Non-technical comprehension 41. Bad news communication 42. Decision memo quality 43. Slide structure 44. Meeting facilitation readiness 45. Recommendation prioritization 46. Insight prioritization 47. Follow-up questions 48. Next-step clarity 49. Action plan quality 50. Cross-functional alignment 51. Decision log readiness 52. Knowledge base readiness 53. Reusability 54. Report length 55. Message hierarchy 56. Stakeholder relevance 57. Credibility 58. Decision readiness 59. Communication risk 60. Overall storytelling maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - stakeholder risk if ignored - decision risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current analysis communication may fail to influence decisions. B. Rebuilt stakeholder package Create: - main message - executive summary - insight hierarchy - evidence structure - chart interpretation plan - caveat and uncertainty section - recommendation section - tradeoff explanation - decision memo - stakeholder Q&A pack - action plan - follow-up measurement plan C. First 10 communication fixes Rank the first 10 improvements. For each include: - issue - fix - why it matters - audience affected - expected improvement - effort D. Final stakeholder-ready version Write: - executive summary - top 5 insights - recommendation - caveats - decision ask - next steps E. Meeting plan Create a meeting agenda for presenting the analysis and getting a decision. F. Executive summary Write a direct summary with: - strongest insight - weakest evidence point - biggest communication risk - biggest decision risk - first message to rewrite - first caveat to clarify - one operating principle for data storytelling Rules: - Do not let analysis stay as a list of charts. - Do not hide caveats or uncertainty. - Do not use technical language where business language is needed. - Use [NEEDS STRONGER EVIDENCE], [NEEDS CAVEAT], [NEEDS STAKEHOLDER CONTEXT], [NEEDS DECISION OWNER], [NEEDS RECOMMENDATION], or [NEEDS ACTION PLAN] where required. - The final communication must make analysis easier to understand, trust, and act on.

#241AI-Assisted Data Cleaning Workflow Designer

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, BI analysts, spreadsheet users, Python users, SQL analysts, analytics teams, consultants, and anyone cleaning messy datasets with AI support.

Use AI to plan and speed up data cleaning while preserving raw data, documenting assumptions, validating transformations, and keeping a human review layer.

You are an AI-assisted data cleaning workflow designer. Build a safe workflow for using AI to clean the dataset below without losing accuracy, auditability, or human judgment. Context: AI tool to use: [AI TOOL] Dataset name: [DATASET NAME] Dataset source: [SOURCE] File or table format: [CSV / XLSX / SQL TABLE / API / OTHER] Business purpose: [PURPOSE] Rows and columns, if known: [ROWS / COLUMNS] Key fields: [KEY FIELDS] Known data issues: [ISSUES] Cleaning tool: [EXCEL / GOOGLE SHEETS / SQL / PYTHON / R / POWER QUERY / OTHER] Sensitive data concerns: [SENSITIVE DATA] Expected clean output: [OUTPUT] Human reviewer: [REVIEWER] Design the workflow: 1. Safe setup Create rules for: - preserving raw data - removing or masking sensitive fields before AI use - working with samples instead of full data when needed - documenting every change - separating AI suggestions from approved cleaning rules - versioning cleaned outputs 2. AI cleaning task map Identify which tasks AI can support: - detecting messy columns - suggesting cleaning rules - writing formulas - generating SQL cleanup logic - generating Python cleaning code - identifying possible duplicates - creating category mappings - writing data quality checks - drafting cleaning documentation 3. Human review gates Define which tasks require human approval before execution: - deleting rows - changing business categories - imputing missing values - removing outliers - merging duplicate entities - changing metric logic - handling sensitive data 4. Cleaning prompt pack Write 5 short prompts to ask AI for: - initial data profiling - missing value treatment - duplicate handling - category standardization - quality checks 5. Validation plan Create checks for: - row count before and after cleaning - missing values - duplicate keys - category values - numeric ranges - date ranges - source totals - sample record review 6. Final cleaning log Create a documentation template with: - issue - AI suggestion - human decision - rule applied - rows affected - validation result - reviewer - date Rules: - Do not let AI change raw data directly. - Do not upload sensitive data unless it is approved and safe. - Do not accept AI cleaning rules without validation. - The workflow must make cleaning faster while keeping the analyst accountable. --------------------------------------------------------------------------------

#242AI SQL Generation and Validation Loop

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONSQL analysts, BI analysts, analytics engineers, data analysts, RevOps teams, finance analysts, and anyone using AI to write database queries.

Use AI to generate SQL from business questions, then validate schema, joins, filters, metrics, grain, performance, and business logic before trusting the query.

Act as an AI SQL workflow architect. Create a safe workflow for generating, reviewing, and validating SQL with AI. SQL context: AI tool: [AI TOOL] Database dialect: [POSTGRES / BIGQUERY / SNOWFLAKE / SQL SERVER / MYSQL / OTHER] Business question: [QUESTION] Decision supported: [DECISION] Tables available: [TABLES] Schema information: [SCHEMA] Expected output: [OUTPUT] Metric definitions: [METRICS] Expected grain: [GRAIN] Filters: [FILTERS] Known data issues: [ISSUES] Performance constraints: [CONSTRAINTS] Build the AI SQL loop: A. Business-to-SQL prompt Create a prompt that asks AI to translate the business question into: - required tables - required fields - join plan - metric logic - filters - expected grain - final SQL B. Query review prompt Create a second prompt that reviews the generated SQL for: - wrong joins - missing filters - wrong aggregation - duplicate inflation - date logic errors - null handling - denominator mistakes - dialect-specific syntax issues C. Validation query pack Ask AI to generate validation queries for: - row counts - duplicate keys - missing join keys - unmatched records - metric totals - date coverage - sample records D. Human checks Define what the analyst must verify manually: - schema accuracy - metric definition - table relationships - source of truth - business assumptions - sensitive fields - query result reasonableness E. Final query handoff Create a documentation block explaining: - what the query returns - what it excludes - assumptions - caveats - validation status Rules: - Do not run AI-generated SQL in production without review. - Do not trust table or column names invented by AI. - Do not approve a query only because it runs. - The workflow must produce SQL that is readable, validated, and business-aligned. --------------------------------------------------------------------------------

#243AI Exploratory Data Analysis Copilot Plan

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, product analysts, growth analysts, BI teams, consultants, finance analysts, operations analysts, and anyone exploring datasets faster with AI.

Use AI as a structured EDA copilot for profiling data, finding patterns, suggesting charts, generating hypotheses, and documenting caveats.

You are an AI EDA copilot designer. Build a workflow that helps an analyst explore a dataset systematically while avoiding false insights and overclaiming. EDA context: AI tool: [AI TOOL] Dataset description: [DATASET] Business question: [QUESTION] Primary metric: [METRIC] Date fields: [DATE FIELDS] Categorical fields: [CATEGORICAL FIELDS] Numeric fields: [NUMERIC FIELDS] Segments: [SEGMENTS] Known data issues: [ISSUES] Analysis tool: [SQL / PYTHON / R / EXCEL / BI TOOL] Expected output: [EDA NOTES / REPORT / DASHBOARD PLAN] Create the AI-assisted EDA workflow: 1. EDA planning prompt Write a prompt that asks AI to create an EDA plan with: - data profiling - missingness checks - duplicate checks - distributions - trends - segment comparisons - anomalies - correlations - seasonality - business questions 2. Chart recommendation prompt Write a prompt that asks AI to recommend visuals for each EDA question. 3. Pattern interpretation prompt Write a prompt that turns observed patterns into: - possible insight - alternative explanation - data quality explanation - caveat - follow-up analysis 4. Hypothesis generation prompt Write a prompt that creates testable hypotheses from EDA observations. 5. Human validation checklist Create checks for: - sample size - segment size - data quality - outliers - incomplete periods - causal overclaiming - business context 6. Final EDA output Create a template for: - observations - evidence - interpretation - caveats - hypotheses - next steps Rules: - Do not let AI invent findings from data it has not seen. - Do not treat EDA patterns as final conclusions. - Do not accept AI chart suggestions without checking metric grain. - The workflow must improve speed while preserving analytical judgment. --------------------------------------------------------------------------------

#244AI Dashboard Planning Assistant

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONBI analysts, dashboard builders, analytics managers, Power BI/Tableau/Looker users, product teams, finance teams, operations teams, and reporting teams.

Use AI to translate stakeholder needs into dashboard requirements, layout, KPI hierarchy, chart choices, filter logic, QA checks, and documentation.

Act as an AI dashboard planning assistant. Help me use AI to design a dashboard before building it in a BI tool. Dashboard context: AI tool: [AI TOOL] BI tool: [POWER BI / TABLEAU / LOOKER / METABASE / EXCEL / OTHER] Dashboard topic: [TOPIC] Audience: [AUDIENCE] Business decisions: [DECISIONS] KPIs: [KPIS] Available data sources: [DATA SOURCES] Required filters: [FILTERS] Required drilldowns: [DRILLDOWNS] Current reporting pain: [PAIN] Refresh cadence: [REFRESH] Known caveats: [CAVEATS] Build the AI dashboard workflow: A. Requirement extraction Create a prompt that asks AI to convert stakeholder notes into: - dashboard purpose - users - decisions - KPIs - filters - drilldowns - must-have views - out-of-scope items B. Layout design Create a prompt that asks AI to design: - page structure - visual hierarchy - KPI cards - chart sections - exception tables - notes and caveats - action area C. Chart selection Create a prompt that asks AI to choose the best chart for each question and explain what charts to avoid. D. QA checklist Create a prompt that asks AI to generate dashboard QA checks for: - metrics - filters - visual logic - refresh - permissions - source totals - caveats E. Human review rules Define what the analyst must validate before building: - metric definitions - stakeholder decisions - source data - security - dashboard scope - chart interpretation Rules: - Do not let AI choose dashboard metrics without decision context. - Do not build the dashboard before validating KPI definitions. - Do not include sensitive drilldowns without access review. - AI should speed up planning, not replace BI design judgment. --------------------------------------------------------------------------------

#245AI Report Writing from Analysis Notes

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, consultants, BI teams, finance teams, product analysts, marketing analysts, operations teams, and anyone writing recurring or executive reports.

Use AI to convert analysis notes, tables, and chart observations into clear reports while preserving evidence, caveats, uncertainty, and analyst control.

You are an AI-assisted analytics report editor. Create a workflow for turning analysis notes into a stakeholder-ready report without losing accuracy. Report context: AI tool: [AI TOOL] Audience: [AUDIENCE] Report type: [EXECUTIVE SUMMARY / MEMO / EMAIL / SLIDES / DASHBOARD NOTES] Business question: [QUESTION] Analysis notes: [PASTE NOTES] Metrics: [METRICS] Tables or charts: [TABLES / CHARTS] Recommended action: [ACTION] Known caveats: [CAVEATS] Tone: [DIRECT / FORMAL / EXECUTIVE / SIMPLE] Length requirement: [LENGTH] Build the workflow: 1. Source material organization Ask AI to classify inputs into: - facts - findings - insights - recommendations - caveats - open questions - weak evidence 2. Report draft prompt Write a prompt that asks AI to produce: - headline - executive summary - key findings - evidence - recommendation - caveats - next steps 3. Accuracy review prompt Write a prompt that asks AI to check the draft for: - unsupported claims - overclaiming - missing caveats - unclear metrics - causal language - vague recommendations - missing owners 4. Analyst review checklist Create manual checks for: - numbers match source - chart interpretations are correct - caveats are visible - recommendation is supported - no invented facts - tone fits audience 5. Final report template Create a reusable report structure. Rules: - Do not let AI invent numbers, citations, or findings. - Do not remove caveats to make the report sound stronger. - Do not use AI-generated recommendations without analyst review. - The workflow must make reporting faster and more trustworthy. --------------------------------------------------------------------------------

#246AI Anomaly Detection Triage Workflow

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONBI teams, operations teams, finance analysts, product analysts, growth teams, monitoring dashboards, data quality teams, and analytics managers.

Use AI to triage unusual metric movements, spikes, drops, outliers, and alerts by separating data issues from real business events.

Act as an AI anomaly triage workflow designer. Build a process for using AI to investigate anomalies without jumping to false conclusions. Anomaly context: AI tool: [AI TOOL] Metric or dashboard: [METRIC / DASHBOARD] Anomaly observed: [ANOMALY] Time period: [TIME PERIOD] Normal baseline: [BASELINE] Segments affected: [SEGMENTS] Related metrics: [RELATED METRICS] Known business events: [EVENTS] Known data issues: [DATA ISSUES] Alert urgency: [URGENCY] Decision needed: [DECISION] Create the triage workflow: A. Initial anomaly summary Create a prompt that asks AI to summarize: - what changed - when it changed - how large it was - which segment was affected - what related metrics should be checked B. Data quality triage Ask AI to create checks for: - missing data - delayed refresh - duplicate records - tracking change - source system change - incomplete period - changed filter - join issue C. Business cause triage Ask AI to generate possible business explanations: - campaign - pricing - product release - operational issue - seasonality - market event - customer mix - capacity issue D. Investigation checklist Create a step-by-step checklist with: - query checks - dashboard checks - stakeholder questions - sample records - source validation - escalation path E. Decision output Create a summary template: - likely cause - confidence - action needed - owner - next check - caveat Rules: - Do not assume anomalies are real business changes before data checks. - Do not ask AI to invent causes without evidence. - Do not remove anomalies without review. - The workflow must turn alerts into disciplined investigation. --------------------------------------------------------------------------------

#247AI Data Documentation Generator

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, analytics engineers, BI teams, data governance teams, consultants, reporting teams, and organizations improving analytics documentation.

Use AI to generate data dictionaries, metric glossaries, table documentation, query explanations, dashboard notes, and analysis handoff docs.

You are an AI data documentation workflow specialist. Create a workflow for using AI to document datasets, SQL, metrics, dashboards, and analysis outputs. Documentation context: AI tool: [AI TOOL] Asset to document: [DATASET / SQL QUERY / DASHBOARD / METRIC / REPORT] Asset content: [PASTE SCHEMA / QUERY / METRICS / NOTES] Business area: [BUSINESS AREA] Audience: [ANALYSTS / STAKEHOLDERS / ENGINEERS / EXECUTIVES] Known definitions: [DEFINITIONS] Known caveats: [CAVEATS] Owner: [OWNER] Documentation format: [DATA DICTIONARY / README / GLOSSARY / USER GUIDE / HANDOFF] Build the documentation workflow: 1. Documentation scope Define what needs documentation: - purpose - source - fields - metrics - transformations - owners - refresh cadence - caveats - usage rules 2. AI documentation prompts Create prompts for: - data dictionary - metric glossary - SQL explanation - dashboard user guide - cleaning log - analysis handoff - caveat section 3. Accuracy controls Create checks to prevent AI from: - inventing field meanings - inventing owners - changing formulas - hiding caveats - creating unsupported definitions 4. Human review process Define reviewer roles: - analyst - data owner - metric owner - business stakeholder - governance owner 5. Final documentation template Create a reusable template with sections and update rules. Rules: - Do not let AI guess field definitions when meaning is unclear. - Do not publish documentation without owner review. - Do not omit limitations or usage boundaries. - Documentation must make analytics assets easier to trust and reuse. --------------------------------------------------------------------------------

#248AI Insight Generation with Human Validation

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, consultants, BI teams, product teams, marketing analysts, finance teams, operations teams, and insight review workflows.

Use AI to generate possible insights from analysis outputs, then filter them by evidence, business value, actionability, confidence, and risk.

Act as an AI insight generation and validation system. Help me generate possible insights from analysis results, then filter them so only strong insights reach stakeholders. Input: AI tool: [AI TOOL] Business question: [QUESTION] Audience: [AUDIENCE] Analysis outputs: [PASTE TABLES / CHART NOTES / FINDINGS] Metrics: [METRICS] Segments: [SEGMENTS] Time period: [TIME PERIOD] Business goal: [GOAL] Known caveats: [CAVEATS] Decision supported: [DECISION] Create the insight workflow: A. Insight generation prompt Write a prompt that asks AI to produce candidate insights. Each candidate must include: - insight - evidence - business meaning - affected segment - confidence - caveat - action implication B. Insight validation filter Score each candidate insight by: - evidence strength - decision relevance - business impact - actionability - novelty - confidence - risk of overclaiming C. Rejection criteria Define when to reject insights: - unsupported by data - only descriptive - low business relevance - causal overclaim - weak sample - data quality issue - not actionable D. Human review checklist Create manual review questions for the analyst. E. Stakeholder-ready output Produce: - top insights - evidence - caveats - recommendation - follow-up questions Rules: - Do not let AI turn every pattern into an insight. - Do not include unsupported explanations. - Do not remove caveats from stakeholder-facing insights. - The workflow must improve insight quality, not just generate more text. --------------------------------------------------------------------------------

#249AI Analyst Workflow Automation Map

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONAnalytics managers, data analysts, BI teams, consultants, founders, operations teams, data teams, and productivity improvement projects.

Identify which parts of a data analyst workflow can be automated with AI and which must remain human-owned.

You are an AI analytics workflow automation consultant. Map the analyst workflow below and identify where AI can save time safely. Workflow context: Analytics team or role: [TEAM / ROLE] Current workflow: [WORKFLOW] Recurring tasks: [TASKS] Tools used: [TOOLS] Data sources: [DATA SOURCES] Pain points: [PAIN POINTS] Quality risks: [RISKS] Security constraints: [SECURITY] Skill level of users: [SKILL LEVEL] Target outcome: [OUTCOME] Map the workflow: 1. Workflow breakdown Break the workflow into stages: - intake - requirements clarification - data access - data cleaning - SQL generation - EDA - visualization - dashboard planning - report writing - documentation - QA - stakeholder communication - follow-up 2. Automation suitability Classify each task as: - safe to automate - AI-assisted with review - template-based - should remain human-owned - unsafe to automate - requires governance 3. AI use cases For each suitable task include: - AI task - prompt needed - input needed - output expected - human review step - risk - time saved - success criteria 4. Governance rules Create rules for: - sensitive data - production queries - metric definitions - stakeholder-facing claims - model outputs - documentation review 5. Implementation roadmap Create: - quick wins - medium-term workflow upgrades - advanced automation - tasks to avoid automating Rules: - Do not automate judgment-heavy decisions without human review. - Do not expose sensitive data unnecessarily. - Do not use AI outputs directly in production without validation. - Automation must improve speed without reducing trust. --------------------------------------------------------------------------------

#250AI Spreadsheet Analysis Automation Assistant

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONExcel users, Google Sheets users, business analysts, finance teams, operations teams, marketers, sales teams, and spreadsheet-heavy workflows.

Use AI to generate spreadsheet formulas, cleaning steps, pivot plans, QA checks, dynamic reports, and automation ideas without breaking workbook reliability.

Act as an AI spreadsheet automation assistant. Help me improve the spreadsheet workflow below with formulas, checks, and practical automation. Spreadsheet context: AI tool: [AI TOOL] Spreadsheet tool: [EXCEL / GOOGLE SHEETS] Workbook purpose: [PURPOSE] Sheet structure: [SHEETS] Columns: [COLUMNS] Current manual steps: [STEPS] Known issues: [ISSUES] Metrics needed: [METRICS] Outputs needed: [OUTPUTS] User skill level: [SKILL LEVEL] Automation allowed: [FORMULAS / PIVOTS / POWER QUERY / APPS SCRIPT / MACROS / NONE] Create the AI-assisted plan: A. Workflow diagnosis Identify: - repetitive steps - formula risks - cleaning issues - manual copy-paste risks - pivot refresh risks - missing QA checks - automation opportunities B. Formula prompt pack Write AI prompts to generate: - lookup formulas - metric formulas - date formulas - text cleaning formulas - error checks - dynamic summaries C. Spreadsheet structure Recommend tabs for: - raw data - clean data - lookups - calculations - dashboard - QA checks - documentation D. Automation options Rank options: - simple formulas - pivot tables - Power Query - Google Sheets QUERY - Apps Script - macros - external BI tool E. QA controls Create checks for: - formula errors - missing values - duplicate keys - row count changes - totals reconciliation - stale data Rules: - Do not automate before workbook logic is clear. - Do not use scripts if formulas or pivots are safer. - Do not hide formula errors with meaningless IFERROR logic. - AI should make spreadsheet work faster, safer, and easier to audit. --------------------------------------------------------------------------------

#251AI Code Review for Data Analysis Scripts

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, data scientists, analytics engineers, Python users, R users, SQL users, notebook reviewers, and analytics teams.

Use AI to review Python, R, SQL, or notebook analysis code for logic errors, data leakage, wrong assumptions, reproducibility, and missing validation.

You are an AI-assisted data analysis code reviewer. Review the code below for correctness, reproducibility, analytical risk, and business logic risk. Input: AI tool: [AI TOOL] Code language: [PYTHON / R / SQL / OTHER] Code or notebook section: [PASTE CODE] Business purpose: [PURPOSE] Dataset: [DATASET] Expected output: [OUTPUT] Key metrics: [METRICS] Known assumptions: [ASSUMPTIONS] Known issues: [ISSUES] Risk level: [LOW / MEDIUM / HIGH] Review the code: 1. Logic review Check for: - wrong filters - wrong joins - wrong aggregations - incorrect metric formulas - data leakage - wrong date handling - missing null handling - duplicate inflation - outlier mishandling - hard-coded assumptions 2. Reproducibility review Check for: - raw data overwritten - hard-coded file paths - missing random seed - undocumented transformations - manual steps - missing environment notes - unstable sorting - non-repeatable output 3. Validation review Check whether the code validates: - row counts - missing values - duplicates - date ranges - source totals - metric sanity - sample records 4. Business risk review Identify where code could mislead stakeholders. 5. Fix plan Create: - critical fixes - recommended fixes - optional improvements - validation tests to add Rules: - Do not rewrite code unless the user asks for rewritten code. - Do not approve code only because it runs. - Do not ignore business definitions. - The review must protect analysis from silent errors. --------------------------------------------------------------------------------

#252AI Data QA Checklist Generator

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONAnalysts, BI teams, analytics managers, data quality teams, consultants, finance teams, product teams, and recurring reporting workflows.

Use AI to generate project-specific QA checklists for datasets, SQL, dashboards, reports, metrics, forecasts, experiments, and stakeholder deliverables.

Act as an AI data QA checklist generator. Create a checklist for validating the analytics deliverable below before it is shared or used for decisions. QA context: AI tool: [AI TOOL] Deliverable type: [DATASET / SQL / DASHBOARD / REPORT / FORECAST / EXPERIMENT / SPREADSHEET] Business purpose: [PURPOSE] Audience: [AUDIENCE] Metrics: [METRICS] Data sources: [SOURCES] Known risks: [RISKS] Refresh cadence: [REFRESH] Decision impact: [LOW / MEDIUM / HIGH] Owner: [OWNER] Generate the QA checklist: A. Data QA Include checks for: - source completeness - row counts - missing values - duplicates - date coverage - freshness - source reconciliation - sensitive data B. Logic QA Include checks for: - metric definitions - formulas - filters - joins - aggregations - segmentation - time periods - caveats C. Output QA Include checks for: - chart clarity - table labels - executive summary - dashboard filters - report wording - recommendation support - uncertainty communication D. Risk-based priority Classify checks as: - must pass - should pass - warning - optional - human review required E. Sign-off process Create approval steps for: - analyst - data owner - business stakeholder - security or privacy, if needed Rules: - Do not create a generic checklist if project risks are specific. - Do not treat all QA checks as equally important. - Do not skip stakeholder-facing wording review. - QA must reduce decision risk, not just technical defects. --------------------------------------------------------------------------------

#253AI Analysis Request Intake Converter

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, analytics teams, BI teams, consultants, RevOps, product teams, finance analysts, and anyone managing analysis intake.

Use AI to turn messy stakeholder requests, meeting notes, Slack messages, or emails into structured analysis briefs.

You are an AI analysis intake assistant. Convert the messy stakeholder request below into a structured analysis brief that an analyst can actually execute. Input request: [PASTE EMAIL / SLACK / MEETING NOTES / RAW REQUEST] Context: AI tool: [AI TOOL] Business area: [AREA] Requester: [REQUESTER] Known data sources: [DATA SOURCES] Known dashboards: [DASHBOARDS] Deadline: [DEADLINE] Stakeholders: [STAKEHOLDERS] Constraints: [CONSTRAINTS] Create the analysis brief: 1. Request summary Rewrite the request in clear business language. 2. Decision extraction Identify: - decision to support - decision owner - decision deadline - action that will follow - urgency level 3. Analysis objective Create: - primary objective - supporting questions - expected output - scope - out of scope 4. Data requirements List: - data sources - fields needed - time period - segments - metrics - access needs - data quality concerns 5. Clarifying questions Create up to 8 questions. Prioritize questions that affect: - metric definition - timeframe - decision - scope - data availability 6. Analyst next steps Create a practical execution plan. Rules: - Do not accept vague requests like “pull insights” as complete. - Do not invent data sources. - Do not start analysis without decision context. - The output must turn messy input into an analyst-ready brief. --------------------------------------------------------------------------------

#254AI Metric Glossary and Data Dictionary Automation

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData governance teams, BI teams, analytics engineers, data analysts, metric owners, reporting teams, and self-service analytics programs.

Use AI to generate and maintain metric glossaries, data dictionaries, table docs, and field descriptions with review checkpoints.

Act as an AI documentation automation planner. Create a workflow for generating metric glossaries and data dictionaries with AI while keeping definitions accurate. Documentation context: AI tool: [AI TOOL] Assets to document: [TABLES / DATASETS / METRICS / DASHBOARDS] Schemas or field lists: [SCHEMAS / FIELD LISTS] Known definitions: [DEFINITIONS] Metric owners: [OWNERS] Business area: [AREA] Users: [USERS] Documentation location: [NOTION / CONFLUENCE / DATA CATALOG / README / OTHER] Update frequency: [FREQUENCY] Known definition gaps: [GAPS] Design the automation workflow: A. Input preparation Define what AI needs: - table names - field names - sample values - metric formulas - source systems - owners - known caveats - business context B. AI generation prompts Create prompts for: - field descriptions - metric definitions - formula explanations - usage rules - caveats - owner questions - glossary structure C. Review gates Define review steps for: - analyst - data owner - metric owner - business stakeholder - governance owner D. Change management Create rules for: - new fields - renamed fields - changed formulas - deprecated metrics - outdated docs - user feedback E. Quality checklist Create checks for: - no invented definitions - formula matches source - caveats included - owners listed - last updated date - examples included Rules: - Do not let AI guess business definitions from column names only. - Do not publish glossary updates without owner approval. - Do not hide deprecated metrics. - Automation must improve documentation speed while preserving trust. --------------------------------------------------------------------------------

#255AI Test Case Generator for Analytics Logic

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, analytics engineers, BI teams, spreadsheet users, SQL developers, metric owners, and analytics QA workflows.

Use AI to create test cases for formulas, SQL queries, classification rules, metrics, dashboards, and data transformations.

You are an AI analytics test case generator. Create test cases that verify whether the analytical logic below works correctly. Logic to test: [PASTE FORMULA / SQL / METRIC DEFINITION / CLASSIFICATION RULE / TRANSFORMATION] Context: AI tool: [AI TOOL] Business purpose: [PURPOSE] Expected output: [OUTPUT] Input fields: [FIELDS] Known edge cases: [EDGE CASES] Tool or language: [EXCEL / SQL / PYTHON / BI TOOL / OTHER] Risk level: [LOW / MEDIUM / HIGH] Generate test cases: A. Normal cases Create examples where the logic should work as expected. B. Edge cases Create cases for: - missing values - zero denominators - duplicate IDs - invalid categories - date boundaries - negative values - outliers - multiple matching rules - unmatched lookup keys - unexpected text format C. Failure cases Create examples where the logic should fail or return a warning. D. Expected results table For each test include: - test ID - input values - expected output - reason - risk if failed - validation method E. Review checklist Create questions the analyst should answer after running the tests. Rules: - Do not create only happy-path tests. - Do not ignore business rule edge cases. - Do not assume the formula or query is correct. - Test cases must make hidden logic errors easier to catch. --------------------------------------------------------------------------------

#256AI Data Pipeline Monitoring Summarizer

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData teams, analytics engineers, BI teams, data quality teams, operations dashboards, monitoring workflows, and reporting owners.

Use AI to summarize pipeline runs, refresh logs, data quality alerts, anomalies, failures, and operational risks into clear analyst or stakeholder updates.

Act as an AI data pipeline monitoring summarizer. Convert technical monitoring output into a clear status summary and action plan. Monitoring input: [PASTE LOGS / ALERTS / CHECK RESULTS / REFRESH STATUS] Context: AI tool: [AI TOOL] Pipeline or dashboard: [PIPELINE / DASHBOARD] Business impact: [IMPACT] Data sources: [SOURCES] Refresh cadence: [CADENCE] Known dependencies: [DEPENDENCIES] Audience: [DATA TEAM / BUSINESS USERS / EXECUTIVES] Urgency level: [URGENCY] Create the monitoring summary: 1. Status classification Classify the run as: - healthy - warning - failed - delayed - partial refresh - data quality issue - needs investigation 2. Key issues Summarize: - what failed or changed - when it happened - affected tables or dashboards - affected metrics - affected stakeholders - likely cause - confidence level 3. Business impact Explain: - what users can trust - what users should not use yet - what decisions may be affected - how urgent the issue is 4. Action plan Create: - immediate action - owner - next check - escalation path - stakeholder message 5. Technical follow-up List technical checks for the data team. Rules: - Do not turn technical logs into unsupported business conclusions. - Do not say everything is fine if quality checks failed. - Do not overwhelm business users with raw logs. - The summary must make data reliability status clear and actionable. --------------------------------------------------------------------------------

#257AI BI Dashboard QA Copilot

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONBI developers, dashboard owners, Power BI/Tableau/Looker users, data analysts, analytics managers, consultants, and dashboard launch reviews.

Use AI to review dashboard requirements, screenshots, metric definitions, visual choices, filters, caveats, and QA scenarios before release.

You are an AI BI dashboard QA copilot. Review the dashboard description below and generate a focused QA plan before release. Dashboard input: [PASTE DASHBOARD DESCRIPTION / REQUIREMENTS / SCREENSHOT NOTES] Context: AI tool: [AI TOOL] BI tool: [POWER BI / TABLEAU / LOOKER / OTHER] Audience: [AUDIENCE] Business decisions: [DECISIONS] Metrics: [METRICS] Data sources: [SOURCES] Filters: [FILTERS] Pages: [PAGES] Security rules: [SECURITY] Known risks: [RISKS] Create dashboard QA plan: A. Requirements check Verify whether the dashboard has: - clear purpose - defined audience - decision connection - KPI definitions - correct filters - caveats - refresh timestamp B. Visual QA Check: - chart type fit - title clarity - axis formatting - number formatting - sort order - color meaning - accessibility - clutter - tooltip usefulness C. Data QA Check: - source totals - metric formulas - date coverage - missing values - duplicate records - incomplete periods - refresh status D. Interaction QA Check: - filter behavior - drilldown behavior - page navigation - cross-filtering - reset states - export permissions E. Launch decision Classify dashboard as: - ready to launch - launch with caveats - needs fixes - not ready Rules: - Do not approve dashboards based only on visual appearance. - Do not ignore metric definitions and data quality. - Do not expose sensitive detail without security review. - AI should support dashboard QA, not replace user acceptance testing. --------------------------------------------------------------------------------

#258AI Data Storytelling Workflow

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, consultants, BI teams, finance teams, product analysts, marketing analysts, operations teams, and analytics leaders.

Use AI to turn analysis into stakeholder-ready narratives, executive summaries, slide outlines, recommendations, caveats, and Q&A prep.

Act as an AI data storytelling workflow designer. Create a workflow for turning analysis outputs into a clear stakeholder communication package. Storytelling context: AI tool: [AI TOOL] Analysis topic: [TOPIC] Audience: [AUDIENCE] Business question: [QUESTION] Decision needed: [DECISION] Findings: [FINDINGS] Metrics: [METRICS] Charts or tables: [CHARTS / TABLES] Known caveats: [CAVEATS] Recommended action: [ACTION] Output format: [SLIDES / MEMO / EMAIL / DASHBOARD NOTES] Build the storytelling workflow: 1. Message extraction Create a prompt that asks AI to identify: - main message - supporting insights - evidence - caveats - recommendation - decision ask 2. Narrative drafting Create prompts for: - executive summary - slide outline - chart captions - report narrative - recommendation memo - stakeholder email 3. Caveat review Create a prompt that checks for: - unsupported claims - missing caveats - causal overclaiming - too much jargon - weak evidence - unclear decision ask 4. Stakeholder Q&A Create prompts to prepare: - likely questions - objections - answers - what not to say - follow-up questions 5. Human final review Create a checklist for the analyst before sending. Rules: - Do not let AI invent findings or numbers. - Do not let AI remove uncertainty to sound confident. - Do not present recommendations without evidence. - AI should help communicate analysis clearly while the analyst owns accuracy. --------------------------------------------------------------------------------

#259AI Analyst Productivity Operating System

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONData analysts, analytics teams, BI teams, consultants, solo analysts, managers, RevOps teams, finance analysts, and data-driven operators.

Build a personal or team operating system for using AI across recurring analytics work, including prompt libraries, templates, QA habits, documentation, and review rules.

You are an AI productivity systems designer for data analysts. Build an operating system for using AI in analytics work safely and efficiently. Productivity context: Analyst role: [ROLE] Main tasks: [TASKS] Tools used: [TOOLS] AI tools available: [AI TOOLS] Recurring deliverables: [DELIVERABLES] Current bottlenecks: [BOTTLENECKS] Quality risks: [RISKS] Data sensitivity level: [LOW / MEDIUM / HIGH] Team size: [TEAM SIZE] Desired productivity gains: [GOALS] Design the operating system: A. AI use case library Create categories: - requirements clarification - data cleaning - SQL drafting - formula generation - EDA planning - chart selection - dashboard requirements - report writing - documentation - QA review - stakeholder communication B. Prompt templates Create reusable prompt templates for the top 10 recurring tasks. C. Review rules Define what must always be reviewed manually: - numbers - formulas - SQL joins - metric definitions - sensitive data - stakeholder recommendations - causal claims - data quality assumptions D. Workflow routines Create routines for: - daily analysis work - weekly reporting - dashboard updates - ad hoc requests - project handoff - post-project documentation E. Governance Create rules for: - safe data sharing - prompt storage - output validation - peer review - version control - stakeholder-ready outputs F. Success measures Define how to measure whether AI is improving productivity and quality. Rules: - Do not use AI as a replacement for analytical ownership. - Do not create a prompt library without QA rules. - Do not expose sensitive data casually. - The operating system must make analysts faster, more consistent, and more reliable. --------------------------------------------------------------------------------

#260Full AI Data Analysis Workflows and Automation Audit

AI DATA ANALYSIS WORKFLOWS & AUTOMATIONAnalytics teams, data analysts, BI teams, analytics managers, consultants, data-driven startups, RevOps teams, finance teams, product analytics teams, and operations teams.

Audit and rebuild AI-assisted analytics workflows across cleaning, SQL, EDA, dashboards, reporting, anomaly detection, documentation, insight generation, QA, automation, and analyst productivity.

Act as an independent AI data analysis workflow and automation auditor. Review my current analytics workflow and rebuild it into a faster, safer, more accurate AI-assisted operating system. Full context: Analytics role or team: [ROLE / TEAM] Business area: [AREA] Current workflow: [WORKFLOW] AI tools used: [AI TOOLS] Data tools used: [DATA TOOLS] Data sources: [DATA SOURCES] Recurring tasks: [TASKS] Current bottlenecks: [BOTTLENECKS] Current quality issues: [QUALITY ISSUES] Sensitive data constraints: [CONSTRAINTS] Current prompt library, if any: [PROMPTS] Dashboard or reporting process: [REPORTING] Documentation process: [DOCUMENTATION] QA process: [QA] Stakeholders: [STAKEHOLDERS] Desired outcome: [OUTCOME] Audit across 60 dimensions: 1. AI use case clarity 2. Task suitability for AI 3. Human review gates 4. Sensitive data handling 5. Prompt quality 6. Prompt reuse 7. Prompt documentation 8. Requirements intake automation 9. Data cleaning assistance 10. Data quality check generation 11. SQL generation workflow 12. SQL validation workflow 13. Formula generation workflow 14. Python or R code assistance 15. Code review process 16. EDA planning assistance 17. Chart recommendation assistance 18. Dashboard requirement planning 19. Dashboard QA assistance 20. Report drafting workflow 21. Executive summary generation 22. Insight generation 23. Insight validation 24. Recommendation drafting 25. Caveat communication 26. Anomaly triage 27. Forecast workflow support 28. Experiment workflow support 29. Metric documentation 30. Data dictionary automation 31. Query documentation 32. Dashboard documentation 33. Analysis handoff documentation 34. Test case generation 35. QA checklist generation 36. Stakeholder Q&A prep 37. Meeting note conversion 38. Action plan generation 39. Knowledge base creation 40. Workflow automation opportunities 41. Spreadsheet automation support 42. BI workflow support 43. Data pipeline monitoring summaries 44. Governance rules 45. Version control 46. Output auditability 47. Accuracy checks 48. Hallucination risk control 49. Causal claim control 50. Metric definition control 51. Review ownership 52. Team training 53. Adoption barriers 54. Time savings potential 55. Quality improvement potential 56. Risk of over-automation 57. Maintenance burden 58. Stakeholder trust 59. Productivity maturity 60. Overall AI analytics workflow maturity For each dimension provide: - score from 1 to 10 - diagnosis - evidence from my context - accuracy risk if ignored - productivity risk if ignored - recommended fix - priority - effort - owner needed - confidence level Then synthesize: A. Hard truth Explain the biggest reason the current AI analytics workflow may save time but still create errors, false confidence, or stakeholder risk. B. Rebuilt AI-assisted analytics system Create: - AI use case map - automation suitability matrix - prompt library structure - data cleaning workflow - SQL workflow - EDA workflow - dashboard workflow - reporting workflow - documentation workflow - anomaly triage workflow - QA workflow - human review rules - governance rules C. First 10 workflow improvements Rank the first 10 improvements. For each include: - issue - fix - AI role - human review role - expected time saved - risk reduced - owner D. Prompt library starter pack Create 10 reusable prompt templates for the highest-value analytics tasks. E. Safety and accuracy checklist Create a checklist for every AI-assisted analytics output before it reaches stakeholders. F. Executive summary Write a direct summary with: - strongest automation opportunity - highest-risk AI use case - first workflow to automate - first human review gate to add - first documentation upgrade - first QA habit to implement - one operating principle for AI-assisted analysis Rules: - Do not automate analytical judgment without human review. - Do not use AI-generated SQL, formulas, code, or insights without validation. - Do not expose sensitive data unless approved and necessary. - Use [NEEDS HUMAN REVIEW], [NEEDS DATA PRIVACY CHECK], [NEEDS SQL VALIDATION], [NEEDS METRIC REVIEW], [NEEDS QA CHECK], or [NEEDS STAKEHOLDER APPROVAL] where required. - The final system should make analysts faster while preserving accuracy, trust, and human accountability.

Unlock all 260 prompts