Marketplace Seller Analyst career guide

• Amazon-only seller brand

  Anker, Public Goods, Pattern, individual top-100 third-party sellers. Focus on Amazon Seller Central data shape: ASINs, FBA fees, Buy Box, sponsored ads. Deeper than multi-marketplace teams on Amazon-specific mechanics; narrower in scope.

• Multi-marketplace aggregator

  Thrasio-style roll-ups, large 3PLs with multi-tenant SKUs, brands selling on Amazon + Etsy + eBay + Walmart Marketplace. The analyst owns the cross-marketplace strategy: which products belong where, when to delist a cannibalized twin, how to reallocate inventory across platforms.

• Etsy-native craft / handmade brand

  Different mechanics — no Buy Box, no FBA. The analytics shifts toward listing CTR, search-keyword attribution, custom-order vs ready-to-ship economics, and Pattern (Etsy’s storefront product) integration.

• eBay seller / reseller brand

  Auction vs fixed-price dynamics, store subscription tiers, promoted listings (different from Amazon sponsored), feedback / reputation analytics. Smaller hiring market but specialty knowledge transfers within the platform.

• Platform-side at Amazon / Etsy / eBay

  Marketplace Insights, Seller Tools, Pattern, Search & Discovery teams. You analyze across thousands of seller tenants, not one. Bigger tooling, more A/B testing, less operational firefighting. Often pays better than seller-side.

1. 1

   Recruiter screen (30 min)

   Lightweight fit check. Be ready to explain why marketplace specifically (vs DTC, vs SaaS). Aggregator brands want to hear marketplace operational depth; platform-side wants engineering / product analytics fluency.

2. 2

   Hiring manager (45–60 min)

   Behavioral + domain depth. Expect a case-style walkthrough: "Our payout dropped 18% but GMV is flat — where would you look?" They’re testing whether you reach for fee-category breakouts (marketplace fee creep), refund-rate spikes, or ad-spend changes — fluently — without prompting.

3. 3

   Technical SQL screen (60–90 min, usually take-home)

   Postgres or Seller Central-shaped schema. Common asks: write the all-time settlement reconciliation, find the Buy Box loss-window cohort, surface the cross-marketplace cannibalization pairs. Edge cases matter — "what if a listing has settlement entries for refunds that posted in a different month than the original order?"

4. 4

   Cross-functional round (operations / marketing / finance)

   A non-analyst asks you to defend a metric or recommend a campaign trigger. Listing Manager will grill you on Buy Box methodology; Marketing Manager will challenge ad-attribution assumptions; CFO will probe the reconciliation arithmetic.

5. 5

   Director / VP round

   Strategy and prioritization. Common ask: "If you had 6 weeks, what would you build first as our new analyst?" The good answer is always "the per-(marketplace, month) settlement reconciliation, automated and self-serve, before any new analysis."

“Walk me through settlement reconciliation in SQL.”

Five SUM aggregates against fact_settlements: gross_amount, marketplace_fee, ad_fee, fulfillment_fee, refund_amount, net_payout. Equation: gross - marketplace_fee - ad_fee - fulfillment_fee - refund_amount = net_payout. The senior version groups by (marketplace, settle_month) for audit-grade output. The trap: forgetting refund_amount, which is economically equivalent to a fee from the seller’s perspective.

“How do you detect Buy Box loss windows?”

Conditional aggregation on fact_buybox_snapshots: SUM(CASE WHEN won_buybox_pct < 0.50 THEN 1 ELSE 0 END) per listing per period. won_buybox_pct is a fraction (0.0–1.0), not binary. The 0.50 threshold = "lost more than half the hour." HAVING loss_hours >= 5 surfaces multi-hour loss runs (transient losses are noise, not signal).

“Why doesn’t fact_orders.gross_amount equal SUM of fact_settlements’ payouts?”

Because fees and refunds net out 18-27% of GMV before payout. Specifically: gross_amount = marketplace_fee + ad_fee + fulfillment_fee + refund_amount + net_payout. The gap (gross - payout) is the cumulative platform take. Real settlement-report shapes denormalize gross_amount onto the settlement row to make the reconciliation join-free per row.

“How do you identify cross-marketplace cannibalization?”

