AceClipper and an internal collector: turning web pages into product data

The problem

Manufacturers’ product data sits in text, structured data and scripts, behind tabs and dropdowns, in frames and linked PDFs, and every site differs. At Acelab, whose Material Hub is a materials-management platform for architects, owners and manufacturers, I built two Chrome extensions to bring it in:

• AceClipper, public on the Chrome Web Store (opens in a new tab). An architect opens it on a manufacturer’s page and pastes the products it finds into a project schedule, the spreadsheet-style product list for a drawing set.
• An internal extension for product-data reviewers. Automated scraping misses swatches on many manufacturer pages, so it collects swatches, finish photos and linked documents for a reviewer to check.

How it works

Both extensions use Manifest V3, read a page only after a click, and hand over a versioned JSON clip on the clipboard. They differ in where extraction happens. The demo below follows one clip from page to schedule.

{
  "version": 1,
  "source": "https://tiles.example/terrazzo",
  "products": [
    {
      "name": "Terrazzo Field Tile",
      "size": "24 × 24 in",
      "colors": ["Fog", "Ember", "Moss"],
      "images": ["…/field.jpg"]
    },
    {
      "name": "Terrazzo Bullnose Trim",
      "size": "3 × 24 in",
      "colors": ["Fog", "Ember", "Moss"],
      "images": ["…/trim.jpg"]
    }
  ]
}

AceClipper is a popup, a service worker and a content script injected only when needed, on https pages. Its capture holds the URL, title, up to 10,000 characters of visible text, meta tags, JSON-LD and up to 50 image URLs, each part guarded so one failure can’t sink the rest. In the .NET API, my endpoint asks OpenAI for products in a fixed shape and validates the answer, and the API drops any link from the model that isn’t http(s). Pasted into a schedule, the clip opens my import modal; the server creates the products, downloads and checks each image, and can match just the new ones.

The internal extension runs everything from Chrome’s side panel. Its service worker only opens the panel and holds no state, so suspension loses nothing. The panel injects a reader into the page and each readable frame, and results come back in an envelope that separates a value from an error, because a frame whose code throws otherwise returns nothing. The reader opens tabs, dropdowns and closed sections, never a product option, a form or a link off the page. Linked PDFs are fetched without the reviewer’s cookies and read with pdf.js. A run ends with a status: “complete” needs a count the page itself states that matches what was found, with nothing failed, cut short or unreadable.

On the receiving side, I built the review platform’s paste dialogs for images and documents and changed the Python workers so reviewer-added document links survive a rescrape. I later re-implemented the extension’s rules as a page scan in the server-side scraper, with no LLM, tested against the extension’s frozen ground truth.

Decisions

What I’d change

The model failed quietly. A reported page with 16 color variants came back empty: the model listed each variant as a product, hit the output limit, and the endpoint returned an empty list. I changed the prompt to treat schema.org JSON-LD as strong evidence and fold variants into one product, raised the limit, and made a truncated answer return a clear error. I’d give the LLM path a frozen test set from day one.

Outcome

Architects can paste products from manufacturer pages into schedules with AceClipper, public on the Chrome Web Store.

For the internal extension, the number that matters is recall: of the files reviewers ended up approving, how many the tool had already found. Replayed offline against reviewers’ decisions on 23 products, it found 117 of 164 (71%), up 14 points from 94 (57%) before a round of fixes. Higher recall means more of the files reviewers keep are already collected when they open a product; the replay measured recall, not reviewer time. Recall isn’t precision either: it doesn’t count the wrong files the tool also suggests, which is why reviewers still approve or reject every one. On a separate 11-page benchmark of the pages it was developed against, it found all 245 files those pages link to directly, against a 95% target, and suggested the right file type 96% of the time, against 90%.