Merchant Onboarding API Best Practices: Reduce Friction and Accelerate Revenue

A well-designed merchant onboarding API does more than collect forms. It determines how quickly a platform can activate a seller, how confidently a risk team can approve an account, and how efficiently operations can scale without creating compliance debt. For platforms, acquirers, and investors, onboarding is the first place where product UX, underwriting, and regulatory controls either work together or fight each other. If the workflow is too strict, conversion drops; if it is too loose, fraud, chargebacks, and remediation costs rise later.

The strongest onboarding systems are built like production infrastructure: modular, observable, policy-driven, and resilient to edge cases. That means treating KYC, AML, sanctions, identity verification, business verification, device risk, and payment configuration as coordinated services rather than a single monolithic form. If you are also comparing providers, the same design choices often show up in a payment gateway comparison, where webhook quality, event consistency, and integration ergonomics can matter as much as headline pricing. The goal is not only to reduce abandonment, but to create a compliant path to revenue that remains maintainable as volumes grow.

Pro Tip: The fastest onboarding flow is not the shortest form. It is the flow that asks only for the minimum data needed to make the next safe decision, then defers everything else to progressive verification.

1) What Merchant Onboarding APIs Actually Need to Do

1.1 Convert applicants without sacrificing control

The core job of a merchant onboarding API is to transform an applicant into an approved, risk-scored, and operationally ready merchant with as little friction as possible. That sounds simple, but in practice the API must coordinate multiple stages: identity capture, document collection, business verification, beneficial ownership checks, watchlist screening, underwriting, and payment configuration. Each stage has different latency, data quality, and failure modes, which is why many teams struggle when they try to force everything into a single synchronous request. A better model is to separate application intake from decisioning.

This separation makes the API more forgiving and more scalable. Your frontend or partner platform can accept the initial submission quickly, create an application record, and then process asynchronous checks in the background. This approach mirrors the pattern used in reliable webhook architectures for payment event delivery, where the system must communicate outcomes without assuming every downstream dependency is ready at once. In onboarding, the result is lower abandonment, less retry confusion, and a cleaner audit trail for regulators and internal reviewers.

1.2 Support multiple approval paths, not one generic funnel

Not every merchant should follow the same path. A low-risk domestic retailer, a high-volume marketplace seller, and a cross-border crypto-enabled platform each create different compliance and fraud exposures. A mature onboarding API therefore needs policy routing: the requested payment rails, MCC category, geography, expected average ticket, and business model should determine the depth of checks. This is where many vendors differ in practice, and it is why a thoughtful fintech product strategy matters before a single line of code is shipped.

From an investor due diligence perspective, the presence of explicit routing logic is a positive signal. It suggests the company understands underwriting economics and can control loss rates by segment. It also indicates the onboarding stack is built to absorb growth without exploding manual review headcount. If a provider cannot explain how it routes higher-risk applications into escalations, that is often a sign the platform relies on ad hoc analyst judgment rather than codified policy.

1.3 Design for reversibility and remediation

Real onboarding is messy. Documents expire, legal names differ across registries, beneficial owners change, and business activity evolves after launch. That means your API must support state transitions, not just one-way approval. A merchant may be provisionally approved, placed into limited mode, or sent back for supplemental data. Good systems allow a merchant to correct a single field or upload one missing file without restarting the entire process.

This is where product teams can borrow from the logic of micro-feature tutorials that drive micro-conversions. Instead of overwhelming users with every possible requirement up front, break the experience into guided moments. That makes the process feel manageable and gives support teams clearer checkpoints to troubleshoot. More importantly, it creates an auditable sequence of decisions, which is invaluable when compliance teams need to explain why a merchant was approved, delayed, or rejected.

2) The Data Model: Fields, Evidence, and Decision Signals

2.1 Collect only the fields you can justify

One of the most common onboarding mistakes is asking for too much information too early. Every additional field increases abandonment, but not every field adds equal risk value. The correct approach is to define a minimum viable decision set for each business model and geography. In many cases, the first step should only require legal entity name, country of incorporation, tax ID, business website, contact details, beneficial ownership threshold data, and a clear description of goods or services.

