EU Accessibility & Privacy Website Signal Scanner
Pricing
from $42.50 / 1,000 result founds
EU Accessibility & Privacy Website Signal Scanner
Scan submitted public pages for deterministic accessibility and privacy HTML indicators, weighted gaps, confidence, evidence, and audit actions—without compliance verdicts.
Pricing
from $42.50 / 1,000 result founds
Rating
0.0
(0)
Developer
Tim Zinin
Maintained by CommunityActor stats
0
Bookmarked
1
Total users
0
Monthly active users
8 days ago
Last modified
Categories
Share
EU Accessibility Privacy Lead Scanner
Point this Actor at a list of submitted URLs and it returns a deterministic, robots-aware report of accessibility and privacy exposure signals that are visible in the page HTML. It is designed for repeatable lead research with bounded network work, strict output counters, and replay-safe result delivery for automation teams.

What it does
- Reads only the URLs you submit.
- Fetches
robots.txtfirst, then the page itself. - Checks a fixed signal set for image alt usage, control names, document language, keyboard semantics, privacy notice links, tracker-before-choice, consent choice, and personal-data form notices.
- Emits only useful Dataset rows with
result-foundbilling. - Stores the compact run envelope in the default Key-Value Store key
OUTPUT. - Never uses an LLM, browser, proxy, login, side effect, or legal verdict.
Features
Robots rules are checked before the submitted path and every same-host redirect target. Public-address SSRF protection, a real connection timeout, terminal request state, and a 16 KiB compact envelope keep the result deterministic and suitable for API clients.
Input
{"schemaVersion": "1.0","requestId": "demo-ai-001","urls": ["https://www.intercom.com", "https://www.w3.org"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "compact"}
How to run
Submit the JSON input in the Apify Console or call the API endpoint shown below. Start with
one or two URLs, choose compact for normal use, and use evidence when excerpts are useful.
Each requestId is idempotent: a completed request is replayed without another paid result.
Output
Useful Dataset rows contain the observed signals, accessibilityGapScore,
privacyGapScore, combinedExposureScore, leadTier, isLead, needsReview, and
source evidence hashes. The compact OUTPUT envelope in the default Key-Value Store
keeps the summary, counts, warnings, and status.
Real Dataset row
Selected fields below come from production canary run CMl4TLSDTKRmCBJNm, observed on 9 August 2026. A zero gap means that this bounded HTML signal set did not establish a gap on that page; it is not a WCAG, EN 301 549, GDPR, or ePrivacy compliance conclusion. The current additive contract also emits freshness.cacheReused so consumers can distinguish a new fetch from a compatible cached report.
{"schemaVersion": "1.0","requestId": "ryan20-access-privacy-intercom-20260809-2025","actor": "eu-accessibility-privacy-lead-scanner","sourceUrl": "https://www.intercom.com/","canonicalUrl": "https://www.intercom.com/","observedAt": "2026-08-09T16:25:41.858Z","accessibilityGapScore": 0,"privacyGapScore": 0,"combinedExposureScore": 0,"leadTier": "none","confidenceScore": 80,"confidenceBand": "medium","dataGaps": ["LEGAL_APPLICABILITY_NOT_DETERMINED","CONFORMANCE_TEST_NOT_PERFORMED","BUYER_INTENT_NOT_OBSERVED"],"recommendedAction": "MONITOR_OR_ARCHIVE","safeToAutomate": false}
Errors use a fixed enum such as ROBOTS_DENIED, SOURCE_TIMEOUT, or DELIVERY_CHARGE_UNKNOWN.
Pricing
apify-actor-start: tiered from $0.004 to $0.005result-found: tiered from $0.04 to $0.05
Only useful rows create result-found charges. Garbage, robots denial, SSRF blocks,
source outages, and invalid input do not create result charges, although the platform may
charge the automatic start event. Internally, the SDK delivery receipt also includes a
zero-price default-Dataset-item event; that bookkeeping entry is not a second paid result.
Request replay and cached report reuse are handled through the persistent named actor cache.
The live Store pricing panel is authoritative for the buyer's current tier.
Limits
- 1..100 URLs per run
- Same-host fetch only
- 3 redirects maximum
- 5 second connect timeout, 15 second attempt timeout, 25 second per-URL work unit
- 2 MiB decoded page body limit
- 50 MiB aggregate decoded response limit and 150 second hard stop
- 16 KiB maximum for the compact
OUTPUTrecord
Source notes
This Actor does not infer WCAG, EN 301 549, GDPR, ePrivacy, compliance, sanctions, or liability. It only reports observed exposure indicators in the submitted page HTML.
Support and limitations
This is a BYOD scanner, so the submitted page must be publicly reachable over HTTP(S) and
must allow the requested path in robots.txt. Report a reproducible bug with the input,
request ID, and OUTPUT error code; do not include secrets or private page content.
API example
curl https://api.apify.com/v2/acts/zinin~eu-accessibility-privacy-lead-scanner/runs \-X POST \-H "Content-Type: application/json" \-d '{"schemaVersion": "1.0","requestId": "demo-ai-001","urls": ["https://www.intercom.com"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "evidence"}'
Related tools
Related tools for adjacent workflows in operational gap-lead generation.
| Actor | What it does |
|---|---|
| EU AI Act Transparency Lead Scanner | Pair it in the operational gap-lead generation workflow: BYOD compliance scanner for observed AI transparency signals on a submitted URL. Deterministic,... |
| Clinic Reception Gap Lead Finder | Pair it in the operational gap-lead generation workflow: Analyze submitted clinic websites for reception-channel gaps with exact BYOD crawling and no discovery |
| Restaurant Booking Gap Lead Finder | Pair it in the operational gap-lead generation workflow: Analyze submitted restaurant websites for booking-channel gaps with exact BYOD crawling and no discovery |
| New Opening Permit Lead Radar | Pair it in the operational gap-lead generation workflow: Detect commercial permit and license openings from five fixed Socrata datasets and return evidence-backed... |
Commercial guide: EU Accessibility and Privacy Website Signal Scanner
Scan buyer-supplied public pages for deterministic accessibility and privacy exposure indicators, weighted gap scores, evidence coverage, confidence, and legal-review-first lead routing.
This guide is written for buyers, operators, analysts, and automation builders. It explains what the Actor observes, how to turn the Dataset into a controlled workflow, and where human verification remains mandatory.
The decision this product supports
Which submitted pages show observable HTML accessibility or privacy control gaps worth manual audit, without claiming WCAG, EN 301 549, GDPR, ePrivacy, or legal noncompliance?
The Actor reduces collection and first-pass triage work. It does not remove responsibility for source verification or authorize an external business action. The commercial value comes from a structured, repeatable evidence layer: stable identity, observation time, source evidence, confidence, gaps, recommended action, and failure semantics travel with the raw facts.
Who uses it
| User | Value |
|---|---|
| Accessibility agencies | Build a page-level audit queue from approved URLs with exact selectors and bounded evidence. |
| Privacy consultancies | Identify visible privacy-link, tracker, consent-choice, and form-notice topics for human review. |
| Web studios | Turn deterministic implementation observations into evidence-based remediation discussions. |
| Small-business marketers | Audit owned sites or approved prospects without relying on opaque compliance labels. |
| Compliance operations | Use page evidence as intake triage while keeping conformance testing and legal conclusions separate. |
| Automation builders | Route useful rows by score, confidence, gaps, and explicit safeToAutomate=false. |
Input contract
| Input field | How to use it |
|---|---|
| schemaVersion | Required request-contract version. Use the documented 1.0 contract. |
| requestId | Required correlation and idempotency key for the exact semantic request. |
| urls | One to 100 buyer-submitted absolute public HTTP(S) pages. No discovery or link crawling is performed. |
| maxResults | Maximum useful rows delivered and billed after successful Dataset write. |
| freshnessMinutes | Maximum preserved page-observation age for compatible cached useful-report reuse; 0 forces a new fetch. Returned rows expose freshness.ageSeconds and freshness.cacheReused. |
| detailLevel | compact summaries or evidence-rich selectors and bounded excerpts. |
Recommended first Input
{"schemaVersion": "1.0","requestId": "accessibility-privacy-demo-001","urls": ["https://www.intercom.com","https://www.w3.org"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "evidence"}
Start with this bounded example, inspect every Dataset field, and only then expand the scope. Input limits are product controls, not inconveniences: they make cost, completeness, and error handling visible.

Field dictionary
| Field or group | Meaning |
|---|---|
| entityId, dedupeKey, inputRef, sourceUrl, canonicalUrl | Stable website/request identity and bounded source references. |
| signals.image_alt, control_name, document_lang, keyboard_semantics | Deterministic page-level accessibility indicators. |
| signals.privacy_notice_link, tracker_before_choice, consent_choice, personal_form_notice | Deterministic visible privacy and consent indicators. |
| accessibilityGapScore, privacyGapScore, combinedExposureScore | Weighted observed-gap measures, not conformance or legal-risk scores. |
| leadTier, isLead, needsReview | Research triage labels based on the bounded score and unknown evidence. |
| sourceMetrics, evidence, signalSetVersion | Collection coverage, bounded source evidence, and rule-set identity. |
| observedAt, firstSeenAt, lastSeenAt, freshness | Page observation timing, measured age, and whether a compatible report cache was reused. |
| confidenceScore, confidenceBand, confidenceReasons | Evidence support derived from known weighted signals and collection coverage. |
| sourceEvidence, dataGaps | Signal evidence hashes/counts and explicit legal, conformance, unknown-signal, and intent gaps. |
| recommendedAction, actionPriority, safeToAutomate, failureType, retryable | Manual validation routing and operational semantics. |
Common decision fields
| Field | Operational meaning |
|---|---|
| recordType | The semantic row family. Use it to distinguish a business result from an advisory or terminal record. |
| schemaVersion | Version of the additive decision-intelligence contract. Pin or validate it in strict consumers. |
| entityId | Stable entity identity for deduplication and joins. It is not necessarily a legal identifier. |
| inputRef | The relevant submitted input reference after normalization. |
| observedAt | When the Actor observed or finalized the evidence. It is not necessarily the source publication time. |
| firstSeenAt and lastSeenAt | Always-emitted observation boundaries. Stateful monitors use the compatible baseline/current boundary. Stateless rows set both equal to observedAt for the current run; that equality does not establish historical tenure. |
| freshness | Page-fetch evidence age. basis=page_fetched_at; ageSeconds is measured from the preserved observation timestamp, and cacheReused distinguishes a compatible cached report from a new fetch. This is not a compliance-freshness guarantee. |
| eventId | For monitors, the stable identity of one observed transition or monitor outcome. It is distinct from entityId. |
| before and after | For monitors, the bounded comparable snapshots used for the decision. Null means that side of a comparison was not honestly available. |
| changedFields and changeFlags | Machine-readable monitor deltas and normalized change labels. Empty arrays mean no supported changed field was established, not that every possible real-world fact stayed constant. |
| materialityScore and materialityBand | Magnitude of an observed monitor change when the Actor can calculate it. Materiality is separate from evidence confidence and may be unknown when the source lacks the required facts. |
| confidenceScore | Evidence support on a 0–100 scale. It is separate from materiality, lead score, or business value. |
| confidenceBand | Readable high/medium/low/unknown grouping of evidence support. |
| confidenceReasons | Observed facts that raise confidence. |
| confidenceRisks | Missing, partial, ambiguous, inferred, or conflicting aspects that reduce confidence. |
| confidenceConflict | Explicit consistency warning when structured evidence does not reconcile. |
| sourceEvidence | Source-linked observations supporting the row. Preserve this during export. |
| dataGaps | Important evidence the Actor did not observe or cannot establish. Keep these gaps visible in CRM, spreadsheet, and automation exports. |
| negativeSignals | Machine-readable risks or gaps. A negative signal is not automatically a negative business outcome. |
| recommendedAction | Bounded review label produced from the available evidence. |
| actionPriority | Suggested queue priority, not urgency guaranteed by the source. |
| actionReason | Plain-language explanation for the recommended action. |
| safeToAutomate | Whether the narrow recommended action is deterministic enough for automation. Organizational policy still applies. |
| failureType | Normalized terminal or partial failure classification. Null means no classified failure. |
| retryable | Whether a later retry may legitimately change an operationally incomplete result. |
| recommendation | Human-readable handling guidance, especially for terminal rows. |
Evidence, confidence, and honest boundaries
What the evidence supports
- The Actor fetches robots.txt first, then only each submitted page through same-host and public-address controls.
- Accessibility indicators cover eligible image alt use, accessible control names, document language, and a bounded keyboard-semantics heuristic.
- Privacy indicators cover visible policy links, recognized tracker hosts in HTML, consent choice when a tracker is observed, and notices near personal-data forms.
- not_applicable and unknown signals are excluded from the weighted gap denominator instead of being silently treated as failures.
- A useful row requires sufficient applicable signal weight and source coverage under the fixed rule set.
What this Actor never claims
- The Actor does not establish WCAG, EN 301 549, European Accessibility Act, GDPR, ePrivacy, or any other legal or technical conformance.
- It does not run a browser, execute JavaScript, test keyboard navigation, screen readers, visual contrast, focus behavior, or complete user journeys.
- A tracker token in page HTML does not prove that tracking executed, consent was invalid, personal data was processed, or a violation occurred.
- A missing notice on one page does not prove the organization lacks a policy or control elsewhere.
- It does not prove jurisdiction, commercial need, budget, buyer intent, damages, enforcement risk, or decision-maker identity.
Reading data gaps correctly
A data gap is part of the result. Nulls, partial flags, confidence risks, source failures, and unavailable fields must survive export. Removing these fields makes the remaining facts look more complete than they are. When two sources conflict or a required identity cannot be proven, lower confidence and keep safeToAutomate=false.
Source evidence is not permission
A public source proves only that a value or statement was observable at the recorded time and URL. It does not establish consent, contractual rights, legal status, accuracy after observation, or authorization for a downstream action. Your organization remains responsible for source terms, privacy rules, outreach policy, retention, and human review.
Decision policy and action routing
| Action | How to use it |
|---|---|
| REVIEW_ACCESSIBILITY_PRIVACY_GAPS | Validate failed indicators with appropriate browser, accessibility, privacy, legal, and organizational review before remediation or outreach. |
| MONITOR_OR_ARCHIVE | Keep the bounded observation without labeling the page compliant or irrelevant. |
| RETRY_SOURCE_CHECK | Retry only a temporary robots, DNS, timeout, source, or delivery failure. |
Confidence is not attractiveness
confidenceScore answers “how strongly does the available evidence support this factual classification?” It does not answer “how valuable is this lead, property, account, or address?” A high-confidence negative fact may be commercially uninteresting; a low-confidence positive signal may deserve research but not action. Keep the concepts separate in dashboards, exports, and CRM fields.
Why safeToAutomate is conservative
safeToAutomate is intentionally false whenever the next step could amplify an uncertain inference. It may be true only for narrow deterministic actions explicitly supported by the row, such as suppressing an email with invalid syntax. A true value does not waive legal, privacy, consent, contractual, or organizational rules.
Retry policy
- Retry when
retryable=trueand the failure is operational, such as a temporary source or DNS problem. - Do not endlessly retry deterministic invalid input, policy refusal, or confirmed absence.
- A retry must preserve the original input reference and must not create duplicate downstream actions.
- Budget exhaustion is not negative evidence about the entity. Resume only the unprocessed scope with an authorized budget.
- A failed Actor run is an operational event. Never transform it into “no listing,” “no contact,” “bad lead,” or “invalid email.”
Commercial use-case playbooks
1. Agency prospect audit
Goal. Scan an approved URL list, inspect high-confidence evidence, and prepare a human-reviewed technical audit without legal claims.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
2. Owned-site release check
Goal. Run on landing pages after deployment and route failed implementation indicators to qualified teams.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
3. Image and control audit
Goal. Use selectors as a first-pass queue, then verify semantics and user impact in a real browser and accessibility test.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
4. Privacy notice review
Goal. Inspect visible links and personal-form notices while checking the broader data flow and policy manually.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
5. Consent implementation triage
Goal. Treat tracker/choice observations as HTML clues and verify runtime behavior through a proper consent audit.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
6. Agency client report
Goal. Deliver exact page scope, rule version, scores, confidence, evidence, gaps, and explicit non-conformance boundaries.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
7. CRM staging
Goal. Store tier as an audit-priority field, not a compliance label, and block automatic external action.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
8. Quality exception lane
Goal. Separate robots denials, unknown/not-applicable signals, insufficient coverage, and source failures from useful lead rows.
Recommended runbook.
- Define the submitted cohort and write down why it is in scope.
- Start with the smallest useful Input and preserve the exact run ID.
- Inspect the Dataset overview before exporting anything.
- Check
failureType,retryable, completeness indicators, andconfidenceBand. - Open the relevant
sourceEvidenceor source URL for material rows. - Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
- Record the analyst's final disposition in the destination system.
Do not skip. A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
Integration recipes
All examples use placeholders. Keep the Apify token in a secret manager and never write it into a Dataset, README, screenshot, or client-side application.
cURL: start a run and wait briefly
curl -sS -X POST 'https://api.apify.com/v2/acts/zinin~eu-accessibility-privacy-lead-scanner/runs?waitForFinish=60' \-H "Authorization: Bearer $APIFY_TOKEN" \-H 'Content-Type: application/json' \--data '{"schemaVersion":"1.0","requestId":"accessibility-privacy-demo-001","urls":["https://www.intercom.com","https://www.w3.org"],"maxResults":10,"freshnessMinutes":60,"detailLevel":"evidence"}'
The run response includes defaultDatasetId. Read clean JSON rows with:
curl -sS "https://api.apify.com/v2/datasets/$DEFAULT_DATASET_ID/items?clean=true&format=json" \-H "Authorization: Bearer $APIFY_TOKEN"
JavaScript with apify-client
import { ApifyClient } from 'apify-client';const client = new ApifyClient({ token: process.env.APIFY_TOKEN });const input = {"schemaVersion": "1.0","requestId": "accessibility-privacy-demo-001","urls": ["https://www.intercom.com","https://www.w3.org"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "evidence"};const run = await client.actor('zinin/eu-accessibility-privacy-lead-scanner').call(input);const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });for (const row of items) {console.log({entityId: row.entityId,confidenceBand: row.confidenceBand,recommendedAction: row.recommendedAction,safeToAutomate: row.safeToAutomate,failureType: row.failureType,});}
Python with apify-client
import osfrom apify_client import ApifyClientclient = ApifyClient(os.environ["APIFY_TOKEN"])run = client.actor("zinin/eu-accessibility-privacy-lead-scanner").call(run_input={"schemaVersion": "1.0","requestId": "accessibility-privacy-demo-001","urls": ["https://www.intercom.com","https://www.w3.org"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "evidence"})for row in client.dataset(run["defaultDatasetId"]).iterate_items(clean=True):print({"entityId": row.get("entityId"),"confidenceBand": row.get("confidenceBand"),"recommendedAction": row.get("recommendedAction"),"safeToAutomate": row.get("safeToAutomate"),"failureType": row.get("failureType"),})
Apify MCP call
{"name": "call-actor","arguments": {"actor": "zinin/eu-accessibility-privacy-lead-scanner","input": {"schemaVersion": "1.0","requestId": "accessibility-privacy-demo-001","urls": ["https://www.intercom.com","https://www.w3.org"],"maxResults": 10,"freshnessMinutes": 60,"detailLevel": "evidence"}}}
Generic webhook consumer policy
- Trigger on a terminal Actor run event.
- Confirm the run status is
SUCCEEDEDbefore reading business rows. - Retrieve rows from
defaultDatasetId. - Reject or quarantine rows whose
failureTypeis non-null unless your policy explicitly handles that failure. - Send
safeToAutomate=falserows to a human-review queue. - Store
entityId,observedAt,sourceEvidence, confidence, action, and the Apify run ID together. - Make retries idempotent by keying the destination on the stable entity ID plus the intended observation or event identity.
Where this fits in a practical stack
| Destination | Recommended pattern |
|---|---|
| Apify Console | Use the visual Input form, start the run, then open the default Dataset overview. This is the fastest path for a one-off review and the best place to inspect evidence before automating anything. |
| Apify API | POST JSON input to the Actor run endpoint, wait or poll for completion, then read the default Dataset through the URL returned by the run object. |
| JavaScript client | Use apify-client from a Node.js service, pass the same JSON object as the Console Input, and preserve the returned run and Dataset IDs in your own audit log. |
| Python client | Use apify-client in a Python enrichment job, iterate Dataset items, and route rows by recommendedAction, confidenceBand, failureType, and retryable. |
| Make | Start the Actor from a scenario, wait for the run, retrieve Dataset items, filter unsafe or low-confidence rows, then insert review-ready rows into the destination application. |
| Zapier | Use an Apify run action or webhook trigger, fetch Dataset items, apply a Filter step, and send only review-approved fields into the next sales or operations step. |
| n8n | Use HTTP Request or Apify nodes, branch on failureType and retryable, keep a manual-review lane for safeToAutomate=false, and write sourceEvidence together with the business fields. |
| Google Sheets | Export the Dataset directly or append rows from an automation. Keep stable entityId as a hidden key so reruns update the correct record instead of creating ambiguous duplicates. |
| Airtable | Map entityId to a primary or deduplication field, store confidence and evidence in separate columns, and expose recommendedAction as the triage view. |
| Webhook | Configure an Apify webhook for terminal run states, retrieve the Dataset after SUCCEEDED, and treat FAILED or TIMED-OUT runs as operational events rather than negative business evidence. |
A safe automation shape
The Actor is a collection and decision-support component. A production workflow should keep raw evidence, decision metadata, and business action in distinct layers:
- Collect: run the Actor with explicit bounded input.
- Validate: require a successful run and schema-valid Dataset rows.
- Triage: branch on
failureType,retryable,confidenceBand, andsafeToAutomate. - Review: open source evidence for rows that may affect a person, campaign, investment, compliance decision, or customer record.
- Act: execute only the action approved by your own policy and authorized operator.
- Audit: retain run ID, Dataset ID, observation time, input reference, source evidence, and the final human decision.
This separation prevents a common automation error: turning “data was observed” into “a business action is justified.”
Operating guide
Before the first production run
- Write the business question in one sentence: Which submitted pages show observable HTML accessibility or privacy control gaps worth manual audit, without claiming WCAG, EN 301 549, GDPR, ePrivacy, or legal noncompliance?
- Confirm every submitted input is within your authorized scope.
- Use the prefilled small example and review all returned row types.
- Map stable identifiers, confidence, evidence, actions, gaps, failure, and retry fields into the destination.
- Establish a human owner for review exceptions.
- Set a run budget and output bound appropriate to the test.
- Verify that secrets are stored only in the platform or workflow secret manager.
After every scheduled run
- Check terminal run status and logs.
- Compare the number of submitted entities, produced business rows, and advisory rows.
- Review partial, unknown, conflict, and low-confidence buckets.
- Inspect a sample of source evidence, including at least one positive and one negative result.
- Confirm the destination deduplicated on the intended stable key.
- Verify that no downstream action was triggered from an error row.
- Track cost per useful reviewed row rather than cost per raw request alone.
Production monitoring signals
Monitor source-unavailable rate, partial-row rate, low-confidence share, missing evidence, retry volume, run duration, Dataset row count, and spend. A sudden shift may indicate source drift, input drift, or an upstream outage. Stop automation and investigate before accepting a new pattern as business truth.
Cost control
Start with one owned page and one control page, maxResults=2, and evidence mode. Validate each selector manually and confirm useful-result billing before scaling an approved list.
Use maxTotalChargeUsd when calling a monetized Actor if your workflow supports it. Treat a buyer-set cap as a hard safety boundary. If the cap stops work, the unfinished items remain unprocessed; they do not become negative results.
Review templates and quality reporting
Row-review worksheet
For every material row, an analyst should be able to answer the following without relying on memory or an unstated assumption:
- What submitted entity or query does this row refer to?
- Is it a business result, a baseline/advisory row, a partial observation, or a failure?
- Which exact source evidence supports the headline fact?
- When was the evidence observed, and is there a different source publication time?
- Which fields are direct observations, which are normalized, and which are deterministic derivations?
- What important evidence is null, missing, partial, ambiguous, or conflicting?
- Does confidence describe evidence support only, or has someone incorrectly treated it as business value?
- What recommended action is present, and what additional verification does its reason require?
- Is the narrow action marked safe to automate? If yes, does organizational policy also permit it?
- What final human disposition was made, by whom, and from which run and Dataset item?
Field-group review prompts
1. entityId, dedupeKey, inputRef, sourceUrl, canonicalUrl
Contract meaning: Stable website/request identity and bounded source references.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
2. signals.image_alt, control_name, document_lang, keyboard_semantics
Contract meaning: Deterministic page-level accessibility indicators.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
3. signals.privacy_notice_link, tracker_before_choice, consent_choice, personal_form_notice
Contract meaning: Deterministic visible privacy and consent indicators.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
4. accessibilityGapScore, privacyGapScore, combinedExposureScore
Contract meaning: Weighted observed-gap measures, not conformance or legal-risk scores.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
5. leadTier, isLead, needsReview
Contract meaning: Research triage labels based on the bounded score and unknown evidence.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
6. sourceMetrics, evidence, signalSetVersion
Contract meaning: Collection coverage, bounded source evidence, and rule-set identity.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
7. observedAt, firstSeenAt, lastSeenAt, freshness
Contract meaning: Page observation timing.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
8. confidenceScore, confidenceBand, confidenceReasons
Contract meaning: Evidence support derived from known weighted signals and collection coverage.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
9. sourceEvidence, dataGaps
Contract meaning: Signal evidence hashes/counts and explicit legal, conformance, unknown-signal, and intent gaps.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
10. recommendedAction, actionPriority, safeToAutomate, failureType, retryable
Contract meaning: Manual validation routing and operational semantics.
Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?
Weekly quality report
Create a recurring internal report with these measures. The report is about pipeline health, not market demand unless the source contract explicitly measures demand.
| Metric | Why it matters | Investigate when |
|---|---|---|
| Submitted inputs | Defines the actual denominator and scope of the run. | The count differs from the approved batch or schedule. |
| Business result rows | Shows how many usable observations were produced. | The rate changes sharply without an input explanation. |
| Advisory/failure rows | Prevents operational failures from disappearing in a results-only dashboard. | Any terminal class grows or is unmapped. |
| Partial-result rate | Measures incomplete source coverage or configured truncation. | It rises, or analysts stop seeing the partial warning. |
| Low-confidence rate | Shows the share of rows requiring more evidence. | It rises by source, cohort, or input pattern. |
| Retryable failure rate | Distinguishes temporary operational issues from deterministic outcomes. | Retries repeat without improving evidence. |
| Evidence-link coverage | Confirms material facts remain traceable after export. | Links or evidence objects are missing from delivered records. |
| Safe-automation share | Shows how little or much of the workflow can be deterministic. | A mapping change makes unsafe actions appear safe. |
| Manual-review backlog | Measures whether human verification capacity matches collection volume. | Rows age beyond the campaign or decision window. |
| Duplicate destination writes | Tests idempotency and stable identity mapping. | The same entity/run creates multiple external actions. |
| Cost per reviewed useful row | Relates platform spend to approved, decision-useful output. | Raw volume rises but reviewed utility falls. |
| Source-drift exceptions | Detects changed markup, response shape, policy, or source availability. | A new unknown pattern survives more than one bounded check. |
Client-facing delivery note template
Use a note like this when delivering exports to a client or another team:
This Dataset contains bounded public-source observations produced by the Apify Actor for the submitted Input. Each row includes observation time, evidence confidence, recommended review action, and explicit gaps where available. A positive row is not proof of buyer intent, permission, legal status, future outcome, or any fact listed in the Actor's “never claims” section. Partial and failure rows are included so coverage is not overstated. Validate material rows at their source before acting.
Add the Actor URL, run URL, Dataset URL, build/version, exact Input scope, observation window, pricing model observed for the run, reviewer name, and date of approval.
CRM disposition vocabulary
Keep collection results and sales dispositions separate. A practical downstream vocabulary is:
needs_evidence_review: useful signal exists but a reviewer has not approved it.needs_identity_review: entity or ownership association is not sufficiently proven.needs_policy_review: contact, privacy, suppression, legal, or contractual policy must be checked.approved_for_research: an analyst may perform more research; this is not approval for outreach.approved_for_authorized_action: a named operator approved one specific action under the organization's policy.retry_operational_failure: the source or infrastructure failed and a bounded retry is appropriate.closed_no_supported_signal: the completed bounded check found no supported signal; this is not a universal negative fact.closed_out_of_scope: the input should not have entered this workflow.
Never overwrite recommendedAction with the CRM disposition. The first is Actor-produced decision support; the second is your organization's accountable decision.
Sampling plan
For a new workflow, review every row in the first small run. When the contract is understood, sample all failure and partial rows plus a representative set of high-, medium-, and low-confidence results. Re-expand to full review whenever the source changes, the schema version changes, a new input cohort is introduced, the error distribution shifts, or a downstream user reports an unexplained result.
Change-management record
When you change field mappings or automation policy, record:
- Previous mapping or rule.
- New mapping or rule.
- Actor build/version and schemaVersion used for validation.
- Test run and Dataset URLs.
- Positive, negative, partial, retry, and budget fixtures inspected.
- Security and privacy review outcome.
- Approver and activation time.
- Rollback condition and responsible operator.
This makes a commercial data workflow supportable. Without the record, a later operator cannot distinguish a real source change from an undocumented mapping change.
Delivery patterns for marketing and small-business teams
One-off research
Run the Actor in Console, inspect the overview table, open evidence for each material row, and export only the approved subset. Record the run URL in the client or campaign notes.
Recurring watch or hygiene job
Use an Apify schedule. Write rows into a staging table keyed by entityId. Compare current and previous observations only when the Actor supplies valid state or your own pipeline implements an explicit comparable baseline. Never infer a change from a failed run.
Agency client delivery
Deliver three views: business results, evidence/quality exceptions, and operational failures. Include the run URL, observation time, configured scope, and a plain-language statement of what the Actor does not prove. This makes the deliverable auditable and reduces disputes caused by overclaiming.
CRM enrichment
Write into staging fields first. A human or approved policy promotes values into canonical CRM fields. Keep raw source values separate from normalized and decision fields, and do not replace a verified value with a lower-confidence observation.
AI-assisted review
An LLM can summarize rows, but it must receive the evidence, confidence risks, negative signals, and limitations. Require citations to sourceEvidence and prohibit invented identity, intent, legal, funding, mailbox, valuation, or availability facts.
Buyer and operator acceptance checklist
Use this checklist before calling the workflow production-ready.
Product fit
- The business question matches: Which submitted pages show observable HTML accessibility or privacy control gaps worth manual audit, without claiming WCAG, EN 301 549, GDPR, ePrivacy, or legal noncompliance?
- The submitted entities were selected through an authorized process.
- A human owner understands the positive, negative, partial, and failure row types.
- The team accepts the boundaries listed in “What this Actor never claims.”
- The destination keeps evidence confidence separate from business scoring.
Input and run controls
-
schemaVersionis explicitly reviewed and bounded. -
requestIdis explicitly reviewed and bounded. -
urlsis explicitly reviewed and bounded. -
maxResultsis explicitly reviewed and bounded. -
freshnessMinutesis explicitly reviewed and bounded. -
detailLevelis explicitly reviewed and bounded. - The first production-like run uses a small representative sample.
- A maximum charge or internal spend alert is configured where appropriate.
- The workflow records Actor ID, build/version, run ID, Dataset ID, and input hash.
Data handling
-
entityIdis mapped to an idempotent destination key. -
observedAtand source-specific time fields remain distinct. -
sourceEvidence, gaps, and nulls are preserved. - Advisory and failure rows cannot enter the positive-results lane.
- Low-confidence and partial rows have a visible manual-review view.
- Retention and deletion rules match the type of data collected.
Action safety
-
recommendedActionis treated as a review label. -
safeToAutomate=falseblocks automatic external action. - Consent, suppression, legal, contractual, and platform rules are evaluated downstream.
- A reviewer can trace a material action back to source evidence and run metadata.
- Retry logic cannot duplicate a downstream action.
Ongoing quality
- The team monitors failure, retry, partial, low-confidence, and empty-result rates.
- A source-drift threshold pauses the workflow for inspection.
- Sample evidence is manually reviewed on a recurring basis.
- Cost per useful reviewed row is measured.
- Documentation and field mappings are updated when schemaVersion changes.
Frequently asked questions
Is this a database?
No. It is an on-demand observation tool. Each run collects or evaluates the submitted scope and records evidence at that time.
Does a found row prove commercial interest?
No. A found row proves only the factual observation described by its fields. Buyer intent is never inferred.
Can I automatically contact every result?
No. Use recommendedAction as triage, verify the evidence and identity, and apply your own consent, privacy, suppression, and outreach rules.
Why is safeToAutomate often false?
Because a useful observation can still require identity, context, legal, or source verification before action. Conservative routing prevents false certainty from scaling.
What should I do with low confidence?
Open confidenceRisks and sourceEvidence, close the important gap, or keep the row in a manual queue. Do not hide the confidence field.
What does partial mean?
The Actor delivered some usable rows but could not finish the requested scope, for example because more submitted URLs remained after a budget boundary or source failure. A budget boundary reached after the final requested row does not make an otherwise fulfilled request partial. Partial is not the same as empty.
What is a confirmed zero?
Only an explicit source or deterministic rule can support a confirmed absence. An outage, truncation, or unreadable response is not a zero.
Should I retry every failure?
No. Retry only when retryable is true. Invalid input, policy refusal, or deterministic classification should be corrected or handled, not looped.
Can I delete failure rows?
You can exclude them from a business-results view, but retain them in operational logs so Dataset completeness and retry decisions stay explainable.
How should I deduplicate?
Use entityId for the entity and, for stateful monitors, eventId for the observed transition. Also retain the Apify run ID.
Can I treat confidence as conversion probability?
No. Confidence measures evidence support, not purchase probability, revenue, suitability, or expected return.
Can I change the recommended action?
Yes. It is an explainable default. Your downstream policy can be stricter, and should encode organization-specific authorization and risk tolerance.
How do I estimate cost?
Run the smallest representative input, inspect live event prices and run usage in Apify, then model one billable result-found event per useful Dataset row plus any platform run-start charge. A zero-price default-Dataset-item entry may appear in the SDK aggregate receipt but is not another paid result. The live pricing panel is authoritative.
Why use a small prefill?
It produces a cheap, fast, inspectable first run and reduces the chance of scaling a wrong input or workflow assumption.
Can I schedule it?
Yes. Use an Apify schedule, but make the destination idempotent and review changes in failure, partial, and confidence rates.
Can I export CSV or Excel?
Yes. Apify Datasets support common export formats. JSON is recommended when you need nested evidence and decision fields.
Can I send results to Sheets or Airtable?
Yes. Preserve entityId, confidence, evidence, gaps, actions, and failure fields instead of mapping only the headline value.
Can I use it from Make, Zapier, or n8n?
Yes. Start the Actor, wait for a successful terminal state, read Dataset items, then branch on decision and failure fields.
Can an LLM consume the output?
Yes, but pass the structured evidence and limitations together. Instruct the model not to invent missing facts and to cite sourceEvidence.
What happens when a source changes?
The run may become partial, unavailable, or fail validation. Monitor these rates and inspect logs before treating changed output as a real-world shift.
Does public mean unrestricted?
No. Public visibility does not remove source terms, privacy obligations, retention rules, or the need for a legitimate downstream purpose.
Is a source URL permanent?
Not necessarily. Store observation time and material facts because web content can change or disappear.
Can I rely on one row for a high-stakes decision?
No. High-stakes legal, financial, employment, compliance, safety, or personal decisions require appropriate primary evidence and qualified review.
How do I report a suspected parsing issue?
Provide the Actor run ID, a redacted input, affected field, expected source evidence, and whether the issue reproduces. Never include tokens or private data.
What does success mean?
A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.
Support information to include with an issue
Provide the public Actor name, Apify run ID, Dataset item index or stable entity ID, a redacted Input, the relevant source URL, expected behavior, observed behavior, and whether retrying produced the same result. Do not include an Apify token, API key, private customer record, or unnecessary personal data.
Final interpretation rule
A useful row proves the stated deterministic HTML observations on one submitted public page. It is a manual audit lead, not proof of accessibility conformance, privacy compliance, violation, legal exposure, buyer intent, or commercial need.