Create reports

On this page, the AI assembles your monthly or weekly report in one go and outputs it as an HTML slide deck. You can run everything — looking up the data, prechecking that it is available, collecting it, composing the slides, and rendering to HTML — with a single instruction, or step through it one stage at a time with confirmation.

About this page

Item	Details
What you can do	Specify a target period and comparison period to generate an HTML report bundling KPIs and slides. You can also save and reuse report settings, and look up the data sources available to you
Applies to	Reports (HTML slide decks). The contents center on Sponsored Products (SP) KPIs and Contribution analysis
Data & connection needed	Ad performance and search data for the connected account (no additional setup). If you distribute the finished HTML via Slack, etc., prepare the destination
Scope	Most prompts are report generation only (producing HTML and the like) and do not change ad settings. The exception is Prompt 3’s “save/delete report settings,” which is a record (persistence); deletion cannot be undone. Each prompt states its own in “Changes”

On ratio metrics, where the data comes from, and reconciling counts (important)

The month-over-month comparison, the year-to-date summary, and the weekly trend (Prompts 5–7) spell out where the data comes from and how to reconcile it, so that metrics are not misread.

• For ratio metrics such as ACoS and ROAS, the prompts require the absolute difference (percentage points) and the relative difference (rate of change) to be shown separately. The delta / changeRate values MCP returns differ in unit from tool to tool (absolute difference, relative difference, bps), so the prompts require them to be recalculated from the measured values rather than transcribed as-is.
• For the weekly trend (Prompt 7), there is no dedicated tool that returns a weekly series, so the prompt calls POST /bigquery/advertising-chart directly through call_picaro_api. get_dashboard does not return a weekly series, and /bigquery/advertising-performance ignores the period you specify, so neither is used.
• For both monthly and weekly work, the prompts require the number of periods actually retrieved (months, weeks) to be reconciled, and anything that could not be retrieved to be stated explicitly. rollup_status can fall to no_data for the whole day off a single ad type with no delivery, so it is not used to judge whether data is finalized — the per-report status is used instead.

Terms used on this page

• precheck … a lightweight step run before building a report to confirm in advance that the required data is available.
• Contribution … the degree to which each search term or ad contributed to sales. The Contribution slides are built from this data.
• HTML preview … a time-limited shareable URL that lets you open the generated report in a browser.
• YTD (Year to Date) … the figure accumulated from January 1 of the year through the present.
• ACoS (Advertising Cost of Sales) … ad spend ÷ ad-attributed sales. Lower is more efficient.
• ROAS (Return on Ad Spend) … ad-attributed sales ÷ ad spend. Higher is more efficient.

Pairing with Slack sharing

The finished HTML report is shareable via URL, so pasting it into Slack to distribute has become an established practice. To put your month-end report into the same shape every month, first save the settings under a name in Save and reuse report settings each month, then call it from your month-start Slack sharing workflow.

When to use this

• You want to create a monthly or weekly report in a single instruction by specifying the target period and comparison period
• You want to build the report step by step, confirming first that the data is available, while reviewing the contents and editing the slides
• You want to save the slide composition and thresholds as settings so you can create the same report shape every month
• You want to look up candidate data sources available to you when creating a new report setting
• You want to see a month-over-month comparison, a year-to-date (YTD) summary, or the past 3 months of trends in a table

Before you run

• Connected account … if you handle multiple accounts, confirm the target account is correct first.
• Target period and comparison period … many prompts take these. If you omit them, the most recent finalized period and the preceding period of the same length are used. Same-day and previous-day data can be unfinalized, so a recent finalized period is safest.
• Saved report settings (optional) … if you want the same shape every month, save your settings first in Prompt 3 so you can call them back on later generations.

Prompt quick reference

What you want to do	What you learn / what gets created	Changes	Prompt
Save and reuse report settings each month	The result of listing / viewing / saving / deleting	Save/delete settings (record)	Prompt 3
Look up data sources usable in reports	A list of candidate data sources (up to the top 5)	No change (lookup only)	Prompt 4
Build a month-over-month comparison report	A comparison table of this month / last month / delta for the key KPIs	No change (report generation only)	Prompt 5
Build a year-to-date (YTD) summary	A month-by-month KPI trend and annual cumulative table	No change (report generation only)	Prompt 6
Check the past 3 months of ad-sales and order trends	A week-by-week sales/order trend and hypotheses for the causes	No change (report generation only)	Prompt 7

