Finally we can do some fun learning together. In October it will be an introduction in how to build better tracking setups. With two live sessions (that will be recorded and added here), daily tasks and exercises and any question you can ask about the topic. Here is the schedule: 22.09 - Pre warmup weeks: I will share all my failures that I did and saw when working on analytics set up. We are setting up the mood to see and learn what we can done better. 06.10 - The best tracking plans cohort is finally kicking off. 08.10 - First live session in the cohort - I will show you in 90 minutes why regular tracking setups don't work and what we can do different instead 07.10 - 31.10 - daily tasks, questions and exercises on the platform that you can follow along and share your thoughts and learnings 15.10 - Voting starts on what cohort we will run in November (yes, you can pick with your votes) 22.10 - Second live session where we dive deeper into all the topics we have started to learn about 29.10 - Our second ALT+ open office hours - join and share your questions and challenges

If you have watched the lesson on Day 4 already you will know that I have a close relationship with properties. Reason #1 -> they can give you the hints in your data that will move the needle in your setup. A specific customer attribute that performs better, a campaign that brings in new users that beat every other cohort. Let's have a look at some properties for ChatGPT that can help them to surface these segments. We define the properties based on the entities we have defined: Account: - account_id: we love ids to later enrich the dataset - account_type: free/paid - in a freemium model this is an existential property to segment two very different account types. Also to understand how well the free model works as channel to paid conversion - account_range_lifetime_chats: how many chats does this account had in its lifetime. This is a range property to make the analysis straight_forward but we would also track account_num_lifetime_chats - account_days_since_last_chat: helpful to understand power and from time to time users (could also need a ranged property) Chat chat_id chat_range_tokens - to understand the size of the chat, could also be broken down into input and output tokens chat_days_active - to understand how many chats last of days or weeks Again the fun part about properties is that they are quite flexible and often tied to specific analysis use cases. Therefore they can change over time.

After defining the entities for ChatGPT now it is time to define the activities. Again, remember to think about a lifetime journey with core milestones. Here are the entities that I would use and the activities I would start with: Account - created - the start of the customer journey. Important event for top of the lifetime events - deleted - not a significant event unless you delete accounts after time of inactivity. If you don't do it better use inactivated or set inactive. Subscription - created - renewed - contracted - expanded - cancelled - churned Just the classic MRR bridge/waterfall events Chat - started - finished - if we don't track messages, we would need an event that determines when a chat is finished. This is a classic session calculation case. You could start from the backend to send this after 10m of inactivity. - restarted - important event to send after the chat has been flagged inactive. This helps you to understand if your finished event makes sense or not (when you have plenty of restarts that are just minutes away from the finished) In general, you need to watch this and see if it better needs the messages tracked. Again tracking messages would be semantically a lot easier but it creates massive volumes. If you track messages, you just need a message sent event. Task - started - finished The tasks are special tasks that the model will perform. It would be an abstraction on top of a tool use. This would need a good task categorization, like deep research, web search, image generation, code generation.

It's now a good time to practice more our skills that we have developed now over the last seven days. What I want you to do is to think about how would you design the entities for ChatGPT. Let's be warned, this is not a simple example. The simple examples we had in the videos. ChatGPT is something that is a little bit exotic because it behaves differently like other products, but therefore it's a super interesting exercise. The exercise for today is: 1. Define the core fundamental entities for ChatGPT. Really think about what is maybe the core entity that is really driving ChatGPT. This might be quite obvious, but also think about the entities surrounding that. 2. Think a little bit more about current strategic moves that OpenAI is doing (just with latest releases). Where they have Operator that is doing stuff for you on the Internet, then they have this new Agent Mode where you can build workflows then they have Codex where you can develop applications from your command line. There are different kinds of directions, so feel free to just pick one and think about how could you create the entities for that. I will create my versions of this as well tomorrow morning, so I will let you know what my thoughts are about that. If comments are not working here, make sure that you first join the space and then write the comments. If they're still not working, just send me your answers via email, and I will have a check. I will also check how we can get the comments up and working, so that we all have the possibility to participate in that.

The first lesson / video will drop later today together with a tiny exercise for you. Maybe do some jumping jacks to warm up.

The most expensive sentence in product analytics. Picture this: Six months of development. Countless sprints. Multiple rounds of QA. The feature is polished, tested, and ready. Tomorrow's the big launch. Then someone asks: "Did we add the event tracking?" Silence. We all have been here. The Sliding Backlog Syndrome Here's how it typically unfolds: Sprint 1: "We'll add tracking in the next sprint" Sprint 5: "Let's focus on the core feature first" Sprint 10: "We're too close to launch to risk breaking anything" Launch day: "Can we add it quickly?" The answer is either a rushed, error-prone implementation or launching blind—neither option is good. Why This Keeps Happening Event tracking consistently slides down the backlog because it's never seen as "blocking" the feature. The feature works without it, right? But here's what you're actually launching without: -> No idea if users even find the feature -> No way to measure if it solves the problem -> No data to guide iterations -> No proof of ROI for the six months invested (ok, this is even hard with data) The Simple Fix One line in your definition of done: "Tracking implemented and tested." (you don't have DoD - well, we should have a different talk). Make tracking requirements part of the initial user stories, not an afterthought. When you write "User can upload video comments," include "Track when video comment is started, completed, and viewed."

I would say I spent most of my time when debugging tracking and analytics with finding out why the funnels look weird. Identity issues can be nasty, because they often are not binary (works, works not), but just in part of the data (people with specific flows). And they can create a lot of distrust in the data. Sign up on desktop, confirm email on mobile? That's two different users in your analytics. Your backend sends beautiful events with user IDs, but they never connect to the frontend because you forgot one identify() call. In B2B marketing it is even worse site → app → payment flow. Each step is another chance to lose the thread. That enterprise deal that closed last month? Good luck proving it came from that LinkedIn campaign. You need a clear identity strategy (I usually have a Miro board with user flows and systems involved) to understand potential break points and where to test regularly.