Conversion tracking

Unlike referrals, it does not award commissions or change referral rewards. The site administrator configures one integration; creators do not connect their own advertising accounts.

How It Works

1. Your ad sends visitors to your homepage or a creator's profile. For click-based tracking, your provider adds a unique click ID to the landing URL, such as https://your-site.com/creator?click_id=abc123.
2. After the visitor accepts marketing cookies, the platform remembers the tracking information for the configured attribution window. No separate incoming notification from the advertising platform is needed.
3. The visitor completes a purchase. The platform checks that payment succeeded and that the purchase matches your tracking rules.
4. The platform reports the qualifying purchase through your chosen delivery method. Your provider uses its tracking identifiers to match the purchase to the campaign.

For example, a visitor clicks an ad and buys a $20 subscription. The provider can credit that campaign with a $20 purchase, without creating a referral commission.

Choosing a Delivery Method

• Browser pixel / tag: runs your configured conversion code in the buyer's browser after a qualifying purchase. The buyer must return to the site, signed in and verified, in the same consented browser. Ad blockers, closing the page, or connection problems can prevent delivery.
• Server-to-server postback: sends the purchase details and captured click ID directly from the server to your provider's HTTPS URL. It runs in the background with retries and does not require the buyer to return after payment. Earlier marketing consent and a captured click ID are still required.

Ask your provider for its conversion HTML or HTTPS GET postback URL and any required click-ID parameter. This is not an automatic connection to every advertising platform: providers requiring a custom API, signed POST requests, or authorization headers need a separate integration.

Configuration

1. Complete the normal application update and database migrations before enabling this feature.
2. Sign in as the root administrator and open Admin > Settings > Payments > Conversion tracking.
3. Enable the cookie banner in Compliance Settings. Visitors must accept the separate Marketing cookies category before checkout; analytics consent alone is not enough. Disabling the banner also prevents conversion tracking.
4. Enable purchase conversion tracking and leave Dry-run mode on for the first test. Dry-run records eligible events locally without contacting your provider or running tracking code.
5. Choose the delivery method and purchase rules below, then enter your provider's tracking code or postback URL.
6. Set the Click-ID query parameter to the name used in your campaign links, such as click_id. It is separate from the referral system's ref parameter.
7. Choose the Attribution window: how long a consented click can be linked to a purchase, from 1 to 90 days (30 by default).

Keep the application's normal cron schedule running. It processes postbacks every minute while tracking is enabled; no separate queue worker is required. When tracking is disabled, only daily cleanup runs to clear expired click IDs and skip unsent deliveries.

Disabled sites do not load tracking scripts or send conversion events. Completed purchases retain one small history update so first-purchase rules remain accurate if you enable tracking later.

Which Purchases Count?

• Purchase types to track: subscriptions, paid posts, paid messages, livestream access, and optional tips (including chat tips). Wallet deposits, withdrawals, free access, signups, and manually added transactions are excluded.
• Count a conversion for: the first qualifying purchase on the site, the first from each creator, or every qualifying purchase. Only your selected purchase types count toward these rules, including earlier purchases made before tracking was enabled or without marketing consent.
• Creator scope: choose whose sales to report: all creators or selected creators receiving payments. This does not select buyers or referrers. The site-wide first-purchase rule still considers qualifying purchases from all creators.
• Include recurring renewals: optionally report subscription renewals when subscriptions and every qualifying purchase are selected. Off by default.

New installations select subscriptions, paid posts, paid messages, and livestream access by default. Existing subscription-only tracking configurations remain subscription-only until you select additional types. Changing settings does not send historical purchases.

Browser Pixel / Tag Setup

Paste trusted conversion HTML containing <script> and/or <img> tags into Browser conversion HTML, not bare JavaScript or PHP. Your provider's code must be configured to send the purchase event; pasting a general page-view pixel alone is not enough.

For your developer or tag-manager setup, purchase details are available in window.purchaseConversion: event_id, transaction_id, value, currency, event_name (purchase), purchase_type, and is_recurring. Alternatively, leave the HTML blank if your integration listens for the purchase-completed browser event, which contains the same details. A tag manager is not connected automatically. Use one reporting path so the same purchase is not counted twice.

If upgrading from subscription-only tracking, update your code to use these generic purchase fields or event before enabling other purchase types. The older subscription-purchased event only covers subscriptions.

Server-to-Server Postback Setup

Paste your provider's URL into Postback URL template, using its required parameter names. The following is an illustration, not a working provider endpoint:

https://tracking.example.com/convert?click={click_id}&event={event_id}&transaction={transaction_id}&value={value}&currency={currency}

• {click_id} is required. Purchases without a captured click ID are not sent by postback.
• Optional placeholders: {event_id}, {transaction_id}, {value}, {currency}, {purchase_type}, and {is_recurring} (1 or 0).
• Use placeholders only in query parameter values. The endpoint must use public HTTPS on port 443, without redirects.
• Map {event_id} to your provider's deduplication field where supported. Temporary failures can trigger retries, so the provider must recognize repeated events to avoid double-counting.

Testing and Going Live

1. With tracking enabled and dry-run on, visit a test campaign link, accept marketing cookies, and complete a qualifying test purchase. Dry-run does not make the payment itself free or simulated; use your normal payment-testing setup.
2. Check Recent conversion deliveries for the recorded event. If it is missing, check consent, the purchase rules, creator scope, and (for postbacks) the incoming click ID.
3. Turn dry-run off for an end-to-end test with your provider. Make a new qualifying purchase: dry-run records are never resent. If testing a first-purchase rule, use a new eligible buyer; the earlier test purchase already counts.
4. For browser tracking, return to the site in the same signed-in browser. For postbacks, allow the scheduled task to run. Confirm the conversion, value, and currency in your provider's dashboard before using production traffic.