stefaniabje

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.

You might wanna check out Rudderstack or Stitchdata:

https://rudderstack.com/guides/how-to-load-data-from-google-...

https://www.stitchdata.com/blog/google-sheets-stitch-easy-sy...

And here's a reverse path from Census as well:

https://www.getcensus.com/sync/redshift-to-google-sheets

So excited about this. And really proud to be working with the Patreon team through Avo

https://www.avo.app/customers/patreon-case-study

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.

It's great that you think so.

Thank you for the Docs pointers! Good spots. We will make sure to fix these.

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.

Thank you for pointing that out. We will make this clearer with a pricing section. Here is the pricing model:

Avo is $15 per seat per month for schema documentation and codegen.

> 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 [email protected].

> 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.

Thank you! Are you personally familiar with it as well?

Thanks for sharing.

> We try to append to our messages to keep backwards compatibility.

Do you additionally do versioning, or do you solve it by only allowing backwards compatible changes such as appending to the message?

Thanks for sharing! So it seems you may end up using an incremental counter as a version – or was that a placeholder example?

What are the main use cases for the data pipelines you're forwarding your data into? Are the events fairly rich or fairly simple? Do you plan on doing any type validation as well?