unicornClicks – Children’s click signal

Among the thousands of fields and modules in the API Content Warehouse, one of the more intriguing turned out to be unicornClicks – a float field in the QualityNavboostCrapsCrapsClickSignals module, belonging to the Quality cluster. The documentation defines it laconically:

„The subset of clicks that are associated with an event from a Unicorn user.”

NavBoost is Google’s internal system that uses click and impression signals to rank search results. The fact that Google isolates a specific subset of clicks as a separate field – alongside regular clicks – is not an accidental decision. Every field in this module exists for a concrete reason.

The guiding question of this article is therefore: why does Google isolate „Unicorn user” clicks as a separate signal, instead of treating them the same as clicks from any other user?

Where the misinterpretation comes from

What the SEO community was saying

Almost immediately after the leak, interpretations like the following began to appear:

„’Unicorn’ is Google’s internal designation for an ultra-high-trust, verified human user profile (someone with a clean, established history across logged-in Google services). Because these accounts cannot be easily simulated by bot nets or click farms, their browsing interactions carry immense algorithmic weight.”

Or more elaborate:

„To qualify as a unicorn click, a click might need to include several of the following: the user spends a good amount of time on the page (dwell time), the user doesn’t immediately hit 'back’ or 'return to search’ (low pogo-sticking), they might interact more (scroll, click further inside the site), maybe the click comes from a 'trusted’ user/browser/session.”

The interpretation of „high-quality clicks from a super-user” caught on very quickly.

Why this interpretation was tempting

It is hard to be surprised that the „super-user” interpretation spread so easily. Several factors contributed to this.

1. No official definition – Google never publicly explained who a „Unicorn user” is.
2. The name itself – „Unicorn” – which could suggest something very important, unique, and exceptional.
3. The NavBoost context – the system genuinely differentiates click signals by quality; it contains fields such as goodClicks and badClicks. Against that backdrop, unicornClicks sounded like yet another quality category, just of the highest tier.

Why the „super-user” interpretation is wrong

The problem with the „super-user” interpretation is simple: a field name does not describe the quality of a click.

Field names describe the source or type of data, not its value.

• The field goodClicks exists alongside badClicks – that is a pair describing quality, and you can tell from the names themselves.
• unicornClicks has no counterpart in the form of notUnicornClicks or regularClicks. This field describes the origin of a click, not its quality.

If Google wanted to flag clicks from exceptionally engaged users, it would have named the field highTrustClicks, verifiedClicks, or simply added another weight to the existing quality evaluation system – at least that is my impression. Instead, it used a proper name – unicorn – which internally denotes a specific and well-defined type of user account.

Who are „Unicorn users” and what is „unicornClicks”

• With very high probability, „Unicorn users” are children’s accounts.
• In that case, unicornClicks must be clicks generated by children’s accounts – not, as widely assumed, a signal of exceptionally valuable clicks from „super-users.”

Intrigued? Below I lay out in detail exactly how I arrived at this conclusion. 🙂

Starting point – Google API Content Warehouse

First clue – Dumbledore in the API documentation

The first clue appears in the module AppsPeopleOzExternalMergedpeopleapiFieldAcl, which describes the access control system for user profile fields. The documentation lists permission examples for different account types:

Consumer user:                        [IDENTITY_ACL_ESTABLISHED]
Dasher user (without domain sharing): [IDENTITY_ACL_ESTABLISHED]
Unicorn user:                         [SAME_UNICORN_FAMILY]
Hafez user:                           []

The „Unicorn user” has access restricted exclusively to SAME_UNICORN_FAMILY – meaning only to members of the same family. This is an architectural confirmation that a Unicorn account operates within a family unit, not as an independent user.

Second clue – Google Play Services

I analyzed the source code of the Google Play Services mobile application. There I found the following set of internal identifiers:

