Cookie & Tracking Notice.

Last updated: 11 October 2026

This notice explains what we store on your device and what we send to third parties. It supplements our Privacy Policy. It covers two quite different things, and the distinction matters: our public marketing website (pitlanehq.com.au) and sign-up page, where we run advertising and analytics tools when configured; and the product after you log in, where we load none. The product is not free of advertising data flows, though — section 2A covers what does happen, which is on our servers rather than through a cookie.

1. The short version

• After you log in, product cookies keep you signed in and remember your settings. We load no advertising or analytics tags there. We also set first-party attribution cookies on the marketing website and at sign-up: plhq_ft records the first campaign that brought you to us, and pitlane_refcredits a referral partner. Both are listed below.
• Advertising platforms can still receive data about a workshop's customers from inside the product, though not through a cookie: where a workshop connects its own Google, Meta, Microsoft, TikTok or LinkedIn advertising accounts, or its own Google Analytics 4 property, our servers send conversion events as its customers move through the funnel. Section 2A says exactly what. An earlier version of this notice denied this outright.
• On the marketing website and the sign-up page, we load Google Analytics 4, Google Tag Manager and Meta Pixel when configured. These tools can send data to overseas companies. There is also a flow with no tag and no cookie: if you send us an enquiry, start a trial or subscribe, our servers report that to PitlaneHQ's own Google, Meta and Microsoft advertising accounts, with your email address hashed (and your phone number too, if you gave us one on an enquiry form). Section 3 says exactly what.
• You can block the tracking on the marketing website and sign-up page. Section 5 tells you how, including the browser-level and platform-level controls that work regardless of anything we do. Those controls act on tags in your browser, so they do not reach either of the server-side flows on this page, and the two stop for different reasons. The sends about a workshop's customers (section 2A) stop when the workshop disconnects the platform, when you opt out of that workshop's marketing, or, for conversion events, at the consent gate where it applies. The sends about our own enquirers and subscribers (section 3) are not covered by any of those — no workshop is involved and there is nothing to disconnect, so if you enquire on this website there is nothing you can switch off yourself; the route is to ask us at privacy@pitlanehq.com.au.
• We are honest below about the state of our consent tooling rather than claiming a banner we have not shipped.

2. Product and attribution cookies

Cookies that keep you signed in and remember your settings are strictly necessary for the product to work. The attribution cookies help us credit referral partners and measure campaigns. For server-side advertising data flows from inside the product, see section 2A.

Cross-site request forgery protection generally does not use a cookie — it is done by checking where the request came from. The exception is the connection-state cookie in the table above, which is a forgery check for one specific thing: attaching a third-party account, or signing in with one. The sign-in hand-off cookie beside it is not a forgery check; it only carries a pending two-factor challenge from one page to the next. An earlier version of this notice said we used no such cookie at all, which was wrong in the other direction.

2A. Advertising data sent from inside the product

We set no cookie for this and load nothing into your browser for it, which is why it sits outside the table above. It still belongs in this notice, for two reasons: it is how data about a workshop's customer reaches an advertising platform from inside the product, and the values it forwards include advertising cookies (_fbc, _fbp, _ttp) already set on the page that customer arrived through.

PitlaneHQ has a marketing-attribution feature. A workshop can connect its own advertising accounts — Google Ads, Meta, Microsoft Advertising, its own Google Analytics 4 property, TikTok, LinkedIn — and when it has, our servers report conversions back to them as that workshop's customers move through the funnel: an enquiry made, a quote sent, a quote accepted, an invoice paid. Email addresses and phone numbers are SHA-256 hashed first, and so are names, for every platform that receives them but one. Some things are not, because the receiving platform will not match them hashed: ad click identifiers and the advertising cookie values picked up from the page the customer arrived through; the customer's IP address and browser user-agent, for Meta and TikTok; country and postcode, for Google Ads; and a plain-text first and last name for LinkedIn, in the case where we hold no hashed email or LinkedIn identifier for that person.

There is a second flow on the same footing: where the workshop has separately accepted Google's, Meta's or Microsoft's customer-data terms, hashed contact lists are uploaded to Google Customer Match, Meta Custom Audiences and Microsoft Customer Match to build advertising audiences: customers with an invoice paid in the last 540 days, and customers sent a quote in the last 90 days that has not converted. Google and Meta receive a hashed email and a hashed phone number, each only where we hold it for that customer; Microsoft receives a hashed email and never a phone number, because its list format has no phone field. Connecting the account alone does not turn that on.

