Filtering query parameters / post processing

[drphrozen]

Is your feature request related to a problem? Please describe.
Filtering query params to ensure compliancy across multiple solutions.
We have multiple teams implementing the same tracker across multiple subdomains and would like to have some guardrails in place for all of these.

Describe the solution you'd like
We want to be able to process URLs from a central position (when events/context are being added, fx).
This could be scoped to allow post processing of any events or contexts.

Describe alternatives you've considered

• plugin with afterTrack implementation, mutating the Payload
• customFetch - mutating the Request with regexes
• implementing a custom PayloadBuilder - thanks to this we could manipulate the payload directly when it’s build - this is an optimal solution because we wouldn’t have to traverse the payload object twice - once when creating it and once when we want to filter and update query params in our events
• implementing custom Emitter - similar to option one, but tied directly to a tracker implementation and configuration

Additional context
The solution should also be aware of the context (fx. which namespace is this running for?)

[drphrozen]

This would not directly help the url added in trackPageView since its being exposed in the url base field. But maybe post processing could happen both for event, context and "payload".

[miike]

I'm not 100% clear on what the functionality here would be.

Is it to modify (remove, modify, transform?) just the url component of the payload or all fields? Generally we would steer the governance layer to be in the dataLayer (or something similar) which then makes it easier to perform things like automated tests and scans rather than the logic being within the tracker itself.