DEV Community: corpdigest

Revenue Is the Wrong Success Metric for a Distribution Business

corpdigest — Mon, 17 Aug 2026 18:37:05 +0000

If you rank companies by revenue, McKesson shows up near the very top — north of $300B a year, bigger than most household-name tech giants. If you rank them by net margin, it nearly disappears: the margin is well under 1%. Both numbers are correct, and storing only one of them in your company-data schema will mislead every downstream comparison you build.

The issue is that revenue means completely different things depending on the business model behind it. For a software company, revenue is close to value captured. For a pure distributor like McKesson — which moves pharmaceuticals from manufacturers to pharmacies — revenue is mostly pass-through: the cost of the drugs flows straight through the income statement. The company's actual economics live in the thin spread it keeps, not the enormous number at the top of the P&L.

So a revenue column, used as a proxy for "size" or "success" across a mixed dataset, systematically overweights distributors, wholesalers, and retailers against asset-light businesses that capture far more per dollar of revenue. A "largest companies" ranking sorted on revenue alone will tell you McKesson is more significant than companies with a tenth of its revenue and ten times its profit.

The schema fix is to stop treating revenue as a scalar success metric and store the fields that let you compute the one that matters for the question you're asking: gross_profit, net_income, and ideally revenue_model (pass-through vs. value-capture) as an explicit category. Then "rank by size" becomes an intentional choice — revenue, gross profit dollars, or margin — rather than an accident of which column was handy.

I dug into this while writing up how McKesson actually makes money — the thin-margin-at-massive-scale model is the clearest example I've found of why a single revenue figure lies.

How do you handle this in your own schemas — a revenue_model enum, a computed margin column, or something else?

ARPU Is the Wrong Shape for a Multi-Surface Ad Business

corpdigest — Sun, 16 Aug 2026 02:22:23 +0000

A lot of company-data schemas have an arpu field: total revenue divided by monthly active users, stored as one number per company per period. It's a fine number to report. It's a bad number to model a business on, and Meta is the clearest example of why.

Meta's advertising business doesn't monetize "a user." It monetizes a user on a surface, at a data density, in a geography. A single global ARPU figure averages away exactly the three variables that explain the revenue. North American ARPU runs several multiples higher than Asia-Pacific ARPU on the same platform, not because the ads are different, but because advertiser willingness-to-pay per impression tracks disposable income and ad-market maturity, not usage. Collapse that into one column and you've thrown away the variable that actually explains the business model.

The practical schema fix is unglamorous: stop treating ARPU as a stored fact and start treating it as a derived view over (revenue, users, dimension) tuples, where dimension is at minimum geography and ideally product surface (feed ads vs. Reels vs. click-to-WhatsApp). If your table can't answer "ARPU for what surface, in what region" it can't actually explain how the money is made, only how much of it there was.

I ended up writing this up after digging into how Meta's business model actually breaks down by segment for a data project, worth a look if you want a concrete example of what the disaggregated numbers look like in practice.

Curious how others have modeled this. Do you store per-surface ARPU as a materialized column, or compute it at query time from raw revenue/user facts?

Your acquisitions table needs a status field, not a boolean

corpdigest — Fri, 14 Aug 2026 18:57:46 +0000

Most schemas model corporate acquisitions as a join table: acquirer_id, target_id, price, closed_date. Some add is_completed BOOLEAN.

That boolean is where the model starts lying to you.

Four states a boolean cannot hold

An acquisition is not binary. Working through several hundred company profiles, the deals refuse to sit in two buckets:

Announced but not closed. In July 2026 Uber announced a voluntary takeover offer for Delivery Hero, around $14.8 billion, with closing expected in the second half of 2027 subject to conditions and regulatory approval. If your pipeline writes that row with is_completed = false, it will be indistinguishable from a deal that collapsed. If it writes true, you have just booked $14.8B of M&A that has not happened.

Closed, then unwound. Uber bought Drizly in 2021 for about $1.1 billion, ran it as a standalone service, and shut it down in 2024, folding alcohol ordering into Uber Eats. The acquisition completed. The entity no longer exists. Both facts are true and a boolean holds neither well.

Closed, then divested. McDonald's took a stake in Chipotle in 1998 and had fully divested by 2006. Financially it was one of the best investments in restaurant history. Strategically it was abandoned. "Completed" is accurate and useless.

Closed with partial disposal. The Uber–Delivery Hero offer earmarks 14 overlapping markets for separate sale to SSW Partners. The deal, if it closes, is simultaneously an acquisition and a divestiture.

A state field that survives contact

CREATE TYPE acquisition_status AS ENUM (
  'announced',      -- disclosed, not closed
  'terminated',     -- announced, then abandoned
  'completed',      -- closed, target operating
  'absorbed',       -- closed, brand retired into acquirer
  'shuttered',      -- closed, operations discontinued
  'divested'        -- closed, later sold on
);

Two things this buys you immediately:

announced rows can be excluded from any "total M&A spend" aggregate with a single predicate, instead of relying on every downstream consumer to remember.
shuttered and divested become queryable. "Which acquirers shut down what they bought?" is a genuinely interesting question and a boolean makes it unanswerable.

