What are cookies?
Cookies are small text files placed on your device by a website you visit. They store information that lets the site remember you between visits (for example, that you're logged in) or measure how the site is used.
How CARTT.AI uses cookies
We use cookies in three contexts:
- The CARTT.AI marketing site (cartt.ai) - a session cookie, which also identifies your visit to our own first-party analytics. We run no third-party advertising or analytics trackers here - no Google Analytics, no Meta pixel, nothing that profiles you for advertising. Two third parties are nevertheless in the picture, and we would rather name both than round them down to zero: every page loads its typefaces from Google Fonts, and pages carrying an enquiry form load Google reCAPTCHA. Both are described below. Our own measurement is described below too, and it is event-level rather than merely aggregate.
- The CARTT.AI admin panel - these are ours, not the tenant's, and it would be wrong to describe them as merely infrastructure we provide. When a merchant's staff sign in to administer a store, we set the session cookie that keeps them signed in, the remember-login cookie if they tick that box, a trusted-device cookie if they choose to skip two-factor on that browser next time, and a small preference cookie that decides whether the admin toolbar appears when they browse their own storefront. They are functional; none of them is advertising or profiling.
- Merchant storefronts - a split. The functional cookies come from our platform code, because the storefront runs on it: session continuity, cart contents, consent choices and the variation of cached pages. What is genuinely the tenant's is everything they choose to add on top - any analytics, advertising or marketing tag they install, and the consent banner they present. Each tenant is responsible for disclosing and controlling cookies on their own site, and their storefront's own notice governs it.
Cookies we set on the marketing site
cartt-ai-session(our session cookie) - session continuity, and the identifier our own analytics groups your visit under. Functional rather than strictly necessary, and we would rather say so: block it and these pages still read and the enquiry form still submits - what changes is that your visit is grouped under a fingerprint instead, as "Controlling cookies" explains. It is not cleared when you close your browser: it is configured to persist, so a later visit from the same browser can be recognised as the same session until it lapses.XSRF-TOKEN- cross-site request forgery protection for authenticated forms elsewhere on the platform. It is not what protects the contact form; that form is validated by our anti-bot checks, reCAPTCHA and rate limiting instead._GRECAPTCHA- set by Google, not by us, on the pages carrying an enquiry form, for the bot scoring described below. We cannot read it.cartt_ad_attr- set only if you arrive by a link carrying advertising parameters (a Google or Meta click identifier, orutm_campaign tags), and it is the one cookie here whose purpose is marketing attribution rather than function, so we would rather list it plainly than fold it into the sentence above about no advertising trackers. It records those parameters and the time it recorded them, and nothing further; it lasts 30 days, is encrypted, and is readable only by our own servers. Nothing goes back to Google or Meta, and it does not follow you to any other site. Arrive without those parameters and it is never set. It exists so that where a visit later becomes an order, we can tell which campaign it came from; the same cookie does that job on merchant storefronts, described below.
We also use sessionStorage (browser storage, not a cookie) to remember the campaign parameters you arrived with for the length of your visit.
Our own analytics on the marketing site
We would rather describe this than let "no third-party trackers" imply we measure nothing. Every page of this site loads our own click tracker, which records the pages you view, the links you click, how far down a page you scroll, and the campaign parameters in the link you arrived by. Those events are stored against your session identifier together with the IP address, browser, operating system and device type the request came from. It is first-party: the data goes to our servers in Australia and to no one else, we do not use it for advertising, and we do not sell or share it. If you would prefer not to be measured, blocking JavaScript from this site stops it and the pages still read; your browser's tracking-protection list generally will not, because these beacons go to cartt.ai rather than to another company's domain. "Controlling cookies" below sets out which controls actually do what.
Cookies we set in the admin panel
These are set by us, on our code, and encountered by staff signing in to administer a store - though as the note after the list explains, some of them are not unique to the admin panel. All are functional; none is advertising or behavioural tracking:
- The session cookie - signs you in and keeps you signed in. Its name is set per deployment, so we do not print it here; it is the same cookie described in the marketing-site list above, issued for the admin domain.
XSRF-TOKEN- the same cross-site request forgery protection listed above, and it is issued on every admin response because the admin panel is form-driven throughout.remember_admin_…- set only if you tick "remember me" at sign-in, so the browser can be recognised after the session lapses. Laravel appends a hash to the name.2fa_device_admin- set only if you choose to trust a browser at the two-factor prompt, so that browser can skip the second factor until it expires. It holds a random token; the matching value stored on our side is hashed, and the device, its last use and its IP are recorded against your account so you can see and revoke it.is_admin_toolbar- a preference, set at sign-in only if you have turned the front-end admin toolbar on, so the toolbar appears when you browse your own storefront._cartt_profile- a developer diagnostic, and the one here that needs more than a line. It arrives two ways: a platform super-administrator turning the page profiler on from the admin toolbar, which needs nothing added to the address; or anyone at all appending?_profile=1to a URL. Either way what is set first is an inert marker that arms nothing. Only if the request also proves to be a signed-in platform super-administrator is that marker replaced with a signed token - and on any other browser it never is, so the marker simply sits there doing nothing until it lapses. Once the signed token exists, it turns on per-page instrumentation (query, cache and outbound-call timings) for that browser until it expires after eight hours or the toggle is switched off. The visible overlay is gated a second time and separately: it is drawn only while that browser is still signed in as a super-administrator. What the instrumentation records is timing about the page, not anything about a visitor.
Three of those are genuinely admin-only - the remember-login, trusted-device and toolbar cookies exist for signed-in staff and are never set for a shopper. The rest are not exclusive to the admin panel: the session cookie and XSRF-TOKEN are set on storefronts as well, for shoppers, which is what the storefront section below describes; and the inert _cartt_profile marker can be queued on any page of any site here by anyone who appends ?_profile=1, though it arms nothing for them. The cartt_ad_attr cookie described above is not an admin-panel cookie in any ordinary sense - it is triggered by advertising parameters in a link, which admin navigation does not carry - but the code that sets it runs across the whole platform rather than on the public pages alone, so we will not claim it can never appear there. Section 3.6 of the Privacy Policy governs and prevails over this page.
Cookies set inside tenant storefronts
It is worth separating these by who put them there, with one that does not fit the split cleanly. Most of what our platform code sets is functional, because the storefront runs on that code - session continuity, shopping cart persistence, customer login, the shopper's consent choices, and the variation of cached pages. Then there are the tenant's own choices: marketing analytics, abandoned cart recovery, A/B testing, and connected third-party services (Google Analytics, Meta Pixel, TikTok Pixel, Klaviyo and the like) where the tenant has enabled those features. The tenant decides what runs on their storefront and publishes their own privacy and cookies policies, which apply to the cookies on it.
The one that sits in neither box is cartt_ad_attr, and we would rather point at it than let the tidy split above imply everything we set is functional. It is ours, not the tenant's, it is set on storefronts as well as on this site, and its purpose is marketing attribution. When a shopper arrives by a link carrying a Google or Meta click identifier or utm_ campaign tags, we store those parameters in an encrypted, server-only cookie for 30 days; if that shopper places an order within the window, the parameters are copied onto the order record so the merchant can see which campaign produced the sale. It captures those link parameters and the time they were captured, and nothing further: no name, no contact details, no record of what was browsed. That is a statement about the cookie's contents rather than about what becomes of them, because once they are copied onto an order they sit beside the name and address of an identified customer, and an advertising identifier attached to a named order is personal information in that context even though it is meaningless on its own. It does nothing at all for a visitor who arrives without such a link. It is not sent back to Google, Meta or any other advertising provider. The merchant does see it, because that is what it is for: once copied onto the order it is part of their order record, visible to their staff alongside the rest of the order. A shopper who wants it gone can clear it like any other cookie, and a merchant who does not want it should say so in the cookie notice on their own storefront.
Google reCAPTCHA on our enquiry forms
The pages with an enquiry form on them - the home page and the agency page - load Google reCAPTCHA Enterprise so that we can tell a person from a script without making you solve a puzzle. It is the one place where a script from another company runs on this site, so here is what actually happens. Google's script loads with the page, not when you press send, and it reports information about your device and browsing session to Google in the United States for scoring: things like your IP address, browser and screen characteristics, and how the page was interacted with. It does not receive what you typed into the form - that comes to us. When you press send, the score is confirmed by a second call to Google, made from our own server rather than your browser, and that call carries only the token Google's own script issued. Google may also set its own _GRECAPTCHA cookie in your browser for the same purpose. Google's handling of it is governed by the Google privacy policy and terms of service, and we use it for spam and abuse prevention only - not for advertising, and not for measuring you. Blocking scripts from google.com stops it - but you should know what that costs you: with the check enabled, a submission that arrives without a Google token is rejected, so blocking the script (or blocking JavaScript generally) means the enquiry form will not go through. That is deliberate - it was the exact hole spam was walking through - and it is why we would rather tell you than let you discover it as a form that silently fails. If you would prefer not to load Google's script, email us at legal@cartt.ai instead and you will reach the same people.
Google Fonts
Every page of this site - including this one and the policy pages - loads its two typefaces, Plus Jakarta Sans and JetBrains Mono, from Google Fonts. No script runs and no cookie is set, but fetching a file from Google is still a request to Google, and it carries what any request carries: your IP address, your browser and operating system, and the fact that you were on cartt.ai. It does not carry which page - every response from this site sets a Referrer-Policy of strict-origin-when-cross-origin, so a request to another company's domain discloses ours and stops at the domain. We are naming it because "no third-party trackers" should not be read as "nothing leaves this page", and because it applies to everyone, not only to people who fill in a form. Blocking fonts.googleapis.com and fonts.gstatic.com stops it and the site stays perfectly readable in your browser's fallback typeface.
Analytics
The marketing site runs no third-party analytics - no analytics or advertising company is told about your visit for measurement or advertising purposes. What it does run is our own first-party click tracker, described above; the only third-party script on the site is the reCAPTCHA described above, which is there for abuse prevention rather than measurement, and the only other third-party request is the font fetch described immediately above. If we ever add a third-party analytics or advertising service, this page will be updated before it goes live and the cookie will be opt-in where required.
Controlling cookies
Most browsers let you view, manage and block cookies via the browser settings. We would rather tell you which controls actually do something here than leave you with a generic paragraph.
Blocking the session cookie does not stop our click tracker. The pages still read and the enquiry form still submits; what changes is only how a visit is grouped. Without a session cookie the tracker falls back to a short fingerprint derived from your IP address and browser string, so the visit is still recorded - grouped under that fingerprint instead of under a session. If your reason for blocking the cookie was to avoid being measured, the cookie is the wrong control.
Blocking JavaScript does stop it. The tracker is a script on our own domain, so it cannot run without JavaScript and no beacon is sent. Your browser's tracking-protection list is unlikely to have the same effect: those lists block requests to other companies' domains, and our beacons go to cartt.ai, so they usually pass straight through. Turning JavaScript off also stops the enquiry form, which is submitted by script and, as explained above, is rejected without a reCAPTCHA token - email legal@cartt.ai instead, and we will treat that exactly as we treat a form submission.
Changes
If we change our cookie usage we'll update this page and the "Last updated" date.
Contact
Questions about cookies: legal@cartt.ai.