Status: protocol published; collection window not started. No reliability percentage, platform winner, or performance result is published yet. The window will begin only after the production migration, secret-gated instrumentation, background worker, stale-run reconciliation, and collection-health check are live. Its exact dates will be added here. When the cohort closes and the checks are complete, aggregate results will replace this status on the same URL; the methodology and change log will remain available.
The goal of this benchmark is to answer a narrow question: when an eligible production website export begins, what outcome does it reach, how complete is the resulting artifact, and how long does that outcome take? Publishing the protocol first makes it harder to change definitions after seeing favorable or unfavorable data.
Download the machine-readable methodology and observation schema (JSON).
Why historical exports are not enough
Existing operational records can have retention bias. Successful ZIPs, delivery records, and completion logs may be retained through different systems or for different periods than failed attempts. Users also tend to retry failures, while one successful attempt may end the sequence. Instrumentation, product limits, and failure labels have changed over time.
Those differences make a retrospective success rate easy to overstate. Historical records may be used to validate the taxonomy, but they will not be used for the headline result. The primary analysis will use a prospective cohort in which every eligible attempt is recorded when it starts and retained under the same observation policy, regardless of outcome.
Prospective 60–90-day cohort
The collection window will be fixed prospectively and will run for at least 60 and no more than 90 consecutive calendar days. Its closing date will not be moved in response to interim results. The exact first and last eligible timestamps, methodology version, and aggregate sample size will be added here before any result is reported.
An attempt is eligible when a production export of a publicly reachable site passes input validation and its processing claim commits atomically with the durable benchmark start row. Internal tests, staff-triggered diagnostics, synthetic monitoring, duplicate webhook deliveries, and repair replays are not opted into the cohort.
The primary analysis uses one deterministic observation from the earliest eligible UTC day for a pseudonymous normalized hostname within each rolling 30-day cluster. If more than one attempt starts on that day, an opaque keyed attempt identifier breaks the tie; exact timestamps and raw hostnames are not retained in the benchmark table. Later exports remain repeat observations, so repeatedly retrying one difficult site cannot dominate the primary estimate. Automatic task retries keep the same attempt identifier rather than becoming new successes or failures.
Outcomes and metric definitions
Each percentage will publish its numerator and denominator. An attempt cannot disappear from the denominator merely because it failed before packaging.
| Metric | Definition | Denominator |
|---|---|---|
| Artifact-ready completion | The export reaches a completed state and a downloadable artifact is stored | All eligible primary attempts |
| Delivery outcome | The completed artifact is delivered through the selected download or integration path | Attempts for which that delivery path was requested |
| Page processing completeness | Pages written to the ZIP divided by pages whose capture was attempted | Attempts with at least one page capture attempt |
| Asset localization completeness | Successfully stored local assets divided by eligible assets requested for localization | Attempts that requested local assets and found at least one eligible asset |
| Time to terminal state | Seconds from accepted task start to completed, failed, canceled, or timed-out state | All eligible primary attempts with valid timestamps |
| Failure distribution | Mutually exclusive primary failure category | Failed eligible primary attempts |
A successful ZIP followed by a GitHub or Netlify delivery failure is counted as an artifact-ready export and as a delivery failure. This prevents a downstream integration problem from erasing a successfully generated artifact. A completed export with skipped or degraded pages remains completed, but its page-completeness result records the degradation.
Duration will be reported with the median and interquartile range, plus clearly labeled percentiles when the sample supports them. A single average will not be used as a speed promise.
Failure taxonomy
Every failed eligible attempt receives one primary category based on the earliest terminal cause:
- input or access rejection after task start;
- crawl or page-discovery failure;
- browser rendering or navigation failure;
- page processing or rewrite failure;
- asset retrieval or localization failure;
- packaging, storage, or artifact persistence failure;
- delivery integration failure;
- timeout or user cancellation;
- unclassified internal failure.
Secondary diagnostic labels can be retained internally, but they will not be mixed into the mutually exclusive public category totals.
Interaction checks are a separate validation sample
Menus, tabs, forms, client-side navigation, and animations cannot be inferred reliably from a task's final status. Predefined interaction checks will therefore be reported separately, with an applicability denominator for each check. Automated checks and any manual screenshots will use owned, synthetic, or explicitly authorized fixtures; customer page content will not be published as evidence without permission.
The interaction sample cannot establish that every exported site preserves every behavior. It is a controlled validation of named behaviors, not a substitute for project-specific QA.
Privacy and low-cell suppression
The analysis record uses an opaque keyed identifier for cohort grouping. Public reporting will not include domain names, full URLs, page content, account IDs, user IDs, authentication data, or raw customer artifacts.
No platform, site-size, delivery-path, or other breakdown will be published when its denominator is below 10. A small group may be combined into “Other” only when that combination cannot reveal the suppressed value. Complementary cells will also be suppressed when they could be subtracted from a total to reconstruct a small group.
Aggregate releases will include definitions, sample sizes after suppression, the observation window, and methodology version. Raw observation-level customer data will not be released. De-identified observation rows are purged after 180 days; only validated, disclosure-controlled aggregates and the versioned methodology remain after that period.
Planned breakdowns
If cell sizes are sufficient, the result will show:
- overall primary-cohort outcomes;
- single-page versus full-site export scope;
- small, medium, and large attempted-page buckets defined before analysis;
- requested hotlinked versus localized asset handling;
- delivery path, reported separately from artifact generation;
- supported platform groups, with small groups suppressed or combined.
These are descriptive breakdowns. They will not be presented as causal proof that a platform, plan, or site characteristic creates an outcome.
Limitations
- The cohort represents people who submitted a production export to NoCodeExport, not all websites or all exporters.
- Only publicly reachable content that the exporter can lawfully access is in scope; private dashboards and backend systems are not reproduced.
- Platform mix, site complexity, third-party outages, geography, and product changes during the window can affect outcomes.
- Page and asset completeness depend on attempt and eligibility definitions; undiscovered, unreachable, or access-controlled resources are not silently treated as successful downloads.
- Interaction validation covers named fixtures and checks, not every possible application behavior.
- The study is not a randomized competitor comparison and will not support universal “best exporter” claims.
- An aggregate completion rate does not guarantee that a particular site's design, forms, SEO, analytics, or interactions are ready to publish without review.
Publication and change policy
The status at the top of this page will be replaced by the analyzed aggregate results after the cohort closes, exclusions are reviewed, low-cell rules are applied, and the calculations are reproduced from the frozen schema. The result section will state the exact observation dates and will link any downloadable aggregate table.
Material definition changes create a new methodology version and will be documented below. They will not be applied silently after the data is inspected.
Change log
- Version 1.0.0 — August 31, 2026: prospective cohort, outcome definitions, retention-bias safeguards, privacy rules, and low-cell suppression published before results.
