AnalyticsOps

WHAT IT IS AnalyticsOps is the operating discipline for the consumption end of the data stack: how metrics are defined, where those definitions live, how dashboards are created and retired, and how a self-serve environment stays trustworthy as it grows. It is the answer to the organisation's most common analytics failure — two dashboards, two numbers, both labelled "revenue". **Not this:** AnalyticsOps is not DataOps: it owns what a number means and who may trust it, not the pipeline that moved the rows. WHY IT EXISTS Self-serve analytics scales access faster than it scales agreement. Within a year of opening a BI tool to everyone, an organisation typically has hundreds of dashboards, a handful of which are load-bearing and none of which are labelled as such. Meetings then spend their first ten minutes reconciling numbers instead of deciding anything. AnalyticsOps exists to make definitions a managed asset rather than an accident of whoever wrote the query first. WHEN TO USE IT Adopt it when the same metric is computed in more than one place, when nobody can say which dashboard is authoritative, or when an executive has asked why two reports disagree. If one analyst serves the whole company, the definitions live in their head and that is fine — until they leave. WHO OWNS IT Analytics engineering owns the semantic layer and the certified metric definitions. Business domain owners own the definition itself — what "active customer" means is a business decision, not a technical one, and delegating it to whoever writes the SQL is how organisations end up with a definition nobody agrees with. A BI or data platform team owns tool administration, access and the retirement process. WHAT GOOD LOOKS LIKE Core metrics have one definition, expressed once in a semantic layer or modelled tables, and dashboards consume that definition rather than reimplementing it. Certified content is visibly distinguished from someone's exploratory work. Dashboards have owners and expiry: unused ones are archived rather than accumulating. A change to a certified metric follows a review process with notification to consumers. Access is governed, and sensitive fields are restricted at the model rather than by hoping nobody looks. HOW TO IMPLEMENT Begin by finding the ten dashboards that actually get used — usage logs will surprise you — and certify those, rather than attempting to govern everything at once. Write the definitions for the metrics they contain and get the business owner to agree in writing. Move those definitions into a semantic layer or shared modelled tables so they are computed once. Introduce a certification badge and an owner field, then a retirement policy for unused content. Only then widen the scope. Pair this with the pipeline reliability work in /dataops, because a certified metric computed from stale data is worse than an uncertified one. HOW TO ASSESS YOURSELF Ask three people to produce last month's headline number independently and compare. Ask how many dashboards exist, how many were opened last month, and who owns the difference. Ask what happens when a metric definition changes — who is told. Take the scored self-assessment at /assess, turn the result into a sequenced plan with /roadmaps, and use the review checklists at /checklists for the recurring certification pass.