Then, based on risk scores, request supplementary data such as bank statements, processing history, invoices, refund policy, fulfillment proof, or licensing documents. This “ask later if needed” model is more effective than demanding a full document pack from every merchant. It also aligns with modern integration best practices, because APIs can return a structured list of missing or required next-step attributes instead of a vague error code. For teams focused on operational efficiency, the idea is similar to the principles in the automation-first blueprint: automate the routine path and reserve human review for anomalies.

2.2 Separate identity evidence from business evidence

KYC and KYB are often treated as one lump, but they solve different problems. Identity evidence tells you whether a person is who they claim to be; business evidence tells you whether the entity exists, is active, and is eligible for the activity it wants to perform. For merchants, especially in marketplaces and platforms, business evidence often matters more than personal identity alone. A strong onboarding API should therefore have different object types for person, business, owner, director, and document evidence.

This design improves data integrity and makes downstream screening more flexible. If the system stores beneficial owners separately from the business entity, you can re-run checks when ownership changes without re-collecting the entire application. It also helps with reconciliation later, because each approved merchant account can be traced back to a unique evidence set. That matters for internal audit teams and for investors evaluating operational durability.

2.3 Make every field decision-relevant

When a field is captured, the API should know why it exists and what decision it affects. Does an average ticket value change reserve policy? Does a bank country influence settlement timing? Does a website category affect prohibited-business screening? The best onboarding systems attach each input to one or more decision rules, so the data model is not just a form schema but a policy engine.

A useful analogy comes from automating signed acknowledgements for analytics distribution pipelines, where each handoff must be tied to an explicit acceptance or authorization event. In merchant onboarding, the equivalent is a field-to-policy mapping that survives audits and prevents “mystery requirements” from creeping into the product. If a support agent asks for a document not tied to a policy rule, that request should be visible as a process exception, not normal behavior.

3) KYC/AML Automation Without Creating False Confidence

3.1 Automate first-pass screening, not final judgment

KYC automation is one of the biggest levers for reducing time-to-revenue, but it is also one of the easiest places to overpromise. Automated checks should handle identity validation, sanctions screening, adverse media, business registry lookups, and owner matching at scale. However, the API should distinguish between deterministic outcomes and probabilistic ones. A watchlist hit, a mismatched registration number, or a high-risk jurisdiction may be actionable immediately; a fuzzy name match should usually trigger review rather than rejection.

This distinction keeps false positives from choking the funnel and prevents your operations team from drowning in manual exceptions. It also creates a clearer product promise for customers, who need to understand what is automated and what remains subject to human review. Teams that understand uncertainty well often perform better in adjacent domains too, as seen in risk analysis and prompt design: ask what the system can verify, not what you wish it could infer.

3.2 Use risk bands, not binary decisions

Binary approve/decline logic is too blunt for most payment businesses. A merchant may be safe enough to activate on a low processing limit, but not yet safe for instant settlement or cross-border volume. The better pattern is to define risk bands that control product entitlements: tier 0 for instant activation with low limits, tier 1 for standard processing, tier 2 for reserve requirements and enhanced monitoring, and tier 3 for manual underwriting or rejection.

This is especially useful for platforms that must scale quickly while protecting margin. Risk bands can also drive user experience: lower-risk applicants move through a lighter flow, while higher-risk applicants see clearer explanations and more granular evidence requests. The same concept is visible in other operational domains such as embedding governance in AI products, where access and behavior are controlled by policy layers rather than by one coarse gate.

3.3 Maintain a full audit trail of decisions and overrides

Any onboarding API used in regulated payments should emit a decision log for every state change. That log should include who or what made the decision, the rule or model version in force, the inputs considered, timestamps, and any manual overrides. Without this, compliance teams cannot explain outcomes, engineering teams cannot debug discrepancies, and investors cannot assess whether the onboarding stack is mature enough to support scale.

Auditability also helps with model governance and vendor management. If you use third-party KYC or AML services, store their response codes and confidence levels, not just the final outcome. Otherwise, you will not know whether a spike in declines came from a vendor outage, a bad rules update, or a new fraud pattern. Teams that build for traceability tend to ship more safely, much like organizations that plan for tech debt as a growth issue rather than an afterthought.

4) UX Patterns That Reduce Drop-Off Without Weakening Controls

4.1 Progressive disclosure beats long forms

