Overview
When a number doesn’t look right, it can be frustrating — especially when you’re not sure why it’s happening or where to start. The good news is that most metric issues come from a small set of common causes, and Polar gives you the tools to track them down.
In this article, we’ll show you a simple, repeatable way to troubleshoot metrics using Custom Tables. Custom Tables let you look at the raw data behind your dashboards so you can:
See exactly which records are included in a metric
Rebuild a metric step by step
Find where a mismatch or discrepancy starts
By the end, you’ll know how to confidently answer the question: “Why does this number look wrong?”
Section 1: Start With the Basics — What Is This Metric Actually Counting?
Before opening a Custom Table, it helps to be clear on what the metric is based on.
Step 1 — Identify the “building block” of the metric
Every metric is built from something more basic, like:
Revenue → orders, payments, or invoice line items
Orders → order records
AOV → revenue divided by orders
New customers → customers with their first purchase in a date range
Refunds → refund or adjustment records
Think of this as the unit the metric is counting or summing.
👉 Tip: It’s almost always easiest to debug metrics at the most detailed level (for example, orders instead of daily totals).
Section 2: Create a Debug Custom Table
Step 2 — Build a Custom Table just for debugging
Go to Custom Tables
Click Create table
Choose the dataset that matches your metric’s building block
For revenue issues, start with Orders
Give it a clear name like:
Debug – Revenue (Orders) or Debug – New Customers
This table is your “source of truth” while troubleshooting.
Step 3 — Add columns that help explain the number
Start by adding a few key columns so you can easily compare and trace records.
Always include:
ID (order ID, customer ID, etc.)
Created date
Status (paid, refunded, canceled, etc.)
Currency
Amount fields (gross, net, discount, refund — whatever applies)
Often helpful:
Marketing source or channel
Product or SKU
Customer type (new vs returning)
Refund or adjustment fields
Tags or flags you use in filters
These extra columns make it much easier to spot patterns or outliers.
Section 3: Check Your Dates and Filters Carefully
Step 4 — Use a “safe” date range
When debugging, always start with a closed time period, like:
Last week
Last month
A specific day that’s already complete
Avoid “Today” or “Yesterday” until you’re confident the logic is right.
Also double-check which date field you’re using:
Order created date
Order paid date
Charge captured date
💡 Helpful trick:
If you’re unsure which date matters, create two tables using different date fields and compare the results. Differences here often explain the issue immediately.
Section 4: Rebuild the Metric Step by Step
Step 5 — Recreate the metric inside the table
Now you’ll rebuild the metric using the table data, one piece at a time.
Example: Debugging Net Sales
Add columns for:
Gross sales
Discounts
Refunds
Calculate:
Net Sales = Gross – Discounts – Refunds
Compare:
The total from your Custom Table
The total shown in your dashboard
If they don’t match, you now know the issue is inside the logic — not the data itself.
Example: Debugging Orders
Add Order ID and Status
Filter to the statuses you expect (usually “paid”)
Count unique Order IDs
Compare that number to the dashboard
Most order mismatches come from status filters.
Example: Debugging New Customers
Start from customers or orders
Add:
Customer ID
First order date
Order date
Filter to customers whose first order falls in your date range
Count unique customers
Different tools often define “new” slightly differently, so this step is key.
Section 5: Find Exactly Where Things Break
Step 6 — Narrow it down until the mismatch appears
If totals still don’t match, break things down:
Compare totals by day
Find the first day that looks different
For that day, group by:
Status
Channel
Product
Look at the individual records (IDs)
This approach quickly shows which records are missing, duplicated, or categorized differently.
Section 6: Common Issues (and What They Usually Mean)
Revenue is higher than expected
Order totals are being counted multiple times
Line items are inflating totals
✔️ Fix: Make sure you’re not summing order totals at the line-item level
Revenue is lower than expected
Missing statuses (e.g., only “fulfilled” included)
Refund timing differences
✔️ Fix: Align status and refund logic with your definition
Orders don’t match Shopify or Stripe
Different date fields
Pending or canceled orders included/excluded
✔️ Fix: Compare order IDs for the first mismatching day
New customer counts are off
Different “first purchase” definitions
Refunds or cancellations affecting logic
✔️ Fix: Confirm how “new” is defined and applied
Conclusion
Custom Tables make troubleshooting much less intimidating by letting you see — and rebuild — exactly how a metric is calculated.
A simple checklist to remember:
Identify what the metric is based on
Create a dedicated debug Custom Table
Add IDs, dates, statuses, and amounts
Use a closed date range
Rebuild the metric step by step
Break it down until the mismatch appears
Once you find the cause, fixing the metric is usually straightforward.
Still Need Help?
If you’re unsure how your raw data is pulling into Polar, or if you’d like assistance with Custom Table, reach out via our in-app live chat—our Support Team will be happy to help.