The Other Bird App Is In Trouble
Data Talks

The Other Bird App Is In Trouble

Philippe Boutros
Philippe Boutros

Last week, the micro-mobility startup Bird—previously best known for its black-and-gray e-scooters—informed the Securities and Exchange Commission that it had been misstating its revenue for more than two years.

This is not the type of message you want to tell the SEC. The market reacted accordingly, erasing >50% of Bird’s market cap*.

Bird had a <$60M market cap at the time of publication.
Bird had a <$60M market cap at the time of publication.

What happened? Accurate reporting of an inaccurate metric.

The determination results from an error (...) related to its business system configuration that impacted the recognition of revenue on certain trips completed by customers of its Sharing business (“Rides”) for which collectability was not probable.
Specifically, for certain customers with insufficient preloaded “wallet” balances, the Company’s business systems recorded revenue for uncollected balances following the completion of certain Rides that should not have been recorded. The Company believes the error resulted in an overstatement of Sharing revenue (...).

Bird should have solely been reporting collected revenue. Instead, they included rides and portions of rides invoiced to delinquent customers in their revenue calculations. While this only impacted a fraction of their topline—small mistakes compound into big problems.

Management has concluded that the Company’s disclosure controls and procedures are not effective at a reasonable assurance level, due to a material weakness in its internal control over financial reporting related to the ineffective design of controls around its business systems that resulted in the recording of revenue for uncollected balances following the completion of certain Rides that should not have been recorded. The Company is in the process of designing and implementing controls to remediate these deficiencies.

Underneath the veil of legalease, this is a pretty straightforward statement—and it paints an uncertain landscape. “We don’t know how bad things are,” and “we don’t know how much time we need to fix this”. While we may never learn the details that led to this incident, the misreporting likely stems from metric definitions built on data pipelines authored with engineering systems in mind—not financial reporting needs.

Bird has indefinitely delayed reporting their most recent financial results until they can be confident in their data discipline. Certainly a challenging, painful situation.

How to make sure this doesn’t happen to you.

As former data analysts for companies like Airbnb, Doordash, and Snowflake, we know firsthand how data teams end up in this nightmare scenario—and how to avoid it.

As organizations grow, they accumulate giant spiderwebs of data pipelines, built on duplicated, disconnected business logic. Some data teams will kick the can down the road as long as possible. That data strategy will earn you a headline.

Top-performing data teams will choose to deal with this sprawl proactively, taking one of two paths:

(Option 1) Be a Data Sheriff: Regularly enforce data discipline in your corporate culture.

This is the more difficult path. As long as you, your team, and your successors commit to it, it can work.

What does being a Data Sheriff mean?

  • You must audit all your existing reporting systems—from Tableau to Excel—to expunge inaccurate definitions. Stay on top of reporting sprawl.
  • You must investigate every data definition, adopting a Socratic approach. Ask and understand why metrics are defined as they are.
  • You must intimately understand how different business groups (incl. Finance, Marketing, Growth, Sales, Partnerships, etc.), define, use, and interpret different metrics.
  • In addition to all that, you must maintain some version of a data dictionary or library (e.g., Alation, Confluence, repurposing Jira, etc.), making sure that business users remember how to find and access it, as well as documenting your data lineage.

There are some best practices you can adopt at the onset—such as Hosting a KPI Development Day—although ultimately, your best bet will be proactively, constantly engaging with how your business is using data.

(Option 2) Adopt a Metric Layer: Hardcode data-discipline into your reporting.

This is the easier path. It’s the path we took at Airbnb, and the foundation on which we’ve built our business intelligence product, the Transform App. While it requires some of the same upfront work as the other path, adopting a metric layer leads to a far more nimble data team.

What does successful adoption of a metric layer look like?

  • You control the data definitions, regardless of where your users access it. Whether it’s in advanced visualization systems like Tableau, data-science adjacent tools like Hex, or business-user friendly systems like Google Sheets, adopting a metric layer ensures that your users are accessing the right data.
  • You are able to monitor who, where, and how data is accessed, providing data governance capabilities from the perspective of an analyst, not just compliance.
  • The upfront time invested is minimal—ideally using capabilities like a SQL inference tool—and it pays dividends. Your team will have fewer ad hoc reporting asks from the rest of the business, and more time to focus on high-impact work.

There are several metric layer solutions out there. While they don’t all provide the same capabilities, they’re all trying to solve the same problem. We’re biased, but we think that MetricFlow is the best option for scaling businesses, because the Transform App lets data teams demonstrate ‘quick wins’ from that time investment in the short term, while benefiting from the long-term investment of a metric layer.

Are you part of a data team? Want to be a Data hero for your organization? Click here to schedule a demo with one of our Data Evangelists today.

* The stock market has a long history of negatively reacting to metric problems (e.g., having to restate earnings due to incorrect metrics). See here for more: