For EdTech companies, K–12 schools, districts, tutoring platforms, and education apps, this makes website tracking worth a closer look. A tool that seems routine on a normal business website can raise different questions when the visitors include children, students, parents, or people using school services.
This article looks at the website tracking and consent layer of COPPA, GDPR children’s data rules, and FERPA-related risk.
Why School and EdTech Website Tracking Needs a Closer Look
A school website can have very normal-looking pages: lunch menus, event calendars, staff pages, enrollment links, and a button to the student portal. An EdTech website can look like a regular SaaS site, with analytics, product videos, chat tools, trial forms, and advertising pixels.
That is where the review gets tricky.
These pages are not always visited by typical adult customers. A parent may be checking an enrollment form or looking for school services. A child may be opening a homework portal. A student may be using a login page before starting a lesson. A tutoring site may have a free-trial form with marketing tags attached.
The issue is not that every cookie, pixel, or analytics tag is automatically a violation. It is that the same tracker can mean something different on a school or EdTech website.
A basic analytics tag on a public calendar is one thing. An ad pixel on a student login page is another. A video embed on a general article is not the same as a video tool inside a child-facing lesson page.
So before leaving tracking tools in place, schools and EdTech businesses need to check where the tracker runs, who the page is for, what data is collected, which vendor receives it, and whether the tool is actually school-authorized.
COPPA: When Children Under 13 Are Involved
COPPA is the U.S. children’s privacy law that often comes up first for EdTech websites, learning apps, tutoring platforms, and child-facing school tools.
It does not apply to every education website just because the topic is education. The FTC describes COPPA as applying to operators of websites or online services directed to children under 13, and to operators that have actual knowledge that they collect Personal Information online from children under 13.
That matters for website tracking because COPPA is not limited to a child’s name, email address, or phone number. In the COPPA Rule, 16 CFR § 312.2, Personal Information can include “a persistent identifier that can be used to recognize a user over time and across different websites or online services.”
For an EdTech website, that can bring tracking tools into the review, including:
- analytics IDs;
- advertising IDs;
- IP addresses;
- device identifiers;
- similar tracking signals used to recognize a user over time.
These identifiers do not create the same risk on every page. They matter most when they are used in a COPPA-covered setting, such as a child-directed service or a service that has actual knowledge it is collecting personal information from children under 13.
COPPA also puts parental consent at the center of many child-data collection scenarios. 16 CFR § 312.5(a)(1) says: “An operator is required to obtain verifiable parental consent before any collection, use, or disclosure of personal information from children.” There are exceptions, so this should not be read as “every technical request always needs parent consent.” But if a child-facing learning tool collects covered personal information, consent needs real attention.
The current rule also pays close attention to third-party disclosure. Parents may need a separate choice before a child’s personal information is disclosed to third parties, unless that disclosure is integral to the nature of the website or online service.
Retention matters too. Under 16 CFR § 312.10, children’s personal information should be kept only as long as reasonably necessary for the specific purpose collected. It should not sit in systems indefinitely.
COPPA violations can lead to civil penalties of up to $53,088 per violation. The actual amount depends on the facts, including how serious the violation was, how many children were affected, what information was collected, how it was used, whether it was shared with third parties, and the size of the company.
School Consent Under COPPA Is Limited, Not a Shortcut
FTC guidance says a school can sometimes consent for parents when an EdTech service is used for a school-authorized educational purpose. The key point is that the operator should be collecting the child’s information for the school’s use and benefit, not for a separate commercial purpose.
That matters in real website setups.
A math app approved by a school for classroom assignments is one case. A homework tool used by students because the district selected it is another. But a tutoring website using ad pixels to build remarketing audiences is different. So is a public landing page that tracks parents or students for marketing.
School consent should not be treated as something that automatically covers every script, tag, or vendor on the site. It should be tied to the actual educational use, the school relationship, the vendor terms, and clear limits on how the data can be used or shared.
If the data is used for advertising, profiling, retargeting, unrelated marketing, commercial reuse, or broad third-party tracking, school consent becomes a much weaker argument.
GDPR-K: Children’s Data Rules Under GDPR
“GDPR-K” is not the name of a separate EU law. It is an informal label used for GDPR rules that deal with children’s personal data, especially GDPR Article 8 on children’s consent.
For an EdTech website, this can matter even when the site is not asking a child to type in a full name. personal data can appear in smaller, less obvious places. For example:
- a student account profile;
- a login ID or device identifier;
- a quiz result connected to a user;
- a learning progress event saved in an account;
- an analytics event tied to a device or profile;
- a cookie or tracking ID that can identify a child directly or indirectly.
Article 8 is relevant when a service is offered directly to a child and consent is the lawful basis. If the child is below the age set by the relevant EU Member State, consent may need to come from, or be authorized by, the person with parental responsibility.
That age is not the same everywhere in the EU. The GDPR default is 16, but Member States can lower it to 13.
Consent also cannot be vague. GDPR Article 4(11) describes consent as “freely given, specific, informed and unambiguous.” On a school or EdTech website, that is hard to match with hidden tracking notices, bundled cookie choices, unclear buttons, or wording that a child or parent is unlikely to understand.
Cookies and similar tracking tools in Europe are not only about GDPR Article 8. Cookie Consent often also comes from national ePrivacy-style rules. GDPR still matters because it shapes what valid consent looks like and how tracking-related personal data is handled after collection.
GDPR fines depend on the type of violation. Some infringements can lead to fines of up to €10 million or 2% of global annual turnover, whichever is higher. More serious violations, including problems with basic processing principles or consent, can reach up to €20 million or 4% of global annual turnover, whichever is higher.
FERPA: Why Student Records Are a Different Issue
FERPA is different from COPPA and GDPR-K. It is not a cookie law, and not every school web page becomes a FERPA issue just because the school owns it.
FERPA protects student education records at schools that receive funds from applicable U.S. Department of Education programs. Under 34 CFR § 99.3, education records are records that are “directly related to a student” and “maintained by an educational agency or institution or by a party acting for the agency or institution.”
For website tracking, that definition matters. A basic analytics cookie on a public homepage is not automatically about education records. The harder questions usually start when a website tool connects to student information that comes from school systems, for example:
- a student portal showing assignments, grades, or attendance;
- a learning platform that receives roster or account data from the school;
- a school-approved app that stores student progress;
- a vendor tool connected to internal school systems.
This is where the vendor setup matters. FERPA may allow some vendors to handle education records under the “school official” route, but not just because the vendor sells to schools. The school control, contract terms, permitted use, and limits on redisclosure all matter.
For a school or EdTech website, the safer approach is to separate public-site tracking from tools connected to student records.
FERPA does not set a standard per-violation money fine like COPPA or GDPR. Enforcement is handled through the U.S. Department of Education. A serious or unresolved FERPA violation can lead to corrective action and, in the most serious cases, the possible loss of eligibility for federal education funds.
Where Website Tracking Can Create Risk
The risky part is often not the cookie by itself. It is what the tracker can see, where it runs, and what the vendor can do with the data.
Common places to check include:
- Tutoring sign-up pages
A marketing pixel or ad tag may receive the page URL, campaign source, form step, or trial sign-up event. On a children’s tutoring page, that can reveal more context than the site owner may expect. - Student login flows
Analytics events inside a portal may show that a user logged in, opened a lesson, started homework, or reached a quiz page. The event becomes more sensitive if it is tied to an account, IP address, device ID, or other identifier. - Embedded videos and learning tools
A lesson page may load requests from video platforms, quiz tools, or content widgets. These requests can happen before the school or EdTech company has checked what data the third party receives. - Forms and enrollment pages
Form pages can pass referral URLs, program names, page paths, button clicks, or form activity into analytics tools. Even without the full form content, that metadata can say a lot about the visitor’s intent. - Chat widgets and support tools
A chat tool on a school services page may collect parent or student details and send them to a vendor outside the school’s main systems.
None of this means every cookie, pixel, analytics tag, video embed, or chat tool must be removed. But schools and EdTech companies should know which trackers run, what data they collect, why they are there, and what happens on the vendor side.
What School and EdTech Websites Should Audit First
Start with the pages and tools most likely to involve children, students, parents, or school services:
- Child-facing and student-facing pages — lessons, quizzes, games, homework tools, portals, learning apps, and account areas.
- School and parent forms — enrollment forms, contact forms, lunch forms, transport forms, special service requests, newsletters, event registrations, and parent portals.
- Analytics and event tracking — page tracking, login events, quiz events, learning progress events, and form-step tracking.
- Marketing trackers — advertising pixels, retargeting tags, campaign tracking, and marketing scripts on school, tutoring, or program pages.
- Embedded and support tools — videos, maps, fonts, calendars, social media widgets, chat widgets, and support tools.
- Third-Party Cookies and scripts — especially non-essential tags that load before a required or valid consent choice is made.
- Vendor and data-use settings — what each vendor receives, whether data is shared further, how long it is kept, and whether old child or student-related data is deleted.
- Consent and authorization flows — parental consent, school-authorized tools, EU/EEA visitor handling, and third-party disclosures that may need separate review.
Consent Is Not Just a Cookie Banner
A Cookie Banner is only the visible part. The harder work is deciding what should load, what should wait, and what choice the visitor should actually be given.
For school and EdTech websites, consent should not be vague. Broad cookie notices, bundled choices, pre-ticked boxes, passive browsing, confusing buttons, or dark patterns are a bad fit, especially where children, students, or parents may be involved.
At the same time, not every tracker on every page needs the same treatment. A strictly necessary login cookie is different from analytics. Analytics is different from an advertising pixel. A school-approved learning tool is different from a marketing script on a public landing page.
The right setup depends on the law, user age, page purpose, data collected, vendor role, and whether the tool is school-authorized.
How CookieScript Can Help, and What It Does Not Replace
CookieScript can help with the part of the work that happens on the website itself: finding trackers, controlling scripts, showing consent choices, keeping consent records, and keeping cookie disclosures easier to maintain.
For school and EdTech websites, that can be useful in several practical ways:
- Cookie Scanner helps identify cookies, pixels, analytics tags, ad tags, embedded tools, and third-party scripts running on school or EdTech pages.
- Automatic monthly scans help catch changes over time. This matters when a new plugin is added, a marketing tag is updated, a video embed changes, or a form tool starts setting new cookies.
- Automatic script blocking helps stop non-essential scripts from firing before consent where that setup is needed.
- Third-party cookie blocking can help limit third-party tracking before a valid choice is made, when configured correctly.
- Cookie Banner / Granular choice helps separate strictly necessary cookies from analytics, functionality, targeting, and marketing categories. This is important because a login cookie, an analytics tag, and an ad pixel should not be treated as the same thing.
- geo targeting can help show different consent experiences based on region, such as EU/EEA visitors or other legal markets. It should not be treated as a shortcut for COPPA, GDPR children’s data rules, or FERPA.
- User consents recording helps keep a record of what a visitor selected, when they selected it, and under which banner setup.
- Advanced reporting can help review consent behavior, such as accept, reject, and ignore patterns.
- Cookie Policy / Privacy Policy Generator can help with cookie and tracker disclosures. School privacy notices, children’s privacy notices, COPPA notices, GDPR notices, and FERPA-related documents should still be legally reviewed.
- Google Consent Mode v2 can help adjust Google tag behavior based on consent choices where Google tags are used. It is not a COPPA, GDPR children’s data, or FERPA compliance solution by itself.
CookieScript does not decide whether a tracker collects children’s personal information, student data, education-record PII, or FERPA-protected information.
It also does not replace parental consent workflows, school authorization, FERPA contracts, vendor due diligence, retention rules, security controls, internal governance, or legal review. Those parts still need to be handled outside the cookie banner.
CookieScript is a Consent Management Platform (CMP) used by businesses worldwide. In 2025, it earned its fourth G2 Leader badge in a row and continued to be recognized by users as one of the leading CMP solutions on the market.
Conclusion
School and EdTech privacy risk does not always start in a student database. Sometimes it starts much earlier, on the website: a tracker on a sign-up page, an analytics event inside a portal, an embedded tool on a lesson page, or a vendor script that nobody has checked in a while.
That is why website tracking should not be treated as a small technical detail. Schools and EdTech companies need to know what runs on their pages, what data leaves the site, who receives it, and whether children, students, parents, or school services are involved.
COPPA, GDPR children’s data rules, and FERPA each look at the issue differently. The safer approach is to review tracking, consent, vendors, school authorization, and retention together, not one piece at a time.
Frequently Asked Questions
Does COPPA apply to all school websites?
No. COPPA does not apply just because a website is about education. It matters when a website or online service is directed to children under 13, or when the operator has actual knowledge that it collects personal information online from children under 13.
What is GDPR-K?
GDPR-K is not a separate EU law. It is an informal label for GDPR rules related to children’s personal data, especially GDPR Article 8 on children’s consent.
Is FERPA the same as COPPA?
No. COPPA focuses on online collection of personal information from children under 13. FERPA focuses on student education records at covered schools.
Can cookies or pixels collect children’s personal information?
Yes, depending on the context. Under COPPA, persistent identifiers can count as personal information when used in a COPPA-covered setting. That can include identifiers used in cookies, pixels, analytics tools, or similar tracking technologies.
Is a cookie banner enough for COPPA, GDPR-K, or FERPA compliance?
No. A cookie banner can help with tracker disclosure and consent choices, but it does not replace parental consent, school authorization, vendor contracts, data retention controls, or legal review.
Can schools use EdTech vendors without parent consent?
Sometimes, but it depends on the law, the school relationship, the purpose of the tool, the vendor terms, and how the data is used. School consent under COPPA is limited and should not be treated as a blanket shortcut.
Can a Consent Management Platform help school and EdTech websites?
Yes, for the website tracking layer. A CMP can help scan for cookies and trackers, block non-essential scripts where needed, show consent choices, and keep consent records. It does not decide whether a tracker involves children’s personal information, student data, or FERPA-protected information.