Add status_as_of DATE alongside it. Status is a point-in-time claim, not a permanent property, and without a date you cannot tell a stale row from a current one.

The counting trap

The related mistake: treating a row count as a fact about the world.

If a profile documents five acquisitions, that means five acquisitions are documented. It does not mean the company made five. Undisclosed deals, asset purchases and acqui-hires routinely never surface. Name the column acquisitions_documented rather than acquisition_count and the ambiguity disappears at the point of use, which is where it matters.

Worked example

If you want a deal-by-deal record with stated purpose and actual outcome for each — including the pending Delivery Hero offer explicitly flagged as pending rather than counted — the Uber acquisition history is laid out that way.

The general principle is boring and keeps paying: model the states your data actually occupies, not the two states that were convenient when the table was created.

Your companies table is lying to you about when things happened

corpdigest — Sat, 08 Aug 2026 19:02:36 +0000

Every company dataset I have worked with stores history as scalar columns:

founded_year   INT
ceo_name       TEXT
headquarters   TEXT
revenue        BIGINT

Every one of those is a point-in-time fact pretending to be a permanent one. The moment you need to answer "who was in charge when this happened", the schema has already thrown the answer away.

The failure is invisible until you query across time

Take Intel. Founded 18 July 1968 by Gordon Moore and Robert Noyce in Mountain View. If your row says founded_year = 1968 and ceo_name = <whoever it is today>, you have compressed nearly six decades into two fields that were never simultaneously true.

Now try to answer:

Who was running the company when the 4004 shipped in 1971?
What was the headquarters when the IBM PC design win landed in 1981?
Which leadership team owned the process-node slippage that Apple Silicon exposed in 2020?

None of these are answerable. Not because the data is missing, but because the schema has no time axis.

The fix is an event table, not more nullable columns

create table company_event (
  company_id    bigint not null,
  event_type    text   not null,  -- 'ceo_start' | 'hq_move' | 'rename' | 'launch'
  valid_from    date   not null,
  valid_to      date,             -- null means still current
  payload       jsonb  not null,
  source_url    text   not null,
  primary key (company_id, event_type, valid_from)
);

Three things this buys you.

valid_to IS NULL means current. Your "current CEO" lookup becomes a view rather than a column somebody has to remember to update. Staleness stops being a silent failure and becomes a missing row you can detect.

source_url sits on the row, not the parent. When a specific figure gets challenged you can point at the specific filing that supports that specific claim. A single source column on the company row cannot do that.

Corrections stop being destructive. Updating a scalar ceo_name destroys the previous value. Inserting an event with a new valid_from preserves it, which means you can reconstruct what you believed and when.

The part that actually bit me

The schema is the easy half. The hard half is that most sources do not give you a clean valid_from. Press releases say "effective immediately". Filings say "during fiscal 2024". Wikipedia says "1968". So you need to store how precise the date is:

valid_from            date
valid_from_precision  text  -- 'day' | 'month' | 'quarter' | 'year'

Without that column you will silently invent a day-level date no source supports, and something downstream will treat it as exact. I have done this. It is very annoying to unpick later.

Worked example

If you want to see the shape rendered as narrative rather than rows, the Intel company history page is built this way -- founding, the 4004, the IBM PC standardisation and the Apple Silicon transition as discrete dated events with sources attached, rather than one prose blob with a founded_year bolted on.

The rule I have settled on: if a fact about a company can change, it is an event with a start date and a source. It is not a column.

Banks Break Your Company-Data Schema, and the Fix Is Not Another Nullable Column

corpdigest — Thu, 06 Aug 2026 17:41:28 +0000

If you have ever modelled companies in a database, you have probably started with a schema that looks something like this:

company
  id
  name
  founded_year
  headquarters
  employee_count
  products[]
  revenue_streams[]
  competitors[]

It works fine for a manufacturer or a SaaS vendor. You can reason from products to revenue, and revenue_streams maps onto things a customer actually buys.

Then you add a bank, and the model quietly stops describing reality.

The problem

For a product company, the business model is downstream of what it sells. For a bank, the business model is the balance sheet. The question "what does this company sell?" has no clean answer. What matters instead is:

which activities consume regulatory capital
which income is fee-based and recurring versus market-dependent and volatile
how the divisions are structured, because divisions are the real unit of analysis
where the funding comes from, because funding mix drives the entire risk profile

None of those fit in a products[] array. If you force them in, you end up with rows like {name: "Investment Banking", type: "product"}, which is a category error your queries will inherit forever.

Why a nullable column does not fix it

The tempting patch is to add is_financial_institution and a few nullable fields. That gets you through the migration and creates two failure modes:

Aggregations lie. Any AVG(revenue_per_product) style query silently includes companies where the denominator is meaningless.
The nulls spread. Insurers, REITs, asset managers and exchanges each need a slightly different set, so you keep adding columns that are null for 95% of rows.

