Shared Residential Proxy Usage: Allocate Projects Without Hiding the Unresolved Gap

Two authorized projects share one residential proxy account. The account meter rises, but neither the exit IP nor the number of successful jobs tells you how much usage belongs to each project. Build an internal allocation ledger with three explicit buckets: directly attributable activity, known shared activity, and unresolved usage.

This guide is for teams running their own website tests, advertising verification, or approved market research. It proposes an operational accounting workflow, not a measured 98IP result, invoice calculation, or promise of lower charges. Keep measured evidence separate from the policy used to distribute shared usage.

1. Decide what the ledger is intended to explain

Agree on the reporting period, timezone, account and product scope, units, project owners, and the decision the report supports. A usage ownership report and a financial chargeback report are different outputs. Start with ownership; any conversion into internal charges needs the organization's approved commercial rules.

Use the 98IP dynamic residential IP page to confirm the product context. Its FAQ describes account usage statistics by hour, day, and month in the user console. That does not establish that the account exposes a per-project billing meter, a particular export API, or every measurement boundary needed by your ledger. Verify actual available controls before designing around them.

2. Assign ownership before work enters the queue

Give each project a stable internal ID and each logical job a run ID. Carry both into queue messages, workers, browser contexts, and retry attempts. Record the resource reference, environment, attempt ID, outcome, timestamps, counter source, and counter units. Use masked resource references rather than passwords or generated extraction links.

Do not use the current exit IP as the project identifier: multiple jobs can share an exit, and one project can use multiple exits. Do not assign an entire pooled connection to the first project that used it. If a client cannot reliably separate traffic for concurrent jobs, mark that measurement limitation instead of inventing precision.

3. Keep three ownership buckets

• Direct: activity supported by a valid project-to-job mapping and an identified measurement source. An unsuccessful attempt can still belong to the project that initiated it.
• Shared: identified platform activity benefiting multiple projects, such as an approved common health probe or a shared maintenance task. Give it its own owner and service ID.
• Unresolved: missing labels, unexplained residuals, uncertain counter scope, or data not yet complete. Keep it visible with an investigation owner.

A missing project tag is not automatically shared overhead. Similarly, a known shared health check is not an unexplained incident. These buckets encode what you know, not a convenient way to make every number look allocated.

4. Compare counters only after their bases align

1. Take account-meter observations for a clearly defined window and record when the observations were retrieved. Confirm which timezone and reporting delay apply in the actual console.
2. Collect worker observations for the same window. Identify whether each counter measures request bytes, response bytes, decoded content, transfer bytes, or another boundary. Keep the source labels.
3. Check that the scope includes the intended products, workers, and attempts. Do not assume a client counter includes everything the provider measures, or that an account total excludes other services.
4. Use an equality or residual calculation only when the units, scope, time window, and measurement definitions are genuinely comparable. Otherwise show the two views side by side and label any allocation as an estimate.

If a comparable subtotal exceeds the account total, investigate duplicates, overlapping windows, unit conversion, or a mismatched counter boundary. Do not silently clamp a negative difference to zero. If reporting is incomplete, keep the window provisional until the established delay has passed.

The public API configuration documentation is the starting point for checking documented interface support. It is not evidence of a project-level usage export method. Do not invent an endpoint or scrape a privileged interface to fill a measurement gap.

5. Write the shared-allocation policy explicitly

For each known shared service, decide whether the platform team retains the usage centrally or whether projects receive an agreed share. If distributing it, record the eligible projects, weight source, effective dates, policy owner, and rounding treatment. The choice is an organizational allocation decision, not a newly discovered fact about network traffic.

For example, consider a completely synthetic ledger on one already harmonized internal unit basis: project A has 400 direct units, project B has 300, a known shared service has 200, and 100 remain unresolved, totaling 1,000. If an approved fixed policy allocates the shared service 40% to A and 60% to B, the internal report becomes A 480, B 420, and unresolved 100. The weights are an assumed policy, not inferred from these direct counts. These are illustrative internal units, not 98IP prices or measured billable traffic.

Do not apply this arithmetic when the measurement bases differ. Do not distribute the unresolved 100 merely to force full allocation. If the organization approves a provisional estimate, retain both the original unresolved evidence and the separately labeled policy adjustment.

6. Preserve attribution through retries and shared workers

Each retry should retain the original project's ID while receiving its own attempt ID. Attribute observed retry activity without counting the same attempt twice through both a scheduler log and a worker log. Decide which source is authoritative for each metric; other logs provide correlation, not another additive meter.

When one browser or worker serves several projects, ensure ownership context changes with the job and does not leak through an asynchronous callback. A heartbeat with no project workload belongs to the identified shared service if that is its documented purpose. A record that has lost its context belongs in unresolved until investigated, not in the most recent project's bucket.

7. Review gaps before approving the period

Check late-arriving records, restarted workers, duplicate attempt IDs, stale labels from cloned deployments, and activity outside the chosen window. Keep unknown deltas separate from claims of misuse. A larger project is not automatically responsible for the residual, and a growing shared account total alone does not identify a culprit.

Ask each project owner to confirm the mapping and each shared-service owner to confirm the policy version. Publish measured direct evidence, allocated shared portions, unresolved or estimated portions, and limitations as separate columns. A report can be useful with an open gap; it should not claim exact per-project provider billing without the necessary evidence.

FAQ and a rehearsal checklist

Can I divide the total by successful request count? That may be an approved allocation proxy, but it is not measured per-project traffic. Different jobs, failures, and retries can have different usage profiles. Label the rule and its limits.

Does issuing separate credentials guarantee separate billing counters? No. Confirm whether the actual product and account provide those counters. An internal resource reference helps attribution but does not create a provider meter.

• Project, job, attempt, resource, and shared-service identities are recorded without secrets.
• Direct, known shared, and unresolved records remain distinguishable.
• Counter definitions, units, timezone, scope, and reporting completeness are documented.
• Every distributed shared portion names its policy, weights, effective period, and owner.
• Residuals and estimates remain visible after allocation.

Rehearse locally with two synthetic projects: remove one project tag and require an unresolved record; duplicate one attempt ID and confirm it is not added twice; insert a late record and verify the period remains provisional or receives a traceable revision. These are proposed tests, not executed results. Restrict reports to authorized recipients, minimize retained data, and never include proxy secrets or customer content merely to prove ownership.