DEV Community: Tim Zinin

Import SEC Form D search hits without inventing a funding-round record

Tim Zinin — Mon, 26 Oct 2026 03:54:02 +0000

A search hit for a Form D filing is useful primary-source research evidence. It is not automatically a completed funding round, a final amount raised or a verified link to a company domain. A pipeline that converts every hit into a funded badge adds claims the collection did not establish.

The Actor at funding-round-tracker is currently titled SEC Form D Search Evidence. It returns identified SEC search hits with filing links and decision-support fields. Its stable URL remains useful, but consumers should read the current contract rather than infer behavior from the historical slug.

Make the query scope explicit

This is the installed public example. It searches a phrase within a declared lookback and limits collection. It is a proposed request, not a new list of filings retrieved for this article.

{
  "queries": [
    "artificial intelligence"
  ],
  "sinceDays": 180,
  "limit": 1,
  "maxConcurrency": 1
}

The runtime validates types and bounds instead of quietly coercing malformed settings. Keep the submitted query and date window beside every imported filing identity. A broad phrase can match text beyond an issuer name; a hit for that phrase is not a corporate-domain match.

Require an identified document

A useful filing row needs an accession number and a direct filing URL. Deduplication uses the filing identity so overlapping queries do not turn one document into several supposed transactions. Rows lacking the required identity remain source-shape diagnostics rather than invented billable records.

Retain accession, CIK, filed date, source URL and the query evidence. Store them in a filing table first. A separate relationship can link a reviewer-approved issuer to your company record. That separation lets you correct an attribution mistake without rewriting the original source observation.

Keep the filing distinct from a financing claim

The SEC describes Form D as a notice of an exempt offering. A notice can be amended, and search metadata is not a complete account of offering proceeds, valuation, investors or a venture-stage label. Open the cited document when the business question requires those details, then record precisely which statement the document supports.

The installed decision layer makes this distinction visible through confidence risks, gaps and a recommended next action. Preserve those fields instead of retaining only the filer name. A research queue with explicit issuer verification is more useful than an apparently enriched CRM field whose meaning cannot be reconstructed.

Separate no match from unavailable collection

An empty successful query is a bounded no-match result. A failed source request cannot establish that no filing exists. The Actor returns free outcome rows for relevant diagnostics, while OUTPUT reconciles source success, candidate counts, merged duplicates, delivery and partial state.

Import filing evidence and run-level coverage together. A partial run can leave useful identified rows while some queries remain unmeasured. The Actor is stateless and can return the same current matches again on another run; keep destination keys based on filing identity and inspect uncertain delivery before repeating collection.

For a regression fixture, pass duplicate observations of one accession through the local deduplication function and verify that the filing remains one identity with query context. Add a hit without an accession and require a diagnostic. Those local checks validate transformation behavior only. They do not establish source availability or verify any company's financing history, and a later platform run can charge again for already known filing evidence.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.005 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.2.1 (f0CCbAPsWFaOPjLI6) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Turn a missing website fingerprint into a review task rather than a removal claim

Tim Zinin — Mon, 26 Oct 2026 01:30:00 +0000

A script disappearing from one HTML response does not prove that a company removed the product. The page could be different, a consent system could suppress the tag, or the signature catalog could miss the implementation. Website technology comparison is more useful when it retains that uncertainty.

Tech Stack Change Detector fetches a bounded public page and compares observed catalog signatures with an optional supplied baseline. It is stateless: the baseline comes from your input rather than an automatically remembered previous run. Your surrounding system therefore owns the comparison history.

Supply the baseline you actually mean

This installed public example requests a current observation and a comparison for the same domain. They are different requests because one includes WordPress as previous evidence. The example does not assert that the site currently uses or has removed WordPress.

{
  "items": [
    "gymshark.com",
    "gymshark.com|WordPress"
  ]
}

Save the baseline's capture time, page URL and collection method outside the pipe-delimited input. A list copied from an unrelated detection service may cover different pages and signatures. Without that context, the resulting added and removed compatibility fields can be mistaken for real installation events.

Preserve evidence type instead of raw page content

The installed catalog can recognize public HTML patterns, final-URL patterns, response-header names and site-scoped signatures. Evidence rows identify the technology, category and matching evidence types. Raw HTML and header values are not emitted as evidence fields.

That is useful for a review queue: an analyst can see whether a claim came from a header or a page signature. It is still bounded evidence from the requested page. The catalog is curated and not exhaustive, and subpages are not scanned as a complete website inventory. Retain those gaps in any downstream technology profile.

Interpret additions and non-observations conservatively

Current-only names are candidate additions. Baseline-only names are candidate non-observations. Neither establishes an installation or removal date. Keep the exact comparison status, confidence reasons and recommended action rather than flattening the row into a Boolean migration trigger.

A successful response with no catalog match is also different from a fetch failure. The first is a bounded negative observation; the second supplies no usable page evidence. If an operations dashboard combines them into one empty list, the next comparison can generate artificial changes caused entirely by collection failures.

Use a review gate before commercial routing

