How we designed paired-control experiments to measure government registry accessibility — and what the data shows.
If you've ever built a tool that queries a government database, you know the pain: no API, no docs, no SLA. Now imagine that database is China's national company registry, serves 160 million business records, and actively distinguishes between human browsers and everything else.
We run Currawong Web, a supplier verification service. Over the past few months we ran controlled experiments measuring what happens when you try to access Chinese government registries from outside China. We published 20 datasets on Harvard Dataverse — all CC-licensed, all reproducible. Here's the technical story.
The problem: a registry that fights back
China's national company registry (国家企业信用信息公示系统, or NECIPS) holds the canonical registration data for every company in the country. It's the source of truth for business licence details, legal representative, registered capital, and operational status.
It also serves a JavaScript challenge to every visitor.
This isn't a simple cookie check. The challenge evaluates your client environment — we observed different outcomes depending on browser fingerprint characteristics even from the same IP address. The system appears to use these signals to decide whether to serve data or return an empty response.
Experiment design
We wanted to measure this systematically, not just anecdote our way through it. So we designed a paired-control experiment:
Variables:
- Client profile matrix: 5 distinct browser fingerprint configurations, ranging from a vanilla Chrome profile to headless configurations
- Entry point matrix: direct URL, search-engine referral, and portal navigation paths
- Network location: 2 mainland China networks + 1 overseas comparison point
Protocol:
- 3 rounds per combination
- Same target company in each round
- Record: HTTP status, JS challenge presence, data payload presence, time to response
- Control: a known-accessible domestic business portal queried in the same session
This gave us a structured matrix of observations rather than a single pass/fail answer.
What the JS challenge actually does
We're deliberately not publishing bypass methods — that would undermine a legitimate anti-scraping system. But the technical observation is worth documenting:
- Initial page load returns a minimal HTML shell with an inline script
- The script performs environment checks — we observed it probing properties that differ between headless and headed browsers
- On passing, a cookie is set and the page reloads with actual content
- On failing, the page either loops or returns empty content — no error message, no HTTP error code
The subtlety is that this isn't binary. Some client profiles pass the challenge but receive degraded results. The registry appears to have multiple tiers of trust, not just allow/block.
Results: what works and what doesn't
From our 106-company English-name lookup dataset:
- End-to-end success rate was low. Most failures occurred before the verification step — at the name-matching stage, not the access stage.
- Network location matters, but less than client profile. A well-configured browser from overseas performed better than a poorly configured one from inside China.
- Certificate registries vary wildly. We tested 8 official sources (CCC, CQC, CFDA, and others) with 240 observations. Some answer reliably from any location. Others are effectively unreachable without a China-side session.
The registration-change problem
One dataset tracked 264 manufacturers classified as national "Little Giant" firms (专精特新"小巨人"). We compared registration snapshots over time and found that key fields — operational status, registered capital, business scope — shift more frequently than most due-diligence processes assume.
A supplier check from 6 months ago may already be outdated. This isn't a data-quality issue — it's a feature of a dynamic registry system that reflects real corporate changes. The implication for anyone building verification tooling is that you need a freshness model, not a cache.
Alibaba vs. 1688: identity field comparison
We also compared supplier identity fields between Alibaba.com (international) and 1688.com (domestic) for 94 companies present on both platforms. The registered company names, addresses, and representative details don't always match — not because of fraud, but because of legitimate differences in how companies present themselves for international vs. domestic trade.
This matters for entity resolution. If your verification system tries to match a supplier's Alibaba profile against the government registry using the English trade name, you'll get a different result than matching via the Chinese registered name on 1688.
Lessons for builders
If you're building tools that interact with government data sources — in any country — a few patterns from this work apply:
- Measure access, don't assume it. We started with the assumption that the registry was accessible. The data showed a more nuanced picture.
- Design for failure tiers, not binary up/down. A system that returns empty content with HTTP 200 is harder to handle than one that returns 403.
- Client fingerprint matters more than you think. We saw different outcomes from the same network with different browser configurations.
- Build a freshness model. Government records change. Your verification is a snapshot, not a permanent fact.
- Separate name-matching from access. Our biggest source of failure wasn't "can't reach the registry" — it was "can't find the company by its English name."
Data availability
All 20 datasets are on Harvard Dataverse with DOIs and CC licences. Download them, reproduce the experiments, challenge the methodology. That's the point.
- Currawong Web research datasets on Harvard Dataverse
- currawongweb.com — our supplier verification service
Derrick Zhou builds supplier verification tools at Currawong Web. Previously worked in cross-border trade operations.
Top comments (0)