🧙 Wiz Kids
LearnEdTech Privacy & Procurement

Third-party trackers in edtech: what the audits found

Evidence grade: STRONG — this is one of the few privacy topics with systematic measurement. Independent audits have opened large samples of education products and counted the third-party data flows directly. The findings are unusually consistent, unusually bad, and fully checkable: the same inspection the auditors ran is available to any teacher with a browser.

Most edtech privacy discussion argues about policies; this topic has measurements. When auditors stopped reading documents and started watching network traffic, the picture was stark. Human Rights Watch (2022) reviewed 164 edtech products endorsed by governments for pandemic-era schooling and found the large majority engaging in data practices that risked or infringed children's rights — sending data to advertising-technology companies, tracking beyond the educational context, mostly without meaningful disclosure. Internet Safety Labs (2022), auditing the apps actually recommended or required by a sample of US schools, found the overwhelming majority sharing data with third parties — very often including advertising-adjacent platforms — and school-vetted apps performing little better than unvetted ones. Different methods, same conclusion: the policy layer and the traffic layer disagree, and the traffic layer is the true one.

How trackers get into school products

Almost never by villainy — by default: a developer adds an analytics SDK to count users, a crash reporter to fix bugs, an attribution kit left over from consumer marketing, embedded fonts or video players that phone home. Each import quietly brings a third-party data relationship: device identifiers, IP addresses, usage streams — personal information under COPPA's definition and squarely inside the minimisation duty — flowing to companies the school never evaluated and the policy names, at best, as "trusted partners." The developer often doesn't know what their own SDKs transmit; that ignorance is the industry's default state, which is exactly why verification beats trust.

The five-minute check

The auditors' core method requires no tooling budget:

  1. Open the product in a browser; open devtools → Network tab; use the product for two minutes.
  2. Read the request domains. First-party traffic goes to the vendor; everything else — analytics hosts, ad-tech domains, social-media pixels — is a third-party data flow happening regardless of what any policy says.
  3. Repeat on the login and marketing pages, which are often worse than the app.

What "clean" looks like: requests to the product's own domain and nothing else (our IT-admin notes tell evaluators to run exactly this check on us — the test is only credible if the tester can fail you). What each finding means: an analytics domain is a usage-profile flow; an ad-tech domain in a children's product is a COPPA/APP-grade problem and a values disclosure; a social-media pixel means the platform learns which children use which school tools.

What the evidence doesn't say

In practice

  1. Add the devtools check to every desk review — it catches in five minutes what policy-reading misses in an hour.
  2. Ask the vendor for their subprocessor list first, then check whether the traffic matches (the vendor questions) — the disagreement is the finding.
  3. Prefer products that publish their own network story — a vendor who says "open devtools on us" has structured their incentives the way you want.
  4. Report what you find — in Australia, tracker findings in school-endorsed products belong with your department and ST4S; the shared-assessment layer only works if findings flow back into it.

References


© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.