Trident Foresight — the full walkthrough.
Everything a merchant needs to install, configure, and get real value out of Foresight. If you're looking for quick answers, the Help page has FAQs. If you want to understand what everything does and why, this is the place.
1. Install and first-run onboarding
Install Trident Foresight from the Shopify App Store or directly via the install URL your account manager provides. The OAuth consent screen lists three access scopes:
- Read products — required, powers side-by-side matching of your catalog against competitors.
- Write products — required for one-tap defense. Without it Foresight is read-only.
- Read orders — optional but strongly recommended. Enables real per-SKU velocity from your actual sales so predictions show honest “$/week at risk” numbers instead of a placeholder.
After installation you land on a four-step onboarding modal: welcome, pick 1–3 competitors, we poll them immediately (10–30 seconds each), and a ready screen. Your Home page starts filling with detected changes on the second poll. Predictions typically start surfacing at ≥70% confidence within 3–7 days as we accumulate enough price history to compute per-product cadence.
2. Adding competitors (Shopify + eBay)
Foresight tracks three kinds of competitor: any Shopify (or Woo, BigCommerce, Magento) storefront that exposes a public product feed, any eBay seller username, and any eBay search phrase. All three feed the same predictions, alerts, and Action Center — you don't manage them separately.
Storefront
On Home → Add competitor, keep the picker on Storefront and paste a bare domain (e.g. example-competitor.com). We auto-detect the platform and start polling immediately. Merchant stores that disable their public /products.jsonendpoint, password-protect, or geo-restrict aren't trackable — the poll surfaces a no_products_json status on the competitor row.
eBay seller
Switch the picker to eBay seller and type the seller's username (the public “example-seller” portion, not the display name). Foresight tracks every live listing that seller has, detecting price drops, stock-outs, restocks, and new items. Each listing appears alongside your other products in the Recent Changes feed with an “eBay · seller-name” label.
eBay search
Switch to eBay search and enter a phrase like wireless charger. Foresight watches the top ~100 eBay results for that query and alerts when a new seller undercuts the market, when the median price shifts, or when a listing goes out of stock. Great for categories dominated by aggressive marketplace sellers.
Plan limits count all three the same way — an eBay seller and an eBay search each occupy one competitor slot.
3. The Home page and Action Center
Your Home page has three main surfaces:
- Action Center — a priority-ranked list of the threats, opportunities, setup tasks and warnings that need your attention today. This is where you spend most of your time.
- Competitors — the left column showing each tracked competitor, their tags, last poll status, and product count. Click any to drill into their catalog.
- Recent changes — the right column with the raw event stream: every price move, stock event, launch, and removal in reverse-chronological order. Filterable by competitor, event type, or watched-only.
Action Center card categories
- Setup (green) — one-time configuration nudges (sync catalog, grant scopes, configure guardrails, connect Slack). Non-dismissible when they block a critical feature.
- Threat (rose) — a competitor is likely to cut a price you sell. Includes the probability, expected magnitude, expected timing, and a “Review defense” button.
- Opportunity (emerald) — you're undercut on N% of matched SKUs, or you're cheapest on N% and can defend the position. Links to the Position dashboard.
- Attention (amber) — a competitor is likely to run out of stock, a webhook is failing, or polling has broken for one of your tracked stores.
- Upgrade (violet) — you've hit your plan limit and would benefit from Pro/Plus.
Every card has a primary action button. Setup cards navigate to the relevant page. Threat cards open the defense modal. Opportunity cards open the Position dashboard. Attention cards jump straight to the failing subsystem.
Cards you don't want back can be dismissed with the X (14-day cool-off). Cards can also be snoozed for 3 days via “Maybe later”. Setup cards for critical scopes and guardrails are intentionally non-dismissible — they represent policy gaps you should not defer.
4. How predictions work
Foresight's prediction model estimates the probability that a specific competitor will cut the price of a specific product within an expected window. The scoring uses three signals:
- Cadence.Every observed price change tightens the model's estimate of how often that product typically moves. If a competitor cuts Product X roughly every 30 days and it's been 28 days since the last cut, base probability is high. If it's been 5 days, base is low.
- Inventory drag.If a competitor exposes inventory quantities and stock is falling fast (≥20% drop over the last 14 days), the model adds a bonus — clearing inventory often precedes a price cut. Many storefronts don't expose inventory, in which case this signal is skipped.
- Sale-wave detection.If a competitor's overall sales activity is running at 2× their 90-day baseline, the model detects an active sale wave and adds a bonus — merchants on a discount push tend to cascade cuts across their catalog.
Combined via a logistic curve into a single probability score. Predictions only surface at ≥30% probability. Predictions at ≥70% are flagged as high-confidence and unlock the one-tap defense flow.
Impact scoring
Each prediction is scored for merchant impact — probability × relevance × price weight. Relevance is the title similarity score between the competitor's product and your own matched SKU. Price weight is a log-scaled function of the merchant's min-price. The Action Center ranks predictions by this composite score, not by raw probability, so high-confidence predictions on cheap SKUs you don't sell rank below moderate-confidence predictions on premium SKUs you do.
Revenue at risk
If you've granted read_orders, Foresight computes per-SKU weekly velocity from your actual Shopify orders (last 90 days, updated daily). Combined with expected drop magnitude and probability, this becomes an estimated $/week revenue at risk figure. Without read_orders, Foresight falls back to a 10-unit/week industry placeholder and labels the estimate as estimated_default_velocity. The Explain modal on each prediction shows which source the number came from.
5. One-tap defense with guardrails
Every Defendentry point in the app — Home's predicted-move tiles, the Action Center, the Insights playbook, and Matches rows — opens the same modal with the same three strategies. The picker is the source of truth for defensive pricing decisions; no matter where you click Defend from, you land on the same choice:
- Undercut 1% — cheapest competitor price × 0.99. The default.
- Match — exactly the cheapest competitor's price.
- Custom — type any target price lower than your current.
After you pick a strategy, the modal previews your current price, the target price, and the resulting drop percentage. Clicking Applywrites the new price to Shopify immediately via the Admin API — the change takes effect on every channel (storefront, marketplaces, active ads, in-progress carts). First-time only, a plain-English risk disclosure requires an “I understand” checkbox before the first apply.
Guardrails
Configure store-wide guardrails at Settings → Defense guardrails. Server-enforced — the client cannot override, and no defense can write a price that violates your policy.
- Price floor— never drop below this percent of the product's current price. E.g. floor = 70 means a defense can go as low as 70% of current, i.e. a max 30% drop.
- Daily reprice cap — total defensive reprices allowed per UTC day, store-wide. Safety brake against runaway loops from a model bug or competitor cascade.
- Max single-drop — hard 15% ceiling on any one defense. The client can propose any target; the server clamps.
- Excluded product IDs — Shopify product IDs (one per line) that are never repriced. For MAP-protected SKUs, brand-tier items, or contractual obligations.
- Excluded tags — same idea by tag. Saved now, enforced once tag sync ships.
Every applied defense is logged in reprice_jobswith the full inputs: source (prediction or reactive), guardrail state, before/after price, Shopify API response. This audit trail is defensible if a supplier or regulator asks “why did this price change on this date.”
Predictive vs reactive
The strategy picker is the same either way; only the trigger differs:
- Predictive— Home's Action Center flags matches where the model expects a competitor cut with ≥70% confidence. You defend before the cut lands.
- Reactive— Matches shows every SKU where you're already undercut (position badge reads Middle of pack or Most expensive). You defend after a cut has left you behind.
5a. Evidence snapshots — dated proof of every price cut
Every price-change event we record for a competitor triggers a second, best-effort fetch of the public product page HTML. The response body is gzipped and stored against the change_event. Result: for every price cut you see in the app, you can download the actual HTML page the competitor published at that timestamp — a self-contained artefact you can hand to a supplier, a distributor, or a regulator without them having to trust our system.
Where to find it: the Evidencechip appears next to the price on every price-change row in the Home “Recent changes” strip. Click it and the browser downloadsevidence-{event_id}.html — the raw response, served as an attachment so nothing renders inline on our domain (no XSS surface from arbitrary competitor JavaScript). Open it locally and you get the same page a customer would have seen at that moment.
Retention: HTML captures are pruned after 90 days to keep DB footprint reasonable — the underlying change_event stays for the full 180-day audit window. If you need longer, download the ones that matter and archive them yourself. Enterprise plans can extend on request.
Failure modes we handle without dropping the row: HTTP non-200 (row stored with capture_error= http_{status}), fetch timeout (8s), competitor pages exceeding 500KB (truncated). Stock-outs, launches, removals and inventory changes don't trigger captures — the change_event is fully audited on its own.
5b. Defense attribution — did it work?
After a defense fires, the Defenses page shows what actually happened. Seven days after each applied reprice we compute:
- Baseline — mean daily units sold over the 14 days before the price change.
- Post-window — actual units sold in the 7 (and later, 14) days after.
- Velocity delta — (post − expected) / expected × 100. Expected = baseline × 7.
- Revenue delta— (post_units × new price) − (expected_units × old price). Signed: negative means margin was sacrificed for volume that didn't materialise; positive means the defense paid off in cash terms.
Every defense lands in one of four outcome bands based on the 7d velocity delta:
- Grew — velocity up ≥10% vs baseline. The cut successfully pulled traffic.
- Held — velocity within −20% to +10%. You kept your ground; margin was the trade.
- Lost— velocity down >20%. The cut didn't help — either the competitor kept cutting, or demand shifted regardless of price. Consider tightening your floor guardrail.
- Insufficient data — fewer than 7 days of pre-window order data available. Wait for the orders sync to catch up.
Attribution requires the read_ordersscope. Grant it in Settings; the first sync runs within 24h and fills baselines for defenses applied thereafter. Historical defenses applied before the scope was granted can't be attributed retroactively — Shopify only exposes 90 days of orders and we need baseline windows on both sides of each apply.
5c. Price elasticity per SKU
For every SKU where we have enough paired price/units history, we fit a log-log OLS regression to estimate the price elasticity of demand — how much units move for every 1% change in price. Formula: ln(mean_daily_units) = α + β · ln(price), where β is the elasticity (typically negative for normal goods).
Requirements per SKU:
- ≥3 distinct historical price points (from
merchant_product_snapshots) - ≥3 days of order data at each price (from
merchant_order_lines_daily) - Fit R² ≥ 0.30 — below that the curve is too noisy to act on and we suppress the estimate
Where you see it: when you open the Defend modal for a SKU with a valid elasticity, a green “Expected units impact” box shows the predicted uplift for the chosen target price: e.g. “10% price drop × |β = 1.42| = ~14% more units.” It's a model estimate based on your own sales, not a guarantee — market changes and promotions confound the fit.
Recomputed nightly at 05:15 UTC after the orders sync and attribution passes have refreshed their underlying data. SKUs with insufficient data show no elasticity chip — that's the honest signal to wait for more price changes to accrue.
5d. Cost of goods — margin-aware defence
Attribution and elasticity are units/revenue based by default. Enter per-unit cost (COGS) for a SKU and every downstream surface flips to margin-aware:
- Defence modal— shows margin/unit at the target price, warns if the target is below cost (“you would lose £X per unit”), amber if margin drops under 10%.
- Defences page— a new “Margin change (7d)” KPI hero and per-defence margin delta row alongside revenue delta. Formula:
margin_delta = post_units × (applied_price − cost) − expected_units × (previous_price − cost). Cost is snapshotted at the moment the defence lands so later cost edits don't rewrite historical attribution. - Matches— inline “Set cost” chip on every merchant product row; once set, the chip shows current margin % with colour (rose <0, orange <15, emerald ≥15).
Cost is stored per SKU on merchant_products.cost_per_unit, never sent to Shopify or exposed on public share links. Any Analyst or higher role can set it — kept separate from Operator (defence apply) so a procurement contact can maintain COGS without inheriting price-change powers.
SKUs without a cost still show revenue delta; the margin KPI simply reads “— set cost on Matches” until you populate a few. No bulk uploader yet — one-at-a-time via the chip. CSV import is a targeted follow-up.
5e. Anomaly alerts — pushed when unusual
An hourly scan compares each competitor's cut-volume today to their 14-day rolling baseline. When today's count is more than 3σ above the mean (with a minimum floor of 5 cuts, to suppress noise), a new anomaly fires:
- Lands as an insight card on Home so the merchant sees it on next open.
- Posts to Slack immediately if the webhook is configured.
- Includes the top 3 sample cuts of the day so the merchant knows which products drove it.
Severity is warning at ≥3σ, criticalat ≥6σ. Anomalies are deduped per (store, competitor, type, day) — one firing per day, not one per hourly scan. Baseline uses a stddev floor of 1 so historically flat competitors don't fire on tiny bumps when their real σ is near zero.
MVP metric is cut-volume spike. Deep-cut spike and stock-out cascade land next as we validate the noise/signal ratio in production.
5f. A/B pricing tests
Analyze → Tests lets you compare two defence strategies side-by-side. Create a test, assign SKUs to cohort A and cohort B, then defend them from Matches however you want. Each apply is stamped with its cohort at apply-time; the Tests page rolls up per-cohort attribution (defences applied, revenue change, margin change, average velocity change, and grew/held/lost counts) as post-windows mature over 7 days.
Cohort assignment is deliberately manual — you choose the design of the test. Example: put your top 20 sellers in A and defend at −1%, put the next 20 in B and defend at −5%, wait a week, compare margin per cohort. If A beat B on margin without losing units, the smaller undercut is the right strategy for your top sellers.
Overlap between cohorts within a single test is refused server-side. A SKU can be in different cohorts of different concurrent tests — the most recently started test wins on apply-time cohort stamping. Ending a test (via the End button) freezes new stamping but leaves historical attribution rolling in for another 7 days.
6. Analytics, Position, and Insights
Three pages for three questions:
Position — “Am I winning or losing?”
Portfolio-wide split of your matched SKUs into cheapest / tied (within 1%) / undercut / no-data. Below it, a per-competitor breakdown (“vs Nike I'm cheapest on 40% of overlapping SKUs”), and a filterable product-level list with the gap %. Prices are FX-normalised to your store currency using daily-refreshed rates. This is the page to open first each morning.
Analytics — “What's happening in the market?”
Headline KPIs (events last 7d / 30d, competitor coverage, poll health, alert utilization). Daily activity chart stacked by event type. Top movers — the competitors with the most price changes, plus the products being cut most frequently across your entire competitor set. Model accuracy card showing prediction hit-rate and calibration per bucket. Backtest calibration you can run on demand against your last 90 days of tracked data.
Insights — “What does it mean?”
An AI-written narrative summary of the last 7 days, generated once per store per UTC day by Claude. Highlights the most aggressive competitor, the biggest drops, and one suggested next step in plain English. The same brief lands in your daily digest email if enabled. Cached — subsequent reads that day cost zero Anthropic tokens.
Today's playbook (Pro / Plus)
Below the narrative sits a prescriptive playbook — 2 to 4 concrete price recommendations per day. Each card carries:
- A Defend / Hold / Raise chip based on the merchant's current position vs the cheapest competitor
- Current price → target price (for Defend / Raise) with a % or £ delta
- A one-line rationale from the model
- Estimated weekly impact in your shop currency
- Review → button on Defend actions that deep-links straight into the Matches page with the Defend modal pre-opened for that SKU — one click from apply
The model is fed the same merchant-position data used in Analytics (matched SKUs, current prices, cheapest competitor per SKU) so recommendations are grounded in your actual catalog, not general commentary. Every price change still requires your explicit approval via the defense flow — playbook is a shortcut, not automation.
7. Matches — auto-matching, manual overrides, reactive defense
How matching works
The Matches page shows your products side-by-side with competitor products, matched by two complementary scores:
- Trigram similarity (Postgres
pg_trgm) — catches pairs that share obvious word overlap: “Vital Seamless Leggings” ↔ “Vital Seamless Legging.” Threshold 30%. - Semantic similarity(title embeddings via OpenAI, cosine distance in pgvector) — catches pairs that mean the same thing but read differently: “Vital Seamless Tee” ↔ “Essential Ribbed Top.” Threshold 78%.
A pair surfaces if EITHER score clears its threshold; the stored similarity is the higher of the two. Semantic matching runs behind the OPENAI_API_KEY env var and a nightly embed cron; without it, matching degrades cleanly to trigram-only. Auto-matcher re-runs daily to catch new products.
Each card shows YOUR product on top with a position badge — Cheapest, Middle of pack, or Most expensive — followed by every matched competitor product with its price, so you can see at a glance where you sit in the market. Prices are FX-normalised to your shop currency where a competitor sells in a different denomination.
Manual overrides
Auto-matching gets things wrong ~20% of the time on messy catalogs. Three controls per row:
- Pin — asserts “this competitor product is definitely the same as mine.” Pinned matches survive daily auto-sync rebuilds. Shows a “pinned” badge on the row.
- Not a match — explicit rejection. The pair is hidden and the auto-matcher will not resurface it on future syncs (rejections are stored as
pinned = falserows). - + Add match — top of each product group. Opens a search over every tracked competitor's catalog so you can pin a specific SKU the auto-matcher missed. Empty search? Try shorter or brand-only phrases; if the SKU still isn't there, that competitor may not stock it or may not expose it in their public feed.
Reactive defense — Defend price
Where you're not the cheapest (middle-of-pack or most-expensive positions), the card gets an orange Defend price button. Distinct from the Home defense flow (which is predictive, fires before a cut happens), Matches defense is reactive: it addresses cuts that have already left you behind.
The confirm modal offers three strategies:
- Undercut 1% — cheapest competitor price × 0.99. Default.
- Match — exactly match the cheapest competitor's price.
- Custom — type any target price lower than your current.
All three run through the same guardrail evaluator as predictive defense — floor %, exclusion list, daily cap, 15% max single-drop. The server refuses any target that would violate those, regardless of what the client sent.
Housekeeping
- Dismiss X — hide products you don't care about. Stored in browser localStorage; a “Show hidden (N)” button in the header restores them.
- Search — filter by your own product title.
- Sync — re-run the full merchant catalog pull + match rebuild. Preserves pins and rejections.
8. Integrations — Slack, email, webhooks, API
Slack
Settings → Slack webhook→ paste an incoming-webhook URL from your workspace. Alerts fire on matching events based on your alert rules. Test button sends a sample message. Rate-limited so a burst of events doesn't spam the channel.
Daily digest email
Settings → Daily digest email → enable + set the recipient. Sent at 14:00 UTC. Contains the AI narrative (Pro+) plus a grouped list of the last 24 hours of change events. Skipped on days with no changes. Preview button sends the current-state digest to your inbox immediately for verification.
Outgoing webhooks (Pro+)
Settings → Outgoing webhooks → add any HTTPS endpoint. HMAC-SHA256 signed payloads for every subscribed topic — price_change, stock_out, restock, new_product, prediction_high_confidence, defense_applied, and more. Every subscription has a Test button that fires a synthetic payload marked test: true. Auto-disables after 10 consecutive failures. Payload docs and a Node.js signature-verification snippet are in the same section.
Common integrations built on webhooks:
- Klaviyo or Attentive — trigger a winback flow to your list when
prediction_high_confidencefires for a product you sell. - Zapier or n8n — journal every
defense_appliedto Airtable or Google Sheets. - Custom Shopify Flow — wire a
stock_outto auto-flag a competitor product on your merchandising dashboard.
Public REST API
Settings → API tokens → create a token. Use as a Bearer against /api/v1/* endpoints: /api/v1/competitors, /api/v1/matches, /api/v1/changes. Token-scoped rate-limiting; tokens are hashed at rest.
CSV export
Export buttons on Home (competitors, changes) and Matches (product matches). Downloads immediately, RFC-4180 CSV, 10 000-row cap per export. For larger exports use the REST API with pagination.
8b. Chrome extension — track from any tab
The Trident ForesightChrome extension lets you add competitors from anywhere on the web without opening the app. Ideal for casual research: you spot a competing SKU while browsing, click the extension icon, and it's tracked before the tab closes.
Install
Search “Trident Foresight” on the Chrome Web Store and click Add to Chrome. Once installed, the icon lives in the browser toolbar.
One-time setup
- Open the app → Settings → API tokens → Create token. Name it something like “browser extension” and copy the token (starts with
tf_). Tokens are shown once — save it in a password manager. - Click the extension icon → paste the token into the field → close the popup. The token is saved to Chrome's per-extension local storage; you never enter it again.
Usage
- On any storefront (e.g.
allbirds.com), click the extension → Track this storefront. Polling starts immediately. - On any eBay seller page (
ebay.com/usr/foo) or search results (ebay.com/sch/i.html?_nkw=…), the extension auto-detects the shape and creates the right kind of competitor. - Success state shows “Tracked ✓” plus a link back into the app.
The extension respects your plan's competitor limit — hitting the limit returns a clear error. Revoke access anytime by deleting the API token in Settings.
9. Settings tour
- Plan — current tier, feature comparison, upgrade CTA. Payment via Shopify's billing system.
- Slack webhook — connect for real-time alerts.
- Daily digest email — enable/disable, set recipient, send preview.
- Alert rules — per-event-type toggles + minimum drop % threshold for price-change alerts. Optional tag filter to alert only for tagged competitors.
- Defense guardrails — floor %, daily cap, excluded IDs, excluded tags. Server-enforced.
- Outgoing webhooks — subscription list, add/remove/test. Pro+ only.
- Alert scope — watched-products-only toggle, quiet hours (skip alerts between two UTC hours).
- Locale — number and date formatting. Defaults to your browser locale.
- API tokens — create, revoke, view last-used timestamp.
- Legal — version of Terms + Privacy + DPA you accepted, and when. Kept for audit.
9b. Team roles and access
Every Shopify staff account with access to Trident Foresight lands in Settings → Team(which appears in the Configure section of the nav). Roles gate what each staff member can do:
- Viewer — read-only. Sees every page and every number, cannot apply defences, add competitors, or change guardrails.
- Analyst — Viewer + watchlist and exports. Still no writes to Shopify.
- Operator — Analyst + applies defences (subject to guardrails) and adds/removes competitors.
- Admin — everything, including changing guardrails, integrations, billing, and other members' roles.
Provisioning is automatic: the first staff member to open the app becomes Admin; every subsequent user starts as Viewer(safe default). Admins promote them from Settings → Team. Roles are enforced on the server — the client hides buttons for lower roles but that's cosmetic; the API returns HTTP 403 role_below_{min} if a mutation is attempted without the right role.
The last Admin cannot be demoted or removed — the app would lock itself out of role management. Promote someone else to Admin first if you need to hand over.
Emergency recovery — no active Admin
If your sole Admin leaves the company (or their Shopify staff account is deleted) and no other Admin has opened the app in 30 days, the Team page shows a red Claim Admin banner to any remaining staff user. Clicking it self-promotes to Admin, logged as team.admin_claimed in the audit trail. The 30-day window is enforced server-side; a race between simultaneous claimants is safe because the UPDATE is guarded by a NOT EXISTS check on active admins, so only one claim can land.
10. Plans, limits, and upgrading
| Feature | Free | Pro ($49/mo) | Plus ($149/mo) |
|---|---|---|---|
| Competitors tracked | 1 | 5 | Unlimited |
| Polling frequency | Daily (06:00 UTC) | Hourly | Priority hourly |
| Event retention | 30 days | 90 days | 180 days |
| Slack + email + push alerts | Slack + email | ✓ | ✓ |
| Side-by-side + semantic matching | Trigram only | ✓ | ✓ |
| AI daily narrative + playbook | — | ✓ | ✓ |
| Predictive + reactive defence | — | ✓ | ✓ |
| Defence attribution + elasticity | — | ✓ | ✓ |
| Outgoing webhooks + REST API | — | ✓ | ✓ |
| RBAC + A/B pricing tests | — | — | ✓ |
Upgrade via Plan in the sidebar (or the Upgrade pill in the top bar for free-tier merchants) → pick a tier → Upgrade to Pro. Payment handled through Shopify's recurring application charge system — appears on your regular Shopify bill. Cancel any time by uninstalling the app; the subscription ends immediately, no cancellation fee.
Annual billing is available at a 15% discount on Pro and Plus — email dean@tridentbi.com to switch. Charged as a single annual RecurringApplicationCharge on your Shopify bill.
11. What we collect, retain, and delete
Foresight receives from Shopify at install: your shop's *.myshopify.com domain, an offline access token, your product catalog (via read_products), your merchant email, and — if granted — aggregate order line-item quantities from the last 90 days (via read_orders). We do not store customer PII, addresses, payment details, or shipping information from orders.
You provide: the competitor domains/sellers/keywords you want to track, optional Slack webhook URL, digest email address, alert rules, guardrail settings, outgoing webhook URLs and secrets, API tokens (hashed at rest).
Retention is plan-dependent (see the table above). Configuration is kept for the life of the install.
On uninstall, all merchant data is permanently deleted within 48 hours in fulfilment of Shopify's shop/redact webhook. Encrypted database backups roll off within a further 30 days.
Full details: Privacy Policy and DPA.
12. Troubleshooting common issues
“Grant access” button doesn't open a Shopify consent screen
The button breaks out of the embedded iframe via window.open('_top')— App Bridge intercepts it. If nothing happens, check your browser is allowing pop-ups from the Shopify Admin domain. Failing that, log into your Partner Dashboard and confirm the requested scopes exceed what's already granted (otherwise Shopify silently completes without prompting).
Competitor shows status “no_products_json”
The competitor's storefront disables its public /products.jsonendpoint, is password-protected, or geo-restricts access. Nothing Foresight can do — the data isn't publicly available and we don't use scrapers.
Predictions aren't showing up after a week
Predictions need a few observed price changes per product to compute cadence. Very stable competitors (rarely change prices) may take 2–4 weeks. Check Analytics → Model accuracy — if Predictions · 7dis zero, the model hasn't yet found any product-competitor pair with enough history to surface at ≥30% probability.
Auto-match got a product wrong
Go to Matches → find the wrong pair → click Not a match (hides + prevents re-matching). If the correct competitor product is elsewhere in your tracked set, click + Add matchat the top of your product's group, search, and Pin it. Pinned matches survive daily rebuilds.
A defense is blocked with “below your X% floor”
Your Settings → Defense guardrails → Price floor is too high for the predicted magnitude. Either lower the floor (accept a larger max drop per defense) or accept the block — this is exactly the safety net doing its job.
Anthropic AI narrative returns “Requires setup”
An ANTHROPIC_API_KEYhasn't been configured on the Foresight server side. This is a global config issue, not merchant-side — contact dean@tridentbi.com.
Still stuck
Email dean@tridentbi.com with your *.myshopify.com domain and a description of what went wrong. Business-hours GMT, best-effort outside.