UNICORN_DUMBLEDORE_PARENTAL_CONTROLS
UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_ANDROID_ADD_ACCOUNT
UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_ANDROID_OUT_OF_BOX
UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_ANDROID_ENFORCE_LAUNCHER
UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_WEBVIEW_ADD_ACCOUNT
UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_WEBVIEW_OUT_OF_BOX
UNICORN_DUMBLEDORE_OPT_IN
UNICORN_DUMBLEDORE_OPT_IN_ANDROID_ADD_ACCOUNT
UNICORN_DUMBLEDORE_OPT_IN_ANDROID_OUT_OF_BOX

The pattern is unambiguous: UNICORN_DUMBLEDORE_PARENTAL_CONTROLS_*. The Unicorn account is tightly coupled with the parental control system, which Google internally named „Dumbledore.”

Combining SAME_UNICORN_FAMILY with PARENTAL_CONTROLS paints a picture of an account that:

• operates within a family unit
• requires parental supervision
• has restricted permissions compared to a regular user

That is why I believe this is not the profile of a „super-user,” but the profile of a child. 🙂

Analysis of Google applications

To verify the children’s account hypothesis, I analyzed the contents of several major Google applications for occurrences of the term unicorn.

The absence of the term in Google Family Link and YouTube Kids is just as telling as its presence elsewhere – those applications are explicitly designed for children and parents, so they have no need for an internal label. The term unicorn appears where the system needs to distinguish a child’s account from adult accounts.

Fields and their meaning

Google Play Services provides the largest number of references and the most detailed picture of the account lifecycle:

UNICORN_ACCOUNT_CREATION_*
UNICORN_ACCOUNT_CREATION_SMS_PARENTAL_CONSENT
UNICORN_ACCOUNT_CREATION_STORE_PARENTAL_CONSENT
UNICORN_FAMILY_LINK_ACCOUNT_CREATION
UNICORN_FAMILY_MANAGEMENT
UNICORN_GRADUATION
NON_UNICORN_ACCOUNT_REMOVED
OTHER_UNICORN_ACCOUNT_REMOVED
EXCEEDS_UNICORN_ACCOUNT_CREATION_QUOTA
exclude_unicorn_account
is_unicorn_account
isUnicornUser

A complete lifecycle is visible: account creation with required parental consent (PARENTAL_CONSENT), linking to Family Link (UNICORN_FAMILY_LINK_ACCOUNT_CREATION), management (UNICORN_FAMILY_MANAGEMENT), and the end of child status (UNICORN_GRADUATION). Each stage requires a separate authorization flow.

YouTube provides two particularly significant fields:

IS_UNICORN_CHILD_ACCOUNT
REGISTERED_GAIA_SERVICES_IS_UNICORN_OVER_13_IN_EU
wasUnicorn

IS_UNICORN_CHILD_ACCOUNT directly confirms that Unicorn is a child’s account. REGISTERED_GAIA_SERVICES_IS_UNICORN_OVER_13_IN_EU reveals that Google applies additional age distinctions specific to the European Union – in line with the more stringent requirements of GDPR-K. Most telling of all, however, is wasUnicorn – as can be inferred, the system remembers that an account belonged to a child even after it transitions to an adult account.

Google Photos contains an interesting field:

DEPRECATED_UNICORN
is_unicorn_sharing_enabled
isUnicornUser

DEPRECATED_UNICORN suggests that the Unicorn account implementation in Google Photos evolved and the old version was replaced by a newer one. is_unicorn_sharing_enabled points to a separate content-sharing logic for children’s accounts.

Google Maps reveals the most significant legal restrictions:

GDPR_LOCATION_ALIAS_USED_IN_OTHER_PRODUCTS_UNICORN_V2
HOME_WORK_NOTICE_UNICORN
PRECHECK_REJECTED_UNICORN_ACCOUNT
UNICORN_ACCOUNT_ERROR
showForUnicorn

PRECHECK_REJECTED_UNICORN_ACCOUNT means that Unicorn accounts are actively rejected when attempting to access certain Maps features, before those features even launch. GDPR_LOCATION_ALIAS_USED_IN_OTHER_PRODUCTS_UNICORN_V2 points to a separate legal pathway for children’s location data – the most sensitive category of personal data.

