BugDigger service has a simple and dynamic approach to user management: There's no manual user administration!
Your subscription for BugDigger service automatically covers all users that:
Report bugs on web sites associated with your projects on BugDigger.
Submit bug reports to projects on an external issue tracker attached to your subscription. (We also call this "sponsored issue tracker".) As BugDigger communicates with external services using credentials (or an authorization token) provided by user, it operates under permissions that the user has on the issue tracker. That means any user of the sponsored issue tracker is automatically enabled to use BugDigger. (Note that BugDigger doesn't care how many users you have on the sponsored issue tracker but how many of them use BugDigger within a month.)
In short, BugDigger counts users that submit a bug report to any of your projects within a month.
Let's say you have a paid BugDigger account with:
A Project ABC created on BugDigger and associated with host name test.example.com. (By the project settings you may have bug routed to a project on an external issue tracker but it doesn't change user counting.)
A Basecamp instance associated with your BugDigger subscription (as your sponsored issue tracker), where on Basecamp you have projects: Basecamp Project X, Basecamp Project Y, etc.
First, imagine a user (signed-in or a Guest) reporting a bug found on test.example.com. The bug report is automatically assigned to the Project ABC and further dispatched in accordance with the project settings. As the web site test.example.com is associated with your project, the user reporting the issue is automatically "approved" and counts against your subscription limit.
Now, let's consider your co-worker Joel who is signed-in to BugDigger via Basecamp. Joel visits somethingelse.com, notices a problem and uses BugDigger to submit a bug report to Basecamp Project X. As the project belongs to the sponsored issue tracker, the bug report was also covered by your subscription.