Cookie / Tracking Policy
This policy explains how Noteese uses cookies, browser storage, attribution IDs, authentication sessions, analytics events, and diagnostics during beta.
Beta legal version: phase2a-beta-2026-07-10
Required storage
Some storage is needed for sign-in, security, settings, and core product operation.
Analytics events
Events help Noteese measure signup, card creation, proof upload, sharing, reports, and reliability.
Attribution signals
Referral, source, campaign, and school-code signals help understand how users arrive.
No ad-sale promise
Noteese should not sell student achievement data to advertisers.
Noteese is building a trust-first achievement platform. Tracking should support product reliability, safety, attribution, and responsible growth—not hidden behavioral advertising.
1. What this policy covers
This policy covers cookies, localStorage, sessionStorage, Supabase authentication storage, anonymous/session identifiers, referral or campaign attribution, analytics events, quality-assurance identifiers, and diagnostic records used by Noteese during beta.
2. Required authentication and security storage
Noteese uses Supabase Auth and browser/session storage to keep users signed in, process account recovery, support OAuth login, protect account sessions, and route users to the correct dashboard or admin area.
Without this required storage, signup, sign-in, password reset, Google login, and secure account workflows may not work correctly.
3. Preference and product storage
Noteese may use localStorage or similar browser storage for product preferences such as light/dark mode, attribution session data, beta QA mode, and user-interface settings.
4. Analytics events
Noteese tracks product events such as landing views, signup started/completed, sign-in completed, OAuth started, password reset events, achievement started, proof uploaded, achievement submitted, card ready, card viewed, card shared, report submitted, report action taken, legal consent completed, profile photo uploaded/removed, and QA validation events.
These events help Noteese understand whether the product is working, where users drop off, and whether beta safety and review workflows are operating properly.
5. Attribution and referral data
When available, Noteese may record source, referral code, school/campus code, UTM source, UTM medium, UTM campaign, UTM content, UTM term, referrer, anonymous ID, and session ID.
This helps Noteese understand which channels lead to real achievement submissions, proof uploads, Card Ready events, and beta adoption.
6. QA and diagnostic tags
Admins may use analytics QA tools that tag a controlled test run with a QA run ID. These tags are used to confirm that analytics events and dashboard formulas work correctly after code changes.
7. Advertising and sponsored opportunities
Noteese should not sell student achievement data to advertisers. If Noteese later shows sponsored opportunities, they should be clearly labeled and handled in a privacy-first, guardian-aware manner.
8. Your choices
You can control some browser storage by using browser privacy settings, clearing site data, or using private browsing. Some product features may stop working if required authentication/session storage is blocked.
For broader privacy choices, review the Privacy Policy and account settings.
9. Updates
This policy may be updated as Noteese adds production analytics, organization accounts, AI features, paid plans, opportunity matching, or mobile apps.
Early Beta
We’re testing Noteese with early users and organizations as we continue improving the experience. Please review our Terms, Privacy Policy, and Beta Safety Notice for information about using Noteese during the beta period.