Skip to content
SemCue

Gertner Data · tools for automation

Websites and PDFs into data.With a source and a history.

An automated workflow needs records it can pass to a spreadsheet, catalogue, search index or its next step. We built the Gertner Data family to read sitemaps, PDF tables and job boards, keep their sources and distinguish genuine changes from failed reads.

Published · products available in Apify Store; public listings checked on 19 October 2026

Product workflow diagram

Sitemap
PDF table
Job board
Gertner DataRead. Validate. Compare.

Source · coverage · changes · errors

JSON / CSVRecords and a snapshot for the next step

A workflow needs records it can act on

A sitemap lists page addresses. A PDF spreads a price list across pages. Each recruitment platform uses its own field names. Passing these through unchanged leaves the next step to handle every source differently.

We built focused tools with defined output fields, read status and enough state to continue the process. On the next run, the monitoring tools accept a saved snapshot and return the changes against it.

  • Sitemap Diff

    What changed on a website

    New URLs can enter a crawl queue. Removed URLs and changed metadata receive their own events. The comparison covers sitemap membership and metadata.

  • PDF Tables

    A table with its evidence

    Rows export to JSON and CSV with a page, table and document identifier.

  • Job Feed Delta

    How a job board changes

    New roles, field updates and confirmed absences across Greenhouse, Lever and Ashby use a shared schema.

A timeout must not become a closed vacancy

Suppose an employer’s website stops responding. A basic monitor treats the empty result as a closed job board. When the website recovers, it announces the same vacancies as new. The recipient gets noise instead of useful events.

Our tool retains the previous board state when a read fails. The first successful check without a role marks it as missing. A second successful observation triggers the closure event. That still means absence from the source: it does not claim someone has been hired.

A separate guard stops mass removals when most roles suddenly disappear from a sufficiently large board. The source needs checking before that change is accepted.

Product workflow diagram

  1. Snapshot savedVacancy present in source
    Baseline
  2. Source timed outPrevious snapshot retained
    No closures
  3. Successful readFirst confirmed absence
    Await confirmation
  4. Successful read againVacancy still absent
    CLOSED event
This diagram follows a local run of the product’s actual comparison function with a fictional vacancy. No external service was called.

An incomplete crawl is not treated as page removal

A nested sitemap may be temporarily unavailable, or a crawl may reach its limit before the last file. Neither proves that pages have been removed.

Sitemap Diff permits removal events only when both snapshots are complete and cover the same root sitemaps and filters. Errors, conflicting duplicates and crawl limits appear in the summary. The next process can check coverage before changing its catalogue.

Changed sitemap metadata does not prove that page text has changed. Page content needs a separate crawl.

Every row leads back to its PDF

When a table enters an accounting system or catalogue, the reader needs to know where each value came from. Records retain the document, page, table and row position. A content-based document identifier gives identical files the same identifier.

Values that look numeric remain strings. An item code keeps its leading zero, and local punctuation does not silently change an amount. CSV exports escape values that a spreadsheet might interpret as formulas.

The extractor reads the PDF text layer. A scan without text receives an explicit status; image recognition is outside this product’s scope.

Failures stay visible and limits are set in advance

A successful response is only part of an integration. The caller also needs to distinguish an unavailable source, an unsupported document and a reached limit. Tools return these states separately so the workflow can stop or retry the relevant step.

Network access has boundaries: public addresses, bounded responses and timeouts. The calling workflow owns its snapshots and decides when to check again and which version to use as its baseline.

What supports this case
  • Sitemap Diff, PDF Tables to Records and Job Feed Delta have public listings in Apify Store.
  • Retaining a snapshot during a timeout and closing after a repeated observation were reproduced locally using the product function.
  • Diagrams explain the mechanism. This case makes no claims about customer revenue or measured time savings.

How it was built

From a one-off scrape to a repeatable process

We separated source reading, normalisation and state comparison. Network failures therefore stay distinct from business events, and the caller receives a snapshot for its next run.

  • CollectRead an authorised source within defined limits.
  • CheckRetain provenance, coverage and read errors.
  • ConnectPass records and a snapshot to the next workflow step.

For technical readers

For technical readers

Runtime
Python and Node.js, with separate product contexts on Apify.
State
Explicit snapshots. Job-board comparison is a separate function with no network requests.
Provenance
PDF content hash, page, table and row; snapshots and observation times for changes.
Boundaries
Public HTTP(S) sources, address validation, read limits and structured errors.

Where the numbers come from

Sources

Next system

AI sales operator →

SemCue / Let’s talk

What would you like to work on?

Tell us about your project and what you need. A rough idea is enough.

Get in touch on Telegram

We’ll discuss your goals, where things stand and the right next step.

Discuss your project on Telegram
In developmentThis site is still being built, so things may change.