📚Knowledge pages

What is the Knowledge section about?

You can think of the knowledge section as the place where you link the business concepts and definitions to data assets.

You can create and group your documentation in different sections with pages related to your:

organisation domains
business processes
metric & KPIs
glossary terms
business concepts
policies
FAQs
etc...

Below are some examples of the key categories of knowledge. The list is not exhaustive and can be different organisation by organisation.

🏷️ Domains documentation & structure

A data domain is a broad grouping of data assets based on its function, usage, or subject matter, and each domain is typically associated with specific governance policies, ownership, and quality standards.

Typical examples of domains:

Customer: including data assets and metrics related to customer lifecycle, customer health, customer attributes etc.
Finance: that includes data assets related to financial transactions, budgets, revenue or expenses
Employee: including job information, talent retention, hiring etc
etc

💡 You can have multiple teams contributing or using information from a single domain. 💡 Typically, there are no more than 10 data domains as part of an organisation. 💡 If your organisation is not used to the concept of domain, you can start by simply using your department hierarchy instead.

How to structure your domains?

A basic structure in the domain structure can follow the domain list and the key areas for each domain. For example:

Typically an organization will have activities split by lifecycle and you can split it based on its stage: prospect, customer etc.
- for prospects we will have qualification stages and sales stages each with its own processes and KPIs
- for existing customers we will have onboarding processes, but also data assets related to customer deals

💡 It is a good idea to start just with 1, 2 levels in the domain hierarchy before expanding further.

How to document your domains?

Some typical questions your domain or team pages should answer:

Why? What the domain, team , data product does / mission
Who? Key people working on it
How? Key process used to achieve the mission → these will be subpages below
What? Key assets / metrics used to achieve the mission
Anything else I should know? Useful presentations / links

For more complex organisations you might want to consider using domains and teams at the same time. In that case you should have separate hierarchies - using tags to intersect.

📊 Metrics Documentation

A metric or Key Performance Indicator (KPI) is a quantifiable measurement used to evaluate the performance or success of an organisation, process, team, or individual.

💡 Putting metrics under a domain or a team bears the risk of adding multiple definitions for the same business concept. For that reason we recommend having a separate section for metrics that is either flat or is only grouped by the type of metric (and not by domain, team etc).

For example you can group MAU, WAU, Number of events etc under Adoption. But we don’t recommend grouping them under Product for example as other departments / teams might play a part in influence them.

When documenting a metric you should consider what questions you want the documentation to answer. Some question examples can be found below:

Why was the metric created? Describe the purpose of the metric
Who should use it? Target audience
What does it measure? Describe where is it commonly used
How and when? How is it calculated, when and how often is it refreshed
Anything special we should know? `Eg always uses a specific filter

Metrics and KPIs will be present in one or more dashboards, datasets / semantic models & fields and can be sourced from one or two tables and columns. We recommend using the Pinned Assets (see Pinned assets & Mentions) in order to highlight these relationships.

💡Each metric should have at least one owner and corresponding domain / team tags.` 💡Each metric should have at least one pinned asset to either dashboard or source table used in the calculation for the metric.

📓 Glossary Documentation

Under glossary (or business concepts) you can add any of those business terms that don’t fit under the metric umbrella.

Some examples could be:

acronyms: eg GDPR, QBR, etc
business groupings: eg territory - EMEA, APAC etc
business terms: eg active employee, commercial / enterprise account , customer etc.

The documentation of these terms should include a business definition, a technical one and possibly the source of the data

🏷️ Domains documentation & structure

📊 Metrics Documentation

📓 Glossary Documentation

Other Categories of Documentation