Skip to main content
Metrics type: Key MetricsCategory: Ecommerce Platform

At a glance

Percentage of customer accounts whose email address has not been verified. Unverified emails reduce deliverability and increase fraud risk. An unverified email may be a typo, a temporary inbox, a fraud vector, or a legitimate signup that simply skipped verification. The card surfaces the share of the customer base operating in this gray zone, high values typically signal signup-flow issues, mass-bot signups, or guest checkout customers being created as accounts without follow-through.

Calculation

For BC stores using guest checkout heavily, guest customers are typically counted as unverified by default unless they explicitly verified the email post-purchase.

Worked example

A UK-based BigCommerce home-and-garden store, customer health reading on Wednesday 15 May 26. Unverified email: 46.6% (well above the BAD threshold of 30%). Card flags as Action Needed in red. What the customer health reading is telling us:
  1. The majority of customer accounts are unverified. 46K out of 100K accounts have not verified their email. At this scale, the implications are: (a) email campaigns sent to unverified addresses will bounce at elevated rates damaging deliverability, (b) the 100K headline customer count overstates the addressable base by roughly 2x, (c) ESPs are billing for storage of contacts that may not even be reachable.
  2. Likely root causes for 46% unverified rate:
    • Guest checkout creating customer records: BC, by default, can create customer accounts for guest checkouts. These customers never received a verification email because the flow doesn’t trigger one.
    • Verification email not being sent: a misconfigured ESP integration or transactional email failure means signup confirmations never reach the customer.
    • Verification step skippable: BC’s signup flow may not enforce verification before account becomes “active”, letting unverified accounts accumulate.
    • Bot signups: at this rate, some portion is likely automated promotional-code-abuse bots; check signup IP patterns.
  3. The deliverability angle (highest-value remediation).
    • Sending to 46K unverified addresses with marketing campaigns will produce 5-15% bounce rate.
    • Bounce rate above 5% damages sender reputation at major mailbox providers (Gmail, Outlook, Yahoo).
    • Recovery from damaged sender reputation takes 3-6 months of careful sending, throttled volume, and engagement-only campaigns.
    • The fastest way to protect deliverability: suppress unverified addresses from marketing sends until they verify (re-engagement campaign or transactional opportunity).
  4. The fraud and metric-skew angle. A 46% unverified rate inflates the denominator on the customer base. Ratios like “conversion rate from registered users” are artificially low because half the registered users are not real. Filter to verified-only when computing customer-engagement KPIs to get the operational truth.
  5. Recommended response, in priority order:
    • Day 1: Audit signup flow for verification step. If verification is optional, make it required for marketing eligibility (not for purchase).
    • Day 2-3: Run a re-verification campaign: send a single transactional re-prompt to all unverified accounts asking them to confirm. Expected 10-25% verify rate.
    • Day 4-5: Suppress non-responders from marketing sends.
    • Week 2: Add verification logic to checkout flow so guest-checkout accounts trigger verification on first purchase confirmation.
    • Week 3: Cleanse list, delete or anonymise unverified accounts older than 12 months with no purchase history.
    • Result: unverified % drops from 46.6% to 15-20% over 4-6 weeks; deliverability protected; CRM cost reduced.
  6. Cross-reference cards:
    • email_health (coverage): customers with valid email captured at all.
    • email_bounce_rate: downstream effect of sending to unverified.
    • klv_bounce_rate, mc_alert_deliverability_drop: ESP-side deliverability signals.
    • zero_spend: registered customers who never purchased; overlap with unverified.
The diagnostic flow:
  1. Read unverified %. Above 10% warrants action; above 30% alert.
  2. Audit signup flow for verification gap.
  3. Run re-verification campaign; suppress non-responders from marketing.
  4. Cleanse old unverified accounts.
  5. Re-measure at 30D and 60D to confirm trend reversed.
Rapid-response playbook:

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Where to look in BC: Customers → Customer list with “verified” filter; Settings → Email → Verification policy. Why our number may differ: Cross-connector: complement with klv_*, mc_* (ESP-side health) for the deliverability story. Quick rule: check verification-flag interpretation and bot-detection setting first.

Known limitations / merchant FAQs

Q: Our unverified rate is 47%. Should we delete those customers? Not without a re-engagement attempt first. Run a single re-verification email; expect 10-25% to confirm. Then suppress the non-responders from marketing sends but keep the records (unless GDPR/data-minimisation policy requires deletion). Outright deletion loses recoverable signal and may breach data retention rules unintentionally. Q: Guest checkout creates customer records, should those count? Configurable per profile. Default behaviour: guest checkouts that create customer accounts (a BC option) are counted as unverified until the customer follows through. Many merchants prefer to exclude guest-only accounts from the metric since they were never offered a verification step. Q: We just imported 50K accounts from a previous platform. Most are unverified. Why? Imports from another platform typically don’t carry verification status, so all imported records start as unverified in BC. Run a re-verification campaign to the imported list, suppress non-responders. Recovery is possible but requires careful rate-limited sending to avoid sender-reputation damage. Q: Verification damages signup conversion. Why bother? The trade-off is real but the math is one-sided over time. Friction in signup costs ~5-15% of conversions. Lifetime deliverability damage from sending to unverified addresses costs 30-50% of email-driven revenue across a 12-month horizon. Verification at signup is a small short-term cost for a large long-term benefit. Q: We use double opt-in for newsletter only, not for customer accounts. Is that enough? Better than nothing, not enough. Customer accounts that are never verified still count toward your contact base if you sync the entire customer list to the ESP. Either (a) only sync newsletter-opted-in records to the ESP, (b) require verification for all account types, or (c) maintain a separate “verified contacts” list that the ESP draws from. Q: We see 0% unverified, is that real? Possible if your store enforces verification before account creation completes (rare in BC default config). More likely: the verification flag is being treated as universally true when it shouldn’t be. Audit the customer record schema and confirm the flag is actually being set per customer. Q: How does this card differ from email_health? email_health measures whether you have an email at all (coverage). This card measures whether the email is verified (quality). A customer with email_health = true but email_verified = false has provided an address that may or may not be deliverable. Both matter, separately. Q: Do unverified accounts hurt SEO or organic traffic? Indirectly. Bot-signup accounts can pollute your A/B test data, distort customer segmentation, and waste resources, but they don’t directly affect SEO or organic traffic. The damage is on email deliverability, fraud exposure, and analytics quality.

Tracked live in Vortex IQ Nerve Centre

Unverified Emails is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.