The Actor includes stable IDs, timestamps, coverage and failure information. Keep those fields with the proposed change in your CRM or research table. A candidate Shopify or WordPress change can justify opening the cited page, but it does not establish budget, buying intent or permission to contact anyone.

For a local parser fixture, use a clearly synthetic HTML signature and a known response-header name, then verify the retained evidence types. Separately validate baseline ordering and case normalization. These checks do not test the remote website or production fetch transport. Before treating a later authorized platform result as a real migration signal, compare the same URL and scope, inspect its gaps, and confirm the change against another suitable source or manual page review. The output then becomes a traceable investigation task rather than a definitive claim unsupported by one response.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.01 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.2.1 (vVMauRfR9rJmzCCJ2) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Watch a newest-first property window without forgetting displaced listings

Tim Zinin — Sun, 25 Oct 2026 23:05:58 +0000

A listing that falls out of the first ten search results and later returns is not necessarily a new property. A monitor that remembers only its latest window can repeatedly announce and bill that same identity. A rolling-window watch needs durable seen history as well as an honest statement of what it observed.

Re New Listing Alert watches a named portal search. Its Krisha adapter uses an explicit newest-first window and preserves a union of seen listing identities. The observation is bounded: newly entering this watch is not the same claim as newly published anywhere in the market.

Keep the watch definition stable

This is the installed public example for Almaty apartment sales. filter.max_items controls the source sample here, while the outer max_items caps new-listing delivery. The JSON illustrates the request; it is not a fresh inventory of available apartments.

{
  "portal": "krisha-kz",
  "filter": {
    "queries": [
      "sale:apartment:almaty"
    ],
    "max_items": 10,
    "max_pages": 1
  },
  "watch_name": "almaty-apartments-example",
  "max_items": 10
}

Store portal, filter, watch_name and collection limits together in your configuration. If you change the business meaning of the search, use a deliberate new watch or document the transition. Reusing a familiar display name for a materially different search makes historical new-listing counts difficult to interpret.

Treat first observation as a baseline

The first accepted check establishes which listing identities are already known. A baseline-created row explains that state; it is not a batch of previously unseen opportunities relative to a nonexistent earlier observation. A baseline snapshot can itself be a paid result, so inspect the current listing and spending limit before starting a watch.

Later complete observations can deliver identities absent from the durable seen set. For Krisha, the declared add_date-desc ordering and clean parsing of the window support rolling-ranked-window status. They do not prove a full-market crawl. Other portals have their own completeness requirements; do not transfer Krisha's window acceptance rule to every adapter.

Preserve identities outside the current window

The durable union matters when listing A is present, disappears behind newer results and later returns. If A was already delivered or included in the baseline, its return is not a first observation. A store containing only the current ten IDs would lose that fact and create repeated alerts.

Keep your destination's own delivered identity record as an additional import guard. A run outcome and a successful downstream import are different boundaries. If your consumer stops after receiving several rows, replay the saved Dataset into your destination with idempotent destination keys rather than automatically recollecting the whole source window.

Keep partial checks from advancing history

Partial snapshots, errors and quiet checks do not become new paid listing results. An unconfirmed charge or broken contract must not advance the affected baseline. Inspect partialReason, snapshotMode and observed counts instead of relying on a single found flag.

For a useful fixture, arrange windows A/B, B/C and A/C and verify that A's return is not new. Add an incomplete middle observation and confirm that it does not silently rewrite history. The real platform acceptance must also inspect named storage and charge counters; a pure local set comparison cannot establish those effects. In the reporting interface, label the metric as first observed by this watch and show its configured window alongside the alert count.

Price and verification scope

This article is pinned to public latest build 0.1.8 (0dxwpu6Gzsqxs8zpt) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Report a listing price sample with its currency and denominator intact

Tim Zinin — Sun, 25 Oct 2026 20:41:56 +0000

An average asking price can look precise while mixing rental listings, sale listings and several currencies. The problem is not solved by adding more decimal places. The report needs a declared market slice, a native currency and the sample counts that actually contributed to each statistic.

Real Estate Price Index collects bounded samples from supported city sources and returns city-level asking-price observations. These are listing prices, not completed-sale valuations or appraisals. A useful dashboard keeps that distinction in its title and export schema.

Make the collection scope inspectable

This is the installed public input example. It requests bounded samples for two cities and does not claim that the sources are currently available or representative. No fresh listing collection was performed for this article.

{
  "cities": [
    "tbilisi",
    "vienna"
  ],
  "max_items_per_city": 20,
  "max_pages_per_city": 1,
  "max_concurrency": 2
}

Each city has a source, native currency and default market slice. Vienna uses apartments for sale, while the current Tbilisi slice includes property and deal types more broadly. A comparison that omits those differences can mislead even if each arithmetic result is correct. Keep source_portal, deal_type and property_type with the numbers.

Separate currency filtering from conversion

The installed aggregation requires a listing to declare the city's exact native currency. Missing currency and explicit mismatches are excluded instead of inferred. currency_filtered_rows and currency_missing_rows explain the exclusions. A row with an attractive price and unknown unit should not sneak into the denominator.

