← Seal CopilotCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Seal Copilot
Snapshot Sep 30, 2026 · 23:13 UTC · version 1.11.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "SKU-level analysis of where the catalog leaks money. Finds products with high views but low add-to-cart, hidden gems, and champions. Trigger on: \"which products convert worst\", \"best/worst products\", \"PDP problems\", \"qué producto vendo poco\", \"product page friction\", \"catalog audit\", \"view to cart by product\", \"productos más vistos\", \"what to fix in my catalog\", or any question about per-product performance.\n",
"included_files": [
{
"relative_path": "examples/output.md",
"size_in_bytes": 1869
}
],
"name": "product-friction",
"skill_md_contents": "---\nname: product-friction\ndescription: >\n SKU-level analysis of where the catalog leaks money. Finds products with\n high views but low add-to-cart, hidden gems, and champions. Trigger on:\n \"which products convert worst\", \"best/worst products\", \"PDP problems\",\n \"qué producto vendo poco\", \"product page friction\", \"catalog audit\",\n \"view to cart by product\", \"productos más vistos\", \"what to fix in my\n catalog\", or any question about per-product performance.\nargument-hint: \"[top-N SKUs]\"\nshort-description: 'Per-SKU analysis of products viewed but not added to cart. Use for \"which products underperform\", \"product friction\", \"qué productos no se venden\", \"catalog audit\".'\n---\n\n# Product Friction\n\nBefore writing your answer, read `examples/output.md` in this skill directory\nand match its density, structure and tone. It is the reference for what a good\nrun of this skill looks like.\n\nFind catalog leaks at SKU level: products that get viewed but not bought.\nBudget: ≤12 tool calls. Read the MCP call rules in\n`skills/seal-copilot/references/methodology.md` first — the property tools\nhave no `limit` or `sort_by`, and the raw tools are capped at 31 days and\n100 rows per page.\n\n## Step 1 — Discover the product property\n\nCheck `<state-dir>/<site_id>/profile.json` first: if\n`product_identifier` is set, use it and skip the probing below. Verify it\nstill appears in the data on your first breakdown call — if it does not,\ntracking changed, so re-probe and update the profile.\n\nOtherwise, item properties are where product identifiers live, so probe in\nthis order:\n\n1. `list_property_keys(table=conversion_items)`\n2. `list_property_keys(table=microconversions)`\n\nAccept the first key that exists, in this order: `sku`, `product_id`,\n`item_id`, `product_name`, `product_sku`, `id`, `name`. State which one you\nchose and which table it came from.\n\n**Confirm the same key appears on both the view event and the add-to-cart\nevent.** Different identifiers on different events is a common integration\nbug and makes the join meaningless. If the key exists on only one of them, or\nnone exists at all, stop and offer the `setup-audit` skill — name this as the\ngap that blocks per-SKU analysis.\n\nMap the event names via `list_microconversion_types`. Common variants:\n`view_item`, `product_view`, `product_viewed`, `view_product`; and\n`add_to_cart`, `add_to_basket`, `atc`, `cart_add`.\n\n## Step 2 — Pull view and cart pivots\n\nTwo calls, for the chosen property `P` over 30d:\n\n1. `get_property_breakdown(table=microconversions, conversion_type=<view-event>,\n property_key=P, period=30d)`\n2. `get_property_breakdown(table=microconversions, conversion_type=<atc-event>,\n property_key=P, period=30d)`\n\nEach response is pivoted **by UTM**: `data: [{ utm_source, utm_medium,\nutm_campaign, total, values: { <sku>: count } }]`. Sum `values` across all\n`data` rows to get one count per SKU. There is no revenue here and no\n`limit`: rank by view count yourself and work with the top 100 SKUs. State\nthat you truncated and that the user can ask for more.\n\n## Step 3 — Join and classify\n\nJoin the two pivots on `P`. For each SKU compute **view→AtC ratio** =\nadd_to_cart_count / view_item_count. Drop SKUs with fewer than 30 views in\nthe period (low confidence). Then classify:\n\n- **Champions** — top quartile by views AND ratio ≥ site median.\n Keep promoting; do not touch.\n- **Friction** — top quartile by views AND ratio ≤ 40% of site median.\n PDP problem suspected. These are the priority — drill in Step 5.\n- **Hidden gems** — bottom-half views AND ratio ≥ 2× site median.\n Demand is real but exposure is missing. Recommend pushing traffic\n (paid, homepage, email) before \"fixing\" anything.\n- **Dead stock** — bottom quartile views AND ratio ≤ site median.\n De-prioritize or retire from catalog if commercially possible.\n\nState the site median view→AtC ratio explicitly so the user can sanity-check.\n\n## Step 4 — Real cart→purchase per SKU (2–4 calls)\n\nDo not assume every SKU converts at the site's average cart→purchase rate.\nPull the actual purchased items:\n\n`get_conversion_items_raw(conversion_type=[purchase], period=30d, limit=100,\npage=1…N)` — one row per product inside each purchase, with `sku`, `price`\nand `quantity` always included. Page up to 4 times (400 item rows), then stop.\n\nCount purchases per SKU from those rows and compute AtC→purchase per SKU for\nthe friction candidates. **This is a sample**, not the full 30 days, whenever\nthe store exceeds 400 purchased items in the period — say so, and fall back to\nthe site-wide cart→purchase rate for any SKU that does not appear in the\nsample.\n\n## Step 5 — Drill the top 3 friction SKUs (4 calls, not per SKU)\n\n`get_property_breakdown` cannot be filtered by device or source, so use the\nraw event stream and read all three SKUs out of the same responses:\n\n1. `get_microconversions_raw(conversion_type=[<atc-event>], device_type=['mobile'],\n include_properties=true, period=7d, limit=100)`\n2. The same with `device_type=['desktop']`\n3. `get_microconversions_raw(conversion_type=[<atc-event>],\n utm_source=['<top paid source>'], include_properties=true, period=7d,\n limit=100)`\n4. The same for the top organic or direct source\n\nFor each friction SKU, compare its **share of add-to-carts** in each sample\nagainst its share in the overall 30d pivot from Step 2.\n\n- Share collapses on mobile only → PDP layout / image / CTA above-fold issue.\n Recommend a mobile PDP audit.\n- Share collapses in one source only → ad–product mismatch. Recommend pausing\n that source for this SKU or swapping creative.\n- Share is uniformly low everywhere → price, stock, reviews or description\n problem on the PDP itself.\n\n**These samples are 100 events over 7 days.** Label every Step 5 conclusion\n\"directional\". If a friction SKU does not appear in any sample, say the sample\nwas too thin to isolate the cause rather than inventing one.\n\n## Output format\n\n1. **Catalog summary line:** \"Analyzed N SKUs (≥30 views). Site median\n view→AtC = X%. Champions: A. Friction: B. Hidden gems: C. Dead: D.\"\n2. **Top 3 friction SKUs table:** SKU/name · views · AtCs · ratio · vs\n median · AtC→purchase (real or site-average, say which) · drill conclusion\n (mobile / source / uniform / sample too thin).\n3. **Top 3 hidden gems table:** SKU/name · views · AtCs · ratio · vs\n median · recommended traffic action.\n4. **Top 3 champions** (one line each, for awareness — do not act).\n5. **Estimated impact:** if friction SKUs reached site-median ratio,\n recovered AtC × that SKU's cart→purchase rate × its average price\n = €/month. State which rates were measured and which were assumed.\n6. **Verify:** re-run in 2–4 weeks after fixes ship; expect ratio to move\n toward median for the SKU touched.\n\n## What you do NOT do\n\n- Do not score SKUs with <30 views; mention them as \"insufficient sample,\n re-check next month\".\n- Do not recommend pausing a product based on one weak week — require 30d\n minimum.\n- Do not present a raw-tool sample as a full census. Name the window and the\n row cap whenever a number came from `*_raw`.\n- Do not invent stock or margin data; if the user wants margin-weighted\n ranking they must paste COGS.\n\n---\n\nLog the run in `<state-dir>/<site_id>/runs.jsonl` with exactly these fields\nand no others: `ts` (ISO timestamp, UTC), `skill`, `calls` (the number of\nSealmetrics calls you made, counted), `budget` (this skill's documented\nceiling, a number — `12` here), `verdict` (one of `on_track`, `watch`, `act`,\n`kpis_only`, `refused`, `error`, or the score for an audit), `scheduled`\n(boolean), `notes` (one line). The first real audit wrote `calls_used` and a\nfree-text verdict because this footer said \"calls used\" in prose; the field\nnames are the contract. Skip silently if the path is not writable.\n"
}SHA-256 of public snapshot: c5db7ac5dbd34a113bff91038bf76f5954dd1eb58946d16d4445eeaa3e251043