Merchant onboarding fails when the user feels trapped in a compliance maze. Progressive disclosure solves this by presenting only what is necessary at the current stage, then revealing additional steps when the data or risk score warrants it. For example, you might begin with business basics, then ask for owner information only after the business entity passes initial validation. If the merchant is low-risk and domestic, you may not need bank account details until after approval.

This approach lowers cognitive load and gives the user a sense of momentum. It also reduces rage quits, because every screen feels purposeful. The best experience is one where the user always knows why they are being asked for something, how long it should take, and what happens next. That level of clarity mirrors the logic of micro-feature tutorial production, where tiny instructional moments perform better than one long lecture.

4.2 Show progress, not just validation

Validation messages are necessary, but they are not enough. A merchant should see a clear timeline: submitted, verifying business, screening owners, reviewing payout setup, approved for limited processing, and fully activated. When the system is asynchronous, status transparency reduces support tickets because users do not need to guess whether the process is still running or silently failed. The status model should also indicate which steps are completed automatically and which are pending manual review.

That transparency is especially important for marketplaces and platforms that onboard thousands of sellers. If the interface hides internal complexity, the support burden shifts to human agents answering “is my application stuck?” messages. If the interface explains the state machine well, support can focus on genuine exceptions rather than status checking. Strong operational storytelling can be as important as technical architecture, similar to how product launch coverage frames expectations before a major rollout.

4.3 Design for recovery, not just first-pass success

Some applicants will fail a step because of a typo, a document scan issue, or a temporary provider outage. Great onboarding UX lets them recover quickly. That means preserving partial data, allowing re-upload of specific documents, and clearly indicating what was rejected and why. It also means sending actionable remediation instructions rather than generic messages like “verification failed.”

The business impact is real. Recovery-friendly UX can convert would-be support escalations into self-serve completions, reducing cost per activation and improving the perception of your platform. In investor diligence, this often shows up as a better activation funnel and lower operational overhead. The more structured the remediation path, the easier it is to support growth without ballooning service costs.

5) Risk Screening, Fraud Prevention, and Chargeback Readiness

5.1 Onboarding is the first fraud-control layer

Many teams think fraud prevention begins after the first transaction. In reality, onboarding is where you prevent entire classes of bad actors from entering the system. Device intelligence, IP geolocation, email reputation, domain age, website content analysis, and mismatch checks between stated business type and observed website behavior all add useful signals. If those signals are exposed through the API, they can be used to route applications into different review paths or product limits.

This matters because fraud often appears as a business model mismatch: a merchant claims to sell digital goods but the site is blank, or it claims to be local but the founders and bank account are elsewhere. Early screening is not just about blocking criminals; it is about catching operationally unsafe merchants before they become expensive chargeback problems. For teams looking at downstream economics, it is also wise to study event-driven payment reliability, because the same observability principles apply to risk events.

5.2 Build controls that anticipate chargebacks

Chargeback prevention should influence onboarding policy directly. If a merchant sells high-dispute goods, uses subscription billing, or has unusually high refunds, that profile should trigger additional checks, explicit descriptor guidance, and reserve policy evaluation. Better onboarding APIs can also attach a risk score to expected dispute exposure, which then informs midstream monitoring and payout timing. This creates a more defensible risk model than relying on post-transaction monitoring alone.

In practice, you want your onboarding data to feed transaction analytics from day one. If the merchant later generates elevated chargebacks, the underwriting team should be able to compare the original onboarding profile with observed transaction behavior. That helps identify whether the problem was fraudulent misrepresentation, a category-specific risk spike, or weak controls in the merchant’s own checkout flow. The more complete your baseline, the more useful your payment event data becomes for loss prevention.

5.3 Use negative signals carefully

It is tempting to decline any applicant with red flags, but some negative signals are noisy and context-dependent. A newly registered domain is not automatically fraudulent; a web-only business is not automatically risky; a foreign founder is not a reason to decline. Good onboarding systems score these signals rather than hard-coding bias into the process. That protects conversion and reduces the chance of rejecting legitimate merchants who could become strong long-term accounts.

The best practice is to combine signals into explainable policies. For example, a new domain plus mismatched legal entity name plus high-risk product category may justify manual review, while any one of those factors alone may not. Explainability is especially important when the onboarding team must justify decisions to partners, auditors, or internal credit committees. Mature organizations usually encode this in the same discipline they use for governance controls elsewhere in the stack.

6) Integration Best Practices for Platforms and Acquirers