The Actor does not convert currencies. If you later present cities in a common unit, save the rate source, timestamp and conversion policy separately, and retain the original native figures. Do not apply the current rate silently to a historical observation and then describe the resulting difference as a change in the property market.

Use the right denominator for area statistics

At least five native-currency prices are needed for a city index. Smaller samples keep statistics unavailable rather than returning a confident median from too little data. Price per square meter has its own sample because some listings do not publish usable area.

Export sample_size and sample_size_price_per_sqm as different columns. A median asking price based on twenty listings and a per-area median based on five listings are not the same measurement. Missing area cannot be replaced with zero, and the median price divided by median area is not automatically the median of listing-level price-per-area observations.

Distinguish bounded collection from a broken scan

A source-confirmed complete scan is required for a paid index. A sufficiently large but partial scan remains free source_partial evidence; an undersized one is insufficient_sample. Preserve these reasons and the final summary's missing and partial cities in your report.

The source sample is bounded by item and page settings. Completeness of the configured scan does not mean that every listing in the city was observed. Keep the collection limits with the snapshot, especially when comparing successive reports. A changed item cap or portal mix can change the sample without any underlying price movement. For an acceptance fixture, test missing and mismatched currencies, too few valid prices and missing areas before using the result in a city comparison.

Price and verification scope

This article is pinned to public latest build 0.1.2 (fnqaxC4zVnvbPqqtc) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Quarantine conflicting tennis records before computing player summaries

Tim Zinin — Sun, 25 Oct 2026 18:17:54 +0000

A duplicate match should not add a second win to a player's history. A conflicting duplicate is more difficult: choosing whichever row arrived last can create a clean-looking summary while concealing a source disagreement. A quality step should keep that identity out of the aggregate until the conflict is resolved.

Tennis Match Dataset Quality Analyzer validates supplied records and returns descriptive historical summaries plus quality findings. It does not collect match results or predict future performance. The useful output is an inspectable account of the submitted batch.

Keep provider identity in the input

This fictional synthetic match follows the installed README's real-analysis example. demo:false selects the billable analysis route when a useful report is produced; fictional data does not automatically make that route free. No platform run was started for this article.

{
  "demo": false,
  "matches": [
    {
      "namespace": "synthetic-example",
      "matchId": "demo-match",
      "playedOn": "2026-09-01",
      "winnerId": "demo-player-a",
      "loserId": "demo-player-b",
      "status": "completed",
      "surface": "hard",
      "bestOf": 3,
      "sets": [
        {
          "winnerGames": 6,
          "loserGames": 3
        },
        {
          "winnerGames": 7,
          "loserGames": 5
        }
      ]
    }
  ]
}

namespace scopes matchId and player IDs. Do not remove it when combining providers unless you have separately established their crosswalk. The analyzer does not perform fuzzy player matching or merge identity spaces. Keep a mapping review outside the quality report when two feeds use different IDs for the same person.

Read set orientation carefully

winnerGames and loserGames follow the overall match winner and loser. In a set lost by the eventual match winner, winnerGames can be smaller. Relabeling each set independently would change the meaning of the record and can produce incorrect match validation.

The supported completed-set formats include ordinary six-game sets and supported tiebreak endings. Short-set, match-tiebreak and advantage-set formats are outside this contract. If your feed uses them, route those records for an explicit adapter decision rather than coercing them into the nearest allowed score. Unsupported scoring should remain visible as a quality issue.

Quarantine by identity rather than arrival order

Normalized exact duplicates count once; JSON property order alone does not create a conflict. Conflicting valid rows quarantine their whole identity group. A malformed row with a readable identity also quarantines valid siblings in that group. Independent valid identities remain usable, so a partial report can still carry useful descriptive results.

That behavior belongs in the importer's acceptance criteria. Test one exact duplicate, one conflict for the same namespace and matchId, and another independent valid match. Inspect the accepted counts and issue row indexes rather than only the run status. A successful computation is not enough if the downstream importer silently reintroduces the quarantined records.

Keep descriptive statistics descriptive

Retired and walkover records do not become ordinary completed wins in the same way as accepted completed matches. The report distinguishes those categories and can return null rates where no completed-match denominator exists. Preserve null rather than replacing it with a zero-percent estimate.

issues is bounded to 100 findings while counting continues; issuesTruncated signals more evidence than the displayed list. Fetch the complete nested Dataset report and retain the quality section with the player summaries. Each new run is a new analysis, and an uncertain Dataset write is not automatically retried. Inspect the existing Dataset and event counters before repeating delivery. This establishes a reproducible batch-quality boundary without turning a historical sample into a skill ranking or source-accuracy certificate.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.15 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.1.5 (gDFJh50dTmhscNQ3e) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Review Wikidata sports candidates before joining two provider ID spaces

Tim Zinin — Sun, 25 Oct 2026 15:53:52 +0000

Two sports providers can use different IDs for the same player, but a shared name is not enough to join their records. Main teams, reserve sides, women's teams and unrelated works can have similar labels. Candidate retrieval should help a reviewer inspect that ambiguity rather than hide it behind a single automatic match.

