Privacy policy

Two things on this site measure how it is used. One counts every visit and asks nobody, because it sets no cookie and keeps no IP address; the other records more, and it asks first. Everything else below is either something you typed on purpose or a request your browser had to make to draw the page. No payment has ever been taken here, and the only cookie on this site is the one set by our email partner, Klaviyo, if you say yes.

One cookie, and only if you say yes

This site sets no cookie of its own. If you choose “Allow analytics” on the bar at the bottom of the page, Klaviyo, the service we use for marketing email, sets one (__kla_id) so it can recognise your browser on later visits. Say no and it is never loaded, so there is no cookie to clear.

Klaviyo, our email partner

If you allow analytics or subscribe to our emails, Klaviyo records the products you view, items you add to your cart, checkouts you start and orders you place, so we can send emails that fit what you like, such as a reminder about a cart you left. Once you give us your email, those visits are linked to your email profile. You can unsubscribe from any email with one click, and withdraw analytics consent any time from Privacy & analytics in the footer.

Visits are counted for everyone, without cookies

We count visits with Umami, a cookie-free analytics tool we host ourselves on Railway, in San Francisco in the United States. It runs whatever you answer on the banner, because it sets no cookie, stores no IP address and does not follow you to other websites; all it leaves in your browser is a note, until you close the tab, of which checkout and which order it has already counted. For each page you open it records the page’s path — never anything after a ? except campaign tags such as utm_source, nothing after a #, and never an order’s reference, which is replaced by :id before it leaves your browser — the page title, the page you came from, your screen size and language, and the browser, system and kind of device your browser reports.

It also counts three things you do in the shop: adding to cart (which product, how many and at what price), starting checkout (how many items and the subtotal), and placing an order: your browser reports how many items, the total and the currency when the confirmation page opens, and our own server sends the same with the order number once the payment has gone through. Never your name, email, address or anything you typed.

Unlike the section analytics below, this one does use your IP address on the way through: your browser sends the count to this site, and our server passes the address to Umami, which works out a country, region and city from it, and a one-way code from it and your browser’s user agent that counts your pages as one visitor’s within the same calendar month — the next month the code is different. Then the address is discarded.

What the section analytics records

Nine bands of the homepage report on themselves — the hero, the aisles, best sellers, the kit offer, sports, picks, new in, gifting and the affiliate band. Nothing else on the site feeds this table. Each row is one of four things happening to one band: it came into view, it was on screen for a number of milliseconds, you scrolled a quarter, half, three quarters or all the way into it, or you clicked a link or a button inside it.

A row holds these fields and no others:

• section — the band’s name, as a word: “hero”, “aisles”, “gifting”.
• event — one of those four. The database rejects a fifth.
• value — the milliseconds, or the percentage. Empty for the other two events.
• label — for a click only, the text on the thing you clicked.
• path — the page path, and only the path. Anything after a ? or a # is cut off before the row is written, because that is where campaign codes and typed search terms live.
• page_id — a random value made fresh on every page load, so one visit’s rows can be read in order.
• created_at and occurred_at — when the server received it, and when your browser says it happened.

There is no IP column in that table, no visitor id, no session id and no account id, because there is nothing of that kind to put in one. page_id lives in a JavaScript variable and is never written to your device, so it dies when the tab does: two visits by you cannot be joined to each other, and neither can be joined to you. That list is the whole of it — the server discards any field a browser sends that is not on it, so a changed page cannot quietly add a column of personal data to a table built not to have one.

The section analytics sends nothing until you say yes

Before you answer the banner, section-analytics events are held in your browser’s memory — capped at a hundred, never written to your device, never transmitted. Press Allow analytics and they are sent. Press Don’t allow and they are thrown away unsent, and the bands record nothing after that. The only thing the banner keeps on your device is the answer itself. Umami, described above, is not part of this choice: it counts visits and shop events either way.

You can change it whenever you like: Privacy & analytics, in the Policies column at the foot of every page, reopens the same question. Turning a yes into a no stops the sending immediately, in the page you are standing on, and discards whatever has not gone yet. It does not wait for a reload.

What a server sees, which is not what we record

Sending a section-analytics event is an HTTP request, and a server cannot answer a request without receiving the address it came from. So the address is seen. It is not recorded: nothing reads it, there is no column for it, and it is written nowhere we keep. That is the accurate version of the banner’s shorter promise, and it is why this page says “not recorded” rather than “never seen”.

Separately, the platform hosting this site keeps its own request logs, as every host does. We have not configured what goes in them or how long they last, and we are not going to describe them as though we had.

Google Fonts — a request to Google on every page, before you choose

The typeface this store is set in is loaded from Google’s font servers by a tag in the page’s head. Your browser therefore contacts fonts.googleapis.com and fonts.gstatic.com on every page you open here, and Google receives your IP address, your browser’s user agent, and the fact that a page on this site asked for a font. It happens on every page, before you interact with anything, and the analytics consent banner does not gate it — the request has gone by the time that banner renders.

This is the most exposed thing on the site, and it is the one place where somebody else learns you were here without you doing anything, so it belongs near the top of a page like this rather than in a footnote. The fix is to serve the font from this site instead, which is a change to the page’s head and nothing else. It has not been made.

Product photographs

Every product image is served from this company’s own file storage rather than from a content network we do not control, so the only server your browser asks for a picture is ours. That request is seen the way any server sees a request for a file. Nothing is stored about who asked for which image.

The mailing list

One pop-up on the homepage asks for an email address. If you give it and tick the box, four things are stored: the address as you typed it, which part of the site collected it, the moment you ticked, and the exact sentence you ticked — “Yes, email me when new kit lands.” — copied in word for word rather than referred to by a version number somebody could later edit.

