Talk details

The umpteenth similar message from your #data-people slack channel: “I seem to be getting a different revenue number for September 2024 from this (link) and that (link) report. Can someone investigate, please?”

Sounds all too familiar? You’re not alone. I am yet to see a data team that hasn’t seen this problem, and I am not referring to a data quality or technical issue. I am referring to the issue that “revenue” or some other metric has been defined differently in different reports.

There are so many ways to get the definitions not to match:
- include or exclude different components
- use the merchandise value before or after discounts, the invoiced value, the received payments etc
- use a different timestamp: order timestamp, invoice timestamp, payment timestamp etc

Now that we have the semantic layer, all of those issues are fixed, right? We have all the metrics defined in code, there’s a single source of truth for everything and nothing can go wrong. We’re in a happy place now.

Unfortunately, the happy place doesn’t ship with the product. One has to work towards it. This session will be about building up that happy place in one of the largest companies in Europe, Bolt. Because in reality, there are quite a few steps to be taken to actually benefit from the semantic layer.

I am going to talk about:
- the decision to adopt the semantic layer
- the pains and gains of being an early adopter
- the process of wrapping your head around the new concepts
- more importantly, getting everyone in your company to understand
- the groundwork needed before defining any metrics
- the adoption strategy and our journey along the way

I strongly believe that semantic layers are the future for data teams and I will do my best to bring that future closer by sharing our experience.