Two phones, same settings, same blast copy, same list - different results. One account runs six months; the second dies on day three. This breaks operators hardest: nothing obvious to fix when everything looked identical. This article explains why it happens and what to do about it.
"Same settings = same survival" doesn't hold. Meta's scoring weighs many factors - most invisible and not directly controllable by the operator.
That doesn't mean the system is random. It's opaque and multi-factor. Identical inputs don't guarantee identical outputs because "identical" inputs are never truly identical in practice.
In official WhatsApp Business API (WABA), number quality builds on user reactions over the last 7 days. Main signals: reports, blocks, negative feedback. Fresher events weigh more.
Quality Rating statuses: 🟢 High / 🟡 Medium / 🔴 Low. Reputation is per number - even two numbers in one WABA account are scored independently.
Meta doesn't publish exact formulas or trigger thresholds. Operators have observations, forums, pool practice. Keep that in mind with any specific numbers.
Likely the heaviest and most controllable factor. Even a formally random 50/50 split can leave one half with 5–10% more inactive numbers, users who haven't opened WhatsApp in ages, or chronic reporters.
Since number quality depends on audience reaction, different list makeup → different outcomes - same copy and volume.
Risk reducer: save recipients to the phone address book before sending. WhatsApp checks whether the recipient is in the sender's contacts - one legitimacy signal.
When splitting a list across accounts, segment by meaning, not row order - random splits still skew.
First few reports hit a new account harder than later ones. If random split sent early messages to complaint-prone users - that account degrades first. The second account may finish most of the run on a more loyal slice.
Not "algorithm luck" - statistics: the same message reached different people.
Two devices on one network get different internal addresses and may exit via different external IPs. Traffic from different proxy ports carries different history - especially if someone else spammed through that port before you.
Operator practice: don't run more than three sending devices on one connection; don't run two parallel blasts from one device. Each account - isolated environment, ideally separate connection. See proxy mistakes.
Send delay benchmark: 30 seconds to 5 minutes with randomization. Identical fixed delays without jitter read as automation.
Each device carries a unique hardware fingerprint - component serials, MAC addresses, module IDs. A phone used in automation schemes or after prior bans starts from a different position than a "clean" device.
Operators observe device history affects account resilience. How long and precisely Meta stores it - not officially confirmed.
Those running dozens or hundreds of accounts: some bans are statistically inevitable on any scheme. Debugging every single ban often leads nowhere - the exact factor combo isn't reproducible.
Right approach - score the pool, not one number. If pool averages are fine and one account burned - not always a broken scheme. Several in a row - systemic signal to audit.
Two Xiaomi phones, same shelf, different mobile proxy ports, one spintax copy, randomized list. Account #1 ran 45 days, 4,500 messages. Account #2 died day three on message 120.
Log audit: account #2's proxy port was heavily used by a third party for Instagram spam an hour before launch - IP on stop lists. Port #1 had no such history.
Operator observation, not a verified experiment. But it shows: infrastructure that looks the same to you isn't always the same to the system.
When one account outlives another, isolate variables before conclusions:
| Factor | What to check |
|---|---|
| List | Same segment? Same audience activity? |
| Device | Usage history, hardware "cleanliness" |
| Network | Shared IP, proxy port history |
| Template | Did different audiences get different copy variants? |
| Number | Account history, age, prior restrictions |
Without isolation - ban cause is guesswork.
"If one survived, the second will too" Number history and audience reaction can differ even with a fully matching external setup.
"There's always one ban cause you can find" Usually a factor combination - the exact mix doesn't reproduce.
"Same scheme = safe limit" Meta publishes no guaranteed limits. Any "safe" benchmark is operator practice, not an official system parameter.
If one pool account burned early - check proxy port history for the 24 hours before launch and compare list composition: inactive number share, last contact date. Two of the most controllable variables behind divergence.
Practical rule:
Meta's scoring isn't roulette - but it's not multiplication tables either. Identical inputs don't yield identical answers because truly identical inputs don't exist in the real world.