This page goes only as far as “creating a report” (except saving settings)

As the quick reference shows, most prompts only generate a report (HTML and the like) and do not change ad settings. The exception is Prompt 3, which saves or deletes report settings on your account (save = record; deletion cannot be undone). For detailed specs, see Automation phases / Troubleshooting.

Prompt 1: Save and reuse report settings each month

Save your report settings under a name so you can call back the same settings each month when generating. Listing, viewing, saving, and deleting settings are all handled in this one prompt.

When to use — when you want to fix the slide composition and thresholds as settings so you can create the same report shape every month.

What you need — the setting name (e.g. monthly-standard / agency-client-a), the display name shown on screen, and the settings themselves (slide composition, thresholds, items to redact, etc.).

Manage my report settings:
- Show me the list.
- Show me the contents of {{SETTING_NAME (e.g. monthly-standard)}}.
- Save the slide composition, thresholds, and redaction settings together
  as {{SETTING_NAME (e.g. monthly-standard)}} (display name: {{DISPLAY_NAME (e.g. Monthly standard)}}).
- Delete {{SETTING_NAME (e.g. monthly-standard)}}.

Saved settings are reused in later data collection, slide composition,
and report generation.

What you can change — the setting name / display name / the settings themselves (slide composition, thresholds, items to redact, etc.) / the operation to run (list, view, save, delete).

What you get back — the result of whichever of listing / viewing / saving / deleting you ran. Saved settings are reused in later data collection, slide composition, and report generation.

Changes — saves or deletes report settings on your account (record). Saving persists the settings, and overwriting an existing name is confirmed in advance. Deletion cannot be undone, so it asks for a final confirmation. It does not change ad settings.

Next steps — saved settings can be called back from the report generation prompts on this page (Prompt 3 and Prompt 4).

---

Prompt 2: Look up data sources usable in reports

When you are creating new report settings or expanding existing ones, this returns up to the top 5 candidate data sources available in Picaro.

When to use — when you want to look up candidates for which data sources you can incorporate into a new report setting.

What you need — the kinds of data you are looking for (e.g. inventory,profit, comma-separated).

Use this when you want to build a new report but do not know which data to use.

For the theme(s) {{DATA_TO_LOOK_FOR (e.g. ACoS, search terms, SQP, inventory)}} (comma-separated; more
than one is fine), give me up to 5 candidate Picaro data sources per theme.

Explore in the following order.
1. Retrieve read_data_paths from get_openapi_spec (the list of paths on the read data side) and pick
   candidates by filtering path, summary, and required fields by the theme words.
   This is the only source of candidate names.
2. discover_report_sources does not return candidate names — only counts and confidence — so do not use it
   to enumerate candidates. Use it only as corroboration (found / confidence) when you pass a feature slug
   (product-detail, search-term-compare, label, and so on).
   Passing a metric name (ACoS and the like) returns not_found even when the data exists, so do not use it
   for that judgment.
3. Check the ingestion status of the target data with get_data_ingestion_status.
   rollup_status falls to no_data if even one report is no_data, so always judge from the detail in
   reports[].statuses.
4. If anything SQP-related is among the candidates, get the periods that actually exist with
   list_sqp_date_ranges.

For each candidate, state the following explicitly.
- The granularity available (account / portfolio / campaign / ASIN / search term, and so on).
  Judge it from the type of the required fields and the aggregation axis; do not write it from guesswork.
- The constraints on the period available (the latest date available, missing periods, whether two periods
  must be specified, the frequency values you can specify). Write only the range you actually retrieved,
  and do not assert anything about periods you have not confirmed.
- A short description of the candidate data (what decision it is used for)

Always finish with "the parameters to specify in the next step."
There is no argument for handing a data source name to the next prompt, so translate the candidate you
chose into concrete values for period / frequency / KPI tab / aggregation level.

Once you have chosen which data source to use, go on to one of the following.
- If you want to confirm the contribution of search terms or initiatives first, run the precheck on the
  contribution data and then move on to the real analysis
- If you want to build up from the report composition, use "Build the report step by step"

What you can change — the kinds of data you are looking for / the number of candidates (default is up to 5).

What you get back — a list of candidate data sources (with where each matched and how relevant it is) plus an example of how to wire one into your report settings.

Changes — no change (lookup only). It only returns candidates and does not save any settings.

Next steps — once you have decided which data sources to incorporate, add them to your report settings and save in Prompt 3.

---

