I picked up a project that was largely in the same state as your end state, and the additions to the above Starter Stack was:
1. Allow product team to take better control of event definitions (using Avo). I think this is probably more important than most realise, and the first thing that teams will struggle with once they get beyond accessing everything.
2. Improve the actual product analytics capabilities. Using dbt+Looker for Product analytics is in my mind an anti-pattern as it leads to a huge bottleneck for product teams to answer their own questions. We ended up using Posthog.
The Starter Stack you describe is great for pure BI tool consolidation reporting, but pure BI is pretty static and frustrating for Product teams, hence the additions. The additions create infrastructure headaches, but worthwhile for the sake of Product teams.
Hi Matt! I agree those are the logical next steps in growing product analytics. But I think you are focusing on only have of the space. If the client had a customer data platform and frontend-driven platform, Posthog or my fav Amplitude would be great.
This was a warehouse-first play, not a real-time play. They did basic funnels and web analytics in heap, and it worked great. The rest of the company was driven by backend systems and the data-flows (even product activation back to app) out of the warehouse. With this design, building a central modeling layer in DBT and treating Looker as if it were a headless BI tool worked great. Product and business analytics was fast and met all their needs.
Be curious why you see a warehouse-first play as an anti-pattern when running self-serve product analytics?
I picked up a project that was largely in the same state as your end state, and the additions to the above Starter Stack was:
1. Allow product team to take better control of event definitions (using Avo). I think this is probably more important than most realise, and the first thing that teams will struggle with once they get beyond accessing everything.
2. Improve the actual product analytics capabilities. Using dbt+Looker for Product analytics is in my mind an anti-pattern as it leads to a huge bottleneck for product teams to answer their own questions. We ended up using Posthog.
The Starter Stack you describe is great for pure BI tool consolidation reporting, but pure BI is pretty static and frustrating for Product teams, hence the additions. The additions create infrastructure headaches, but worthwhile for the sake of Product teams.
Hi Matt! I agree those are the logical next steps in growing product analytics. But I think you are focusing on only have of the space. If the client had a customer data platform and frontend-driven platform, Posthog or my fav Amplitude would be great.
This was a warehouse-first play, not a real-time play. They did basic funnels and web analytics in heap, and it worked great. The rest of the company was driven by backend systems and the data-flows (even product activation back to app) out of the warehouse. With this design, building a central modeling layer in DBT and treating Looker as if it were a headless BI tool worked great. Product and business analytics was fast and met all their needs.
Be curious why you see a warehouse-first play as an anti-pattern when running self-serve product analytics?