The honest modelling answer is that "business model" is not one shape. It is a discriminated union, and financial institutions are a distinct variant with their own required fields. Whether you implement that as separate tables, a JSONB payload with a schema tag, or single-table inheritance matters less than admitting the variant exists.

A concrete example

Deutsche Bank is a useful test case because its structure is legible and its history explains it. It was founded in Frankfurt in 1870 by Adelbert Delbrück and Wilhelm von Philipsborn for a specific reason: German merchants depended on British banks to finance international trade, and the new institution existed to do that financing domestically.

That origin still shows up in the divisional structure 155 years later. The bank has always leaned corporate and cross-border rather than domestic-retail-deposit, which is why the 1989 acquisition of Morgan Grenfell and the later global-markets build-out read as continuations of the founding logic rather than departures from it. Roughly 90,000 employees, and a restructuring under Christian Sewing that was fundamentally a question of which businesses to keep rather than which products to ship.

If you want to see what fields a bank profile actually needs, the Deutsche Bank business model page is a reasonable reference for the shape of the data: divisional structure and revenue logic rather than a product list.

What I would do differently next time

Start with the variant. Write down two or three company archetypes before you write the first migration:

Product company — products, unit economics, revenue streams
Financial institution — divisions, capital consumption, funding mix, fee vs market income
Marketplace / platform — two-sided supply and demand, take rate, liquidity

You will discover more archetypes later. But starting with one and bolting on the rest is how you end up with a companies table that has 140 columns and no one willing to touch it.

If you have modelled this differently, I would like to hear it, particularly how you handled conglomerates that span more than one archetype.

foundedYear Is the Wrong Field for Company Data

corpdigest — Wed, 05 Aug 2026 18:48:46 +0000

Almost every company dataset stores founding as a single integer. It is the first field you add and the first one that turns out to be a lie.

Take Visa Inc. What year was it founded?

1958, when Bank of America launched the BankAmericard programme
The early 1970s, when the programme was reorganised into a member-owned network under Dee Hock
1976, when it took the Visa name
2007-2008, when Visa Inc. was incorporated as a stock corporation and went public

All four are defensible. Your integer field forces you to pick one and silently discard the other three. Worse, whichever you pick becomes unfalsifiable downstream, because the reasoning is not stored anywhere.

Model entity events, not a founding year

Keep the integer for display, but make it derived rather than authoritative. Store the events:

{
  "slug": "visa",
  "displayFoundedYear": 1958,
  "entityEvents": [
    { "year": 1958, "type": "program_launch", "note": "BankAmericard" },
    { "year": 1976, "type": "rename", "note": "Visa" },
    { "year": 2008, "type": "ipo" }
  ]
}

Three things get easier immediately. Conflicting sources stop being bugs and become different event types. "Companies founded before 1970" becomes a question you can answer precisely instead of approximately. And when someone challenges a date, you can show them why you chose it.

The rendered version of that record, for reference: Visa company data

Banks, insurers and anything that has been through a demutualisation will break the same way. If your schema has a single founding integer, pick your oldest company and try to defend the number. That exercise is the whole argument.

Modelling Corporate Acquisition History as a Graph, Not a List

corpdigest — Wed, 05 Aug 2026 17:59:41 +0000

Most acquisition data on the web is stored as a flat list: acquirer, target, date, price. That shape is easy to render in a table and nearly useless for analysis, because it throws away the thing you actually want - structure.

Acquisitions are a graph. Nodes are entities, edges are transactions with a direction and a timestamp. Once you model it that way, a set of queries opens up that a flat table cannot answer:

Chains. Company A buys B; B had previously bought C. The IP you care about moved twice. A flat list shows two unrelated rows.
Divestments. An entity leaves the graph and re-enters elsewhere. Spin-offs are edges too, and omitting them makes portfolios look monotonically expanding.
Clustering by category. Group edges by target category and the acquirer's strategy becomes visible as a shape rather than a narrative.

Pharmaceutical companies are the clearest test case for this, because their acquisition activity is pipeline acquisition. Buying a company is often buying one molecule at a specific trial phase. Novartis AG is a useful example - the company was itself formed in 1996 by the merger of Ciba-Geigy and Sandoz, so its own root node is a merger, and its subsequent activity includes both acquisitions and significant divestments as it moved away from generics.

A schema that survives contact with real data:

{
  "acquirer": "novartis",
  "target": "example-bio",
  "announced": "2024-03-11",
  "closed": "2024-07-02",
  "type": "acquisition",
  "category": "oncology",
  "disclosed_value_usd": null,
  "source_url": "https://..."
}

Two design notes.

Keep announced and closed separate. Deals fall through, and collapsing the two dates silently rewrites history.

Make disclosed_value_usd explicitly nullable rather than defaulting to zero. "Undisclosed" and "zero" are very different facts, and 0 will quietly poison every aggregate you compute.

For a worked example of the raw material, the Novartis acquisition history is laid out chronologically, which is a reasonable input format before you normalise it into edges.

Once the graph exists, the interesting queries are the ones about time: how long between a therapeutic area's first acquisition and its second, and does that interval shorten when a strategy is working?