Privacy

PracticeMarks is built for a parent and their kid. Privacy is taken seriously here because the product is meant for families and because much of the data is about minors.

What we collect

From the parent: an email address and a password (stored as a salted hash — the actual password is never stored). The email is used to sign in and to recover the account.

From the kid (set when the parent or teacher adds the kid): a display name, a username, and a password. A kid’s password is stored two ways — as a salted hash used for sign-in, and, unlike a parent’s or teacher’s password, additionally in encrypted (reversible) form so the parent or teacher who manages the account can look it up when the child forgets it. It is encrypted at rest, never kept in plaintext, and shown only to that account holder. The display name and username are used to identify which kid is signed in. We never ask for a kid’s real name, address, school, birthdate, or contact information.

From normal use: which questions a kid answered and when, the kid’s answer, whether it was correct, the standard the question is aligned to, and the reward posters the kid creates (the theme, style, and free-text seed they pick, plus the AI-generated image). We also temporarily keep an IP address in memory to rate-limit logins and posts; it is not written to the database.

Why we collect it

The parent email and password let the parent sign in and let us scope a kid’s account to a single household. Kid usernames and passwords let kids practice without a parent re-typing credentials each session. Practice attempts are what produce the per-standard progress that the parent dashboard shows. Posters are the kid’s reward and only exist because the kid practiced.

Who has access

Only the operator (the dad behind this app — see About) has access to the database. We don’t sell your data. The third-party advertising relationships are Google Ads conversion tracking and the Meta (Facebook) pixel; we also run Google Analytics and PostHog to measure how the site is used. All four are described below, and all four are scoped to parent-facing pages only, never to the kid practice flow.

Third parties we use

OpenAI. We send prompts to OpenAI to generate practice questions and reward poster images. The prompts include the standard being practiced and (for posters) the kid’s theme/style/free-text seed. The prompts do not include the parent email, the kid’s username, the kid’s display name, or any account identifiers. OpenAI’s use of inputs is governed by their privacy policy.

Vercel hosts the app, serves the pages, and stores the reward poster images in private Vercel Blob storage, which only a signed-in owner can read. Neon hosts the Postgres database where account info, attempts, and the rest of each poster’s record are stored. Both are reputable infrastructure providers under their own privacy policies.

Stripe processes payments for paid subscriptions. We never see or store your card number — Stripe does. We store only the Stripe customer and subscription identifiers tied to your parent account.

Google Ads. On parent-facing marketing pages (the homepage, grade landing pages, signup, login, upgrade, and account) we load Google’s gtag.js so that ad clicks that lead to a paid subscription can be attributed to the campaign that produced them. Google sees the URL you visited, your IP address, and a Google Ads click identifier (gclid) if one is present. Conversion events fire only on the post-checkout success page and include the Stripe checkout amount and a Stripe session id. Google Ads is not loaded on the kid practice pages, on quiz screens, or on any page once a kid is signed in. Google’s use of this data is governed by their privacy policy.

Meta (Facebook). On parent-facing marketing pages (the homepage when you are signed out, the state and grade landing pages, the guides under /learn, about, privacy, terms, and the signup pages) we load Meta’s pixel so that ad clicks that lead somewhere can be attributed to the campaign that produced them. Meta sees the URL you visited, your IP address, your browser user agent, and a Meta click identifier (fbclid) if one is present. The only event we send is a page view; we do not send your email address, your kid’s name or username, or any account identifier. The pixel is not loaded on the kid practice pages, on quiz screens, on the parent dashboard or account pages, on the login page, or on any page once anybody is signed in. Meta’s use of this data is governed by their privacy policy.

Google Analytics. On the same pages that carry the Meta pixel, and only those, we load Google Analytics 4 (measurement id G-BS86XJX0DR) to count page views and see which marketing pages people actually read. This is a separate Google product from the Google Ads tag above, with a separate identifier and a narrower placement: Analytics is not loaded on login, upgrade, or account pages, and never on a kid-facing screen. It records the URL you visited, your IP address, your browser and device type, and an approximate location derived from the IP. We send no custom events to it, so it never receives your email address, your kid’s name or username, or any account identifier. Google’s use of this data is governed by their privacy policy.

PostHog. We use PostHog to count product events — page views, signups, kid-profile creation, practice-session starts/completions, poster reveals, paywall views, checkout starts, and purchases — so we can see where new visitors drop off in the funnel. Event payloads contain numeric account and kid identifiers, never email addresses, kid display names, or usernames. Autocapture, heatmaps, and session replay are all disabled — only the specific events listed above are recorded. PostHog is not loaded on the kid practice pages or on any page where a kid is signed in; kid-engagement events (questions answered, poster pieces revealed, sessions completed) are recorded server-side from our own APIs so the kid browser never contacts PostHog. PostHog’s use of this data is governed by their privacy policy.

Cookies

Our own cookies, both first-party and both lasting 30 days: eog_session, an HttpOnly, SameSite=Lax cookie holding the signed session token that keeps you signed in; and eog_kind, a readable companion cookie that records only whether the session belongs to a parent, a teacher, or a kid, so the page can show the right navigation without waiting on a request. The companion cookie carries no token and no account identifier.

