Lead and Intent Data QA: Release Tests, Sampling and Costs

Apply ten documented QA tests

Copy this checklist into each delivery run. Replace every blank acceptance value with a client-approved, contract-scoped rule. Do not borrow thresholds from a different data source, use case, or client.

1. Provenance test: Can the team identify the source category, received time, relevant use constraint, transformation, and current evidence for the field?
2. Scope test: Does the record match approved topics, markets, account criteria, geography, and client use? Reject rather than stretch the scope.
3. Schema test: Are required fields present, typed, normalized, and within allowed values? Are nulls distinct from zero, false, or unknown?
4. Identity test: Does the resolved entity have sufficient evidence for the intended action? Record conflicts, confidence, review, and rejection.
5. Freshness test: Is each signal and attribute inside its approved age rule? Preserve observed and processed times separately.
6. Uniqueness test: Are duplicates defined at the right event, account, contact, and delivery levels? Preserve legitimate repeated signals.
7. Eligibility and suppression test: Do exclusions, existing customers, active opportunities, opt-outs, client rules, and sensitive segments work before activation?
8. Cross-field reasonableness test: Do domain, company, role, geography, topic, source, and destination agree? Flag conflict instead of forcing a match.
9. Delivery integrity test: Does the destination receive the intended fields, row count, encoding, permissions, and client separation without silent truncation?
10. Evidence and exception test: Can a reviewer reproduce the checks, find rejected items, see corrective action, and understand residual limitations?

Release state should be one of four values: pass, pass with accepted exception, hold for correction, or reject. Give each exception an ID, severity, affected scope, owner, containment action, client-notification decision, correction evidence, and closure approval. “Looks okay” is not a release state.

Start with one fit-for-purpose delivery

Define fitness for one decision before designing checks. A record used to prioritize an account needs different evidence from one sent into a person-level outreach workflow. Start with the smallest useful delivery, run the full gate, show the client accepted and rejected examples, and record feedback. Repeatability comes from fixed definitions and controlled exceptions, not from pretending sources never change.

Build QA upstream. Validate a source sample before integration, validate schema at intake, resolve identity before qualification, apply suppression before activation, and reconcile the destination after delivery. This shortens correction loops and makes time-to-value measurable. The agency intent-data vendor guide can be used to test whether an underlying provider exposes the evidence and controls the QA plan needs.

Assign release and exception owners

Assign a source owner, data steward, identity reviewer, activation owner, security or privacy escalation owner, client approver, and release owner. The release owner should be able to stop delivery. The sequence is intake, quarantine, source and schema validation, identity review, scope and suppression, sample inspection, automated rule checks, exception triage, correction or rejection, destination test, release approval, client handoff, and post-delivery reconciliation.

Set service levels for acknowledgement, initial triage, containment, correction attempt, client decision, and closure. A dependency clock should stop only under written rules. The handoff contains release state, scope, counts by disposition, test results, open exceptions, known limitations, delivery evidence, and the next scheduled review. Never hide rejected records by reporting only the delivered count.

Maintain reproducible QA artifacts

The basic toolkit includes a data dictionary, rule registry, source register, sample worksheet, validation environment, identity review queue, exception tracker, secure file or API delivery, field-level change log, and client-facing scorecard. At higher volume, add automated schema contracts, anomaly detection, lineage, role-based workflow, and destination reconciliation. A portal is useful when it shows current status and limitations rather than only polished totals.

Evaluate software on reproducibility, versioned rules, raw-to-output lineage, access control, client isolation, error handling, export, deletion, and the ability to sample rejected as well as accepted records. Avoid ranking tools by the number of checks advertised. A black box that marks a record valid without exposing the rule cannot support a defensible client exception conversation.

Compare automated and human review

A hybrid can combine deterministic checks with human review of ambiguous records, provided its rules, sample design, cost and actual risks support the decision. Compare error coverage, explainability, reviewer consistency, client visibility and correction speed rather than assuming a universal best approach.

Use automation for deterministic checks and queue risk-based samples and conflicts for people. Compare options by setup work, recurring labor, error coverage, explainability, client visibility, correction speed, security boundary, and total cost. A manual spot-check with no sampling plan is not equivalent to documented human review. Likewise, an automated green status is not proof of real-world accuracy.

Price the actual validation work