Sports Team and Player Identity Candidate Matcher connects your sourceId to examined Wikidata candidates and their structured evidence. It returns candidate reports, not verified identities. A resolved QID is a specific source entity; it does not prove that your provider record refers to that entity.

Retain your provider's identifier

The installed public example uses an explicit sourceId for each query. One query searches a name; the other reads a supplied QID. This article validates the input shape only and makes no new claim about the current candidate list or current Wikidata facts.

{
  "queries": [
    {
      "sourceId": "team-home",
      "name": "Bayern Munich",
      "sportQid": "Q2736"
    },
    {
      "sourceId": "player-1",
      "qid": "Q1426",
      "name": "Roger Federer",
      "sportQid": "Q847"
    }
  ],
  "candidateLimit": 3
}

Keep your original provider namespace with sourceId in the destination. The same short source ID from two providers is not one global key. Save the candidate report separately from an approved crosswalk, with reviewer, decision time and the source revision used for that decision.

Distinguish search scope from identity confidence

Name search is English and bounded by candidateLimit, with a maximum of five. The result order follows the source rather than a calibrated confidence score. One returned candidate can mean one candidate was examined, not that no alternative exists. An empty examined result likewise does not establish global nonexistence.

When a QID is supplied, the Actor reads that entity directly and can compare the accompanying name with labels and aliases. Name agreement normalizes text, but remains name agreement. Do not promote an exact label match into proof of the correct club, player or historical organization.

Interpret constraints as exact observed claims

sportQid, countryQid, nationalityQid and typeQid refer to different Wikidata properties. Country and citizenship are not interchangeable. A requested claim can be observed, absent from the observed values, or unstated. Preserve those states rather than compressing them into one Boolean called verified.

The matcher does not traverse subclass hierarchies or interpret temporal qualifiers. A claim observed in the source does not automatically establish current membership or eligibility. qualifyingCandidateQids records candidates satisfying the supplied exact constraints; when none are supplied, it includes all returned candidates. That field is a filter result, not an approved identity crosswalk.

Preserve revisions and review partial work

Real reports include source URLs, retrieval times, revision IDs and response hashes with Wikidata attribution. Keep those receipts when copying the evidence to another system. They explain which source observation supported a later human mapping, even if Wikidata changes afterwards.

Before importing a batch, require an explicit review outcome for ambiguous candidates and inspect which sourceIds were actually delivered after a partial run. Rerunning the whole batch can charge again for already resolved reports. For a safe local contract check, validate the sourceId uniqueness and candidate limit without making source requests. For a later authorized platform check, inspect Dataset evidence and actual charge counters before deciding that an uncertain run needs repetition.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.005 for apify-actor-start and $0.003 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.1.1 (eoDXifyBMDq70R7oa) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Aggregate a job-board sample without exporting its raw job identities

Tim Zinin — Sun, 25 Oct 2026 13:29:50 +0000

A useful hiring dashboard does not always need the job titles, company names and source identifiers behind every row. An aggregate can support a narrow planning question while deliberately withholding small groups and raw identities. The boundary needs to be described precisely: suppressing fields in the output does not erase the input submitted to the platform.

Job Board Market Demand Analyzer accepts buyer-supplied normalized observations. It does not collect a new job market sample. Its closed input contract and minimum group size make the resulting report more predictable for downstream consumers.

Declare the sample scope explicitly

This example retains three observations from the installed fictional synthetic prefill. The sample label is intentional. These rows demonstrate the contract and do not establish demand in Tbilisi or any other labor market. The real analysis route can bill for a useful report even when the supplied observations are synthetic.

{
  "schemaVersion": "1.0",
  "analysisId": "synthetic-engineering-demand-sample",
  "sampleCompleteness": "BOUNDED_OR_PARTIAL_SAMPLE",
  "observations": [
    {
      "sourceBoard": "synthetic-job-board",
      "sourceJobId": "synthetic-001",
      "title": "backend engineer",
      "company": "synthetic company alpha",
      "location": "tbilisi",
      "category": "engineering",
      "employmentType": "full-time",
      "remote": false,
      "salaryMin": 3000,
      "salaryMax": 4500,
      "salaryCurrency": "GEL",
      "salaryPeriod": "month",
      "postedAt": "2026-08-25T09:00:00.000Z"
    },
    {
      "sourceBoard": "synthetic-job-board",
      "sourceJobId": "synthetic-002",
      "title": "data engineer",
      "company": "synthetic company beta",
      "location": "tbilisi",
      "category": "engineering",
      "employmentType": "full-time",
      "remote": true,
      "salaryMin": 3500,
      "salaryMax": 5000,
      "salaryCurrency": "GEL",
      "salaryPeriod": "month",
      "postedAt": "2026-08-26T09:00:00.000Z"
    },
    {
      "sourceBoard": "synthetic-job-board",
      "sourceJobId": "synthetic-003",
      "title": "platform engineer",
      "company": "synthetic company gamma",
      "location": "tbilisi",
      "category": "engineering",
      "employmentType": "full-time",
      "remote": false,
      "salaryMin": 4000,
      "salaryMax": 5500,
      "salaryCurrency": "GEL",
      "salaryPeriod": "month",
      "postedAt": "2026-08-27T09:00:00.000Z"
    }
  ]
}

