Integrations
How conversion tracking works, and everything your account needs to run it.
In plain terms
A creator shares a link to your site. Someone clicks it, and later does something you care about — signs up, buys something, makes a deposit. Your site tells us it happened, we work out which creator sent that person, and the creator gets paid for it. The rest of this page is how each of those steps works.
How conversion tracking works
The full path from a creator's link to a credited conversion — what runs on your site and what Influence360 does.
- 1CreatorCreator shares linkA unique go.influence360.io tracking link per creator.
- 2Influence360Click redirectWe record the click and send the visitor on to your site, tagged with a ref id — the code that says which creator sent them.
- 3BrowserLanding pageOur snippet on your page saves that ref id in a cookie on your own domain.
- 4Your siteVisitor convertsSign-up, purchase or other action on your site.
- 5Your siteBrowser pixelA snippet on the page reports it from the visitor's browser.
- 6Your backendServer postbackYour own server reports it to us directly.
- 7Influence360Influence360 attributesWe match the ref id to the creator, then run our timing, duplicate and fraud checks.
- Creator creditedValidated conversions feed dashboards and payouts.
Which one should you use?
Two ways to tell us a conversion happened: the pixel is a snippet of code in your web page, the postback is a request your own server sends us. Both report the same events into the same attribution pipeline. What differs is what we can guarantee about the report itself — which is why anything carrying an amount belongs on your server.
Report Purchase and Deposit through the server postback. Sign-up, KYC verification, App install and Subscription carry no amount, so either route is fine — pick whichever is easier to reach in your stack.
| What differs | Browser pixel | Server postbackRecommended for money events |
|---|---|---|
| Best for | Events with no amount — sign-ups, installs, verifications. | Anything that decides money — purchases, deposits, refunds. |
| Authentication | A public token that ships in your page source, plus the list of domains allowed to use it. Nothing secret is involved. | A secret token sent in the request header, optionally hardened with request signing (HMAC) and a list of allowed IP addresses. |
| Can the amount be altered? | Yes. The amount is whatever the browser sends, so a visitor can edit it before it reaches us. | No, once request signing is on — the signature covers the whole body, amount included. |
| Duplicate protection | Optional. dedupKey is your own id for the conversion; leave it out and there is no protection at all — a double-submitted checkout becomes two conversions. | Built in. dedupKey is required, so retries and replays collapse into one conversion. |
| Refunds and chargebacks | Not supported. A refunded order cannot be reversed from the browser. | Send the same conversion with reversal set to true and the credit is taken back. |
| Delivery | Send and hope. Ad blockers, a tab closed too early or a failed request lose events silently, with no retry. | Your server owns delivery and can retry safely: dedupKey means a repeated send counts once, never twice. |
| Do you find out about failures? | No. The endpoint always returns the same empty success response (HTTP 204) by design, so a dropped event looks exactly like an accepted one. | Yes. It returns HTTP 202 when the event is accepted, and an explicit error when it is not. |
| Setup effort | Around 5 minutes — one snippet, pasted site-wide. | Around 15 minutes — store the ref id on landing, then POST from your backend. |
Both routes run through the same validation, duplicate checks, fraud checks and minimum-value rules — a browser-reported amount is not discounted or scored more harshly. That is precisely why an amount you cannot vouch for should never be reported from the browser in the first place.
Attribution
Every creator in a cost-per-action (CPA) campaign shares a unique tracking link. When a visitor clicks it, Influence360 records the click and forwards them to your destination URL. It adds a ref id to the web address — a short code identifying which creator sent that visitor. The pixel then stores the ref id in a cookie set on your own domain, so it is still there when the visitor converts.
When the visitor converts, you report the conversion together with the ref id — from the browser via the pixel, or from your server via the postback. Influence360 matches the ref id back to the creator, then runs its checks before crediting the conversion. It has to fall inside the attribution window — the time limit after a click for a conversion to still count. It also has to be new rather than a repeat of one already reported, and it has to clear our fraud checks.
Attribution strictness for wallets
Web3 conversions are detected on the blockchain, from the visitor's crypto wallet. For a creator to be credited, that wallet has to be linked to the referral the visitor arrived with — a wallet binding. By default any binding counts. If you want a stronger guarantee, attribution strictness lets you prefer, or require, bindings the visitor has signed with their own wallet to prove they own it.
Strictness is a per-company setting — you change it on the Configuration tab under On-chain attribution.
Test mode
Events sent with the test flag are practice runs: they go through exactly the same checks as a real conversion, but are never billed and never credit a creator. Your account has a dedicated test ref id, and the Configuration tab can fire a test event for you and confirm automatically when it lands.
The test ref id only works together with the test flag — real conversions must carry the ref id captured from the visitor's click.