ENSAnalytics
ENSAnalytics will be the analytics layer that turns the live state of ENS into the kind of insights a protocol team, a registrar, or an app builder actually wants to act on.
Look at any product business and the analytics dashboard is the steering wheel — which cohorts of users stick around, which campaigns convert, which segments are quietly worth more than the loud ones. ENS deserves the same lens. Today most of that signal is locked inside ENSDb as raw events. You can count names and count registrations, but answering “which registrars retain users best?” or “how does behavior shift in the second year of holding a name?” still means writing one-off SQL or stitching subgraph queries together by hand.
What we’re building toward
Section titled “What we’re building toward”A few directions we’re particularly excited about.
Cohorts and behavior
Section titled “Cohorts and behavior”How long has each holder been in ENS, what did they renew, what did they let expire, how did their record-set evolve? Group accounts into cohorts by entry date, by registrar, by the kind of names they hold, and watch how those cohorts behave over time. Cluster on activity rather than on a single hardcoded segmentation — the interesting stories tend to live in the slices nobody pre-defined.
Policy levers
Section titled “Policy levers”Run a referral edition, change a renewal price, ship a new ENSv2 feature, then see what it did. By cohort, by chain, by registrar. Today this kind of analysis happens in spreadsheets after the fact; we want it to happen in a dashboard while it’s still actionable.
Custom dashboards
Section titled “Custom dashboards”Registrars, the ENS DAO, and apps each care about a different slice of the same data. ENSAnalytics will let operators compose their own dashboards — the metrics that matter to a Basenames operator are not the metrics that matter to a DAO budget review — without forking the service.
The ENS Referral Program
Section titled “The ENS Referral Program”The ENS Referral Program is the first analytics product we’ve shipped on ENS. Leaderboards, advocate detail pages, full per-referral award accounting — all of it driven by aggregations over ENSDb, surfaced through an API, rendered on ENSAwards. It’s the smallest end-to-end version of the bigger vision, and we’re using it to learn what the more general engine should look like.
Built for
Section titled “Built for”- The ENS DAO and its delegates, evaluating program impact and renewal economics across cohorts, chains, and time.
- Registrars across the indexed namespace (mainnet
.eth, Basenames, Lineanames, 3DNS, and what gets indexed next) wanting to see how their users compare to the rest of ENS. - App builders adding ENS to their product and wanting to know which features actually move the needle.
- Anyone running a referral program, growth campaign, or pricing change on ENS and wanting to measure what it did.
How it fits
Section titled “How it fits”ENSAnalytics will sit on top of ENSDb, the same way ENSApi does — a separate service that reads the live indexed state of ENS and turns it into aggregates, time series, cohorts, and rollups. Apps like ENSAwards consume the API, operators run their own queries against the engine, and the underlying name and registration data stays exactly where it already lives.