We’re working on automation around how we manage dbt schemas and tests – particularly maintaining dbt models (schemas and tests) for our ever-changing raw analytics events, which are typically updated with every feature release. Our trigger for kicking this off was that we just finished an internal hackathon where we ended up building a dbt utility that we’re excited to take further and open source.
Right now we’re particularly focusing on metrics that we compute by tying together those ever-changing raw analytics events (e.g. "Account Created", "App Opened", "Code Generated") with data from our backend and 3rd party tools like Stripe.
We want to make sure to build something that makes sense for a wider and doesn’t reinvent the wheel – so we’d love taking into account some HN perspectives.
If you’re up for contributing to our research (and maybe even building with us), we’d appreciate your answers to this quick 4-9 min survey. It’s a mix of situational questions (your data stack) and open questions on how you manage the steps from when a success metric has been defined (pre feature release) until the insights are visualized.
That's correct. Avo today is particularly designed for consistency issues. Coverage issues are top of our mind though, and we have some internal tools for that that we're excited to share soon.
Thanks for taking the time to clarify.
Thank you for surfacing the need for a better demo and examples.
> I'm currently managing a team using Google Analytics, Facebook Pixel and Hotjar.
Avo is optimized for event based analytics, such as when people send events with metadata into Amplitude, Mixpanel, Segment or into custom pipelines. Are you sending custom events into the platforms you mentioned, and sending metadata along with the events?
> From what I understand, I can use Avo to setup flows that I want to watch (like a sales conversion funnel) and make sure that the analytics tags are properly implemented across all pages of the funnel.
You can use Avo to define the structure of the events that you want to send at each step in that flow. From those definitions, developers can generate code that validates that the event structures are correct.
What I mean by event structures is for example event names, which properties should be required on those events, what those properties should be named, and which type their values should be.
An example event could be:
event name: "Checkout Completed"
properties and their values: {"Number of Items": 2, "Amount": 100.00, "Currency": "USD"}
> In the case that the sales funnel changes and a new page is added, do I need to remember to update Avo with the change?
If your data should change along with the sales funnel change, then you should update Avo and then your code.
> I've been frustrated at the absence of any integration with my eng teams build/CI systems or really any automated way to catch problems at the PR or code review stage. Is this something on your radar?
CI / GitHub integrations are definitely on our radar. We have already integrated `avo status` in our own CI pipeline (see https://www.avo.app/docs/reference/regression) and we are excited to do more. I would love to understand your desired use case. If you want to share feel free to continue here or email us at friends@avo.sh.
> I feel strongly that the data organization needs to own this outright, and the only thing holding them back was the right tooling. This seems like the perfect tool to enable it. Very excited to give it a spin.
Glad to hear. We can't wait to hear what you think.
We do - that's how Kafka Registry knows what schema to apply for the Avro message. If you like, you can ping me at my username + gmail and I can answer any other questions about what you're doing.
Right now we’re particularly focusing on metrics that we compute by tying together those ever-changing raw analytics events (e.g. "Account Created", "App Opened", "Code Generated") with data from our backend and 3rd party tools like Stripe.
We want to make sure to build something that makes sense for a wider and doesn’t reinvent the wheel – so we’d love taking into account some HN perspectives.
If you’re up for contributing to our research (and maybe even building with us), we’d appreciate your answers to this quick 4-9 min survey. It’s a mix of situational questions (your data stack) and open questions on how you manage the steps from when a success metric has been defined (pre feature release) until the insights are visualized.