Profit-First Bidding

Our bid optimization algorithm is built on a simple but powerful principle: your advertising should be profitable. Instead of blindly chasing sales or impressions, we calculate the maximum you can spend on ads while still making money on each sale. The algorithm uses five key factors: 1. Unit Economics (COGS, margins, break-even ACOS) 2. Inventory Status (days of supply, velocity zones) 3. Organic Rank (reduce paid spend where organic visibility exists) 4. CPC Gap Analysis (actual vs target CPC) 5. Placement Optimization (RPC-based placement modifiers)

The algorithm calculates your optimal bid through these steps: 1. Effective Target ACOS = Break-Even ACOS × Profit Retention × Inventory Modifier 2. Target CPC = RPC × Effective Target ACOS × Organic Modifier 3. Recommended Bid = Current Bid × (1 + CPC Gap Modifier) Each factor adjusts your bid based on real business conditions.

Break-Even ACOS represents the advertising cost of sale at which you neither make nor lose money. It's calculated from your actual unit economics. Formula: Contribution Margin = Sale Price - COGS - Referral Fee (15%) - FBA Fee Break-Even ACOS = Contribution Margin / Sale Price

Sale Price: $30.00 COGS: $8.00 Referral Fee: $4.50 (15%) FBA Fee: $5.00 ───────────────────────── Contribution: $12.50 Break-Even ACOS: $12.50 / $30.00 = 41.67% This means you can spend up to 41.67% of your sales on advertising before losing money.

The algorithm looks for COGS data in this order: 1. Profit Tracker COGS (primary) - Full cost breakdown with product, shipping, duties, packaging 2. Custom Product Costs (fallback) - Production cost + freight cost 3. Default Break-Even (estimate) - Configurable default when no data available (typically 25%) When you provide accurate COGS data, the algorithm calculates precise break-even points for each product.

Every campaign has a BASE BID — the number you'd see in Amazon's console. Exactly one thing sets it: you, a Rule, or Auto Mode. Dayparting never sets the base bid — it flexes it up or down by hour of day, and puts it back. Your manual edits always win, instantly, over everything.

Manual You edit a bid in the grid or bulk editor. Applies instantly. Always allowed. Rules Your if-this-then-that conditions adjust bids on the schedule you set. Auto Mode Shurq's optimizer manages bids toward your ACOS / ROAS target, continuously. Dayparting Flexes the current bid by hour of day (e.g. +30% during peak hours), then reverts.

1. YOU ALWAYS WIN. Edit any bid at any time — automation doesn't fight you. It adopts your new bid as the new baseline and continues from there. Dayparting applies its next hourly adjustment to your number. 2. ONE MANAGER PER CAMPAIGN: Rules or Auto Mode, never both. Two systems setting the same base bid would fight each other, so Shurq blocks the combination when you try to create it — you'll see a message naming the conflicting campaigns or rules. To switch managers, detach one first. The Rule column in the campaign grid shows which rule manages each campaign; blank means unmanaged. 3. DAYPARTING STACKS ON TOP of whoever is managing. It shapes the bid across the day and reverts — pause or delete a dayparting schedule and your bids return to their base values automatically. It's safe to run dayparting together with Rules, Auto Mode, or neither. 4. THE FREEZE SWITCH. Every campaign has a Bid Control setting: • Managed — automation may act (the default) • Hybrid — automation may only suggest; you approve every change • Manual — nothing automated touches this campaign, period Set a campaign to Manual and rules skip it, the optimizer skips it, and every blocked attempt is logged so you can see what would have happened.

…I edit a bid on a campaign a Rule manages? Your bid applies immediately. The rule uses your new bid as its starting point on its next scheduled run. …I try to attach a Rule to an Auto Mode campaign (or vice versa)? Blocked, with a message telling you exactly which campaigns or rules conflict and what to detach. …I pause dayparting at 3pm during a +40% window? Bids revert to base. Guaranteed — if Amazon's API hiccups, Shurq retries until the revert lands. …something outside Shurq changes a bid (Seller Central, another tool)? Shurq detects it within about two hours and adopts it as the new base — same as a manual edit.

Every rule carries its own guardrails — max change per run, min/max bid bounds, daily execution caps. Every automated change is logged with what changed, old → new, and which rule or system did it. And Manual mode is always one click away, per campaign.

