Since ours is a centrally-managed system shared in common among all merchants who use us, it's not generally possible to alter how our system works for any one merchant without also applying the same alteration system-wide to everyone, unless there's a setting to manage that as a custom preference in Seller Admin.
Tracking cookies do not work the way you seem to think they do. A cookie is not software nor any sort of script that can do anything by itself, and they certainly cannot be used to monitor the URLs a user visits which are entirely unrelated to the site which originally set the cookie.
A cookie is just a plain text file that stores a name=value pair in the user's browser for a set period of time. A cookie must be set by and for a specific domain name and can only be read by pages on the same domain. The way Internet tracking basically works, a script in a page sets a cookie in the user's browser, and other pages on the same site may have a script that can look for that cookie in the user's browser, as the user moves from page to page on that site.
It's a bit unfortunate the inventor chose the term "cookie" for this, when he might have picked a term from a more familiar and suitable analogy. Setting and tracking a cookie is really rather like getting a ticket stub at some event, where your stub and the other half of the ticket each have a set of matching numbers. While attending that event, you might be asked show your stub on demand to claim a doorprize or complimentary drink, or to otherwise prove you're the same person who gained admittance at the door.
Extending the metaphor, now imagine that you are asked for the stub every time you enter a new room at the venue, and the doorman in each room logs which ticket numbers entered which rooms when; in that way, the hosts could anonymously track the movement of each specific ticket number through their venue and figure out generally where people generally went, and when, and in what sequence, even without knowing exactly who has each number. However, if you provided some personal information to the event hosts by writing it on their half of the ticket (e.g., to enter a doorprize drawing), the stub you keep and show to the doormen only has the ticket number, which cannot be tracked back to you personally without matching its number to the host's half of the ticket which has the personal info you wrote on it.
The tracking script (doorman) on each page (room) just requests the tracking cookie ID (ticket stub number) from the user, or sets a cookie (issues a stub) if they don't have one, and tells the tracking service such as Google Analytics (the event organizers) to log that ID as having visited that page URL (room). Tracking just "follows the bouncing cookie" as the buyer goes from page to page on that site.
This gets a bit more complicated when the site's pages embed third-party advertising and tracking scripts in their pages. E.g., suppose you're visiting Site A, and the pages on that site are displaying advertising served from Site B. Those ads from Site B may have scripts that can set and read their their own cookies for Site B's domain, but the pages on Site A cannot read those cookies. However, if another Site C also displays advertising served from Site B, the scripts in those ads can read the cookies that Site B had set on Site A, allowing Site B to know that the same user viewed their ads on both Site A and Site C. While you're viewing Site A or Site C, the cookies that Site B sets or reads would be considered "third-party" cookies (since they're not set by you personally nor the site you're on); most browsers now have a setting to block these, and these would also be the type of cookies that your anti-malware software finds and offers to delete for you.