--- title: "When Product Telemetry Outgrows the Marketing Stack" id: "603" type: "post" slug: "frameio-product-events-marketing-pipeline" published_at: "2026-06-09T22:28:00+00:00" modified_at: "2026-10-21T22:30:22+00:00" url: "https://compiledrogue.com/articles/frameio-product-events-marketing-pipeline/" markdown_url: "https://compiledrogue.com/articles/frameio-product-events-marketing-pipeline.md" excerpt: "When Frame.io's product telemetry grew into millions of events, sending everything downstream was no longer practical. We extended the marketing data architecture with Kinesis, Lambda, and Segment to filter, transform, and route meaningful signals." taxonomy_category: - "Selected Work" taxonomy_post_tag: - "AWS Kinesis" - "AWS Lambda" - "Data Architecture" - "Event Processing" - "MarTech" - "Segment" --- June 9, 2026Selected Work ## When Product Telemetry Outgrows the Marketing Stack # How we helped Frame.io turn millions of raw events into controlled marketing signals using AWS Kinesis, Lambda, and Segment. One of the clearest signs your product is maturing isn’t more data. It’s realizing that **not every event belongs in your marketing stack**. I’ve found that when teams start asking which events should actually make it downstream, it’s rarely because the tools are failing. More often, it’s because the product has matured, customer behavior has become more complex, and the business has outgrown the assumptions its original data architecture was built around. A project with Adobe’s [Frame.io](https://frame.io/) marketing team made that pattern very concrete. ## Millions of Events Is a Good Problem to Have As Frame.io’s product telemetry scaled into millions of events, the marketing stack needed a more deliberate way to preserve valuable signals without sending every raw event into every downstream platform. That is a great problem to have. It means the product is generating meaningful behavioral data, the customer base is active, and the growth operation is mature enough to use product activity in meaningful ways. But volume changes the nature of the work. At a smaller scale, the job can look like connecting a source to a destination. An event occurs, an analytics tool records it, and a marketing platform does something useful with it. At a larger scale, that same approach can create a flood of low-value data. Product activity is useful for understanding the product, but that doesn’t mean every event should trigger an automation, update an audience, affect a score, or travel to an advertising platform. The problem isn’t collecting the data. It’s deciding what should leave the product data environment and what the marketing systems should actually be responsible for consuming. ## Putting a Processing Layer Between Activity and Activation Segment was already part of Frame.io’s workflow, but millions of raw events created a different class of problem. We needed controlled processing between product activity and downstream marketing activation. We extended the event architecture with **AWS Kinesis and Lambda** so events could be throttled, filtered, transformed, and routed before reaching marketing automation, lifecycle, and advertising platforms. Those four operations matter for different reasons: | Operation | Why it matters | | --- | --- | | Throttle | Control how much event traffic reaches systems that do not need every raw occurrence. | | Filter | Keep low-value or irrelevant activity from entering a downstream marketing workflow. | | Transform | Give the events that do move forward a consistent, useful structure. | | Route | Send the right signals to the systems that actually have a reason to use them. | This is the part that can be easy to miss when talking about MarTech. The work isn’t finished when an integration successfully sends an event. That only proves the plumbing works. The harder question is **whether that event should have been sent at all**. ## A Marketing Signal Is More Than a Raw Event Reducing volume wasn’t the goal on its own. The goal was better signal quality. That meant working beyond the stream-processing layer, including Segment workflows, Personas configuration, lifecycle routing, trial and account state logic, and enterprise suppression. Those concerns are related, but they aren’t interchangeable. A product event describes something that happened. A useful marketing signal gives a downstream system enough context to decide whether it should act. That can require more than passing along the original event name. Trial status matters. Account state matters. Whether a customer should be included in a lifecycle journey or excluded from a campaign matters. And sometimes the right decision is to send nothing. **Important**The objective wasn’t to reduce visibility into the product. It was to avoid treating every piece of product telemetry as an instruction for the marketing stack. That last point is important. A product can have excellent instrumentation and still make poor decisions about marketing activation. Collecting useful data and distributing useful signals are separate responsibilities. ## The Pipeline Needs to Be Observable, Too Once a data pipeline starts deciding what moves downstream, it becomes part of the operational system. It can’t be treated as invisible plumbing. We used **Amazon CloudWatch** to monitor throughput and anomalies. That gave us visibility into the processing layer itself, rather than leaving teams to infer its health from whatever did or didn’t appear in a destination platform. It’s easy to focus on whether a campaign or audience is behaving correctly and overlook the system that feeds it. When that system includes filtering and transformation, observing the flow matters just as much as observing the final destination. This doesn’t require pretending that a pipeline is perfect. It requires enough visibility to recognize when behavior changes and a clear understanding of which layer owns the problem. ## What Changed The result was a more stable and intentional marketing data path: fewer low-value events moving downstream, less strain and overage risk for vendors, and a clearer separation between millions of raw product events and the signals that should drive marketing systems. I wouldn’t claim that the right architecture is always Kinesis and Lambda. That’s what fit this problem. The broader point is the need for an operating model that can make deliberate decisions between product activity and downstream activation. At smaller scale, marketing data architecture can look like connecting tools and moving events. **At larger scale, it becomes a control problem.** The mature move is not sending more data everywhere. It’s building enough discipline into the system that the right data gets to the right place for the right reason. This is the practical side of an argument I made in [Not Every Product Event Is a Marketing Signal](https://compiledrogue.com/articles/not-every-product-event-is-a-marketing-signal/) . The perspective is simple enough. The engineering work begins when the volume, dependencies, and operating requirements make it impossible to ignore.