Bloom Profit Analytics
Shopify profit insights
- Category
- Data & Analytics
- Primary Subcategory
- Self-Serve BI & Conversational Analytics
Integration details
Description
Bloom helps Shopify merchants understand store profitability without digging through dashboards. Ask ChatGPT for revenue, margins, marketing spend, net profit, order-level costs, or product and variant performance, and Bloom returns clear analytics from your connected store data. It is built for operators who want faster answers to practical questions: which products are most profitable, how fulfillment costs affect margin, how net profit is trending, or which connected store needs attention. Bloom keeps the workflow focused on read-only business insights, so teams can explore performance, spot margin issues, and make better day-to-day decisions from the data they already trust in Bloom.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Self-Serve BI & Conversational Analytics
- Secondary Subcategories
- None listed
- Brand
- Bloom Analytics
- Access
- Account required
- First tracked
- 2026-07-17
- Tool count
- 22
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Get alerts for Bloom Profit Analytics
Get updates when Bloom Profit Analytics’s Discoverability Score or category rank changes.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competing in ChatGPT Self-Serve BI & Conversational Analytics
View Category22 tools agents can invoke
Create a new operating expense, or update an existing one by `expense_id`, on Costs → Custom Expenses. Expenses flow into the P&L operating-expense lines within about a minute. FIELDS: name; amount (native currency, or a percentage when expense_type=Percentage); category (one of the shop's expense categories, e.g. Marketing, Salaries, Rent, Maintenance, Tax, Interest, Professional Fees, Other COGS, Storage Fee, IT & Software, Other); expense_type Fixed|Percentage; percentage_of (total_sales|tax|shipping|gross_sales|net_sales|product_cost|ads_spend) for Percentage; recurrence Monthly|Daily|Weekly|Yearly|One Time — the amount is per recurrence period and spread per day; platform is always Shopify — Amazon operating expenses cannot be created or updated with this tool; start_date YYYY-MM-DD; end_date YYYY-MM-DD or omit for ongoing (One Time sets end_date = start_date). On update only the fields you pass change. Overlapping date ranges for the same name+category+platform are rejected. Preview shows current vs new values. CONFIRMATION (required): call once WITHOUT `confirm` to get a preview of exactly what will change and a short `confirmation_code`. Show the preview to the merchant and ask them to approve it. Only after they explicitly say yes, call again with `confirm: true` and the code. Never confirm on the merchant's behalf. After applying, tell them where in the Bloom app to verify (`verify_in_app`). This tool only creates or updates — it never deletes. MULTISTORE: on accounts with more than one shop you must also pass `shopify_domain` matching the target store; call `list_shops` to see domains.
upsert_custom_expense
Guide to this Bloom connector: what each tool answers, example questions merchants ask, how the cost-setting tools' preview → confirm flow works, and how numbers should be read (currency, percentages, freshness). Call it when the merchant asks what you can do, how to use Bloom here, or when you are unsure which tool fits a question. No arguments; returns the full guide as markdown plus the current tool list.
get_started
Lists every Bloom shop reachable from this MCP token (the primary shop plus any associated multistore shops). Call this FIRST when the user names a store by display name ("the Acme store", "our EU site") — match their phrase against `shop_name` or `shopify_domain`, then pass the resolved `shop_id` to any other tool. If the user has multiple shops and does not specify one, ask which to use or fall back to `default_shop_id`. RESPONSE: { count, default_shop_id, shops: [{ shop_id, shop_name, shopify_domain, currency, reporting_currency, selected, is_primary }] }. `currency` is the shop's Shopify base currency. `reporting_currency` is what the other tools' returned amounts are denominated in — use it when comparing or converting amounts across shops.
list_shops
Bloom Pulse for the authenticated shop: the overall revenue-and-profit health check behind the Pulse briefing email, computed live. Best first call for "how is the business doing" — it already compares the period to a baseline and explains WHY numbers moved. CADENCE: daily = one day vs the same weekday last week; weekly = Mon–Sun week vs prior week (+ 4-week trailing average and the 5 marketing gates); monthly = last complete month vs prior month (+ same month last year). `date` picks the reference day (default: yesterday in shop timezone); the period containing it is used. RESPONSE SECTIONS: meta (period, baseline, currency, severity green/yellow/red); pl (revenue, gross_profit + margin, contribution, orders, visitors — each with value, baseline, delta_pct, display); revenue_bridge (ranked drivers: visitors / conversion / orders / AOV); profit_split (volume vs rate effect, rate_breakdown); ads_blended (spend, ROAS, break-even ROAS, profitable?); new_customers (count, CAC, first-order profit after CAC); products (dominant mover, refund concentration, margin trap); anomalies (up to 3, EWMA z-score); flags (quiet_day, low_volume, data_gaps, caveats). If the emailed briefing for that period exists, `narrative` carries its headline/sections. Values are in the shop's reporting currency. Percentages already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_bloom_pulse
Profitability by shipping country for the authenticated Bloom shop over a date range, with an automatic comparison to the same-length period immediately before. Same engine as the Country Profit page. VIEWS (pick via `view`): - before_ads: country profit BEFORE ad spend (CM2 = net revenue - product/shipping/handling/transaction/tariff costs). Columns: Orders, Net Revenue, cost breakdown, CM2, CM2 %, AOV, Rev Share, Profit/Order, Shipping Impact, Top Cost Driver, Net Revenue Change, CM2 % Change, Status, Suggested Action. - after_ads: country profit AFTER ad spend (CM3 = CM2 - Ad Spend). Every country with orders is included; Ad Spend may be 0. Columns: Net Revenue, costs, CM2, Ad Spend, CM3, CM3 %, Clicks, Conversions, Conversion Value, ROAS, CPA, CM3 Change, ROAS Change, Status, Suggested Action. WHICH VIEW: if the merchant does not say before/after ads ("which countries are most profitable", "how profitable is the US"), use after_ads (default) and report BOTH numbers from the same row, labelled: "profit before ad spend (CM2)" and "profit after ad spend (CM3)". Never present one of them as just "profit" without the label. `insights` carries short auto-generated observations (type info/warning/danger/success). Tune with `margin_threshold` (CM2 %, default 20) and `cm3_threshold` (CM3 %, default 20). Rows sorted by Net Revenue (before_ads) or CM3 (after_ads) DESC; no pagination, one row per country. RESPONSE: { view, currency, count, rows, insights }. Values in reporting currency; percentages already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_country_profit
The merchant's own saved dashboards (My Dashboard) for the authenticated Bloom shop. USAGE: call without `dashboard_id` to list dashboards and their widgets. Then call with `dashboard_id` + start_date/end_date to compute every widget on that dashboard for the range. Widget payloads mirror the UI: kpi { name, value, formatted }, donut { center, segments }, line/bar { x, series }, table { columns, rows }, cohort { columns, rows }, or { error: true }. RESPONSE: { dashboards: [...] } or { dashboard: { id, name }, period, currency, widgets: { <widget_id>: payload } }. Values in reporting currency. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_custom_dashboards
Customer cohort / retention table for the authenticated Bloom shop — the Cohorts tab on the Customers dashboard. Customers are grouped by first-order period (rows) and tracked over subsequent periods (columns). METRICS (`metric`): Customer (count of returning customers), Customer retention rate (%), Gross Sales, Net Sales, Total Sales, Average order value, Amount spent per customer (always cumulative). `group_by` sets the period (default month). RETENTION %: for ANY question about retention percentage ("what % of customers came back after N months") ALWAYS use metric="Customer retention rate". It adjusts for cohort maturity (a cohort too young to have completed Month N is left out of that column). NEVER derive retention from metric="Customer" with percentage=true — its Total row divides by all first-order customers including immature cohorts and understates retention. CUMULATIVE: only Gross Sales, Net Sales, Total Sales accept cumulative=true (same as the UI). Customer counts are never cumulative — a returning customer would be counted once per period they returned, which can exceed the cohort size. "How many April customers returned by Month 3" = distinct returners is NOT answerable by summing Month 0..3 cells. RESPONSE: { metric, group_by, currency, columns, values }. columns = ["First Order Date", "All Time", "First Order", "Month 0", "Month 1", …]; values = one array per row, first row is the Total. Cells are numbers, or "12.34%" strings in percentage mode. Money in reporting currency. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_customer_cohorts
Aggregated profit-and-loss summary for the authenticated Bloom shop, grouped by day/week/month/year. Includes a 'Total' rollup row summarising the entire date range. USAGE: 1. `group_by: "auto"` (default) picks day/week/month/year by date span (≤7d=day, ≤31d=week, ≤366d=month, else year). 2. Pick only the fields you need via `fields`. `date` is always included. 3. No pagination — period count is bounded (≤365 daily rows worst case). AVAILABLE FIELDS: date, gross_merchandise_value, price_cut_mark_down, price_cut_pct, discounts, discounted_orders_pct, discount_value_pct, gross_revenue, gross_orders, gross_aov, refunds, return_value_pct_gross, orders_returned_pct, shipping_revenue, shipping_revenue_pct_gross, taxes, taxes_pct_gross, net_revenue, net_orders, net_aov, cogs, product_cost, other_cogs, cm1, cm1_pct, order_fulfillment_costs, shipping_cost, handling_cost, tariff_cost, payment_processing_fees, cm2, cm2_pct, marketing_spend, meta_ads, google_ads, tiktok_ads, snapchat_ads, pinterest_ads, non_ad_marketing_costs, cm3, cm3_pct, mer, amer, new_customers, beroas, cac, mpr, ampr, first_order_cm, first_order_cm_per_customer, marketing_pct_sales, operating_expenses, salaries, storage_fee, rent, maintenance, professional_fees, interest_payments, custom_taxes, other_expenses, channel_fee, disputes, opex_pct_sales, net_profit, net_profit_margin_pct, cogs_pct, fulfillment_pct, marketing_pct, opex_pct, new_customers_pct, total_revenue, taxes_add_back, removed_taxes, duties_and_tips. cm1 = Gross profit. cm2 = profit after fulfillment. cm3 = profit after marketing. MER = revenue / marketing_spend. aMER = new-customer-revenue / marketing_spend. BEROAS = revenue / cm1. CAC = marketing_spend / new_customers. MPR = cm2 / marketing_spend. aMPR = new-customer-cm2 / marketing_spend. RESPONSE: { group_by, currency, count, rows }. All currency values in shop's reporting currency. Percentages already × 100. First or last row will have `Date: "Total"` (the rollup over entire range). MULTISTORE: if the user has multiple connected shops, pass `shop_id` to target one. Call `list_shops` first to discover available shops and match the user's phrasing. Each call returns one shop's data in its own `reporting_currency` (also surfaced in the response's `currency` field). For "total across all stores", call this tool once per shop and either label each shop's row with its currency or ask the user before applying FX conversion.
query_daily_summary
Email / SMS campaign and flow profitability for the authenticated Bloom shop over a date range (Klaviyo, Mailchimp or Omnisend). Same engine as the Email Profits page. One row per campaign or flow message: name, type (campaign/flow), channel (email/sms), send_time, recipients, opens_unique, clicks_unique, open_rate, click_rate, orders, revenue, cogs, discounts, refunds, discount_pct, cogs_pct, refund_pct, gross_profit, margin, profit_per_recip, trend, plus label ∈ Profit Engine / Solid Earner / Margin Trap / Breakeven Zone / Money Pit and a recommended action. Sorted by revenue DESC, paginate with limit/offset. RESPONSE: { provider, currency, count, rows, offset, limit, next_offset, has_more }. Values in the shop's NATIVE currency. Percentages already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_email_profit
Marketing attribution for the authenticated Bloom shop: ad spend, orders, revenue and profit attributed to each marketing channel / campaign / adset / ad for a date range. USAGE: 1. Returns detail rows only — one row per (channel, campaign, adset, ad) combination. No channel/campaign subtotals or grand total. 2. `attribution_model` picks how conversions are credited (default LAST_NON_DIRECT). 3. `lookback_window` is the attribution window in days (default 7). 4. Pick only the metrics you need via `fields`. Dimension columns (ca_channel_name, ca_channel_category, adset_name, ad_name) are always included. AVAILABLE FIELDS: order_count, nc_order_count, nc_orders_pct, ads_spend, clicks, impressions, conversions, conversion_value, net_revenue, order_fulfillment_costs, product_cost, cm2, cm2_margin, nc_net_revenue, nc_revenue_pct, nc_order_fulfillment_costs, nc_product_cost, nc_cm2, nc_cm2_margin, ads_roas, bloom_roas, bloom_poas, cac, ctr, cpc, cpm, aov, nc_aov, bloom_nc_roas, cm3, cm3_margin, nc_cm3, nc_cm3_margin. ads_spend = ad platform spend. ads_roas = conversion_value / ads_spend. bloom_roas = net_revenue / ads_spend. cac = ads_spend / new customers. nc_ = new-customer variant. cm2 = profit after fulfillment. cm3 = profit after marketing. RESPONSE: { attribution_model, lookback_window, currency, count, rows }. Percentages already × 100. CURRENCY: values are in the shop's reporting currency (falls back to the shop's native currency when none is set), surfaced in the response's `currency` field. MULTISTORE: pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_marketing_attribution
Marketing Efficiency for the authenticated Bloom shop — the same model as the Marketing Efficiency page: is ad spend profitable, is the next dollar profitable, do new customers pay back, and what budget is recommended. WINDOWS ARE FIXED by the model (no date range input): weekly series covers the trailing ~3 months in 7-day buckets ending yesterday; cohorts are the trailing 6 calendar months of new customers with a 60-day LTV horizon. Use `as_of` to evaluate the model as it stood on a past date. SECTIONS (pick via `sections`, default weekly, scale, advice): - weekly: per 7-day bucket — adSpend, netRevenue, ncRevenue, blendedROAS, poas, beroas (break-even ROAS), newCustomers, ncCAC, ncAOV, ncROAS, ncPOAS, firstOrderProfit, profitLTV60, repeatRate60, paybackDays. - cohorts: monthly new-customer cohorts — new_customers, aov, cac, fop (first-order profit), profit_ltv_60, ltv_to_cac, payback_days, repeat_rate, maturity_pct, is_estimated. (60-point curve_points omitted.) - mature: the most recent fully matured cohort's CAC / LTV / payback. - payback_curve: cumulative profit per customer by day vs CAC. - marginal: spend-response curve, marginal ROAS at current spend, ceiling budget, reliability. - scale: headline gauges — blended_roas, beroas, nc_beroas, current_daily_budget, marginal_at_current, ceiling_budget, payback_gauge. - advice: verdict state + cause, recommended/trim/next daily budget, next_review, and the 5 gate checks (ads_profitable, next_dollar, customers_pay_back, repeat_pace, first_order_covers_cac). RESPONSE: { as_of, currency, window, sections requested… }. Money in reporting currency; percentages already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_marketing_efficiency
Query per-order metrics for the authenticated Bloom shop. Mirrors the merchant's Order Metrics table. USAGE: 1. For wide date ranges (>1 month) call FIRST with `count_only: true` to gauge size. Response includes `count` and `suggest_batches`. 2. If `count` is large (>500), narrow `start_date`/`end_date` OR paginate using `offset` (start at 0, increment by `limit` each call until `has_more` is false). 3. Pick only the fields you need via `fields` — fewer columns = smaller payload + faster query. AVAILABLE FIELDS: order_name, shopify_order_id, created_at, source_name, tags, gross_sales, discounts, refunds, net_sales, tax, total_sales, shopify_gross_profit, shopify_gross_margin_pct, cm1, cm1_pct, cm2, cm2_pct, gateway_cost, shipping_cost, product_cost, handling_cost, channel_fee, tariff_cost, disputes. cm1 = Contribution Margin 1 (total_sales - product_cost). cm2 = Profit after fulfillment / Contribution Margin 2 (cm1 minus handling/shipping/payment/channel/tariff costs). Row key for cm2 is "Profit after fulfillment". RESPONSE: { count, rows, offset, limit, next_offset, has_more }. All currency values are in shop's reporting currency. Percentages are already multiplied by 100. MULTISTORE: if the user has multiple connected shops, pass `shop_id` to target one. Call `list_shops` first to discover available shops and match the user's phrasing. Returned amounts are in that shop's `reporting_currency` (see `list_shops`). When comparing or summing across shops with different reporting_currencies, label each value with its currency rather than silently summing — confirm with the user before applying any FX conversion.
query_order_profits
Product Insights for the authenticated Bloom shop: every product classified into an action bucket for a date range. Same engine as the Product Insights page (Performance / Ads / Momentum tabs). TABS (pick one via `tab`): - performance: units, gross/net revenue, discounts, refunds, COGS, shipping, gross profit + margin, refund/discount rate, shop 90d benchmarks. Category ∈ Profit Star / Revenue Trap / Margin Bleeder / Hidden Gem / Underperformer / Dead Weight / Cost Missing with a recommended Action. - ads: per-product ad spend, ad revenue, actual vs break-even ROAS, contribution margin, net profit after ads. Category ∈ Profit Maker / Margin Trap / Budget Drain / Money Pit / Hidden Gem / Dead Weight. Tune with `target_roas` (default 2.0) and `margin_floor` % (default 30). - momentum: FIXED window only — last `lookback` days ending today (7/14/30/60/90, default 30) vs the same-length window immediately before it, exactly like the Momentum tab. start_date/end_date are IGNORED for this tab. Units, revenue, profit for both windows plus % change and Label ∈ On Fire / In Freefall / Margin Squeeze / Profit Engine / Losing Steam / Holding Steady / New / Low Volume. `New` and `Low Volume` rows are Excluded=true. Tune with `momentum_threshold` % (default 5) and `min_units` prior-window floor (default 5). PRODUCT COUNTS DIFFER BY TAB — this is by design, not a data inconsistency: performance lists every product incl. unsold; ads lists products with a daily product summary row in range (ad spend may be 0); momentum lists products with units sold in the current or prior window. Do not compare row counts across tabs. USAGE: pass a tab (+ start_date/end_date for performance/ads, `lookback` for momentum), optionally `category` to filter to one bucket, and paginate with limit/offset. Performance/Ads are sorted by gross profit / ad spend DESC; Momentum by current revenue DESC. RESPONSE: { tab, currency, count, rows, offset, limit, next_offset, has_more }. Row keys are human column names (e.g. "Product Name", "Gross Profit"). Percentages already × 100. CURRENCY: `ads` values are in reporting currency; `performance` and `momentum` are in the shop's NATIVE currency. Performance and Ads read different fact tables, so COGS/profit for the same product can differ slightly between tabs. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_product_insights
Query per-product (or per-variant) metrics for the authenticated Bloom shop. Mirrors the merchant's Product Metrics table. GRAIN: `grain: "product"` (default) for one row per product, `grain: "variant"` for per-variant. variant_name and sku apply only to variant grain; every other field works in both grains. USAGE: 1. For wide date ranges (>1 month) call FIRST with `count_only: true` to gauge size. 2. If `count` is large (>500), narrow the date range OR paginate using `offset`. 3. Pick only the fields you need via `fields`. AVAILABLE FIELDS: product_name, product_id, variant_name, image, product_type, vendor, sku, tags, status, units_sold, units_refunded, inventory_quantity, gross_sales, discounts, refunds, net_sales, total_sales, product_cogs, gross_profit, gross_margin_pct, ads_spend, net_profit, net_profit_margin, product_roas, inventory_cost, inventory_value, shipping_cost, beroas. ads_spend = blended across Meta/Google/etc. net_profit = total_sales - cogs - ads_spend - handling. product_roas = total_sales / ads_spend. beroas = break-even ROAS. RESPONSE: { grain, count, rows, offset, limit, next_offset, has_more }. All currency in shop's reporting currency. Percentages already × 100. MULTISTORE: if the user has multiple connected shops, pass `shop_id` to target one. Call `list_shops` first to discover available shops and match the user's phrasing. Returned amounts are in that shop's `reporting_currency` (see `list_shops`). When comparing or summing across shops with different reporting_currencies, label each value with its currency rather than silently summing — confirm with the user before applying any FX conversion.
query_product_profits
Full Profit & Loss statement for the authenticated Bloom shop — the same rows as the P&L page. Use `source` to pick Shopify, Amazon, or the combined Overall P&L. - shopify: revenue → refunds/discounts → COGS → fulfillment (shipping, handling, transaction fees) → marketing spend by channel → contribution margins → operating expenses → net profit. - amazon: Gross Revenue → Returns & Refunds → Net Revenue → COGS → Product Gross Profit → Amazon Fees (Referral/Commission, Order Fulfillment) → Gross Profit → Marketing Spend (Sponsored Products/Brands/Display, DSP, deals, coupons) → Contribution Profit → Operating Expenses (supply chain & storage, reimbursements, other Amazon fees) → Net Profit. Amazon costs are NEGATIVE numbers; fees for unsettled orders are estimated until Amazon settles them. Requires Amazon connected. - all: both channels combined. USAGE: one row per period (`group_by` auto: ≤7d=day, ≤31d=week, ≤366d=month, else year) plus a row with Date="Total" for the whole range. Default `fields` = the headline P&L lines; pass `fields: ["all"]` for every line item, or an explicit list of row names. Call with a short range first to see available row names. RESPONSE: { source, currency, group_by, count, rows }. Values in reporting currency; margin rows already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_profit_loss
Headline KPI scorecards for the authenticated Bloom shop over a date range — the KPI tiles at the top of the Marketing, Customers and Products dashboards. DOMAINS: marketing (ROAS (API), Conversion Value, Conversions, Ad Spend, Clicks — across connected ad platforms); customers (New Customer %, Repeat Customer %, New/Repeat Customer Revenue, AOV, AOV new vs returning); product (Conversion Rate, Cart Abandoned Rate, Checkout Abandoned Rate). `compare: true` also returns the same-length period immediately before with change_pct. RESPONSE: { domain, currency, period, previous_period, widgets: [{ name, value, previous_value, change_pct, is_currency, is_percentage }] }. Values in reporting currency; percentages already × 100. MULTISTORE: single shop only. Pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_scorecards
Settings that change how every other tool's numbers should be read, for the authenticated Bloom shop: currency (native vs reporting), timezone, profit_calc_mode (net_revenue vs total_revenue as the margin base), tax handling, shipping-revenue treatment, the merchant's default dashboard date range, plan, store age, and which integrations are connected. Cheap — call once per conversation. MULTISTORE: pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_shop_settings
Data freshness for the authenticated Bloom shop: which integrations are connected and when each data source (Shopify orders, ad platforms, email, shipping, Amazon) last finished syncing. Call this before answering questions about very recent days, or when numbers look incomplete — a source with status ERROR or an old synced_till explains gaps. RESPONSE: { shop_id, timezone, first_time_synced, overall, connected_integrations, sources: [{ resource, status, synced_till, updated_at }] }. overall ∈ ok / not_integrated (no ad platform connected) / not_synced (connected but no data yet). status ∈ PENDING / RUNNING / COMPLETED / ERROR. MULTISTORE: pass `shop_id` to target one shop; call `list_shops` first to discover IDs.
query_sync_status
Set the fulfillment handling cost Bloom charges per order and per item (Costs → Handling Cost), in the shop's NATIVE currency. `country` defaults to Worldwide, the rate used for every shipping country without its own override; pass a country name to set an override for that country only. One row per country; calling again updates it. No date range: applies to new orders, and to past orders too when `recalculate_past_orders` is true (default true); pass false to apply to new orders only. Preview shows the current per-order / per-item cost for that country and the new one. CONFIRMATION (required): call once WITHOUT `confirm` to get a preview of exactly what will change and a short `confirmation_code`. Show the preview to the merchant and ask them to approve it. Only after they explicitly say yes, call again with `confirm: true` and the code. Never confirm on the merchant's behalf. After applying, tell them where in the Bloom app to verify (`verify_in_app`). This tool only creates or updates — it never deletes. MULTISTORE: on accounts with more than one shop you must also pass `shopify_domain` matching the target store; call `list_shops` to see domains.
set_handling_cost
Set the payment processing fee Bloom charges against orders for a gateway (Costs → Gateway Cost): `percentage_fee` % of order value plus `fixed_fee` per order, in the shop's NATIVE currency (e.g. 2.9 + 0.30). One rate per gateway per shop; calling again updates it. `gateway_name` must be one of Bloom's known gateways — `Other` is the catch-all applied to any gateway without its own rate. Fees have no date range: they apply to new orders, and to past orders too when `recalculate_past_orders` is true (default true); pass false to apply to new orders only. Preview shows the current rate for that gateway (if any) and the new one. CONFIRMATION (required): call once WITHOUT `confirm` to get a preview of exactly what will change and a short `confirmation_code`. Show the preview to the merchant and ask them to approve it. Only after they explicitly say yes, call again with `confirm: true` and the code. Never confirm on the merchant's behalf. After applying, tell them where in the Bloom app to verify (`verify_in_app`). This tool only creates or updates — it never deletes. MULTISTORE: on accounts with more than one shop you must also pass `shopify_domain` matching the target store; call `list_shops` to see domains.
set_gateway_cost
Set the cost of goods (COGS) for product variants — the same effect as the bulk cost import on Costs → Product Cost. Use it to fix "Cost Missing" products from query_product_insights or to correct wrong COGS. Each item names a variant by `variant_id` (Shopify variant id) or `sku`, plus the new `cost` per unit in the shop's NATIVE currency (> 0). A SKU that matches several variants is rejected with the candidates so you can pass variant_id instead. Only variants of ACTIVE products can be updated; draft and archived products are rejected. Shopify products only — Amazon catalogue costs cannot be set with this tool. The new cost replaces ALL existing Bloom cost rules for that variant (all countries, date ranges and quantity tiers) with one fixed worldwide cost from store creation onward. `recalculate_past_orders` (default true) re-runs profit for historical orders; false applies to new orders only. Changes reach reports within about a minute. PREVIEW returns, per variant: product/variant title, sku, current Shopify cost, current Bloom cost rules, new cost. CONFIRMATION (required): call once WITHOUT `confirm` to get a preview of exactly what will change and a short `confirmation_code`. Show the preview to the merchant and ask them to approve it. Only after they explicitly say yes, call again with `confirm: true` and the code. Never confirm on the merchant's behalf. After applying, tell them where in the Bloom app to verify (`verify_in_app`). This tool only creates or updates — it never deletes. MULTISTORE: on accounts with more than one shop you must also pass `shopify_domain` matching the target store; call `list_shops` to see domains.
set_product_cost
Set the commission Bloom deducts for orders from a sales channel or order source (Costs → Channel Commission): `commission_fee` is a percentage of the order total (e.g. 15 for a 15% marketplace fee). `channel_name` must be one of the channels seen on this shop's orders (e.g. Online Store, Amazon, TikTok, Faire, POS); unknown names are rejected with the available list. One rate per channel; calling again updates it. No date range: applies to new orders, and to past orders too when `recalculate_past_orders` is true (default false). Preview shows the current commission for that channel (if any) and the new one. CONFIRMATION (required): call once WITHOUT `confirm` to get a preview of exactly what will change and a short `confirmation_code`. Show the preview to the merchant and ask them to approve it. Only after they explicitly say yes, call again with `confirm: true` and the code. Never confirm on the merchant's behalf. After applying, tell them where in the Bloom app to verify (`verify_in_app`). This tool only creates or updates — it never deletes. MULTISTORE: on accounts with more than one shop you must also pass `shopify_domain` matching the target store; call `list_shops` to see domains.
set_channel_commission
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Bloom Profit Analytics alternatives on ChatGPT?
As of 2026-09-29, Bloom Profit Analytics competes with ADECI, Alteryx Insights, Answer Charts, Azadea One, Bark AI, BlazeSQL, Book Report, ChartMogul, Cleverbridge, Coupler.io, Cube, DataAssist-IO, DATAHILL, Deepnote, Evidence Studio, Ezoic Analytics, Flourish, Fr8Labs Analytics, Fullmetrix, Hex, Hologrow, Keypup, Krewss BI, Menu Integrado, Metorik, Omni, Orion, OWOX Data Marts, Peaka, Perlucem.ai, Prism by Crossdeck, PublisherChamp, Sales Compass by Luzmo, Social Plus Agentry, Steep, Sweet Analytics, Tableau (MCP only; EOL soon), Tenzo, ThoughtSpot Spotter, ThoughtSpot SpotterCode, TitanSigma, VODER, Winnow, WisdomAI, WitCloud, Wren AI, XAPP Analyst in ChatGPT Self-Serve BI & Conversational Analytics, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.