Test Intent-Data Freshness: Nine Checks for Clocks and Outcomes

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.

Run nine freshness checks

Measure evidence age and each delivery stage separately. Timeliness depends on the stated decision window; correct identity, fit and permitted use are additional gates. Topic research, matching and enrichment do not establish a purchase or a universal commercially useful half-life.

1. Define every timestamp

Ask the provider to define each time field in plain language: event occurred, collected, received, classified, account resolved, person enriched, record generated, record delivered, connector accepted, CRM written, and campaign or sales workflow activated. A single “last updated” field can hide hours or days of processing.

Record timezone, precision, null behavior, backfills, batching, late-arriving events, and whether the field is an event time or a system-write time. The assessment fails if the buyer and provider use the same word for different clocks. Your contract and pilot acceptance test should reference the defined field, not an undefined promise such as real time.

2. Draw a representative sample

Use a stratified sample from the actual ICP: large and small accounts, priority industries, regions, subsidiaries, sparse and dense web traffic, easy and difficult domains, and both active and quiet periods. Do not let the vendor choose only showcase accounts. Include exclusions and accounts you know should not match.

Set the sample, minimum usable records, error definitions, and pass thresholds before results are visible. Track missingness as well as lag. A feed that delivers quickly for a narrow subset may still be a poor fit if the usable-coverage rate is low or concentrated outside the client’s market.

3. Use known events

Create a small truth set of events whose timing the buyer can independently observe: a controlled first-party form submission, a known page visit where testing is permitted, a published hiring change, a verified technology change, or another non-sensitive event with a reliable clock. Never manufacture off-site activity that violates terms or interferes with a publisher.

Known events reveal clock meaning, collection lag, resolution behavior, duplicates, and correction paths. They do not prove the feed’s entire market coverage. Use them alongside the representative sample, and keep first-party explicit actions separate from inferred off-site intent.

4. Measure collection-to-delivery lag

For each record, calculate the intervals that matter: event-to-collection, collection-to-classification, classification-to-resolution, resolution-to-delivery, and delivery-to-client acceptance. Report the distribution – not just an average. Median, upper percentiles, missing timestamps, and the share delivered inside the chosen decision window expose long-tail delay.

Evaluate lag by signal type and use case. A funding announcement may remain relevant longer than a website visitor session. A weekly strategic report has a different requirement than a sales alert or paid-audience sync. A provider should not be declared universally fresh or stale without a use-case threshold.

5. Repeat the test over time

One pilot window can coincide with unusually high traffic, a strong data partner, a product change, or a quiet market. Repeat the same sample and calculations across multiple delivery cycles. Log schema changes, connector downtime, coverage shifts, corrections, and provider releases that could alter the result.

Separate ordinary variance from a structural failure. A recurring assessment can set warning and stop states: within threshold, watch, degraded, and fail closed. An agency should show clients when evidence quality fell rather than quietly delivering the same volume with lower utility.

6. Test decay and expiry

Choose a provisional expiry rule for each source, topic and workflow, then evaluate actual usefulness as records age. Do not assume an exponential decay curve or known commercial half-life. Preserve evidence, uncertainty, rule versions and buyer outcomes; retest after changes.

Require the feed to support corrections, retractions, and state changes. An account that was active should be able to return to baseline; a departed employee should not remain attached forever; an invalid match should be suppressible. Keeping every past event in an “active intent” segment inflates volume and erodes trust.

7. Audit identity resolution

Freshness and identity are separate dimensions. Check company-domain resolution, parent/subsidiary treatment, location, current employment, duplicate people, confidence values, and the evidence used to join records. Measure false matches and unresolved records, not only match rate.

Never convert account-level research into a claim that a named person researched a topic. If person-level activation is proposed, require a separate lawful and supportable identity process, permitted use, suppression, current employment validation, and human review. A wrong-person alert and a slower account-level record have different failure paths; hold unsupported person-level action.

8. Measure activation latency

A feed can arrive quickly and still become stale inside the client’s stack. Time the API, file, webhook, integration, CRM queue, audience upload, sales routing, review, and approval steps. Record destination rejection, partial writes, duplicates, rate limits, and the interval until a seller or campaign can actually act.

Test the rollback path too. Can the client remove an expired audience, suppress a corrected record, retract a sales task, and prove the change reached the destination? Test correction and reversal propagation separately from delivery speed.

9. Correlate freshness with outcomes

Join age bands to independent outcomes: seller acceptance, qualified meetings, opportunity creation, pipeline progression, win rate, and revenue. Use a control or matched comparison when practical. If fresher records cost more but do not improve qualified economics, the faster delivery may not be worth the premium.

Do not let the same intent score define both the cohort and its success. Report sample size, outcome window, missing joins, and uncertainty. Freshness is valuable only when it changes a supportable decision or outcome; faster noise is still noise.

Assign sampling and clock owners

Run the assessment as a controlled procurement workflow: write decision thresholds → prepare real-ICP sample and known-event truth set → receive records through the proposed delivery path → preserve raw timestamps and payloads → validate schema and identity → measure lag and missingness → activate a bounded test → reconcile delayed outcomes → document exceptions → accept, remediate, renegotiate, or reject.