Each strategy determines how much of your break-even margin you keep as profit vs. reinvest in advertising. Target ACOS = Break-Even ACOS × Profit Retention Rate

Best for: Established products, maximizing profit Keeps 50% of your break-even margin as profit. Example: • Break-Even ACOS: 40% • Target ACOS: 40% × 0.50 = 20% Conservative approach ensuring strong profitability on every sale.

Best for: Most campaigns, sustainable growth The default choice for most advertisers. Keeps 25% of margin as profit while allowing competitive bidding. Example: • Break-Even ACOS: 40% • Target ACOS: 40% × 0.75 = 30% Good balance between profitability and market presence.

Best for: Product launches, market share expansion Aggressive bidding that prioritizes visibility over profit. Example: • Break-Even ACOS: 40% • Target ACOS: 40% × 0.90 = 36% Use for new products that need reviews, or when capturing market share is more important than immediate profit.

The algorithm adjusts bids based on your inventory levels. When stock is low, it automatically reduces ad spend to protect organic rank and avoid stockouts. When stock is high, it increases spend to move inventory. Effective Target ACOS = Break-Even × Retention × Inventory Modifier

Zone Days of Supply Modifier Effect ───────────────────────────────────────────────────── CRITICAL < 7 days 0.25 75% bid reduction DANGER 7-14 days 0.50 50% bid reduction CAUTION 14-21 days 0.75 25% bid reduction WATCH 21-30 days 0.90 10% bid reduction HEALTHY 30-60 days 1.00 No change HIGH 60-90 days 1.10 10% bid increase EXCESS 90+ days 1.20 20% bid increase

The algorithm uses weighted velocity to calculate days of supply accurately: Weighted Velocity = (7d × 50%) + (14d × 30%) + (30d × 15%) + (90d × 5%) Days of Supply = Current Inventory / Weighted Daily Velocity Important: We use TOTAL sales (organic + PPC), not just ad-attributed orders. Using PPC orders alone would vastly overestimate days of supply.

Don't pay for visibility you already have organically. If you rank #2 organically for "protein powder", you're already visible at Top of Search. The algorithm reduces TOS ad spend but maintains Product Page spend where you're competing against other products.

Zone Rank Description ─────────────────────────────────────── DOMINANT 1-3 Own the keyword organically STRONG 4-8 High visibility CLIFF 9-15 Risk of falling off page 1 MID_PAGE 16-31 Lower page 1 / top page 2 BURIED 32+ Deep pages NEW No data Discovery phase

Different placements get different modifiers based on your organic rank: Zone TOS ROS Product Pages ───────────────────────────────────────────── DOMINANT 0.25 0.50 0.75 STRONG 0.50 0.75 0.85 CLIFF 1.00 1.00 1.00 MID_PAGE 1.25 1.10 1.00 BURIED 1.50 1.25 1.10 NEW 1.50 1.25 1.10 Example: If you rank #2 (DOMINANT) on "protein powder": • Top of Search: 75% bid reduction (you're already visible) • Rest of Search: 50% bid reduction • Product Pages: 25% bid reduction (still competing with other products)

The algorithm compares what you're actually paying (Actual CPC) vs. what you should be paying (Target CPC) to hit your ACOS goal. Target CPC = RPC × Effective Target ACOS × Organic Modifier CPC Gap = (Actual CPC - Target CPC) / Target CPC

Gap Range Action Bid Change ───────────────────────────────────────────────────────── > +100% PAUSE Turn off +50% to +100% REDUCE_SIGNIFICANT -30% to -50% +20% to +50% REDUCE_MODERATE -15% to -30% +10% to +20% REDUCE_SLIGHT -5% to -15% -10% to +10% MAINTAIN No change -20% to -10% INCREASE_SLIGHT +5% to +15% -50% to -20% INCREASE_MODERATE +15% to +30% < -50% INCREASE_SIGNIFICANT +30%+

Keyword: "protein powder" • Target CPC: $0.65 • Actual CPC: $0.85 • CPC Gap: ($0.85 - $0.65) / $0.65 = +30.8% Action: REDUCE_MODERATE The keyword is overpaying by 30%, so the algorithm recommends a moderate bid decrease.

For keywords with clicks but no conversions, the algorithm uses a smooth decay formula instead of hard cutoffs: Target CPC = AOV / (Clicks + 1/CVR) × Target ACOS × Inventory Modifier As clicks accumulate without conversion, target CPC smoothly decreases.

