Assume that you found a website affected by persistent XSS (stored) that you want to exploit. How do you control which target can be affected by this vulnerability? I don't want all who enter the page affected by the payload.
An XSS vulnerability that lets you run arbitrary JS lets you do anything you can do with JS. So designing your payload is simply a programming issue.
If you want to limit on IP, just check the users IP. If you want to limit on logged in username or id, just grab that from wherever it is stored and compare to your targets. Usernames are usually displayed somewhere on the page, and if it's not just fetch a page where it is displayed and read it from there. Especially for a SPA the username is probably stored in a JS variable so you don't even have to grab it from the DOM.
It might require some searching to find where to retrieve the info from in your specific case - there is no universal solution - but it should be doable with a little bit of JS.
I don't want all who enter the page affected by my payload
This comes down to an authorization case. Let's assume that the page in which the vulnerable parameter (now exploited) resides in an area which is open to the public. Indeed, everyone visiting that page will now be affected by your payload.
If you're trying to target specific users, one would could (please see the comment below) exploit a previous vulnerability such as stealing the targeted users session ID and authenticating it against an already-known session ID in order to craft your payload to target this specific user. Now, in order to make this happen, you need to assume that you have already captured the targeted users session ID, and that the session ID has not yet expired. (Which is the 'previous' vulnerability mentioned).
There may be other ways to identify the users in which you can target, though that strictly depends upon the application in which you are pentesting and how they authenticate with the server. Again, you will generally need to capture this information via a MitM styled attack.
TL;DR: It all comes down to the web app that you're pentesting and how it identifies its users. In your case, this is highly subjective. Unless we know exactly what that information is, that's really all that we can provide.