Revenue
Other Polar methods
On this page
If you create checkouts with the Polar API or checkout links, pass the visitor ID as in Connect Polar. For every other flow, the buyer's email links the payment to the visit.
Send the buyer's email from the browser
When you can't put the visitor ID in the checkout's custom data (a third-party storefront, a no-code tool, a mobile app or an older checkout), tell MetricRaven which email this visitor is paying with. A Polar payment with that customer email, made within an hour, is credited to the visit.
Connect Polar
Follow Connect Polar first: payments arrive through its webhook.
Call payment() after a successful payment
On the page buyers land on after paying, pass the email they paid with:
script.js// On the page buyers see after paying, with the email they paid with. window.metricraven.payment({ email: "customer@example.com" });Make the call safe before the script loads (recommended)
Add this to the page's
<head>, above other scripts. Calls made before the MetricRaven script loads are queued and sent as soon as it does.Queue stub<script> // Keeps the call until the MetricRaven script has loaded, then replays it. window.metricraven = window.metricraven || { q: [] }; window.metricraven.payment = window.metricraven.payment || function () { window.metricraven.q.push(["payment"].concat([].slice.call(arguments))); }; </script>
Example: a React welcome page
If checkout redirects to /welcome, call it when the page loads:
"use client";
import { useEffect } from "react";
// The page your checkout redirects to, e.g. /welcome, with the signed-in buyer.
export default function Welcome({ user }) {
useEffect(() => {
if (!user?.email) return;
if (window.metricraven?.payment) {
window.metricraven.payment({ email: user.email });
} else {
window.metricraven = window.metricraven || { q: [] };
window.metricraven.q.push(["payment", { email: user.email }]);
}
}, [user?.email]);
return <h1>Welcome aboard</h1>;
}With the npm package, the call is payment({ email }) from @metricraven/web.
When to use this
- Checkouts where you can't set custom data, including third-party tools that sell through Polar.
- Flows where the buyer's email is known on the page after payment.
When you can pass the visitor ID at checkout, prefer that: it's exact and needs no email.
Notes
- Repeat calls are ignored, so reloading the page can't double anything. Payments themselves still come only from the webhook.
- It only fills in payments that have no other link to a visit, and never replaces a visitor ID, user ID or server-side identify.
- Matching rules, privacy and the security model: Attribute by email.