AOV=$30, CVR=10%, Target ACOS=25%: Clicks Target CPC % of Initial ──────────────────────────────────── 0 $0.75 100% 5 $0.50 67% 10 $0.375 50% 20 $0.25 33% 50 $0.125 17%

Different match types have different decay thresholds: Match Type Min Clicks Decay Starts Rationale ────────────────────────────────────────────────────── EXACT 10 30 clicks Clear signal, quick decisions PHRASE 15 45 clicks Noisier signal, more patience BROAD 25 60 clicks Discovery focused, most patience Broad match is for discovery - you expect some search terms won't convert. Killing a broad keyword after 30 clicks might eliminate one that would find profitable search terms at click 40.

Amazon allows bid adjustments for different ad placements: • Top of Search (TOS): Premium position at the top of search results • Rest of Search (ROS): Below the fold on search pages • Product Pages (PP): Ads shown on competitor product detail pages

The algorithm calculates placement modifiers based on Revenue Per Click: 1. Find worst-performing placement (lowest RPC) = baseline 2. Baseline placement gets 0% modifier 3. Other placements: modifier = (RPC / baseline_RPC) - 1 Example: • TOS RPC: $5.00 (best) • ROS RPC: $2.50 • PP RPC: $1.00 (worst = baseline) Modifiers: • TOS: ($5.00 / $1.00) - 1 = +400% • ROS: ($2.50 / $1.00) - 1 = +150% • PP: 0% (baseline) Logic: Bid more aggressively for placements that convert better.

• Min Bid: Prevents bids from going too low (default: $0.10) • Max Bid: Caps maximum bid amount (default: dynamic based on product price) • Max Increase: Limits how much a bid can increase per optimization (default: 25%) • Max Decrease: Limits how much a bid can decrease per optimization (default: 25%)

These limits prevent sudden dramatic changes that could hurt campaign performance. Gradual optimization allows the algorithm to learn and adjust over time while protecting against: • Sudden bid spikes from data anomalies • Over-aggressive decreases that kill momentum • Stockout situations from excessive ad spend

We recommend weekly optimization for most campaigns. This gives Amazon's algorithm enough data to show results while keeping bids current with market conditions.

Yes. Every optimization run is logged in the Optimization History. You can revert any run with a single click, restoring all bids to their previous values.

New products with limited data should use the Growth strategy to build visibility and gather conversion data. Once you have 2-4 weeks of data, you can switch to Balanced or Profit-First.

The Profit-First approach adds several layers of intelligence: • Dynamic Target ACOS: Calculated per-product from actual COGS • Inventory Awareness: Adjusts for stock levels • Organic Rank: Reduces spend where you already rank well • CPC Gap Analysis: Compares actual vs target cost • Smooth Decay: Graceful handling of non-converters • Simultaneous Placement: Optimizes bids + modifiers together

Dayparting flexes a bid by hour of day. It does not set the base bid. The base bid stays whatever you, a rule or Auto Mode last set it to, and dayparting applies a percentage on top of that number for the hours you choose, then puts it back. A schedule is a day by hour grid attached to a set of campaigns: 00 01 02 ... 12 13 ... 22 23 Mon 0 0 -10 +15 +15 -5 0 Tue 0 0 -10 +20 +20 -5 0 ... Each cell is a percentage adjustment applied to the current base bid for that hour, in the timezone the schedule was created with. New schedules default that timezone to the marketplace's home zone rather than your own, because a German campaign shaped around California hours is shaped around nothing. Because the adjustment is applied and then reverted, dayparting is safe to run alongside Rules, alongside Auto Mode, or on its own. Pause or delete a schedule and the bids return to their base values. If you edit a bid by hand mid schedule, your number becomes the new base and the next hourly adjustment applies to it. Use dayparting when your conversion rate genuinely differs by hour or weekday, not because a report looks uneven. An uneven looking hour with very little traffic is noise, and the schedule builder is deliberately reluctant to act on it.

