5 key lessons from building our Newswire Analytics Platform

For over a century, newswires have distributed their stories via RSS feeds, teletype machines, and even The Pony Express. What do each of those mediums have in common? They send stories out into the ether, and are difficult to measure.

In late 2021, with stories from our newswire being published by over 700 outlets every month,  we realized how crucial it is to track the performance and reach of our coverage beyond anecdotal feedback. Hence began an 18-month process to ensure we didn’t fall victim to the same challenge that has plagued newswires for over a century: publishing stories without a clear feedback loop on what resonates with our audience.

Solving this problem is crucial to our success; today, we provide a free newswire to over 2,000 publishers nationwide. A content studio subsidizes the newswire, which requires us to prove the value of running stories on the Stacker Newswire, and our analytics platform has become pivotal in ensuring we can optimize the value we provide to customers on both sides of the marketplace.

Keep reading for a walk-through of our development process from alpha to full product launch, and reflections and lessons learned.

Our three product development cycles

Alpha

To begin, we created a pixel that would be attached to all stories that ran across our RSS feeds and in our publisher-facing portal, Story Hub. This approach provided us with an extremely low cost of entry, but it wasn’t scalable, as it required engineering resources to export the data from the database manually.  

There was also no connection to our CRM, which meant we had a giant list of URLs but no way of easily identifying whether the syndicated stories (“pickups”) were from one of our publishing partners. It served as an important foundation, but there was more to do.

Beta

Next, we built a web app on Heroku that tied into our Airtable CRM and allowed us to run a series of reports that sliced the pickup data by story or publishing partner. During this process, we pulled together a small group of Stacker employees to raise problems they were looking to solve and to provide regular user experience feedback. We kept our focus narrow and said no to requests that might distract us from core functionality.

As a result, the system was intuitive and easy to navigate without feeling overly burdensome. Based on feedback, we also added a series of alerts; for example, whenever a publisher hasn’t picked up a story in 30 days or whenever a story has slow pickup velocity. These alerts now trigger our team to reengage a publishing partner or consider republishing a story or rewriting a headline.

However, we didn’t spend enough time considering the eventual scale of the product and suffered from outages and slowness as the database grew larger and larger.

Full-scale product

Once we had validated the product’s desirability and feasibility, it was time to make it viable long-term. We built an analytics platform for scale on DigitalOcean using NodeJS and Postgresql. It integrated seamlessly with our CRMs (Airtable and HubSpot) and CMS (Drupal). We also integrated a third-party authentication service and developed training materials both for our in-house account managers and our clients and partners accessing the platform.

Lastly, we began to separate each user persona’s experience and features.

• For our Studio clients, we built a customer-facing platform on Next.js that gives real-time access to performance results for each of their stories.
  

• For our partner success team—who work with publishers to ensure they’re getting the most out of the newswire—we provide robust data around the stories our publishing partners are picking up so we can tailor our outreach to them when we publish stories that match their publishing behaviors.
  

• And for our newsroom, we built a dashboard to help identify the stories resonating most with our audience.  
  
  

What we learned

There were a lot of lessons learned throughout the project—some new and some reinforced. Here are a few key takeaways for product managers navigating the transition to a successful product launch.

Lesson 1: Build your MVP outside your primary tech stack.

When you’re operating a 24/7 newsroom, uptime and reliability are critical. You need to spend countless hours architecting, budgeting, and reducing risk for new tech stack updates. You must think about changes to workflow, regression testing, critical security patches, and the list goes on. Is it really worth it to do all that when you’re just testing a new idea that might not work?

Once we got to the beta phase, we built the analytics platform outside our standard tech stack. This allowed our primary developers to stay focused on the production-ready platform and let a separate team to go all-in on building a system we knew would get us to market quickly, albeit with a potentially limited shelf life.

It’s a gamble we were willing to take, and if we went back in time, we’d likely make the same decision.

Lesson 2: Say no often and politely.

From the beginning, we knew this platform had the potential for massive scale and could—over time—satisfy a myriad of use cases and user personas.

But we needed to focus. So the product team said no often (and politely).

In our beta version, users regularly asked to include certain features. But those features brought risks to the performance of the database. It also took our small team’s focus away from identifying the specific data points most helpful to our users.

And when we launched our customer-facing portal, we picked a single persona: the power user. While we would have loved to build exec-level dashboards for stakeholders and budget holders, we knew it would stretch us too thin. We would need to add more helper text, context, account and payment information, etc.

Lesson 3: Ask for help. And be generous.

As we already mentioned, measuring the distribution of a newswire is an age-old problem that many people have worked on. Before we built anything, we explored off-the-shelf technologies that we might be able to buy, but none fit our use case.

We set up a series of conversations through the News Product Alliance Slack, then took inspiration from some of the top minds in the business, like The Texas Tribune and ProPublica, to understand how they approached the problem. At no point did we try to hide what we were working on, and we saw the benefits of sharing our lessons—and fears—with others.

Lesson 4: Plan ahead.

While design and user experience provide the first impressions of a product, the technology “under the hood” is equally critical and can either help you be wildly successful or bring down your entire system. Our technology partners at Dentzau, LLC helped us think through the most cost-effective and efficient solutions.

A whole new series of challenges arose when we started planning the transition from beta to launch.

• We needed a hosting platform that we wouldn’t outgrow in six months.
• We needed to process over 55 million (and quickly growing) pixel hits.
• We wanted to add visualizations and charts.
• We intended to launch the customer-facing dashboard, which meant we needed to ensure we had a robust user authentication system, GDPR compliance, downtime alerts, and more.

Each of these items took time and money. Had we not planned and budgeted for each of them before we launched the project, we could have quickly gotten in over our heads.

Lesson 5: Don’t get too comfortable.

Looking back, we didn’t make a hard cutover from our beta product to our launch product. We kept both running while we replicated functionality in the launch product (and, of course, culled features we learned we didn’t need).

But that meant supporting two systems on two different architectures with two different development teams. It required teamwork when things went wrong (i.e., which system was responsible?) and extensive coordination when making critical updates. We also saw our internal users getting confused as to which system they should access for what.

So be confident in your success. If you’re ready to transition, go all-in and shut down legacy systems with the same vigor that you launch new systems.

What’s next?

As we look out over the next six months, we’re excited about our roadmap. Here are a few things we plan to implement:

• Leverage our analytics foundation to support nonprofit newsrooms. We recently launched a pro bono program to distribute and provide reporting on stories produced by nonprofit newsrooms. Our first cohort of newsrooms includes The Marshall Project, The 74 Million, and Grist, and we’re actively soliciting other partner newsrooms to join us. We are also exploring foundation funding to scale this program at a minimal cost to nonprofit newsrooms. Email publishers@stacker.com if you’re interested in learning more.
• Add additional data points. From additional SEO data to reach and impact data, we look forward to creating a holistic picture of the success of distributing stories on the Stacker Newswire.
• Reminders and notifications. We want users to know when something important is waiting for them, so we plan to build out an entire suite of notifications based on when reports are ready, when outliers in the data occur, when an archived story is newly gaining traction, etc.

As always, we'll continue listening to our customers and improving the product to ensure we're delivering them a best-in-class solution.