sampleCompleteness travels with the report. A bounded export cannot become a complete market simply because the transformation succeeded. Retain the sampling method and collection period in your surrounding dataset, and keep that description beside every chart built from the aggregate.

Validate the whole batch before summarizing

The installed contract accepts 3–500 observations and requires sourceBoard, sourceJobId, title, location and an exact UTC postedAt. Duplicate normalized source-board/job-ID pairs reject the input. Unknown fields and incomplete salary tuples also reject it rather than silently changing the measurement basis.

Salary evidence needs all four fields: minimum, maximum, currency and period. A monthly GEL range and an annual EUR range are different groups; the Actor does not convert or infer their comparability. Do that work separately with an explicit policy if the eventual report requires a common unit.

Understand what the privacy threshold does

Exact normalized labels appear in topGroups only when at least three observations contribute. Salary distributions also need at least three complete ranges in the same currency-period group. A missing group can therefore mean it was withheld by the threshold, not that no such jobs existed in the input.

Raw titles and company names participate in validation and fingerprinting rather than being returned as raw report rows. Source job IDs support validation, deduplication and fingerprinting. The report still describes a particular submitted sample, and aggregate suppression alone should not be presented as a formal anonymity guarantee.

Separate output minimization from input retention

The original INPUT remains subject to the Apify account's storage and retention settings. Sending unnecessary personal or confidential fields and assuming they disappear because the Dataset is aggregated would misunderstand the product boundary. Prepare only the normalized job facts the contract needs before submitting the batch.

For a local fixture, compare three same-location observations with a batch split into groups of two and one. Verify which labels are exported and which are withheld. Add a duplicate source identity and confirm that validation rejects the batch. Finally, inspect the report for raw job identifiers before wiring it into a shared dashboard. Those checks validate the data contract; they do not prove that the original sample represents the wider market.

Price and verification scope

FREE-tier event prices read on 24 October 2026 are $0.006 for apify-actor-start and $0.019 for result-found. Start-event count can depend on allocated memory; other account tiers have their own rates. Check the listing's current billable unit and the platform's run spending limit before executing an example. Input row or result caps are separate from Max total charge. A free diagnostic does not necessarily remove the platform start charge.

This article is pinned to public latest build 0.1.6 (TYZPCP9rEG1Gb1Uyl) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Give a hiring trend its own baseline and a visible coverage boundary

Tim Zinin — Sun, 25 Oct 2026 11:05:48 +0000

A current job count becomes a trend only when there is a comparable previous observation. The first successful check cannot establish growth by itself. A monitoring integration should make that first snapshot visible and keep incomplete collections from quietly replacing the comparison point.

Hiring Trend Index watches explicit company or board slices. Company slices can name a provider and token; board slices describe a bounded market sample. These are different observation scopes, even when both eventually produce counts of engineering roles.

Name the experiment before collecting it

The following input is the installed public example with an explicit watch name. The listed organizations and keywords identify collection targets, not freshly verified vacancy totals. Using the same watch_key preserves the intended comparison history; a new watch starts a separate one.

{
  "slices": [
    "company:greenhouse:gitlab",
    "board:xing-jobs:engineering"
  ],
  "watch_key": "software-hiring-example",
  "new_window_days": 30
}

Keep your watch definition in version control or a configuration table. Record the slices and the company lookback setting with each exported observation. If the definition changes materially, start a separately named series or annotate the break rather than treating the next count as directly comparable with the old one.

Preserve the first-check distinction

A baseline-created row is a current snapshot. The next complete observation can report before and after counts and a function-level direction. Store baselineCreated alongside totalOpenRoles, totalOpenRolesBaseline and totalOpenRolesDelta. Showing a first-check zero delta as flat hiring would imply a comparison that did not happen.

Function grouping is part of the installed method. Counts from an ATS and counts from a board sample should retain their source and slice labels. A change can reflect postings entering or leaving the observed source, collection timing, or changes in the underlying sample. It does not by itself prove changes in headcount, revenue or completed hiring.

Keep incomplete slices out of the baseline

An unavailable slice must remain a coverage gap. The installed contract exposes partial state, missingSlices and source counters, while other slices can still deliver. An incomplete slice does not advance its baseline. That behavior protects the next valid comparison from using a timeout or a truncated collection as its previous truth.

The same distinction belongs in your dashboard. A missing observation is not a zero. Leave a gap or attach an unavailable state rather than drawing an apparently measured collapse in open roles. If some slices succeeded, publish their bounded results with a visible partial-run label and route the failed slices for investigation.

Inspect storage and delivery before repeating

This Actor uses a named baseline in the buyer's account. The watch identifier is therefore operational state, not just a presentation label. Avoid simultaneous runs for the same logical watch, and inspect an uncertain run's Dataset and charge counters before repeating it. A local process timeout alone does not establish that platform work stopped.