Open AI Optimize on a set of campaigns and Shurq analyses their own hourly history, then proposes a grid. The default analysis window is the last 90 days, because weekday patterns need several observations of each weekday before they mean anything. The numbers behind that analysis are anchored to Amazon's reported daily totals rather than to the raw hourly feed. Amazon delivers hourly traffic before invalid traffic is removed, so the raw feed runs high on clicks and spend while the daily reports settle lower. Anchoring to the reported dailies is why a generated schedule does not over cut campaigns that are already sitting at their target. Evidence gates sit in front of every adjustment: Under 14 days of observed data day of week is held flat entirely 14 to 27 days hour shaping only, weekday exceptions wait Thin cells faded in the heatmap, click count shown A single day and hour cell only earns its own exception when it has pooled evidence behind it, the deviation is large relative to its own dispersion, and the deviation survives removing its loudest week. One dead Prime Day week is an event, not a rule. Shopping events are the common contaminant. If Prime Day, Black Friday or Christmas falls inside your analysis window, the builder points at it and offers to exclude those days. It never excludes them for you.

A schedule can carry a maximum bid per hour as well as a percentage. The automatic ceiling is derived from each hour's revenue per click and your break even, so hours that genuinely earn more are allowed to pay more, and the ratio between hours can exceed what a percentage grid alone could express. Placement modifiers are the part people misread. Amazon applies your Top of Search or Product Pages percentage on top of the already adjusted bid, so the two compound. A bid of 3.10 with a 300 per cent Top of Search modifier is really paying close to 9.00 for that click. Because of this, the ceiling divides the placement out: the cap is a contract on the effective click price, not on the number in the bid field. One behaviour worth knowing. Placement fields you never touch are left alone. A placement field you deliberately set to 0 is treated as an instruction to assert zero per cent, and will be written every hour. Earlier behaviour wrote an implicit zero for untouched fields, which quietly overwrote placement settings made in Seller Central. Untouched now means untouched. Changes made outside Shurq are adopted rather than fought. If you change a bid in Seller Central, the schedule takes your number as the new base within the hour and continues shaping around it.

Holding a metric heatmap next to the generated grid and concluding the grid is wrong. The heatmap shows what happened. The grid shows what should change. They disagree constantly, and the disagreement is usually correct. A cell showing 50 per cent conversion and 6 per cent ACOS looks like an obvious hour to bid into, until you check the evidence and find it was two clicks, one order and one unusually large sale. Statistical nothing painted in saturated green. Before concluding the model is wrong, check two things: 1. The click count on the cell. It is in the tooltip. 2. The window you generated on. A cell can sit under the evidence floor in a 30 day window and clear it in a 90 day window, so the same campaign produces different grids from different windows, correctly. The second common error is expecting dayparting to do the job of bid management. It shapes spend across the day around whatever your base bid already is. If the base bid is wrong, dayparting makes it wrong in a more interesting pattern. Get the base right with Rules or Auto Mode first, then shape it. The third is reading a flat row as a bug. When several hours all sit at the same value, that usually means they have all hit the ceiling implied by your break even. Every one of them means bid at the ceiling.

Amazon never tells anyone what a product cost to make, so COGS is the one number in the P&L that has to come from you. Until it is entered, a product carries no cost and its profit is overstated by exactly the amount you paid for it. There are three entry paths and all three apply to your whole catalogue, not just the products currently on screen: Customize Cost modal one product, typed in Bulk template download the template, fill it, upload it Third party import a cost export from another tool, CSV or XLSX The third party import is the migration path. It matches on ASIN, reads European decimal commas, detects whether a file writes dates day first or month first rather than assuming, and skips rows the source file marked as hidden. Rows are filtered to the marketplace you are importing into, so a German row cannot set a British cost by accident. If your SKUs are listed in more than one marketplace, one upload can serve all of them. The preview lists every other marketplace the file matches with a count and a tick box, and converts the values into each target's own currency, which you can switch off when the file already carries per market numbers. Large imports are sent in chunks and are safe to re run. Uploading the same file twice updates rather than duplicates.

A cost is not a single value attached to a product. It is a value attached to a date range. cost per unit = production cost + freight cost applies to every order where start date <= order date <= end date no end date means open ended Your first ever cost for a product is backdated to 2020-01-01. That is deliberate: it means historic profit restates the moment you enter a cost, so last year's P&L stops showing pure revenue minus fees. Costs entered later become new tiers starting today, so raising a price does not rewrite last quarter's margins. When several tiers exist, an order is costed at the latest tier starting on or before the order date. That is the whole rule. A cost entered against an ASIN applies to every SKU sharing that ASIN. If you run two SKUs on one ASIN at genuinely different costs, that case is ambiguous today and the most recently entered value wins, so check it rather than assume. The write is not instant. A save is queued, batched with anything else you saved in the same few seconds, and the P&L is recomputed behind it. Expect the dashboard to reflect a bulk import in roughly fifteen to sixty seconds, not immediately.