Prompt 3: Build a month-over-month comparison report

Compares this month’s and last month’s SP ad performance and generates a visualized table.

When to use — when you want a table showing the month-over-month change in the key KPIs at a glance for the month-start business review.

What you need — this month (e.g. 2026-04; if omitted, the most recent finalized month) and last month (e.g. 2026-03; if omitted, the month before).

Compare the SP ad performance (sales / ad spend / ACoS / ROAS / orders) of {{THIS_MONTH (e.g. 2026-04)}} and {{LAST_MONTH (e.g. 2026-03)}}, and create a visualized table including the differences (absolute and %) ({{LAST_MONTH}} may be derived automatically as the month before {{THIS_MONTH}}).
Goal: grasp the monthly change and use it to decide next month's operating direction.

[Data retrieval]
- Get SP performance with analyze_ad_type_performance using campaign_types=["SP"], calling it twice — once for {{THIS_MONTH}} and once for {{LAST_MONTH}} — with period_start / period_end stated explicitly as the first and last day of the calendar month. Do not combine both months into one call.
- Check every time that the period in the response matches the month you requested, and write the period actually returned in the table's footnote. If they do not match, do not publish figures — report the mismatch.
- Do not use /bigquery/advertising-performance for a period-specified comparison. This endpoint discards from_date / to_date without warning and returns a different pair of calendar months while still returning HTTP 200. "This month vs last month" looks structurally correct, so the error is impossible to notice.
- Take all 5 metrics from the same response (metrics[] of analyze_ad_type_performance) and do not mix sources. get_dashboard does not return ROAS, is not SP-only, and its total sales is a separate aggregation that is tax-exclusive and includes organic — do not line it up in the same table.
- Check source_row_count and fetch_truncations, and if anything was truncated, state explicitly that "the total is understated."

[The full-month principle]
- If {{THIS_MONTH}} is still in progress, do not compare a partial month with a full month (it will always come out as "deterioration"). After confirming the last finalized day with get_data_ingestion_status, either
  (a) substitute the most recent full month and the month before it, or
  (b) state explicitly that it is a partial month and compare on a daily average (period total ÷ number of days).
  If you use a daily average, always write the numerator, denominator, and number of days in the table. Do not include unfinalized days in the day count (whether you include them can flip the sign).
- Do not use rollup_status to judge whether data is finalized (a single ad type with no delivery drops the whole day to no_data). Look at the status of the individual reports.
- Even between two full months, when the number of days differs (28/29/30/31), state the daily-average difference alongside the difference in absolute figures.

[Sanity check on order counts]
- For each month, calculate sales ÷ orders = average order value and check that the order of magnitude lines up with the last few months. A month that is off by an order of magnitude most likely has incompletely ingested orders, so do not publish a month-over-month figure for orders — state "orders cannot be compared due to inconsistent data." Do not fill the gap with an estimate.

[How to express differences]
- Amounts and counts: absolute = the difference in actual figures, % = the relative change ((this month − last month) ÷ last month).
- Ratio metrics such as ACoS and ROAS: absolute = the difference in percentage points (%p), % = the relative change. Do not write only one of them.
- Do not transcribe the delta / changeRate MCP returns as-is. The unit differs from tool to tool (absolute difference, relative difference, bps), so the same change comes out as a different number. Calculate the table's values yourself from the measured values in metrics[], and write the formula (numerator, denominator, number of days) in the footnote.

[Visualization]
- MCP does not return chart images. build_report_slide_spec goes only as far as a spec of chart type and series names — it does not render. Output the comparison table as a Markdown table.
- Use run_report_command mode=pptx only when a PPTX deliverable is required, but note that this is an account-wide report, not the SP-only comparison table. Do not confuse the two.

Output in the following 5-part structure.
1. What happened — the performance of the key metrics and the month-over-month change (absolute and %)
2. Why — if any metric worsened, check the driver (search terms / bids / CPC / CVR / budget / placements) with "cause diagnosis" and add 1-2 points
3. So what — what it means for the business (lost opportunity, room for improvement). State explicitly that any extrapolated estimate "is not a value returned by MCP"
4. What was done — state the initiatives carried out during the period if any. If they cannot be retrieved, write "the initiative log could not be retrieved" (do not conclude "no initiatives were carried out")
5. What should we do next — raise 1-2 areas that need "keep" or "revisit" next month, and route the ones to revisit to the bid-change proposal and approval flow

