{"id":372,"date":"2021-10-22T14:16:25","date_gmt":"2021-10-22T14:16:25","guid":{"rendered":"https:\/\/blog.mozilla.org\/data\/?p=372"},"modified":"2021-10-22T14:16:25","modified_gmt":"2021-10-22T14:16:25","slug":"this-week-in-glean-the-three-roles-of-data-engagements","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/data\/2021\/10\/22\/this-week-in-glean-the-three-roles-of-data-engagements\/","title":{"rendered":"This Week in Glean: The Three Roles of Data Engagements"},"content":{"rendered":"

(\u201cThis Week in Glean\u201d is a series of blog posts that the Glean Team at Mozilla is using to try to communicate better about our work. They could be release notes, documentation, hopes, dreams, or whatever: so long as it is inspired by Glean.) All \u201cThis Week in Glean\u201d blog posts are listed in the TWiG index<\/a>).<\/p>\n

I\u2019ve just recently started my sixth year working at Mozilla on data and data-adjacent things. In those years I\u2019ve started to notice some patterns in how data is approached, so I thought I\u2019d set them down in a TWiG because Glean\u2019s got a role to play in them.<\/p>\n

Data Engagements<\/h2>\n

A Data Engagement is when there\u2019s a question that needs to engage with data to be answered. Something like \u201cHow many bookmarks are used by Firefox users?\u201d.<\/p>\n

(No one calls these Data Engagements but me, and I only do because I need to call them _something_.)<\/p>\n

I\u2019ve noticed three roles in Data Engagements at Mozilla:<\/p>\n

    \n
  1. Data Consumer: The Question-Asker. The Temperature-Taker. This is the one who knows what questions are important, and is frustrated without an answer until and unless data can be collected and analysed to provide it. \u201cWe need to know how many bookmarks are used to see if we should invest more in bookmark R&D.\u201d<\/li>\n
  2. Data Analyst: The Answer-Maker. The Stats-Cruncher. This is the one who can use Data to answer a Consumer\u2019s Question. \u201cBookmarks are used by Canadians more than Mexicans most of the time, but only amongst profiles that have at least one bookmark.\u201d<\/li>\n
  3. Data Instrumentor: The Data-Digger. The Code-Implementor. This one can sift through product code and find the correct place to collect the right piece of data. \u201cThe Places database holds many things, we\u2019ll need to filter for just bookmarks to count them.\u201d<\/li>\n<\/ol>\n

    \"This<\/p>\n

    (diagrams courtesy of :brizental)<\/p>\n

    It\u2019s through these three working in concert — The Consumer having a question that the Instrumentor instruments to generate data the Analyst can analyse to return an answer back to the Consumer — that a Data Engagement succeeds.<\/p>\n

    At Mozilla, Data Engagements succeed very frequently in certain circumstances<\/i>. The Graphics team answers many deeply-technical questions about Firefox running in the wild to determine how well WebRender is working. The Telemetry team examines the health of the data collection system as a whole. Mike Conley\u2019s old Tab Switcher Dashboard<\/a> helped find and solve performance regressions in (unsurprisingly) Tab Switching. These go well, and there\u2019s a common thread here that I think is the secret of why:<\/p>\n

    In these and the other high-success-rate Data Engagements, all three roles (Consumer, Analyst, and Instrumentor) are embodied by the same person<\/i>.<\/p>\n

    \"This<\/p>\n

    It\u2019s a common problem in the industry. It\u2019s hard to build anything at all, but it\u2019s least hard to build something for yourself. When you are in yourself the Question-Asker, Answer-Maker, and Data-Digger, you don\u2019t often mistakenly dig the wrong data to create an answer that isn\u2019t to the question you had in mind. And when you accidentally do make a mistake (because, remember, this is hard), you can go back in and change the instrumentation, update the analysis, or reword the question.<\/p>\n

    But when these three roles are in different parts of the org, or different parts of the planet, things get harder. Each role is now trying to speak the others\u2019 languages and infer enough context to do their jobs independently.<\/p>\n

    In comes the Data Org at Mozilla which has had great successes to date on the theme of \u201cMaking it easier for anyone to be their own Analyst\u201d. Data Democratization. When you\u2019re your own Analyst, then there\u2019s fewer situations when the roles are disparate: Instrumentors who are their own Analysts know when data won\u2019t be the right shape to answer their own questions and Consumers who are their own Analysts know when their questions aren\u2019t well-formed.<\/p>\n

    Unfortunately we haven\u2019t had as much success in making the other roles more accessible. Everyone can theoretically be their own Consumer: curiosity in a data-rich environment is as common as lanyards at an industry conference[1]. Asking _good_ questions is hard, though. Possible, but hard. You could just about imagine someone in a mature data organization becoming able to tell the difference between questions that are important and questions that are just interesting through self-serve tooling and documentation.<\/p>\n

    As for being your own Instrumentor\u2026 that is something that only a small fraction of folks have the patience to do. I (and Mozilla\u2019s Community Managers) welcome you to try: it is possible to download and build Firefox yourself. It\u2019s possible to find out which part of the codebase controls which pieces of UI. It\u2019s\u2026 well, it\u2019s more than possible, it\u2019s actually quite pleasant to add instrumentation using Glean\u2026 but on the whole, if you are someone who _can_ Instrument Firefox Desktop you probably already have a copy of the source code on your hard drive. If you check right now and it\u2019s not there, then there\u2019s precious little likelihood that will change.<\/p>\n

    (Unless you come and work for Mozilla<\/a>, that is.)<\/p>\n

    So let\u2019s assume for now that democratizing instrumentation is impossible. Why does it matter? Why should it matter that the Consumer is a separate person from the Instrumentor?<\/p>\n

    Communication<\/h2>\n

    Each role communicates with each other role with a different language:<\/p>\n