COGS is recorded as a small ledger rather than a single netted figure, because a mistake on one unit is a rounding error and the same mistake on a thousand units is a false picture of the business: cost of goods recognised at sale minus cost credited back for returns graded sellable plus cost written off for returns graded damaged or defective ──────────────────────────────────────────────────────────── net cost of goods, which feeds every contribution margin The distinction matters more than it sounds. A simpler model credits the full cost back on every refunded order, which quietly assumes every returned unit comes back saleable. It does not. The units Amazon grades as damaged or defective are inventory you paid for and cannot sell again, and they belong in the write off line where you can see them. That net figure is what break even ACOS is calculated from, so cost accuracy propagates directly into bidding. A product with no cost entered shows a break even ACOS far higher than reality, which means every bid derived from it is too aggressive. The same figure drives the refund page's unsellable cost, the lifetime margin views on LTV, and the contribution margin lines on the P&L. One entry, several surfaces.

A day showing zero cost of goods is not automatically missing data. Two cases are legitimately zero and are not worth chasing: 1. A refund only day. Units were returned, nothing was sold, so there is no cost to recognise. 2. A day after a cost's end date. The cost expired and nothing succeeded it, so nothing applies. The second one is worth watching, because it is the failure that looks like good news. If you entered a cost with an end date and never entered the next tier, everything sold since that date carries no cost, and your recent profit will read as considerably better than it is. If margins improve sharply for no reason you can name, check whether a cost expired. The other frequent misreading is treating a margin figure from an account with no costs entered as a real margin. Without COGS, contribution margin is revenue minus Amazon's fees, which is a genuinely useful number and is not profit. Every downstream surface inherits this: lifetime profit on LTV, margin ratios, break even ACOS, payback periods. Cost quality is margin quality, everywhere, with no exceptions. Finally, marketplaces are not interchangeable when importing. Check the marketplace selector before confirming a file. A cost applied to the wrong market is harder to notice than a cost not applied at all.

Each tracked product carries a list of keywords, and each keyword carries a position history. Ranks are collected daily by default. Individual keywords can be promoted to hourly tracking, which is worth spending on the handful of terms where intraday movement changes a decision, not on a long tail. Two ranks are recorded per keyword: Organic rank where your listing sits in the natural results Sponsored rank where your ad sits, when one is placed The daily heatmap is the fastest read. Each row is a keyword, each column a day, and the colour is the position, so a listing sliding off page one shows as a band drifting the wrong way before any single number looks alarming. Products can be viewed on their own, in aggregate across a set, or in rival mode against tracked competitors, where competitor positions overlay your own rank chart. Keyword discovery seeds the list rather than making you type it. Give it a product, and it finds the other ASINs ranking for that product's strongest terms, pulls the full keyword set those competitors rank for, scores each term on how many competitors rank for it and how much it is searched, and adds the top of that list to your tracker along with the competitors themselves. Keywords added this way count against your tracked keyword allowance, which an organisation admin sets per member.

Rank on its own tells you where you are. The market columns tell you whether the term is worth being there for. Click share your share of clicks on that term against the market estimate for the same week Purchase share the same comparison on purchases STP ratio keyword sales as a percentage of search volume, a read on how strongly the term converts at all Sponsored rank your paid position beside your organic one Opportunity Score folds four of these into one number out of 100, weighted so no single input can carry a term on its own: Demand up to 35 how much the term is searched Momentum up to 20 which way your rank is moving Conversion up to 25 how well the term converts Share gap up to 20 headroom between your share and the market A term scoring high on demand and low on everything else is a term you are not winning, which is useful; a term scoring high on share gap is a term where the traffic already exists and you are not taking it. The Top Clicked marker flags terms where your product is among the three products Amazon reports as taking the most clicks. That is a strong signal, and it is worth defending explicitly rather than assuming it holds.