What this reveals as a whole

The application analysis reveals a coherent, systemic picture: unicorn is an internal account type identifier present throughout the Google ecosystem and consistently associated with the same set of characteristics:

• parental consent required for every significant action
• restricted access to product features
• separate legal pathways for sensitive data
• isolation within the family unit
• retention of status history after it ends (wasUnicorn)

Every one of these characteristics describes a child’s account, not a „super-user.” None of the analyzed fields suggests exceptional click quality, high trust, or an advanced behavioral profile. All of them, without exception, point to protection, restrictions, and parental oversight.

Confirmation – Chromium documentation

The official definition of a Unicorn account

All the previous evidence – mobile application analysis, ACL fields, the Dumbledore system – came from internal data structures that required interpretation. The Chromium documentation requires none.

The Chromium project is open source, and its repository contains a public document, user_types.md, describing the types of user accounts that can log in to ChromeOS¹. In the „Child users” section, the following passage appears:

„Users that logged in using a Unicorn account – an account designated for children under the age of consent in their jurisdiction.”

That is the official, public definition. Unicorn account = an account for children below the age of consent in their jurisdiction.

The same document adds technical details that complete the picture:

„In order to add a child user to the device, the user has to go through an adapted GAIA flow, which also requires their parent to authenticate.”

„A child account can be created at https://families.google.com/signupkid/famlink-kc?e=UnicornFamily.”

„For internal Google instructions for creating child accounts (including test accounts), see go/unicorn-test-account-creation.”

The UnicornFamily parameter in the child account creation URL, and the internal link go/unicorn-test-account-creation, confirm that unicorn is an official, systemic identifier for a child’s account used consistently throughout Google’s entire infrastructure.

Why this closes the case

The Chromium documentation is the endpoint of this analysis for one simple reason: it is the only source that explicitly and publicly defines what a Unicorn account is within the Google ecosystem.

I believe the chain of evidence is now complete:

• Google API Content Warehouse → „unicornClicks” = clicks from Unicorn users
• Google Play Services mobile app → Unicorn = account with parental controls
• YouTube mobile app → IS_UNICORN_CHILD_ACCOUNT
• Google Maps mobile app → PRECHECK_REJECTED_UNICORN_ACCOUNT
• Chromium documentation → Unicorn account = account for children below the age of consent

Every link in this chain comes from a different source, a different product, and a different technical context. All of them point in the same direction: Unicorn user = a child.

What this means for unicornClicks

Legal reason – COPPA and GDPR-K

Google operates globally and is subject to two key regulations concerning children’s data.

1. In the United States, COPPA (Children’s Online Privacy Protection Act) prohibits the collection and use of behavioral data from children under the age of 13 for profiling, targeting, and personalization purposes.
2. In the European Union, GDPR-K applies GDPR provisions with particular strictness to children’s data – hence the separate field REGISTERED_GAIA_SERVICES_IS_UNICORN_OVER_13_IN_EU in YouTube, indicating that Google applies additional age distinctions specific to the EU.

Isolating unicornClicks as a separate field in NavBoost is a response to these legal requirements. Google must know which clicks come from children in order to lawfully refrain from using them for certain purposes.

What we know and what we don’t

What we know for certain:

• unicornClicks are clicks generated by children’s accounts
• Google architecturally isolates these clicks from the other NavBoost signals
• The isolation has both legal and technical justification
• The widespread SEO interpretation – „super-user” and „high-quality click” – is wrong

What we don’t know:

• Whether unicornClicks are actively used in ranking or merely recorded and isolated
• Whether, after a child’s account transitions to an adult account, historical unicornClicks are reset, archived, or carried over
• How large this set of clicks is and whether its scale has any practical significance for ranking

That last question is, however, secondary. The main conclusion remains unchanged: unicornClicks were never a signal of click quality. They were – and are – a signal of click origin.

1. Chromium Documentation – https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/login/user_types.md ↩︎