For an integration acceptance check, inspect a first snapshot, a later comparable snapshot and an incomplete-slice outcome. Verify that the chart distinguishes baseline creation, a measured flat count and missing coverage. Keep source collection time beside import time. The resulting series can support a defensible observation about this hiring sample without claiming a complete labor-market census.

Price and verification scope

This article is pinned to public latest build 0.2.2 (420XlHjUglrFYhsCI) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Keep company attribution uncertainty beside a lead qualification score

Tim Zinin — Sun, 25 Oct 2026 08:41:46 +0000

A high lead score is difficult to interpret when one of its strongest signals belongs to another company. Domain-based research has this trap: a website is explicit, while an ATS token or issuer name may have been guessed from the hostname. The output needs to retain those different identity bases.

Lead List Qualifier combines contact, hiring, technology and funding-mention evidence into a transparent qualification row. The installed runtime embeds its source scanners. A score is useful for ordering research, but its contributions do not all carry the same attribution strength.

Begin with explicit domains

This is a shortened installed public example. It is a proposed bounded input, not evidence that these companies currently have any particular score or vacancy count. No source collection was performed for this article.

{
  "domains": [
    "stripe.com",
    "shopify.com"
  ],
  "role_keywords": [
    "sales",
    "marketing"
  ],
  "company_name_overrides": {}
}

For hiring and funding research, inspect how the company lookup was derived. A domain-derived slug is a guess. A buyer override records the identity you supplied, but the override itself does not independently verify ownership. Keep that provenance when exporting the result so an analyst can distinguish a convenient lookup parameter from a confirmed company link.

Separate source completion from positive findings

The output records whether each scanner completed. A completed source with no positive signal differs from a failed source that could not be checked. Store both the scanner status and its evidence summary. A score assembled from two available sources should not be compared with a four-source score as though coverage were identical.

Contact checking can also be inconclusive after a bounded website inspection. Retain that state rather than labeling the company unreachable. The installed decision layer reduces confidence when checks are missing or contact evidence is incomplete, and it exposes the corresponding gaps. Confidence here describes the support for this bounded qualification, not a probability that the company will buy.

Inspect identity-sensitive contributions

A confirmed hiring-board owner mismatch excludes that hiring signal from scoring. Unavailable ownership evidence stays unverified. Funding-name matches require additional care: a name substring in SEC evidence is not a domain-to-issuer link or proof of a completed financing round. Keep the match basis beside any points it contributes.

Useful fields include hotnessScore, signalContributions, identityConfidence, attributionConfirmed and the decision layer's data gaps. Inspect the structured contribution total rather than relying only on a summary sentence. If your database flattens the row, preserve the negative signals and reasons as structured arrays or a linked evidence record.

Route incomplete research deliberately

The installed decision layer sets safeToAutomate to false for these research actions. A strong score can prioritize manual review; it does not authorize outreach. A partial qualification belongs in a queue that names the missing evidence, while an all-source failure belongs with operations. A zero score after completed bounded checks is also different from a universal statement that the company is a bad fit.

Test your importer with a high-score partial row, a confirmed owner mismatch and a complete row with no positive signals. Verify that all three remain distinguishable after sorting and exporting. Review one apparent top lead against its actual source identity before widening the batch. The useful deliverable is a research order with reasons, not an automatic contact decision concealed inside a number.

Price and verification scope

This article is pinned to public latest build 0.3.1 (w7QBd1XTFztk1he8b) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

Deduplicate a company lead export without treating DNS as mailbox proof

Tim Zinin — Sun, 25 Oct 2026 06:17:44 +0000

A spreadsheet can contain five contacts for one company and still look like five independent prospects. Before enrichment, decide whether the unit you want is a company or an individual. That decision determines which duplicates should disappear and which should survive into a separate contact table.

Lead List Cleaner normalizes heterogeneous lead rows and can run deduplication, email checks, domain checks and scoring. Its company-oriented deduplication prefers the normalized domain; email is the fallback when a domain is absent. Two people at one domain can therefore collapse into one lead. Keep the original export when individual contact identity matters.

Start with a bounded normalization experiment

The JSON below is adapted from the installed public example. The duplicate Shopify observation is deliberate. Selecting only dedupe and score isolates that part of the workflow: it does not request email or domain checks. The company names and websites illustrate the input shape; they are not an assertion of current contact quality.

{
  "items": [
    {
      "title": "Shopify",
      "categoryName": "Software company",
      "website": "https://www.shopify.com",
      "phone": "+1 888-746-7439",
      "url": "https://www.google.com/maps/place/Shopify"
    },
    {
      "title": "Shopify Inc",
      "website": "https://shopify.com",
      "phone": "+1 888-746-7439"
    },
    {
      "title": "Stripe",
      "categoryName": "Payment processor",
      "website": "https://stripe.com",
      "phone": "+1 888-926-2289",
      "emails": [
        "support@stripe.com"
      ]
    }
  ],
  "checks": [
    "dedupe",
    "score"
  ],
  "minScore": 0,
  "maxRows": 10
}