6.1 Make the API idempotent and event-driven

Onboarding flows often suffer from duplicate submissions, retry storms, and state mismatches. The API must therefore be idempotent for create and update actions, especially when partner platforms or embedded finance products are involved. Every request should carry a stable merchant/application identifier and support safe retries without creating duplicate applications or double-verification charges. Event-driven callbacks should notify partners when a state change occurs, rather than forcing constant polling.

This is where implementation discipline matters. If the API emits rich status events, partner systems can update dashboards, allocate support work, and trigger downstream configuration only when the merchant is actually ready. The pattern is closely related to designing reliable webhook architectures, which is essential for payment APIs of any kind. When the integration contract is clear, technical teams spend less time debugging “where did the request go?” and more time improving activation.

6.2 Version your onboarding policy separately from your API

One of the most underappreciated mistakes is shipping policy changes as invisible backend edits. If your rules change and the same payload now yields a different decision, partners will experience unpredictable behavior and support becomes nearly impossible. Instead, version your policy engine independently. The API should expose policy version, rule set, and decision reason codes so that partners can trace why an application was handled the way it was.

This helps with experimentation as well. You can test different approval thresholds, document requests, or screen order sequences without breaking integration contracts. Versioning is also essential for investor diligence because it shows the company can evolve controls without destabilizing the platform. In operational terms, it is the difference between a business with a configurable underwriting engine and one with a brittle hard-coded workflow.

6.3 Document developer workflows like a product, not a PDF dump

Many onboarding integrations fail because the documentation is too shallow, too stale, or too abstract. Developers need quick-start payload examples, error catalogs, sample webhook events, test/sandbox walkthroughs, and clear mapping between API fields and compliance outcomes. A strong onboarding program treats docs as a living part of the product. That means including annotated examples, recovery paths, and specific edge cases like beneficial owner changes, partial verification, and re-review after bank account updates.

Good docs can materially reduce integration time and support load. They also make it easier for channels, ISVs, and embedded finance partners to implement the flow correctly on the first try. If you want a useful model for structured technical writing, the discipline described in developer documentation for complex SDKs applies surprisingly well here: clear templates, example-driven guidance, and realistic error handling matter more than jargon-heavy completeness.

7) Fees, Economics, and Revenue Acceleration

7.1 Onboarding speed affects revenue recognition

Every extra day between application and activation delays processing volume, interchange revenue, and ancillary product adoption. For platforms, that delay also affects seller trust and partner NPS. A streamlined onboarding API creates economic value by reducing time-to-first-transaction and improving conversion from application to active account. This is especially relevant when comparing providers with different fee stacks, because faster activation can offset slightly higher nominal pricing if it produces higher net volume.

That is why merchant onboarding should be analyzed alongside narrative arbitrage style market thinking in investor conversations: not every optimization is visible in a unit-price comparison. A lower processing rate matters less if a merchant never makes it through onboarding, or if your ops team spends the savings on manual remediation. Revenue acceleration comes from the combination of fast approval, low abandonment, and controlled risk.

7.2 Measure the hidden cost of manual review

Manual review is not free. It consumes analyst time, increases queue latency, and often creates inconsistent decisions if the playbook is unclear. The actual cost of manual review includes salary, QA, training, rework, support tickets, and lost conversion from waiting applicants. A mature onboarding API should therefore emit metrics such as median time to decision, percentage of applications requiring review, review queue age, and reasons for escalation.

Those metrics are central to building better KPI dashboards, because what you cannot measure you cannot manage. Teams often discover that a small number of incomplete applications cause a disproportionate share of review effort. Once that pattern is visible, product and compliance teams can simplify the flow or tighten upfront validation to eliminate avoidable work.

7.3 Align fee strategy with risk strategy

Merchant onboarding, fee pricing, and risk policy should be coordinated. If your platform charges higher fees for high-risk segments, onboarding should collect the data needed to classify those segments accurately. If you use reserves, tiered pricing, or delayed settlement, the application flow should set expectations early and clearly. Surprises after approval damage trust and can lead to churn, disputes, or partner escalation.

For comparison-minded buyers, this is why payment processor fees should never be evaluated without understanding the onboarding and control experience. A platform with slightly lower published fees but poor onboarding controls may produce more disputes, more manual work, and slower realization of revenue. The economically superior choice is often the one that delivers stable activation economics end-to-end.