[Citing sources]
- In the table's footnote, write the tool names used, campaign_types, the period actually returned, source_row_count, and fetch_truncations.
- State explicitly that sales are tax-inclusive and attributed to SP on a 7-day click window.

[Guardrail]
- Create the same report next month and confirm whether the areas you flagged improved.

What you can change — this month / last month.

What you get back — a comparison table laying out the key KPIs (sales, ad spend, ACoS, ROAS, orders) for this month, last month, and the difference (absolute and %).

Changes — no change (report generation only). It does not change ad settings.

Next steps — to see it alongside the yearly trend, use Prompt 4.

---

Prompt 4: Build a year-to-date (YTD) summary

Displays the SP ad metrics from the start of the year through now as a summary.

When to use — when you want to summarize the year-to-date KPI trend and annual cumulative total for a quarterly or annual review.

What you need — the target year (e.g. 2026; if omitted, the current year).

Summarize the year-to-date SP (Sponsored Products) ad performance for {{TARGET_YEAR (e.g. 2026)}} in the
following 5-part structure.

Retrieval steps (always run in this order)
1. First, fix "the most recent finalized month" of the year. Check the data ingestion status monthly, and do not include the current month in the cumulative total because it is mid-month. Define "year to date" as running through the finalized months, and state the target period, the number of months, and the coverage rate at the top of the report
   🔴 Do not use rollup_status to judge whether data is finalized. A single ad type with no delivery drops the whole month to fully_missed / no_data even when every other report is completed (measured: a month with 13/16 completed still had rollup_status=fully_missed). Always look at the per-report status and judge on whether the reports your analysis needs (for SP: Sponsored Products / Sponsored Product Campaign / Targeting SP) are completed
   🔴 Viewed monthly, the set of reports differs from the daily view (Subscribe & Save and SQP appear only in the monthly view, and Suggested Bid does not appear). The monthly view also has out_of_range in addition to completed / in_progress / no_data / fully_missed. That value means "outside that report's retention period," not "ingestion failed," so do not use it as a reason to exclude a whole month
2. Always retrieve SP performance "one month at a time." Do not retrieve the whole year to date with a single period specification
3. Reconcile. Compare the sum of the monthly values against the value you get by specifying the same period in a single call, and if there is a gap, state both figures and the difference (amount and %) in the report. When they match, state "reconciled" explicitly
   🔴 In practice these two do not match. Verified over 3 months, the single-call version came out roughly 5% lower on ad spend and roughly 7% lower on impressions (at a yearly scale this becomes a difference on the order of tens of millions of yen).
   Use the sum of the monthly values for the cumulative total, and give the single-call value alongside it as a reconciliation reference. State explicitly which one you adopted. The cause of the gap has not been identified, so do not attach a speculative explanation
4. Limit the ad type to SP only. Do not treat account-wide values, or values including DSP / SB / SD, as SP values
5. Fix the source of each metric to a single one and state the source name in the report. The same ACoS takes different values depending on where it comes from, so do not change source midway
6. Check for truncation month by month. If the truncation information is not empty, state explicitly that "that month's total is understated."
   🔴 The campaign count (campaign_count / source_row_count) returns the same value however you change the period (measured: identical across single-month and 3-month runs). Do not read it as "the number of campaigns running in that month." If you need the monthly count of running campaigns, get it from another tool

Output
1. What happened — show the month-by-month trend of ad spend / ad sales / ACoS / ROAS / clicks / CPC, and the cumulative total through the finalized months, in a table. Do not mix months you could not retrieve or partial months into the cumulative total — set them apart outside the table and state them explicitly. The number of days differs by month (28/29/30/31), so give the daily average alongside when reading the trend
2. Why — decompose the movement in the cumulative values as ACoS = CPC ÷ RPC (cost per click ÷ ad sales per click), show numerically whether it is a CPC factor or an RPC (CVR, unit price) factor, and then classify the explanation as one of search terms / bids / CPC / CVR / budget (you may use "cause diagnosis")
3. So what — show the comparison against {{ANNUAL_KPI_TARGET (e.g. ACoS 15% or lower)}}. Treat this target as a value the user supplies (annual targets cannot be retrieved from MCP).
   🔴 If monthly KPI targets are stored in MCP, enumerate which metrics are stored before placing them alongside. In practice the ACoS ceiling was not set, and only a TACOS ceiling and a CPA ceiling were stored (and only for one month of the target year). Do not present a TACoS value as an ACoS target (a different metric with a different denominator). State how many months of KPI targets exist and how many of them overlap the target period (the coverage rate of the targets). If there is a gap, describe the business impact in one line
