Privacy Policy

1. Who This Policy Covers

This policy applies to all users of the TrackDataLab, Inc. platform:

• Coaches (Account Holders) — individuals who create and manage a TrackDataLab, Inc. coach account, acting for their school, organization, or program as applicable.
• Assistant Coaches — additional users added to a coach account by the head coach, with access scoped to permissions the head coach configures.
• Athletes — individuals whose performance data is recorded by coaches, and who may independently access their own data through the TrackDataLab, Inc. Athlete App using their own authenticated account.
• Website Visitors — individuals who visit trackdatalab.com without creating an account.

Account authorization: the authorized coach or administrator accepts a school/organization authorization on the account. Athlete join codes link students to that account; they are not independent evidence of lawful consent. See Children's Privacy.

2. Data We Collect

Coach account data:

• Email address and bcrypt-hashed password (plaintext never stored)
• Display name (optional)
• Subscription plan and billing status
• Account identifiers, creation/login timestamps, and authentication/session information
• Subscription plan, billing status, expiration, and payment-provider identifiers where configured; see Section 7

Athlete data (entered or managed by coaches):

• Athlete name or alias (coaches may use initials or pseudonyms)
• Group or team membership
• Optional gender, grade level, and graduation year
• Athletic performance metrics (times, distances, scores, custom fields)
• Attendance records (practice check-in status)
• Schedule and competition events
• Workout assignments and athlete-entered workout logs/results, where enabled
• Assessment results, derived performance calculations, and leaderboard rankings, where enabled
• Optional bodyweight and school-configured training metrics, which may contain health-related information
• Inventory/equipment checkout and return records, where enabled
• Application/roster identifiers, coach or staff associations, record dates, and season history

Athlete portal / app account data (when athletes create their own account):