Preserve the raw row identifier in your own staging table before processing. A company-level key is useful for avoiding repeated research, while your source record remains the place to inspect alternative names, phone numbers and conflicting contacts. Deduplication is not a legal-entity resolution service, and a shared domain is not proof that every source row describes the same business unit.

Store check state beside the score

When the email stage runs, syntax and MX evidence support a bounded address assessment. They do not prove that a particular mailbox exists or that its owner will accept a message. A live DNS response likewise does not prove that a business is trading, suitable for your offer, or safe to contact. Keep role-address and disposable-domain flags as review evidence.

Disabled checks must remain distinguishable from completed negative checks. Otherwise, a cheap normalization pass can accidentally become a spreadsheet full of supposedly verified contacts. Give the staging table separate columns for requested checks, returned statuses, rejection reasons and the original source reference. Do not replace an unavailable status with a convenient Boolean.

Apply a cutoff only to a score that was measured

The installed classifier rejects dead email or domain statuses and rows without either contact signal. A score cutoff applies when scoring actually ran. That distinction matters when you deliberately disable scoring: a default numeric value is not an observed poor lead. The score is a workflow heuristic rather than a prediction of purchase or response.

For a small regression fixture, include two rows with the same normalized domain, one email-only row and one row containing only a company name. Check which identity survives deduplication and why the contactless row is rejected. Then change the enabled stages and verify that unchecked evidence stays unchecked. This fixture can be synthetic; running useful synthetic input through the real platform route may still incur charges.

Make the import reversible

Write cleaned leads to a staging destination before merging them into a CRM. Count accepted, rejected and duplicate rows separately, and retain the rejection explanations. If a source export contained several addresses for one company, review that information before treating the surviving row as the preferred person. A clean company queue solves repeated research; choosing the right contact remains a separate decision.

Price and verification scope

This article is pinned to public latest build 0.3.1 (PHslDioacSvY6LxhN) at the recorded read time. Source, input and pricing were read from Apify; no new cloud build or run was started. The supplied example and any synthetic local checks do not establish current source facts, cloud delivery or customer outcomes.

Inspect the Actor's current contract and pricing.

AI-assisted writing. Source contracts and verification limits are documented above.

The installed contract gives the first 25 clean leads of each run no result-event charge; rejected and summary rows also request no result event. Preserve actual charged-event counters when reconciling a real run.

Benchmark Instagram posts within an explicit account and format cohort

Tim Zinin — Sun, 25 Oct 2026 03:53:43 +0000

A post can look exceptional when compared with the wrong baseline. Mixing several accounts or combining images with reels creates a number that is easy to calculate and hard to interpret. A useful benchmark defines the comparable cohort before it produces a percentile.

Instagram Campaign Performance Benchmark reads an existing post export. It compares each usable post within the same account and exact format, using the metrics that are actually available. The output keeps cohort size, metric basis and evidence beside its relative measures.

Start with a comparable historical sample

The example below selects three comparable records from the installed public historical snapshot. Their likes and comments are saved observations, not current counts. The small sample is useful for inspecting cohort behavior; it is not representative of the account's entire publishing history.

{
  "items": [
    {
      "id": "3991274049559765207",
      "type": "Image",
      "shortCode": "Ddj2pn1PqDX",
      "ownerUsername": "nasa",
      "likesCount": 171442,
      "commentsCount": 625,
      "timestamp": "2026-09-21T18:56:33.000Z"
    },
    {
      "id": "3988961919403244082",
      "type": "Image",
      "shortCode": "Ddbo7s0lzoy",
      "ownerUsername": "nasa",
      "likesCount": 401824,
      "commentsCount": 1187,
      "timestamp": "2026-09-18T14:22:23.000Z"
    },
    {
      "id": "3986255392669277466",
      "type": "Image",
      "shortCode": "DdSBijYCZ0a",
      "ownerUsername": "nasa",
      "likesCount": 448527,
      "commentsCount": 1091,
      "timestamp": "2026-09-14T20:45:06.000Z"
    }
  ],
  "maxInputRows": 100,
  "maxResults": 10
}

Keep ownerUsername, type and stable post identity. The transformation normalizes account-name casing and uses the source's exact format value. An Image, Sidecar and video format should not become one cohort merely because they appeared in the same export file.

Preserve the metric basis

The strongest supported basis combines known likes and comments. When only one metric can be used, the result discloses likes_only or comments_only and marks the output partial. A missing or hidden count should not be converted into zero to create an apparently complete engagement total.

The installed contract requires at least three comparable posts for a computable benchmark. A smaller cohort becomes a diagnostic. Keep that outcome visible so a dashboard does not silently omit a new format and make the remaining output look like complete campaign coverage.

Read percentiles together with the cohort size

The percentile uses a tie-safe middle rank. An all-tied cohort reads fifty, which expresses a common position rather than inventing a weakest post. Preserve comparableCohortSize whenever a percentile is shown, especially when a user compares small and large exports.

