Counting people, not rows

The problem

The new campaign needed sizing. The obvious source was a stored copy of the LinkedIn platform's data in the client's database. It looked authoritative. The job that fills it was scheduled, and the tables were real.

What we built

We didn't trust the copy until we'd checked it. We read the platform API live, campaign by campaign, across every campaign in scope. Then we folded the rows down to distinct people before counting anything.

What it produced

• About 4,000 campaign rows became about 2,200 distinct people. Roughly 1,500 people sat in more than one campaign. Sizing on rows would have inflated every figure by about 78 percent.
• The stored copy had every row stamped inside one 26 second window, and nothing after it. It hadn't written a row in 17 days, and it was missing 6 campaigns.
• The event hook was routing connection events to a handler that logged a line and wrote nothing.
• A documented platform limit turned out to be wrong. The endpoint was said to return only pending leads. It returned every status.

Then the binding constraint. The email step needs a company domain to find an address. On one path, under 1 percent of the surviving contacts had one. On the other path, about 8 percent did. That's the real size of the campaign, and it's a lot smaller than the row count said.

What runs now

Sizing reads the live API and counts distinct people. The stored copy is treated as unverified until it's shown to be current.

Your scenario

Before you size a campaign off a synced table, check when it last wrote a row. Send us the count you're planning around and we'll tell you how we'd check it.

Related tools: HeyReach, Instantly, Multichannel Enrollment Rules

Some of the links on this page are affiliate links.

Client names are always kept confidential at MMG, so they have been removed from this case study.

Published July 14, 2026

Last updated August 12, 2026