Re: Eppo - they're similar in setup but Growthbook is open source with an optional cloud SaaS offering. Eppo is currently cloud SaaS only AFAIK.
Re: Optimizely - Optimizely is a walled garden, you need to push all of your metrics as events to Optimizely from your apps for any experiment analyses. Eppo and GrowthBook both connect to your data warehouse and support any metrics you can design in query form using your existing warehouse.
Not sure how this comment relates to PyMC3 though - PyMC3 is for Bayesian statistical modeling with MCMC. It uses Theano as a backend. Keras is a specifically for neural networks.
In my experience you have to strike a balance between allowing exploration that unblocks people outside the team to look into data (with a bit of a buyer-beware attitude) to help them build intuitions while making sure that core metrics that you use internally and/or share publicly are appropriately vetted. Using Aleph or other shared SQL tools like it allows us to quickly look at a query someone else on another team has built and provide support. Making time to walk through core tables and their pitfalls as part of SQL training can also help.
Reporting on core company metrics needs to be curated and owned by people with the right expertise. In some cases we'll build additional views on top of our core BI layer that simplify a lot of this information for some of the examples you're describing (like the number of active customers at different points in time) and use to drive our dashboards, and people can query from those. Aleph also supports tagging and ad hoc parameter setting, so you could fix and build off of more novice users' queries, tag them as "official" and allow them to set parameters like time ranges.
But at the end of the day, AFAIK there's no silver bullet here - you have to train people in the pitfalls of your data and expect that they'll make some mistakes but it's part of the data team's responsibility to help them learn. As individuals in different groups gain expertise, they can help each other too. The alternative extreme, where a priesthood owns all data analysis will avoid mistakes, but it won't allow your team to work on activities that are both high leverage for them and provide more value to the company.
We actually control access to our raw data sources. The vast majority of people looking at data look at data we surface in our BI layer in Looker (or in Aleph if they know SQL).
I didn't focus on this in the article, but in addition to removing sensitive information, that layer simplifies a lot of the complexities of our app's data models. Core calculations like the one in your parenthetical example live in core dashboards that the Data Analytics team owns.
Raw access is limited to our applications like Airflow and a small number of authenticated users. So an engineer can easily go into our Airflow repo and add some new columns to a table in the BI layer by updating the SELECT clause of the query that creates that table, without needing to access the raw data themselves.
Thanks! this approach has worked well for us so far, and we have a lot of product engineers writing their own ETLs for new features that launch at this point. We've found enabling teams to self-serve where possible works well for us, and it's something we're continuing to invest in with training both on the engineering side (eventing, instrumentation and ETLs) and on the analysis side (e.g., with SQL training).
Our data warehouse does look pretty typical, and this is at least partially intentional. We're cautious about jumping onto new technologies when we don't need to yet given the scale of our data, especially if it would make it harder for other teams to contribute.