Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#41

Post by texasbigdata »

cedricd wrote: post #26
texasbigdata wrote: post #25

So cool! Had a weekend tinker a few weeks ago that needed this use case and a quick search didn’t produce any useable light solutions so did it by hand. One tiny data point for y’all. Good luck! Edit: assuming eventually your schema transformation unlocks at least partially and you have at least some flexibility outside the default 11 column approach?

Great to hear from someone who also built this themselves! As far as flexibility beyond 11 columns: I'd love to know your use case. We do support additional metadata on each activity with what we call enrichment tables. Some events are going to need more metadata -- a page view would want to have the actual page, the five UTM parameters, referrer, etc, which is more than the 3 fields of metadata we store on the activ…

Conversely, isn’t literally any use case that doesn’t feed your schema something you can’t really support?

Went through your docs and the pre-populated “narratives” or query templates are thoughtful and probably capture a wide load of initial analytics (and will get better), however it’s a pretty narrow solution.

I guess technically if you have 1 table with support tables of metadata you are closer to a traditional relational DB, so maybe this isn’t as restrictive as it seems.

Excited to see your product iterate!

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#42

Post by cedricd »

texasbigdata wrote: post #41
cedricd wrote: post #26

Earlier quoted context omitted.

Great to hear from someone who also built this themselves! As far as flexibility beyond 11 columns: I'd love to know your use case. We do support additional metadata on each activity with what we call enrichment tables. Some events are going to need more metadata -- a page view would want to have the actual page, the five UTM parameters, referrer, etc, which is more than the 3 fields of metadata we store on the activ…

Conversely, isn’t literally any use case that doesn’t feed your schema something you can’t really support? Went through your docs and the pre-populated “narratives” or query templates are thoughtful and probably capture a wide load of initial analytics (and will get better), however it’s a pretty narrow solution. I guess technically if you have 1 table with support tables of metadata you are closer to a traditional r…

Yeah, that's true, but you'd be surprised by the number of things that can be modeled with an activity stream.

It's one of the more common objections people have as they understand the model, but in practice we've found that it's not an issue. Our CEO loves asking people to describe their hard data questions and then redefine them in terms of the activity stream.

The metadata support tables are actually an exception -- we don't use them frequently in practice.

Thanks for engaging with us. If you ever want to dive deeper into this we're always happy to chat.

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#43

Post by ZephyrBlu »

Everyone is talking about the tech, but I'm really curious about the marketing site.

It's very clean and looks great. How long, or how many iterations did it take to get it to this level? Did you do it in-house or contract it out?

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#44

Post by mritchie712 »

ZephyrBlu wrote: post #43

Everyone is talking about the tech, but I'm really curious about the marketing site. It's very clean and looks great. How long, or how many iterations did it take to get it to this level? Did you do it in-house or contract it out?

I'm in a similar space, what do you find most compelling?

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#45

Post by mattjstar »

ZephyrBlu wrote: post #43

Everyone is talking about the tech, but I'm really curious about the marketing site. It's very clean and looks great. How long, or how many iterations did it take to get it to this level? Did you do it in-house or contract it out?

Thanks! We actually worked with Superside to help us put it together: https://www.superside.com/

We worked with them over the course of a few weeks. Given how complicated the topic was we came to them with copy, layout and a few loose ideas for what graphics we need. The design and graphic work was all them though.

If you have any other questions about it happy to dive in deeper!

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#46

Post by jeremyis »

I worked at a big, high-growth tech company on a product team and saw first hand how much of a challenge cleaning up / joining data was. This seems like a really novel and useful solution to a big problem (and well timed on the heels of Snowflake's IPO news).

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#47

Post by modoc »

cedricd wrote: post #32
slotrans wrote: post #24

Hard to imagine a worse idea. The problem in data warehousing is not the structure , it's the definitions . It doesn't matter one tiny little bit whether you store your data in a fact/dimension star schema, a normalized OLTP-style schema, arbitrary aggregate/rollup tables, or this one-table monstrosity you've constructed. You still have to do the work of determining what the data means . This isn't 50% of the work of…

Appreciate the skepticism, since yes, we're a totally different approach. I'll try to address your points in order. Yes, we agree that 99% of the work is determining what the data means. Our structure doesn't magically make things better because of its structure. It's that once you have it analysis / aggregation on top of it becomes substantially less work because you don't have to constantly redo models to answer ne…

If I am understanding correctly, if my BI folks want to report on things like order total or order sub total, or order sub total + shipping, or order sub total + tax, or presumably anything about the contents of the order (SKUs, quantities, per item pricing, price adjustments, coupons and promotions, etc...) instead of capturing a "order submitted" event, we'd have to capture every add to cart, every cart pricing recalc operation, shipping address added, shipping method selected, shipping cost added to order, shipping method changed, new shipping cost added to order, etc... as separate events? And have the smarts to generate reports using the final selected shipping method (for example) for calculations?

For an average-ish B2C order that could be dozens of events, and for a complex B2B order that might easily be hundreds of events.

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#48

Post by ahmedelsama »

jeremyis wrote: post #46

I worked at a big, high-growth tech company on a product team and saw first hand how much of a challenge cleaning up / joining data was. This seems like a really novel and useful solution to a big problem (and well timed on the heels of Snowflake's IPO news).

Thank you. Once you start using it, then you will experience the difference and honestly there is no going back. You should try it or schedule a demo for your product team. I would love to showcase Narrator answering questions live for you.

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#49

Post by cedricd »

modoc wrote: post #47
cedricd wrote: post #32

Earlier quoted context omitted.

Appreciate the skepticism, since yes, we're a totally different approach. I'll try to address your points in order. Yes, we agree that 99% of the work is determining what the data means. Our structure doesn't magically make things better because of its structure. It's that once you have it analysis / aggregation on top of it becomes substantially less work because you don't have to constantly redo models to answer ne…

If I am understanding correctly, if my BI folks want to report on things like order total or order sub total, or order sub total + shipping, or order sub total + tax, or presumably anything about the contents of the order (SKUs, quantities, per item pricing, price adjustments, coupons and promotions, etc...) instead of capturing a "order submitted" event, we'd have to capture every add to cart, every cart pricing rec…

It's not quite that granular. I was more responding to the idea that there can't be a source of truth for these activities.

We actually have several e-commerce companies using our platform (with decently high volume). In practice we tend to see events like 'completed order' 'shipped order' 'product added to cart' 'order delivered'. I.e. they're all very discrete differentiated steps in the process.

There's a bit of an art between when to make a new activity and when to add it as metadata on an existing one. A completed order will more likely have 'discount code' as a feature than 'discount code applied' as an activity for example.

Your order completed event could have total amount along with tax, shipping, etc costs that add up to the total. It depends on the analyses you want to generate.

We do see things like an order submitted event with the total, num products purchased, discount code on it, and a separate 'purchased product' event with individual product price, sku, etc. Once can do things like MRR and another could let you identify best selling skus or product categories.

Happy to chat more offline if you want to dive into the specifics for your use case. We love digging into what sorts of analysis someone wants to do and figuring out which activities make sense https://calendly.com/ahmed-narrator/30min-1

Re: Launch HN: Narrator (YC S19) – a data modeling platform built on a single table

#50

Post by nsrivast »

cedricd wrote: post #33
newintellectual wrote: post #12

This sounds very similar to the approach used by Salesforce internally. How does it differ?

Hmm. That's interesting. I'm not familiar with what Salesforce does. Do you have any more info about it? I'd love to learn more!

I think this may be referring to Force.com UDD model [PDF]

http://www.developerforce.com/media/ForcedotcomBookLibrary/F...

Post reply on HN