4. What was done — enumerate the initiatives carried out during the period. State the retrievable range of the change history (how many days back it goes) first, and if the target period is outside that range or 0 records were returned, do not write "no initiatives were carried out" — write "could not be retrieved from MCP (retrievable range: XX)."
   If you pass the change-history tool a start date beyond its limit, it automatically rounds up to the limit and returns the adjusted start date in a note, so quote the date in that note as-is. Declare at the top that the year to date cannot be covered, and write the initiatives section with its range limited to "only the last XX days can be confirmed"
5. What should we do next — if any month diverges widely, state explicitly that "a driver investigation is needed" and give the next actions in priority order

Execution conditions
- The period runs from January of {{TARGET_YEAR (e.g. 2026)}} through the most recent finalized month. Retrieve every month of monthly data, and state explicitly if any month is missing
- Unfinalized days can come back as zero-filled rows, so state explicitly that zero performance cannot be distinguished from un-ingested data
- Even a finalized month can have its values rewritten by a re-ingest (re-crawl / backfill). Do not present past figures as immutable (if a quarterly update differs from last time, that alone is not proof of a defect)
- If you produce a year-over-year comparison, align the number of months and days in the two periods. If you cannot align them, do not compare
- Update the same report each quarter and track how the gap to target moves

What you can change — the target year / the annual KPI target (e.g. ACoS 15% or lower, optional; specifying it lets the report show the gap against target).

What you get back — a table of the month-by-month KPI trend (sales, ad spend, ACoS, ROAS) and the annual cumulative total.

Changes — no change (report generation only). It does not change ad settings.

Next steps — for a comparison by month, use Prompt 5; for the recent weekly trend, use Prompt 7.

---

Prompt 5: Check the past 3 months of ad-sales and order trends

Displays the trend of Amazon ad-driven sales and order counts over the past 3 months.

When to use — when you want to gauge the recent up/down trend in ad sales and order counts and get a sense of what is driving it.

What you need — none (use it as is).

Show the Amazon ad-driven sales and order counts over the past 3 months as a weekly trend.
For weeks with a large increase or decrease, add a hypothesis for the driver, classified as one of
search terms / bids / CPC / CVR / budget / placements.
Goal: understand what lies behind the change in the trend and use it for the next operating decision.

Data retrieval (retrieve it this way)
- Get the weekly series from POST /bigquery/advertising-chart (frequency: "weekly") via call_picaro_api.
  Pass amazon_account_id / frequency / from_date / to_date in the body.
  get_dashboard does not return a weekly series even when you specify frequency=weekly — it returns a
  single period total — so do not use it for trend work.
  Do not use analyze_ad_type_performance with one long period specification (the longer the window, the
  more it under-aggregates without warning).
  Do not use /bigquery/advertising-performance — it discards the period you specify without warning.
- Align the period to week boundaries running Sunday to Saturday. Take the last Saturday that ended on or
  before {{ANALYSIS_BASE_DATE}} as the end, and the Sunday 13 weeks before it as the start. If you do not
  align to week boundaries, the partial weeks at the edges drop out entirely, without warning.
- Always reconcile after retrieval: does "the number of weeks returned × 7" match the number of days you
  requested? If not, an edge week has dropped out, so realign to week boundaries and retrieve again.
- Do not use the tooltip in the response as evidence of completeness. Not only does the tooltip fail to
  indicate gaps, it also shows weeks that do not exist in chart_data as the end point. Always count the
  rows in chart_data to judge.
- Use purchases for "ad-driven order count." order_count in the same response is the total order count
  (including non-ad orders) — do not confuse the two.
- Do not include unfinalized days in the final week. Check the ingestion status with
  get_data_ingestion_status.
  However, do not use rollup_status to judge whether data is finalized, since a single ad type with no
  delivery drops the whole day to no_data. Judge from reports[] on a per-report basis.

Mapping of response fields (do not fill gaps by guessing)
- Usable as-is: ad_sales (ad sales) / purchases (ad-driven order count) / ad_spend (ad spend) / acos / cvr /
  ad_clicks (clicks) / impressions / rpc (= ad_sales ÷ ad_clicks)