Relative indices compare a post's value with its cohort median. They describe the observed sample and basis. A combined relative index is not an engagement rate against followers, and it cannot establish reach, conversions or paid campaign return. Keep the source counts available for a reviewer who needs to understand an unusual ratio.

Resolve duplicate identity before interpreting performance

Rows connected by supported ID or short-code aliases are consolidated into a post entity. Conflicting duplicate metric evidence can make a post unsuitable for the benchmark. Preserve diagnostics rather than selecting the more flattering observation.

When refreshing the workflow, keep accepted snapshots and compare equivalent cohorts. A different mix of formats or a changed historical window can alter the median without any new post receiving another interaction. Record the source batch and observation context with the output.

For the human handoff, export the action label, basis, cohort size and evidence. Ask the campaign analyst to inspect creative context and the business result in its own systems. The transformation supplies an explainable relative comparison from saved public counts. It does not infer audience quality, detect fraud, collect commenter identities or establish that a campaign achieved its commercial goal.

Price and verification scope

Listing pricing read on 23 October 2026 is $0.012 per result-found event on the FREE tier. The documented unit is: One useful post benchmark delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.

This article uses the installed source contract from build 0.1.3 (WtEKJ35s0lsBcBtK2). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.

Inspect the Actor's current input and pricing.

AI-assisted draft; independent technical and cover review is required before publication.

Audit an Amazon product batch with marketplace-aware identity

Tim Zinin — Sun, 25 Oct 2026 01:29:41 +0000

An ASIN is useful identity evidence, but it does not by itself identify a marketplace offer. A product batch can contain the same ASIN from different national sites, ambiguous currency symbols and conflicting duplicate observations. Importing those rows under one bare key can overwrite valid differences or hide a source problem.

Amazon Catalog Variation Quality Auditor reads an existing product export and creates an assessment for each ASIN and observed marketplace scope. It preserves missing-value states, checks duplicate consistency and inspects supported variation references before a catalog import accepts the data.

Start with an observed marketplace URL

The example retains a shortened projection of the installed public historical snapshot. Price, stock and review values belong to that saved observation. The attributes list is deliberately shortened for illustration, so this example should not be presented as an exhaustive product specification.

{
  "items": [
    {
      "asin": "B0FC5SJNQX",
      "url": "https://www.amazon.com/dp/B0FC5SJNQX",
      "title": "Logitech MX Master 4 Ergonomic Wireless Mouse with Haptics - Graphite",
      "price": {
        "value": 119.99,
        "currency": "$"
      },
      "inStock": true,
      "brand": "Logitech",
      "attributes": [
        {
          "key": "Connectivity Technology",
          "value": "Bluetooth, Radio Frequency, USB"
        }
      ],
      "stars": 4.3,
      "reviewsCount": 2019,
      "breadCrumbs": "Electronics > Computers & Accessories > Computer Accessories & Peripherals > Keyboards, Mice & Accessories > Mice"
    }
  ],
  "maxInputRows": 100,
  "maxResults": 10
}

A verified product URL must reference the same ASIN on a supported marketplace host. The generated convenience URL used when evidence is missing does not establish where the source observed the offer. Keep canonicalUrlSource and marketScope beside the exported link.

Preserve price states

The assessment distinguishes a missing price field, an observed absent value, a literal zero, a usable price and an unparseable value. Those states support different import decisions. Replacing all of them with zero would manufacture a free offer from an export error.

Currency also needs evidence. A bare dollar symbol can be ambiguous. The output preserves the symbol while resolving an ISO currency only when the supported source evidence allows it. Keep the raw source projection and the assessment together rather than assuming that every symbol has the same monetary meaning.

Review duplicate conflicts before choosing a winner

Two rows sharing an ASIN and marketplace can disagree about price, stock or other catalog fields. A deterministic import should expose that conflict and send it to a review rule. Choosing whichever row happened to arrive last hides the reason a downstream price changed.

Preserve duplicateSourceRowCount and evidence indices. If the export contains different observation times, the receiving system can apply a separately documented freshness policy. The audit itself should not be described as a new source check merely because it processes a recent upload of old rows.

Treat variation coverage as its own claim

An absent variants field does not prove the product has no variations. The contract can qualify an otherwise complete assessment when variation scope was never captured. Parent references, malformed variation identities and duplicate entries also need their own inspection.

The currently selected ASIN appearing in its own variation list can be normal scraper output. A useful gate distinguishes that informational case from an actual hierarchy problem instead of rejecting every self-reference indiscriminately.

Stage assessments before replacing an accepted catalog. Require the states your application needs for monetary display, stock handling and variation navigation. Keep diagnostics for invalid rows and source coverage limits. The resulting import is easier to explain because its acceptance decision depends on explicit field and scope evidence, with a clear route for records that need another authorized collection or a human review.

Price and verification scope

Listing pricing read on 23 October 2026 is $0.015 per result-found event on the FREE tier. The documented unit is: One useful catalog assessment delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.

This article uses the installed source contract from build 0.1.2 (t1y4GVwth4cSw2MAZ). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.

Inspect the Actor's current input and pricing.

AI-assisted draft; independent technical and cover review is required before publication.