GROUP BY product_title (or external SKU table when available) with COUNT(DISTINCT marketplace_id) >= 2. The trap: grouping by listing_id — twins have different listing_ids, so cannibalization never surfaces. Real warehouses use SKU mapping tables; in-seed product_title equality works when titles are clean.

“How is ROAS computed at listing grain?”

ad_attributed_revenue / ad_spend per listing, where both are aggregated only over orders with ad_fee > 0. Trap: dividing total revenue by total ad spend across all orders — meaningless because most orders aren’t ad-driven. HAVING SUM(ad_fee) >= $50 minimum threshold to avoid statistically thin listings dominating the top-ROAS list.

“What’s the difference between order_ts and settle_ts? When do you filter on which?”

order_ts = when the customer placed the order. settle_ts = when the marketplace paid the seller, typically 1-14 days later. Cash-flow questions (CFO, audit, board reports) belong on settle_ts. Product-velocity questions (merchandising, listing manager) belong on order_ts. Some questions span both (a March order velocity reconciled against April’s cash receipt) and require explicit timing logic.

• Amazon Advertising — Sponsored Ads Foundations / Retail / DSP

  Gold standard

  Free Amazon Ads training program. The foundations / retail / DSP tracks add up to a few hours; the certification is platform-recognized signal. Combined with portfolio work on real Sponsored Ads data, it’s the strongest credential for Amazon-side roles.

• Etsy Plus / Etsy Ads / Pattern training

  Nice to have

  Less formal than Amazon Ads. Etsy publishes some training material; mostly the credential is "have you used these tools." Build a portfolio Etsy listing and an Etsy Ads campaign instead.

• dbt Analytics Engineering certification

  Nice to have

  dbt is the modeling layer at most aggregator brands. The cert is signal but the portfolio of dbt models matters more. Build a public sample dbt project for a fictional multi-marketplace seller if you don’t have one already.

• Looker LookML developer certification

  Nice to have

  Useful at brands using Looker as their BI layer. Free LookML training; certification cost is moderate.

• Google Analytics 4 / GA4 certification

  Skip

  Marketplace analytics relies less on GA4 than on the marketplace’s own reporting. Skip in favor of Amazon Ads or Etsy Ads training.

• Reporting GMV (gross merchandise value) as "revenue." GMV is what customers paid; revenue is what the marketplace paid out — net of fees and refunds.
• Forgetting refund_amount in fee aggregations. Refunds are economically equivalent to fees from the seller’s perspective; omitting them makes reconciliation off by 5-10%.
• Date-filtering on order_ts when the question is cash-flow. Cash receipts attribute to settle_ts; product velocity attributes to order_ts. Match the filter to the question.
• Treating won_buybox_pct as binary (0/1). It’s a fraction of an hour (0.0–1.0). Filtering < 0.50 means "lost more than half the hour," not "lost the hour entirely."
• Identifying cross-marketplace cannibalization by listing_id instead of product_title. Each marketplace assigns its own listing_id; the cannibalization signal is same product_title across different marketplace_ids.
• Computing ROAS over all orders instead of ad-attributed orders. Most orders are organic; only ~5% carry sponsored attribution. Total revenue / total ad spend is a meaningless ratio.
• Forgetting the s.ad_fee > 0 filter in attribution queries. Including non-attributed orders inflates the denominator and dilutes the ROAS signal.
• Joining fact_settlements to fact_orders to get marketplace_id when settlements already have order_id. Sometimes the join is necessary (when you need order-only fields like units); often it’s redundant overhead.
• Trusting the marketplace’s self-reported "revenue" number on Amazon Seller Central's default report. The default screen sometimes excludes refunds and pending settlements; always reconcile against the Settlement Report itself.
• Over-indexing on Python early. Marketplace analytics rewards rock-solid SQL + platform fluency + stakeholder skills first; Python is the Year-3 lever.

The caseSQL Marketplace path can’t hand you Amazon Seller Central credentials or an Etsy shop dashboard — but the schema is the right shape, the gotchas are the same gotchas (GMV ≠ payout, Buy Box loss windows, cross-marketplace cannibalization, ROAS over the wrong denominator), and the canonical missions force the SQL skills the hiring loop screens on. The Hard tier (M11–M15) is the closest approximation of the live SQL screen; the Expert and Master tiers (M16–M25) are the take-home territory. M16 — the all-time settlement reconciliation across 4 fee types — is the question you’ll be asked in some form on every senior marketplace analyst loop.