No name, no IP address, no browser, no referring page, no cart contents, no page path. The request your browser makes carries several of those and the code drops them. Close the pop-up without submitting and nothing is stored at all, except a flag on your own device so it does not ask twice.

Nothing sends from that list. No message has gone out, no email tool is connected, and so there is no unsubscribe link to give you — there is nothing yet to unsubscribe from. This page will name the tool before the first message is sent.

Photo search sends your photo to a company in the United States

The photo search page lets you upload a picture and get products back. Your browser shrinks the image, posts it here, and this site passes it to Anthropic’s API — a company in the United States — asking which of the products in the catalogue it looks like. If you are not in the US, that is your photo crossing a border, and it happens on that one request.

The photo is not written down at any point: no file, no storage bucket, no database row, no log line. It exists in one server’s memory for the length of one request and is gone when the answer is written. What comes back to you is product names and a sentence, and nothing about the picture is kept to improve anything.

One thing about that request is held briefly. So that nobody can loop the feature and run up a bill, your IP address is counted in the server’s own memory for sixty seconds. It is not written to a file or a database and it is gone when that server restarts.

Live chat

If you open the chat panel, a random id is written to your browser’s storage at that moment — not on page load, and not at all if you never open it. That id is what proves the conversation is yours; without it the support desk returns none of it, to you or to anybody else. The conversation’s own id is kept beside it, so reopening the panel returns you to the same thread instead of starting a new one.

What reaches the desk is what you type, the page you opened the chat from, and a name and an email address if you choose to give them — both are optional and the conversation works without either. Those messages are stored at the desk, which is shared by the 9 shops this company runs, so an agent can read and answer them. None of it goes through the analytics described above.

Where no chat desk is connected to this store, the contact page says so and no request is made at all.

What stays on your device

Six things, all in your browser’s own storage, none of them sent anywhere except where noted:

• Your cart. Lines and quantities. There is no cart on any server, so clearing your browser clears it and nobody else can see it.
• Your analytics answer. The single word “granted” or “denied”.
• Whether the email pop-up has been shown. So that it asks once.
• Which checkout and which order the visit counter has already counted. The cart’s or order’s reference, kept only until you close the tab, so a reload does not count them twice.
• Your chat visitor id and the chat thread id, written only if you open live chat. These two do reach the support desk, because they are how it recognises your conversation.

Clearing site data for this site removes all six. The first four are yours alone and we never see them.

Forms that go nowhere

The contact form, the order-tracking form and every account screen — sign in, register, forgotten password, addresses, details — are not connected to anything. Pressing the button tells you so in plain words rather than accepting what you typed and dropping it. Nothing you enter into them leaves your browser, and it is gone when you reload the page.

Payments

Card payments are taken by Stripe. The card fields on the checkout are Stripe’s own, served from Stripe in a separate frame, so the card number and security code go straight to Stripe and never touch this site — there is no code here that could receive them, and none that could log them.

What we send Stripe is the amount, the currency, the name and email address you typed on the delivery step, and a label saying the charge belongs to Adrenaline. What comes back and is stored against your order is what Stripe tells us about the payment: the card brand, the last four digits, the expiry month and year, the country that issued it, whether it is debit or credit, Stripe’s own reference for the charge, and whether the security-code check passed. The full card number is never among them.

Stripe is a payment processor in its own right and handles your card details under its own privacy policy, which is the one that governs them. Your card statement will show our account name followed by ADRENALINE, so the line is recognisable.

Sign-ins

When somebody tries to sign in to an account we record the time, the email address used, whether it worked, the IP address the request came from and the browser and platform from the user agent. Nothing about what you do once you are signed in is recorded here.

Failed attempts are recorded too, and they are the point: “somebody tried and could not get in” is the thing worth being able to see. One consequence follows and is worth stating rather than leaving to be discovered — if somebody types an address that has no account here, that attempt is still logged, so this table can briefly hold an email address belonging to somebody who has never shopped with us. The alternative would be to check whether an account exists before deciding to log, and that would leak who has an account into the behaviour of the log itself.

You can see your own last five on your account page. Nobody else can: the table grants nothing to the public keys this site ships, so it is reachable only by the server, and the server only ever asks for the address on your own session.

It is deleted after 30 days. Not by a script somebody has to remember to run — by a scheduled job inside the database, which runs whether or not anybody visits the site. An IP address is roughly where you are, and thirty days is long enough to answer “was that me?” without the shop keeping a map of where its customers have been.

How long any of this is kept

Sign-in records are deleted after 30 days, on a schedule, as described above — that is the one thing here with a real retention period, and it has one because it is the one thing here that is personal data of that kind. Mailing-list rows and chat transcripts are kept until somebody deletes them by hand. The analytics table was designed to be pruned, and the pruning has not been built. Umami’s visit counts are kept until somebody deletes them, too; no retention period has been set for them.

Who holds it, and how to ask

Adrenaline is run by Zingo World, registered in Australia under ABN 79 231 531 384, and it ships to 28 countries. About links that number to the national register, so you can confirm the company exists before you give it an email address.

To ask what is held about you, or to have it deleted, use the contact form or write to hello@adrenaline-shops.com. The two things that could be held are your address on the mailing list and a chat transcript; for the mailing list, the address you write from is enough to find it.

What would change this page

Four things, each of which rewrites a section above: a payment provider being connected, the typeface being served from this site instead of Google’s, a retention job existing, and an inbox existing. Until one of them happens this page is not waiting on a decision — it is describing what the site does today, which is what it is for.