Measurement workflow
Measure enrichment on your own sample.
Use the same records, field requests and acceptance rules to compare runs. The downloadable runner records returned fields and latency without exporting contact values in its report.
Define the sample before seeing results.
Select records you are authorized to process, with known person identifiers and a documented selection rule. Include the countries, seniorities, company sizes and difficult records relevant to your workflow. Deduplicate inputs. Do not replace failed records with easier ones after the run.
Start with 20 records to validate the process. A small pilot is a functional check, not a representative market benchmark. Record the collection date, eligibility criteria, sample count, requested fields and plan. Save inputs privately as a JSON array:
[
{"first_name":"Alex","last_name":"Reed","company_domain":"example.com"}
]Run once with an explicit call budget.
Download targetwise-benchmark.mjs. With Node.js 22+ and TARGETWISE_API_KEY configured in your environment, run:
node targetwise-benchmark.mjs input.json --run --limit=20
# Add --phone only when your evaluation needs business phones.Without --run, the script sends no requests. It sends at most one request per input, runs sequentially and stops on authentication, balance, rate-limit, configuration or transport failures. Requested returned fields consume the normal plan balance. The report records row numbers, request IDs, status, field-presence flags and latency; it excludes input identities and returned contact values.
Use a new output directory for each run. Keep the sample, plan details and report together privately; redact request IDs before publishing. If the run stops early, report the attempted count and the reason before drawing conclusions.
Keep returned data separate from accepted data.
| Metric | Denominator | How to obtain it |
|---|---|---|
| Email return rate | All attempted records | Records with a returned work email ÷ attempts |
| Business-phone return rate | All attempted records | Records with a returned business phone ÷ attempts; not mobile classification |
| Accepted-result rate | All attempted records | Requires a separate review against predeclared acceptance rules |
| Deliverability / correct-person accuracy | Independently reviewed returned results | Requires external verification; the runner leaves these metrics null |
| Median / p95 latency | Completed HTTP 200 responses | Measured by the runner; report errors separately |
| Cost per accepted result | Accepted results | Actual allocated subscription and verification spend ÷ accepted results |
Record unused monthly balance in your cost calculation. A per-field rate is not the same as the effective cost of your subscription. Use current plan terms and reconcile billed usage against the dashboard.
Publish only measured and approved evidence.
A publishable benchmark needs the sample methodology, run date, request settings, attempted and completed counts, error distribution, independent acceptance checks and cost assumptions. Include the raw aggregate report and limitations. Repeat the same protocol for each comparator.
Customer case studies also need the customer’s permission to use their name, quote and measured outcomes. The illustrative market model demonstrates arithmetic; it is not evidence of a measured TargetWise outcome.