Nothing is sent for a workshop that has connected nothing, and no conversion event is sent about a customer who has opted out of marketing. The audience uploads exclude them too, and additionally exclude anyone who has asked to be erased. Coming off a list already uploaded differs by platform: an erasure request tells Google and Meta to remove those identifiers, while Microsoft gets no such instruction — the daily upload replaces the whole list, so the person drops out when the next daily replace runs, and stays in the list Microsoft already holds if that sync stops first. The platform-by-platform field list is on our Sub-processors page. If you are a workshop's customer and want to know whether this is switched on, ask that workshop — it controls the connection, and it is the responsible entity for its own customer records.

3. Tracking on the marketing website and sign-up page

These are not strictly necessary. They exist so we can understand which pages bring us customers and measure our own advertising. Tags load when configured. On the sign-up page, they load only with allow-listed query parameters for campaigns, ad clicks, plans, referrals and errors, and with no '@' in any parameter value, including when encoded. The referrer must be empty or from another web address (a different origin), or its query must pass the same rule when it is from our own origin. Email parameters and pending sign-up keys are removed from the address after the page captures the values it needs.

We do not sell personal information and we do not share it with data brokers. Google and Meta are listed on our Sub-processors page, and these tools can involve disclosure outside Australia — see the cross-border section of our Privacy Policy.

3.1 Our own advertising conversions (no tag, no cookie)

The table above is the browser side, and it is not the whole picture. When you submit an enquiry or demo request on this website, start a trial, or become a paying subscriber, our servers report that event to PitlaneHQ's own advertising accounts — Google Ads, Meta (via its Conversions API) and Microsoft Advertising — and to our own Google Analytics 4 property. This is us measuring our own advertising. It is mechanically the same kind of server-to-server send as section 2A, but the data is about you as our enquirer, no workshop is involved, and no workshop can switch it off.

What goes: your email address, SHA-256 hashed before it leaves our servers, together with the event (enquiry, trial start, subscription), its value and currency, and the time. Your phone number goes too, hashed, but only for an enquiry made through a form on this website — that is the only one of the three events where we hold one, so the trial and subscription events carry the email alone. Each send also carries our own ID for the event. In these server-side conversion sends, your name, your message and your company do not go. Google Analytics 4 receives no email address or phone number at all; it gets our own record ID for the enquiry or workshop instead.

What this means for the controls in section 5: they will not stop it. Blocking cookies or installing a tracker blocker acts on tags running in your browser, and none of this runs in your browser. There is no self-service switch for it either. If you would rather we did not, ask us at privacy@pitlanehq.com.au: we do it by hand rather than through a switch in the system, and we will stop sending further events about you. An event already sent cannot be recalled, and we would rather say all of that plainly than let section 5 imply a control it does not have.

4. The honest state of our consent tooling

We do not currently present a cookie consent banner on the marketing website or sign-up page. Configured analytics and advertising tags load when you visit, except on the sign-up URLs described in section 3. We are telling you that rather than describing a control that does not exist.

You can block browser tags with a tracker blocker or use the browser and platform controls in section 5. These controls do not stop server-side sends. To opt out of our own server-side advertising events, contact us at privacy@pitlanehq.com.au.

5. How to turn tracking off

These work whatever we do, which is why we are pointing you at them:

• Block third-party cookies in your browser. Every current browser can do this, and most can block trackers by category. Safari and Firefox block a great deal by default.
• Google Analytics opt-out. Google publishes a browser add-on that stops GA4 measuring you on every site that uses it.
• Meta ad preferences. Your Facebook or Instagram settings include controls over off-platform activity, including the ability to disconnect activity businesses have sent to Meta about you.
• Browser privacy modes and tracker blockers both prevent these tags from loading.

Blocking non-essential tracking does not degrade the marketing website or the product in any way. Blocking the sign-in cookies in section 2 will stop you being able to sign in — those are what keep your session alive.

