On this page
Implement MarketPulse around one defined market, one useful decision and a named owner. Select relevant topics, apply the ICP, inspect the available matches and prepare a reviewed next step. Use five phases: scope, configure, control, test, then launch and learn.
This guide separates the current product workflow from additional agency or technical work. A MarketPulse subscription does not automatically provide a custom API implementation, a white-label client portal, exclusive topics or managed delivery.
Reviewed October 3, 2026.
Start with the current MarketPulse workspace
- Select a relevant topic from the catalog.
- Apply and save your ideal-customer-profile filters.
- Review the available people, roles, companies and contact fields.
- Inspect relevance, missing information and overlapping audiences.
- Export eligible records or prepare a reviewed next step through the supported configured workflow.
- Verify the destination and record the actual outcome.
Standard plans are Starter includes one weekly refreshed topic and 25,000 monthly exports, Growth includes three daily topics and 100,000 monthly exports, and Scale includes ten daily topics and unlimited exports.
A pull retrieves available data from the previous 24 hours for one topic. In a 30-day month, daily use across all included topics provides 90 Growth pulls or 300 Scale pulls. Weekly Starter pulls vary by calendar. Audiences can overlap, and connected products, channel usage and fulfillment may cost extra. Any eligible early-access offer is separate from standard pricing.
Five readiness gates
1. Outcome
Choose a decision the team can act on, such as a weekly review of matching accounts. Define the baseline, responsible owner, review capacity and evidence to record. “Find buyers” is too broad to serve as an acceptance test.
2. Market and signal
Document the supported market, relevant topics, ICP, excluded meanings and expected useful scope. Inspect actual results rather than inferring fit from a headline catalog count. Keep unknowns and unsuitable records visible.
3. Action
Choose one bounded next step: an account brief, an internal review, an export or an approved configured campaign action. Name the destination, required evidence, owner, approval and expiry. An ignored queue is not an implemented workflow.
4. Data and governance
Review the actual source, purpose, access, retention, permitted use, suppression and incident responsibilities. Identification or research activity does not establish permission for every channel. Review the actual law, contracts and destination rules with qualified advice where needed.
5. Commercial scope
Confirm the selected plan and allowances. Separate the subscription from additional services, integrations, agency fees and channel costs. Document any special rights in the actual agreement; do not infer a general reseller arrangement or exclusive territory from this guide.
A five-phase implementation plan
Phase 1: scope and agree acceptance
Write a short charter with the market, topic, ICP, action, owner, capacity, baseline, required evidence and decision date. Identify what is part of the product and what requires additional implementation.
Exit check: the relevant business, operation and data owners agree on the purpose and pass conditions.
Phase 2: configure and inspect the workspace
Set up the actual project, topic and ICP. Review access and available output. For a separate reporting or integration layer, define its fields, identifiers and client boundaries explicitly. A proposed event schema is not a promise that every field is supplied natively.
Exit check: a sample can be explained and reconciled to the available source, and the actual access boundaries have been tested.
Phase 3: define qualification and approvals
Use accept, reject, hold and expire states with reasons. Define the required fit and evidence for the next action. Keep suppression and action eligibility separate from a score or the apparent attractiveness of an account.
AIMEE can help prepare an account brief or other work through configured connected tools. Inspect the result and retain a named approval owner. Verify actual supported tools rather than assuming unrestricted execution.
Exit check: a reviewer can reproduce the decision and inspect the supporting evidence before approving the next step.
Phase 4: connect, test and recover
Start with one actual supported destination. Check missing fields, duplicates, retries, stale records, suppression, permission failures, expired access, schema changes and missing receipts. Keep an exception owner and a recovery runbook.
If additional API work is in scope, review its design and runtime risks. NIST’s March 2026 API-protection publication addresses API lifecycle risks and controls; it does not certify BrandWell or establish a particular connector.
Verify duplicate prevention at the actual side-effect boundary. Repeating a request must not silently create two tasks or messages; a locally assigned ID alone is not proof that the destination supports idempotent behavior.
Exit check: required failure tests pass, the recovery path is documented and delivered records reconcile with the defined ledger.
Phase 5: pilot, launch and learn
Run a bounded evaluation of topic relevance, available match information, review effort and the intended action. A short pilot can reveal implementation problems; it does not prove long-cycle revenue, universal match quality or incremental lift.
Launch only within approved capacity. Monitor exceptions, record rule changes and check whether a real owner uses the output. Keep implementation acceptance separate from later commercial outcomes.
Exit check: production ownership, monitoring, support, change control and end-of-service handling are documented.
Keep an implementation evidence pack
- Selected plan and verified allowances.
- Implementation charter and responsibilities.
- Market, ICP, topic and exclusions.
- Data-flow and field definitions for the actual workflow.
- Approved uses, access and retention decisions.
- Qualification rules and reasons.
- Action brief and assistant instructions where used.
- Connection tests and recovery runbook.
- Baseline, metric definitions and outcome records.
- Handoff, support, change and exit plan.
Test with approved, minimized data. A sandbox is useful only if its relevant permissions and schema resemble the real workflow. Do not copy live client information into an uncontrolled environment for convenience.
Acceptance checklist before production
- Product: current product and purchased allowances are understood.
- Market: ICP and exclusions are approved.
- Topics: relevance and ambiguous meanings have been sampled.
- Delivery: the actual export or supported destination is defined.
- Access: user and client boundaries are tested where applicable.
- Evidence: available source, fields and dates are preserved without inventing missing provenance.
- Identity: required confidence is defined for the specific action.
- Governance: purpose, suppression, retention and incident ownership are reviewed.
- Qualification: accept, reject, hold and expiry decisions can be reproduced.
- Activation: owner, capacity, approval and rollback are clear.
- Recovery: duplicate, permission, suppression and destination failures are tested.
- Measurement: baseline, unit, denominator and follow-up are fixed.
- Economics: subscription, labor and additional work are modeled.
- Exit: access, data and additional destinations can be handled appropriately at termination.
For a failed item, record an owner and resolution date. Return to the relevant phase rather than waiving the control because a sample looks promising.
Who should own implementation?
An internal team can own the workflow, an agency can provide separately scoped research and operations, and product support can answer configuration questions. Choose by actual expertise, responsibilities and capacity. Do not assume that a vendor owns client change management or that an agency receives particular licensing rights automatically.
Worked example: budget the operating effort
For a fictional monthly evaluation, a team selects the $250 standard Starter plan, spends eight review hours valued at $75 per hour and budgets $150 for additional setup work. The defined total is $250 plus $600 plus $150, or $1,000.
To calculate effective cost per pull, divide the subscription cost by the Intent Scans actually used during the same period. A pull retrieves available data from the previous 24 hours for one topic. Unused allowances increase the effective cost per consumed pull; fields, counts and audience overlap vary.
Track the first sample, first accepted output, first completed action and first reconciled outcome separately. Revenue may take longer than the implementation period. Do not manufacture a short-cycle ROI to declare the setup successful.
Frequently asked questions
Are all integrations included?
No blanket claim is made. Verify the actual supported workflow, selected plan and any additional implementation scope.
Is TrafficID the same as MarketPulse?
No. TrafficID concerns eligible identified visitors to your own site. MarketPulse supports topic research. Keep their sources, restrictions and interpretations distinct.
Do I need a custom portal to start?
Start with the actual product workflow and one bounded decision. Build additional reporting only when it serves a defined need and is appropriately scoped.
Does passing the checklist prove revenue lift?
No. It establishes defined operational acceptance. Incremental commercial impact needs an appropriate measurement design and follow-up.
Watch the MarketPulse demo and compare current plans starting at $500/mo before choosing a scope.
Reviewed and updated October 3, 2026.
Written by
