ahmedelsama

The Bloom filter framing is right. What made it work for me: the cheap model is only allowed to point, never to decide. Once it stopped judging anything and just returned file paths and line ranges, the quality complaints disappeared. The expensive model still does all the reading that matters, just on 10% of the bytes.

GLM 5.3 Flash is crushing benchmarks and is dirt cheap. This interested me so I moved our entire step to it and that was a disastor.

AI is changing a lot. The traditional pipeline will not continue: Customer / Leadership (what/problems) → Product (product solution/UX) → Engineering (implementation) I argue that the future will be way smaller cycles. A new product role will talk with customer, build prototypes and ship code Engineering will be investing in the system - ensuring AI generated code is good and reliable What do you all think?

In this role you will: - Be a product expert of Narrator - Build analyses/dashbaords to help drive decisions - Develop content that enable new customers to learn the Activity Schema

A look into different kind of metrics and which can help you improve your customer conversion

A quick course where you can learn how to go beyond star schema when you want to learn how users interact with your services with activity schema and use Narrator to ask and answer complex questions quickly.

Yeah I love this! Well said

I think the ideal is start with something that you think is causal, then do the discussed correlation analysis then it it looks fruitful, start testing by changing the distribution of the feature and if it is causal then you should see the kpi move in the same direction.

Does that make sense? Smaller steps to make sure you only invest if it is worth it

I took the blog to mean something a little different. You should pursue causality but not everything is worth the work so start with a faster easier correlation analysis, then it it seems worth it you can test it to see if it behaves as expected.

Working in data, especially in a startup, we often need to make so many decisions and trying to change the culture is good but when it’s a fire then this approach would get us the furthest

I like this a lot. I studied Bayesian mathematic and in my opinion it’s the beat approach to solving these problems. Start with a prior and continue to update your state with measurements. This avoids a lot of the common pitfalls when doing batch ML and getting junk results

Does anyone know any other way that is fast and easy to implement?

This is incredibly well written and covers everything I thought about

I am a data person and I never knew about the boundary counting. Like you can have a `day diff` be 3 and the `week diff` be 1 and the `month diff` be 1 You can also have `day diff` be 25 and the `month diff` be 0.

I would love to know why warehouse do this because as a data person it confuses me and is even more confusing to explain to stakeholders.

This is really great. I think it is about what and how one is being tracked. I think people are trying to stop companies from tracking them everywhere but if I am interacting with a single company, I know they are tracking some things. Foe example, if I buy off of an e-Comm website then they should have tracked my order so I can go back to it.

This extends to support. I hate submitting a support ticket to just be told to go view the docs that I already viewed, or try things I have already done. As a customer, I want you to know I did that and to help me.

All this is trying to do is allow company to understand their customer within their own platform and own data.

This is not trying to fingerprint users or track everything they do on all websites like Facebook and other platforms.

I hope this clears up the motivation. In short, it is to resolve issues in using the data that a company has internally and is not about creeping on users across the internet.

In addition, if you are using Saas products like Shopify, you already have unique urls for carts and orders so you can also use that without any additional engineering.

Honestly putting the cookie as a param is pretty clever. The challenge with cookies is there are often many cookies that point to one person. Imbedded browsers, multiple devices, cookies being refreshed by browsers. So seeing the full journey requires stitching all the cookies

Love it! This is super similar but we allow many different layers of conversions. So anytime we bridge systems you can connect the user. This is critical with the many browsers, devices and so on. In e-commerce we see that emails have such high conversion rates but they are often opened on the phone then the user buys on the browser without clicking. These situations are captured by doing the many layers of identity resolutions

Well your tracking a user via the Anonymous id. Once you see a link (checkout url, order link, form submission, etc) you create a link. Now you have a list of cookies, their linked email at a moment in time. Then you create a table that has the cookie and who it maps to from a timestamp to a timestamp. This is then used to update the past and future identities. Think multi-user, multi-device in time.

So in the example you gave, the user who opens that links becomes tied to that cookie from the time they open the order to the next linked event. This is really critical because it will continue to stitch the users identity over time.

If link sharing is happening a lot, you can choose to not use that linkage foe identity resolution.

Does this help clarify the approach?

Identity Resolution via warehouse is the future!!! I love this!

Yeah, for this blog, it was optimizing a Postgres table with 100m records. so 1000x more and thus all these issues came to be.

That is really great to hear! I think you make a great point and we will discuss your recommendations internally to improve our messaging.

I am excited to chat in person.

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.

Yeah our first iteration of the activity stream was at WeWork and it was impossible to use. For this reason we built our Dataset tool and thanks to our innovation of relationships we are now able to make use of this structure to create any table.

Often, people think that just creating a time-series table is enough but it is so hard to use and so hard to maintain that you will hate yourself. Narrator solve all those problems so your experience become truly incredible!

Definitions are super important. Getting agreement on definitions is really hard and can easily get us stuck in a loop.

In my last job, we spent months talking about "What is a Sale?" is it when someone signs a contract or when they pay or when they move in, etc...

Then you add your sale metric into a table and as that table is used in different places the sales numbers till don't match, people don't remember what a sale is and the conversation starts up again.

Why is Narrator different?

In Narrator, you don't define what a sale is, you break up your data into customer actions. So "Signed Contract", "Paid Invoice", "Moved In" and thus as people ask different questions we can alway clearly see what they are referring to.

Step 1 to alignment is guaranteeing consistency and transparency.

How do you deal with states? You are right that does make it really hard. We see customers leveraging the incremental aspect of the activity stream to diff the stream with the updated_at to pull out changes as the activity stream updates. (every 15 minutes so yes you will loose changes in between that time). This doesn't solve the problem but does take you much closer. And then when you do add proper timestamps then you can have historical data in the activity stream and cleaned data from you new tables merged. All the users using that activity are NOT affected.

Not perfect but allows us to have as accurate data as possible.

What about the market? Yes, I agree the market is a challenge since the world has been only using star schema. We hope that standardization, speed, reusability aspect of Narrator is so compelling that people slowly switch.

How do we get numbers to match? Consistency and Transparency. Every one who uses the "Completed Order" uses the same revenue. SO it is consistent! Then you can add the "Shipped Order" activity which has the shipping amount.

By having clear CONSISTENT definitions and clear activities you end up in a world where your numbers match. The only ways for numbers not to match is if some is being deliberate about getting the data not to match which thanks to dataset, is always transparent.

Definitions are a social problem but technology, limitations and consistency can help a lot.