Integrations

I'm integrating Influence360 Performance conversion tracking into my website using the browser pixel. Generate the code for my stack and explain where each piece goes.

CONTEXT
- A creator link sends a visitor to my site with an Influence360 ref id in the destination URL. The pixel below captures and persists it automatically (first-party cookie), so I only report the conversion event.

SETUP — load the pixel (influence360.js) once on every page:
   <script>
     !(function(w,d){w.influence360=w.influence360||function(){(w.influence360.q=w.influence360.q||[]).push(arguments)};var s=d.createElement('script');s.async=1;s.src='https://tracking-pixel.influence360.io/v1/influence360.js';d.head.appendChild(s)})(window,document);
     influence360('init', '<YOUR_PUBLIC_TOKEN>', { collectUrl: 'https://tracking.influence360.io/public/pixel/conversion' });  // every page — captures the ref id
   </script>

REPORT — on each conversion success page, call (use the matching event type):
   - SIGN_UP — a new user registered
     influence360('track', 'SIGN_UP', { dedupKey: '<your-company>:sign_up:<order-or-user-id>' });
   - KYC_VERIFICATION — a user passed identity verification
     influence360('track', 'KYC_VERIFICATION', { dedupKey: '<your-company>:kyc_verification:<order-or-user-id>' });
   - APP_INSTALL — a user installed the app
     influence360('track', 'APP_INSTALL', { dedupKey: '<your-company>:app_install:<order-or-user-id>' });
   - PURCHASE (orderValue required) — a paid order (orderValue = order amount)
     influence360('track', 'PURCHASE', { dedupKey: '<your-company>:purchase:<order-or-user-id>', orderValue: '49.99' });
   - DEPOSIT (depositValue required) — a funded deposit (depositValue = deposit amount)
     influence360('track', 'DEPOSIT', { dedupKey: '<your-company>:deposit:<order-or-user-id>', depositValue: '49.99' });
   - SUBSCRIPTION (qualifyingPlan required) — a paid subscription (qualifyingPlan = the plan the user subscribed to; payout is plan-driven)
     influence360('track', 'SUBSCRIPTION', { dedupKey: '<your-company>:subscription:<order-or-user-id>', qualifyingPlan: 'pro-monthly' });

NOTES
- influence360('init', ...) must run on every page so the ref id is captured site-wide.
- To route events through your own proxy or a regional/staging collector, change collectUrl.
- dedupKey (built as <my-company>:<event-type>:<order-or-user-id>, see below) makes retries idempotent — always send it. Omitting it on the pixel disables duplicate protection entirely, so a double-submitted checkout counts twice.
- Monetary events must send their type-specific amount field (PURCHASE → orderValue, DEPOSIT → depositValue); it has to meet the action's configured minimum or the conversion is rejected.
- PREFER THE SERVER POSTBACK FOR PURCHASE AND DEPOSIT if my backend can report them: an amount reported from the browser is whatever the page sends (a visitor can edit it), the pixel cannot reverse a conversion after a refund or chargeback, and the pixel endpoint answers 204 to any well-formed request so a rejected event is indistinguishable from an accepted one. Use the pixel for the events that carry no amount (SIGN_UP, KYC_VERIFICATION, APP_INSTALL, SUBSCRIPTION). If you wire a purchase or deposit through the pixel anyway, tell me why and flag it in your summary.
- SUBSCRIPTION must send qualifyingPlan (the plan the user subscribed to); its payout is decided by matching that plan against the action's configured plan tiers — an unlisted plan is rejected — so it carries no amount.
- Web3 events (WALLET_ACTIVITY, TOKEN_ACQUISITION, DEPOSIT_STAKE, NFT_MINT) are DETECTED on-chain — you never report them — but they still need the visitor's wallet tied to the referral, which does take client code: call influence360('identify', '<connected-wallet-address>', { chain: 'ETHEREUM' }) right after the wallet connects. Without that binding (or an on-chain referral tag) an on-chain conversion has nothing to attribute and is never credited.
- THE EVENT TYPES ABOVE ARE THE COMPLETE CATALOG — there are no custom event types, and an unknown content.type is refused (postback) or silently dropped (pixel). If I need to pay for a milestone that is not in the list, map it onto the event whose pricing fits — a flat fee: any of SIGN_UP, KYC_VERIFICATION, APP_INSTALL; a fee per named level: SUBSCRIPTION with the level as qualifyingPlan; a fee graded by an amount: PURCHASE, DEPOSIT — and tell me which one you chose and why. Never invent a type.
- A campaign carries at most one action per event type, and a conversion is matched to it by its type alone, so the same type cannot be paid at two prices in one campaign.
- dedupKey IS GLOBAL AND PERMANENT: a key that was already accepted is rejected as a duplicate whichever company, campaign or event type accepted it, and even after that conversion was reversed. Build every key as <my-company>:<event-type>:<id> (e.g. acme:deposit:order-1001) so it is unique to what should pay once, give a repeat purchase or re-subscription a new key, and send the same key only on a retry of the same event. On an action marked new users only the key is also the user's identity (compared across all of my company's campaigns), so there build it from the user id (e.g. acme:deposit:user-42). Tell me which ids you chose. Without a dedupKey there is no duplicate protection.
- The pixel answering 204 (it does for any well-formed request) means RECEIVED, not credited: amount tiers, plan ids, the campaign's actions, new-users-only, the attribution window and fraud burst limits (more than 20 events per ref id or 50 per IP within 60 seconds) are applied afterwards and the outcome is not reported back. On the postback the per-IP limit counts MY SERVER's address, so keep bulk sends and backfills under 50 requests a minute per outbound IP. A test event (test: true) is never matched to a campaign, so an accepted test does not prove any of those will pass — list them in your summary as things for me to confirm in the campaign's configuration.