8) Compliance Architecture: PCI, AML, Privacy, and Records

8.1 Treat compliance as a design constraint, not a final review step

Compliance teams should not be brought in only after the onboarding flow is built. PCI, AML, data retention, privacy, and recordkeeping requirements must be mapped into the architecture from the beginning. If your onboarding API receives cardholder data, avoid storing it unnecessarily and ensure the payment data path is segmented appropriately. If documents contain sensitive PII, define retention limits, access controls, and encryption standards before launch.

A practical PCI compliance checklist for onboarding includes data minimization, tokenization where possible, encrypted storage, strict access logging, vulnerability management, and vendor risk controls. The point is not to make the system compliance-heavy; it is to make it compliance-native. Teams that adopt this mindset often move faster, because they do not need to rework the stack every time a new jurisdiction or partner adds requirements. The same logic underlies governance by design in other regulated products.

8.2 Build for cross-border variation

Different jurisdictions require different fields, evidence, and screening thresholds. A merchant onboarding API should therefore be configurable by geography and entity type. Country-specific tax IDs, local beneficial ownership rules, license checks, and data residency considerations should be handled through policy configuration rather than code forks. If you have to maintain separate codebases for each market, your compliance cost will rise faster than your revenue.

Cross-border flexibility also matters for crypto and hybrid payment businesses. They often need sharper distinctions between fiat settlement, wallet funding, custody, and asset conversion flows. A robust onboarding model can support these differences with policy-driven schemas and reusable identity objects. This is one reason why platforms should think in terms of operating model design, not just API implementation.

8.3 Keep a defensible record of what was known at approval time

When a merchant later causes a loss event or regulatory issue, the question is not only what happened, but what the platform knew when it approved the account. Maintain immutable approval snapshots: submitted data, screening results, policy version, risk score, manual notes, and any special conditions. This allows your legal, risk, and finance teams to reconstruct the decision chain quickly and accurately.

That record also supports board and investor scrutiny. It demonstrates that the business has a repeatable underwriting process, not a collection of ad hoc exceptions. If growth equity or strategic acquirers are assessing the company, they will look closely at whether activation quality is traceable. Operational clarity often predicts better outcomes than a pure growth story.

9) A Practical Comparison Framework for Evaluating Merchant Onboarding APIs

9.1 Compare vendors on workflow depth, not just endpoints

When buyers evaluate merchant onboarding APIs, they often look at endpoint count, SDK language support, or marketing claims about “easy integration.” Those are table stakes. The real comparison should focus on the business workflow: identity capture, document handling, screening logic, state transitions, exception management, auditability, webhook reliability, and remediation support. A platform that exposes fewer endpoints but better decision orchestration may outperform a more expansive but fragmented competitor.

For a broader market evaluation, it helps to review adjacent categories like fintech productization and event delivery reliability. Those capabilities often determine whether your onboarding program scales safely. If you are buying for an enterprise platform, ask for sandbox evidence, sample payloads, decision logs, and policy versioning examples—not just a demo.

9.2 Use a structured scorecard

The table below is a practical way to compare onboarding APIs. It is not a vendor ranking; it is a framework for diligence. Score each dimension on how well it balances speed, compliance, and operational overhead. Then compare not only the product, but the operational burden of adopting it over the next 12 to 24 months.

9.3 Ask due diligence questions that expose maturity

For platforms and investors, the right diligence questions are revealing. Ask how the system handles policy changes mid-flight, how often manual review is needed, what percentage of applicants are provisionally approved, and how quickly a merchant can recover from a document failure. Also ask whether the company can prove that its onboarding policies reduced fraud or losses over time. If the answer is vague, the architecture is probably less mature than the pitch suggests.

It is also worth asking whether the business has a formal trust signal strategy. In regulated payments, saying “no” to risky behavior is often as important as saying “yes” to growth. A platform that is transparent about what it will and will not support usually earns stronger long-term enterprise confidence.

10) Implementation Roadmap: How to Build It Without Rebuilding It Later

10.1 Start with one policy, one flow, one country

Trying to launch every region, merchant type, and risk rule at once usually creates chaos. A better approach is to choose one market, one merchant segment, and one policy set, then instrument the funnel end-to-end. The initial build should include application intake, identity and business checks, manual review routing, webhook status updates, and a dashboard showing funnel drop-off and approval latency. This gives the team a real baseline before they introduce complexity.

