CLItrail
Support
Support
Most answers depend on two things: the browser your visitors use and the computer your tool installs on. Find yours in the matrix, run three checks, and if you’re still stuck, write to us from this page.
01Support matrix
Find the system your visitors browse on and their browser. Each row says what works with the default setup, where the handoff command gets attribution instead, and the one step to take in each case.
Links an install to the visit on the same Mac or Linux computer in Chrome, Firefox, Edge, Brave and Vivaldi, and in Safari through the handoff command.*
Plans. Attribution (the same-machine match, the handoff command and reconstruction) runs on Standard and Enterprise. On Free, CLItrail counts visits and installs without matching them, and installs reported on Free are never matched later.
The support matrix is drawn by this page’s script. The same matrix, with its methodology, is in the documentation.
The same browser can match or not depending on where your command runs. These cases hold for every browser above.
On macOS and Linux the hook searches the profile folders of Chrome, Chrome Beta, Chrome Dev, Chromium, Edge, Brave, Vivaldi and Firefox; on macOS also Chrome Canary, and on Linux also Zen and the Snap and Flatpak builds. Safari, WebKit browsers and forks that name themselves, such as Opera, get the handoff command from prepareInstall in auto mode. For browsers that present themselves as Chrome or Firefox but keep their own profiles, such as Arc or LibreWolf, use handoff mode. Support matrix in the docs ↑
Last updated . Methodology and sources
02Check your setup
Each check looks at one link in the chain: the visit on your install page, the hook on the installing computer, then the delivery to your ad platforms.
Open your install page in the browser you want to check, then run this in its developer console:
await InstallAttribution.ready{ ok: true, … } means the visit and its receipt were recorded. Anything else carries a reason that names the cause.
On the computer that installs, as the same user who visited, run the hook from your Setup tab with --doctor:
sh clitrail.sh --doctorStatus on says what an install would send; off gives the reason. It sends nothing and never prints folder paths or receipts.
New destinations start in test mode: events are prepared and listed, and nothing is sent. Use Send test event, check the delivery on Install events, then Go live.
The Logs tab shows every request CLItrail received and every delivery attempt, with the bodies as sent and credentials redacted.
Destinations| What you see | Why it usually happens | What to do |
|---|---|---|
| Installs show as unmatched | The visit was in another browser, on another computer or for another OS user, or in a browser the hook doesn’t read, such as Safari. | Find the row in the support matrix. For Safari, remote boxes and agents, show the handoff command on your install page. Handoff command |
InstallAttribution.ready gives opfs_unavailable | The page is served over plain http on a host other than localhost, or the browser has no private storage for the receipt. | Serve your install page over https. Common problems |
--doctor says Status off | DO_NOT_TRACK or CLITRAIL_DISABLE is set, a CI variable is set, or neither curl nor wget is installed. | The Status line names the reason. Opt-outs and CI are respected by design. Opt-outs |
The installer runs with sudo | The hook ran as root, whose home folder has none of the visitor’s browser profiles. | Do the privileged steps with sudo, then run the hook as the original user. Run as the right user |
| Nothing reaches an ad platform | The destination is still in test mode, the event type isn’t ticked, the visit carried none of that platform’s click or browser IDs, or consent was not granted. | Check the destination’s health and each delivery on Install events, then the attempt itself in Logs. Common problems |
| No sources, channels or campaigns in the dashboard | The organisation is on Free, which counts visits and installs without matching them. | Upgrade to Standard or Enterprise. Installs reported from then on are matched. Plan and usage |
402 plan_limit | A plan limit was reached: install paths, websites, domains, members, destinations or log streams. | The response names the limit and its maximum. Remove one, or upgrade. Limits |
429 rate_limited | Too many requests in a short window, from one client or for one website. | Wait the number of seconds in the Retry-After header, then retry. Limits |
03Plans and billing
Plans belong to an organisation, not to a person. Its owner manages billing; every member sees the plan.
Billed monthly through Stripe. Cancel anytime. Compare plans
The organisation’s owner opens Plan and usage in the dashboard and picks Standard or Enterprise. Payment happens on Stripe Checkout, and the plan changes as soon as Stripe confirms it, usually within a few seconds.
No. Free performs no matching of any kind. Attribution starts with installs reported after the upgrade; nothing reported on Free is matched later.
From Plan and usage, the owner opens Stripe’s billing portal, which handles plan changes, cancellation, the payment card and invoices.
Nothing is deleted. Install paths, destinations and log streams over the new plan’s limit are paused until the owner chooses which to keep; a paused install path is still counted but not attributed or delivered. Websites over the limit keep collecting, and members over the limit stay, but new ones can’t be added until you’re under it.
Paid plans are never cut off: past the quota, data keeps flowing, the dashboard tells you, and there is no overage charge. On Free, events past the quota that month are counted but not stored.
Only owners start checkout or open the billing portal. Admins, members and viewers see the plan and its usage.
Every plan and service limit, with the error each one returns, is listed in the docs, and your organisation’s usage against them is on Plan and usage. Limits
04Security and privacy
Sign in and write to us below with the topic Security, or email founders@pilotprotocol.network. Describe what you found and how to reproduce it. The message and diagnostics of a request sent from this page are visible only to you and the CLItrail operator. Your organisation’s activity records that you sent a request, with its topic and website, but not its message or diagnostics.
Write to usSupport never needs your API secrets, access tokens, service-account keys, webhook signing secrets or session cookies. If one was exposed, revoke it at its platform and paste the new one into the destination. Credentials are write-only and encrypted, in a store apart from the main database.
Secrets and encryptionIf you installed a tool or visited a website that uses CLItrail and want to use your privacy rights, contact that company first: they control the data. For data requests about CLItrail itself, email founders@pilotprotocol.network.
Privacy policy05Write to us
Requests are tied to your account and organisation, so we can look at the right website. Their status and our reply appear on this page.
--doctor output and the InstallAttribution.ready result where they apply.Sign in with Google or an email link. The first sign-in creates a free account for you and your organisation, so there is nothing to set up before you write.
Until then, the support matrix and the checks above answer most questions, and the documentation covers the rest. Without an account, email founders@pilotprotocol.network.
Signed in as