Tracking health

A list of tracked sales looks the same whether it’s missing 2% of them or 20%. Admin → Tracking health shows the gaps instead: where partner clicks stop on their way to becoming customers, which browsers lose them, which of your Stripe payments should have credited a partner but were never recorded, why a conversion credited nobody, what OpenPartner received but had to drop, and which partner codes bring customers who hadn’t clicked the partner’s link.

Almost every number is worked out from your raw click, landing, customer and conversion records each time the page loads, so it always matches them. The two exceptions: dropped input is counted as it happens, and the Stripe revenue section is kept for ten minutes after it’s read.

Pick a window (the last 7, 30 or 90 days) and, if you run more than one program, one program or All programs. The program choice applies to the click funnel, the browser breakdown, Coupon took credit from a link and Partner codes. The other sections always cover your whole workspace, as noted below.

Partner link clicks

The window’s clicks on partner links, and how far they got. Clicks flagged as fraud and clicks from bots are counted separately and left out. Coupon redemptions aren’t counted here, because nobody clicked them.

Stage	Means	Comes from
Clicks	Real visitors who clicked a partner link.	The click router.
Landed	The click reached a page running the OpenPartner script.	The SDK’s landing report.
Stitched	The click was linked to a customer.	`identify()` at signup or login, a Stripe checkout that carried the click, or a conversion reported by click id.
Credited	The click earned at least one conversion.	Attribution.

Each stage is a share of the window’s real clicks.

Landed reads Not measured until the first landing report arrives. It needs the script tag your portal serves, or @openpartner/sdk 0.3.0 or later, on the pages partner links send visitors to. A link whose destination is a Stripe Payment Link sends the visitor straight to Stripe, so its clicks never land, by design.

When fewer than 70% of clicks land, the page says so. The usual causes:

a redirect on the landing page drops ?cref= from the URL;
the destination page doesn’t carry the script tag;
a consent banner holds the script back (data-consent="pending") and the visitor never answered it.

Stripe revenue

With your Stripe account connected through the Stripe App (beta), this section puts your own Stripe revenue next to what OpenPartner recorded from it and credited to partners, payment by payment.

It reads the two kinds of payment OpenPartner records revenue from: paid invoices (subscriptions and other invoices) and paid one-time Checkout payments, created in the window. Every payment counts in In Stripe, and then in one of Recorded, Missed sales, Not creditable or No partner signal:

Column	Means
In Stripe	Every such payment, gross (before refunds).
Recorded	OpenPartner recorded it.
Credited to partners	The part of Recorded that was credited to a partner.
Missed sales	Not recorded, and it would have credited a partner if it had been.
Not creditable	Not recorded. It carries a partner signal, but that signal wouldn’t have credited anyone.
No partner signal	Not recorded, and nothing ties it to a partner. Usually a customer who came on their own.

A partner signal is one of: the customer is linked to a partner click made before the payment, the Checkout’s client_reference_id is one of your partner clicks, or the payment used a partner’s code.

Whether a signal would have credited a partner is decided the way attribution would have decided the payment if its webhook had arrived when it was paid (an invoice’s paid time; a Checkout’s creation, since Stripe doesn’t record when a Checkout completed). The payment is judged for the customer it would be recorded under: the openpartner_user_id on the Stripe customer, or else the Stripe customer id. It credits a partner through:

a click inside its program’s attribution window, not flagged as fraud, from a partner who isn’t revoked (flags and revocations as they are now);
or an earlier credited conversion of the same customer, which carries the payment the way it carries a renewal, unless that program lets renewals go.

A partner code still active at the time of the payment counts as a click at that moment. If the customer already had a click from that partner, the code uses that click instead, however old it is, just as a recorded redemption would.

Not creditable payments are counted by why, in the line under the table:

Why	Means
outside the window	There are usable partner clicks (not flagged, partner not revoked), but all are older than their program’s window, and no earlier credited conversion carries the payment.
with a code deactivated before the payment	No usable click, and a partner code on the payment was deactivated before it was used.
with only flagged clicks or revoked partners	No usable click: the clicks are flagged as fraud or belong to revoked partners.

These aren’t leaks: recorded, they’d have credited nobody.

Missed sales is the number to watch. The most recent (up to 50) are listed with what tied each one to a partner and a link to it in your Stripe dashboard. Possible causes are a webhook that never arrived (check the event’s delivery history in Stripe) or a payment OpenPartner couldn’t map to a customer or click. A missed sale is about credit, not commission: once recorded, the program’s commission rules still apply.

So the numbers mean what you think they mean:

Totals are per currency, your default currency first, and are never added across currencies.
A Checkout that created an invoice counts once, as that invoice.
Partner codes are matched by Stripe id, not by their text: the promotion code recorded for a partner’s code, or the Stripe coupon behind it, on the invoice, a line item or the Checkout. A promotion of your own with the same wording doesn’t match, unless it uses the partner code’s Stripe coupon.
Payments your backend charges directly (a PaymentIntent outside invoices and Checkout) aren’t read. Report those with the conversions API.
Up to 2,000 invoices and 2,000 Checkout payments are read per window. The page says when there were more.
It’s read from Stripe when the page loads and kept for ten minutes. Read again fetches it fresh. Nothing is stored.

It covers your whole Stripe account, whichever program you picked.

The connection needs to read invoices, Checkout Sessions and customers. If Stripe isn’t connected, needs reconnecting, or your connection doesn’t grant those, the section says so and links to Integrations.

By browser

