Integrations

How conversion tracking works, and everything your account needs to run it.

Transparency & verification

Everything influence360.js does on your pages, everything it stores, everything it deliberately does not do — and how to prove the copy your visitors load is the copy we published. The source is public and the builds are reproducible, so none of this rests on our word.

View the source Apache-2.0 licence Security policy

What leaves your page

One request, to one host, carrying the fields below and nothing else. The script is loaded from our CDN and reports conversions to the collector; it makes no other network call.

Reports to: POST https://tracking.influence360.io/public/pixel/conversion
Content type: text/plain;charset=UTF-8
Script loaded from: https://tracking-pixel.influence360.io/v1/influence360.js
Reads from the URL: ?influence360RefId=

See every field in the event reference →

What it stores in the browser

Three writes, all first-party on your own domain. This list is complete — if you find a fourth in your browser's Application tab, that is a bug and we want the report.

Name	Kind	Lifetime	Scope	Purpose
`_influence360_ref_id`	Cookie	90 days	Your domain, all paths	The referral id the visitor arrived with, so a conversion can be credited to the creator who sent them.
`_influence360_ref_id`	localStorage	until cleared	Your origin	A copy of the same referral id, so attribution survives the cookie being evicted. Not a second identifier — same key, same value.
`__influence360_d`	Cookie	transient	Candidate parent domain	Written and deleted within the same call, to find the widest domain that accepts a cookie so a click on one subdomain converts on another. Never persists.

About these writes

The referral cookie is written with Path=/; SameSite=Lax; Secure — first-party, sent only over HTTPS, and not sent on cross-site requests.

Nothing is written to a domain other than yours, and nothing is read that the script did not write. If you set the cookieDomain option, the cookie is scoped to exactly that domain instead of the auto-detected one.

What it does not do

Each of these is a property of the bundle you can confirm yourself: search the source for the API it would have to call, and it is not there.

No device fingerprintingNo canvas, font, WebGL or audio probing, no screen or hardware enumeration, no attempt to identify a device across sites.
Reads only what it wroteIt reads its own referral cookie and its own localStorage key. It does not enumerate your cookies, storage or session data.
No page contentNo form fields, no keystrokes, no clipboard, no DOM scraping, no session recording, no screenshots.
No third-party callsThe only request it makes is the conversion beacon to the collector shown above. No ad networks, no analytics vendors, no tag loaders, no dynamically injected scripts.
No cross-site trackingStorage is first-party on your domain only. There is no third-party cookie, no iframe, no cross-site identifier, and no advertising id.
No personal data we chooseThe only field that could carry personal data is the dedupKey your own code supplies. Send a hash or an order id — the pixel neither reads nor infers an email, a name or an address on its own.

What happens when it fails

The honest answer to “will this break my checkout?”, with the mechanism behind each guarantee named so you can check it rather than take it.

It never throws into your pageEvery entry point is wrapped, including storage access and the network call. A failure inside the tracker cannot become an exception in your own code.
It never blocks renderingThe snippet loads the script asynchronously, and conversions are sent fire-and-forget through sendBeacon (or a keepalive fetch). Nothing waits on a response, and there is no response to wait for.
Blocked storage is not an errorIn private mode, with storage disabled, or under a sandbox, reads and writes fail silently. Attribution is lost for that visitor; the page is unaffected.
A tampered build fails closedIf you pin a version with an integrity hash, a browser that receives different bytes refuses to execute them. The worst case is no tracking, never wrong tracking or unexpected code.

Verify the bytes you load

Pinned builds are immutable and never republished with different bytes, so a hash that matched yesterday still matches today. The manifest is the authoritative record of what we have published.

Open the published manifest ↗

Published builds

The published-build list could not be loaded. The manifest linked above is the authoritative record.

1. Hash what the CDN served you

Needs nothing but curl. Proves the file your visitors receive is the file listed in the manifest — the same sha384 a pinned snippet carries.

hash-pixel.sh

curl -s https://tracking-pixel.influence360.io/manifest.json

curl -sO https://tracking-pixel.influence360.io/v<version>/influence360.js
openssl dgst -sha384 -binary influence360.js | openssl base64 -A

2. Check the build provenance

Every published build carries a sigstore attestation binding its digest to the workflow, repository and commit that produced it. Proves the bytes came out of our public build pipeline and not from someone with CDN access.

verify-provenance.sh

curl -sO https://tracking-pixel.influence360.io/v<version>/influence360.js
gh attestation verify influence360.js --repo Influence360/tracking-pixel

3. Rebuild it yourself

The build is reproducible: rebuilding the commit shown in the Commit column above produces byte-identical output. The command prints a sha256 — compare it with the one in the table. This is the check that requires trusting nobody: not us, and not GitHub.

rebuild-pixel.sh

git clone https://github.com/Influence360/tracking-pixel
cd tracking-pixel && git checkout <commit>
npm ci && npm run verify:reproducible

# prints "build is reproducible: sha256-…" — compare it with the manifest

What the provenance attestation proves

Builds from this repository are signed by public sigstore and recorded in its public Rekor transparency log, so the attestation is independently auditable: you can confirm the bytes came out of this repository's workflow without taking our word for it, or GitHub's. Verified on the current build — the signing certificate is issued by sigstore.dev, and the Rekor entry is retrievable anonymously with a signed inclusion proof. Builds published before this repository became public on 5 August 2026 were signed by GitHub's own sigstore instance instead and carry no public log entry. Step 3 goes further still, tying those bytes to source you can read.

Staying informed, and reporting a problem

A pinned version never changes under you. If you use the auto-update channel, or your script-monitoring tool alerts on a change, these are how you correlate and how you reach us.

Published-builds feed (Atom): One dated entry per published build, with its hashes and the commit it was built from. Subscribe with a feed reader or your monitoring tool; there is no email list.
Report a vulnerability: Opens a private draft advisory on the repository. We acknowledge within three business days. Please do not open a public issue for a security problem.
Privacy Policy: Retention, international transfers and the rest of our data-protection commitments, including for data collected through conversion tracking.