Google Ads cookies (only on parent-facing marketing pages, never in the kid practice flow): _gcl_au and _gcl_aw, used by gtag.js to remember whether you arrived from a Google ad so a later subscription can be attributed to the right campaign. These are first-party cookies on practicemarks.com and are not used to build a cross-site advertising profile from this site.

Meta cookies (only on the parent-facing marketing pages listed above, never in the kid practice flow and never once you are signed in): _fbp, and _fbc if you arrived from a Meta ad, used to recognise the same browser across visits so an ad click can be tied to what it led to. These are first-party cookies on practicemarks.com. Unlike our own cookies, Meta uses the data collected through its pixel for its own advertising purposes across the sites that run it — that is what a pixel is for, and it is the reason it is kept off every page a kid or a signed-in parent sees.

Google Analytics cookies (only on the pages listed for the Meta pixel above, never in the kid practice flow and never once you are signed in): _ga and _ga_BS86XJX0DR, used to recognise the same browser across visits so a returning reader is not counted as a new one. These are first-party cookies on practicemarks.com.

PostHog cookie (only on parent-facing pages, never in the kid practice flow): ph_*_posthog, used to assign a random identifier so anonymous events captured before signup stitch to your account after you sign up. It is a first-party cookie on practicemarks.com and is not used to build a cross-site advertising profile.

Kids and COPPA

Kid accounts are created in one of two ways, and the basis for collecting a child’s information differs between them. When a parent creates a kid account through their own account, the parent confirms they are the child’s parent or legal guardian and provides consent to the collection described here. When a teacher creates a student account for their classroom, we rely on the school’s authorization: the student information is collected for the use and benefit of the school and for no other commercial purpose, and the teacher confirms their school or district has authorized them to use PracticeMarks and to provide the information they enter. In both cases the profile is only a display name, a username, and a password — we never ask for a child’s real name, address, school, birthdate, or contact information.

No advertising or analytics script runs on any kid-facing screen. Google Ads gtag.js is loaded only on parent-facing marketing and account pages (homepage, grade landing pages, signup, login, upgrade, account). The Meta pixel and Google Analytics are loaded on a smaller set — marketing pages and signup only, never on login, upgrade, or account. Once a kid signs in and starts practicing, no Google script, no Meta script, and no PostHog script is loaded, and none of their cookies are read.

A parent can delete a kid account at any time, which removes all of that kid’s sessions, attempts, and posters.

Teachers, schools, and student data

When a teacher adds students, PracticeMarks acts as a service provider to the teacher and their school. We hold and process student information only to provide the classroom service, under the school’s direction; we do not sell it, use it for targeted advertising, or use it to build a profile of a student for anything other than K–12 school purposes; and we do not re-disclose it except to the connecting parent (below) or to the service providers that run the app under our instructions. Each student account holds only a display name, a username, and a password. A student account is standalone practice data — it is not connected to, and we do not receive, any official school or student record (such as a student information system, official grades, or an IEP). The display name is simply what shows on the student’s own screen and does not need to be a real name; we ask teachers to use a first name, nickname, or initials — not a full legal name unless their school has authorized it — and not to enter information their school has not authorized. A teacher can see and reset their students’ login details and sees class-wide and per-student progress; students log in with the teacher’s email plus their own username and password and see only their own practice.

A school or district may ask us to delete its students’ information, or tell us the service has ended, by emailing our support address; we delete that information within 45 days (the exception is a student a parent has already connected to and chosen to keep — see next).

A teacher may invite parents to connect to their own child using a class code. A parent who connects — by entering the class code and the child’s practice password — affirmatively claims that one child, agrees to this policy and our Terms for their own family account, and can then see that child’s progress and, with a family plan, guide their practice at home. A parent only ever reaches their own child, never the rest of the class. If a teacher removes a connected student or closes the classroom, that already-claimed student’s account moves to the connecting parent’s account so the work is preserved; students who were never claimed are archived with the classroom, not transferred to anyone. No advertising or analytics script runs on any student practice screen, the same as for any kid.

Data retention and deletion

We keep account data while the account is active. To delete an account, email support@practicemarks.com from the parent or teacher email on file. When a parent account is deleted, all linked kid profiles, sessions, attempts, and posters are removed. When a teacher account is deleted, its classroom and student accounts are removed too — except for any student a parent has already connected to, which stays with that parent’s account.

A school or district may request deletion of its students’ information, or notify us that its use of the service has ended, by emailing support@practicemarks.com. We delete the covered student information within 45 days of such a request, other than a student a parent has already connected to and chosen to keep.

Security

Account passwords (parents and teachers) are stored as bcrypt hashes and are never recoverable. Kid passwords are the one exception: in addition to the sign-in hash, a kid’s password is also kept in encrypted form, decryptable only with a key held by the server, so the managing parent or teacher can retrieve it for a child who forgets. It is encrypted at rest rather than stored in plaintext, and is shown only to that account holder. Session tokens are signed and stored in an HttpOnly cookie with SameSite=Lax — Lax rather than Strict so that returning from an external checkout still carries your session. Because Lax is the weaker setting, every state-changing request is additionally checked to confirm it came from this site rather than another one. None of this guarantees perfect security — no system is airtight — but those are the practical safeguards in place.

Changes

If this policy changes in a way that affects what is collected, how it’s used, or who it’s shared with, we’ll announce the change in-product before it takes effect.

Last updated 17 August 2026.

Privacy questions or deletion requests: support@practicemarks.com.