Bandwidth pooling: one balance or several separate purchases

Bandwidth pooling says where purchased traffic can be spent. An account-wide pool can serve several eligible users or proxy types from one balance. A per-plan or per-subuser allowance cannot. That difference decides whether a buyer can make one larger purchase or must maintain several smaller balances, each with its own minimum and risk of unused traffic. Dataset snapshot, all evidence retrieved 2026-07-25

The plan where one balance prevents double counting

soax-residential-builder-unified-credits is a monthly plan with a $200 checkout, 200 included credits, and a published Tier 1 rate of $3 per GB. The dataset records pooling: account_wide, pool_scope: cross_type, and coverage for residential and mobile traffic. SOAX describes it as one rate across those two types. SOAX pricing, retrieved 2026-07-25T15:31:32Z

That means the $200 balance is one purchase, not one residential plan plus a second mobile plan. Counting the row once is not merely a database detail. It stops a comparison from inventing two $200 checkout obligations when the vendor sells one shared balance. SOAX pricing, retrieved 2026-07-25T15:31:32Z

Pooling does not make traffic free, and it does not remove the plan’s other limits. It changes the boundary around the meter. If one team uses most of the credits on residential traffic and another uses the remainder on mobile traffic, an account-wide cross-type pool can absorb that mix. With per-plan balances, the same total demand could strand traffic in one balance while the other runs out. SOAX pricing, retrieved 2026-07-25T15:31:32Z

Most rows do not publish a usable pooling rule

The current dataset has no usable published pooling state on 556 of 710 plan rows. Of those, 449 are correctly encoded as null, meaning “Not published.” Another 107 carry the legacy value unknown, which is not a permissive state and cannot be treated as account-wide pooling. Only an explicit value such as account_wide, per_subuser, per_plan, or none can support a pooling claim. Dataset snapshot, all evidence retrieved 2026-07-25

That missing information matters most when the advertised rate assumes a large purchase. A buyer should ask four questions before using that rate: Can the balance cross proxy types? Can subusers share it? Can separate projects draw from it? Does a renewal or expiry rule apply to the whole pool or to each allocation? A pricing page that answers only “pooling included” has not yet said where the meter sits. Dataset methodology and plan evidence, retrieved 2026-07-25

For comparisons, keep one pooled plan as one checkout obligation. Keep separate balances separate. If the provider does not publish the boundary, show “Not published” and do not model the plan as though every user and product can draw from the same traffic. Dataset snapshot, all evidence retrieved 2026-07-25