Beyond the Build: How We Helped Upstream Understand Their Product Through Analytics

Beyond the Build: How We Helped Upstream Understand Their Product Through Analytics

When a product launches, the work doesn't stop at deployment. The real questions start arriving: Are people using the product? Which flows are they using the most? Where are they dropping off? For Upstream, a nonprofit focused on expanding access to contraceptive care for underserved women, answering these questions and adjusting the product as needed was critical to achieve their mission. As a product manager at Echobind, I was positioned well to understand how to create the tooling in order to help take our engagement with Upstream beyond feature delivery and build a window into how their users actually experience their platform, FreeBC.

The Platform: "FreeBC"

FreeBC is a digital tool designed to guide users through contraceptive education and connect them with care. The application includes a “quiz” flow, which guides users through questions aiming to capture their preferences surrounding lifestyle and priorities for birth control, and provide them with results based on methods best for them. It also has an AI chatbot, trained using materials used to train clinicians. It also has 19 method detail pages, which contain information from clinicians regarding pros and cons of the method, video testimonials from real users, and pathways for both telehealth and clinic-based care completion. Upstream had meaningful questions they needed answered before and after launch:

• Which campaigns were driving the most traffic?

• Were users completing care pathways in a single visit or across multiple sessions?

• Were lower-income users gravitating toward telehealth or clinic-based care?

• Which methods were most popular?

• Were users actually engaging with the AI?

• Where were users dropping off in the quiz, the method exploration, and the telehealth flows?

The list was long, and it reflected a team that genuinely wanted to understand their users, with the goal of ultimately improving the product.

PostHog

PostHog was already in the stack, as it’s Echobind’s analytics tool of choice. The challenge for us wasn't access to data, it was how best to structure that data. Raw event data flowing into PostHog is only useful if you've thought through what you want to capture, how you want to group it, and what questions those events are meant to answer. The first phase of the work was translating Upstream's business questions into an analytics architecture: funnels, insights, and dashboards that could surface real answers. Some questions mapped naturally to PostHog's out-of-the-box capabilities. Conversion funnels became the primary tool for understanding the telehealth and clinic care pathways. These helped us track where users entered, where they advanced, and where they left. Drop-off points in the quiz, method exploration, and care flows were modeled as distinct funnel stages so the team could see exactly which steps were losing users. Other questions required a bit more creativity. Tracking scroll depth, CTA clicks by location on the page, video engagement, AI chatbot interactions, and filter usage meant thinking carefully about what events were being fired and whether they'd hold up over time.

The Event Tracking Decision

Early in the process, the team went through three distinct phases of thinking about event tracking, and each phase taught something the previous one couldn't.

Phase one: autocapture. PostHog offers autocapture out of the box, which automatically records user interactions without any developer instrumentation. It requires near zero work to set up, and an immediate flow of data. The team started here, using autocaptured events to begin building funnels and insights. This worked until the limitations became apparent. Autocaptured events are opaque. You can see that something was clicked, but tying it reliably to a specific interaction, across users, across languages, across product changes, is fragile.

Phase two: interaction IDs. The next step was attaching interaction IDs to PostHog events. We manually tagged elements in the codebase so that events could be identified more precisely and used more generally across insights and funnels. This felt like a meaningful improvement. Instead of relying on PostHog to guess what happened, the team was asserting it from the level of the codebase. But the cracks started to show as the team went deeper. The core problem was brittleness. Interaction IDs are scoped to how components are structured in the code. If a developer refactors a component, even without changing any functionality, the interaction ID can change silently, breaking any insight or funnel built on top of it. And because developers have no visibility into what PostHog is tracking through these IDs, they wouldn't even know they'd broken something. There was also a multilingual dimension. FreeBC currently supports both English and Spanish users, with the goal of expanding to more languages in the future. Interaction IDs tied to text content would fail to capture Spanish-language interactions consistently, meaning any funnel built on them would have a hidden gap in the data.

Phase three: custom events. The team landed on fully custom events: deliberate, developer-placed tracking calls that fire when specific things happen in the app. More setup work upfront, but dramatically more reliable. When a developer sees a custom event in the code, they know that interaction is being tracked, and if they change the component, they know to preserve it. The tracking is no longer silent to the people maintaining the codebase. The team also designed the custom events to be dimensional rather than exhaustive. Instead of creating a separate event for every pill on every method page, a single pill_clicked event carries properties like method and prompt_text. Instead of a hundred CTA events, a single cta_clicked event with placement (e.g., home_hero, home_get_real) and target_url. One event, many dimensions, and fewer things to break.

Building the Dashboards

With a cleaner event architecture in place, the dashboard work could begin in earnest. The dashboards were organized around Upstream's core questions:

Acquisition — Where are users coming from? UTM source and medium tracking gave visibility into which campaigns drove traffic, and how those sources correlated with deeper engagement versus immediate bounces.

Engagement — How are users actually moving through the product? Page view tracking, scroll depth, and CTA click events made it possible to understand not just that users visited a page, but how they interacted with it. Funnel visualizations showed the most common paths users took before completing a care pathway.

Care Pathway Conversion — The telehealth and clinic funnels were the heart of the analytics work. Each stage of each flow was instrumented, so Upstream could see exactly where momentum was lost. Were users dropping off when asked for their zip code? After viewing their best-fit method? Before completing the telehealth intake? These answers would directly inform product iteration.

AI Engagement — The AI chatbot was a major feature investment, and Upstream wanted to know if it was paying off. Tracking chatbot opens, the pages users were on when they engaged with it, and the volume of back-and-forth exchanges gave a picture of how the AI was being used — and whether users who engaged with it were more likely to complete a care pathway.

User Demographics and Outcomes — Some of the most meaningful questions Upstream had were about equity: Were lower-income users completing care differently than higher-income users? How did age correlate with method selection and care completion? These questions intersected with a separate data mapping effort, but the PostHog instrumentation was designed to leave room for that analysis.

What This Kind of Work Actually Takes

One of the things I took away from this engagement is how underestimated analytics work tends to be, especially on product teams moving fast toward launch. Setting up event tracking isn't a checkbox. It requires product thinking (what questions matter?), technical judgment (how do we structure events so they're maintainable?), and ongoing coordination between PMs and engineers. We were doing a lot with a little, and that constraint forced some real clarity. It pushed us toward the custom events approach, which helped us create analytics dashboards that would hold up over time as the product evolved.

The Bigger Lesson

Upstream's mission is to make contraceptive care accessible to women who face the most barriers to getting it. Every drop-off in the quiz, every user who didn't complete their care pathway, every AI interaction that didn't lead somewhere represent real people who came looking for help and didn't quite get there. Building the analytics layer helps to serve that mission. It gives Upstream the visibility to ask hard questions about their product, learn from the answers, and keep improving. Delivering a product is the beginning. Understanding how it's actually used is what makes it better.