The Ads tab joins your sponsored spend for a keyword onto the same row as its rank, which is the join that makes two expensive mistakes visible. The first is wasted spend: a keyword accumulating clicks and cost with no orders behind it. Rank data is what tells you whether that is a relevance problem or a listing problem, because a term you rank well for organically and still cannot convert on paid is usually a term that does not describe your product the way shoppers think it does. The second is cannibalisation: paying for exact match placement on a term where you already hold a top organic position. You are not always buying incremental sales there, and the same principle drives the organic rank modifier in the bidding algorithm documented above. Supporting surfaces: Tags group keywords into sets and filter by them Rank alerts a drop past your threshold raises a notification, grouped by product, linking into the tracker Weekly digest a Monday email summary with a keyword CSV attached Export multi sheet workbook of keywords, product and hourly ranks Campaign names in the ads columns link straight into the ad manager filtered to that campaign, so the path from a rank problem to the bid causing it is two clicks.

Market share and search volume figures are Amazon's weekly data. They are aligned to the most recent complete week Amazon has published, which is not this morning. Rank is current; share is weekly. Comparing a rank movement from yesterday against a share figure from last week and concluding they contradict each other is comparing two different clocks. The second common confusion is the two counters. The line beneath the table counts products. The pager inside the keyword grid counts keywords. They sit close together and they are not measuring the same thing. The third is treating discovery as free. Running it adds keywords to your tracker, and tracked keywords are a finite allowance, so a re run on a product that already has a healthy list mostly spends allowance to confirm what you had. The fourth is over tracking. A tracker with several hundred keywords per product is a tracker nobody reads. The useful shape is a short defended set of terms you actually bid on, plus a rotating discovery set you review and cut. Hourly tracking in particular should be reserved for terms where you would genuinely act on an intraday move.

Most Amazon reporting stops at the order. LTV and Retention continues past it, and asks what a buyer is worth over their whole relationship with your brand rather than on the day you acquired them. Buyer identity comes from fulfilment data you already have, so nothing new needs connecting. Orders are grouped by buyer, and every figure on the page follows from that grouping: New customer this buyer's first ever order with you Repeat any later order from a buyer you already had Unmatched orders with no buyer identity available; they count in totals but not in the new or repeat split, rather than being silently assigned The headline split is a revenue share, not an order share. New customer percentage is new customer revenue divided by total revenue. This is worth stating plainly because the order count version of the same figure runs materially higher on almost every account, since first orders skew towards smaller baskets. Both numbers are real. They answer different questions, and quoting one against the other looks like a discrepancy when it is a definition. The page runs in five views: an overview with the trend and per product breakdown, buyer cohorts, time to reorder, break even ACoS, and Subscribe and Save.

Every buyer belongs to the month they first bought from you, and stays in it. The cohort matrix reads acquisition month down the side and months since acquisition across the top, so a row is one group of customers followed forwards through time. month 0 month 1 month 2 month 3 Jan ... ... ... ... Feb ... ... ... masked Mar ... ... masked masked Cells a cohort has not lived long enough to reach are masked rather than shown as zero. A February cohort has not had a month three yet, and rendering that as zero would drag every average down and make recent cohorts look like failures. The metric views cover lifetime revenue, units, profit, margin, retention and dollar retention. The lifetime views accumulate, so a row should climb as it moves right; that is the curve you are looking for. Month zero can exceed what one order per new buyer would imply, and that is correct rather than a bug. Repeat purchases made inside the acquisition month itself land in month zero alongside the first order, so an account with fast reorder behaviour shows a heavy month zero. Profit views inherit their accuracy from your COGS entry. Where cost data does not cover a period, profit is left blank rather than filled with a zero that would read as a real number.

Time to Reorder answers when a repeat buyer comes back, which is the input to almost every retention decision. Reorder gaps are grouped into buckets: Bucket Gap between orders ────────────────────────────────── 0-7 0 to 7 days 8-15 8 to 15 days 16-30 16 to 30 days 31-60 31 to 60 days 61-90 61 to 90 days 91-120 91 to 120 days 121-150 121 to 150 days 151-180 151 to 180 days 180+ 181 days and over Read the label carefully: a gap of exactly 180 days sits in the 151-180 bucket, and 180+ begins at day 181. The page states the milestone in plain terms, for example that half of reorders arrive by a given day, and turns the shape into a retargeting window: the days between which a returning buyer is most likely to be reachable. That is the window worth spending on, and it is specific to your catalogue rather than a general rule. The Break Even ACoS view puts acquisition cost next to what a customer is worth. Break even here is calculated from contribution margin before advertising, which is the honest comparison; using an after advertising figure and then comparing it to advertising cost counts the same spend twice. Payback is expressed in months, so you can see how long a customer takes to repay what they cost to win.