The same funnel, split by browser and device. A row is highlighted when it has at least 20 clicks and stitches at under 60% of your overall stitch rate. That’s where clicks are being lost between the visit and the signup.

A highlight is a reason to look, not proof of a tracking fault: some traffic signs up less anyway. But when the same campaign’s visitors stitch fine in Chrome and badly in one other browser, the browser is the first suspect. Two common causes:

Safari deletes what a site’s scripts stored after 7 days without a visit. A visitor who clicks a partner link and comes back two weeks later to sign up can arrive without the click. Set the referral cookie from your own server, which Safari doesn’t cap that way, and call identify() as early as you can.
In-app browsers (Instagram, TikTok, Facebook) keep storage of their own, separate from the phone’s main browser. A visitor who taps a link inside the app and buys later in their usual browser arrives without the click. Only something that happens inside the in-app browser carries it across, such as an email capture or an account created there, or a partner code, which doesn’t depend on any browser.

Conversions that credited nobody

The window’s conversions that credited no partner, grouped by the first reason the attribution engine stopped at. Refunds and disputes are left out: they’re never credited, by design.

Reason	Means
No partner click on record	The customer was never linked to a partner click. Every customer who came without a partner is here too, so this is the most that could be missing, not what is.
Only excluded clicks	Every click behind the customer is flagged as fraud or belongs to a revoked partner.
Click outside the window	None of the customer’s usable partner clicks falls inside its program’s attribution window: they’re all older than the window, or came more than five minutes after the conversion.
Recorded before the click was linked	The customer is linked to a usable click inside the window, and the conversion still has no credit. A common cause: the conversion arrived before the click was linked, and the call that linked it (a conversion by click id sent with your own `userId`) credits only its own conversion.

To keep the last one from happening, link the click before the conversions arrive: call identify() at signup or login (or POST /attribution/identify from your server). An identify that links a click to a customer for the first time also credits conversions already recorded for them. One for a click and customer that are already linked changes nothing.

This section always covers your whole workspace: a conversion belongs to no program until it’s credited.

Dropped by OpenPartner

Input OpenPartner had to reject, counted per day. Each count is a reference or request it couldn’t match, and a retry counts again, so these aren’t counts of lost conversions. They’re signs that some conversions may be losing their partner. Some still get credited another way, such as through a partner code. The latest value it saw is shown, so you can recognise your own typo.

What	Usual cause
identify() named an unknown click	The click isn’t one of this workspace’s. Usually the script tag’s `data-api-url` (or the SDK’s `apiUrl`) points at another workspace. Copy the tag from Admin → Integrations again.
Landing report named an unknown click	The same.
Conversion or postback named an unknown click	The sender passes something other than the `{click_id}` it received, or a click from another workspace.
Stripe checkout carried an unknown click	`client_reference_id` looks like a click id but isn’t one of this workspace’s: a stale link, or another workspace’s script on the page.
Stripe checkout carried your own reference	Your Checkout Sessions put your own order or user id in `client_reference_id`, so partner clicks can’t ride on it. Pass the referral there instead (see the `op_ref` cookie), or link customers to your users with `openpartner_user_id` metadata.
Coupon redemption with an unknown code	`POST /coupons/redeem` got a code no partner holds, such as a typo.

Clicks belong to a workspace, not to a program, so these counts cover the whole workspace. They stay on the deployment that recorded them and aren’t part of an export.

Credit decisions

Coupon took credit from a link. Conversions credited to a coupon code’s partner while another partner, whose link click was inside the window (not flagged as fraud, the partner not revoked), got nothing. Under last click, the code entered at checkout is usually the customer’s most recent touch, so it wins. A split that credits both partners isn’t counted. To let the link win instead, turn on Partner links beat coupon codes for the code’s program.
Stripe events recovered. With Stripe connected through the Stripe App (beta), OpenPartner checks your Stripe account every six hours for the kinds of event it records, from up to the last 72 hours (never from before you connected, and leaving the most recent hour to webhooks still on their way), and processes any that no webhook delivered, the same way a webhook would. Each run has limits, and what’s left is picked up by the next run while it’s still inside the 72 hours. This counts the Stripe events that were recorded this way in the window. Anything above zero means webhook deliveries are failing: check your webhook’s delivery history in Stripe. The catch-up runs only on Stripe App connections, and the count covers your whole workspace.

Partner codes

For each partner credited through a coupon code in the window: the customers credited to them, and how many of those came through the partner’s code with no click on the partner’s own link before buying (Code, no click of theirs; a click flagged as fraud doesn’t count). It counts customers, not conversions, so a customer’s renewals count once. Only partners with a code-credited conversion are listed, the most clickless customers first, up to 20.

A partner’s share is highlighted when 5 or more of their customers, and at least 80% of all the customers credited to them, came through the code alone. A code that brings almost nobody through the partner’s own link may have spread beyond their audience, to a coupon site or a browser extension. For a podcast or a video read, where people type the code they heard, a high share is normal. Tracking is working either way: this is about whether the credit is deserved. To let a link click win over a code, see Partner links beat coupon codes.

Last received

The latest of each kind of signal OpenPartner has on record: a partner link click, a click’s first landing, a new stitch (a click linked to a customer), an event recorded from Stripe (dated by Stripe), and a use of your current postback URL. Never means there’s no such record yet. Next to one you rely on, check that integration. These cover your whole workspace.

What it can’t see

A sale that left no trace at all: no click kept in the browser or by your server, no linked account, no partner code. No tracking tool can credit those. What this page shows are the common places where a trace starts and then stops, which is where the fixable losses are.