Where Your Product Actually Appears in Shopping Results: Building Placement Intelligence With a Shopping API

E-commerce teams track their product pages obsessively and their shopping-placement visibility almost never — even though the shopping surface (Google Shopping results, product cards, seller listings) is where buying intent concentrates. A structured shopping-results API turns that blind spot into a feed. This is the build guide: what to collect, how to turn placements into decisions, and what it costs to run per market.

The Blind Spot, Quantified

Ask an e-commerce team where their product appears in search, and they’ll show a rank tracker. Ask where it appears in *shopping results* — which sellers surface, at what prices, in which positions, in which markets — and the answer is usually a manual check someone did last quarter. The gap matters because the two surfaces obey different rules:

That last row is the business case: on shopping surfaces, the seller above you at a lower price isn’t taking your traffic, they’re taking your sales. Teams that monitor the surface catch MAP violations, unauthorized resellers, and price erosion the day they appear; teams that don’t, catch them at the quarterly margin review.

What a Shopping API Delivers

The data shape to demand: structured shopping results per query, per market, with product title, price, seller, position, and product identifiers. Thordata’s SERP API covers the shopping surface among its engine variants — same endpoint, same structured-response contract, same per-response pricing (roughly $0.70–$1.20 per 1,000 responses at volume). One query to the shopping engine returns the placement set your market actually sees:

def shopping_snapshot(query, market):
    payload = serp_api.get(q=query, engine="google_shopping",
                           location=market, device="mobile")
    return [{
        "position": item["position"],
        "title": item["title"],
        "price": item["price"], "currency": item["currency"],
        "seller": item.get("seller"),
        "product_id": item.get("product_id"),     # joins to your catalog
        "is_us": item.get("seller") == OUR_STORE_NAME,
        "seen_at": payload["timestamp"],
    } for item in payload.get("shopping", [])]

def alert_worthy(snapshot):
    ours = next((s for s in snapshot if s["is_us"]), None)
    if not ours:
        return "absent", snapshot                  # we vanished from the surface
    above = [s for s in snapshot if s["position"] < ours["position"]
             and s["price"] < ours["price"]]
    if above:
        return "undercut", above                   # margin alert, not a rank alert
    return "healthy", None

The alert_worthy function is the difference between shopping monitoring and rank monitoring: an undercut alert — someone above you *and* cheaper — is a margin event, and it’s the alert shopping surfaces exist to fire.

The Decisions the Feed Drives

Placement intelligence earns its budget in four decisions:

1. MAP enforcement: resellers undercutting your minimum advertised price, caught the day they surface — with the structured record (seller, price, timestamp) as the enforcement letter’s evidence.
2. Unauthorized-seller detection: unfamiliar sellers on your listings — the shopping surface is where gray-market distribution shows up first.
3. Price positioning: your position-versus-price relationship per market, over time — the input for actual pricing strategy, not just price matching.
4. Market-entry triage: before launching in a new market, run the top category queries for a week: how dense is the surface, who’s above, what’s the price band. A week of snapshots replaces a quarter of guessing.

Pair it with the listing side — the product pages themselves — and the stack is complete: structured marketplace data via the Web Scraper API (Amazon, eBay, Walmart among the 120+ maintained targets, ~$0.50–$1.00 per 1,000 delivered results) plus the shopping surface through the SERP API. Product pages tell you what’s for sale; the shopping surface tells you who wins.

The Budget Arithmetic

A concrete monitoring program — 2,000 category queries, 5 markets, daily:

The entire placement-intelligence line prices under most teams’ rank-tracking SaaS spend — and unlike rank tracking, its alerts are denominated in margin.

FAQ

Doesn’t our marketplace analytics already cover this?
Marketplace dashboards show your own listings’ performance; the shopping surface shows the *market’s* — including resellers, gray-market sellers, and competitors who never appear in your own data. The two feeds answer different questions, and only one of them fires the undercut alert.

How is this different from plain rank tracking?
Different data and different alerts: ranks track position; placement intelligence tracks position *and price and seller together*, which is what margin events are made of. A seller appearing above you at a compliant price is competition; appearing above you at a violating price is enforcement.

What about the agent side — can agents query shopping results?
Yes, and it’s where this gets interesting: Thordata’s MCP server exposes the shopping engine variant as an agent-readable schema, so a pricing agent can decide to check the surface, choose the market, and react — with history and usage-statistics tools to audit what it did. The 500 free calls cover the first agent experiment.

How do we start?
One category, one market, the top 100 queries, daily snapshots for two weeks — then wire the undercut alert to one person who owns pricing. When the first alert arrives with a seller, a price, and a timestamp, the program funds itself for the year. Add agent-driven checks when the manual cadence starts feeling slow — that’s the sign the feed graduated from experiment to infrastructure.