Comparing cohorts at their own ages. An eighteen month old cohort has had eighteen months to accumulate revenue and a three month old cohort has had three, so ranking them on lifetime totals crowns the oldest cohort every time and tells you nothing. Compare cohorts at the same month offset, which is what the matrix is shaped for and what the insight line uses. The second is reading a very small early cohort as a real result. The first month or two of any account's history often holds a handful of identified buyers against a full month of advertising spend, which produces an acquisition cost that is arithmetically true and completely meaningless. Cohorts that are tiny relative to the account's normal size are marked as partial coverage and left out of the headline claims for exactly this reason. The third is expecting lifetime figures per product to add up to the account total. They do not, by design. A product level cohort follows every later purchase that buyer makes, not only repeat purchases of that same product, because the question being answered is which products bring in customers worth having. Two products can both take credit for the same later order, so summing them double counts. And as everywhere else, profit views are only as good as the costs you have entered.

Profit and cash are different questions. A profitable month can still leave you short in the week a payment is due, and a calendar view hides that because Amazon does not pay you on the first of the month. Cashflow is therefore organised around payouts by default. Each period ends on a day money actually landed and reaches back to the day after the previous payout: payout payout payout today │ │ │ │ ───┴─────────────┴─────────────┴─────────────┴──► period 1 period 2 period 3 open period Three consequences follow, and all of them are deliberate. Settlements from several marketplaces that land on the same day collapse into one payment, because that is one arrival in one bank account. An expense falling between two payouts is attributed to the payout that closes its period, so no day is uncovered and the running balance never has a hole. The final period is the open stretch since the last payout, which exists so that recent expenses and the current balance are not lost off the end. A month view is available for anyone reconciling against accounts kept in calendar months. The ledger itself always reads in calendar months, one panel per month, with quiet stretches collapsed to a single line so an inactive December does not consume half a screen.

Shurq knows what Amazon paid you. It does not know what is in your bank account, and cannot, so it asks. The anchor is one figure and one date: how much cash you hold, as of when. Every balance on the page chains forward from it, adding each payout, expense and manual entry in date order. Set it accurately once and the balance line is real. cash on hand at anchor date + payouts since - expenses since - manual entries since = balance at any later date Without an anchor there is no way to know a balance, so the page does not invent one. Balances show as dashes and the chart switches to net cash flow per period, which is the honest thing it can show: the difference each period made, without claiming to know the level. Entries dated before the anchor still appear, so you can see the history, but they do not move the balance. Moving money before your stated starting point would double count it. The anchor date cannot be in the future. An anchor dated next month gives every period a balance it cannot yet bear, and the result is a permanently empty chart with no obvious cause. On top of the payouts and recurring expenses, you can add entries manually for stock purchases, investments, dividends, tax set asides and anything else that moves cash, and import or export the whole ledger as CSV.

The forecast runs eight weeks ahead and is built from your own payment history rather than a model. For each marketplace with at least three settlements behind it, Shurq takes the typical gap between the last several deposits and the typical amount, and projects forward from your most recent payout at that rhythm. The projected amount is then adjusted by a seasonal factor: the same week one year earlier compared against that year's baseline, clamped so that one freak week cannot triple or erase a projection. Where last year's data is too thin to say anything, the factor is one and the projection is simply your recent median. A marketplace with fewer than three settlements projects nothing at all. It would be a guess, and a guess in a cash forecast is worse than a gap. Recurring expenses and recurring manual entries expand through the same horizon, so a monthly bill appears on each of its future dates. Monthly recurrence is anchored to the original day, so a payment on the 31st clamps to the 28th in February and recovers to the 31st in March rather than drifting earlier every month. Everything projected is drawn dashed, sits under a Forecast divider, and carries an Estimated label. It can be hidden entirely with one toggle when you want to see only what has actually happened.

