Industrial Procurement Watchlist

Monitor public industrial product pages for procurement-relevant changes over time.

Signal Veqrin Industrial Procurement Watchlist is designed for procurement teams, sourcing teams, operations teams, and engineering organizations that need to monitor known industrial products across public supplier pages.

Who it's for

Typical use cases include:

• Monitoring known components across multiple suppliers
• Tracking price and availability changes
• Watching lead-time changes for important components
• Maintaining a recurring watchlist of industrial spare parts
• Feeding structured procurement observations into downstream workflows

The Actor monitors product pages supplied by the user. It does not automatically discover an entire supplier catalog.

Input

Provide a watchlist containing product-page URLs.

Each watchlist item requires:

• url — public HTTP or HTTPS product-page URL

Optional fields:

• sku — supplier SKU or catalog number
• manufacturer — manufacturer name
• mpn — manufacturer part number

maxItems controls how many watchlist entries are processed in a run. It defaults to 100 and supports up to 5,000 supplied items.

Output

The Actor writes structured records to the Apify Dataset.

The main dataset view exposes:

• Product identity
• Current price and currency
• Availability
• Stock quantity
• Lead time
• Pack size and unit
• Minimum order quantity
• Observation time
• Extraction confidence
• Source URL
• Detected changes
• Procurement signals
• Warnings

Each complete dataset item also contains the structured product, supplier, source, current, identity, previous, changes, procurementSignals, and warnings sections.

Industrial Procurement Watchlist takes a list of public product URLs, extracts structured product and procurement information, maintains product history across runs, and reports meaningful changes such as price movements, stock changes, lead-time changes, and pack-size changes.

What it does

For each product page, the Actor can extract:

• Product name
• Manufacturer
• Manufacturer part number (MPN)
• Supplier SKU
• GTIN when available
• Current price and currency
• Availability and stock status
• Stock quantity when available
• Lead time and lead-time days
• Pack size and unit
• Minimum order quantity (MOQ)
• Source URL and observation timestamp
• Extraction confidence
• Stable product identity

On later runs, the Actor compares the current observation with the previous saved observation for the same product.

Change detection

The Actor can report:

• PRICE_INCREASED
• PRICE_DECREASED
• OUT_OF_STOCK
• BACK_IN_STOCK
• LEAD_TIME_INCREASED
• LEAD_TIME_DECREASED
• PACK_SIZE_CHANGED

The first successful observation establishes the baseline. It does not generate a change event simply because the product was seen for the first time.

Procurement signals

The Actor derives procurement-oriented signals including:

• Effective unit cost
• Cost pressure
• Supply risk
• Packaging change

For example, a price increase can produce a cost-pressure signal, while an out-of-stock transition or increasing lead time can produce a supply-risk signal.

These signals are based on observed product data and detected changes. They are not forecasts of future prices, availability, or supplier behavior.

How to use it

Provide a watchlist containing public product URLs.

A watchlist item can optionally include a manufacturer, MPN, and supplier SKU.

Only the product URL is required.

The Actor supports up to 5,000 watchlist items per run.

First run vs. later runs

First run

The Actor:

1. Fetches each supplied product page.
2. Extracts and normalizes product information.
3. Resolves a product identity when possible.
4. Saves the current observation as the baseline.
5. Returns the current product data with no change events for the initial observation.

Later runs

The Actor:

1. Fetches the supplied product page again.
2. Loads the previous saved product state.
3. Compares the current observation with the previous observation.
4. Reports detected changes.
5. Calculates procurement signals.
6. Saves the new observation for the next run.

Product state is persisted in the Actor's Key-Value Store.

Product identity

History depends on resolving a stable product identity.

Identity resolution uses available identifiers in this order:

1. Manufacturer + MPN
2. GTIN
3. Supplier SKU
4. Canonical URL
5. A fallback combination of available product fields

If no usable identity can be resolved, the Actor returns the product data but does not maintain persistent state for that observation. A structured IDENTITY_UNRESOLVED warning is included.

Output

Each dataset item contains structured sections including:

• product
• supplier
• source
• current
• identity
• previous
• changes
• procurementSignals
• warnings

The dataset view highlights the main procurement fields while the complete structured item remains available for downstream processing.

Supported scope

The MVP is designed for:

• Publicly accessible industrial product pages
• Product pages that expose useful information in returned HTML
• User-supplied product URLs
• Repeated runs against the same products
• Structured procurement monitoring

The Actor monitors known product pages rather than automatically discovering an entire supplier catalog.

Current limitations

The MVP does not provide:

• Automatic supplier or product discovery
• Login or authenticated-page access
• CAPTCHA solving
• Browser automation for JavaScript-only applications
• Automatic proxy management
• Email or Slack notifications
• Forecasting or machine-learning predictions
• Supplier recommendations
• Full-catalog crawling from a single starting URL
• Replacement functionality for an ERP, procurement system, or supplier portal

Results depend on the information made publicly available by each product page and on the extraction methods supported by the Actor.

Reliability and confidence

Each observation includes extraction-confidence metadata.

When a stable identity cannot be established, the Actor intentionally avoids creating persistent history rather than guessing an identity that could merge different products.

Request failures are handled by the crawler's retry mechanism. Failed requests are reported in the run logs.

Example workflow

A procurement user can provide a recurring watchlist of known supplier product pages.

The first run establishes the baseline.

A later run might report:

• Product A: price increased and cost pressure detected
• Product B: in stock to out of stock and supply risk detected
• Product C: lead time increased and supply risk detected

This allows downstream systems or procurement workflows to consume structured changes instead of repeatedly comparing raw product-page snapshots.

Data and privacy

The Actor is designed to process publicly accessible product-page information supplied in the watchlist.

Do not provide credentials, passwords, private customer information, or other sensitive information as product-page input.

Getting started

1. Add public industrial product URLs to watchlist.
2. Optionally provide manufacturer, MPN, and supplier SKU.
3. Run the Actor.
4. Review the resulting dataset.
5. Run it again later to detect changes against the saved product history.

The first run establishes the baseline; subsequent runs provide the monitoring value.