Why I'm getting more unspecified when I place UV against tracking code

Honestly, Visitors and "visitor overlap" is one of the hardest things to wrap your head around (hence I tried to add as many visuals and examples as possible). I often find myself helping to explain that within my own company...

Now that said, depending on how complex you want to go, you could probably create some non-overlapping segments for Users with Tracking Code vs User without Tracking Code... (for users that have encountered both in the reporting period, you could defer them to the "with" bucket, by using some extra exclusion logic).

You could display as three columns (with, without, and total):

Visitors WITH Tracking Code:

Visitors WITHOUT Tracking Code:

(Notice the inclusion of an exclude container, also at Visitor level, excluding visitors that have tracking code.)

You can pair both segments with the UV metric, and if you pull UVs as it's own column, the two segments added together should match the total users (no overlapping) - this will at least help people read and interpret the report easier 🙂

For other cases, try to think like how a user might interact with your site... each visit will be slightly different, a different way to enter the site, interacting with different touch points. So when you segment by users you have to remember that only one touch point for the user needs to match for the segment to be true for the user, but all the visits that user has won't necessarily....

Even when you are dealing with Users... sometimes a "Visitor" level segment isn't the segment you need... you can always pair UV metric with a segment built on Visit or Hit level logic...

For instance, in the above... you could just build your segments for "Visits with Tracking Code" and "Visits without Tracking Code"... from a Visit perspective, there is no overlap, but at the UV level there will be depending on the various methods that the user came to your site. But this still isn't necessarily wrong.. You did have X Visitors with Tracking Codes, and Y Visitors without... it's just that some of those visitors did both (and it's a good idea to add a description to the table to explain this overlap to the people consuming the report).

And I hear you, business users do like to complain about data quality, usually when they are reading the info wrong. This is why most reports I add descriptions to try and explain exactly what they are looking at, and how best to interpret it.... and there will always be those users who don't read that, but hopefully when those people complain, enough other people will have read it and will realize that person complaining is just wrong....

Now, for Target, we don't actually have Target, but I have worked in another A/B testing tool with integrations (all custom) into our Analytics.. I may not have any of hand pitfalls to help you avoid, but I would expect some of the stuff I have dealt with would have a correlatable equivalence to Target... and I would be happy to help you with specific questions.

Anyway, second novel done 🙂 But I am glad I was able to help you out.