Comparing dates against another tool and concluding one of them is wrong. Most tools date a payout on the day Amazon closed the settlement. Shurq dates it on the deposit date, which is later, typically by a couple of days. Both are defensible and they measure different events. Amazon's own disbursement timeline shows a settlement closing, then a transfer being sent, then the bank acknowledging it, spread over several days. Closing is when the accounting period ended. The deposit date is the closest available approximation of the money arriving, and for a cash view that is the event that matters. Expect every row to sit slightly later here than in a settlement dated report, and do not treat the gap as an error. The second is expecting the anchor and manual entries to be per marketplace. They are account level on purpose. You have one bank account and one business; a dividend or a stock purchase is not a British or German event. Payouts are marketplace scoped, because they arrive in a currency from a specific marketplace, and the marketplace filter applies to them. The third is leaving the anchor stale. The forecast is only as good as its starting point, and an anchor set six months ago and never revisited will drift away from your real balance one unlogged purchase at a time.

The refunds view sits as a tab on the P&L page, and its headline is not refunded revenue. Refunded revenue is only the first component of what a refund costs you: Net Refund Impact = refunded revenue + return related fees + cost of returned stock graded unsellable The third line is the one usually missing. When a unit comes back, Amazon grades it. Stock graded sellable goes back into inventory and the cost you paid for it is credited back to you, so it is recoverable. Stock graded damaged or defective is inventory you paid for and can never sell, so it is a write off, and it belongs in the cost of the refund. Six summary tiles carry the headline figures with comparison against the previous window of equal length. Their colouring is deliberately inverted against every other page in Shurq: on this page a fall is green, because less is better. Do not read a green downward arrow here as a decline in something good. Underneath, the rate trend plots your refund rate over time against your own catalogue average, so you can see which periods ran hot rather than only what the current number is.

Two different questions get confused constantly, and the page answers them separately. Why the customer says they returned it comes from the customer stated reason on the return, grouped into buckets you can act on rather than left as raw Amazon codes: Product or listing the item was not what the page implied Buyer's remorse they changed their mind Amazon or logistics damage, delivery, fulfilment Other That grouping is the actionable one. Product and listing reasons point at your detail page, your images or your sizing; remorse reasons rarely do. What condition it came back in is a different lane, read from the inventory ledger, and it is what determines whether the money is recoverable. A returned unit graded sellable is stock you still own. A damaged one is not. Two limits are worth knowing. Reason data is units only. There is no money figure at reason level anywhere in Amazon's data, so anyone showing you cost per reason is allocating it themselves. And not every account has return reason rows at all, because a financial refund is not always a physical FBA return; an empty reason panel on an account with real refunds is usually accurate rather than broken.

The worst offenders table ranks products by the money the refunds cost, not by refund rate, and flags the ones that are genuinely above your catalogue average rather than the ones that merely look it. The distinction matters more than it sounds. A crude rule such as more than one and a half times the catalogue average will flag a product with four units sold and one return, which tells you nothing, while missing a high volume product sitting slightly above average that is quietly costing you far more. Instead, a product is flagged only when the lower bound of its rate's confidence interval clears the catalogue average and it has enough units behind it to support the claim. Small samples are pulled towards the catalogue average rather than being treated at face value. The result is a shorter flagged list than a naive rule produces, and every item on it is real. Alongside it, the Reimbursement Radar looks for inventory Amazon may owe you for: units damaged in Amazon's care, units damaged in the warehouse, and units lost net of units later found, netted against reimbursements already paid. Values there are labelled as estimates because they are valued at your average selling price rather than at a figure Amazon has agreed. It is a prompt to file, not a receipt.

Reading the rate and stopping. Refund rate and refund cost move independently, and the most common pattern on this page is a rate that is improving while the money is getting worse. That happens when the mix of returns shifts towards stock coming back unsellable. Fewer returns, more of them written off, worse outcome. If the tiles say one thing and the impact figure says another, the reconciliation is almost always in the unsellable line, and the money is the number that matters. The second is expecting money to appear at reason level. It does not exist, here or anywhere. Reasons tell you what to fix; the condition and cost lanes tell you what it is worth. The third is treating a benchmark as an external one. Where the page ranks your rate against a distribution, that distribution is your own trailing history, month by month, plus the same window a year earlier. Comparing your rate against other sellers' data is prohibited by Amazon's Acceptable Use Policy, which is why no tool offers it and why this one does not either. The last is chasing the reason bars before checking volume. Sort by cost first. A reason bucket that dominates the chart on a low volume product is a smaller problem than a modest bucket on your best seller.