What these controls do not reach. Every control above acts on something running in your browser. Neither server-side flow on this page runs in your browser, so none of them stops the sends in section 2A (about a workshop's customers) or section 3.1 (about people who enquire with us). For section 2A, ask the workshop — it controls the connection and your marketing opt-out with it. For section 3.1, ask us at privacy@pitlanehq.com.au. We would rather point you at the control that works than list one that does not.

6. Embedded widgets on workshop websites

Workshops can embed our booking and messaging widgets on their own websites through Pitlane Connect.

Correcting an earlier version of this notice: it said the widgets set “no advertising or analytics cookies”. That was wrong. The embed surfaces record a pageview (anonymous until the visitor submits an enquiry or booking through the widget, when the workshop's records link the pages they viewed to it) and set a first-party cookie named pitlane_ev (1 year) so a returning visitor's journey on that one site is counted once rather than twice. It is set on our own domain and is partitioned under CHIPS, meaning the browser scopes it per top-level site — it cannot be used to follow anyone from one workshop's website to another. No advertising cookies are set and the widget loads no Google or Meta tags.

The Pitlane Connect analytics beacon. A workshop that wants to know which pages its visitors read can add one script to its own site — the Pitlane Connect beacon, /connect/beacon.js, pasted beside the widget snippet. On each page view allowed by the consent rules, the beacon reports that view to our server, and the server replies with the consent policy that applies to the visitor's region. That reply is a statement of our regional rule, not permission or confirmation for that particular view: the view has already been sent by the time the reply arrives, and the server returns the same policy whether or not the view was stored. Where policy allows, the beacon writespitlane_vid (90 days), a first-party cookie on the workshop's own domain, if the visitor has no identifier for that site yet.

pitlane_vid holds one opaque random identifier and nothing else — no name, no email address, no phone number. Its whole job is continuity: it is what lets the pages someone read be matched to the booking or enquiry they later submit through the widget, so the workshop can see what a lead was browsing before they got in touch. The page views stay anonymous until that submit; from then on the browsing is attached to that lead's record. Because each site sets the cookie on its own domain, it cannot follow anyone from one workshop's website to another.

The consent panel and the choice it stores. Our own policy asks the visitor for consent before any page view is recorded, in every region except Australia, New Zealand and the United States — including a region we cannot determine. That is a Pitlane policy, not a claim about what any law requires. Where we ask, the beacon shows a small panel on the page offering Accept or Reject, says the choice is optional, and links to this notice. Either answer is remembered in a first-party cookie named pitlane_beacon_consent (90 days), so the question is not asked again on every page; a Reject writes that cookie and records no page view and no pitlane_vid, and deletes a pitlane_vid that is already there. Accepting lets the beacon send the page view and write pitlane_vid, and a “Privacy choices” button keeps the panel reachable so the answer can be changed later.

Choices from supported consent tools take precedence when they provide a consent signal Connect reads. When that signal records a choice, our panel and Privacy choices button are not shown, and that choice decides whether anything is recorded. Other consent controls are not detected.

A visitor in Australia, New Zealand or the United States is on the notice basis instead, so the page view is recorded with no prompt — but not unconditionally, because consent signals from supported consent tools still take precedence there, and a Reject remembered from an earlier visit stops anything being recorded. Everywhere else, including the EU, the EEA and the UK, no visitor cookie or page view is set or recorded before the visitor accepts.

If a workshop turns on the analytics beacon in our WordPress plugin, the plugin sets that same pitlane_vid cookie (90 days) on the workshop's own domain so a returning visitor is recognised on that site. It is off until the workshop turns it on in the plugin's own settings. In the EU, UK and EEA the plugin records a page view only after the visitor opts in. A workshop can override those regions to “Notice” mode instead, and then the plugin sets the cookie as soon as the page loads, with no opt-in at all — but Pitlane still records nothing from it, because our server drops any event that names one of those regions, or names no region, unless it carries an opt-in.

The WordPress plugin stores the visitor's consent choice in its own first-party cookie named pitlane_consent (180 days) on the workshop's domain. It also writes a copy of that choice to localStorage under the same name, which the plugin does not read back. Where the workshop uses “Notice” mode, it stores whether the visitor closed the notice in localStorage as pitlane_consent_notice. Neither localStorage entry has an automatic expiry. These are separate from the pitlane_vid visitor identifier and the beacon's pitlane_beacon_consent cookie.

The workshop's own website may run its own tracking, which is the workshop's responsibility and governed by their privacy policy, not this notice.

7. Changes

We will update this notice when we add or remove a tracking technology, and the “Last updated” date will change. If we add a tool that receives personal information about you, it will also appear on the Sub-processors page.

8. Contact

• Privacy: privacy@pitlanehq.com.au
• Phone: 07 4800 9005