• Email address and bcrypt-hashed password
• Display name (entered by the athlete at registration)
• Linked roster entry (associated with coach's account via join code)
• Authentication cookies/tokens and browser storage used by the mobile/web athlete portal

Technical and communications information: service requests can involve IP addresses, cookies/session identifiers, browser/request metadata, and record/activity timestamps. Support messages and account-related emails can contain names, email addresses, or student information voluntarily supplied. Service data can also exist in live records, archives, recovery snapshots, and backups. See Sections 10, 13, and 14.

Website usage: basic first-party page-visit measurement records the requested page path (including query parameters), referring page, browser/user-agent information, and visit time. This supports understanding website use, not targeted advertising or commercial student profiles. Avoid putting sensitive student information in page URLs or query parameters.

Data minimization: only enter information necessary for the authorized athletic or educational purpose. Custom metrics, imports, and free-text content require special care because they can contain information beyond the standard fields. We do not ask for or require athlete dates of birth. We retain an account-level authorization record identifying the accepting coach/administrator, acceptance time, attestation text, and Terms/Privacy Policy versions. Older age-eligibility metadata may remain in existing records but is not used to determine access.

Do not submit:

• Social Security numbers, government IDs, or financial account information about athletes
• Clinical medical records, health insurance information, or biometric identifiers; optional bodyweight/training metrics are disclosed separately above
• Unnecessary athlete home addresses or phone numbers; athlete account email addresses are collected for authentication
• Geolocation data or GPS coordinates
• Cross-site browsing histories, advertising identifiers, or device fingerprints for commercial profiling

3. Coach–Athlete Relationship & Data Ownership

For school-authorized use, the school retains authority over covered education records and directs their use under applicable law and the signed agreement. Coaches act within that authority; a coach account does not override a school's or student's legal rights. For non-school use, the responsible organization or account holder's role depends on the circumstances and applicable law.

• Records are associated with the responsible team account. School agreements and applicable law govern ownership, permitted use, access, and disposition of student records.
• Athlete access is scoped. Linked athletes can access their own results and the group information, workouts, schedules, or leaderboards their account is authorized to view.
• Coaches control what athletes can see. Coaches configure which sections (schedule, leaderboard, workout, reporting, assessment) are visible to athletes on a per-join-code basis. Coaches may restrict or expand access at any time.
• Leaderboards are limited. Leaderboard views exposed to athletes show athlete names and aggregate ranking values only — not full metric breakdowns, raw trial data, or assessment profiles of other athletes.
• Access follows authorization. Team associations, assigned groups, and permissions restrict ordinary account access. Authorized administrative/support access must be limited to legitimate service, security, or legal purposes.

4. Athlete Portal & Mobile App

TrackDataLab, Inc. provides a dedicated Athlete App (available as a mobile and web application) that allows athletes to independently access data their coach has made available to them.

When an athlete uses the Athlete App:

• They can view their individual performance results and trends
• They can view their personal assessment profile (if enabled by the coach)
• They can view the group leaderboard (aggregate rankings, names + best score only)
• They can view workouts and schedules assigned to their group
• They cannot view any other athlete's individual metric history, assessment breakdown, or attendance records
• They cannot view athletes in other groups unless the coach has explicitly included them

Athlete app accounts are separate from coach accounts and are linked to a roster and coach account through the service's account-linking process. A join code grants only the configured access under the account's school/organization authorization; it does not itself establish the school's legal authority to disclose records. Changes to links and access must preserve the school's control of its records.

5. How We Use Data

We use collected data only to:

• Provide, operate, and improve the TrackDataLab, Inc. platform
• Display performance data, reports, and leaderboards to authorized coaches, assistants, and athletes
• Send transactional emails (account creation, password resets, billing confirmations, security alerts)
• Administer subscriptions, school purchasing arrangements, and payment-provider records where configured
• Enforce subscription plan limits (athlete roster capacity)
• Ensure account security and prevent unauthorized access
• Comply with legal obligations and respond to lawful requests

We never:

• Sell coach, athlete, or student data to any third party
• Use athlete or student data for targeted advertising or behavioral profiling
• Share athlete data with third parties for commercial purposes
• Use student data for any purpose other than delivering the service requested by the coach or institution
• Train AI or machine learning models on any user or athlete data

6. Data Isolation & Access Controls

TrackDataLab, Inc. uses account, role, and group-based controls to restrict access:

• Team access is scoped. Ordinary users must be authenticated and authorized for the requested team records. Authorized staff/support functions are subject to their administrative permissions.
• Athlete portal access requires authorization. Protected data requests require a valid account and the corresponding roster/group permissions.
• Join codes are scoped. An athlete registered via a specific join code can only see data within the groups and sections that code grants access to.
• Public dashboards are disabled. Join codes support account onboarding, not anonymous publication of student dashboards. Athletes view authorized group leaderboards through their authenticated accounts.
• Assistants have restricted access. Assistant access follows assigned groups and permissions; head-coach-only functions remain restricted.

7. Payment & Billing Data

Account records can include subscription plan, status, pricing, expiration, and payment-provider identifiers where configured. A school's service agreement, purchase order, invoice, or the terms shown at purchase determine billing and renewal arrangements.

• Do not send payment-card details or taxpayer identifiers through ordinary support messages or athlete records. Use the designated secure purchasing or payment process.
• When Stripe is used, its payment service handles information submitted through its checkout; its privacy notice applies to that processing. This policy does not represent that Stripe checkout or a billing portal is currently enabled.
• Business billing records are separate from student athletic records and must have an appropriate accounting/legal retention schedule.
• Starting the 14-day trial does not require any payment information.

If Stripe is used, see Stripe's privacy policy. The payment provider and purchasing terms must be identified when payment is arranged.

8. School Records & FERPA

When TrackDataLab, Inc. is used by a school or educational institution, student performance data may constitute "education records" under FERPA. In such cases:

• The school retains ownership and control of student education records.
• A school must determine its lawful basis for disclosure and whether the conditions for using a service provider under FERPA, including any applicable school-official exception, are satisfied. This status is not established simply by creating a coach account.
• We do not disclose student education records to third parties without written consent, except as permitted by FERPA.
• Schools may request access to, correction of, or deletion of student records at any time through our contact form.

Schools and districts should execute a Data Processing Agreement (DPA) with TrackDataLab, Inc. before use. DPAs are available upon request — please submit a request through our contact form.

9. Student Privacy Laws (SOPPA, COPPA & Similar)

School use is subject to applicable student privacy laws and the executed agreement. Illinois SOPPA and FERPA-related requirements may apply regardless of a student's age. Requirements in other states or countries must be assessed for the actual use. We do not claim blanket certification under student privacy laws.

• We do not sell student data.
• We do not use student data to advertise to students or other parties.
• We do not build behavioral or commercial profiles on students.
• Student data is used solely to provide the TrackDataLab, Inc. service.
• Schools and parents retain the right to request deletion of student records.
• School breach notices follow the earliest applicable legal or contractual deadline. The supplied Illinois IL-NDPA requires notice generally within 72 hours of confirmation, subject to its lawful law-enforcement exception; see Section 17.

Children's Privacy

TrackDataLab is provided to schools and organizations for their educational and athletic programs. Athlete accounts and records are created by, or at the direction of, the school or organization. We do not ask students to provide an individual age confirmation or require athlete dates of birth.

For students under 13 in school-authorized services, we rely on the school to provide consent on behalf of parents, as permitted under COPPA, for collection and use of student information solely for the school's educational and athletic program purposes and no unrelated commercial purpose. Student information is used only to provide the service to the school or authorized program, never for advertising or selling. We provide schools notice of our collection, use, and disclosure practices through this policy and applicable agreements; an account attestation does not replace required notice, lawful authority, or our own obligations as the service provider.

The coach or administrator confirms that they are authorized by their school or organization to add athlete information and that required consent has been provided. The school or organization is responsible for its authority to share student information, any required parent notice, and applicable FERPA obligations. Schools are encouraged to execute a data privacy agreement (DPA). School consent on behalf of parents is not a blanket exception for non-school organizations; such organizations must obtain any legally required parental consent before directing collection of children's information.

Parents and guardians may ask their school to review, correct, or delete their child's information, or contact TrackDataLab directly or use our contact form. We coordinate with the responsible school or organization to address those requests. We do not knowingly collect information directly from a child under 13 outside a school/organization-authorized account. If we learn that this has happened, we will stop that collection and delete the information, coordinating with the responsible institution where applicable. Send only enough information to identify the account or school; do not send passwords, identity documents, or student records in an initial message.

10. Data Retention

• Retention purpose: keep personal information only as necessary for its authorized purpose, school instructions, applicable agreements, or legal/security obligations. An active account does not justify indefinite retention of every record.
• School access and disposition: the supplied Illinois IL-NDPA requires a response within 5 business days when the school needs provider cooperation for a parent's inspection/copy request, and requested deletion or transfer within 30 calendar days. Where executed, those terms and any stricter applicable requirements govern.
• Corrections and end of service: Illinois Exhibit G requires correction of a school-identified factual inaccuracy within 90 calendar days with written confirmation, and a final data-necessity review within 60 calendar days after termination. Deletion/transfer also requires written confirmation; the 60-day review period does not extend a separately applicable deletion deadline.
• Account versus record deletion: deleting an athlete login does not automatically delete the school's roster or education records. Record retention and disposition follow the responsible school's instructions and applicable rights, not merely a coach's personal preference.
• Copies and recovery: a disposition procedure must address live records, archives, recovery snapshots, backups, and applicable provider copies. Restoring a backup must not reintroduce information that should remain deleted.
• Logs, backups, and billing: their specific retention periods, lawful exceptions, and disposition methods require a verified schedule. We do not represent an unverified fixed 12-month log period, 30-day backup purge, or seven-year payment-provider retention period.

Schools may request the current retention/deletion procedures before contracting. Where a legal hold or other lawful retention requirement affects a request, it must be assessed and explained to the authorized requester as appropriate. The applicable schedule and backup-disposition capability must be confirmed during school readiness review; this policy alone does not verify completion of those controls.

11. Data Security

The application uses controls including:

• HTTPS for production access; passwords supplied in authentication requests must be protected in transit.
• bcrypt hashing for locally managed passwords rather than plaintext password storage.
• Server-side sessions and signed session cookies, with Secure and HttpOnly cookie settings; tokens/browser storage are also used by supported application flows.
• Authentication endpoints are rate-limited to prevent brute-force and credential-stuffing attacks.
• Parameterized database access and account/role/group authorization checks.
• Session-identity checks designed to reject mismatched-account state writes.

No system can guarantee that an incident will never occur. These application features do not establish completion of a NIST, ISO, CIS, or other security framework, nor do a hosting provider's certifications certify TrackDataLab, Inc. Schools may request implementation information; a framework selection in a DPA must reflect verified controls.

Report vulnerabilities or suspected student-data exposure to Tucker Platt or through our contact form. We aim to acknowledge security reports promptly; applicable incident-notice deadlines are separate and control when required.

12. Your Rights

Coaches (and schools or parents acting on behalf of athletes) have the following rights:

• Access — request a copy of all data stored in your account. Coach data is exportable as CSV from the Management tab at any time.
• Correction — use the editing features your role permits, or request correction through the school or our privacy contact.
• Deletion — use available account-deletion controls or submit a record-disposition request to our privacy contact. Account deletion and school-record deletion are different; scope and deadlines are described in Section 10.
• Portability — export athlete and performance data as CSV from the Management tab at any time without contacting support.
• Restriction — request that we limit processing of specific data. Note that certain processing is required to provide the service.
• Objection — object to processing in cases where processing is based on legitimate interests.

Athletes, parents/guardians acting within their authority, and authorized school representatives may contact our privacy lead. We may need to verify identity and authority before releasing or changing records; do not send passwords, government IDs, or a full student list in an initial ordinary email. School-controlled record requests are coordinated with the school without overriding applicable student or parent rights.

13. Third-Party Services

TrackDataLab, Inc. uses the following third-party services to operate the platform:

• Hosting, database, and private storage: Replit services support the application, database, and stored recovery files. Service-specific locations, retention, and contractual protections must be verified for school requirements.
• Transactional email: the configured SMTP email-delivery provider handles account, recovery, subscription, and service notifications, which may contain recipient email, names, or other information necessary for the message. The actual provider identity must be confirmed and included in the school-specific list; email processing is not assumed to contain no student information.
• Support correspondence: Google/Gmail supports the designated privacy/support mailbox. Correspondence can include personal or student information supplied in a request; do not send unnecessary sensitive records by ordinary email.
• Fonts and interface assets: Google Fonts and Cloudflare's cdnjs deliver interface resources. These requests can expose IP addresses and browser/request metadata to those providers; we do not describe those requests as transmitting no personal information.
• Payment/authentication providers: any additional provider actually enabled for purchasing or authentication must be included in the applicable inventory. Stripe, when used, is described in Section 7; it is not represented here as an active checkout integration.

We do not use Google Analytics, Facebook Pixel, Mixpanel, Segment, or Intercom, or place third-party advertising cookies. Basic first-party website usage measurement is described in Section 2; it is not used to advertise to students or build commercial student profiles.

A school-specific subprocessor list should identify actual services, processing purposes, covered data, and relevant storage locations. The supplied Illinois IL-NDPA requires the subcontractor list within 5 business days after execution of the DPA and updates on January 1 and July 1. Applicable signed terms govern, and required written protections must be reviewed before school data is entrusted to a provider. This website's general list is not a substitute for that review.

14. Cookies & Session Data

TrackDataLab, Inc. uses first-party session cookies, including tdl.sid, and browser storage for supported authentication flows, preferences, and locally cached application state. Session cookies:

• Use HttpOnly settings to prevent ordinary page JavaScript from reading the cookie.
• Use Secure settings for HTTPS transmission.
• Use SameSite=None with Secure where required by the configured application flow.
• Identify a server-side session and are signed; signing is not the same as encrypting the cookie.

Session lifetime and token handling depend on the authentication flow. Sign out of shared devices and protect locally stored application information. We do not use advertising cookies or tracking pixels; third-party resource requests are disclosed above. Whether additional notices or consent are required depends on the actual technologies and applicable jurisdiction; this policy does not make a universal cookie-consent exemption claim.

15. Changes to This Policy

We may update this policy to reflect changes in practices, services, or legal obligations and will update the date above. We will notify schools before making material changes to how student information is collected or used and obtain any additional authorization or consent required by law or agreement. Publishing a revised policy or continued use does not amend a signed school DPA, expand authorized student-data uses, or replace required school/parent authorization.

For questions about what constitutes a "material change," please reach out through our contact form.

16. School Agreements & Readiness

The school DPA states the provider's contractual promises. A privacy policy, a draft agreement, or an internal checklist does not prove that those promises have been implemented. Before accepting school data under an agreement, the school and provider must confirm the legal contracting party, authorized use, data inventory, and ability to meet the agreed safeguards.

• Services and data: Exhibits A and B describe the coaching/performance service and actual data categories, including optional fields, custom content, and provider processing. Student records are governed by school/organization authorization and legally required consent, including for students under 13.
• Security: Exhibit F or another agreed provision must identify a framework that has actually been implemented. No framework checkbox or certification is claimed by this policy.
• U.S. storage: the supplied Illinois Exhibit G requires covered student data to be stored in the United States. Evidence must cover relevant live storage, backups, authentication, logs, and communications providers; this requirement is not a claim that all locations have already been verified.
• Access, transfer, and deletion: school procedures must meet agreed deadlines and cover applicable live, archived, backup, and provider-held copies. Exhibit G also calls for annual review of data necessity.
• Provider obligations: actual subprocessors and their written protections must be reviewed, not inferred from hosting-provider certifications.
• Incident costs: Illinois Exhibit G includes provider-attributable breach reimbursement/indemnity provisions that can override an otherwise agreed liability cap. Those terms require separate legal and insurance review; this summary neither limits nor changes an executed agreement.
• Other districts: the optional Exhibit E offer is not automatically accepted or signed by publishing this policy. Each district must have an appropriate agreement and purchasing authorization.
• Agreement transparency: Illinois Exhibit G requires the school to post its executed DPA, including the Illinois supplement, on the school's website. Publishing this policy does not execute that agreement or fulfill the school's posting requirement.

Current preparation status: a school DPA and readiness packet have been drafted. Entity formation, age-control verification, security-framework implementation, service-specific storage/subprocessor evidence, retention/deletion procedures, and operational incident-plan readiness remain items to verify before execution. Formation instructions and internal business paperwork are not part of this privacy policy.

Request current DPA terms, the school-facing response summary, provider information, and readiness evidence from Tucker Platt, Owner. International use requires assessment of applicable local privacy, consent, data-transfer, and tax requirements; an Illinois DPA is not a global compliance certificate.

17. Security Incidents & Breach Response

Plan status: a written incident-response plan and school-facing summary have been drafted. Adoption, alternate responder coverage, verified escalation contacts, monitoring/evidence procedures, and a tabletop exercise must be completed before representing the plan as an operational program. The response steps below summarize that plan; they are not a claim that a response exercise or certification has been completed.

1. Identify and escalate: promptly record suspected unauthorized access, loss, disclosure, or alteration and involve the privacy lead.
2. Contain and preserve: restrict affected access as appropriate and preserve relevant evidence securely without unnecessarily copying student information.
3. Investigate and notify: identify affected systems, schools, students, data types, and dates; obtain appropriate legal/provider assistance; notify authorized recipients under the earliest applicable legal or contractual deadline.
4. Recover and review: correct the cause, verify recovery without restoring data that must remain deleted, provide material updates, and document lessons and remaining actions.

Under the supplied Illinois IL-NDPA, school notice is generally due within 72 hours after confirmation of a covered incident, subject to its lawful law-enforcement exception and any earlier applicable obligation. Notice should include available incident facts, involved information types, relevant dates, and a contact; Illinois Exhibit G adds affected students when known and a provider contact for parent inquiries. Unknown details should be followed by updates, not used to postpone an otherwise required notice.

Student lists and sensitive incident details must use a verified secure delivery route. Under the DPA, the school handles student/parent notifications with provider cooperation, subject to any additional independent legal duties. Non-school incidents require their own applicable-law notice review; the Illinois school contract's deadline is not assumed to govern every situation.

Privacy lead and incident contact: Tucker Platt, Owner — tuckplatt@gmail.com. Report suspected incidents promptly and do not include passwords, access tokens, or unnecessary student lists in the initial email.