Setup cost includes defining acceptance rules, mapping fields, establishing truth or reference sets where possible, creating suppression tests, configuring validation, integrating the destination, training reviewers, and agreeing on exception communication. Recurring cost includes source and platform charges, compute, sample review, identity conflicts, support, client questions, reprocessing, destination changes, and documentation maintenance.

Calculate scoped delivery cost as source and usage costs plus direct QA labor, tooling allocation, exception/support allowance and any defined reserve. That cost total is not a selling-price formula for a target margin. With no pass-through adjustments, price for a chosen delivery contribution rate is defined cost divided by one minus that rate. Keep acquisition, general overhead, tax and financing visible separately.

Measure tested fields and defined outcomes

Track time to approved schema, first releasable sample, first delivery, exception containment, correction, and client acceptance. Quality KPIs include provenance coverage, required-field completeness, rule-valid rate, duplicate rate, freshness distribution, identity conflict rate, suppression failure, accepted-exception share, destination reconciliation difference, and reopened issue rate. Report both numerator and denominator.

Use “accuracy” only when there is an appropriate truth set and method. Otherwise name what was tested, such as domain agreement or client-confirmed role. Adoption metrics include reviewed deliveries, disposition completeness, activation acceptance, and client feedback resolution. Outcome evidence can show how accepted records progressed, but QA does not cause pipeline or revenue. Use the client’s own history for benchmarks and label sample size, selection method, and uncertainty.

Match QA scope to the use case

A low-maturity client may need a controlled spreadsheet, a small risk-based sample, manual identity review, and delivery by a named owner. A middle-maturity client can use automated schema validation, CRM deduplication, exception tickets, and destination reconciliation. An advanced client may add warehouse lineage, versioned data contracts, statistical sampling, automated monitoring, and separate client acceptance environments.

Vary QA by use case as well as maturity. Account-priority reports can tolerate different fields and uncertainty from direct outreach or audience activation. A strategic account list may justify deeper manual review. A recurring broad feed needs more automation. Do not weaken the privacy or security boundary because a client is immature. Reduce the data and action scope instead.

Preserve signal and identity evidence

For signals, inspect provenance, entity level, observation and processing times, topic definition, change history, and permitted use. For identity, test the inputs relevant to the action, preserve method and conflict, and require review when evidence is ambiguous. Domain-to-company resolution, contact matching, and household or device inference have different implications. Do not report them as interchangeable certainty.

For activation, verify qualification, suppression, destination, permission, owner, and payload. Use a dry run or isolated test when the integration supports it. Reconcile sent, accepted, rejected, and changed records. Outcome evidence should preserve client disposition and downstream events without retroactively turning a failed record into a pass. Quality reporting shows how the data performed against defined tests, not whether every prospect eventually bought.

Review scope and unsupported certainty

Risks include undefined acceptance, source drift, stale fields, false merges, duplicate suppression, cross-client leakage, excessive personal data, unsecured exports, integration truncation, reviewer inconsistency, biased samples, silent rule changes, and a client treating a QA score as certainty. Maintain a risk register and map each risk to prevention, detection, containment, correction, and client communication.

Review actual source rights, purpose, fields, identity boundaries, access, retention and destination approvals. A passing validation rule does not certify privacy, security, legal suitability or every record field.

Scope recurring QA delivery

Include a maintained data dictionary, source and field inventory, acceptance rules, sampling plan, automated test results, identity-review queue, suppression evidence, exception register, destination reconciliation, client scorecard, change log, release approval, and correction allowance. The report should show what was tested, what passed, what failed, what was excluded, and what remains uncertain.

Add a renewal decision: continue, repair, reduce scope, expand, or stop. Tie it to observed quality, client adoption, delivery cost, open risk, and useful outcome evidence. The agency intent-data reporting guide helps place QA evidence inside a client review. The agency intent-data compliance program provides a related governance structure without turning QA into a compliance guarantee.

Choose a sample that supports the decision

Define the population, risk strata, selection method, sample unit, reviewer, test, acceptance rule, and escalation before looking at results. Include accepted, rejected, high-risk, newly changed, and edge-case records. A purely convenient sample can miss systematic errors. For a critical release, ask a qualified analyst whether the sample supports the decision. Do not present a sample percentage as the population’s accuracy unless the design and uncertainty justify that inference.

When a sample fails, decide whether the failure is isolated, systemic, or unknown. Quarantine affected scope, expand investigation, correct the rule or source, rerun the test, and preserve evidence. Do not simply replace the failed row with another row until the sample passes.