- Needs deriving: CPC is not returned. Derive it as ad_spend ÷ ad_clicks and note that it is a derived value.
- Do not use: the aov field in the response. Its value matches neither ad_sales ÷ purchases nor
  total_sales ÷ order_count, and its definition is not disclosed. Always calculate average order value
  yourself as ad_sales ÷ purchases.

Output
1. Weekly table — week (Sunday start) / ad sales / week-over-week / ad-driven order count / week-over-week /
   ad spend / ACoS / CPC (derived) / CVR / average order value (ad sales ÷ ad-driven order count, calculated
   yourself) / clicks / impressions
2. Sanity check — always calculate the average order value per week. If a week sits far outside the others,
   flag it explicitly as "suspected missing order data" and do not use that week's rate of change as grounds
   for a conclusion
3. Driver hypotheses — for weeks where ad sales or order counts moved by ±15% or more week over week,
   classify the driver as one of search terms / bids / CPC / CVR / budget / placements
   - Bids, CPC, and CVR can be judged from the same weekly source as above (CPC, CVR, clicks, impressions,
     ad spend), so you may state them definitively with the figures attached
   - Search terms, budget, and placements come from a different source and a different aggregation window,
     and cannot be put on the same basis as the weekly data (placements sit in a different table lineage
     with a different aggregation window / search-term retrieval is truncated / budget utilization breaks
     down as a unit over windows of 2 days or more).
     If you refer to them, state explicitly that they are "supporting hypotheses from a different window"
     and do not assert them

Finally, output the following three points.
1. Recommended actions — 1-2 improvement actions for the drivers trending worse recently, stating target,
   reason, priority (by Impact), expected effect, confidence, and risk
2. How to execute — if the driver is bids or CPC, connect to "cause diagnosis" or the relevant bid
   adjustment prompt; if it is search terms, connect to the negative-keyword prompts.
   ACoS takes divergent values depending on the source, so if you filter by a threshold, fix the source to
   one and state which tool's value it is
3. Measurement — on {{EVALUATION_DATE (e.g. 4 weeks after the initiative)}}, retrieve the same trend again
   with the same week boundaries and the same source as this prompt, and compare ACoS / CPC / CVR / average
   order value before and after the week the initiative ran.
   Whether the initiative actually ran cannot be tracked through Picaro's change history (the change-history
   tool returns 0 records under every condition), so confirm the execution date from the requester's own
   records.
   Take a measurement window longer than the attribution window (a mix of 7 and 14 days depending on ad
   type). The week immediately after execution looks understated because attribution is not yet complete

Execution conditions
- Retrieve the weekly data for the whole period, and always write the result of reconciling "weeks returned
  × 7" against the requested number of days in the body.
  If any week dropped out, also state the number of days lost and what percentage of total ad sales the
  ad sales in that week represent
- Whenever you produce a ratio, always state the numerator, denominator, and number of days
- Ad sales are tax-inclusive, the tax treatment of ad spend is undetermined, and total sales are
  tax-exclusive — do not present a ratio spanning these as a figure "on a consistent tax basis"
- Even finalized past periods can move on a re-crawl, so do not present figures as immutable
- With partial data, do not draw definitive conclusions about increases or decreases
- Read-only. Do not run write operations

What you can change — the analysis base date (optional; the day used as the origin for the week boundaries) / the date on which you measure the effect (e.g. 4 weeks after the initiative, optional).

What you get back — a week-by-week table of sales and order counts, along with hypotheses for what is driving the changes (search terms / bids / CPC / CVR / budget / placements).

Changes — no change (report generation only). It does not change ad settings.

Next steps — for the year-scale trend, use Prompt 6; to look at the link with your initiatives, use Log external events and initiatives to verify their impact.

---

Report generation pipeline

[Save report settings (optional, Prompt 3)]
   ↓
Look up data sources (optional, Prompt 4)
   ↓
Precheck (Step 1 of Prompt 2)
   ↓
Data collection
   ↓
Slide composition
   ↓
Render to HTML → Slack sharing

Prompt 1 (generate in one instruction) is a shortcut that runs the precheck → data collection → slide composition → HTML rendering above all at once.

Related categories

• Analyze where things stall from search to purchase (SQP) — the Contribution-data precheck uses the same mechanism as the SQP category
• Analyze high-performing search patterns with N-grams — dig into the data backing the Contribution slides
• Check KPIs on the dashboard — reports incorporate the dashboard’s KPIs as well
• Log initiatives — before/after slides reference the action log
• Plan your ad strategy — “cause diagnosis” breaks the driver of a worsening metric into 6 factors