Privacy Policy
ShotLab TOUR
Effective date: 10 September 2026
Version: 2026-09-12
Supersedes: the policy dated 16 June 2026
1. Controller and scope
ShotLab TOUR (the "Service") is a golf swing analysis web application operated by Oliver Seydlitz (the "Operator", "we", "us", "our") and published at https://shotlab.oliverseydlitz.com. The Operator is the data controller for the personal data described in this policy.
The Operator is established in the Czech Republic. Processing is therefore governed by Regulation (EU) 2016/679 (the General Data Protection Regulation) and by Czech Act No. 110/2019 Coll., on the processing of personal data. The competent supervisory authority is the Office for Personal Data Protection (Úřad pro ochranu osobních údajů), Pplk. Sochora 27, 170 00 Prague 7, Czech Republic, https://uoou.gov.cz.
No data protection officer has been appointed. The Operator is not a public authority, does not carry out large-scale systematic monitoring, and does not process special categories of data on a large scale, so none of the conditions in Art. 37(1) GDPR applies. Privacy matters are handled directly by the Operator at the address below.
Contact for all privacy matters, including requests to exercise the rights described in Sections 9 and 10: shotlab_legal@oliverseydlitz.com.
This policy applies to the Service and to the cloud database that supports it. It does not apply to any third-party site or service reached from the Service, including those listed in Section 6.
This policy forms part of, and is incorporated into, the Terms of Service.
2. Summary of processing
The Service operates in two modes.
Guest mode. No account is created and no personal data is transmitted to the Operator or to any cloud service. Imported sessions are held in the browser tab's memory and are lost when the tab is closed, unless the user enables the "Keep sessions on this device" setting described in Section 5.3, in which case they are written to the browser's own storage on the user's device only.
Signed-in mode. An account is created through Supabase Auth. Account data and session data are stored in a Supabase project hosted in the European Union and are accessible only to the account that created them.
3. Categories of personal data processed
3.1 Data provided by the user
| Category | Detail | Applies to |
|---|---|---|
| Account identifier | Email address | Signed-in users |
| Authentication credential | Password, transmitted to and stored by Supabase in hashed form; never stored by the Operator in any form | Signed-in users who register with email |
| Federated identity data | Email address and basic profile identifier received from Google when Google Sign-In is used | Signed-in users who use Google Sign-In |
| Launch monitor data | Club type, ball speed, club speed, smash factor, carry distance, launch angle, launch direction, attack angle, club path, spin rate, spin axis and related values imported from a launch monitor CSV export | All users |
| Session metadata | Session date, ball type, hitting surface, alignment confirmation, free-text notes and tags entered by the user | All users |
| Practice records | Putting and chipping results, on-course round statistics, practice log entries and retention-probe answers entered by the user | All users |
| Preferences | Theme, goals, view settings and the settings recorded in Section 5.2 | All users |
| Terms acceptance record | Account identifier, which version of these documents was accepted, whether the experimental-software acknowledgement was given, and the timestamp | Signed-in users |
Free-text session notes and tags are user-supplied. Users are asked not to enter data about identifiable third parties, health information, or any other sensitive category, because the Service applies no special handling to free text.
3.2 Data generated by the Service
The Service derives statistics, quality scores, fault classifications, practice recommendations and trend verdicts from the data in Section 3.1. These derived values are stored alongside the source data and are subject to this policy in the same way.
The Service does not collect, and does not ask for, precise location, contacts, demographic information, health data, device fingerprints, or any identifier beyond the account identifier described above.
3.3 Data collected automatically
The Service sets no analytics cookies, contains no advertising or tracking pixels, operates no profiling for marketing purposes, and makes no request to any third-party server while it loads. Typefaces and code libraries are served from the Service's own origin rather than from a content delivery network, so no third party receives the user's IP address as a side effect of opening the application.
Supabase records standard server-side connection logs for the requests the Service makes to it, which may include IP address, user-agent string and timestamp. GitHub, as the host of the static site, may record equivalent logs for requests to the site itself. Neither log is accessible to, or aggregated by, the Operator for any purpose other than security and abuse investigation, and the Operator does not combine them with account data.
4. Purposes and legal bases
The table below sets out each purpose of processing and the legal basis relied upon under the UK GDPR and EU GDPR. Where consent is the basis, it may be withdrawn at any time under Section 9.6 without affecting the lawfulness of processing carried out before withdrawal.
| Purpose | Legal basis |
|---|---|
| Creating and authenticating an account; maintaining account security | Performance of a contract (Art. 6(1)(b)) |
| Storing, synchronising and returning the user's own session data across the user's devices | Performance of a contract (Art. 6(1)(b)) |
| Producing the statistics, charts, fault classifications and practice guidance that constitute the Service | Performance of a contract (Art. 6(1)(b)) |
| Storing preferences and settings on the user's device | Consent, where the storage is not strictly necessary (Art. 6(1)(a)); see Section 5 |
| Maintaining the security and integrity of the Service, and investigating abuse | Legitimate interests (Art. 6(1)(f)) — the interest being the protection of the Service and its users, balanced against the limited and security-restricted nature of the data used |
| Recording which version of the Terms and Privacy Policy an account accepted | Legitimate interests (Art. 6(1)(f)) — establishing and evidencing the agreement between the parties, which cannot be done from a record the user's browser can erase. The data is an account identifier, two version strings and a timestamp |
| Complying with legal obligations, including responding to rights requests | Legal obligation (Art. 6(1)(c)) |
The Operator does not process special categories of personal data under Art. 9 and does not seek to do so.
5. Storage on the user's device
5.1 Nature of the storage
The Service is a static web application. All storage on the user's device is browser storage — localStorage, sessionStorage and IndexedDB — and not conventional HTTP cookies set by the Operator. Browser storage of this kind is treated in this policy as equivalent to cookies for the purposes of the ePrivacy Directive and the UK Privacy and Electronic Communications Regulations.
None of this storage is encrypted. Any person or software with access to the browser profile can read it. The Service should not be used on a shared or untrusted device.
5.2 Items stored
| Key | Purpose | Category | Retained until |
|---|---|---|---|
sb-<project>-auth-token | Supabase authentication session, set and managed by the Supabase client library | Strictly necessary | Sign-out, token expiry, or browser data cleared |
slTermsAccepted | Record of which version of the Terms was accepted, so acceptance is not requested repeatedly | Strictly necessary | Browser data cleared |
slCookieConsent | Record of the user's storage-consent choice | Strictly necessary | Browser data cleared |
slGuestChosen | Record that the user chose to continue without an account | Strictly necessary | Browser data cleared |
slKeepLocal | Whether "Keep sessions on this device" is enabled | Strictly necessary | Browser data cleared |
slSeenIntro | Whether the first-run orientation screen has been shown | Preference | Browser data cleared |
slTheme | Light or dark appearance | Preference | Browser data cleared |
slViewPrefs | Which dashboard sections are shown | Preference | Browser data cleared |
slGoals | Targets set by the user | User content | Deletion in app, or browser data cleared |
slLastConditions | Last ball type and surface used, to prefill the import form | User content | Deletion in app, or browser data cleared |
slPutts | Quiet-eye putting results | User content | Deletion in app, or browser data cleared |
slShortGame | Chipping and putting drill results | User content | Deletion in app, or browser data cleared |
slRounds | On-course round statistics | User content | Deletion in app, or browser data cleared |
slPracticeLog | Practice blocks marked complete | User content | Deletion in app, or browser data cleared |
slProbes | Retention-probe records | User content | Deletion in app, or browser data cleared |
slDebug | Diagnostic logging, off by default and set manually | Preference | Browser data cleared |
| IndexedDB store | Imported sessions, written only when "Keep sessions on this device" is enabled | User content | Setting disabled, deletion in app, or browser data cleared |
| Service worker cache | Copies of the application's own files, for offline use. Contains no personal data | Strictly necessary | Cache version change, or browser data cleared |
The Supabase authentication token is held in localStorage, not in an HttpOnly cookie. This is a consequence of the Service being a static site with no server able to set such a cookie. It means the token is readable by scripts running in the page, and the Operator relies on a restrictive Content-Security-Policy and on output escaping to mitigate that risk. Users concerned by this should sign out when finished, and should not use the Service on a device they do not control.
5.3 "Keep sessions on this device"
This setting, in Settings → Data & Export, is off by default. While it is off, imported sessions are held in memory only and are lost when the tab closes.
Enabling it writes sessions to IndexedDB on the device. It applies to sessions already imported during the current visit as well as to future imports. Disabling it erases the stored copy immediately rather than only preventing further storage. Deleting a session, or clearing local data, removes the stored copy. If the browser refuses to provide storage — for example in private browsing, or where site data is blocked — the setting will not enable and the Service reports this rather than appearing to succeed.
This setting is independent of signing in. It governs storage on the device only.
5.4 Consent, refusal and withdrawal
Items marked "strictly necessary" in the table above are exempt from the consent requirement in Art. 5(3) of Directive 2002/58/EC, as implemented by Section 89(3) of Czech Act No. 127/2005 Coll., because they are required to provide a service the user has explicitly requested. They are not optional, and the Service cannot function without them.
Everything else is optional. The storage notice shown on first use offers acceptance and refusal with equal prominence and equal effort, and no optional item is written before a choice is made. Refusing removes any optional item already stored rather than merely preventing further writes. The choice may be changed at any time from Settings, and clearing site data in the browser removes every item in Section 5.2.
Continued use of the Service is not treated as consent. Consent within the meaning of Art. 4(11) GDPR requires a clear affirmative act, and browsing is not one.
6. Recipients and processors
The Operator does not sell, rent, licence or trade personal data, and does not disclose it to any third party except as set out below.
| Recipient | Role | Data received | Basis |
|---|---|---|---|
| Supabase, Inc. | Processor — authentication, database, hosting of the account and session data | Email address, hashed password, session and practice data, preferences synced to the account | Data processing agreement under Art. 28 |
| GitHub, Inc. | Processor — static hosting of the application files | Connection metadata only, as described in Section 3.3 | Data processing agreement under Art. 28 |
| Google LLC | Independent controller — only where the user chooses Google Sign-In | The authentication exchange itself. Google returns an email address and identifier to the Service | The user's own decision to authenticate with Google |
The Operator may also disclose personal data where required to do so by law, by a court of competent jurisdiction, or where necessary to establish, exercise or defend legal claims.
Supabase's privacy terms are at https://supabase.com/privacy. Google's are at https://policies.google.com/privacy.
7. Location of processing and international transfers
The Supabase project used by the Service is hosted in the European Union (Ireland, eu-west-1). Account and session data are stored there and are not routinely transferred outside the European Economic Area.
Supabase, Inc. and GitHub, Inc. are incorporated in the United States, and support or administrative access from the United States is possible. Any such transfer is made under the European Commission's Standard Contractual Clauses adopted by Implementing Decision (EU) 2021/914, as incorporated into each processor's data processing agreement, supplemented by the technical measures described in Section 11. Where a processor is certified under the EU-US Data Privacy Framework, that adequacy decision may be relied on in addition.
Google LLC receives personal data only where a user chooses Google Sign-In, and acts as an independent controller in that exchange under its own terms.
A copy of the relevant transfer mechanism may be requested at the address in Section 1.
8. Retention
| Data | Retained for |
|---|---|
| Account record and all associated session, practice and preference data | The life of the account. Deleted on account deletion, without a grace period |
| Data held in browser storage | Until the user deletes it, disables the relevant setting, or clears site data. Not retained by the Operator |
| Guest session data held in memory | The life of the browser tab |
| Supabase and GitHub server logs | The retention period operated by each processor, over which the Operator has no control |
| Terms acceptance record | The life of the account. Deleted with the account by cascade. Not editable or deletable by the user in isolation, because a record of what was agreed is worthless if either party can rewrite it |
| Correspondence relating to a rights request | Twenty-four months, as a record that the request was handled |
The Operator operates no separate backup of the production database, and no copy of deleted account data is retained by the Operator after deletion.
9. Rights of data subjects
Users in the European Economic Area and the United Kingdom have the rights set out below under the GDPR and, respectively, Czech Act No. 110/2019 Coll. and the UK GDPR. Users elsewhere are afforded the same rights as a matter of policy, to the extent this is technically possible. No fee is charged and no right is conditional on any other.
9.1 Access. All data held about an account is visible within the Service, and a complete machine-readable copy may be exported at any time from Settings → Data & Export.
9.2 Portability. The export in Section 9.1 is provided as JSON or CSV, both structured, commonly used and machine-readable formats.
9.3 Rectification. Session notes, tags, conditions, goals and preferences are editable within the Service. Corrections to an email address, or to any value not editable in the Service, may be requested at the address in Section 1.
9.4 Erasure. An account and all data associated with it may be deleted from within the Service at Settings → Account → "Delete my account & data". Deletion is immediate and irreversible. It removes the authentication record and, by cascading deletion, every database row belonging to that account, including its session data and its Terms acceptance record. The Operator keeps no separate backup of the production database, so no copy survives deletion on the Operator's side; the processors named in Section 6 operate their own infrastructure-level backups on their own cycles, over which the Operator has no control. A separate control at Settings → Data & Export → "Clear all local data (keep account)" removes data from the device only and does not affect the account. Erasure may also be requested at the address in Section 1.
9.5 Restriction and objection. Processing may be restricted, or objected to where it is carried out on the basis of legitimate interests, by contacting the address in Section 1. Because the Service's core function is the processing of the user's own data at the user's request, a successful objection will in most cases mean the account can no longer be operated.
9.6 Withdrawal of consent. Where processing is based on consent, consent may be withdrawn at any time as described in Section 5.4, or by contacting the address in Section 1.
9.7 Complaint. A complaint may be lodged with a supervisory authority, in particular in the member state of habitual residence, place of work, or place of the alleged infringement. The Operator's lead supervisory authority is the Czech Office for Personal Data Protection (Úřad pro ochranu osobních údajů), https://uoou.gov.cz. Users in the United Kingdom may instead contact the Information Commissioner's Office, https://ico.org.uk. Users are asked, but not required, to raise the matter with the Operator first.
9.8 Compensation. Art. 82 GDPR gives a right to compensation for material or non-material damage caused by processing that infringes the Regulation. That right exists independently of these documents and is not affected by any limitation of liability in the Terms of Service.
9.9 Making a request. Requests should be sent to shotlab_legal@oliverseydlitz.com from the email address registered with the account. A response will be provided within one month of receipt, extendable by two further months where the request is complex, in which case the user will be told within the first month. No fee is charged unless a request is manifestly unfounded or excessive.
10. Rights of California residents
Under the California Consumer Privacy Act as amended by the California Privacy Rights Act, California residents have the rights below. The Operator has not sold or shared personal information, as those terms are defined in the CCPA, in the preceding twelve months, and does not do so. The Operator does not use or disclose sensitive personal information for any purpose requiring a right to limit.
10.1 The right to know the categories and specific pieces of personal information collected, the categories of sources, the business purposes for collection, and the categories of third parties to whom it is disclosed. This information is in Sections 3, 4 and 6. The source of all personal information is the user, except for the federated identity data received from Google described in Section 3.1.
10.2 The right to delete personal information, exercisable as described in Section 9.4.
10.3 The right to correct inaccurate personal information, exercisable as described in Section 9.3.
10.4 The right to opt out of the sale or sharing of personal information. No sale or sharing occurs, so no opt-out mechanism is required or provided.
10.5 The right not to receive discriminatory treatment for exercising any of these rights. The Service is provided on identical terms regardless of whether a right is exercised.
Requests may be submitted to the address in Section 1 and will be verified against the email address registered with the account. An authorised agent may submit a request on a consumer's behalf with written proof of authorisation.
11. Security
Traffic between the browser and both GitHub and Supabase is encrypted in transit using TLS, and HTTP Strict Transport Security is enforced. Data at rest in the Supabase project is encrypted by the processor.
Access to account data is restricted at the database level by row-level security policies scoped to the authenticated account, which are enforced by the database rather than by application code, and which are additionally forced against the table owner. Anonymous database roles hold no privileges over account data, and signed-in roles hold only the specific privileges the application uses. Row size, row count and per-account session ceilings limit the impact of misuse. The Service applies a restrictive Content-Security-Policy that permits scripts, styles and fonts only from its own origin, and escapes user-supplied text before rendering it.
Cross-account isolation is tested rather than assumed. Reading, updating, deleting and forging rows belonging to another account were each attempted directly against the production database as an authenticated user in September 2026, and each returned no rows and changed nothing.
No transmission or storage method is completely secure, and the Operator does not warrant that the Service or its processors cannot be compromised. The specific limitations of browser storage are set out in Section 5.
Where a personal data breach occurs that is likely to result in a risk to the rights and freedoms of data subjects, the Operator will notify the relevant supervisory authority within seventy-two hours of becoming aware of it, and will notify affected users without undue delay where the breach is likely to result in a high risk to them.
12. Automated processing
The Service produces automated statistics, quality scores, fault classifications and practice recommendations from the user's own data. These are informational outputs presented to the user. They produce no legal effect and no similarly significant effect within the meaning of Art. 22 of the UK GDPR and EU GDPR, and the Service does not carry out automated decision-making, profiling for marketing, or any form of scoring that affects a user's access to the Service or to anything outside it.
All of it is produced by fixed rules and a fixed library held inside the application. No artificial-intelligence or machine-learning provider is used, and no personal data of any kind is sent to one. Analysis runs in the browser; the only data leaving the device is the user's own session record being saved to their own account.
13. Age
The Service is intended for users aged eighteen or over and is not directed at children. The Operator does not knowingly collect personal data from anyone under eighteen. Where the Operator becomes aware that such data has been collected, it will be deleted without undue delay. A parent or guardian who believes a child has provided personal data should contact the address in Section 1.
14. Changes
This policy may be amended. The version identifier and effective date at the head of the document will be updated, and the previous version's date recorded. Where an amendment materially changes the purposes of processing, the categories of data processed, or the recipients of that data, signed-in users will be notified in the Service before the amended policy takes effect, and acceptance will be requested again.
Continued use of the Service after an amendment takes effect constitutes acceptance of the amended policy, except where consent is separately required.
15. Contact
Oliver Seydlitz, Operator of ShotLab TOUR
shotlab_legal@oliverseydlitz.com
Requests concerning data protection should identify the right being exercised and the email address registered with the account.