Current MarketPulse research workflow

BrandWell MarketPulse: intent data starting at $500/mo. Find people researching topics relevant to what you sell, apply saved ICP filters, and review available contact details before taking action.

MarketPulse plans are starting at $500/mo. Verify current package scope and offers on the product page.

MarketPulse standard monthly plans

Plan	Topics and refreshes	Monthly exports
Starter	1 topic, weekly	25,000 contacts
Growth	3 topics, daily	100,000 contacts
Scale	10 topics, daily	Unlimited contacts

Swipe the table to see all columns.

A pull retrieves available data from the previous 24 hours for one topic. Daily use across all included topics provides 90 Growth pulls or 300 Scale pulls in a 30-day month. Weekly Starter pulls vary by calendar month. Available audience size and contact fields vary, and audiences may overlap. Refreshes stop at the plan limit without overage charges.

• Find and qualify: search the topic catalog, save your ICP, and review the people and companies that match.
• Act on the research: export qualified contacts or prepare an Outreach or Direct Mail workflow. Connected products, channel usage, and fulfillment may cost extra.
• Get help from AIMEE: Growth and Scale include AIMEE for the initial user to research accounts and prepare the next step through connected tools.

Agencies and other service businesses can build client deliverables around their available Intent Scans and exports. Keep each client’s scope, permissions, and service fees clear. A subscription is not a promise of a white-label platform or exclusive access to a market.

Explore MarketPulse and watch the demo or compare plans starting at $500/mo. Any early-access discount is a separate, time-limited offer shown to an eligible recipient.

Keep custom QA and product scope separate

AIMEE can help summarize approved validation results through configured connected tools. Preserve the actual test, sample design and missing evidence. Human owners approve corrections, exports and release decisions.

Start with supported MarketPulse research starting at $500/mo and preserve the actual topic, available fields and pull window. AIMEE can help organize an approved QA brief through configured tools. A custom validation service, client portal and integration test system are separately scoped agency work.

MarketPulse plans are starting at $500/mo. Starter includes 1 topic, weekly refreshes, and 25,000 exportable contacts per month. Growth includes 3 topics, daily refreshes, and 100,000 exportable contacts. Scale includes 10 topics, daily refreshes, and unlimited contact exports. AIMEE for the initial user is included with Growth and Scale. Compare MarketPulse plans and current offers.

Copyable assistant validation review

Use an assistant only with approved, minimized records and documented tools. Keep it in a review role until the agency has separately approved any live-system access. Require human release authority.

Act as a QA review assistant for a recurring lead and intent-data delivery.
Inputs: approved data dictionary, source register, acceptance rules, sample plan,
suppression rules, identity-review policy, delivery manifest, and test results.
Return: rule-by-rule results, failed record IDs, severity, suspected scope,
missing evidence, correction options, retest plan, and a release recommendation.
Separate deterministic validation from judgment. Never infer a missing identity,
source, permission, truth value, legal status, or client approval. Do not invent
benchmarks, accuracy rates, pricing, outcomes, or guarantees. Do not modify source
data, suppressions, permissions, or destinations. Route ambiguity, security,
privacy, legal, and high-impact identity decisions to named human owners.

An assistant recommendation is not release authority. Human owners verify the evidence, unresolved exceptions and agreed acceptance rules before any live delivery.

Preserve failures and reference boundaries

Maintain truth sets carefully. A client-confirmed company domain can test one identity field, but it does not validate a person’s current role, an intent event, or the permitted activation. Record who established the reference, when it was applicable, what field it supports, and how conflicts are resolved. Refresh or retire reference data when the underlying fact can change.

Blind review can reduce confirmation pressure for selected tests. Give the reviewer the fields needed for the rule without showing whether the record came from a favored source or was expected to pass. Compare reviewers on the same bounded sample when judgment is material. Disagreement is an exception to investigate, not a reason to average two unsupported answers.

Periodically seed safe, synthetic test records designed to fail a known rule, provided the agency and client systems allow it and the records cannot trigger real outreach. Confirm that the record is quarantined and removed. Keep synthetic tests clearly separated from client data and never let them appear in performance reporting.

A mature QA program makes it easy to hold, reject, and explain records. The goal is not a perfect-looking delivery. It is a fit-for-purpose release whose source, rules, exceptions, and limits can be understood by the agency and client. That discipline protects trust and provides a sounder basis for renewal than an unsupported claim of perfect data.