Useful resources include a timestamp dictionary, stratified-sample worksheet, raw immutable delivery log, schema validator, identity-error register, activation receipt, correction and suppression test, outcome join, and acceptance-scorecard template. A spreadsheet can support a small pilot; a warehouse is useful for recurring high-volume distributions. Tools should make evidence inspectable rather than hiding it behind a composite score.

Marketing or RevOps owns the commercial threshold; data engineering owns ingestion and clock calculations; sales operations owns action feedback; analytics owns sampling and outcome comparison; procurement owns acceptance terms; and privacy, security, legal, or compliance reviewers assess provenance, permitted use, access, retention, and vendor controls. Name one owner for stop and rollback decisions.

Compare demos, SLAs and actual tests

A vendor demo is useful for learning terminology and workflow, but it is not evidence of performance on your ICP. A contractual delivery SLA can define a clock and remedy, but only if both are precise and the buyer can verify them. Manual spot checks are fast, but they miss distribution tails and coverage gaps. A controlled sample-and-outcome pilot costs more effort and produces the most decision-relevant evidence.

Use the simplest method that fits the stakes. A low-risk weekly planning feed may need a smaller sample and wider threshold. Automated outreach, advertising, or personal-data actions require stronger provenance, identity, correction, and approval tests. No purchase is the right choice when clocks are undefined or permitted use cannot be documented.

Check the decision-window prerequisites

Use a defined freshness assessment when evidence age can change a material operating decision. Check actual scope, volume, available clocks, source rights, review capacity and outcome maturity. An account-value, industry or regulated-sector label does not establish a universal ideal use case.

It is a poor fit to pretend a precise benchmark exists when the use case has no decision window or outcome definition. A small team may use a lighter checklist if records remain account-level and human-reviewed. Any buyer that cannot store timestamps, corrections, and outcomes should fix that foundation before paying a premium for speed.

Budget verification and full costs

Budget for sample design, raw data access, implementation, connector testing, identity validation, analyst time, privacy and security review, outcome reconciliation, and repeat cycles – not only the feed. Include the cost of delayed or wrong action, manual repair, duplicate records, and client support. Model cost per usable, in-profile, fresh, correctly resolved, activatable record and cost per qualified outcome.

Ask each provider whether pilot data includes every timestamp, corrections, raw exports, API access, usage, overages, support, security review, and permitted client-service use rights. Public list pricing does not substitute for a scope-matched quote.

Define seven acceptance measures

• Clock completeness: share of records with every required timestamp and timezone.
• Lag distribution: median, upper percentiles, and share inside the decision window by signal type.
• Usable coverage: in-ICP records that are fresh, correctly resolved, permitted, and activatable.
• Identity quality: unresolved, false-match, duplicate, parent/subsidiary, and employment-error rates.
• Correction quality: time to suppress, retract, update, and verify downstream deletion.
• Outcome quality: acceptance, qualified opportunities, pipeline, and economics by age band.
• Service quality: uptime, schema incidents, support response, remediation, and client adoption.

Thresholds should be buyer-defined and use-case-specific. Do not publish a universal freshness benchmark or imply a small pilot guarantees future performance.

Record collection and correction responsibilities

Verify actual source, observation unit, collection context, recipient, purpose, jurisdiction, destination, rights and suppression before activation. Preserve ownership of necessary fields, access, retention, correction, deletion and incidents. A timestamp or vendor description does not establish permitted use.

Verify the actual implementation, security responsibilities, access, logging, correction, incident and exit procedures. Resolve unanswered requirements before rollout rather than treating a vendor statement as general legal or security approval.

Common failures include accepting an undefined “real-time” claim, using a system-write time as event time, testing only vendor-picked accounts, ignoring late-arriving records, retaining expired identities, failing to propagate suppression, and reporting volume as accuracy. Human approval should remain in the loop for personal-data use and consequential outreach or advertising.

Scope freshness-review work separately

An agency can sell an initial acceptance audit plus a recurring signal-health service: timestamp dictionary, real-ICP sample, delivery-lag report, identity and correction tests, activation receipts, monthly decay analysis, client adoption review, and quarterly outcome recalibration. Define delivery and remediation commitments; do not guarantee revenue.

Review an available MarketPulse topic, saved ICP and actual preceding-24-hour matches for the approved research purpose. Keep uncertain company context visible. AIMEE can organize supplied context through configured tools; named owners approve actual exports, messages, audience uploads and CRM writes.

AIMEE can prepare a review brief through configured connected tools. Keep proposed actions separate from actual approvals and destination acknowledgements. Confirm the implementation and permissions before execution.

Use the implementation checklist

• Write the commercial decision window for each signal type.
• Define every source, processing, delivery, identity, and activation timestamp.
• Build a stratified sample from the real ICP and include negative controls.
• Create a small independently timed truth set without violating platform terms.
• Preserve raw payloads and calculate the full lag distribution.
• Repeat across delivery cycles and log schema or coverage changes.
• Set decay, expiry, correction, suppression, and rollback rules.
• Audit identity separately from speed.
• Measure destination latency and deletion propagation.
• Join age bands to independent qualified outcomes.
• Accept or expand only after human product, pricing, privacy, security, and legal review.

Keep source-event age, system delays, missing fields, correction state, identity support and actual action separate. If the necessary clocks or correction evidence are unavailable, record the limitation rather than claiming to have verified an undefined real-time promise.