Once the first flow is stable, expand by exception rather than by wholesale rewrite. Add new geographies, higher-risk verticals, and additional controls as separate policy modules. This is analogous to how automation-first operations grow in modular layers: standardize the repeatable path, then add controlled variation. By keeping the system composable, you reduce future rework and preserve velocity.

10.2 Instrument everything that affects conversion and risk

If you cannot see it, you cannot improve it. Track application start rate, completion rate, time in each verification stage, document rejection reasons, manual review rate, approval rate by segment, and post-activation loss indicators such as early chargebacks or refund spikes. Also track the specific data fields that create friction. That may reveal, for example, that beneficial ownership capture is causing most abandonment, not the overall length of the form.

These insights are the bridge between product and risk operations. They show where to simplify the UX, where to add inline help, and where to harden controls. They also help the finance team estimate true acquisition cost, because the cost of a merchant includes both sales effort and onboarding labor. In that sense, the onboarding API becomes part of the company’s unit economics engine, not just its compliance layer.

10.3 Keep the human exception path excellent

No matter how sophisticated the automation becomes, some cases will need manual judgment. The quality of that exception process often determines whether the platform feels enterprise-ready. Analysts should have a single console with all evidence, rule hits, notes, and suggested next actions. They should be able to request a missing file, approve with conditions, or reject with a documented reason in a few clicks.

This is where operational design pays off. When the exception path is fast and explainable, the business can safely automate more over time. That also improves support and partnership confidence because a “review” is no longer a black box. The system becomes a controlled funnel instead of a compliance bottleneck.

Conclusion: Build for Speed, But Engineer for Judgment

The best merchant onboarding APIs are not the fastest because they ask the fewest questions; they are the fastest because they ask the right questions, at the right time, with the right fallback paths. If you design for progressive verification, policy versioning, explainable risk bands, and resilient event delivery, you can reduce friction without weakening compliance. That is how platforms accelerate revenue while preserving the controls needed for sustainable growth.

For teams evaluating vendors or preparing for investor diligence, the key takeaway is simple: onboarding quality is a direct signal of product maturity. It reveals whether the company understands integration best practices, whether its transaction analytics are operationally useful, and whether it can control payment processor fees indirectly by reducing losses and manual overhead. In regulated payments, speed matters—but only when it is built on a system that can defend every decision.

The most common mistake is trying to make the API do everything synchronously. That creates slow response times, brittle integrations, and unnecessary abandonment. A better pattern is to separate application submission from background verification and final decisioning.

2) How do you balance KYC automation with compliance requirements?

Automate deterministic checks first, then route ambiguous cases to manual review. Use policy-driven risk bands, keep decision logs, and ensure every automated outcome can be explained after the fact. Automation should reduce work, not obscure judgment.

3) What data should be collected at onboarding?

Collect only what is needed to make the next safe decision: legal entity information, beneficial ownership, contact details, business description, tax identifiers, and any data required by geography or product type. Add supplemental evidence only when risk or regulation justifies it.

4) How should onboarding APIs support chargeback prevention?

They should feed underwriting with risk signals such as industry category, fulfillment model, website quality, refund policy, average ticket size, and historical processing experience. That data helps set appropriate limits, reserves, and monitoring thresholds before the first transaction.

5) What makes an onboarding API enterprise-ready?

Enterprise readiness usually means idempotency, versioned policy rules, strong webhook/event handling, audit trails, configurable risk routing, recovery-friendly UX, and good documentation. It also means the system can support multiple geographies and merchant types without major rework.

Related Reading

• Designing Reliable Webhook Architectures for Payment Event Delivery - Learn how resilient event delivery reduces state mismatches in payment workflows.
• Embedding Governance in AI Products: Technical Controls That Make Enterprises Trust Your Models - Useful for understanding policy versioning and explainable controls.
• Automating Signed Acknowledgements for Analytics Distribution Pipelines - A helpful analogy for audit trails and defensible handoffs.
• Crafting Developer Documentation for Quantum SDKs: Templates and Examples - Strong technical documentation patterns that also work for API onboarding.
• Build Better KPIs: Dashboard Metrics Every Parking Lift Operator Should Track - A practical framework for building operational dashboards and funnel metrics.